Re: [Somelib] More changes

[John P. (Quinticent) <jo...@ma...>]

Thomas Matelich wrote:

>
> > Thomas Matelich wrote:
> >
> > >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.
>
> No, I had to drop std::map completely.  I could make a constructor that takes
> a std::map.  Essentially the problem is when the map is created on one side
> and used on the other.  Although, both sides do share the same memory space,
> the static members of template classes seem to exist on both sides.
>

The solution is to kill windows ;-) Ok, yes add a constrctor that takes a map.
Document this workaround in doxigen.

>
> > 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.
> >
>
> Ok, makes sense.  So the errors I'm getting on hpux are UserConfig.h can't
> find config.h, things can't find boost and apparently your test for if it is
> hpux doesn't work because USE_SOME_HPUX_SL is not defined.  I'll try it out on
> Linux see if I can get it to work there.  Is the directory for installation
> configurable?
>

configure --prefix=<base install dir> (default is /usr but the libs get sent to
<prefix>/lib/SOME and headers to <prefix>/include/SOME)

I could make it more configurable.

As for the test, I guessed at what the name for hpux would be.  I will change the
configure script to print out the current host os.  You send me the output and I
will change it.

What are the directories for libs and includes on HPUX?

> > > 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.
> >
>
> ClassProperties and LibCatalog?  I'll change the classname and category keys
> to something peculiar.
>

Not ClassProperties this implies encapsulated class variables (eg properties)-
ClassInfo is fine.  I like LibCatalog though.  getCatagory should take arguments:

getCatagory( string simpleCatagory );
getCatagory( string key, string value );
getCatagory( SOME::map keyvalueMap );

setCatagory for the ClassInfo should take:
setCatagory( string simpleCatagory );
setCatagory( string key, string value);

> > > 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.
>
> How do you feel about exceptions?  I know a lot of people don't like them, but
> they are standard compliant, and I think the errors we send out are
> exceptional.
>

I'm not sure.  I use them a lot in Java but never touched it in C++.  I guess we
will ask this of our beta testers.

>
> > > 6) Write the searchForLib func.
> >
> > Yes.
>
> Actually, I have no idea what I intended searchForLib to do.  What does it
> sound like to you?
>

findLib is more compact.

Search for a library and return its LibCatalog.  Should we extend LibCatalog to
have the same catagory functionality as ClassInfo?

>
> > > 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.
>
> Sounds good to me.  I'll put it on my list.  Though, what if they accidently
> pass in a dir and load 300M of libraries?
>

Hmm...well it is their fault but I see how this could be a problem.  Since we can
only load libs that are compiled for somelib there is no real problem with someone
trying to loadLib( "/usr/lib" ).  Anytime a library is found not to contain the
correct exported functions it should be beaten to death with a stick and then
unloaded from memory (and the programmer/user properly chastised for sloppy
selection of directories).  Remeber also that each loaded lib should only load
into memory the exported function (lazy loading) and memory usage should not go up
until an object is actualy created.  To allow the programmer to finietly control
memory usage we should provide methods for unloading specific libs and checking
the size a library is currently taking up in memory.  In the future we could
implement a caching mecinism that can be turned off or on (perhaps create a cache
plugin achetecture - SOMELib using SOMELib, cool!!!)  that will unload unused
libraries from memory and when requested load them back up.

>
> > > 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.
>
> So far I've only used it in my own version of CppUnit (the XP unit testing
> framework).  I made it so tests can be stored in shared libraries and loaded
> at runtime.  This is nice because I can now ship my tests and not have their
> existence affect the customer.  I hope to clean it up and get management to
> let me release it.  The neat thing is that each test case has a static member
> which returns a suite of tests and I was able to do some "Test Defines" macros
> to call that static and send it's return back to the host app, rather than
> calling a constructor.
>

Cool. Oh I'm going to start work on a preprocesor that is optional (I need to
refresh myself on the usage of lex and yacc so I said, "why not?").  The cool
thing about the preprocessor is that using the same functionality as printf
(unknown # of arguments) I can create an object with an unlimited amount of
constructors.  It will be awhile before that goes in though.

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