Matthew wrote:

>>I still think it should be an external library,
>>but not primarily because of the code size...
> 
> [Do the following two paras make the point of why?
> If so, it's not clear. Can you rephrase/elucidate?]

I meant that: if recls should be in or out is a
different discussion, a few hundred KB of library
code that is usually dead-stripped if not actually
used is not really the reason for that discussion ?

And if size really matters, it should be accurately
measured and not just from hearsay on some newsgroup ;-)

>     - it'll be 2-3 months away. But because (AFAICT) that's still before 1.0 is released - at least I hope so! - I really don't see a problem with going with updating Phobos with recls 1.x right now. To not do so seems to arbitrarily single out recls for a fault (size) when the rest of Phobos is so embarassingly crappy (and I don't just mean the features that I wrote).

Yes, if etc.c.recls stays in the main download,
it should be updated to version 1.6.1 / 1.8.3...

Q: Why does the C/C++ library need to be in the
DMD download ? Wouldn't just std.recls be enough ?

And then link with the recls library, when linking.
That's how I usually use external libraries, with D.

>>Also, recls 1.6.1 requires the latest beta of STLSoft
>>(i.e. 1.8.3 beta 3 or above). The stable lib won't do.
> 
> What's your point here?

That recls seems to still be in beta, since requirements are ?
(but that whole paragraph somehow came out wrong, as I just
meant to say that a new STLSoft is required to compile recls...)

But, when I ran the new "1.8.3-beta5" unittest - it failed ?
I think I will take it to the c++.stlsoft newsgroup instead...
On the plus side, I did make some SRPMS for them - if you like.

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:d2sa6u$506$1@digitaldaemon.com...
> Matthew wrote:
>
>>>I still think it should be an external library,
>>>but not primarily because of the code size...
>>
>> [Do the following two paras make the point of why?
>> If so, it's not clear. Can you rephrase/elucidate?]
>
> I meant that: if recls should be in or out is a
> different discussion, a few hundred KB of library
> code that is usually dead-stripped if not actually
> used is not really the reason for that discussion ?

Gotcha

> And if size really matters, it should be accurately measured and not just from hearsay on some newsgroup ;-)

Indeed! (FYI: I've been doing that as part of the prep for the
July Positive Integration, and am coming to some very
interesting, and occasionally, startling results. Of which more,
later, when I'm fully armed with objective
information.)

>>     - it'll be 2-3 months away. But because (AFAICT) that's still before 1.0 is released - at least I hope so! - I
>> really don't see a problem with going with updating Phobos with recls 1.x right now. To not do so seems to
>> arbitrarily single out recls for a fault (size) when the rest of Phobos is so embarassingly crappy (and I don't just
>> mean the features that I wrote).
>
> Yes, if etc.c.recls stays in the main download,
> it should be updated to version 1.6.1 / 1.8.3...

No argument here.

> Q: Why does the C/C++ library need to be in the
> DMD download ? Wouldn't just std.recls be enough ?
>
> And then link with the recls library, when linking.
> That's how I usually use external libraries, with D.

I get you.

For: reduced download
Against: need to specify the library in link: trivial; need to
acquire or compile the recls libs.

I'm planning to start having binaries - .libs and also Python/Ruby .so/.dll - in the recls distro sometime in the non-too-distant future, which'd help. But my guess is that we'd want to have an RPM for the Linux, and I have _no idea_ how to do that. Would you help with that?

I still feel that, because I expect recls 2.0 to be *really* small
_and_ to be out before Phobos 1.0, recls 1.6 should
just go in as is. So what if it's a bit big now, given that
the issue is recognised and will be dealt with?

To be honest, the lack of recognition of the obviousness of the
preceeding statement is somewhat annoying. As with all
other contributors, I don't get paid for the time I spend working
on recls (recls/D), and playing to moving goalposts on
a module for a library so otherwise unready is kind of rich.

>>>Also, recls 1.6.1 requires the latest beta of STLSoft
>>>(i.e. 1.8.3 beta 3 or above). The stable lib won't do.
>>
>> What's your point here?
>
> That recls seems to still be in beta, since requirements are ?

Well, the whole of D is in beta (or is it alpha), so that's not a biggie surely?

Obviously STLSoft 1.8.3 is going to go live just as soon as I get
the time (and run the unittests - see below), and
there's very little likelihood of D 1.0 before then, methinks.

> (but that whole paragraph somehow came out wrong, as I just meant to say that a new STLSoft is required to compile recls...)
>
> But, when I ran the new "1.8.3-beta5" unittest - it failed ?

LOL! As I pushed the beta zip up last night I wondered whether any
of the latest changes might break the unit-tests
(that file's not changed since beta 1).

Oh well, another job for me. <g>

> I think I will take it to the c++.stlsoft newsgroup instead... On the plus side, I did make some SRPMS for them - if you like.

Cool. What's an _S_RPM ? :-)

Matthew wrote:

> Indeed! (FYI: I've been doing that as part of the prep for the
> July Positive Integration, and am coming to some very
> interesting, and occasionally, startling results. Of which more,
> later, when I'm fully armed with objective
> information.)

I forked out the $20, so I can now follow yours
and Walter's adventures on the DDJ website...

> But my guess is that we'd want to have an RPM
> for the Linux, and I have _no idea_
> how to do that. Would you help with that?

Consider it done. (which it, in fact, already is)

> Well, the whole of D is in beta (or is it alpha), so that's not a biggie surely?

Not at all, which was why it "came out wrong".

> Obviously STLSoft 1.8.3 is going to go live just as soon as I get
> the time (and run the unittests - see below), and
> there's very little likelihood of D 1.0 before then, methinks.

I would consider that fairly slim, unless Walter pulls a fast one.

But then we would just have to wait for "1.1" or "Service Pack 1" :-)

>>But, when I ran the new "1.8.3-beta5" unittest - it failed ?
> 
> LOL! As I pushed the beta zip up last night I wondered whether any
> of the latest changes might break the unit-tests
> (that file's not changed since beta 1).
> 
> Oh well, another job for me. <g>

Life on the bleeding edge... :-D

One can now use "rpmbuild -bi --with unittest stlsoft.spec" too

>>I think I will take it to the c++.stlsoft newsgroup instead...
>>On the plus side, I did make some SRPMS for them - if you like.
> 
> Cool. What's an _S_RPM ? :-)

"Source". Also known as .src.rpm, it's what builds the binary RPMS.
Specfiles posted on the other newsgroups, build with "rpmbuild -bb"

The old documentation for RPM is at http://www.rpm.org/max-rpm/

--anders