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.

> 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

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.

>>> 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

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.

>> 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