www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Stewart's Utility Library 0.01 release

reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Stewart's Utility Library is a small collection of utility modules.

http://smjg.port5.com/pr/d/

It is at a pre-alpha stage of development.  Currently it consists of:

bitarray
~~~~~~~~
Bit pointer and array implementation supporting slices that don't have 
to begin on byte boundaries.  A modification of code posted around here 
to try and fix D's own bit arrays.

Implementation logic is written for LE and BE platforms, but only the LE 
is as yet tested.  See the readme file for more on this issue.

datetime
~~~~~~~~
Object-oriented date and time types.  A first attempt at implementing 
this idea:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/6085

Getting the system time and time zone, and generating an OS-formatted 
string, are currently implemented only for Windows.  Any volunteers?

hashmap
~~~~~~~
Associative container template that doesn't rely on an ordering of the 
key type.  Previously released as a standalone module.


Among my next plans is to implement this idea

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/6089

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jul 04 2005
parent reply "Uwe Salomon" <post uwesalomon.de> writes:
 Among my next plans is to implement this idea

 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/6089


To answer to this post: Yes, in some weeks i want to implement a  
TextStream class (similar to QTextStream from Qt) that works on an  
IODevice. I have already implemented the IODevice, the File (a special  
IODevice) and a DataStream. Well, i guess you do not want to adhere to my  
coding conventions and write the TextStream for me / with me. If i am  
wrong with this assumption, !pleeeaase! let me know. This would save both  
of us some time, as i already wrote the platform-dependant code for  
opening/reading binary file contents. You could concentrate on UTF  
handling and that stuff.

Ciao
uwe
Jul 04 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Uwe Salomon wrote:

 Among my next plans is to implement this idea

 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/6089


 
 To answer to this post: Yes, in some weeks i want to implement a 
 TextStream class (similar to QTextStream from Qt) that works on an  
 IODevice. I have already implemented the IODevice, the File (a special  
 IODevice) and a DataStream. Well, i guess you do not want to adhere to 
 my coding conventions and write the TextStream for me / with me. If i 
 am wrong with this assumption, !pleeeaase! let me know. This would save 
 both of us some time, as i already wrote the platform-dependant code 
 for opening/reading binary file contents. You could concentrate on UTF 
 handling and that stuff.


If you're in a position to share your coding conventions and the work 
you've done so far, then I'll take a look at it.  Maybe we can collaborate.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jul 05 2005
parent reply "Uwe Salomon" <post uwesalomon.de> writes:
 http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/6089


  To answer to this post: Yes, in some weeks i want to implement a  
 TextStream class (similar to QTextStream from Qt) that works on an   
 IODevice. I have already implemented the IODevice, the File (a special   
 IODevice) and a DataStream. Well, i guess you do not want to adhere to  
 my coding conventions and write the TextStream for me / with me. If i  
 am wrong with this assumption, !pleeeaase! let me know. This would save  
 both of us some time, as i already wrote the platform-dependant code  
 for opening/reading binary file contents. You could concentrate on UTF  
 handling and that stuff.


 If you're in a position to share your coding conventions and the work  
 you've done so far, then I'll take a look at it.  Maybe we can  
 collaborate.


Well, coding "conventions" are:
   - Cleanly formatted code.
   - *Very* well optimized for speed.
   - Names, functions, constants, behaviour, everything from Qt
      possible, but adapted to D specialities.
   - Perfectly documented from the beginning.
      Using NaturalDocs for API docs, and a lot of in-code
      explanations.

The work i've done so far is already open source (GPL). To get an  
impression, look at:

http://www.uwesalomon.de/code/indigo/index.html

If you are interested, let me know (perhaps by private email).

Ciao
uwe
Jul 05 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Uwe Salomon wrote:
<snip>

 Well, coding "conventions" are:
   - Cleanly formatted code.
   - *Very* well optimized for speed.
   - Names, functions, constants, behaviour, everything from Qt
      possible, but adapted to D specialities.
   - Perfectly documented from the beginning.
      Using NaturalDocs for API docs, and a lot of in-code
      explanations.


Sensible conventions on the whole.  But what do you mean by point 3 
exactly?  And to me your project falls short of "perfectly" documented 
on these counts:
- documentation doesn't seem to be available in a downloadable form
- no clear documentation of the class hierarchy
- a few spelling errors, including several instances of "independant" 
instead of "independent"
- documentation of setFileName: "Changes the name of the file to name. 
It must not be opened."  It appears that you meant: "It must not be 
already open."


 The work i've done so far is already open source (GPL).


The package lacks a copy of the GPL text, so AIUI it's not a legitimate 
GPL distribution.

However, releasing a library as GPL strikes me as the Wrong Thing - 
people are likely to want to write applications that use a library and 
then release them under various licences.  Even use libraries that 
aren't GPL-compatible as well as yours.  Can I persuade you to release 
it under some other licence?  Maybe LGPL, or some simple licence similar 
to that of my libraries?


 To get an impression, look at:
 
 http://www.uwesalomon.de/code/indigo/index.html
 
 If you are interested, let me know (perhaps by private email).


I will investigate it and get back to you in due course.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- a->--- UB P+ L E W++  N+++ o K- w++  O? M V? PS- PE- Y? 
PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Jul 07 2005
parent "Uwe Salomon" <post uwesalomon.de> writes:
 Well, coding "conventions" are:
   - Cleanly formatted code.
   - *Very* well optimized for speed.
   - Names, functions, constants, behaviour, everything from Qt
      possible, but adapted to D specialities.
   - Perfectly documented from the beginning.
      Using NaturalDocs for API docs, and a lot of in-code
      explanations.


 Sensible conventions on the whole.  But what do you mean by point 3  
 exactly?


Well, the library should provide the "look&feel" of Qt. Most of the  
classes have a direct counterpart in the Qt 4.0 library, like Vector for  
example. Its functions have the same name, and they mostly do exactly the  
same. Thus it should be easy for a programmer new to D, but accustomed to  
Qt, to write programs using Vector. But this is not always possible, as D  
is different from C++. We don't need something like QMetaObject, as D  
already provides RTTI. Signals&slots are implemented using string  
comparisons in Qt, that would make no sense for D, as it has very powerful  
templates, and we have to take care about the GC specialties. That's why  
there is no QObject, and nothing like a "public slots:" section  
implemented, but instead the class CmdTarget and the struct Signal.

In a sum: i try to “copy” ideas, implementation and style from Qt (it is  
very well designed, in my opinion), but if that is not possible or not  
feasible, i try to invent something more targeted for D.


 And to me your project falls short of "perfectly" documented on these  
 counts:
 - documentation doesn't seem to be available in a downloadable form


That is a good idea.


 - no clear documentation of the class hierarchy


NaturalDocs does not support that yet, and Doxygen simply produces waste  
most of the time. Anyways, there currently is no class hierarchy. Since  
the last release there is a small “class list“ ─ File : IODevice :  
CmdTarget. But you are right, in the future i should make something up  
that provides an overview.


 - a few spelling errors, including several instances of "independant"  
 instead of "independent"
 - documentation of setFileName: "Changes the name of the file to name.  
 It must not be opened."  It appears that you meant: "It must not be  
 already open."


As you may already have guessed, i am not a native speaker. I try very  
hard to write good and correct english, but my german is better :). I have  
corrected these mistakes, and if you spot more during investigation, drop  
me a note. I am always thankful for corrections.


 The work i've done so far is already open source (GPL).


 The package lacks a copy of the GPL text, so AIUI it's not a legitimate  
 GPL distribution.

 However, releasing a library as GPL strikes me as the Wrong Thing -  
 people are likely to want to write applications that use a library and  
 then release them under various licences.  Even use libraries that  
 aren't GPL-compatible as well as yours.  Can I persuade you to release  
 it under some other licence?  Maybe LGPL, or some simple licence similar  
 to that of my libraries?


I will change the license to the LGPL.


 I will investigate it and get back to you in due course.

 Stewart.


Thanks a lot!
uwe
Jul 07 2005