Re: [Somelib] More changes

[John P. <jo...@ma...>]

Thomas Matelich wrote:

> Well, I finally finished my project files for Windows.  On our (probably
> my :) TODO list is documentation for using SOMELib on Windows.  There's
> a few tricks involved.
>
> You may notice the addition of some_string_map.h in SOMELib.  This was
> necessary due to the way windows does its dll's and the fact that
> std::map uses a static pointer called Nil for keeping track of things.
> This static would apparently get created both in the app and the dll,
> then when the map was modified by the dll in the initSOMELibInfo
> function it would have a different address than the exe.  Essentially it
> became fubar.  The solution was to write my own map, which was
> surprisingly easy.  Only a few real lines of code.  This change has been
> ifdef'ed for windows only and the API remains the same.
>

Hmm... is your map derived from std::map? I want to add functionality soon
that passes in a map to a method to search for multipule object matches.

>
> The Makefile situation needs some real work, too bad the Software
> Carpentry solution is still on the horizon.  I have as yet been unable
> to get the makefiles to work.  Also, the SOMELib, TestApp, and
> BasicTestLib Makefiles are missing.  If you could put those in
> Quintecent, I would appreciate it.
>

There is only one Makefile for the main distro and simple Makefiles for the
examples.  The reason for this is I don't use recursive makes but instead
include vars.mk and rules.mk from each directory.  This creates a faster
build.  Tell me what errors you are getting and I will fix them.

>
> So what else do we need to do before we can go 1.0?
> Docs, Docs, Docs:
> 1) Finish out API documentation

This is a must.  A person who has to jump through hoops to use our lib
won't.

>
> 2) I'd like to get a homepage put on the sourceforge site
>

Sounds good.  Perhaps someone would like to do this for us.

> 3) Doxygen also generates latex, man, and rtf formats, should I add
> those to CVS?

Hmm...no but add them to the tarballs.  We should automate their creation
with a make docs and make docs_install.

>
> 4) Tutorials
>

Yes also a must.

>
> Code:
> 1) Formatting.  I was going to run astyle on it.  Are you CoreLinux++
> guys using a pretty printer?

I used lint once and hated it but anything taht increases the readability
of the code I am all for.

>
> 2) Spell check.
>

Yes.  I am dislexic and often spell words very very wrong :)

> 3) Name analysis.  Are these the names we want for our classes

Yes.  I think we need to run this through beta testers and develop a
vocabulary (Perhaps the Info stuff should be called a catalog and
getCategory should be overloaded to handle both the simple catagory and
multipule category gets).  Also intern names we use for the maps should be
obfusicated so as to avoid name clashes with someone perhaps using
"category" as one of their categories.

>
> 4) Namespaces.  Pretty please :)
>

I just took a look at the white paper for Itini stuff from RedHat (C++
wrapper for GTK+).  They use namespaces and I think so should we.  Screw
all the non complient complilers use g++ :)

> 5) Error conditions.  Currently a few exceptions.  Do we like this?

The lib itself should never coredump (it does when it can't find a library
on linux).  Users objects we have no control over.

>
> 6) Write the searchForLib func.

Yes.

>
> 7) Do we want a getAllLibsInThisDirectory type function?
>

Yes but it should just be the same method that loads the librarys.  The
method should just check if the agument given is a file or a directory.  We
should also perhaps add the ability to load libraries defined in a an
enviornment variable and a text file.

>
> Examples:
> 1)  Like what you did there Quinticent, do we need more?  Lets try and
> think of other tricks people might want to do with this.
>

Yes.  For each functionality we should add an example.  Beta testers should
be encouraged to contribute.

>
> What did I miss?  Should we make a beta dist next week and make a
> freshmeat posting?
>

I was thinking the same thing.  Beta testing should be concentrating on
getting ideas from outside developers and then after we freeze the
development a final beta should be packaged and all bugs fleshed out for
1.0.  Wow my first 1.0 open source project.

I'm interested to know what projects you are using this in.  For me I am
using it in Snaglepuss - open source multimedia development. And OnCue -
Snaglepuss' scripting enviornment.

>
> --
> Thomas O Matelich
> Senior Software Designer
> Zetec, Inc.
> sos...@us...
> tma...@ze...
>
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

-Quinticent