[Push] Push3 in C++

[Maarten]

Hi John,

first off, I think bugs to the C++ version could best be posted to 
the sourceforge site. It's got a bug list. As for the issues with 
autom4te.cache and FloatInstructions.cpp, these are resolved in the 
cvs now, I think. If stuff still barfs, try regenerating everything 
using:

aclocal
automake
autoconf

in sequence.

As for the pushgp_int problems. Hmm. I shouldn't have added highly 
experimental code there I guess. What goes wrong is that I try to 
dynamically get a grip on the computational effort for the problem, 
which is flaky at the moment. At best. Maybe change the code a bit 
(I'll update that to cvs as well when I get around to it). In 
evaluate in pushgp_int.cpp, search for 'env.go'. Instead of the 
max_effort I have put there, put env.parameters.pusheval_limit in 
its place (it's behind it but commented out). Right after that, 
there's another check if the piece of code exceeded this max_effort 
limit. You can put the same env.parameters.pusheval_limit there. 
That should take care of it. The limit can be set in the 
configuration file. I'm currently toying around with this, so I 
can't really change it as we speak. (will do shortly though).

I'm still looking for ways to create a true 'pushgp' where the 
fitness cases are entered through a push progra, but that has to 
wait as well, together with a scheduler for doing time-sliced 
execution. 

Hope this helps,

-Maarten-



On Saturday 14 August 2004 00:06, John Truesdale wrote:
> Hi Maarten and Lee:
>
> First of all where should I be posting messages regarding bugs
> and code type issues.  Is there a developers list or anything
> like that or do want to see coding issues brought up on this
> list?  Until I hear differently I'll be posting here.  Now on to
> push3++ issues.
>
> Checked out the model via cvs into a new directory and tried to
> configure it. It balked at something to do with autom4te.  I was
> able to remove autom4te.cache directory (probably cached data for
> Maarten's machine) and on the next try it recreated the
> autom4te.cache directory.  After that I was able to configure and
> build the model correctly.  I'm not sure that removing the
> directory was the best way to solve the problem but you should
> look into that and make sure the CVS repository doesn't contain
> any autoconf cached information.
>
> The model compiled correctly but I didn't notice any speed up for
> Instructions.cpp.  I was now able to run the example program as
> expected.  I started pushgp_int before I left last night and much
> to my suprise when I checked in this morning it looked to be hung
> or stuck in some type of loop.  No output to the screen but still
> chewing up lots of processor time.  It ran for a long time before
> I left to go home but hung sometime during the night. I'm still
> just going through the papers for push3 but I thought there was
> some safeguards against this type thing.  Do your gp runs hang
> occasionally?
>
> Next I tried to update my cvs distribution and sure enough some
> new files did show up.  It looked like the new files created from
> splitting Instructions.cpp.  I'm not sure what happened during my
> first checkout of push3.  I seemed to get some of the files that
> made the example program run correctly but somehow missed the
> newly created xxxInstructions files. Unfortunately it still looks
> as though the CVS repository is still missing the
> FloatInstructions.cpp file as the compile dies with the following
> error.
>
> make[2]: *** No rule to make target `FloatInstructions.cpp',
> needed by `FloatInstructions.lo'.  Stop.
>
> Could you add and commit that file to the CVS repository?
>
> Thanks
>
> jt
>
> On Fri, 13 Aug 2004, Maarten wrote:
> > On Thursday 12 August 2004 23:58, John Truesdale wrote:
> > > Hi Maarten, Lee, pushers and spammers galore:
> > >
> > > 2) Compile times and memory usage for this code are a little
> > > high. Compile time on a xeon (2.8Ghz-2Gb) was about 20
> > > minutes. Memory usage by gcc with default optimization was
> > > around 200 Mb. Maarten says the autoconf stuff could use a
> > > little work and I may start there just to cut the build time
> > > down.
> >
> > I'm still looking into the double build that goes on. It seems
> > that on the linux platform it builds two types of object files,
> > one for the shared library and one for the static one. Not sure
> > if there's an easy workaround for that. Will look at source
> > code optimizations though.
> >
> > > 3) The examples directory contain some test executables but
> > > they require a configuration file (test.config) which is
> > > missing. Hopefully you can help out here Maarten.  Even if
> > > you have a sample config file that is probably enough to get
> > > me going.
> >
> > (have sent the files through personal email).
> >
> > Woops, forgot to include these in the distribution. Apparently
> > didn't test it properly. I've just uploaded a new release that
> > fixes these problems.
> >
> > > 4) The test directory contains a pushtest executable but
> > > again no driver to run tests of basic push functionality.  Is
> > > there something similar to the run_tests.sh that you provided
> > > with previous versions?
> >
> > Again an oversight in the distribution. You should now be able
> > to say: 'make check' for testing the thing. If all goes well
> > you won't see a thing happening (pushtest will execute a push
> > program and quit silently when the top of the boolean stack is
> > true at the end of execution. Kind of like an assert).
> >
> > > 5) When I build the executables, autoconf/libtool is placing
> > > a wrapper script into the directory and putting the
> > > executable in a .libs directory.  The wrapper script says
> > >
> > > # pushgp_int - temporary wrapper script for .libs/pushgp_int
> > > # Generated by ltmain.sh - GNU libtool 1.5a (1.1240
> > > 2003/06/26 06:55:19) #
> > > # The pushgp_int program cannot be directly executed until
> > > all the libtool # libraries that it depends on are installed.
> > >
> > >    Maarten, do you know what its talking about.  What
> > > libraries need to be installed?  I installed the push
> > > libraries updated my LD_LIBRARIES_PATH and tried to rebuild
> > > some of the executables but it keeps generating the wrapper
> > > files.  What am I missing?
> >
> > It expects the stuff to be installed through 'make install'.
> > With 'configure --prefix=/some/location' you can determine
> > where it installs it (and luckily, also 'make uninstall'
> > works).
> >
> > This is caused by the difficulties of having shared libraries.
> > For debugging, what I usually do is run the true executable
> > found in:
> >
> > examples/.libs/pushgp_int
> >
> > and set my LD_LIBRARY_PATH to
> >
> > src/.libs
> >
> > That usually does the trick. After the stuff is installed the
> > wrapper is no longer necessary/used.
> >
> > > 6)  What is the status of the boost files in the
> > > distribution? Ideally it would be nice to link to a boost
> > > library.
> >
> > It's a fairly recent boost distribution (I took it from my
> > debian unstable box). Given the license of boost I can
> > incorporate it this way. Actually way too much is included as I
> > only need the shared_ptr. But you know with c++, this includes
> > that and that includes this again, so I just added most of it.
> > I will keep the thing up to date with the moving target that is
> > the boost library. I just assumed that most people wouldn't
> > have it installed, and didn't like them having to hunt it down.
> > I hate it when that happens.....
> >
> > > 7)  Thank you Lee and Maarten for putting the code out there.
> > > Hopefully I'll be able to contribute.
> >
> > Thanks for this, this already helps a lot.
> >
> > -Maarten-
> >
> >
> > _______________________________________________
> > Push mailing list
> > Push at lists.hampshire.edu
> > http://lists.hampshire.edu/mailman/listinfo/push
>
> _______________________________________________
> Push mailing list
> Push at lists.hampshire.edu
> http://lists.hampshire.edu/mailman/listinfo/push