www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is latest recls going into next Phobos, as stated by author in recent post?

reply "Jamboree" <jam bor.ee> writes:


 Mar 21 2005



 next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com>  writes:


On a related note, how does one recompile phobos on Linux? It fails in the 
current recls. 



 Mar 25 2005



 next sibling parent  =?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?=  writes:


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ben Hinkle wrote:
| On a related note, how does one recompile phobos on Linux? It fails in
| the current recls.
|

Play a bit with the GCC settings in recls' makefile.
I think gcc-3.4.2 works but gcc-3.4.3 fails.

Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFCRCe73w+/yD4P9tIRAlbUAJ9NpgFlbBIZmXfJJUXkTzlNhtCvMwCeLz6M
lK/kNmIvcMBybO7tNTFBOwk=
=DgVl
-----END PGP SIGNATURE-----



 Mar 25 2005



prev sibling next sibling parent reply "Carlos Santander B." <csantander619 gmail.com>  writes:


Ben Hinkle wrote:

 On a related note, how does one recompile phobos on Linux? It fails in the 
 current recls. 
 
 


I managed to recompile it (gcc 3.4, or was it 3.3?). What can't be done 
is use it in a program. It fails because std.recls has non-versioned 
extern(Windows) declarations. Obviously, ld will later complain. I don't 
know how to solve it, though.

_______________________
Carlos Santander Bernal



 Mar 25 2005



  parent reply "Matthew" <admin.hat stlsoft.dot.org>  writes:


"Carlos Santander B." <csantander619 gmail.com> wrote in message
news:d21ba4$20e$1 digitaldaemon.com...

 Ben Hinkle wrote:

 On a related note, how does one recompile phobos on Linux? It fails in the
current recls.


 I managed to recompile it (gcc 3.4, or was it 3.3?). What can't be done is use
it in a program. It fails because 
 std.recls has non-versioned extern(Windows) declarations. Obviously, ld will
later complain. I don't know how to solve 
 it, though.


Can you be specific?

Alas - partly because of the stunning lack of Apple customer service - I've not
yet got to the point of using D on 
Linux. I'd be more than happy for people to make changes to the std/recls.d
file in the latest release 
(http://recls.org/downloads.html) and feed them back to me.

Or, if there's the interest, and it's not too bothersome to get GDC going on
Linux, I could be motivated to get D on 
Linux going and do it myself. I've just not been motivated to do that - D on
Linux, that is - as there's been no 
interest in incorporating later versions of recls in Phobos. Any feedback here
- +ve or -ve - would be informative.

FTR: I get plenty of +ve recls feedback from non-D people (e.g.
C/C++/STL/Python/Ruby - even .NET!), so I know the 
library's doing something(s) that people want to do. My suspicion is that the
problems that've been part of recls/D - 
which are substantially out of my control - have made it much less attractive
for D users. Of course, that's largely 
conjecture, since the only feedback has been complaints about the docs being
out of step with the library and the 
problems with Linux builds.

The former is people's reasonable consternation at finding docs out of step
with library. This occured because the 
documentation was submitted to Walter for a version post 1.2 (the current level
of recls within Phobos), sometime around 
1.4 or 1.5. Unfortunately, Walter rejected the library update on the grounds
that there was too much source code, but 
put the new docs in! Ever since, I've been trying explaining this to users, and
promising that, come a newer trimmed 
down version (which happens to be 1.6.1) all would be in sync.

The latter is more my responsibility, since I've not (yet) got around to having
D on Linux. Is this easy to do? If so, 
I'll bite the bullet and get it done. Then it'll all be in Walter's court.

But please understand that getting any upgrade into Phobos is out of my
control. Realistically, if people want a 'good' 
recls, they may have to go to the effort of using the latest release separately
to Phobos. :-(

Matthew



 Mar 25 2005



 next sibling parent  "Matthew" <admin.hat stlsoft.dot.org>  writes:


One last thing, which may or may not be good news: There are no more 1.x
releases of recls planned. I plan to do a 
complete rewrite - recls2 - which will do a great many things that I've learned
should have been in recls 1, including:

    - date/time filtering
    - size filtering
    - content filtering (with plug-in file comparators)
    - search feedback
    - optional breadth-first (and depth-limited) search
    - plug-in pattern matching (along with example plug-ins using pcre, DMC++'s
regexp, Windows PathMatch(), etc. etc.)
    - (optional) platform-independent data representation

and there'll be a greater spectrum of search spaces, including:

    - file systems
    - FTP host directories
    - Win32 registry
    - SourceSafe repositories
    - CVS repositories
    - anything else sensible that people request

and, perhaps of interest:

    - it's quite likely to be written substantially in C, for maximising
portability and minimising size

This'll be the last big extension in my Positive Integration column, before I
start looking at language embedding.

The bad news is that this is not likely to start for some months hence. My
suggestion is, as per the understanding 
Walter and I made some months ago, that the best scenario for Phobos is that
the current version (1.6.1) of recls be 
incorporated and then this newer, better (and probably smaller) recls2 can be
incorporated towards the end of the year.



"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d21vge$pkr$1 digitaldaemon.com...

 "Carlos Santander B." <csantander619 gmail.com> wrote in message
news:d21ba4$20e$1 digitaldaemon.com...

 Ben Hinkle wrote:

 On a related note, how does one recompile phobos on Linux? It fails in the
current recls.


 I managed to recompile it (gcc 3.4, or was it 3.3?). What can't be done is use
it in a program. It fails because 
 std.recls has non-versioned extern(Windows) declarations. Obviously, ld will
later complain. I don't know how to 
 solve it, though.


 Can you be specific?

 Alas - partly because of the stunning lack of Apple customer service - I've
not yet got to the point of using D on 
 Linux. I'd be more than happy for people to make changes to the std/recls.d
file in the latest release 
 (http://recls.org/downloads.html) and feed them back to me.

 Or, if there's the interest, and it's not too bothersome to get GDC going on
Linux, I could be motivated to get D on 
 Linux going and do it myself. I've just not been motivated to do that - D on
Linux, that is - as there's been no 
 interest in incorporating later versions of recls in Phobos. Any feedback here
- +ve or -ve - would be informative.

 FTR: I get plenty of +ve recls feedback from non-D people (e.g.
C/C++/STL/Python/Ruby - even .NET!), so I know the 
 library's doing something(s) that people want to do. My suspicion is that the
problems that've been part of recls/D - 
 which are substantially out of my control - have made it much less attractive
for D users. Of course, that's largely 
 conjecture, since the only feedback has been complaints about the docs being
out of step with the library and the 
 problems with Linux builds.

 The former is people's reasonable consternation at finding docs out of step
with library. This occured because the 
 documentation was submitted to Walter for a version post 1.2 (the current
level of recls within Phobos), sometime 
 around 1.4 or 1.5. Unfortunately, Walter rejected the library update on the
grounds that there was too much source 
 code, but put the new docs in! Ever since, I've been trying explaining this to
users, and promising that, come a newer 
 trimmed down version (which happens to be 1.6.1) all would be in sync.

 The latter is more my responsibility, since I've not (yet) got around to
having D on Linux. Is this easy to do? If so, 
 I'll bite the bullet and get it done. Then it'll all be in Walter's court.

 But please understand that getting any upgrade into Phobos is out of my
control. Realistically, if people want a 
 'good' recls, they may have to go to the effort of using the latest release
separately to Phobos. :-(

 Matthew


 





 Mar 25 2005



prev sibling next sibling parent reply "Carlos Santander B." <csantander619 gmail.com>  writes:


Matthew wrote:

 "Carlos Santander B." <csantander619 gmail.com> wrote in message
news:d21ba4$20e$1 digitaldaemon.com...
 

I managed to recompile it (gcc 3.4, or was it 3.3?). What can't be done is use
it in a program. It fails because 
std.recls has non-versioned extern(Windows) declarations. Obviously, ld will
later complain. I don't know how to solve 
it, though.


 
 
 Can you be specific?
 


I'm not using the latest recls, but the one that comes with Phobos. I 
take it as a problem, but I still think Phobos should just work.

In particular, the problem is line 161 of dmd/src/phobos/std/recls.d. It 
just says "extern(Windows)". To make it even more weird, later in the 
same extern scope, it says "version(Windows)". That doesn't make any 
sense, IMO. Maybe it was supposed to be extern(C)?

_______________________
Carlos Santander Bernal



 Mar 25 2005



  parent  "Matthew" <admin.hat stlsoft.dot.org>  writes:


"Carlos Santander B." <csantander619 gmail.com> wrote in message
news:d22hqj$1ao3$1 digitaldaemon.com...

 Matthew wrote:

 "Carlos Santander B." <csantander619 gmail.com> wrote in message
news:d21ba4$20e$1 digitaldaemon.com...


I managed to recompile it (gcc 3.4, or was it 3.3?). What can't be done is use
it in a program. It fails because 
std.recls has non-versioned extern(Windows) declarations. Obviously, ld will
later complain. I don't know how to 
solve it, though.



 Can you be specific?


 I'm not using the latest recls, but the one that comes with Phobos. I take it
as a problem, but I still think Phobos 
 should just work.


I agree, but what can I do about it? Walter's refused to upgrade since 1.2.1.

The current version, 1.6.1, is ready. I spent a lot of time refactoring and
coallescing common(-ish) code, and also on 
the D mapping. It's just ready to go.


 In particular, the problem is line 161 of dmd/src/phobos/std/recls.d. It just
says "extern(Windows)". To make it even 
 more weird, later in the same extern scope, it says "version(Windows)". That
doesn't make any sense, IMO. Maybe it was 
 supposed to be extern(C)?


Early versions of recls used __stdcall (i.e. extern(Windows) on Win32. Yet
again, this is something that changed a lot 
time ago.



 Mar 25 2005



prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Matthew wrote:


 The former is people's reasonable consternation at finding docs out of step
with library. This occured because the 
 documentation was submitted to Walter for a version post 1.2 (the current
level of recls within Phobos), sometime around 
 1.4 or 1.5. Unfortunately, Walter rejected the library update on the grounds
that there was too much source code, but 
 put the new docs in! Ever since, I've been trying explaining this to users,
and promising that, come a newer trimmed 
 down version (which happens to be 1.6.1) all would be in sync.


[...]

 But please understand that getting any upgrade into Phobos is out of my
control. Realistically, if people want a 'good' 
 recls, they may have to go to the effort of using the latest release
separately to Phobos. :-(


What are the *advantages* of shipping an old recls (and an old zlib
as well) with Phobos ? Wouldn't it be easier if those two subprojects
were stripped out of the "runtime" library ? Or am I missing some
hidden connection between Phobos and Recls (besides Walter/Matthew) ?

I know that building in strings/hashes/unittests has some advantages
over being implemented as libraries (that are being shadowed by bugs
in the built-ins, that are much harder to fix than bugs in libraries),
but are there any such advantages with bundling recls with Phobos ?

--anders



 Mar 26 2005



  parent reply "Jamboree" <jam bor.ee>  writes:


"Anders F Björklund" <afb algonet.se> wrote in message
news:d24nsp$jhm$1 digitaldaemon.com...

 Matthew wrote:


 The former is people's reasonable consternation at finding docs out of step
with library. This occured because the 
 documentation was submitted to Walter for a version post 1.2 (the current
level of recls within Phobos), sometime 
 around 1.4 or 1.5. Unfortunately, Walter rejected the library update on the
grounds that there was too much source 
 code, but put the new docs in! Ever since, I've been trying explaining this to
users, and promising that, come a 
 newer trimmed down version (which happens to be 1.6.1) all would be in sync.


 [...]

 But please understand that getting any upgrade into Phobos is out of my
control. Realistically, if people want a 
 'good' recls, they may have to go to the effort of using the latest release
separately to Phobos. :-(


 What are the *advantages* of shipping an old recls (and an old zlib
 as well) with Phobos ?


You're asking two questions in one, here. Do you mean what are the advantages
of having recls in Phobos? Or what 
advantages are there in having the old (1.2.x) recls in Phobos instead of the
new (1.6.x)?


 Wouldn't it be easier if those two subprojects
 were stripped out of the "runtime" library ? Or am I missing some
 hidden connection between Phobos and Recls (besides Walter/Matthew) ?


Well, one could argue it'd be easier if everything was stripped out. It's a
balance of what's useful and what's not.

One of the main (valid) criticisms of C++ is its parlous standard library. Two
notable absences from it are zlib and 
regexp.

If one wants to pare down Phobos to the absolute minimum, then that's fair, but
it'd be going against what the bulk of 
'normal' users want, I would think.


 I know that building in strings/hashes/unittests has some advantages
 over being implemented as libraries (that are being shadowed by bugs
 in the built-ins, that are much harder to fix than bugs in libraries),
 but are there any such advantages with bundling recls with Phobos ?


As far as I know, there's only been one bug with recls, and that was the UTF-8,
which was fixed sometime ago. The only 
'problem' with it is that updates to it have not been incorporated into Phobos
for a *long* time, and, as I keep 
pointing out, I have precisely 0 control over that.

I'm confident that recls 1.6 would make a fine, useful, substantial
contribution to Phobos. I'm aware several find it 
useful, and suspect many more would in its later guises. Of course, I'm biased,
but since I'd find it a step back if 
zlib were removed, and you've lumped them together, then I think it's fair to
say the same for recls.



 Mar 26 2005



 next sibling parent  "Dave" <Dave_member pathlink.com>  writes:


"Jamboree" <jam bor.ee> wrote in message 
news:d255it$11ji$1 digitaldaemon.com...

 "Anders F Björklund" <afb algonet.se> wrote in message 
 news:d24nsp$jhm$1 digitaldaemon.com...

 Matthew wrote:


 The former is people's reasonable consternation at finding docs out of 
 step with library. This occured because the documentation was submitted 
 to Walter for a version post 1.2 (the current level of recls within 
 Phobos), sometime around 1.4 or 1.5. Unfortunately, Walter rejected the 
 library update on the grounds that there was too much source code, but 
 put the new docs in! Ever since, I've been trying explaining this to 
 users, and promising that, come a newer trimmed down version (which 
 happens to be 1.6.1) all would be in sync.


 [...]

 But please understand that getting any upgrade into Phobos is out of my 
 control. Realistically, if people want a 'good' recls, they may have to 
 go to the effort of using the latest release separately to Phobos. :-(


 What are the *advantages* of shipping an old recls (and an old zlib
 as well) with Phobos ?


 You're asking two questions in one, here. Do you mean what are the 
 advantages of having recls in Phobos? Or what advantages are there in 
 having the old (1.2.x) recls in Phobos instead of the new (1.6.x)?


 Wouldn't it be easier if those two subprojects
 were stripped out of the "runtime" library ? Or am I missing some
 hidden connection between Phobos and Recls (besides Walter/Matthew) ?


 Well, one could argue it'd be easier if everything was stripped out. It's 
 a balance of what's useful and what's not.

 One of the main (valid) criticisms of C++ is its parlous standard library. 
 Two notable absences from it are zlib and regexp.

 If one wants to pare down Phobos to the absolute minimum, then that's 
 fair, but it'd be going against what the bulk of 'normal' users want, I 
 would think.


I very strongly agree.

I know there have been some (actually a pretty small minority) who've been 
arguing for a trimmed-down Phobos for various reasons. I see nothing wrong 
with that as an alternative lib., /but/ when D will be competing against the 

out of the current basic runtime lib. unless it is terribly buggy or some 
other big issues crop up.

Even with Phobos as-is, it's hard to argue that DMD executables are grossly 
bloated, being statically linked to Phobos as they are.


 I know that building in strings/hashes/unittests has some advantages
 over being implemented as libraries (that are being shadowed by bugs
 in the built-ins, that are much harder to fix than bugs in libraries),
 but are there any such advantages with bundling recls with Phobos ?


 As far as I know, there's only been one bug with recls, and that was the 
 UTF-8, which was fixed sometime ago. The only 'problem' with it is that 
 updates to it have not been incorporated into Phobos for a *long* time, 
 and, as I keep pointing out, I have precisely 0 control over that.

 I'm confident that recls 1.6 would make a fine, useful, substantial 
 contribution to Phobos. I'm aware several find it useful, and suspect many 
 more would in its later guises. Of course, I'm biased, but since I'd find 
 it a step back if zlib were removed, and you've lumped them together, then 
 I think it's fair to say the same for recls.


Again, strongly agree.

- Dave



 Mar 26 2005



prev sibling  parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Jamboree wrote:


What are the *advantages* of shipping an old recls (and an old zlib
as well) with Phobos ?


 
 You're asking two questions in one, here. Do you mean what are the advantages
of having recls in Phobos? Or what 
 advantages are there in having the old (1.2.x) recls in Phobos instead of the
new (1.6.x)?


I meant that: since the bundled version can't be kept up to date, 
wouldn't it be better to use the "standard" installation of recls ?

The thing against zlib is that it is an old version (1.2.1), without
the security updates that eventually went into zlib version 1.2.2...


 If one wants to pare down Phobos to the absolute minimum, then that's fair,
but it'd be going against what the bulk of 
 'normal' users want, I would think.


Maybe we need a "D Micro Edition" version of Phobos then, with just
what is needed for the language to function. (like garbage collection
and handlers for the assertions and other callbacks, for instance...)

Then again, I wanted to separate the library from the DMD compiler too.


 As far as I know, there's only been one bug with recls, and that was the
UTF-8, which was fixed sometime ago. The only 
 'problem' with it is that updates to it have not been incorporated into Phobos
for a *long* time, and, as I keep 
 pointing out,



 I have precisely 0 control over that.


Matthew, is that you ? :-) ("Jamboree")


 I'm confident that recls 1.6 would make a fine, useful, substantial
contribution to Phobos. I'm aware several find it 
 useful, and suspect many more would in its later guises. Of course, I'm
biased, but since I'd find it a step back if 
 zlib were removed, and you've lumped them together, then I think it's fair to
say the same for recls.


Do you mean "it's a substantial D contribution", or did you really mean 
Phobos ? I'm not arguing that the libraries make a good contribution,
just think it was easier if it wasn't bundled with the runtime library ?

I think building things into the runtime library has rather similar
pros and cons as building features into the language itself, great if
it works (and is up to date) - but useless if it doesn't, or is too old.

Q: Couldn't it be bundled with the "download", but still be separate ?
(so that one could upgrade it to a later library version, if available)

--anders

PS. Sorry for lumping several things together in one post. (i.e. "zlib")



 Mar 27 2005



  parent reply J C Calvarese <jcc7 cox.net>  writes:


Anders F Björklund wrote:

 Jamboree wrote:
 

 What are the *advantages* of shipping an old recls (and an old zlib
 as well) with Phobos ?



 You're asking two questions in one, here. Do you mean what are the 
 advantages of having recls in Phobos? Or what advantages are there in 
 having the old (1.2.x) recls in Phobos instead of the new (1.6.x)?


 
 
 I meant that: since the bundled version can't be kept up to date, 
 wouldn't it be better to use the "standard" installation of recls ?


That's a good point. If the recls were easy for a novice to setup and 
use, I'd see it as a good idea to ask Walter to simply remove recls from 
Phobos. But I'm not so sure that's the case. Am I wrong on this?

Does the standalone version include a pre-compiled .lib (or even a 
makefile) for a lazy Windows user like me? I can't find it. Did I 
download the wrong file or something?

And it looks like I'd have to compile stlsoft-1.8.3-beta3, too. 
Stlsoft's Readme.txt and ReleaseNotes-1.8.3-beta3.txt look nice, but I 
couldn't track down any tips for compiling these source files. I thought 
  maybe the stlsoft FAQ would tell me how to put it all together, but I 
guess I'm the first one that didn't find it self-explanatory.

I can muster up effort to download a separate library, but I'm much too 
lazy to be persuaded to compile a bunch C/C++ libraries without even a 
guide. This may not be a big deal for people with a strong C/C++ 
background, but if I have to do a bunch of research to compile it 
myself, I'm just not going to end up using the standalone version of recls.

At least with the "from the dawn of time" version compiled into Phobos, 
I don't have to download a bunch of separate files and sift through them 
hunting for instructions that may not exist.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/



 Mar 27 2005



 next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org>  writes:


 Does the standalone version include a pre-compiled .lib (or even a makefile)
for a lazy Windows user like me?


No. I plan to do that in the future, but it's not happened yet.


 I can't find it. Did I download the wrong file or something?


Makefiles are under the /build directory. I should mention this in a readme in
the root level. :$


 And it looks like I'd have to compile stlsoft-1.8.3-beta3, too.


STLSoft is 100% header-only, so no compilation required (or possible <G>)


 Stlsoft's Readme.txt and ReleaseNotes-1.8.3-beta3.txt look nice, but I
couldn't track down any tips for compiling 
 these source files. I thought maybe the stlsoft FAQ would tell me how to put
it all together, but I guess I'm the 
 first one that didn't find it self-explanatory.


The FAQ is not good. I'm not exactly talented when it comes to docs. :(


 I can muster up effort to download a separate library, but I'm much too lazy
to be persuaded to compile a bunch C/C++ 
 libraries without even a guide. This may not be a big deal for people with a
strong C/C++ background, but if I have to 
 do a bunch of research to compile it myself, I'm just not going to end up
using the standalone version of recls.


Sounds like a reasonable point of view. I should add more "Getting started for
D users" type help. It's that 
double-whammy of not knowing what you know implicitly, and being short on time.
;)


 At least with the "from the dawn of time" version compiled into Phobos, I
don't have to download a bunch of separate 
 files and sift through them hunting for instructions that may not exist.


Indeed. That's a powerful argument for keeping recls in Phobos. I guess we just
have to hope Walter'll.



 Mar 27 2005



  parent reply J C Calvarese <jcc7 cox.net>  writes:


Matthew wrote:

Does the standalone version include a pre-compiled .lib (or even a makefile)
for a lazy Windows user like me?


 
 
 No. I plan to do that in the future, but it's not happened yet.


Cool. That'd be very helpful.


I can't find it. Did I download the wrong file or something?


 
 
 Makefiles are under the /build directory. I should mention this in a readme in
the root level. :$


If I knew to look for a makefile in recls, I would've found it pretty 
quickly. I just got distracted trying to build STLsoft. (oops)


And it looks like I'd have to compile stlsoft-1.8.3-beta3, too.


 
 
 STLSoft is 100% header-only, so no compilation required (or possible <G>)


Well, that explains the absence of a makefile. (oops, again)

...


I can muster up effort to download a separate library, but I'm much too lazy to
be persuaded to compile a bunch C/C++ 
libraries without even a guide. This may not be a big deal for people with a
strong C/C++ background, but if I have to 
do a bunch of research to compile it myself, I'm just not going to end up using
the standalone version of recls.


 
 
 Sounds like a reasonable point of view. I should add more "Getting started for
D users" type help. It's that 
 double-whammy of not knowing what you know implicitly, and being short on
time. ;)


Yes, I understand that you're trying to cater to a lot of different
programming languages. And each person only has so many hours in each day.

I guess I'll try to include some newbie-friendly tips on compiling recls 
at http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Phobos/StdRecls
(provided I finally manage to get it built myself).

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/



 Mar 27 2005



  parent reply "Matthew" <admin.hat stlsoft.dot.org>  writes:


Ok, here's the fast version:

1. Download and install STLSoft 1.8.3 beta 4. Wherever you put it - e.g.
C:\3pty\STLSoft\1.8.3 or 
/usr/include/stlsoft/1.8.3 - you need to setup and environment variable
STLSOFT_INCLUDE that points to the directory 
containing stlsoft.h. The other headers that are in relative directories - e.g.
winstl/path.hpp - are under that main 
directory. Note: recls 1.6.x also uses some of the "in progress" STLSoft
components - things that are very likely to go 
in on the next non-beta release - but the recls makefiles contain include
directorives for both "-I$(STLSOFT_INCLUDE)" 
and "-I$(STLSOFT_INCLUDE)/inprogress", so you shouldn't have to worry about
that. (Just FYI, in case <g>)

2. Say you're building recls for DMC++ on Win32. You'll need to be in a CLI
which has the STLSOFT_INCLUDE environment 
set, and can see the DMC++ toolset. Then go to the <recls>/build/dm directory,
and just type "make". Or type "make test" 
and it'll run the sample programs after a successful build.

3. If 1. is set up, which should mean that 2. builds ok, then you'll have
recls.dm.lib and recls.dm.debug.lib in the 
<recls>/lib directory. That contains all the core library, and 'll need to be
linked in to your exe

4. Then just go to <recls>/mappings/D, and compile
<recls>/mappings/D/std/recls.d. If you like, you can use the makefile 
there, and just type "make". Assuming DMD is successfully installed and all
components visible, you should have the 
libraries recls.D.debug.lib and recls.D.lib, which, along with the core
library, can be linked to form you exe.

That should be it, but I may have missed something obvious. HTH

Cheers

Matthew

"J C Calvarese" <jcc7 cox.net> wrote in message
news:d27l9o$hbq$1 digitaldaemon.com...

 Matthew wrote:

Does the standalone version include a pre-compiled .lib (or even a makefile)
for a lazy Windows user like me?



 No. I plan to do that in the future, but it's not happened yet.


 Cool. That'd be very helpful.


I can't find it. Did I download the wrong file or something?



 Makefiles are under the /build directory. I should mention this in a readme in
the root level. :$


 If I knew to look for a makefile in recls, I would've found it pretty quickly.
I just got distracted trying to build 
 STLsoft. (oops)


And it looks like I'd have to compile stlsoft-1.8.3-beta3, too.



 STLSoft is 100% header-only, so no compilation required (or possible <G>)


 Well, that explains the absence of a makefile. (oops, again)

 ...


I can muster up effort to download a separate library, but I'm much too lazy to
be persuaded to compile a bunch C/C++ 
libraries without even a guide. This may not be a big deal for people with a
strong C/C++ background, but if I have 
to do a bunch of research to compile it myself, I'm just not going to end up
using the standalone version of recls.



 Sounds like a reasonable point of view. I should add more "Getting started for
D users" type help. It's that 
 double-whammy of not knowing what you know implicitly, and being short on
time. ;)


 Yes, I understand that you're trying to cater to a lot of different
 programming languages. And each person only has so many hours in each day.

 I guess I'll try to include some newbie-friendly tips on compiling recls at 
 http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Phobos/StdRecls
 (provided I finally manage to get it built myself).

 -- 
 Justin (a/k/a jcc7)
 http://jcc_7.tripod.com/d/ 





 Mar 27 2005



  parent reply J C Calvarese <jcc7 cox.net>  writes:


Matthew wrote:

 Ok, here's the fast version:
 
 1. Download and install STLSoft 1.8.3 beta 4. Wherever you put it - e.g.
C:\3pty\STLSoft\1.8.3 or 
 /usr/include/stlsoft/1.8.3 - you need to setup and environment variable
STLSOFT_INCLUDE that points to the directory 
 containing stlsoft.h. The other headers that are in relative directories -
e.g. winstl/path.hpp - are under that main 
 directory. Note: recls 1.6.x also uses some of the "in progress" STLSoft
components - things that are very likely to go 
 in on the next non-beta release - but the recls makefiles contain include
directorives for both "-I$(STLSOFT_INCLUDE)" 
 and "-I$(STLSOFT_INCLUDE)/inprogress", so you shouldn't have to worry about
that. (Just FYI, in case <g>)
 
 2. Say you're building recls for DMC++ on Win32. You'll need to be in a CLI
which has the STLSOFT_INCLUDE environment 
 set, and can see the DMC++ toolset. Then go to the <recls>/build/dm directory,
and just type "make". Or type "make test" 
 and it'll run the sample programs after a successful build.
 
 3. If 1. is set up, which should mean that 2. builds ok, then you'll have
recls.dm.lib and recls.dm.debug.lib in the 
 <recls>/lib directory. That contains all the core library, and 'll need to be
linked in to your exe
 
 4. Then just go to <recls>/mappings/D, and compile
<recls>/mappings/D/std/recls.d. If you like, you can use the makefile 
 there, and just type "make". Assuming DMD is successfully installed and all
components visible, you should have the 
 libraries recls.D.debug.lib and recls.D.lib, which, along with the core
library, can be linked to form you exe.
 
 That should be it, but I may have missed something obvious. HTH


Thanks. Looks good. I've added already added this to Wiki4D. I plan to 
go in and explain a tad more about installing DMC and STLport (and 
adding STLport to the INCLUDE path in sc.ini), but I think what you've 
written covers most of the bases for the actual recls part.

I finally managed to compile recls.dm.lib, but I can't get my test 
program to link:

<code>
import std.recls;

void main()
{
     FileSearch  search  = new FileSearch(".", "*.*", 
RECLS_FLAG.RECLS_F_RECURSIVE);
     foreach(Entry entry; search)
     {
         with(entry)
         {
             if(!shortFile())
                 printf("%.*s%.*s\n", directoryPath(), file());
             else
                 printf("%.*s%.*s (%.*s)\n", directoryPath(), file(), 
shortFile());
         }
     }
}
</code>


<command line>
I:\pgm\d\recls>dmd test.d D:\dm\recls-1.6.1\lib\recls.dm.lib 
-ID:\dm\recls-1.6.1
\mappings\D
d:\dmd\bin\..\..\dm\bin\link.exe 
test,,,D:\dm\recls-1.6.1\lib\recls.dm.lib+user3
2+kernel32/noi;
OPTLINK (R) for Win32  Release 7.50B1
Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

test.obj(test)
  Error 42: Symbol Undefined __Class_3std5recls10FileSearch
test.obj(test)
  Error 42: Symbol Undefined 
_D3std5recls10FileSearch5_ctorFAaAakZC3std5recls10Fi
leSearch
--- errorlevel 2
</command line>

My instinct is that I need to recompile Phobos to get it to work since 
it's called std.recls. It's too late for me to play around with this 
more tonight. I plan to continue my investigation tomorrow. I think I'm 
close to understanding what's going on. ;)

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/



 Mar 27 2005



  parent reply "Matthew" <admin.hat stlsoft.dot.org>  writes:


"J C Calvarese" <jcc7 cox.net> wrote in message
news:d281d0$s64$1 digitaldaemon.com...

 Matthew wrote:

 Ok, here's the fast version:

 1. Download and install STLSoft 1.8.3 beta 4. Wherever you put it - e.g.
C:\3pty\STLSoft\1.8.3 or 
 /usr/include/stlsoft/1.8.3 - you need to setup and environment variable
STLSOFT_INCLUDE that points to the directory 
 containing stlsoft.h. The other headers that are in relative directories -
e.g. winstl/path.hpp - are under that main 
 directory. Note: recls 1.6.x also uses some of the "in progress" STLSoft
components - things that are very likely to 
 go in on the next non-beta release - but the recls makefiles contain include
directorives for both 
 "-I$(STLSOFT_INCLUDE)" and "-I$(STLSOFT_INCLUDE)/inprogress", so you shouldn't
have to worry about that. (Just FYI, 
 in case <g>)

 2. Say you're building recls for DMC++ on Win32. You'll need to be in a CLI
which has the STLSOFT_INCLUDE environment 
 set, and can see the DMC++ toolset. Then go to the <recls>/build/dm directory,
and just type "make". Or type "make 
 test" and it'll run the sample programs after a successful build.

 3. If 1. is set up, which should mean that 2. builds ok, then you'll have
recls.dm.lib and recls.dm.debug.lib in the 
 <recls>/lib directory. That contains all the core library, and 'll need to be
linked in to your exe

 4. Then just go to <recls>/mappings/D, and compile
<recls>/mappings/D/std/recls.d. If you like, you can use the 
 makefile there, and just type "make". Assuming DMD is successfully installed
and all components visible, you should 
 have the libraries recls.D.debug.lib and recls.D.lib, which, along with the
core library, can be linked to form you 
 exe.

 That should be it, but I may have missed something obvious. HTH


 Thanks. Looks good. I've added already added this to Wiki4D. I plan to go in
and explain a tad more about installing 
 DMC and STLport (and adding STLport to the INCLUDE path in sc.ini), but I
think what you've written covers most of the 
 bases for the actual recls part.

 I finally managed to compile recls.dm.lib, but I can't get my test program to
link:

 <code>
 import std.recls;

 void main()
 {
     FileSearch  search  = new FileSearch(".", "*.*",
RECLS_FLAG.RECLS_F_RECURSIVE);
     foreach(Entry entry; search)
     {
         with(entry)
         {
             if(!shortFile())
                 printf("%.*s%.*s\n", directoryPath(), file());
             else
                 printf("%.*s%.*s (%.*s)\n", directoryPath(), file(),
shortFile());
         }
     }
 }
 </code>


 <command line>
 I:\pgm\d\recls>dmd test.d D:\dm\recls-1.6.1\lib\recls.dm.lib
-ID:\dm\recls-1.6.1
 \mappings\D
 d:\dmd\bin\..\..\dm\bin\link.exe
test,,,D:\dm\recls-1.6.1\lib\recls.dm.lib+user3
 2+kernel32/noi;
 OPTLINK (R) for Win32  Release 7.50B1
 Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

 test.obj(test)
  Error 42: Symbol Undefined __Class_3std5recls10FileSearch
 test.obj(test)
  Error 42: Symbol Undefined
_D3std5recls10FileSearch5_ctorFAaAakZC3std5recls10Fi
 leSearch
 --- errorlevel 2
 </command line>

 My instinct is that I need to recompile Phobos to get it to work since it's
called std.recls. It's too late for me to 
 play around with this more tonight. I plan to continue my investigation
tomorrow. I think I'm close to understanding 
 what's going on. ;)


Hmm. Nothing immediately springs to mind as wrong, although I note you've
omitted the recls core library from the link. 
But since it's complaining about not seeing the recls/D mapping lib, which
you've specified, that may not have anything 
to do with it.

FYI: I've never had a problem with linking the recls lib along with the
standard Phobos distro. It's always selected the 
one explicitly specified to the linker.

...

Still pondering your command line. I can't see anything. I'll keep thinking ...



 Mar 27 2005



  parent reply J C Calvarese <jcc7 cox.net>  writes:


Matthew wrote:

 "J C Calvarese" <jcc7 cox.net> wrote in message
news:d281d0$s64$1 digitaldaemon.com...


...

<command line>
I:\pgm\d\recls>dmd test.d D:\dm\recls-1.6.1\lib\recls.dm.lib -ID:\dm\recls-1.6.1
\mappings\D
d:\dmd\bin\..\..\dm\bin\link.exe test,,,D:\dm\recls-1.6.1\lib\recls.dm.lib+user3
2+kernel32/noi;
OPTLINK (R) for Win32  Release 7.50B1
Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

test.obj(test)
 Error 42: Symbol Undefined __Class_3std5recls10FileSearch
test.obj(test)
 Error 42: Symbol Undefined _D3std5recls10FileSearch5_ctorFAaAakZC3std5recls10Fi
leSearch
--- errorlevel 2
</command line>

My instinct is that I need to recompile Phobos to get it to work since it's
called std.recls. It's too late for me to 
play around with this more tonight. I plan to continue my investigation
tomorrow. I think I'm close to understanding 
what's going on. ;)


 
 
 Hmm. Nothing immediately springs to mind as wrong, although I note you've
omitted the recls core library from the link. 
 But since it's complaining about not seeing the recls/D mapping lib, which
you've specified, that may not have anything 
 to do with it.


You mean the recls core library is something other than "recls.dm.lib"?


 FYI: I've never had a problem with linking the recls lib along with the
standard Phobos distro. It's always selected the 
 one explicitly specified to the linker.


Okay, I just thought that might be a problem. Maybe I'll do a fresh 
reinstall of DMC and try again. It could be something weird about how my 
system is cobbled together. I tend to just unzip one version of the DM 
compiler tools over the old stuff.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/



 Mar 27 2005



  parent reply "Matthew" <admin.hat stlsoft.dot.org>  writes:


"J C Calvarese" <jcc7 cox.net> wrote in message
news:d283c8$u1h$1 digitaldaemon.com...

 Matthew wrote:

 "J C Calvarese" <jcc7 cox.net> wrote in message
news:d281d0$s64$1 digitaldaemon.com...


 ...

<command line>
I:\pgm\d\recls>dmd test.d D:\dm\recls-1.6.1\lib\recls.dm.lib -ID:\dm\recls-1.6.1
\mappings\D
d:\dmd\bin\..\..\dm\bin\link.exe test,,,D:\dm\recls-1.6.1\lib\recls.dm.lib+user3
2+kernel32/noi;
OPTLINK (R) for Win32  Release 7.50B1
Copyright (C) Digital Mars 1989 - 2001  All Rights Reserved

test.obj(test)
 Error 42: Symbol Undefined __Class_3std5recls10FileSearch
test.obj(test)
 Error 42: Symbol Undefined _D3std5recls10FileSearch5_ctorFAaAakZC3std5recls10Fi
leSearch
--- errorlevel 2
</command line>

My instinct is that I need to recompile Phobos to get it to work since it's
called std.recls. It's too late for me to 
play around with this more tonight. I plan to continue my investigation
tomorrow. I think I'm close to understanding 
what's going on. ;)



 Hmm. Nothing immediately springs to mind as wrong, although I note you've
omitted the recls core library from the 
 link. But since it's complaining about not seeing the recls/D mapping lib,
which you've specified, that may not have 
 anything to do with it.


 You mean the recls core library is something other than "recls.dm.lib"?


No. He he. We've both been hit by the little men with the large green bats.

You need to specify
    recls.D.lib - the recls/D mapping
    recls.dm.lib - the recls core C/C++ library

I couldn't see the woods for the tree! :-)



 Mar 27 2005



  parent  J C Calvarese <jcc7 cox.net>  writes:


Matthew wrote:

 "J C Calvarese" <jcc7 cox.net> wrote in message
news:d283c8$u1h$1 digitaldaemon.com...
 


...

You mean the recls core library is something other than "recls.dm.lib"?


 
 No. He he. We've both been hit by the little men with the large green bats.


Or giant white rabbits.


 You need to specify
     recls.D.lib - the recls/D mapping
     recls.dm.lib - the recls core C/C++ library


I hadn't even created a recls.D.lib. I figured the magical build process 
had taken care of those types of issues and put D's information in 
recls.dm.lib. Oops!

So I did something like this:

dmd -c std\recls.d D:\dm\recls-1.6.1\lib\recls.dm.lib
lib -c D:\dm\recls-1.6.1\lib\recls.D.lib recls.obj

Voila! recls.D.lib is born!


 I couldn't see the woods for the tree! :-)


Pretty much, yeah.

Thanks for bearing with me. I finally got it to work!

dmd test.d D:\dm\recls-1.6.1\lib\recls.dm.lib 
D:\dm\recls-1.6.1\lib\recls.D.lib -ID:\dm\recls-1.6.1\mappings\D wininet.lib

(By the way, I don't know where you found your wininet.lib, but I was 
able to create my own, so that's what I used: 
http://svn.dsource.org/svn/projects/bindings/trunk/lib/wininet.lib. I 
guess I'll know if it's actually correct when I try to search an FTP 
site sometime.)

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/



 Mar 27 2005



prev sibling  parent  "Regan Heath" <regan netwin.co.nz>  writes:


On Sun, 27 Mar 2005 15:30:44 -0600, J C Calvarese <jcc7 cox.net> wrote:

 Anders F Björklund wrote:

 Jamboree wrote:


 What are the *advantages* of shipping an old recls (and an old zlib
 as well) with Phobos ?



 You're asking two questions in one, here. Do you mean what are the  
 advantages of having recls in Phobos? Or what advantages are there in  
 having the old (1.2.x) recls in Phobos instead of the new (1.6.x)?


   I meant that: since the bundled version can't be kept up to date,  
 wouldn't it be better to use the "standard" installation of recls ?


 That's a good point. If the recls were easy for a novice to setup and  
 use, I'd see it as a good idea to ask Walter to simply remove recls from  
 Phobos. But I'm not so sure that's the case. Am I wrong on this?

 Does the standalone version include a pre-compiled .lib (or even a  
 makefile) for a lazy Windows user like me? I can't find it. Did I  
 download the wrong file or something?


Why don't/can't we...

- Split recls (and others like it - some sort of discretion is reqd for  
deciding how/what) into it's own lib file.
- Package the recls lib (and others) with the default D download.

What this means is that:

- People who get D will get recls.
- People who want/need the more recent recls can simply download a  
prebuilt lib, and/or build one *without* having to rebuild the entirety of  
phobos as well.

Further, it means:

- Several different D library packages made up of different sub-libraries  
can be produced/downloaded.
- Parts of the library can be downloaded seperately (updates, new  
sub-libraries) and added to the whole.
and so on.

So, the D standard library could be called/defined a modular library made  
up of sub-libraries like "core" (the core functions/modules), "recls",  
..etc..

I think it would make life easier for users, they just grab a file and  
save it in the right place and hey-presto they have updated part of the "D  
standard library", no messy building required.

It would make life easier for library maintainers, eg if they get a  
complaint, bug, etc they can fix it and produce a download which the user  
can immediately grab, try and report back.

Regan



 Mar 27 2005



prev sibling  parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Matthew wrote:


 Alas - partly because of the stunning lack of Apple customer service - I've
not yet got to the point of using D on 
 Linux. I'd be more than happy for people to make changes to the std/recls.d
file in the latest release 
 (http://recls.org/downloads.html) and feed them back to me.


Maybe I'm missing something here, but what does Apple's support has to 
with Linux ? If anything, it should have more to do with Mac OS X, yes ?
(although I am running both Mac OS X and Linux on my own Apple machines)


 The latter is more my responsibility, since I've not (yet) got around to
having D on Linux. Is this easy to do? If so, 
 I'll bite the bullet and get it done. Then it'll all be in Walter's court.


It's not very hard to install GDC on a regular Linux platform...
There's a specfile for RPM, an ebuild for Gentoo, and a Makefile ?
http://www.algonet.se/~afb/d/Makefile (downloads, compiles, installs)

Installing DMD, on a supported X86 Linux, is even easier to do :
http://www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial/InstallingDCompiler

--anders



 Mar 26 2005



  parent reply "Matthew" <admin.hat stlsoft.dot.org>  writes:


"Anders F Björklund" <afb algonet.se> wrote in message
news:d24ofu$jv8$1 digitaldaemon.com...

 Matthew wrote:


 Alas - partly because of the stunning lack of Apple customer service - I've
not yet got to the point of using D on 
 Linux. I'd be more than happy for people to make changes to the std/recls.d
file in the latest release 
 (http://recls.org/downloads.html) and feed them back to me.


 Maybe I'm missing something here, but what does Apple's support has to with
Linux ? If anything, it should have more 
 to do with Mac OS X, yes ?
 (although I am running both Mac OS X and Linux on my own Apple machines)


Oh, I was just going to use getting an Apple into springboarding me into doing
D primarily on Linux. ;) Since they've 
demotivated me re buying one, it's put a crimp on that side of things.


 The latter is more my responsibility, since I've not (yet) got around to
having D on Linux. Is this easy to do? If 
 so, I'll bite the bullet and get it done. Then it'll all be in Walter's court.


 It's not very hard to install GDC on a regular Linux platform...
 There's a specfile for RPM, an ebuild for Gentoo, and a Makefile ?
 http://www.algonet.se/~afb/d/Makefile (downloads, compiles, installs)

 Installing DMD, on a supported X86 Linux, is even easier to do :
 http://www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial/InstallingDCompiler


Thanks. I'll note this down. :-)



 Mar 27 2005



 next sibling parent reply Dave <Dave_member pathlink.com>  writes:


In article <d27p22$kv0$1 digitaldaemon.com>, Matthew says...

"Anders F Björklund" <afb algonet.se> wrote in message
news:d24ofu$jv8$1 digitaldaemon.com...

 Matthew wrote:


 Alas - partly because of the stunning lack of Apple customer service - I've
not yet got to the point of using D on 
 Linux. I'd be more than happy for people to make changes to the std/recls.d
file in the latest release 
 (http://recls.org/downloads.html) and feed them back to me.


 Maybe I'm missing something here, but what does Apple's support has to with
Linux ? If anything, it should have more 
 to do with Mac OS X, yes ?
 (although I am running both Mac OS X and Linux on my own Apple machines)


Oh, I was just going to use getting an Apple into springboarding me into doing
D primarily on Linux. ;) Since they've 
demotivated me re buying one, it's put a crimp on that side of things.


 The latter is more my responsibility, since I've not (yet) got around to
having D on Linux. Is this easy to do? If 
 so, I'll bite the bullet and get it done. Then it'll all be in Walter's court.


 It's not very hard to install GDC on a regular Linux platform...
 There's a specfile for RPM, an ebuild for Gentoo, and a Makefile ?
 http://www.algonet.se/~afb/d/Makefile (downloads, compiles, installs)

 Installing DMD, on a supported X86 Linux, is even easier to do :
 http://www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial/InstallingDCompiler


Thanks. I'll note this down. :-)


It sounds like you were ready to spring (for an above avg. cost) new system.

If that's the case - could I suggest something? I'm really impressed with the
AMD64 chip and some of the boards coming out for it now, as well as the Linux
support for them (in general). If a laptop is what you need, I've been told some
of the systems running the AMD64 chip are nice as well, as long as you don't
need to run them on battery a lot.

Dual- (Windows/Linux32) or tri- (Windows/Linux32/Linux64) boot the new AMD64
system and you'll have a nice all-around, reasonably high-perf. system for a
reasonable cost as well.

I'd also suggest making sure the Linux distro. you are thinking of using
supports the board you buy, though (for example, up until recently SATA support
for Linux was about 6 months behind Windows support, and you might want to
Google for problems supporting the new system's Video Card - things like that).

Just in case that is an option for you..

- Dave



 Mar 27 2005



  parent reply Georg Wrede <georg.wrede nospam.org>  writes:


Dave wrote:

 It sounds like you were ready to spring (for an above avg. cost) new
 system.
 
 If that's the case - could I suggest something? I'm really impressed
 with the AMD64 chip and some of the boards coming out for it now, as
 well as the Linux support for them (in general). If a laptop is what
 you need, I've been told some of the systems running the AMD64 chip
 are nice as well, as long as you don't need to run them on battery a
 lot.


There are two speeds for a computer: too slow, and adequate.

Buy something 500 times faster than adequate, and you won't even see the 
difference to adequate. (Everything happens "right now" anyhow.) I've 
used the biggest Cray in the Nordic Countries, so I know.


 Dual- (Windows/Linux32) or tri- (Windows/Linux32/Linux64) boot the
 new AMD64 system and you'll have a nice all-around, reasonably
 high-perf. system for a reasonable cost as well.


Dunno. Ok, if the real motivation is to explain to wife why you need the 
coolest laptop around, then Linux64 might be the thing. But for non-game 
use, I'd use an older laptop.

An older one has got several advantages: longer battery life compared to 
the screamers (that even burn your willy), and all popular distros 
install right off the box, with all hardware detected and properly 
configured.

I bought two IBM ThinkPad T21 machines second-hand, 18 months ago. Both 
have a 20GB disk, and an 800MHz cpu, with 256MB ram. Got even a 6 month 
warranty, and Original Licenses for Windows, actually backed up by IBM 
service!

On one, I use RedHat 9 and Windows 98, on the other Fedora 3 and Windows 
2000.

The Linuxes have always been Full installs, and on the windowses I have 
a lot of applications (Start/Programs is taller than the screen, even 
though I've grouped apps), Open Office, Microsoft Office, full Cygwin, 
graphics programs, programming languages, etc. Not having windows on 
NTFS file system gives me full read/write access from Linux.

Not downloading music or movies lets me have ample disk space. (I'm too 
old to listen to music while programming, and too much "TV-watching" 
only erodes your IQ.)  :-) Currently I use these laptops, often side by 
side, with one on windows and the other on linux.


 I'd also suggest making sure the Linux distro. you are thinking of
 using supports the board you buy, though (for example, up until
 recently SATA support for Linux was about 6 months behind Windows
 support, and you might want to Google for problems supporting the new
 system's Video Card - things like that).


SATA and newest main boards simply are not needed for work use. 
Especially with Linux!



 Mar 29 2005



  parent reply Dave <Dave_member pathlink.com>  writes:


In article <42493EF7.8030104 nospam.org>, Georg Wrede says...

Dave wrote:

 It sounds like you were ready to spring (for an above avg. cost) new
 system.
 
 If that's the case - could I suggest something? I'm really impressed
 with the AMD64 chip and some of the boards coming out for it now, as
 well as the Linux support for them (in general). If a laptop is what
 you need, I've been told some of the systems running the AMD64 chip
 are nice as well, as long as you don't need to run them on battery a
 lot.


There are two speeds for a computer: too slow, and adequate.

Buy something 500 times faster than adequate, and you won't even see the 
difference to adequate. (Everything happens "right now" anyhow.) I've 
used the biggest Cray in the Nordic Countries, so I know.


 Dual- (Windows/Linux32) or tri- (Windows/Linux32/Linux64) boot the
 new AMD64 system and you'll have a nice all-around, reasonably
 high-perf. system for a reasonable cost as well.


Dunno. Ok, if the real motivation is to explain to wife why you need the 
coolest laptop around, then Linux64 might be the thing. But for non-game 
use, I'd use an older laptop.

An older one has got several advantages: longer battery life compared to 
the screamers (that even burn your willy), and all popular distros 
install right off the box, with all hardware detected and properly 
configured.

I bought two IBM ThinkPad T21 machines second-hand, 18 months ago. Both 
have a 20GB disk, and an 800MHz cpu, with 256MB ram. Got even a 6 month 
warranty, and Original Licenses for Windows, actually backed up by IBM 
service!

On one, I use RedHat 9 and Windows 98, on the other Fedora 3 and Windows 
2000.

The Linuxes have always been Full installs, and on the windowses I have 
a lot of applications (Start/Programs is taller than the screen, even 
though I've grouped apps), Open Office, Microsoft Office, full Cygwin, 
graphics programs, programming languages, etc. Not having windows on 
NTFS file system gives me full read/write access from Linux.

Not downloading music or movies lets me have ample disk space. (I'm too 
old to listen to music while programming, and too much "TV-watching" 
only erodes your IQ.)  :-) Currently I use these laptops, often side by 
side, with one on windows and the other on linux.


 I'd also suggest making sure the Linux distro. you are thinking of
 using supports the board you buy, though (for example, up until
 recently SATA support for Linux was about 6 months behind Windows
 support, and you might want to Google for problems supporting the new
 system's Video Card - things like that).


SATA and newest main boards simply are not needed for work use. 
Especially with Linux!


Well, I gotta chalk all this up to "it depends on what you do". If you spend a
good part of the day waiting for C++ builds or DB queries to finish then I'd say
that usually an upgrade to faster equipment pays off. 10 or 20 coffee breaks a
day are nice, but kinda hard on the kidneys and wallet <g>

And then of course there's the gaming aspect ;)

Generally I'd agree though - top of the line systems aren't worth the extra
ching. And of course there's the argument that it's better to develop (or at
least test) on more 'standard' hardware to get an accurate feel how an app. will
perform on most systems.

That said, AMD64 chips and boards are often a price/performance value compared
to comparable Intel stuff, plus you have an upgrade path.

- Dave



 Mar 29 2005



  parent  Georg Wrede <georg.wrede nospam.org>  writes:


Dave wrote:

 In article <42493EF7.8030104 nospam.org>, Georg Wrede says...
 

 Dave wrote:
 

 It sounds like you were ready to spring (for an above avg. cost)
 new system.
 
 If that's the case - could I suggest something? I'm really
 impressed with the AMD64 chip and some of the boards coming out
 for it now, as well as the Linux support for them (in general).
 If a laptop is what you need, I've been told some of the systems
 running the AMD64 chip are nice as well, as long as you don't
 need to run them on battery a lot.


 
 There are two speeds for a computer: too slow, and adequate.
 
 Buy something 500 times faster than adequate, and you won't even
 see the difference to adequate. (Everything happens "right now"
 anyhow.) I've used the biggest Cray in the Nordic Countries, so I
 know.
 

 Dual- (Windows/Linux32) or tri- (Windows/Linux32/Linux64) boot
 the new AMD64 system and you'll have a nice all-around,
 reasonably high-perf. system for a reasonable cost as well.


 
 Dunno. Ok, if the real motivation is to explain to wife why you
 need the coolest laptop around, then Linux64 might be the thing.
 But for non-game use, I'd use an older laptop.
 
 An older one has got several advantages: longer battery life
 compared to the screamers (that even burn your willy), and all
 popular distros install right off the box, with all hardware
 detected and properly configured.
 
 I bought two IBM ThinkPad T21 machines second-hand, 18 months ago.
 Both have a 20GB disk, and an 800MHz cpu, with 256MB ram. Got even
 a 6 month warranty, and Original Licenses for Windows, actually
 backed up by IBM service!
 
 On one, I use RedHat 9 and Windows 98, on the other Fedora 3 and
 Windows 2000.
 
 The Linuxes have always been Full installs, and on the windowses I
 have a lot of applications (Start/Programs is taller than the
 screen, even though I've grouped apps), Open Office, Microsoft
 Office, full Cygwin, graphics programs, programming languages, etc.
 Not having windows on NTFS file system gives me full read/write
 access from Linux.
 
 Not downloading music or movies lets me have ample disk space. (I'm
 too old to listen to music while programming, and too much
 "TV-watching" only erodes your IQ.)  :-) Currently I use these
 laptops, often side by side, with one on windows and the other on
 linux.
 

 I'd also suggest making sure the Linux distro. you are thinking
 of using supports the board you buy, though (for example, up
 until recently SATA support for Linux was about 6 months behind
 Windows support, and you might want to Google for problems
 supporting the new system's Video Card - things like that).


 
 SATA and newest main boards simply are not needed for work use. 
 Especially with Linux!


 
 Well, I gotta chalk all this up to "it depends on what you do". If
 you spend a good part of the day waiting for C++ builds or DB queries
 to finish then I'd say that usually an upgrade to faster equipment
 pays off. 10 or 20 coffee breaks a day are nice, but kinda hard on
 the kidneys and wallet <g>


True! And if you don't have access to Sun Microsystems Grid 
(http://www.sun.com/service/utility/N1gridppu.html) no PC in the world 
can help you there. :-(


 And then of course there's the gaming aspect ;)


Oh, I wish I was younger...


 Generally I'd agree though - top of the line systems aren't worth the
 extra ching. And of course there's the argument that it's better to
 develop (or at least test) on more 'standard' hardware to get an
 accurate feel how an app. will perform on most systems.


True!


 That said, AMD64 chips and boards are often a price/performance value
 compared to comparable Intel stuff, plus you have an upgrade path.


I love computers, and whether I need it or not, I probably will buy one, 
with bad luck already this year. ;-)



 Mar 29 2005



prev sibling next sibling parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Matthew wrote:


 Maybe I'm missing something here, but what does Apple's support has
 to with Linux ? If anything, it should have more to do with Mac OS
 X, yes ? (although I am running both Mac OS X and Linux on my own
 Apple machines)


 
 Oh, I was just going to use getting an Apple into springboarding me
 into doing D primarily on Linux. ;) Since they've demotivated me re
 buying one, it's put a crimp on that side of things.


Doing Linux on Apple computers is a lot "harder" than with PCs,
since, well, Microsoft don't make the hardware too ? (yet ;-) )
It can be done, but you regularly lose things like hardware drivers
(fan control, AirPort, OpenGL, audio, etc, etc) that Apple provides...

There is also the general problem of people confusing "Linux" with
"Linux x86", which means that a lot of closed software won't work
(and you usually have to recompile the open third party stuff too)
Usually the supported PPC platform is Mac OS X, not any kind of Linux.


But, it is worth the effort (I think) - and works great in the end...
(Assuming you need some kind of Linux interaction, otherwise just using
Mac OS X and its DeveloperTools and Darwin BSD-system should be plenty!)

Some nice Linux distributions that support PowerPC and Macintosh are:
- Debian
- Gentoo 2005.0
- Yellow Dog Linux 4.0.1
- Ubuntu Linux "The Hoary Hedgehog"

It should also be noted that you can run both Linux and Darwin on your
regular X86 box too, even if the hardware support for OpenDarwin is a
bit limited still. But probably simpler than shifting X86 -> PPC ?

You can get a virtualization program, if you don't like dual-booting.
(unfortunately the options for doing this *on* Mac is now more or less
limited to emulation like Virtual PC for Mac, not "native" Xen-style)


And none of this should stop you from getting a Mac Mini, of course :-)

--anders



 Mar 28 2005



prev sibling  parent reply Georg Wrede <georg.wrede nospam.org>  writes:


Inspired by this, I tried a lamp-foot Mac at a Mac-only friend.

To my utter embarrasment, I couldn't find the command line?? Is it true 
that there really isn't one? (He obviously hadn't heard of such a thing, 
being a Mac-only person. :-( )

I mean, OS X is built on a real operating system, right? So, have they 
actually hidden/removed/nuked any means to use a Mac with an xterm 
window, ssh, or even telnet?

:-( Not that I'd be surprised, knowing their attitude problem.

Matthew wrote:

 "Anders F Björklund" <afb algonet.se> wrote in message
news:d24ofu$jv8$1 digitaldaemon.com...
 

Matthew wrote:



Alas - partly because of the stunning lack of Apple customer service - I've not
yet got to the point of using D on 
Linux. I'd be more than happy for people to make changes to the std/recls.d
file in the latest release 
(http://recls.org/downloads.html) and feed them back to me.


Maybe I'm missing something here, but what does Apple's support has to with
Linux ? If anything, it should have more 
to do with Mac OS X, yes ?
(although I am running both Mac OS X and Linux on my own Apple machines)


 
 
 Oh, I was just going to use getting an Apple into springboarding me into doing
D primarily on Linux. ;) Since they've 
 demotivated me re buying one, it's put a crimp on that side of things.
 
 

The latter is more my responsibility, since I've not (yet) got around to having
D on Linux. Is this easy to do? If 
so, I'll bite the bullet and get it done. Then it'll all be in Walter's court.


It's not very hard to install GDC on a regular Linux platform...
There's a specfile for RPM, an ebuild for Gentoo, and a Makefile ?
http://www.algonet.se/~afb/d/Makefile (downloads, compiles, installs)

Installing DMD, on a supported X86 Linux, is even easier to do :
http://www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial/InstallingDCompiler


 
 
 Thanks. I'll note this down. :-)
 
 
 





 Mar 29 2005



 next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org>  writes:


I played around with a couple of iBooks in DJs the other day, and could find a
terminal on one easily, but couldn't find 
it on another despite several minutes of searching.

So I guess it's there, but different models go to different lengths to pretend
to be a GUI

"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:424933EF.2050904 nospam.org...

 Inspired by this, I tried a lamp-foot Mac at a Mac-only friend.

 To my utter embarrasment, I couldn't find the command line?? Is it true that
there really isn't one? (He obviously 
 hadn't heard of such a thing, being a Mac-only person. :-( )

 I mean, OS X is built on a real operating system, right? So, have they
actually hidden/removed/nuked any means to use 
 a Mac with an xterm window, ssh, or even telnet?

 :-( Not that I'd be surprised, knowing their attitude problem.

 Matthew wrote:

 "Anders F Björklund" <afb algonet.se> wrote in message
news:d24ofu$jv8$1 digitaldaemon.com...


Matthew wrote:



Alas - partly because of the stunning lack of Apple customer service - I've not
yet got to the point of using D on 
Linux. I'd be more than happy for people to make changes to the std/recls.d
file in the latest release 
(http://recls.org/downloads.html) and feed them back to me.


Maybe I'm missing something here, but what does Apple's support has to with
Linux ? If anything, it should have more 
to do with Mac OS X, yes ?
(although I am running both Mac OS X and Linux on my own Apple machines)



 Oh, I was just going to use getting an Apple into springboarding me into doing
D primarily on Linux. ;) Since they've 
 demotivated me re buying one, it's put a crimp on that side of things.



The latter is more my responsibility, since I've not (yet) got around to having
D on Linux. Is this easy to do? If 
so, I'll bite the bullet and get it done. Then it'll all be in Walter's court.


It's not very hard to install GDC on a regular Linux platform...
There's a specfile for RPM, an ebuild for Gentoo, and a Makefile ?
http://www.algonet.se/~afb/d/Makefile (downloads, compiles, installs)

Installing DMD, on a supported X86 Linux, is even easier to do :
http://www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial/InstallingDCompiler



 Thanks. I'll note this down. :-)

 







 Mar 29 2005



  parent  Georg Wrede <georg.wrede nospam.org>  writes:


Matthew wrote:

 I played around with a couple of iBooks in DJs the other day, and
 could find a terminal on one easily, but couldn't find it on another
 despite several minutes of searching.
 
 So I guess it's there, but different models go to different lengths
 to pretend to be a GUI


:-) !!

That's one thing I hate with all of the GUI things. HP, Digital, Apple, 
Xerox, Microsoft.... I constantly feel that I have to search for things 
that should be where I look for them. Helping others with their machines 
is depressing. Windows Explorer might be found just about anywhere, 
except the obvious places. "I thought this be a nice place for it."

On today's computers, I hardly use the "os gui" at all. Just the "Start 
menu" and the guis in the apps themselves. All serious stuff I do with 
the command line. (Ever tried drag-and-drop with a shaky left button? 
Bob only knows where your files will end up. And boy if you don't notice 
while Undo is still usable.)


 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 news:424933EF.2050904 nospam.org...
 

 Inspired by this, I tried a lamp-foot Mac at a Mac-only friend.
 
 To my utter embarrasment, I couldn't find the command line?? Is it
 true that there really isn't one? (He obviously hadn't heard of
 such a thing, being a Mac-only person. :-( )
 
 I mean, OS X is built on a real operating system, right? So, have
 they actually hidden/removed/nuked any means to use a Mac with an
 xterm window, ssh, or even telnet?
 
 :-( Not that I'd be surprised, knowing their attitude problem.
 
 Matthew wrote:
 

 "Anders F Björklund" <afb algonet.se> wrote in message
 news:d24ofu$jv8$1 digitaldaemon.com...
 
 

 Matthew wrote:
 
 
 

 Alas - partly because of the stunning lack of Apple customer
 service - I've not yet got to the point of using D on Linux.
 I'd be more than happy for people to make changes to the
 std/recls.d file in the latest release 
 (http://recls.org/downloads.html) and feed them back to me.


 
 Maybe I'm missing something here, but what does Apple's support
 has to with Linux ? If anything, it should have more to do with
 Mac OS X, yes ? (although I am running both Mac OS X and Linux
 on my own Apple machines)


 
 
 Oh, I was just going to use getting an Apple into springboarding
 me into doing D primarily on Linux. ;) Since they've demotivated
 me re buying one, it's put a crimp on that side of things.
 
 
 

 The latter is more my responsibility, since I've not (yet)
 got around to having D on Linux. Is this easy to do? If so,
 I'll bite the bullet and get it done. Then it'll all be in
 Walter's court.


 
 It's not very hard to install GDC on a regular Linux
 platform... There's a specfile for RPM, an ebuild for Gentoo,
 and a Makefile ? http://www.algonet.se/~afb/d/Makefile
 (downloads, compiles, installs)
 
 Installing DMD, on a supported X86 Linux, is even easier to do
 : 
 http://www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial/InstallingDCompiler
 


 
 
 Thanks. I'll note this down. :-)
 
 




 
 





 Mar 29 2005



prev sibling  parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Georg Wrede wrote:


 Inspired by this, I tried a lamp-foot Mac at a Mac-only friend.

 To my utter embarrasment, I couldn't find the command line?? Is it true 
 that there really isn't one? (He obviously hadn't heard of such a thing, 
 being a Mac-only person. :-( )


It's hidden under /Applications/Utilities/Terminal.app... :-)
(shown as Program > Verktygsprogram > Terminal here, Swedish)

You can also enable SSH access from remote, under Sharing.

--anders



 Mar 29 2005



  parent reply Georg Wrede <georg.wrede nospam.org>  writes:


Anders F Björklund wrote:

 Georg Wrede wrote:
 

 Inspired by this, I tried a lamp-foot Mac at a Mac-only friend.

 To my utter embarrasment, I couldn't find the command line?? Is it 
 true that there really isn't one? (He obviously hadn't heard of such a 
 thing, being a Mac-only person. :-( )


 
 
 It's hidden under /Applications/Utilities/Terminal.app... :-)
 (shown as Program > Verktygsprogram > Terminal here, Swedish)
 
 You can also enable SSH access from remote, under Sharing.


Gee, thanks! I'll try that the next time.

Funny, I don't even remember what language his was. Guess I'm just too 
used to all three. (Finnish, Swedish, English)

Incidentally, your answer came at the last momemt: I was just going to 
dig up my old tomahawk (Native American war axe, with "Apple" written in 
permanent felt tip on it) that I've saved for this kind of things. But 
now I can again think that even Apple may now be an alternative. :-)

<polite fit>

The UI does look even nicer than in magazine pictures. And the screen 
with the transparent frame was kind of cool. Not to mention the small, 
cool globular transparent loudspeakers, which had a better sound than 
designed-to-death gadgets usually do.

The whole thing really looked like a piece of value furniture. Fit to be 
kept on a mahogany desk with a crimson genuine leather writing area, 
decorated with 24k gold leaf. Like what you see at rich peoples' next to 
the top-of-the-line SLR camera, cigar cutter, hand engraved shotgun, and 
the sword that Really Has Been wielded by Karl the [many sticks, some of 
them crossed]. None of which the rich guy can properly operate.

</polite fit>



 Mar 29 2005



  parent  =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se>  writes:


Georg Wrede wrote:


 The UI does look even nicer than in magazine pictures. And the screen 
 with the transparent frame was kind of cool. Not to mention the small, 
 cool globular transparent loudspeakers, which had a better sound than 
 designed-to-death gadgets usually do.


Posting this on one, and can only agree. I like my iLamp a lot.
http://www.lowendmac.com/imacs/imac17.html (still booting OS 9)

Although mine is broken since the FireWire ports, which happens
to be welded right on the motherboard, both fried a while ago...
And it's not like I can just replace it myself, like on the PC ?
(I can send the whole computer in, and pay $500 to get a new MB)

Price you pay for designer stuff, I guess... It's not like you
can actually *wash* the clothes, without going to the chemists ;-)

--anders



 Mar 29 2005



prev sibling  parent reply "Matthew" <admin.hat stlsoft.dot.org>  writes:


"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d20vlk$2koi$1 digitaldaemon.com...

 On a related note, how does one recompile phobos on Linux? It fails in the
current recls.


recls builds and executes for me without a whimper on Linux. As I said in the
post (and as is mentioned on the recls 
website), one needs the latest STLSoft 1.8.3 beta.

Can you specify what the build problem(s) are?



 Mar 25 2005



 next sibling parent reply =?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?=  writes:


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew wrote:
| "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d20vlk$2koi$1 digitaldaemon.com...
|
|>On a related note, how does one recompile phobos on Linux? It fails in
the current recls.
|
|
| recls builds and executes for me without a whimper on Linux. As I said
in the post (and as is mentioned on the recls
| website), one needs the latest STLSoft 1.8.3 beta.
|
| Can you specify what the build problem(s) are?

See atached diff for G++-3.4.3's problems with dmd-0.119's phobos.
I don't have vanilla gdc sources at hand but I remember lot's of
problems just to create the object files (etc/c/recls) using g++-3.4.3
but no major problems with g++-3.4.2.

Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFCRJtr3w+/yD4P9tIRAlL9AKCWszM+b3i5eYUWTdp+kZOvqnz1FQCfexpA
2TPc2IRrxXnvgO+oG+8X7nw=
=l4b/
-----END PGP SIGNATURE-----



 Mar 25 2005



  parent  "Matthew" <admin.hat stlsoft.dot.org>  writes:


Wow! It'd forgotten how old that stuff was. This's all been taken care of many
months ago.

I can't do anything about what's in Phobos, so all I can suggest is that people
use  the latest distro from 
http://recls.org/downloads.html unless and until Walter upgrades Phobos.

"Thomas Kühne" <thomas-dloop kuehne.THISISSPAM.cn> wrote in message
news:d225ui$vcu$1 digitaldaemon.com...

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Matthew wrote:
 | "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:d20vlk$2koi$1 digitaldaemon.com...
 |
 |>On a related note, how does one recompile phobos on Linux? It fails in
 the current recls.
 |
 |
 | recls builds and executes for me without a whimper on Linux. As I said
 in the post (and as is mentioned on the recls
 | website), one needs the latest STLSoft 1.8.3 beta.
 |
 | Can you specify what the build problem(s) are?

 See atached diff for G++-3.4.3's problems with dmd-0.119's phobos.
 I don't have vanilla gdc sources at hand but I remember lot's of
 problems just to create the object files (etc/c/recls) using g++-3.4.3
 but no major problems with g++-3.4.2.

 Thomas
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.0 (MingW32)

 iD8DBQFCRJtr3w+/yD4P9tIRAlL9AKCWszM+b3i5eYUWTdp+kZOvqnz1FQCfexpA
 2TPc2IRrxXnvgO+oG+8X7nw=
 =l4b/
 -----END PGP SIGNATURE-----



--------------------------------------------------------------------------------



 --- dmd.119/dmd/src/phobos/etc/c/stlsoft/stlsoft_null.h.org 2005-03-26
00:01:46.561083840 +0100
 +++ dmd.119/dmd/src/phobos/etc/c/stlsoft/stlsoft_null.h 2005-03-26
00:02:03.834457888 +0100
    -188,10 +188,11   
     }

 // Not to be implemented
 +NULL_v(NULL_v const &);
 +
 private:
     void operator &() const;

 -    NULL_v(NULL_v const &);
     NULL_v const &operator =(NULL_v const &);
 };

 





 Mar 25 2005



prev sibling  parent reply Ben Hinkle <Ben_member pathlink.com>  writes:


In article <d21unh$p3b$1 digitaldaemon.com>, Matthew says...

"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d20vlk$2koi$1 digitaldaemon.com...

 On a related note, how does one recompile phobos on Linux? It fails in the
current recls.


recls builds and executes for me without a whimper on Linux. As I said in the
post (and as is mentioned on the recls 
website), one needs the latest STLSoft 1.8.3 beta.

Can you specify what the build problem(s) are?


using dmd-119:
make -C ./etc/c/recls -f linux.mak
make[1]: Entering directory `/home/bhinkle/dmd/src/phobos/etc/c/recls'
g++ -Wall  -O4 -mcpu=i686  -DNDEBUG -DUNIX -D_M_IX86 -c -I. -I../stlsoft
-orecls_fileinfo_unix.o recls_fileinfo_unix.cpp
./stlsoft/stlsoft_null.h: In function `const recls::recls_fileinfo_t*
recls::FileInfo_Allocate(size_t)':
./stlsoft/stlsoft_null.h:194: error: `stlsoft::NULL_v::NULL_v(const
stlsoft::NULL_v&)' is private
recls_fileinfo_unix.cpp:237: error: within this context
./stlsoft/stlsoft_null.h: In function `void recls::FileInfo_Release(const
recls::recls_fileinfo_t*)':
./stlsoft/stlsoft_null.h:194: error: `stlsoft::NULL_v::NULL_v(const
stlsoft::NULL_v&)' is private
recls_fileinfo_unix.cpp:256: error: within this context
./stlsoft/stlsoft_null.h: In function `recls::recls_rc_t
recls::FileInfo_Copy(const recls::recls_fileinfo_t*, const
recls::recls_fileinfo_t**)':
./stlsoft/stlsoft_null.h:194: error: `stlsoft::NULL_v::NULL_v(const
stlsoft::NULL_v&)' is private
recls_fileinfo_unix.cpp:277: error: within this context
make[1]: *** [recls_fileinfo_unix.o] Error 1

g++ -v gives:
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)



 Mar 25 2005



 next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org>  writes:


As I mentioned in the other post, this is stuff that was sorted nearly a year
ago.

It's a shame, but I guess the recls in Phobos is damn near unusable. :-(

"Ben Hinkle" <Ben_member pathlink.com> wrote in message
news:d228ia$11pa$1 digitaldaemon.com...

 In article <d21unh$p3b$1 digitaldaemon.com>, Matthew says...

"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d20vlk$2koi$1 digitaldaemon.com...

 On a related note, how does one recompile phobos on Linux? It fails in the
current recls.


recls builds and executes for me without a whimper on Linux. As I said in the
post (and as is mentioned on the recls
website), one needs the latest STLSoft 1.8.3 beta.

Can you specify what the build problem(s) are?


 using dmd-119:
 make -C ./etc/c/recls -f linux.mak
 make[1]: Entering directory `/home/bhinkle/dmd/src/phobos/etc/c/recls'
 g++ -Wall  -O4 -mcpu=i686  -DNDEBUG -DUNIX -D_M_IX86 -c -I. -I../stlsoft
 -orecls_fileinfo_unix.o recls_fileinfo_unix.cpp
 ./stlsoft/stlsoft_null.h: In function `const recls::recls_fileinfo_t*
 recls::FileInfo_Allocate(size_t)':
 ./stlsoft/stlsoft_null.h:194: error: `stlsoft::NULL_v::NULL_v(const
 stlsoft::NULL_v&)' is private
 recls_fileinfo_unix.cpp:237: error: within this context
 ./stlsoft/stlsoft_null.h: In function `void recls::FileInfo_Release(const
 recls::recls_fileinfo_t*)':
 ./stlsoft/stlsoft_null.h:194: error: `stlsoft::NULL_v::NULL_v(const
 stlsoft::NULL_v&)' is private
 recls_fileinfo_unix.cpp:256: error: within this context
 ./stlsoft/stlsoft_null.h: In function `recls::recls_rc_t
 recls::FileInfo_Copy(const recls::recls_fileinfo_t*, const
 recls::recls_fileinfo_t**)':
 ./stlsoft/stlsoft_null.h:194: error: `stlsoft::NULL_v::NULL_v(const
 stlsoft::NULL_v&)' is private
 recls_fileinfo_unix.cpp:277: error: within this context
 make[1]: *** [recls_fileinfo_unix.o] Error 1

 g++ -v gives:
 Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
 Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
 --infodir=/usr/share/info --enable-shared --enable-threads=posix
 --disable-checking --with-system-zlib --enable-__cxa_atexit
 --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
 Thread model: posix
 gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)

 





 Mar 25 2005



  parent reply J C Calvarese <jcc7 cox.net>  writes:


Matthew wrote:

 As I mentioned in the other post, this is stuff that was sorted nearly a year
ago.
 
 It's a shame, but I guess the recls in Phobos is damn near unusable. :-(


No, it's not unusable -- just often confusing. Such a shame that Walter 
won't update it.

I was looking at the docs included with Phobos the other day and found a 
function that I need to use was in recls. Unfortunately, the ancient 
version in Phobos was missing that particular function. And I wasn't in 
the mood to compile your updated version myself.

I've written some stuff in D using recls, but not as much as I'd like. :(

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/



 Mar 26 2005



  parent  "Matthew" <admin.hat stlsoft.dot.org>  writes:


"J C Calvarese" <jcc7 cox.net> wrote in message
news:d25km9$1fji$1 digitaldaemon.com...

 Matthew wrote:

 As I mentioned in the other post, this is stuff that was sorted nearly a year
ago.

 It's a shame, but I guess the recls in Phobos is damn near unusable. :-(


 No, it's not unusable -- just often confusing. Such a shame that Walter won't
update it.

 I was looking at the docs included with Phobos the other day and found a
function that I need to use was in recls. 
 Unfortunately, the ancient version in Phobos was missing that particular
function. And I wasn't in the mood to compile 
 your updated version myself.

 I've written some stuff in D using recls, but not as much as I'd like. :(


Yeah, this is one reason why I've written so much more Ruby code than D code
over the last few months. Using recls/D, 
even for me, is more painful than it need be, and so I tend to go with what's
ready and running _right now_, i.e. Ruby.

(FYI: recls 1.6.x also comes with recls/Python, for those who've not yet seen
the shining red light that is Ruby <g>)



 Mar 27 2005



prev sibling  parent  Dave <Dave_member pathlink.com>  writes:


With the version of recls that shipped w/ DMD v0.119, and compiling with GCC
ge. v3.3.x, replace the following in etc/c/stlsoft/stlsoft_null.h:

private: // line 191
void operator &() const;

NULL_v(NULL_v const &);
NULL_v const &operator =(NULL_v const &);

with:

private: // line 191
void operator &() const;
public:
NULL_v(NULL_v const &);
private:
NULL_v const &operator =(NULL_v const &);

It could be a compiler issue - I didn't look into it that far. I think I sent
something into stlsoft on this issue last year.

- Dave

In article <d228ia$11pa$1 digitaldaemon.com>, Ben Hinkle says...

In article <d21unh$p3b$1 digitaldaemon.com>, Matthew says...

"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:d20vlk$2koi$1 digitaldaemon.com...

 On a related note, how does one recompile phobos on Linux? It fails in the
current recls.


recls builds and executes for me without a whimper on Linux. As I said in the
post (and as is mentioned on the recls 
website), one needs the latest STLSoft 1.8.3 beta.

Can you specify what the build problem(s) are?


using dmd-119:
make -C ./etc/c/recls -f linux.mak
make[1]: Entering directory `/home/bhinkle/dmd/src/phobos/etc/c/recls'
g++ -Wall  -O4 -mcpu=i686  -DNDEBUG -DUNIX -D_M_IX86 -c -I. -I../stlsoft
-orecls_fileinfo_unix.o recls_fileinfo_unix.cpp
./stlsoft/stlsoft_null.h: In function `const recls::recls_fileinfo_t*
recls::FileInfo_Allocate(size_t)':
./stlsoft/stlsoft_null.h:194: error: `stlsoft::NULL_v::NULL_v(const
stlsoft::NULL_v&)' is private
recls_fileinfo_unix.cpp:237: error: within this context
./stlsoft/stlsoft_null.h: In function `void recls::FileInfo_Release(const
recls::recls_fileinfo_t*)':
./stlsoft/stlsoft_null.h:194: error: `stlsoft::NULL_v::NULL_v(const
stlsoft::NULL_v&)' is private
recls_fileinfo_unix.cpp:256: error: within this context
./stlsoft/stlsoft_null.h: In function `recls::recls_rc_t
recls::FileInfo_Copy(const recls::recls_fileinfo_t*, const
recls::recls_fileinfo_t**)':
./stlsoft/stlsoft_null.h:194: error: `stlsoft::NULL_v::NULL_v(const
stlsoft::NULL_v&)' is private
recls_fileinfo_unix.cpp:277: error: within this context
make[1]: *** [recls_fileinfo_unix.o] Error 1

g++ -v gives:
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)





 Mar 25 2005



prev sibling  parent  "Matthew" <admin.hat stlsoft.dot.org>  writes:


As "the author", I can say that I agreed with Walter some months ago that if I
trimmed it down, he'd put it in. This I 
have done so, in the form of recls 1.6.1 (http://recls.org/downloads.html), but
I've not heard anything about it from 
Walter as yet. I assume he's busy on other things.

As I mentioned in the announcement post, Walter had been reluctant to put it in
since version 1.2, as it'd grown in size 
(both source and object), with the accumulation of features, particularly the
FTP searching (Windows-only). Hence the 
trimming that's been done for 1.6.1.

As for when he'll do it, I can't say, but I'm also one who's keen to see it
happen, as it'd simplify my projects. ;$


"Jamboree" <jam bor.ee> wrote in message news:d1mco4$2q8t$1 digitaldaemon.com...

 





 Mar 25 2005