www.digitalmars.com         C & C++   DMDScript  

D - SynSoft.D libraries 1.2 released

reply "Matthew Wilson" <matthew stlsoft.org> writes:
The SynSoft.D libraries 1.2 are now available from http://synsoft.org/d.html

There are several new small housekeeping modules, along with the
synsoft.win32.reg module that does registry stuff.

I've also changed the names of several methods in previous modules (I've
decided to standardise on ThisKindOfMethodName, rather than
this_kind_of_method_name()), but because of a linker weirdness  - it
wouldn't link when there were start() and Start() methods in the same
class - the deprecated functions with the old names have had to be removed.
Apologies if this causes problems. ;/

The registry library, like the other ones, is a header-only from a
source-perspective (i.e. the method bodies are stripped). This is not
because I'm being precious, just that I only want any attention you may give
on the module's API, not the implementation. Once this module is matured, it
may be going into Phobos, at which point, obviously, all source will be
available.

Note that the reg module only does enumeration for the moment. I've not yet
decided on the format for adding/deleting keys/values, and am happy to hear
some suggestions from anyone.

Alas, there are still no test programs, but I'm including my test program
for the registry module here. Version 1.3 of the libraries will have test
and sample progs, I promise.

(I've got to toddle off and do some other things - deadlines, deadlines -
but I'll be keeping an eye on the ng, and will try to respond to
feedback/questions/abuse. ;) )

Enjoy!



-- 
Matthew Wilson

STLSoft moderator and C++ monomaniac

(http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
                              (www.synesis.com.au/articles.html#columns)

"An Englishman by birth, a Yorkshireman by the grace of God" -- Michael
Gibbs

----------------------------------------------------------------------------
---
Sep 15 2003
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Matthew Wilson wrote:
 The SynSoft.D libraries 1.2 are now available from http://synsoft.org/d.html
 
 There are several new small housekeeping modules, along with the
 synsoft.win32.reg module that does registry stuff.
 
 I've also changed the names of several methods in previous modules (I've
 decided to standardise on ThisKindOfMethodName, rather than
 this_kind_of_method_name()), but because of a linker weirdness  - it
 wouldn't link when there were start() and Start() methods in the same
 class - the deprecated functions with the old names have had to be removed.
 Apologies if this causes problems. ;/
 
 The registry library, like the other ones, is a header-only from a
 source-perspective (i.e. the method bodies are stripped). This is not
 because I'm being precious, just that I only want any attention you may give
 on the module's API, not the implementation. Once this module is matured, it
 may be going into Phobos, at which point, obviously, all source will be
 available.

Are the stripped headers provided? I couldn't find any in synsoft.D.1.2.zip or synsoft.D.1.2-libs.zip. When I tried to compile the program the compiler says: Error: Error reading file 'synsoft\win32\perf.d'
 
 Note that the reg module only does enumeration for the moment. I've not yet
 decided on the format for adding/deleting keys/values, and am happy to hear
 some suggestions from anyone.
 
 Alas, there are still no test programs, but I'm including my test program
 for the registry module here. Version 1.3 of the libraries will have test
 and sample progs, I promise.
 
 (I've got to toddle off and do some other things - deadlines, deadlines -
 but I'll be keeping an eye on the ng, and will try to respond to
 feedback/questions/abuse. ;) )
 
 Enjoy!

Thanks. It sounds great. The .exe's you "released" earlier worked fine. Justin
Sep 15 2003
next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
 The registry library, like the other ones, is a header-only from a
 source-perspective (i.e. the method bodies are stripped). This is not
 because I'm being precious, just that I only want any attention you may


 on the module's API, not the implementation. Once this module is


 may be going into Phobos, at which point, obviously, all source will be
 available.

Are the stripped headers provided? I couldn't find any in synsoft.D.1.2.zip or synsoft.D.1.2-libs.zip. When I tried to compile the program the compiler says: Error: Error reading file 'synsoft\win32\perf.d'

Gah! What a dodo!! I shall rectify right now. <blush>
 Note that the reg module only does enumeration for the moment. I've not


 decided on the format for adding/deleting keys/values, and am happy to


 some suggestions from anyone.

 Alas, there are still no test programs, but I'm including my test


 for the registry module here. Version 1.3 of the libraries will have


 and sample progs, I promise.

 (I've got to toddle off and do some other things - deadlines,


 but I'll be keeping an eye on the ng, and will try to respond to
 feedback/questions/abuse. ;) )

 Enjoy!

Thanks. It sounds great. The .exe's you "released" earlier worked fine.

He he
Sep 15 2003
prev sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Ok, they should be up there now. Try again ...


"J C Calvarese" <jcc7 cox.net> wrote in message
news:bk5g1c$gi0$1 digitaldaemon.com...
 Matthew Wilson wrote:
 The SynSoft.D libraries 1.2 are now available from


 There are several new small housekeeping modules, along with the
 synsoft.win32.reg module that does registry stuff.

 I've also changed the names of several methods in previous modules (I've
 decided to standardise on ThisKindOfMethodName, rather than
 this_kind_of_method_name()), but because of a linker weirdness  - it
 wouldn't link when there were start() and Start() methods in the same
 class - the deprecated functions with the old names have had to be


 Apologies if this causes problems. ;/

 The registry library, like the other ones, is a header-only from a
 source-perspective (i.e. the method bodies are stripped). This is not
 because I'm being precious, just that I only want any attention you may


 on the module's API, not the implementation. Once this module is


 may be going into Phobos, at which point, obviously, all source will be
 available.

Are the stripped headers provided? I couldn't find any in synsoft.D.1.2.zip or synsoft.D.1.2-libs.zip. When I tried to compile the program the compiler says: Error: Error reading file 'synsoft\win32\perf.d'
 Note that the reg module only does enumeration for the moment. I've not


 decided on the format for adding/deleting keys/values, and am happy to


 some suggestions from anyone.

 Alas, there are still no test programs, but I'm including my test


 for the registry module here. Version 1.3 of the libraries will have


 and sample progs, I promise.

 (I've got to toddle off and do some other things - deadlines,


 but I'll be keeping an eye on the ng, and will try to respond to
 feedback/questions/abuse. ;) )

 Enjoy!

Thanks. It sounds great. The .exe's you "released" earlier worked fine. Justin

Sep 15 2003
parent reply J C Calvarese <jcc7 cox.net> writes:
Matthew Wilson wrote:
 Ok, they should be up there now. Try again ...

Thanks. I found 'em. Your registry example works great now. Justin
Sep 15 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
So you've got it compiling and running ok? Cool. :)

"J C Calvarese" <jcc7 cox.net> wrote in message
news:bk5i3g$j4a$1 digitaldaemon.com...
 Matthew Wilson wrote:
 Ok, they should be up there now. Try again ...

Thanks. I found 'em. Your registry example works great now. Justin

Sep 15 2003
prev sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
There've been quite a few downloads, which is nice. :)

Please let me have all your feedback, good or bad.

Cheers

Matthew

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bk5cki$bsj$1 digitaldaemon.com...
 The SynSoft.D libraries 1.2 are now available from

 There are several new small housekeeping modules, along with the
 synsoft.win32.reg module that does registry stuff.

 I've also changed the names of several methods in previous modules (I've
 decided to standardise on ThisKindOfMethodName, rather than
 this_kind_of_method_name()), but because of a linker weirdness  - it
 wouldn't link when there were start() and Start() methods in the same
 class - the deprecated functions with the old names have had to be

 Apologies if this causes problems. ;/

 The registry library, like the other ones, is a header-only from a
 source-perspective (i.e. the method bodies are stripped). This is not
 because I'm being precious, just that I only want any attention you may

 on the module's API, not the implementation. Once this module is matured,

 may be going into Phobos, at which point, obviously, all source will be
 available.

 Note that the reg module only does enumeration for the moment. I've not

 decided on the format for adding/deleting keys/values, and am happy to

 some suggestions from anyone.

 Alas, there are still no test programs, but I'm including my test program
 for the registry module here. Version 1.3 of the libraries will have test
 and sample progs, I promise.

 (I've got to toddle off and do some other things - deadlines, deadlines -
 but I'll be keeping an eye on the ng, and will try to respond to
 feedback/questions/abuse. ;) )

 Enjoy!



 -- 
 Matthew Wilson

 STLSoft moderator and C++ monomaniac

 (http://www.stlsoft.org)
 Contributing editor, C/C++ Users Journal
                               (www.synesis.com.au/articles.html#columns)

 "An Englishman by birth, a Yorkshireman by the grace of God" -- Michael
 Gibbs

 --------------------------------------------------------------------------

 ---

Sep 17 2003
parent reply Ant <Ant_member pathlink.com> writes:
In article <bk949o$191s$1 digitaldaemon.com>, Matthew Wilson says...
There've been quite a few downloads, which is nice. :)

Please let me have all your feedback, good or bad.

Cheers

Matthew

I'm gonna look at GConf now. "GConf is a system for storing application preferences." (Took me what? 1 hour just to find that it exist) Do you think we could integrate GConf and your win32.reg in a common interface? Is that desirable? Is that possible at all? what's the license on your libs? I'll know more about GConf tomorrow. Ant (yeah, DUI for windows is boring is anybody out there interested in tweeking the makefiles and stuff like that to make it run? I should make a separate post with this)
Oct 01 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Ant

I'm afraid I know nothing about GConf, so can't comment.

As regards the registry library, as soon as Walter's finished some essential
compiler-waltering on the C++ compiler we'll be putting the registry API
into Phobos, and releasing the next version, so it'll be best if you can
hang fire a little while, and then it'll all be available in its majesty,
ready for digestion and potential regurgitation. :)

If the reg and GConf are in any way similar, I'd certainly like to
investigate a potential merge. I'd probaby prefer that there was a separate
common module, perhaps DConf, which could be implemented in terms of the reg
module on Win32, and the appropriate technology on Linux. Does that sound
sensible?

Cheers

Matthew

"Ant" <Ant_member pathlink.com> wrote in message
news:blg2mo$bdf$1 digitaldaemon.com...
 In article <bk949o$191s$1 digitaldaemon.com>, Matthew Wilson says...
There've been quite a few downloads, which is nice. :)

Please let me have all your feedback, good or bad.

Cheers

Matthew

I'm gonna look at GConf now. "GConf is a system for storing application preferences." (Took me what? 1 hour just to find that it exist) Do you think we could integrate GConf and your win32.reg in a common interface? Is that desirable? Is that possible at all? what's the license on your libs? I'll know more about GConf tomorrow. Ant (yeah, DUI for windows is boring is anybody out there interested in tweeking the makefiles and stuff like that to make it run? I should make a separate post with this)

Oct 01 2003
parent reply Ant <Ant_member pathlink.com> writes:
In article <blg6mv$gf0$1 digitaldaemon.com>, Matthew Wilson says...
Ant

I'm afraid I know nothing about GConf, so can't comment.

A tree struct that holds key/value pairs, (if it's not that ignore the rest of this) and more (a value can be a list) but the common interface would leave out the "uncommon" features (wouldn't you know...) There is a GConf client that looks a lot like the regedit.exe (for win9x I didn't check latelly)
As regards the registry library, as soon as Walter's finished some essential
compiler-waltering on the C++ compiler we'll be putting the registry API
into Phobos, and releasing the next version, so it'll be best if you can
hang fire a little while, and then it'll all be available in its majesty,
ready for digestion and potential regurgitation. :)

If the reg and GConf are in any way similar, I'd certainly like to
investigate a potential merge. I'd probaby prefer that there was a separate
common module, perhaps DConf, which could be implemented in terms of the reg
module on Win32, and the appropriate technology on Linux. Does that sound
sensible?

That's my idea. I'm coding and experimental version that I named DConf :) (copy/paste of course no fancy ,def files yet ;) As I see it now, the DUI package will have 3 libs libdui - core GTK,GDK,GLIB,Pango... libduigl - OpenGL libduiext - extensions (maybe divided into linux and windows versions(?)) The first extension is DConf (if it can migrate to phobos better). For now I'm implementing it through the GTK+ wrapper 'cause it familiar to me but it can be completly independent. As to be integrated into phobos I'm not sure as I'm doing just a wrapper. phobos would be dependent on a third party lib (BTW it LGPL). GConf is a gnome system, probably KDE will have it's own, I don't know about others... (Is it starting to get complicated?...) Let's wait and see. Ant
Oct 01 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:blg9ll$ktr$1 digitaldaemon.com...
 In article <blg6mv$gf0$1 digitaldaemon.com>, Matthew Wilson says...
Ant

I'm afraid I know nothing about GConf, so can't comment.

A tree struct that holds key/value pairs, (if it's not that ignore the rest of this) and more (a value can be a list) but the common interface would leave out the "uncommon" features (wouldn't you know...)

Sounds great. I'd be very happy if the D.win32.registry module could serve as an exemplar for such a thing, as well as being used in its Win32 implementation
 There is a GConf client that looks a lot like the regedit.exe
 (for win9x I didn't check latelly)

Where does it store its stuff? Is it system global, or can each process have its own reg file?
As regards the registry library, as soon as Walter's finished some


compiler-waltering on the C++ compiler we'll be putting the registry API
into Phobos, and releasing the next version, so it'll be best if you can
hang fire a little while, and then it'll all be available in its majesty,
ready for digestion and potential regurgitation. :)

If the reg and GConf are in any way similar, I'd certainly like to
investigate a potential merge. I'd probaby prefer that there was a


common module, perhaps DConf, which could be implemented in terms of the


module on Win32, and the appropriate technology on Linux. Does that sound
sensible?

That's my idea. I'm coding and experimental version that I named DConf :) (copy/paste of course no fancy ,def files yet ;)

Great minds, and all that !
Oct 02 2003
prev sibling parent reply Mike Hearn <mike theoretic.com> writes:
On Thu, 02 Oct 2003 02:31:52 +0000, Sir Ant scribed thus:
 I'm gonna look at GConf now.
 "GConf is a system for storing application preferences."
 (Took me what? 1 hour just to find that it exist)

I would not recommend making GConf and the registry the same API - they look the same but really are quite different. For instance: * GConf entries must (?) have schemas that give key documentation, possible values etc * GConf key types are different * GConf notifications are used a lot more than win32 registry notifications are * GConf is not guaranteed to be available on any given Linux system in the same way the registry is. * GConf is not meant to be used to store arbitrary data like the registry is, it's supposed to be for app preferences only (hence the powerful application defaults/lockdown settings)
 Do you think we could integrate GConf and your win32.reg in a 
 common interface? Is that desirable?

I would generally recommend that D bindings have the same name as what they bind to (so import gtk rather than import dui) and are direct mappings rather than abstractions. If somebody wants to use the registry and GConf in the same way they can always write their own simple abstraction class on top of them, IMHO, and use the versioning stuff in D to let it figure itself out.
Oct 02 2003
parent Ant <Ant_member pathlink.com> writes:
In article <pan.2003.10.02.10.23.14.738016 theoretic.com>, Mike Hearn says...
On Thu, 02 Oct 2003 02:31:52 +0000, Sir Ant scribed thus:
 I'm gonna look at GConf now.
 "GConf is a system for storing application preferences."
 (Took me what? 1 hour just to find that it exist)

I would not recommend making GConf and the registry the same API - they look the same but really are quite different. For instance: * GConf entries must (?) have schemas that give key documentation, possible values etc

??
* GConf key types are different

That's why we need an abstraction layer
* GConf notifications are used a lot more than win32 registry
notifications are

Don't see it as a problem
* GConf is not guaranteed to be available on any given Linux system in the
same way the registry is.

That's a real problems.
* GConf is not meant to be used to store arbitrary data like the registry
is, it's supposed to be for app preferences only (hence the powerful
application defaults/lockdown settings)
 
 Do you think we could integrate GConf and your win32.reg in a 
 common interface? Is that desirable?

I would generally recommend that D bindings have the same name as what they bind to (so import gtk rather than import dui) and are direct mappings rather than abstractions.

I'm even thinking of remove all the gtk tokens from DUI. (probably a mistake(?) I'll take another look at it)
If somebody wants to use the registry and GConf in the same way
they can always write their own simple abstraction class on top of them,
IMHO, and use the versioning stuff in D to let it figure itself out.

My first idea was to have that. except for the "their own" part. Integrating it into phobos might be too ambitious... Thanks for your insights! Ant
Oct 02 2003