somelib-devel — Public mailing list for design discussion and bug reports

Re: [Somelib] Modifications for Solaris 2.6

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

Thank you.  I've been trying to get this to work forever.  Back at school I could compile Solaris sources but the linker would
spew out pages of errors.  Now I am out and had no Solaris resources to work on.  Well, thanks again. We can now add Solaris to
our list of supported platforms.

--J5

Nathan Doss wrote:

> Here are the modifications I made to the configure.in file in order to
> get it to work on my solaris 2.6 box.  With these changes it compiled
> and worked without a problem.
>
> * Added a check for whether its compiling on a solaris system
>
> * Although the dl library was installed on my system, the configure
>   script could not find it.  To fix this:
>
>   - I added a check for the standard C compiler.  Without this, the
>     check for the ld library failed because it was using a default
>     (wrong) value for the C compiler.
>
>   - I moved the dl library check to after the check for the C compiler
>     so that it would use the compiler found in AC_PROG_CC during the
>     library check
>
> The modified configure.in script is included below.
>
> Also, the following line in INSTALL should be modified to refer to the
> SOMELib CVS directory.
>
>  "cd to the toplevel SOMELib directory (some0-5 if you checked out from CVS)"
>
> Thanks,
> --
> Nathan  Doss                     nd...@us...
>
> dnl Process this file with autoconf to produce a configure script.
>
> AC_INIT()
> AC_CONFIG_HEADER(config/config.h)
> AC_PREFIX_DEFAULT(/usr)
> AC_CANONICAL_HOST
>
> dnl define os
> echo "host_os = \"$host_os\""
>
> platform="nohostplatform"
>
> dnl hpux
> if test "$host_os" = "hpux10.20"; then
> platform="hpux"
> AC_DEFINE(USE_SOME_HPUX_SL, 1)
> fi
>
> dnl linux
> if test "$host_os" = "linux-gnu"; then
> platform="unix_so"
> fi
>
> if test "$host_os" = "freebsdelf4.2"; then
> platform="unix_so"
> fi
>
> dnl solaris
> solaris_os=`echo "$host_os" | sed 's/solaris.*/yes/'`
> if test "$solaris_os" = "yes"; then
> platform="unix_so"
> fi
>
> dnl oh no we havent configured for this platform yet
> if test "$platform" = "nohostplatform"; then
> echo "I am sorry, platform \"$host_os\" has not been added to our build system yet!"
> echo "This could mean 2 thing:"
> echo "1) SOMELib will compile under your platform using a similar platforms build."
> echo "2) SOMELib will not compile unless you add the platform specific code needed for your platform."
> echo
> echo "Please go to http://sourceforge.net/projects/somelib to find out how you can get your platform working with SOMELib!!!"
> exit -1;
> fi
> AC_SUBST(platform)
>
> AC_ARG_ENABLE(debug,
>   [  --enable-debug          Debugging options],
>   debug=yes, debug=no)
> AC_SUBST(debug)
>
> AC_ARG_ENABLE(verbose,
>   [  --enable-verbose        Verbose output],
>   verbose=yes, verbose=no)
> AC_SUBST(verbose)
>
> dnl Checks for programs.
> AC_PROG_CC
> CXXFLAGS="$CXXFLAGS "
> AC_PROG_CXX
> AC_PROG_INSTALL
>
> dnl Checks for libraries.
>
> dnl unix_so
> if test "$platform" = "unix_so"; then
> dnl check for so loading libs
> AC_CHECK_LIB(dl, dlopen,
> HAVE_LIBDL=yes
> ,
> AC_CHECK_FUNC(dlopen,
> HAS_DLOPEN=yes,
> echo "ERROR: Can't find dynamic linking funtionality!!! Please install libdl."
> )
> )
>
> AC_SUBST(HAVE_LIBDL)
> AC_DEFINE(USE_SOME_UNIX_SO, 1)
> fi
>
> dnl Checks for header files.
>
> dnl Checks for typedefs, structures, and compiler characteristics.
>
> dnl Checks for library functions.
>
> AC_OUTPUT(config/config.mk)
>
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/lists/listinfo/somelib-devel

Re: [Somelib] Modifications for Solaris 2.6

[Thomas M. <sos...@us...>]

Nathan Doss wrote:

> Here are the modifications I made to the configure.in file in order to
> get it to work on my solaris 2.6 box.  With these changes it compiled
> and worked without a problem.
>
> * Added a check for whether its compiling on a solaris system
>
> * Although the dl library was installed on my system, the configure
>   script could not find it.  To fix this:
>
>   - I added a check for the standard C compiler.  Without this, the
>     check for the ld library failed because it was using a default
>     (wrong) value for the C compiler.
>
>   - I moved the dl library check to after the check for the C compiler
>     so that it would use the compiler found in AC_PROG_CC during the
>     library check
>
> The modified configure.in script is included below.
>
> Also, the following line in INSTALL should be modified to refer to the
> SOMELib CVS directory.
>
>  "cd to the toplevel SOMELib directory (some0-5 if you checked out from CVS)"

Thanks for the submission Nathan, and thanks Quinticent for beating me to the punch.

--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sos...@us...
tma...@ze...

[Somelib] Modifications for Solaris 2.6

[Nathan D. <nd...@us...>]

Here are the modifications I made to the configure.in file in order to
get it to work on my solaris 2.6 box.  With these changes it compiled
and worked without a problem.

* Added a check for whether its compiling on a solaris system

* Although the dl library was installed on my system, the configure
  script could not find it.  To fix this:

  - I added a check for the standard C compiler.  Without this, the
    check for the ld library failed because it was using a default
    (wrong) value for the C compiler.
  
  - I moved the dl library check to after the check for the C compiler
    so that it would use the compiler found in AC_PROG_CC during the
    library check

The modified configure.in script is included below.

Also, the following line in INSTALL should be modified to refer to the
SOMELib CVS directory.

 "cd to the toplevel SOMELib directory (some0-5 if you checked out from CVS)"

Thanks,
-- 
Nathan  Doss                     nd...@us...	




dnl Process this file with autoconf to produce a configure script.

AC_INIT()
AC_CONFIG_HEADER(config/config.h)
AC_PREFIX_DEFAULT(/usr)
AC_CANONICAL_HOST

dnl define os
echo "host_os = \"$host_os\""

platform="nohostplatform"

dnl hpux
if test "$host_os" = "hpux10.20"; then
platform="hpux"
AC_DEFINE(USE_SOME_HPUX_SL, 1)
fi

dnl linux
if test "$host_os" = "linux-gnu"; then
platform="unix_so"
fi

if test "$host_os" = "freebsdelf4.2"; then
platform="unix_so"
fi

dnl solaris
solaris_os=`echo "$host_os" | sed 's/solaris.*/yes/'`
if test "$solaris_os" = "yes"; then
platform="unix_so"
fi

dnl oh no we havent configured for this platform yet
if test "$platform" = "nohostplatform"; then
echo "I am sorry, platform \"$host_os\" has not been added to our build system yet!"
echo "This could mean 2 thing:"
echo "1) SOMELib will compile under your platform using a similar platforms build."
echo "2) SOMELib will not compile unless you add the platform specific code needed for your platform."
echo
echo "Please go to http://sourceforge.net/projects/somelib to find out how you can get your platform working with SOMELib!!!"
exit -1;
fi
AC_SUBST(platform)


AC_ARG_ENABLE(debug,
  [  --enable-debug          Debugging options],
  debug=yes, debug=no)
AC_SUBST(debug)

AC_ARG_ENABLE(verbose,
  [  --enable-verbose        Verbose output],
  verbose=yes, verbose=no)
AC_SUBST(verbose)

dnl Checks for programs.
AC_PROG_CC
CXXFLAGS="$CXXFLAGS "
AC_PROG_CXX
AC_PROG_INSTALL

dnl Checks for libraries.

dnl unix_so
if test "$platform" = "unix_so"; then
dnl check for so loading libs
AC_CHECK_LIB(dl, dlopen,
HAVE_LIBDL=yes
,
AC_CHECK_FUNC(dlopen,
HAS_DLOPEN=yes,
echo "ERROR: Can't find dynamic linking funtionality!!! Please install libdl."
)
)

AC_SUBST(HAVE_LIBDL)
AC_DEFINE(USE_SOME_UNIX_SO, 1)
fi

dnl Checks for header files.

dnl Checks for typedefs, structures, and compiler characteristics.

dnl Checks for library functions.

AC_OUTPUT(config/config.mk)

[Somelib] Windows port

[Thomas M. <sos...@us...>]

I have reconfigured the Windows port so that the MSVC projects actually
build.  Its kind of wierd because the dsp's and dsw are all in one
directory (config/Windows), but it ends up being kind of nice, having
all the dlls and exes together.

--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sos...@us...
tma...@ze...

Re: [Somelib] SOME::Path::parsePath

[Thomas M. <tma...@ze...>]

John Palmieri wrote:

> oops :-).  I can't commit because I dont have a real ISP that works under
> Linux yet.  Schools out and I miss my dual T3.  I'll be in London soon and
> will set myself up with one of those free ISP's (there is even one that is
> pure Linux) and work on SOMELib some more.  I think we can just go with the
> '/' since they are the standard for URI's and most modern OS's should
> support them.

Sounds good to me.  I'll fix it when I get a chance.

> Have you looked at the web site yet?
> somelib.sourceforge.net.  Eveything is up except the tutorial which I am
> working on.  Send me any questions you would like to see in the FAQ.

looks good.  I had to replace the tarballs, so if you could fix the link to
download, that would be great.  Maybe it should just go to the sourceforge
download page.

>  Also I did not get a reply on the STL stuff.  Do you think that 200k is
> acceptable
> for our lib?  I have been reading the C++ FAQs and they seem to think that
> homegrown container classes are bad.  Of cource they do not go into code
> bloat and focus more on performance.  I don't know. Ask 100 experts and get
> 100 conflicting answeres.  Hehe.

Sorry, didn't have a good answer to give.  I do see peoples' point of view when
it comes to things like template bloat.  It can really blow things up, we've
got executables around here that have gone from 7 meg to 23 meg just by
switching to g++ from HP c and adding a little STL.  Even though the standard
has been around for quite a while, compilers are still working on simple
compliance rather than good compliance.  So my personal opinion is to keep
things working the way they are, when g++ v3 stabilizes, I think they'll start
making some good inroads into these STL problems.  Out of curiosity, what are
the sizes you show for the example programs and libs?

On Windows 2K (release mode), I've got the following chart:
SOMELib.lib        -> 221k

TestApp.exe          -> 32k
BasicTestLib.dll    -> 32k

complexmenu.exe  -> 56k
Johncomplex.dll    -> 32k
Kathycomplex.dll  -> 28k

helloworld.exe       -> 28k
hello_plugin.dll      -> 28k

simplemenu.exe     -> 44k
johnswritings.dll    -> 32k
kathyswriting.dll    -> 24k

I was going to put the hpux results up, but I can't build on hpux at the time
being :(


--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sos...@us...
tma...@ze...

Re: [Somelib] SOME::Path::parsePath

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

oops :-).  I can't commit because I dont have a real ISP that works under
Linux yet.  Schools out and I miss my dual T3.  I'll be in London soon and
will set myself up with one of those free ISP's (there is even one that is
pure Linux) and work on SOMELib some more.  I think we can just go with the
'/' since they are the standard for URI's and most modern OS's should
support them.  Have you looked at the web site yet?
somelib.sourceforge.net.  Eveything is up except the tutorial which I am
working on.  Send me any questions you would like to see in the FAQ.  Also I
did not get a reply on the STL stuff.  Do you think that 200k is acceptable
for our lib?  I have been reading the C++ FAQs and they seem to think that
homegrown container classes are bad.  Of cource they do not go into code
bloat and focus more on performance.  I don't know. Ask 100 experts and get
100 conflicting answeres.  Hehe.

--Quinticent

Thomas Matelich wrote:

> oops, this is an infinite loop if delimit is not '/'.  I didn't
> recognize it at first because it seems sort of logical.  I'm not sure
> what the plan is here.  In the past I have changed all \'s to /'s
> because windows will work just find with /'s.  For now, I have commented
> this out locally (because I still have trouble committing from windows).
>
> --
> 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

[Somelib] SOME::Path::parsePath

[Thomas M. <tma...@ze...>]

oops, this is an infinite loop if delimit is not '/'.  I didn't
recognize it at first because it seems sort of logical.  I'm not sure
what the plan is here.  In the past I have changed all \'s to /'s
because windows will work just find with /'s.  For now, I have commented
this out locally (because I still have trouble committing from windows).

--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sos...@us...
tma...@ze...

[Somelib] SOMELib STL and library bloat

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

I recently had an e-mail discussion with Pierre Phaneuf, the author of
another inprocess object manager XPLC (http://xplc.sourceforge.net) and
early contributor to the old SOMLib. He is very vocal in his peer review
which I think is very invaluable in assessing a projects strengths and
weaknesses.  I will post his e-mail as well as my reply at the bottom of
this message.

One point that he brought up was the sear size of our "simple" object
model.  With optimizations turned on it compiles down to a somewhat
hefty 200K which is fine for a large system but not so much for embedded
systems and other small memory systems.  I did some tests and this is
indeed a result of the STL.  A simple hello world program compiled down
to 23bytes.  When string was added it jumped up to 400bytes, vector 23k,
map 30k, multiple initializations of vector and map churned up a 43k
executable.  I think using the STL was a good start because it allowed
us to create the system rapidly and fairly bug free and it also allows
developers to use familiar tools and not write to confusing non-standard
interfaces.  I think now we must assess each data structure and
algorithm and use only those which are needed while perhaps creating our
own paired down STL compatible data structures. Our first goal is
simplicity and we should not sacrifice this for the size of the library
but beyond that whatever we can do to cut the library size would be
great.  Suggestions?

The e-mail exchange follows:
from: <pp...@lu...>

Note: I can seem "abrasive" in some comments that I make in this
message, but I do not have any bad feelings toward you or your library,
I am just being honest, expressing my impressions, which might or might
not be the reality. If I say that SOMELib suck (which I don't), it could

very well be just because I do not understand it. So, having said
this...

> Our code has vastly changed and is moving to 1.0.  Get the new
> code from CVS and see what you think.  There are a few examples
> on how to use it in the examples dir.  Perhaps we can meld the
> two having XPLC be an extra component built on top of SOMELib
> much like SOMELib is an extra component built on top of libdl.
> Collaboration is good if it reduces work :-)

My goals with XPLC seem so similar to those of SOMELib that XPLC
wouldn't gain much by being on top of SOMELib (having parallel things
for almost everything in it). In particular, I have additional goals of
having this work in large complex systems like a web browser, a window
manager or a network service server. I see you are working with strings,

which I have found to be a great impediment toward this goal for
example.

I remember contributing something to SOMELib a long time ago, but I
can't remember what... The makefiles seem a bit familiar, but they are
recursive, unlike those I usually make...

I checked SOMELib and even parts of Snaglepuss. Could you do the same
with XPLC? The test program exercise all the current classes and
components of XPLC, even if they are not very visually interesting, the
code is.

You seem to have good ideas, but you seem lack some kind of inner
feeling in your code and design, some things you did not seem to break
down to their lowest level to understand. Experience maybe...

For example, let me explain the way the XPLC service manager came into
being as it is now...

Firstly the goal: I wanted to do something like using a regular C++
library, but at runtime instead of at compile/link-time.

I found two basic parts to a C++ library, the headers and the object
files. The headers are pretty easy to deal with, these *have* to be
stable, and are dealt with using the interface system (based on
IObject). Pretty easy (consider that I stole the idea anyway).

Making a runtime linker is much harder though... A linker works by
resolving symbols and giving them to whoever needs them. One of the
problem often encountered with "regular" C++ development is symbol
collision (occurs more often than you'd think in larger programs). Using

UUIDs for global symbols resolves this problem, and you can always make
a local alias for a UUID so that you do not have to type them in.

So I made a table, similar to the map STL template (and once was
implemented with map, actually). This was good I thought. Now I had a
runtime linker. But this is not that easy.

I found that having all the required factories in the table (so that you

could create any component at a moment notice) would require having all
the modules loaded at all time, to have their factory object in the
service manager! This was not acceptable. Keeping a map of UUIDs to
files and demand-loading them was not very interesting to me, because I
was starting to bloat the service manager.

So I had the idea of having "handlers". When the service manager didn't
have an object in its map<>, it asked its "handlers" to see if they
could get it for him. One of the handlers would be a dynamic loader and
would keep the mapping of UUID to module files, keeping related things
together.

This was good. But the design of the service manager suffered: there was

more methods now, and the object lookup code was done twice, once for
its map, and once for the handlers.

Some more thinking, and I got the idea of spinning off the map<> into
its own handler, making the service manager using only handlers. At
initialization time, the "static service handler" is populated with all
the components that are included with XPLC, then added to the service
manager. From there, the application can instantiate the dynamic module
handler component and add it to the service manager as another handler,
configuring things like where to look for modules first.

This result in a stripped libxplc.so of of less than 24k, compared to a
stripped libSOME.so (which doesn't do much more) of over 200k. When I
say "lightweight", I mean it, don't I? ;-)

So, saving a few kilobytes of code from XPLC by using your multiple
hundred kilobytes SOMELib doesn't seem like a very good idea to me. When

I will have a table-based getInterface implementation (this weekend), I
think XPLC binary and source code size will decrease even more.

I tried to understand why it is so big, I think it is because of the
templates. Beware, as templates are a very static thing that does not
meld very well with dynamic code. They have good uses though, mainly as
a super-inlining and super-clean macro facility (compare my
GenericComponent template to the fantastically obscure macro that XPCOM
uses to do the same thing!). As smart pointers, they can be useful. I
found the STL to be a particularly nasty thing to use if you try to be
lightweight... :-)

About your RANT file: garbage collection is very good to have in a
complex system, because you can then share more general objects between
the subsystems. For example, if you have an object for the X connection,

you can have unrelated objects create windows, which increate the
connection refcount, which is then destroyed when the last window is
destroyed. Or maybe not, if something else decided it might have to
recreate a window later (for example, a screen saver).

But I *know* why you found it Hard to have working correctly. There is
one key realization to garbage collection: some references are strong
and other are weak. Only the strong ones should prevent the destruction
of an object.

The weak reference implementation of XPCOM is a nice one, and pretty
easy to understand.

If I keep going at the rate of nearly a thousand lines of code a week
here on XPLC that I'm already going, I estimate that by early January,
XPLC will have a whole lot of features over SOMELib.

--
"How much does it cost to entice a dope-smoking Unix system guru
to Dayton?" -- Brian Boyle, UNIX/WORLD's First Annual Salary Survey

-
-----------------------my reply-----------------------------
Pierre,

Sorry for not writing back sooner but with the holidays and all it has
been hectic.  You contributed the makefiles at one point.  I had to
change them back to recursive make files because it is just easier to
maintain.  Also I would get dependency warnings because of header files
it could not find every time I did a clean build.  I was considering
using XPLC at one point but it took to long to get into a usable state
and a bunch of people contacted me over the summer with porting SOMELib
to windows so I put it on Source Forge and the rest is history.  Some
counterpoints on your design vs. our design:

In regards to IObject we decided to chuck any standard base classes.
While most current object models require you to use some sort of base
class or interface(IObject in your implementation) we felt that this,
although easy to use, was not desirable.  As it stands now, you can take
any C++ class or object file that has its own pure virtual interface and
without modifying the code, link it to a SOMELib class descriptor and
load it up using SOMELib.  This leaves the implementation of a base
interface up to the user.

On the topic of UUIDs, objects are loaded in SOMELib by categorization.
In essence if a user wishes to use UUIDs to categorize objects then they
simply can add a UUID category and assign each class a UUID in the class
descriptor.  This is not imposed by SOMELib.

On loaded modules.  Our system works by loading descriptors (Catalogs in
SOMELib) of classes and not the actual classes themselves until an
object is physically constructed so memory usage is kept at a minimum.
In the future a caching algorithm will be added to also unload all
catalogs not used in a while.  Your idea of loading handlers was a topic
we had thought of when discussing the ability to swap in and out
different algorithms for caching but it would mean that there would have
to be a configuration file or environment variable somewhere telling
SOMELib where to find its own components. It remains an option in the
future.

As for the STL.  I looked at the size of the library and I concur that
it is a bit large.  We wanted to get all the features in and bug free
before we started optimization.  Now we might just go in and take out
the STL pieces replacing them with our own similar versions.  I still
want to work with iterates because they are a lot easier to work with
and understand.

Perhaps our projects can't work together but they can feed of each
other.  Thank you for the input.

--John Palmieri

Re: [Somelib] S_IFDIR

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

Cool, I think you can send out a nother tar ball for the masses to devoure.
I'll write up documentation and we can move to 1.0 in the next few weeks.
I have finals until the 18th so don't expect anything too soon.  I'll leave
space for you to fill in the windows specific stuff.

-Quinticent

Thomas Matelich wrote:

> John Palmieri wrote:
>
> > It seems as if S_IFDIR is defined on my Debian GNU linux and on
> > FreeBSD.  Should it not also be defined on HPUX? I am having trouble
> > with the tests in configure for checking headers -  AC_EGREP_HEADER.
> > Please check the sys/stat.h for this decleration.  In my experience with
> > C/C++ if a macro is prepended by underscores it is mostly only supposed
> > to be used internaly and is given a public alias without the underscores
> > if it ment to be used externaly.
> >
> > --Quinticent
> >
> > _______________________________________________
> > somelib-devel mailing list
> > som...@li...
> > http://lists.sourceforge.net/mailman/listinfo/somelib-devel
>
> Here is the whole kit and caboodle from HP's sys/stat.h.   So there is a
> S_IFDIR macro on HPUX.
>
> /* Symbols and macros for decoding the value of st_mode */
>
> #ifdef _INCLUDE_POSIX_SOURCE
> #  ifndef S_IRWXU  /* fcntl.h might have already defined these */
> #    define S_ISUID 0004000 /* set user ID on execution */
> #    define S_ISGID 0002000 /* set group ID on execution */
>
> #    define S_IRWXU 0000700 /* read, write, execute permission (owner) */
> #    define S_IRUSR 0000400 /* read permission (owner) */
> #    define S_IWUSR 0000200 /* write permission (owner) */
> #    define S_IXUSR 0000100 /* execute permission (owner) */
>
> #    define S_IRWXG 0000070 /* read, write, execute permission (group) */
> #    define S_IRGRP 0000040 /* read permission (group) */
> #    define S_IWGRP 0000020 /* write permission (group) */
> #    define S_IXGRP 0000010 /* execute permission (group) */
>
> #    define S_IRWXO 0000007 /* read, write, execute permission (other) */
> #    define S_IROTH 0000004 /* read permission (other) */
> #    define S_IWOTH 0000002 /* write permission (other) */
> #    define S_IXOTH 0000001 /* execute permission (other) */
> #  endif /* S_IRWXU */
>
> #  define _S_IFMT   0170000 /* type of file */
> #  define _S_IFREG  0100000 /* regular */
> #  define _S_IFBLK  0060000 /* block special */
> #  define _S_IFCHR  0020000 /* character special */
> #  define _S_IFDIR  0040000 /* directory */
> #  define _S_IFIFO  0010000 /* pipe or FIFO */
>
> #  define S_ISDIR(_M)  ((_M & _S_IFMT)==_S_IFDIR) /* test for directory */
> #  define S_ISCHR(_M)  ((_M & _S_IFMT)==_S_IFCHR) /* test for char special
> */
> #  define S_ISBLK(_M)  ((_M & _S_IFMT)==_S_IFBLK) /* test for block special
> */
> #  define S_ISREG(_M)  ((_M & _S_IFMT)==_S_IFREG) /* test for regular file
> */
> #  define S_ISFIFO(_M) ((_M & _S_IFMT)==_S_IFIFO) /* test for pipe or FIFO
> */
> #endif /* _INCLUDE_POSIX_SOURCE */
>
> #ifdef _INCLUDE_POSIX4_SOURCE     /* P1003.4/D14.1 */
> #  define S_TYPEISMQ(buf) (0)    /* 5.6.1.1 */
> #  define S_TYPEISSEM(buf) (0)    /* 5.6.1.1 */
> #  define S_TYPEISSHM(buf) (0)    /* 5.6.1.1 */
> #endif /* _INCLUDE_POSIX4_SOURCE */
>
> #ifdef _INCLUDE_XOPEN_SOURCE
> #  define S_IFMT _S_IFMT  /* type of file */
> #  define S_IFBLK _S_IFBLK /* block special */
> #  define S_IFCHR _S_IFCHR /* character special */
> #  define S_IFDIR _S_IFDIR /* directory */
> #  define S_IFIFO _S_IFIFO /* pipe or FIFO */
> #  define S_IFREG _S_IFREG /* regular */
> #  ifndef _XPG4
> #    define S_ISVTX 0001000  /* save swapped text even after use */
> #  endif /* not _XPG4 */
> #endif /* _INCLUDE_XOPEN_SOURCE */
>
> #ifdef _INCLUDE_AES_SOURCE
> #  define S_IFLNK 0120000 /* symbolic link */
> #  define S_ISLNK(_M) ((_M & S_IFMT)==S_IFLNK)   /* test for symbolic link
> */
> #endif /* _INCLUDE_AES_SOURCE */
>
> #ifdef _INCLUDE_XOPEN_SOURCE_EXTENDED
> #  ifndef S_ISVTX
> #    define S_ISVTX 0001000 /* save swapped text even after use */
> #  endif /* not S_ISVTX */
>
> #  define S_IFSOCK 0140000 /* socket */
> #  define S_ISSOCK(_M) ((_M & S_IFMT)==S_IFSOCK) /* test for socket */
> #endif /* _INCLUDE_XOPEN_SOURCE_EXTENDED */
>
> #ifdef _INCLUDE_HPUX_SOURCE
> #  define S_CDF  0004000 /* hidden directory */
> #  define S_ENFMT 0002000 /* enforced file locking (shared w/ S_ISGID) */
> #  define S_IFNWK 0110000 /* network special */
>
> #  define S_ISNWK(_M) ((_M & S_IFMT)==S_IFNWK)  /* test for network special
> */
> #  define S_ISCDF(_M) (S_ISDIR(_M) && (_M & S_CDF)) /* test for hidden dir
> */
>
> /* Some synonyms used historically in the kernel and elsewhere */
>
> #  define S_IREAD   S_IRUSR /* read permission, owner */
> #  define S_IWRITE  S_IWUSR /* write permission, owner */
> #  define S_IEXEC   S_IXUSR /* execute/search permission, owner */
>
> #  define st_rsite st_rcnode
>
> #endif /* _INCLUDE_HPUX_SOURCE */
>
> #ifdef _UNSUPPORTED
>
> --
> 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

Re: [Somelib] S_IFDIR

[Thomas M. <tma...@ze...>]

John Palmieri wrote:

> It seems as if S_IFDIR is defined on my Debian GNU linux and on
> FreeBSD.  Should it not also be defined on HPUX? I am having trouble
> with the tests in configure for checking headers -  AC_EGREP_HEADER.
> Please check the sys/stat.h for this decleration.  In my experience with
> C/C++ if a macro is prepended by underscores it is mostly only supposed
> to be used internaly and is given a public alias without the underscores
> if it ment to be used externaly.
>
> --Quinticent
>
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

Here is the whole kit and caboodle from HP's sys/stat.h.   So there is a
S_IFDIR macro on HPUX.

/* Symbols and macros for decoding the value of st_mode */

#ifdef _INCLUDE_POSIX_SOURCE
#  ifndef S_IRWXU  /* fcntl.h might have already defined these */
#    define S_ISUID 0004000 /* set user ID on execution */
#    define S_ISGID 0002000 /* set group ID on execution */

#    define S_IRWXU 0000700 /* read, write, execute permission (owner) */
#    define S_IRUSR 0000400 /* read permission (owner) */
#    define S_IWUSR 0000200 /* write permission (owner) */
#    define S_IXUSR 0000100 /* execute permission (owner) */

#    define S_IRWXG 0000070 /* read, write, execute permission (group) */
#    define S_IRGRP 0000040 /* read permission (group) */
#    define S_IWGRP 0000020 /* write permission (group) */
#    define S_IXGRP 0000010 /* execute permission (group) */

#    define S_IRWXO 0000007 /* read, write, execute permission (other) */
#    define S_IROTH 0000004 /* read permission (other) */
#    define S_IWOTH 0000002 /* write permission (other) */
#    define S_IXOTH 0000001 /* execute permission (other) */
#  endif /* S_IRWXU */

#  define _S_IFMT   0170000 /* type of file */
#  define _S_IFREG  0100000 /* regular */
#  define _S_IFBLK  0060000 /* block special */
#  define _S_IFCHR  0020000 /* character special */
#  define _S_IFDIR  0040000 /* directory */
#  define _S_IFIFO  0010000 /* pipe or FIFO */

#  define S_ISDIR(_M)  ((_M & _S_IFMT)==_S_IFDIR) /* test for directory */
#  define S_ISCHR(_M)  ((_M & _S_IFMT)==_S_IFCHR) /* test for char special
*/
#  define S_ISBLK(_M)  ((_M & _S_IFMT)==_S_IFBLK) /* test for block special
*/
#  define S_ISREG(_M)  ((_M & _S_IFMT)==_S_IFREG) /* test for regular file
*/
#  define S_ISFIFO(_M) ((_M & _S_IFMT)==_S_IFIFO) /* test for pipe or FIFO
*/
#endif /* _INCLUDE_POSIX_SOURCE */

#ifdef _INCLUDE_POSIX4_SOURCE     /* P1003.4/D14.1 */
#  define S_TYPEISMQ(buf) (0)    /* 5.6.1.1 */
#  define S_TYPEISSEM(buf) (0)    /* 5.6.1.1 */
#  define S_TYPEISSHM(buf) (0)    /* 5.6.1.1 */
#endif /* _INCLUDE_POSIX4_SOURCE */

#ifdef _INCLUDE_XOPEN_SOURCE
#  define S_IFMT _S_IFMT  /* type of file */
#  define S_IFBLK _S_IFBLK /* block special */
#  define S_IFCHR _S_IFCHR /* character special */
#  define S_IFDIR _S_IFDIR /* directory */
#  define S_IFIFO _S_IFIFO /* pipe or FIFO */
#  define S_IFREG _S_IFREG /* regular */
#  ifndef _XPG4
#    define S_ISVTX 0001000  /* save swapped text even after use */
#  endif /* not _XPG4 */
#endif /* _INCLUDE_XOPEN_SOURCE */

#ifdef _INCLUDE_AES_SOURCE
#  define S_IFLNK 0120000 /* symbolic link */
#  define S_ISLNK(_M) ((_M & S_IFMT)==S_IFLNK)   /* test for symbolic link
*/
#endif /* _INCLUDE_AES_SOURCE */

#ifdef _INCLUDE_XOPEN_SOURCE_EXTENDED
#  ifndef S_ISVTX
#    define S_ISVTX 0001000 /* save swapped text even after use */
#  endif /* not S_ISVTX */

#  define S_IFSOCK 0140000 /* socket */
#  define S_ISSOCK(_M) ((_M & S_IFMT)==S_IFSOCK) /* test for socket */
#endif /* _INCLUDE_XOPEN_SOURCE_EXTENDED */

#ifdef _INCLUDE_HPUX_SOURCE
#  define S_CDF  0004000 /* hidden directory */
#  define S_ENFMT 0002000 /* enforced file locking (shared w/ S_ISGID) */
#  define S_IFNWK 0110000 /* network special */


#  define S_ISNWK(_M) ((_M & S_IFMT)==S_IFNWK)  /* test for network special
*/
#  define S_ISCDF(_M) (S_ISDIR(_M) && (_M & S_CDF)) /* test for hidden dir
*/


/* Some synonyms used historically in the kernel and elsewhere */

#  define S_IREAD   S_IRUSR /* read permission, owner */
#  define S_IWRITE  S_IWUSR /* write permission, owner */
#  define S_IEXEC   S_IXUSR /* execute/search permission, owner */

#  define st_rsite st_rcnode

#endif /* _INCLUDE_HPUX_SOURCE */

#ifdef _UNSUPPORTED


--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sos...@us...
tma...@ze...

[Somelib] S_IFDIR

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

It seems as if S_IFDIR is defined on my Debian GNU linux and on
FreeBSD.  Should it not also be defined on HPUX? I am having trouble
with the tests in configure for checking headers -  AC_EGREP_HEADER.
Please check the sys/stat.h for this decleration.  In my experience with
C/C++ if a macro is prepended by underscores it is mostly only supposed
to be used internaly and is given a public alias without the underscores
if it ment to be used externaly.

--Quinticent

Re: [Somelib] Build tree changed

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

Yes, XPPath is not needed.  The Project builds under BSD now with one cavet.
HP Unix uses _S_IFDIR, Linux uses __S_IFDIR and BSD uses S_IFDIR.  Doh!!!  I am
in the process of creating a test for these macros within configure.  I will
then define SOME_IFDIR with the correct macro in the config.h header.

-Quinticent

Thomas Matelich wrote:

> Thomas Matelich wrote:
>
> > I'll do it as soon as I can get to the cvs server.  Our windows support is
> > currently not verified because I haven't been working there for quite a
> > while.  Maybe I should get a copy of VMWare.
>
> It still works.  I believe we can remove XPPath from the project now that we
> have PathDriver correct?
>
> --
> 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

Re: [Somelib] Build tree changed

[Thomas M. <tma...@ze...>]

Thomas Matelich wrote:

> I'll do it as soon as I can get to the cvs server.  Our windows support is
> currently not verified because I haven't been working there for quite a
> while.  Maybe I should get a copy of VMWare.

It still works.  I believe we can remove XPPath from the project now that we
have PathDriver correct?

--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sos...@us...
tma...@ze...

Re: [Somelib] Build tree changed

[Thomas M. <tma...@ze...>]

John Palmieri wrote:

> I changed the build to detect if libdl functionality is in a shared
> library as in linux or integerated into libstdc as in BSD for .so
> systems.  I also changed the platform from linux to unix_so.  I have yet
> to do a build on BSD to test out the new build system and will implement
> it tomorow.  On a side note I had trouble commiting my changes due to
> conflicts in the CVS tree.  Please do a cvs update/configure/make
> clean/make to verify that the tree is not broken.
>
> -Quinticent
>
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

I'll do it as soon as I can get to the cvs server.  Our windows support is
currently not verified because I haven't been working there for quite a
while.  Maybe I should get a copy of VMWare.

--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sos...@us...
tma...@ze...

[Somelib] Build tree changed

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

I changed the build to detect if libdl functionality is in a shared
library as in linux or integerated into libstdc as in BSD for .so
systems.  I also changed the platform from linux to unix_so.  I have yet
to do a build on BSD to test out the new build system and will implement
it tomorow.  On a side note I had trouble commiting my changes due to
conflicts in the CVS tree.  Please do a cvs update/configure/make
clean/make to verify that the tree is not broken.

-Quinticent

[Somelib] RegEx in cvs

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

I have created a new file some_algo.h which has the regex stuff in it.
It works very well.  It uses the old dos shell wildcard format.  The
only two special symbols are the '*' and '?'.  * means match 0 or more
of any character. ? means match exactly 1 of any character.  I could
have gutted grep for code but grep is much to complicated for our needs.

On another side note.  My professor doesn't know why SOMELib is not
linking on the Suns.  He suggests that we might have touched on a bug in
GCC.  I have scratched it off my lists of things to do since I am no
Solaris expert and out of all the Unix's I have ever used I hate Solaris
the most.  If there is someone out there who realy wants to get this
working for Solaris( and I think it should work with this major
platform) then be my guest and fool around with it and send back the
patches.

-Quinticent

Re: [Somelib] SOME::Path changed - RegEx and BSD compile fix are next

[Thomas M. <tma...@ze...>]

John Palmieri wrote:

> Hope you have had a good Thanksgiving.

Very good, thanks.

> SOME:Path has changed to Path encapsulating the platform specific code
> of PathDriver. (Before XPPath was being inherited by platform specific
> code Path).  PathDriver should be duplicated under the HPUX and Windows
> directory and changed to reflect the platform (ie __IS_DIR back to
> _IS_DIR).  From our last e-mail I got the impression that directory
> searching is the same on Windows, Linux and HPUX (except for the
> macro)?  Is this true for Windows 9x or just NT (I know NT is somewhat
> Posix complient for military use).  I would like to keep these seperate
> for different platforms even if they are the same on these three
> platforms, being that it will make it easyer to port to some esoteric OS
> that does not support Posix.  Am I wrong in stating that opendir,
> closedir, etc. are not ANSI standards?  If they are then the PathDriver
> is redundant and can be folded into Path.

opendir, closedir, etc. are not available on Winders.  So these will have
to remain seperate.  I changed all of them to use stat for checking whether
its a dir because it seemed faster than what you were doing previously.

> I will  beimplementing simple regular expressions for file searching
> next.  I am still not sure about using boost.  How are their feelings if
> we take their code LGPL?  I can see using smart pointers but the Regular
> Expression code is going to be highly modified.  Will this meen that
> under their licence I can not make someone give back code if they modify
> the RegEx portion of the code?  I also feel bad about taking someones
> code and making it completely open if they wish that people can use it
> in closed source apps.  I havn't looked at it yet and I have a feeling
> that it is a bit more complicated than we need anyway.  All I want is
> the old dos pattern matching.  * for wildcard, ? for 1 char wildcard and
> the rest literals.

I think if we used boost::regex we would have to leave it with their
license (as must our modified use of that code).  If you have experience
with that simple matching, then I would just go ahead and write it, rather
than try and modify regex for our use.

> --Quinticent

--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sos...@us...
tma...@ze...

[Somelib] SOME::Path changed - RegEx and BSD compile fix are next

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

Hope you have had a good Thanksgiving.

SOME:Path has changed to Path encapsulating the platform specific code
of PathDriver. (Before XPPath was being inherited by platform specific
code Path).  PathDriver should be duplicated under the HPUX and Windows
directory and changed to reflect the platform (ie __IS_DIR back to
_IS_DIR).  From our last e-mail I got the impression that directory
searching is the same on Windows, Linux and HPUX (except for the
macro)?  Is this true for Windows 9x or just NT (I know NT is somewhat
Posix complient for military use).  I would like to keep these seperate
for different platforms even if they are the same on these three
platforms, being that it will make it easyer to port to some esoteric OS
that does not support Posix.  Am I wrong in stating that opendir,
closedir, etc. are not ANSI standards?  If they are then the PathDriver
is redundant and can be folded into Path.

I will  beimplementing simple regular expressions for file searching
next.  I am still not sure about using boost.  How are their feelings if
we take their code LGPL?  I can see using smart pointers but the Regular
Expression code is going to be highly modified.  Will this meen that
under their licence I can not make someone give back code if they modify
the RegEx portion of the code?  I also feel bad about taking someones
code and making it completely open if they wish that people can use it
in closed source apps.  I havn't looked at it yet and I have a feeling
that it is a bit more complicated than we need anyway.  All I want is
the old dos pattern matching.  * for wildcard, ? for 1 char wildcard and
the rest literals.

--Quinticent

Re: [Somelib] _S_IFDIR is not defined

[Thomas M. <tma...@ze...>]

John Palmieri wrote:

> Thomas Matelich wrote:
>
> > John Palmieri wrote:
> >
> > > >
> > > >
> > > > If one is using kdevelop to create the shared libraries, it uses libtool which
> > > > automatically uses the versioning scheme I mentioned.  Therefore, I think it is
> > > > very important to only find the files with the correct extension.
> > > >
> > >
> > > Well, I think that this is application specific and not SOMELib specific.  Say
> > > I wanted to end all my libraries with the extention .plug so that it can be
> > > associated with a mime type?  In the current scheme I could do this but if you
> > > enforce library extentions then this is not possible.
> >
> > Ok.  I think changing extension doesn't work on Win and HP, but it is a valid point.
>
> I've seen plugin systems under windows that change the dll extention.  Try it out and
> see what you get.
>
> >
> >
> > > I did a test by creating a
> > > soft link to one of the libraries in complexmenu.  It does load the lib 2 times.
> > > I belive that to avoid this we should be checking if a library is already loaded
> > > (Which I thought it did) and to not load it twice.  Perhaps we should give
> > > libraries UID's.
> >
> > It only checks to see if the same path is loaded twice.  Aren't there functions for
> > tracking down the "real" path to a file or dir?  I'll look into that.  I suppose I
> > should add the check for the same name and version of a library.  Should we allow
> > multiple versions loaded?  Probably.
> >
>
> Yes.
>
> >
> > > I think that once wildcard (regular expression) matches and text
> > > file loading are implemented a developer will have the option of restricting what
> > > extentions are loaded.  Perhaps you would feel better if we restricted directory
> > > loading so that you would have to supply a wildcard?  i.e. To load a entire
> > > directory you would have to use Path p = "plugins/*" and not just Path p =
> > > "plugins/"?  That way a developer would have to deliberatly say I want all files
> > > in this directory no matter what.
> >
> > That would make me feel better, but i don't know if I would enjoy using that
> > interface.  Hmm, tough decision.
> >
>
> I'll change it then when I implement regex.

I know you don't want outside dependencies, but boost now includes regex++, in case you
don't want to write it yourself.

> >
> > > On a side note, have you gotten the assignment operator to work?  It is a lot
> > > nicer to say Path p="plugins/" instead of Path p; p.set("plugins/");  I don't know
> > > why it was not working for me.
> >
> > Assignment operators are not inherited.  So I guess the first question is what the
> > purpose of the XPPath base class is (I'm guessing this relates to the regex stuff).
> > If it is needed, those functions will need to be added to Path, otherwise, let's drop
> > the heirarchy.
> >
>
> Realy, that is wierd because I inherited string in one of my programs and assignment
> still works.

If the inherited class had a constructor inh_string(string), then the default assignment
operator would have been invoked for inh_string because a constructor becomes an implicit
converison operator.  Since Path doesn't have Path(string), it is failing.

>  XPPath is needed so we don't have to duplicate the regex code(and other
> generic code) everytime we change it, unless the changes you made to Path render it
> platform independent.  The other idea is to change XPPath to Path and Path to PathDriver
> and have the new Path encapsulate PathDriver for the platform specific code.
> Composition over inheritance.

Yes, I like this much better.  I'll let you handle that.

>
>
> When do you think we could put out another tar ball?  Version .4a is a bit dated now and
> the new code is quite usable.  Perhaps after Path has frozen and regex is in?
>

That sounds like a good time to do it.

>
> --Quinticent
>
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sos...@us...
tma...@ze...

Re: [Somelib] _S_IFDIR is not defined

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

Thomas Matelich wrote:

> John Palmieri wrote:
>
> > >
> > >
> > > If one is using kdevelop to create the shared libraries, it uses libtool which
> > > automatically uses the versioning scheme I mentioned.  Therefore, I think it is
> > > very important to only find the files with the correct extension.
> > >
> >
> > Well, I think that this is application specific and not SOMELib specific.  Say
> > I wanted to end all my libraries with the extention .plug so that it can be
> > associated with a mime type?  In the current scheme I could do this but if you
> > enforce library extentions then this is not possible.
>
> Ok.  I think changing extension doesn't work on Win and HP, but it is a valid point.

I've seen plugin systems under windows that change the dll extention.  Try it out and
see what you get.

>
>
> > I did a test by creating a
> > soft link to one of the libraries in complexmenu.  It does load the lib 2 times.
> > I belive that to avoid this we should be checking if a library is already loaded
> > (Which I thought it did) and to not load it twice.  Perhaps we should give
> > libraries UID's.
>
> It only checks to see if the same path is loaded twice.  Aren't there functions for
> tracking down the "real" path to a file or dir?  I'll look into that.  I suppose I
> should add the check for the same name and version of a library.  Should we allow
> multiple versions loaded?  Probably.
>

Yes.

>
> > I think that once wildcard (regular expression) matches and text
> > file loading are implemented a developer will have the option of restricting what
> > extentions are loaded.  Perhaps you would feel better if we restricted directory
> > loading so that you would have to supply a wildcard?  i.e. To load a entire
> > directory you would have to use Path p = "plugins/*" and not just Path p =
> > "plugins/"?  That way a developer would have to deliberatly say I want all files
> > in this directory no matter what.
>
> That would make me feel better, but i don't know if I would enjoy using that
> interface.  Hmm, tough decision.
>

I'll change it then when I implement regex.

>
> > On a side note, have you gotten the assignment operator to work?  It is a lot
> > nicer to say Path p="plugins/" instead of Path p; p.set("plugins/");  I don't know
> > why it was not working for me.
>
> Assignment operators are not inherited.  So I guess the first question is what the
> purpose of the XPPath base class is (I'm guessing this relates to the regex stuff).
> If it is needed, those functions will need to be added to Path, otherwise, let's drop
> the heirarchy.
>

Realy, that is wierd because I inherited string in one of my programs and assignment
still works.  XPPath is needed so we don't have to duplicate the regex code(and other
generic code) everytime we change it, unless the changes you made to Path render it
platform independent.  The other idea is to change XPPath to Path and Path to PathDriver
and have the new Path encapsulate PathDriver for the platform specific code.
Composition over inheritance.

When do you think we could put out another tar ball?  Version .4a is a bit dated now and
the new code is quite usable.  Perhaps after Path has frozen and regex is in?

--Quinticent

Re: [Somelib] _S_IFDIR is not defined

[Thomas M. <tma...@ze...>]

John Palmieri wrote:

> >
> >
> > If one is using kdevelop to create the shared libraries, it uses libtool which
> > automatically uses the versioning scheme I mentioned.  Therefore, I think it is
> > very important to only find the files with the correct extension.
> >
>
> Well, I think that this is application specific and not SOMELib specific.  Say
> I wanted to end all my libraries with the extention .plug so that it can be
> associated with a mime type?  In the current scheme I could do this but if you
> enforce library extentions then this is not possible.

Ok.  I think changing extension doesn't work on Win and HP, but it is a valid point.

> I did a test by creating a
> soft link to one of the libraries in complexmenu.  It does load the lib 2 times.
> I belive that to avoid this we should be checking if a library is already loaded
> (Which I thought it did) and to not load it twice.  Perhaps we should give
> libraries UID's.

It only checks to see if the same path is loaded twice.  Aren't there functions for
tracking down the "real" path to a file or dir?  I'll look into that.  I suppose I
should add the check for the same name and version of a library.  Should we allow
multiple versions loaded?  Probably.

> I think that once wildcard (regular expression) matches and text
> file loading are implemented a developer will have the option of restricting what
> extentions are loaded.  Perhaps you would feel better if we restricted directory
> loading so that you would have to supply a wildcard?  i.e. To load a entire
> directory you would have to use Path p = "plugins/*" and not just Path p =
> "plugins/"?  That way a developer would have to deliberatly say I want all files
> in this directory no matter what.

That would make me feel better, but i don't know if I would enjoy using that
interface.  Hmm, tough decision.

> On a side note, have you gotten the assignment operator to work?  It is a lot
> nicer to say Path p="plugins/" instead of Path p; p.set("plugins/");  I don't know
> why it was not working for me.

Assignment operators are not inherited.  So I guess the first question is what the
purpose of the XPPath base class is (I'm guessing this relates to the regex stuff).
If it is needed, those functions will need to be added to Path, otherwise, let's drop
the heirarchy.


--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sos...@us...
tma...@ze...

Re: [Somelib] _S_IFDIR is not defined

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

>
>
> If one is using kdevelop to create the shared libraries, it uses libtool which
> automatically uses the versioning scheme I mentioned.  Therefore, I think it is
> very important to only find the files with the correct extension.
>

Well, I think that this is application specific and not SOMELib specific.  Say
I wanted to end all my libraries with the extention .plug so that it can be
associated with a mime type?  In the current scheme I could do this but if you
enforce library extentions then this is not possible.  I did a test by creating a
soft link to one of the libraries in complexmenu.  It does load the lib 2 times.
I belive that to avoid this we should be checking if a library is already loaded
(Which I thought it did) and to not load it twice.  Perhaps we should give
libraries UID's.  I think that once wildcard (regular expression) matches and text
file loading are implemented a developer will have the option of restricting what
extentions are loaded.  Perhaps you would feel better if we restricted directory
loading so that you would have to supply a wildcard?  i.e. To load a entire
directory you would have to use Path p = "plugins/*" and not just Path p =
"plugins/"?  That way a developer would have to deliberatly say I want all files
in this directory no matter what.

On a side note, have you gotten the assignment operator to work?  It is a lot
nicer to say Path p="plugins/" instead of Path p; p.set("plugins/");  I don't know
why it was not working for me.

--Quinticent

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

Re: [Somelib] _S_IFDIR is not defined

[Thomas M. <tma...@ze...>]

John Palmieri wrote:

> Thomas Matelich wrote:
>
> > OOPS!  Sorry about that, thought it would be faster.  _S_IFDIR *should* be
> > in <sys/stat.h>.  I figured since it is on Windows and HPUX that it would
> > be in Linux.  I don't think it would be a problem to change it back if you
> > want.
> >
>
> Well since they are platform specific we can just change them for linux or
> define _S_IFDIR under linux.
>

Apparently on linux, its called __S_IFDIR.  For convenience there is a macro
called S_IFDIR to call on the mode to check if it is a dir.


>
> >
> > On a related note, do we want to change Path so that it only searches for
> > dyn libs?  There could be problems (besides efficiency) if people have the
> > lib.1.1, lib.1, lib.so scheme I think.
> >
>
> Hmmm... Well I think that if a developer is using SOMELib they wouldn't load
> their whole /usr/lib directory.  The directory loading is for use when
> loading from say a plugin directory that only has lib.so.  Remeber that
> SOMELib takes care of versioning (Perhaps we should change versioning to
> three int's for comparison sake - ie major, minor and patch).  I plan to
> offer wildcard matching and text file loading (the textfile would specify
> what libs to load) in the future so that a developer could fine tune their
> lib loading.  Remember, C++ gives you the ability to format your HD, go into
> infinite loops, etc.  It doesn't meen a developer will use these "features".
> But they are there if a developer is crazy enough to want them.

If one is using kdevelop to create the shared libraries, it uses libtool which
automatically uses the versioning scheme I mentioned.  Therefore, I think it is
very important to only find the files with the correct extension.

--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sos...@us...
tma...@ze...

Re: [Somelib] _S_IFDIR is not defined

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

Thomas Matelich wrote:

> OOPS!  Sorry about that, thought it would be faster.  _S_IFDIR *should* be
> in <sys/stat.h>.  I figured since it is on Windows and HPUX that it would
> be in Linux.  I don't think it would be a problem to change it back if you
> want.
>

Well since they are platform specific we can just change them for linux or
define _S_IFDIR under linux.

>
> On a related note, do we want to change Path so that it only searches for
> dyn libs?  There could be problems (besides efficiency) if people have the
> lib.1.1, lib.1, lib.so scheme I think.
>

Hmmm... Well I think that if a developer is using SOMELib they wouldn't load
their whole /usr/lib directory.  The directory loading is for use when
loading from say a plugin directory that only has lib.so.  Remeber that
SOMELib takes care of versioning (Perhaps we should change versioning to
three int's for comparison sake - ie major, minor and patch).  I plan to
offer wildcard matching and text file loading (the textfile would specify
what libs to load) in the future so that a developer could fine tune their
lib loading.  Remember, C++ gives you the ability to format your HD, go into
infinite loops, etc.  It doesn't meen a developer will use these "features".
But they are there if a developer is crazy enough to want them.

I can see it now :-)

Dear somelib-devel,  I point SOMELib to /usr/lib so that is may find my
libraries but when I run my program it just seems to suck up all my resources
and then crashes for no reason.

PS This also happens when I execute this piece of code:
for( int i=0; i>=0;i++)
       new myObject();

I just don't understand.

-Quinticent

>
> John Palmieri wrote:
>
> > I see you changed the directory checking method of SOME::Path.  For some
> > reason _S_IFDIR is not defined on my system.   Where is this defined?
> >
> > -Quinticent
> >
> > _______________________________________________
> > somelib-devel mailing list
> > som...@li...
> > http://lists.sourceforge.net/mailman/listinfo/somelib-devel
>
> --
> 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

Re: [Somelib] _S_IFDIR is not defined

[Thomas M. <tma...@ze...>]

OOPS!  Sorry about that, thought it would be faster.  _S_IFDIR *should* be
in <sys/stat.h>.  I figured since it is on Windows and HPUX that it would
be in Linux.  I don't think it would be a problem to change it back if you
want.

On a related note, do we want to change Path so that it only searches for
dyn libs?  There could be problems (besides efficiency) if people have the
lib.1.1, lib.1, lib.so scheme I think.

John Palmieri wrote:

> I see you changed the directory checking method of SOME::Path.  For some
> reason _S_IFDIR is not defined on my system.   Where is this defined?
>
> -Quinticent
>
> _______________________________________________
> somelib-devel mailing list
> som...@li...
> http://lists.sourceforge.net/mailman/listinfo/somelib-devel

--
Thomas O Matelich
Senior Software Designer
Zetec, Inc.
sos...@us...
tma...@ze...