libfunutil-devel — development forum for libfunUtil

Re: [fU] approaching impact

[Rusty B. <ho...@sb...>]

> > One thing which doesn't seem to work is whatever's supposed to strip
> > the binaries during the packaging process.  libfunUtil.so goes from
> > like 3.5MB to 300K if you strip it after installing the RPM package.
>
> It used to work and i removed it because i once tried to link to
> libfunutil.a and it was devoid of symbols.

Oh, I was talking about something I noticed rpm doing during its
gyrations--it runs some /usr/lib/rpm/redhat/brp-strip command, which
I assumed was trying to strip binaries, but it turns out it's purpose
is to strip developers of their will to live.  ("Which is strange,
because that functionality is handled by so many other aspects of
rpm...")

--Rusty

[fU] Re: [fU-cvs] libfunutil/doc/api Makefile.bt,1.3,1.4

[Rusty B. <ho...@sb...>]

> > hmm, buildtool doesn't like it when some parts of the glob aren't
> > present??
> > +GLOB =3D html/*.html html/*.gif html/*.css
>
> Or try:
> GLOB =3D $(wildcard ...)
>
> but this can have has side-effects which the list of files to be globbe=
d
> is not created until after GLOB is processed.

Well, I think the buildtool makefiles are not GNU make. :)=20
($(wildcard ...) is a gmake extension, right?)  I think there are
ways to do it in buildtool by shelling out to ls... (which seems less
desirable than a builtin like $(wildcard), which is why gmake is
nice...)

(When you run doxygen on your box, do you get .png's?)

--Rusty

Re: [fU] approaching impact

[stephan b. <st...@ei...>]

On Friday 05 September 2003 07:55, Rusty Ballinger wrote:
> > Well, what I did instead was fiddle with getting an RPM target
> > (which works now...
>
> One thing which doesn't seem to work is whatever's supposed to strip
> the binaries during the packaging process.  libfunUtil.so goes from
> like 3.5MB to 300K if you strip it after installing the RPM package.
>

It used to work and i removed it because i once tried to link to 
libfunutil.a and it was devoid of symbols. i suspect, though i haven't 
bothered to try to prove it, that it's okay to strip a .so without 
suffering this side-effect.

In fact, in the toc tree i've changed the way libs are handled, partly 
because of this point. It is now as follows:

INSTALL_LIBS go to $prefix/lib and are not stripped
INSTALL_LIBEXECS also go to prefix/lib (instead of prefix/libexec, for 
reasons explained in install.make), but are mode 0755.

(note, though, that fun's tree isn't updated to that state yet.)

-- 
----- stephan
st...@ei... - http://www.einsurance.de
"...control is a degree of inhibition, and a system which is perfectly
inhibited is completely frozen." -- Alan W. Watts

Re: [fU] approaching impact

[Rusty B. <ho...@sb...>]

> > So I *will* make that API change in ClassLoader (there are only 2 or
> > 3 places), "and *then* it'll be ready for qub."
>
> This is done.

well, quadruple backflip bozo award for me this evening:

  void f1(QString &s) { }
  void f2(const QString &s) { }

  int main()
  {
      f1(QString());  //  doesn't compile!?
      f2(QString());  //  does compile
      QString s;
      f1(s);  //  does compile, of course
      return 0;
  }

So I was looking in the C++ ARM to figure out whether that's correct,
and in my copy, on page 308, someone has scribbled the words "RUSTY
YOU ARE A BOZO" in handwriting which is remarkably similar to mine.

Very strange.

But I did find on page 146 the bit which proves I'm not a *total*
bozo: "In early versions of C++ where temporaries were allowed as
initializers for non-const references..."  Ha ha ha, and on page 155:
"Naturally, this feature will be faded out of implementations
slowly..."

Anyway, I guess I'll be fixing tonight's changes tomorrow...

--Rusty

Re: [fU] approaching impact

[Rusty B. <ho...@sb...>]

> So I *will* make that API change in ClassLoader (there are only 2 or
> 3 places), "and *then* it'll be ready for qub."

This is done.

--Rusty

Re: [fU] approaching impact

[Rusty B. <ho...@sb...>]

> Regarding API changes, one thing which occurred to me is that where I
> was turning this:
>
>     QString getSomeString();
>
> into this:
>
>     #if FUN_API_QSTRING
>     void getSomeString(QString &);
>     #endif
>     #if FUN_API_STD_STRING
>     void getSomeString(std::string &);
>     #endif
>
> that's not really necessary; I could make it
>
>     #if FUN_API_QSTRING
>     QString getSomeString();
>     #endif
>     #if FUN_API_STD_STRING
>     void getSomeString(std::string &);
>     #endif
>
> which is a little better because it doesn't affect the QString
> version.  So I think I'll go back & do that in ClassLoader, and
> *then* it'll be ready for qub.

No, that's a stupid idea; it means if you want to switch between
QString and std::string in your code, there's one more place you have
to make changes.  On my first pass at updating QUB with the API
changes, I wished I'd changed this:

    QString getSomeString();

into this:

    #if FUN_API_QSTRING
    QString getSomeString(QString &);
    #endif
    #if FUN_API_STD_STRING
    std::string getSomeString(std::string &);
    #endif

because then code which used to be this:

    QString myString =3D getSomeString();

can change to this:

    QString myString =3D getSomeString(QString());

instead of this:

    QString myString;
    getSomeString(myString);

So I *will* make that API change in ClassLoader (there are only 2 or
3 places), "and *then* it'll be ready for qub."

--Rusty

Re: [fU] approaching impact

[Rusty B. <ho...@sb...>]

> Well, what I did instead was fiddle with getting an RPM target (which
> works now...

One thing which doesn't seem to work is whatever's supposed to strip
the binaries during the packaging process.  libfunUtil.so goes from
like 3.5MB to 300K if you strip it after installing the RPM package.

--Rusty

Re: [fU] approaching impact

[Rusty B. <ho...@sb...>]

> Anyway, I will be offline until Tuesday night, but will see what I
> can get done without being too antisocial at Syndi's parents' house.
> (If I get anything done, I will focus on documentation in libfunUtil,
> source changes in qub, and *maybe* getting qub to work with
> buildtool

Well, what I did instead was fiddle with getting an RPM target (which
works now... by God I hate RPM), because I didn't want to "make
install" into /.

The nice thing about going through RPM (or, more specifically, about
having the headers & libs installed in /usr/include & /usr/lib) is
that I was able to fiddle with building qub without messing with the
configure script much.

Regarding API changes, one thing which occurred to me is that where I
was turning this:

    QString getSomeString();

into this:

    #if FUN_API_QSTRING
    void getSomeString(QString &);
    #endif
    #if FUN_API_STD_STRING
    void getSomeString(std::string &);
    #endif

that's not really necessary; I could make it

    #if FUN_API_QSTRING
    QString getSomeString();
    #endif
    #if FUN_API_STD_STRING
    void getSomeString(std::string &);
    #endif

which is a little better because it doesn't affect the QString
version.  So I think I'll go back & do that in ClassLoader, and
*then* it'll be ready for qub.

--Rusty

Re: [fU] lib symlinks in install?

[Rusty B. <ho...@sb...>]

> > Hey, "make install" doesn't give me symlinks to the created .so.
> > Does that sound like something I've got broken in my local tree?
>
> Can't reproduce :(

Hmm, I just checked in support for an "rpm" target, and *that* does a
"make install", and the symlinks are created correctly there, so it
must be working.  No idea what the problem was, but I'm not going to
worry about it.

--Rusty

Re: [fU] lib symlinks in install?

[stephan b. <st...@ei...>]

On Thursday 04 September 2003 13:10, Rusty Ballinger wrote:
> Hey, "make install" doesn't give me symlinks to the created .so. 
> Does that sound like something I've got broken in my local tree?

Can't reproduce :(

Installing/symlinking 
/home/stephan/cvs/libfunutil/build/lib/libfunUtil.so.0.7.999
ln -fs libfunUtil.so.0.7.999 libfunUtil.so
ln -fs libfunUtil.so.0.7.999 libfunUtil.so.0
ln -fs libfunUtil.so.0.7.999 libfunUtil.so.0.7
stephan@cheyenne:~/cvs/libfunutil> l build/lib/
total 11279
drwxr-xr-x    2 stephan  users         224 2003-09-04 14:18 .
drwxr-xr-x    6 stephan  users         144 2003-09-04 14:18 ..
-rw-r--r--    1 stephan  users     7867932 2003-09-04 14:18 libfunUtil.a
lrwxrwxrwx    1 stephan  users          21 2003-09-04 14:18 
libfunUtil.so -> libfunUtil.so.0.7.999
lrwxrwxrwx    1 stephan  users          21 2003-09-04 14:18 
libfunUtil.so.0 -> libfunUtil.so.0.7.999
lrwxrwxrwx    1 stephan  users          21 2003-09-04 14:18 
libfunUtil.so.0.7 -> libfunUtil.so.0.7.999
-rwxr-xr-x    1 stephan  users     3674431 2003-09-04 14:18 
libfunUtil.so.0.7.999

A 'cvs status' shows that i've got no uncommitted changes.

i've made a couple changes to the install/subdirs/clean handling over 
the past 2 days, but none of that is in the fun tree yet.

-- 
----- stephan
st...@ei... - http://www.einsurance.de
"...control is a degree of inhibition, and a system which is perfectly
inhibited is completely frozen." -- Alan W. Watts

Re: [fU] lex-based SerialTree text format parser underway :)

[stephan b. <st...@ei...>]

Thursday 04 September 2003 14:01, stephan beal wrote:
> Attached is the lex input. It won't compile as-is because it needs
> some external code, but it'll give you and idea of how simple it was.
> i will proactively admit that it may contain any number of lex
> faux-pas (faux-pi?), as it is my very first lex work.

Sample output from gev.map:
~/cvs/elib/lex> time ./ltest --e-ENm=enm < gev.map > foo
main.cpp:326 : 701 nodes traversed.
real    0m0.380s
user    0m0.310s
sys     0m0.070s
stephan@cheyenne:~/cvs/elib/lex> less foo
main.cpp:160 : 1 Opening new node [fun::HexMap[elib::EPropertyList],map]
main.cpp:133 : 1   map: add_property(gameboxName,G.E.V.)
main.cpp:133 : 1   map: add_property(gameboxVers,0.1)
main.cpp:133 : 1   map: add_property(asiz,529)
main.cpp:160 : 2     Opening new node [GEVHex[elib::EPropertyList],area]
main.cpp:133 : 2       area: add_property(name,0101)
main.cpp:133 : 2       area: add_property(id,0)
main.cpp:177 : 2     Closing node [GEVHex,area]
main.cpp:160 : 2     Opening new node [GEVHex[elib::EPropertyList],area]
main.cpp:133 : 2       area: add_property(name,0102)
...
ad nauseum...
...
main.cpp:160 : 2     Opening new node 
[fun::HexNumberStyle[elib::EPropertyList],xstyle]
main.cpp:133 : 2       xstyle: add_property(first,01)
main.cpp:133 : 2       xstyle: add_property(ascending,true)
main.cpp:133 : 2       xstyle: add_property(numeric,true)
main.cpp:177 : 2     Closing node [fun::HexNumberStyle,xstyle]
main.cpp:160 : 2     Opening new node 
[fun::HexNumberStyle[elib::EPropertyList],ystyle]
main.cpp:133 : 2       ystyle: add_property(first,01)
main.cpp:133 : 2       ystyle: add_property(ascending,true)
main.cpp:133 : 2       ystyle: add_property(numeric,true)
main.cpp:177 : 2     Closing node [fun::HexNumberStyle,ystyle]
main.cpp:177 : 1 Closing node [fun::HexMap,map]

-- 
----- stephan
st...@ei... - http://www.einsurance.de
"...control is a degree of inhibition, and a system which is perfectly
inhibited is completely frozen." -- Alan W. Watts

[fU] lib symlinks in install?

[Rusty B. <ho...@sb...>]

Hey, "make install" doesn't give me symlinks to the created .so.  Does
that sound like something I've got broken in my local tree?

--Rusty

Re: [fU] lex-based SerialTree text format parser underway :)

[stephan b. <st...@ei...>]

On Thursday 04 September 2003 12:23, Rusty Ballinger wrote:
> > i started to learn lex yesterday and i've got a basic parser for
> > the STree text format underway.
>
> I bought the O'Reilly "lex & yacc" book *years* ago, but (obviously)
> never read it, & now I feel like a dumbass for not having used it in
> the first place.

i bought it a few days ago and i feel like a dumbass for reading a 
computer book which is more than 2 years old!

> If you get this working, I will be quite happy to
> throw out my hand-rolled parser.

Attached is the lex input. It won't compile as-is because it needs some 
external code, but it'll give you and idea of how simple it was. i will 
proactively admit that it may contain any number of lex faux-pas 
(faux-pi?), as it is my very first lex work.

i still haven't migrated into yacc yet, but it seems we don't need it 
for the text mode parser.

-- 
----- stephan
st...@ei... - http://www.einsurance.de
"...control is a degree of inhibition, and a system which is perfectly
inhibited is completely frozen." -- Alan W. Watts

Re: [fU] lex-based SerialTree text format parser underway :)

[Rusty B. <ho...@sb...>]

> i started to learn lex yesterday and i've got a basic parser for the ST=
ree
> text format underway.

I bought the O'Reilly "lex & yacc" book *years* ago, but (obviously)
never read it, & now I feel like a dumbass for not having used it in
the first place.  If you get this working, I will be quite happy to
throw out my hand-rolled parser.

--Rusty

[fU] non-Qt text-mode parser and a SerialTree-like prototype

[stephan b. <st...@ei...>]

i've got my lex-based serial-text parser working, including a very 
rudimentary classloader, and it parses the GEV maps wonderfully.

i'm experimenting with a SerialTree-like class which works a bit 
differently. Mainly, instead of children having to be Serializable, 
that type is simply a template type, and the STree can have any number 
of children /of any type/. Each child list gets it's own type, at 
compile time, and the object does some jumping-through-hoops to make 
sure all the various template-based containers are cleaned up when the 
object is destroyed (this one was tricky, though).

Here's a sample of how a mutli-type list is used:

       SerTree tree( "Root" );
        tree.set( "ClassName", "SerTree" );
        SerTree * chtree = 0;
        typedef std::vector<SerTree *> SerTreeList;
        SerTreeList & sertreelist  = tree.children<SerTree>();
        //COUT << "SerTreeList = " << hex << sertreelist << endl;
        chtree = new SerTree( "Tree Named Fred" );
        chtree->set( "bar", "foo" );
        sertreelist.push_back( chtree );
        chtree->set( "foo", "bar" );

        EPropertyList * pchild = new SerTree( "Another Tree Named Fred" 
);
        tree.children<EPropertyList>().push_back( pchild );
// note that we just stuck a SerTree * into the EPropertyList children.

        pchild->set( "thisispchild", "yes" );
        pchild = new EPropertyList( "An EPropertyList" );
        pchild->set( "thisisanotherpchild", "yesyes" );
        pchild->set( "42", 17 );
        tree.children<EPropertyList>().push_back( pchild );

i'll admit that the template parms make it a bit verbose, but it's very 
flexible (and typedefs can clean it up a bit). The core of it is one 
static-only class which can dole out arbitrary containers of pointers 
to type Foo, and maps those containers to a given parent object. This 
means you can add new children type at any time to any object which 
proxies this "container doler-outer".

Note that this unifies the interface for accessing any child list type 
(well, any list of pointers to children), regardless of the underlying 
child pointer type:

   EMTCoP list; // EMTCoP = Multi-Type Container of Pointers
   EMTCoP::iter<FooChild>::list_type & li = 
EMTCoP::children<FooChild>();
   EMTCoP::iter<BarChild>::list_type & li3 = 
EMTCoP::children<BarChild>();   
   EMTCoP::iter<int>::list_type & li4 = EMTCoP::children<int>();
(integral types are untested!)

Your parent container need not know that it will handle these types.
Doing the above will automatically register all entries for each of 
these 3 lists (and the lists themselves) to be destroyed when 'list' is 
destroyed. Alternately, remove the items from the list yourself so 
cleanup is not necessary.

This SerTree is not yet usable - i just threw together a quick 
PropertyList subclass to try it out with. But the concept appears to 
work, so i'm going to experiment with it more.

-- 
----- stephan
st...@ei... - http://www.einsurance.de
"...control is a degree of inhibition, and a system which is perfectly
inhibited is completely frozen." -- Alan W. Watts

Re: [fU] Re: [fU-cvs] libfunutil/tests/funUtil Makefile,1.21,1.22

[stephan b. <st...@ei...>]

On Wednesday 03 September 2003 10:25, Rusty Ballinger wrote:
> > Update of /cvsroot/libfunutil/libfunutil/tests/funUtil
> >
> > +ifeq (1,$(configure_with_buildtool))
> > +DIST_FILES += Makefile.bt
> > +endif
>
> Shouldn't the buildtool files always be included in the dist
> tarball? 


They should, but i couldn't test 'dist' because of the missing data dir, 
so i added this workaround. ;)

Now that data/ is there this block (and another one like it in... i 
forget where) can go away.

-- 
----- stephan
st...@ei... - http://www.einsurance.de
"...control is a degree of inhibition, and a system which is perfectly
inhibited is completely frozen." -- Alan W. Watts

Re: [fU] Re: [fU-cvs] libfunutil/include/fun Makefile,1.4,1.5

[stephan b. <st...@ei...>]

On Wednesday 03 September 2003 09:51, Rusty Ballinger wrote:
> (catching up with mail since last Thursday night)
>
> > Update of /cvsroot/libfunutil/libfunutil/include/fun
> >
> > +INSTALL_PACKAGE_HEADERS = $(wildcard *.h)
>
> Would it work to put "INSTALL_PACKAGE_HEADERS = $(HEADERS)" in
> lib/funUtil/Makefile instead?  I think that would be "safer", as it
> prevents random *.h cruft in include/fun from being installed.

That will work, but you'll need to change on thing:
INSTALL_PACKAGE_HEADERS_DEST = $(prefix)/include/fun
otherwise they'll go to $(prefix)/include/$(PACKAGE_NAME) and #include 
<fun/foo.h> won't work.

i prefer that the install come from the fun dir, but that wasn't 
possible at one early point because i didn't have properly configurable 
INSTALL_XXX vars and  the headers wanted to install to libfunutil, 
which isn't what we want.

So, yes - the preferred way (for me, anyway) would be to do the install 
from the files' homes and not an intermediary dir like include/fun.

-- 
----- stephan
st...@ei... - http://www.einsurance.de
"...control is a degree of inhibition, and a system which is perfectly
inhibited is completely frozen." -- Alan W. Watts

[fU] Fwd: Buildtool 0.13 released

[Rusty B. <ho...@sb...>]

"nuts!"  This is from the buildtool-devel list.  I haven't looked yet
at converting to 0.13.

--Rusty


----------  Forwarded Message  ----------

Hi,

I'm pleased to announce that the 0.13 version of Buildtool has been relea=
sed.
As usual, you can find it in the homepage:

=09http://buildtool.sourceforge.net/

This version means a radical change over the previous ones with respect t=
o
files needed to control a package.  The main highlights include:

* The bt_sh module, an integrated shell interpreter.  This doesn't affect=
 you
  directly, but you won't have to care about shell portability any more ;=
)

* The buildtool.d directory is no longer recognized.  Buildtool will now =
use
 a single file, Generic.bt, placed in the top level directory of your
 project. This file is splitted up into functions, which have similar
 functionality to the independant files.  The conversion is very
 straigforward; see below. You must do this change in your project if you
 want to use 0.13.

* A new make-like tool has been added, bt_logic, which will eventually
  deprecate bt_make (together with bt_logic).  Both systems are kept now,=
 so
  your Makefile.bt files will still work.  Anyway, I recommend you switch=
ing
  to the new Logic.bt files as soon as possible to detect missing
 functionality and bugs.

I know these changes are a PITA.  Therefore, I have written a script that
 tries to convert a 0.12 project to a 0.13 one.  This script will be laun=
ched
 whenever you execute "buildtool <something>" inside a 0.12 project; it w=
ill
 ask you if you want to proceed, and then it will write a new Generic.bt
 file.  You will doubtly have to touch this (except for indentation issue=
s).

OTOH, converting from Makefile.bt to Logic.bt is a bit more difficult.  T=
he
script will tell you what to do (run "buildtool make tologic") when it's =
time
 to do so, but the conversion may lack some details.  If you have only us=
ed
 standard features, it should be able to do an accurate conversion.

As examples of Logic.bt files, you can check out the testsuite or the
 buildtool-doc package.  Both have been converted to the 0.13 framework.

The main problem maybe is that there is no real documentation for bt_logi=
c
 yet; it is likely to change in some aspects, so writting good docs now c=
ould
 be silly. Anyway, the distribution comes with a file, bt_logic/NOTES, th=
at
 includes several notes with respect to bt_logic.  If you know makefiles,=
 you
 should be able to switch your mind easily.

I've decided to release 0.13 now so that developers using it for their ow=
n
projects can start migrating them to the new framework, if possible.  If =
this
can't be accomplished by some feature missing in the actual code, it can =
be
easily (and sooner) introduced in the next version.  As soon as people ca=
n
migrate their own projects to the new framework, compatibility will be
 dropped (that is, bt_make and bt_wrap will be removed), thus decreasing
 Buildtool's size by around a 45%.

At last, the actual codebase has been tested in NetBSD, Solaris, Darwin,
Gentoo Linux and Debian Linux, and all portability issues have been hopef=
ully
fixed (aside from shared library building, which is still in the TODO).

If you have any trouble in the conversion, please let me know.  Suggestio=
ns
 and bug reports will be welcome too.

Good luck!

[fU] Re: [fU-cvs] libfunutil/tests/funUtil Makefile,1.21,1.22

[Rusty B. <ho...@sb...>]

> Update of /cvsroot/libfunutil/libfunutil/tests/funUtil

> +ifeq (1,$(configure_with_buildtool))
> +DIST_FILES +=3D Makefile.bt
> +endif

Shouldn't the buildtool files always be included in the dist
tarball?  That way, even if the person building the tarball never
uses buildtool, the people who download that tarball can.  (I haven't
looked at any other --with-buildtool changes, but I assumed that if
you were using toc's configure script, you'd be using toc throughout
& would have nothing to do with buildtool, but the buildtool files
should still tag along in the dist tarball, for other people to use.)

--Rusty

[fU] Re: [fU-cvs] libfunutil/include/fun Makefile,1.4,1.5

[Rusty B. <ho...@sb...>]

(catching up with mail since last Thursday night)

> Update of /cvsroot/libfunutil/libfunutil/include/fun

> +INSTALL_PACKAGE_HEADERS =3D $(wildcard *.h)

Would it work to put "INSTALL_PACKAGE_HEADERS =3D $(HEADERS)" in
lib/funUtil/Makefile instead?  I think that would be "safer", as it
prevents random *.h cruft in include/fun from being installed.

--Rusty

Re: [fU] lex-based SerialTree text format parser underway :)

[stephan b. <st...@ei...>]

On Wednesday 03 September 2003 04:55, stephan beal wrote:
> (If you're wondering why i at-parse the lex file, it's because @WORD@
> is much asier to read and write than ([_a-zA-Z0-9]+), an @CLASSNAME@
> can now be mapped to: (@WORD@\:\:)?@WORD@

/smack forehead/. If i had spent 10 more minutes with the manual i would 
have learned that lex can do such symbolic substitution already. :/


-- 
----- stephan
st...@ei... - http://www.einsurance.de
"...control is a degree of inhibition, and a system which is perfectly
inhibited is completely frozen." -- Alan W. Watts

[fU] text-mode parser: it's alive!

[stephan b. <st...@wa...>]

It works on basic inputs now, plus extends the format to include optional=
 =3D=20
signs between keys and values:


map class=3DYetAnotherNoopClass
{
        gameboxName=3DG.E.V.
        gameboxVers 0.1
        foo class=3Delib::NoClass
        {
                x novalue
                z true
        }
        asiz  =09=3D=09  529
        strval "this is a string"
# (doesn't handle multi-line string yet)

}

Will do the following:

main.cpp:52 : 1 Opening new node [YetAnotherNoopClass,nodename=3Dmap]
main.cpp:40 : 1 map: add_property(gameboxName,G.E.V.)
main.cpp:40 : 1 map: add_property(gameboxVers,0.1)
main.cpp:52 : 2     Opening new node [elib::NoClass,nodename=3Dfoo]
main.cpp:40 : 2     foo: add_property(x,novalue)
main.cpp:40 : 2     foo: add_property(z,true)
main.cpp:65 : 2     Closing node [elib::NoClass,foo]
main.cpp:40 : 1 map: add_property(asiz,529)
main.cpp:40 : 1 map: add_property(strval,"this is a string")
main.cpp:65 : 1 Closing node [YetAnotherNoopClass,map]

The amount of lex code is remarkably small, and of course i made a toc sn=
ippet=20
to process them for me :).

So... with this, if we will move the load/save functions out of SerialTre=
e's=20
immediate interface, i can have a format-compatible text-based de/seriali=
zer=20
ready which doesn't need any libs other than libfl. :) i'm using flex's C=
++=20
interface because it allows easy redirection from/to streams, so it's=20
possible to use stringstreams (instead of just C-style FILE *).


--=20
----- st...@wa...
http://qub.sourceforge.net  http://libfunutil.sourceforge.net        =20
http://toc.sourceforge.net  http://countermoves.sourceforge.net
http://stephan.rootonfire.org

[fU] lex-based SerialTree text format parser underway :)

[stephan b. <st...@wa...>]

i started to learn lex yesterday and i've got a basic parser for the STre=
e=20
text format underway. It doesn't handle strings with spaces in them, but=20
here's what it does to the top of gev.map:

stephan@ludo:~/cvs/elib/lex >make && ./ltest < gev.map | head
Generating C_DEPS rules for *.cpp *.c *.c++ *.C *.cc *.moc
toc_atparse_file: test.flex is up to date.
Building C[++] binary [ltest].
+ cc -I. -I../include -o ltest main.cpp test.flex.cpp -lstdc++=20
=2E./lib/elib/libessentials.a -lfl
main.cpp:46 : Opening node [fun::HexMap]
main.cpp:38 : [fun::HexMap] add_property(gameboxName,G.E.V.)
main.cpp:38 : [fun::HexMap] add_property(gameboxVers,0.1)
main.cpp:38 : [fun::HexMap] add_property(asiz,529)
main.cpp:46 : Opening node [GEVHex]
main.cpp:38 : [GEVHex] add_property(name,0101)
main.cpp:38 : [GEVHex] add_property(id,0)
main.cpp:46 : Opening node [GEVHex]
main.cpp:38 : [GEVHex] add_property(name,0102)


(If you're wondering why i at-parse the lex file, it's because @WORD@ is =
much=20
asier to read and write than ([_a-zA-Z0-9]+), an @CLASSNAME@ can now be=20
mapped to: (@WORD@\:\:)?@WORD@
(i just added the ability to recursively @-parse tokens, so @-tokens can =
now=20
expand to other @-tokens.)

i don't yet know enough about lex to know if i'll need to also use yacc/b=
ison=20
to properly handle keys like:
    foo "this is a quoted string, \
          possibly multi-line."


--=20
----- st...@wa...
http://qub.sourceforge.net  http://libfunutil.sourceforge.net        =20
http://toc.sourceforge.net  http://countermoves.sourceforge.net
http://stephan.rootonfire.org

[fU] toc & cygwin

[stephan b. <st...@wa...>]

After #ifdefing out some signal handling code i was able to build elib us=
ing=20
toc under cygwin. :)

This means, and this hadn't occured to me until a minute ago, that if we =
can=20
eliminate the Qt code from libfun we can get it running under cygwin. :)

As far as toc was concerned, i only had to add a running_under_cygwin tes=
t.


--=20
----- st...@wa...
http://qub.sourceforge.net  http://libfunutil.sourceforge.net        =20
http://toc.sourceforge.net  http://countermoves.sourceforge.net
http://stephan.rootonfire.org

[fU] added option: --help-X

[stephan b. <st...@ei...>]

Added test: toc_tests_help:

It looks for --help-X. If none are found it exits with zero.
If any are found it looks in the X test for a block like this:

# toc_begin_help =
# This test does something amazing!
# It shows how to use --help-X!!!
# = toc_end_help

If it finds such text it outputs it like so:

==1== test: [toc_tests_help] checks for --help-X and tries to do 
something about it.
help: gnu_cpp_tools
    It takes the following configure arguments:
    --enable-debug    causes stuff to be built -g instead of -02.  This 
is a
    little weird, but you can control the optimization level
    with --enable-debug="-O3 -fno-inline" etc.
    --enable-warn     causes stuff to be built -Wall.  To turn on 
-Werror, go
    --enable-warn="-Wall -Werror" etc.

    It calls toc_add_make for the following:
    - CC         /path/to/gcc?
    - INCLUDES   probably empty
    - CPPFLAGS   probably empty
    - OPT        -g or -O2 (or some other value specified by 
--enable-debug)
    - WARN       -Wall (or some other value specified by --enable-warn)
    - CFLAGS     probably empty (or maybe -pipe)
    - CXXFLAGS   probably empty (or maybe -pipe)
    - LDFLAGS    probably empty


If it finds any help vars it returns 1, the assumption being that you 
don't want to continue if the user used --help.

(FYI, the 1 in "==1==" is the current test nesting level.)

TODO: add support for --help-tests, which shows help for all tests.

-- 
----- stephan
st...@ei... - http://www.einsurance.de
"...control is a degree of inhibition, and a system which is perfectly
inhibited is completely frozen." -- Alan W. Watts