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 likes of C# and Java, we can't be cutting even remotely useful functionality 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)?

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:
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

-----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