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