• Matthew (16/16) May 23 2005 ========================================================================...
• Ben Hinkle (8/24) May 23 2005 Two questions:
• Matthew (37/44) May 23 2005 I hope so, but it's out of my control.

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

================================================================================
23rd May 2005 : recls 1.6.1 => 1.6.2
--------------------------------------------------------------------------------

Changes:

 - Header files in the old mappings/Cpp directory now redirect to
   <recls/cpp/search.hpp>, <recls/cpp/entry.hpp>, etc.

 - Java mapping now uses the STLSoft sub-project PlatformSTL

 - Java, Python and Ruby mappings now use new STLSoft C-compatible 
components,
   i.e. <winstl/time_conversion_functions.h>

 - The implementation is significantly refactored, to reduce source 
and binary
   sizes, as described in the July instalment of the "Positive 
Integration"
   column in C/C++ Users Journal (http://www.cuj.com)

================================================================================

"Ben Hinkle" <bhinkle mathworks.com> writes:

Two questions:
1) Is it going into phobos?
2) I browsed the std.recls documentation and noticed the Entry class is 
generic enough to be moved to std.file or something. Any plans for that? 
Also the top-level functions (eg "getPathNameSeparator") in std.recls don't 
look to be recls-specific.

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d6s1t6$kg0$1 digitaldaemon.com...
 ================================================================================
 23rd May 2005 : recls 1.6.1 => 1.6.2
 --------------------------------------------------------------------------------

 Changes:

 - Header files in the old mappings/Cpp directory now redirect to
   <recls/cpp/search.hpp>, <recls/cpp/entry.hpp>, etc.

 - Java mapping now uses the STLSoft sub-project PlatformSTL

 - Java, Python and Ruby mappings now use new STLSoft C-compatible 
 components,
   i.e. <winstl/time_conversion_functions.h>

 - The implementation is significantly refactored, to reduce source and 
 binary
   sizes, as described in the July instalment of the "Positive Integration"
   column in C/C++ Users Journal (http://www.cuj.com)

 ================================================================================

 

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

"Ben Hinkle" <bhinkle mathworks.com> wrote in message 
news:d6tcca$1us5$1 digitaldaemon.com...
 Two questions:
 1) Is it going into phobos?

I hope so, but it's out of my control.

The agreement Walter and I had a long time ago was that recls 1.6.1 
would go into Phobos. But Walter seems determined to wait for the 
'slim' recls2, which I've maintained is several months' away (I have 
other things that are higher priority!), despite the inconvenience 
and confusion for users. I think that that not only costs me some 
reputation, but it also makes D, or at least Phobos, to be 
unnecessarily lower in quality/usability.

(FYI: For the latest instalment of "Positive Integration" (CUJ: July 
and September) I've delved into the size issues, and found areas 
where trimming had a good effect, and where some further trimming 
may be done; I'll be doing some changes to STLSoft 1.8.4 to that end 
in the non-too-distant future. But the study revealed something of a 
surprise in that, for some 'tight' compilers (e.g. VC++ 7.1), the 
size of the recls libraries on an executable were ~20K. Although 
that's not as small as I would like, it's exactly huge either, when 
one considers all the functionality in recls, so I think the 
argument against its update into Phobos is weakened, limited only to 
source size. I expect that recls2 may have a smaller source size, 
but equal or greater binary size, given the fact that it's going to 
have a *lot* more functionality.)

But, it's not my decision, so if anyone's got a problem, please take 
it up with Walter.

 2) I browsed the std.recls documentation and noticed the Entry 
 class is generic enough to be moved to std.file or something. Any 
 plans for that?

No.

To be honest, if the distribution wasn't so FU'd, I had expected by 
now that people would use recls for many/most file-system needs, and 
that the usefulness of the Entry class - e.g. the directory parts 
collection, the directoryPath property, etc. - would be a major part 
of that. "Best laid plans" and all that ...

 Also the top-level functions (eg "getPathNameSeparator") in 
 std.recls don't look to be recls-specific.

They may have analogues elsewhere in Phobos. Remember that recls is 
a stand-alone library with mappings to many languages - Python, 
Ruby, C++, etc. - so it probably will have small areas of overlap 
with standard libraries from some of these languages.


Cheers

Matthew