www.digitalmars.com         C & C++   DMDScript  

c++ - recls 1.6.2 released - recls's been on a diet

reply "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)

================================================================================
May 23 2005
parent reply "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)

 ================================================================================
May 23 2005
parent reply "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
May 23 2005
parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
 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 ...


To be honest I hadn't looked at std.recls much before because I assumed it 
was focused on recursive ls. But now that I look at the doc there are parts 
that I would expect in std.file. It just seems odd to have basic file 
handling in std.recls. But then I'm used to Java where things are more 
organized...


 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


ok. I don't think there's much overlap actually with other parts of phobos. 
But there should be - the other parts are lacking basic features :-P
May 23 2005