Lisp plugin

OK. It seems that what I really need is a Lisp "front-end". It seems that breve needs a complete recompile to add a new language front-end, because of some callbacks that must be added.

Compilation is quite cumbersome, however. Could someone please state what environment is best suited to compile the beast?

I'am currently using the following:

mingw 5.0.2 (gcc 3.4.2, bison 2.0)
ode 0.6
glut 3.7.6
gsl 1.8
expat 2.0.0
ptheradlib 2.7.0
zlib 1.2.3

wich ends up with a lot of errors, ending with:

"d:/prog/breve/trunk/breve/steve/steveFrontend.cc:221: undefined reference to `lineno'
steve/steveFrontend.o(.text+0x1232):d:/prog/breve/trunk/breve/steve/steveFrontend.cc:222: undefined reference to `yyfile'
collect2: ld returned 1 exit status
make: *** [bin/breve_cli.exe] Error 1"

Hi there,
those symbols are supposed to be defined by code generated by bison and flex. First I would check that both of those programs are up to date.

That code is used for reporting the filename and line where an error occurred, but in the interest of getting it compiled, you can actually comment those lines out without any real trouble, I think.

- jon

I have programmed a 'lisp-like' stack machine. But because it is only used in a very own project it is not suited for parsing real lisp expressions. I only use it to transfer GP individuals via network and to execute them.
The next disadvantage is that currently there is no way to externally define functions, so all tokens/functions are specified internally within the plugin.

so what can it not do:
Execute a real lisp expression with things like cdr etc..

what can it do:
tokenize an expression like : ( add( sub( 10 sleep(23) 77) ) into functions and constants and use a thing called StackMachine to calculate them with taking care of sideeffects (like the sleep in the example)

OK. Then perhaps just sending sensor/motor signals (in practice function arguments and results) over the network would be sufficient. Perhaps it could even be an advantage, as the Lisp process and Breve could be run on (many)different macines. This may more than outweight the loss of performance introduced by network overhead (I hope).

I tried the following using Steve:

PhysicalControl : SimulationWorld {
 + variables:
     networkServer (object).
    ...

 + to init:
    ...
     networkServer = new NetworkServer.
     networkServer listen on-port 8000.

 + to do-nothing:
    return "nothing done".

This effectively locks up breve when the "do-nothing" method is called from a browser (e.g. GET'ting http://server:8000/do-nothing). If I pause the simulation before calling the method, it works though (the result, "nothing done", is sent back to the web-browser). Is there something I am missing here?

Then perhaps my plugin suits for you. It would be quite useful to know what you are planning to do. In case of my project I am creating Genetic Programming individuals via an external Java-Kernel. This is send over the network to the breve engine. The NetworkServer class is not usefull for my purpose because of its restrictions to accept parameters: You can't transfer all kinds of symbols (used in my S-Expressions) or some other more complex stuff (from an external application). So I wrote a TCP/IP-server by myself which starts in an own thread accepting and delegating String-commandos to breve. You are right that this enables you to have a clean distinction between the simulator and any kind of commando-server which can run on a remote machine. If you are thinking about performance just let the commando server run on the same machine using the socket communication. For the far most applications this will be fast enough and you don't have any internet-delay.

But I do not understand your code suggestion, especially the do-nothing method. I think the decision is quite easy: If you can control your simulation program with some method-calls which only need some simple integer or floating values, the networkServer-class will do it for you. If you experience restrictions you will need something like my String-Server.

Quote:It would be quite useful to know what you are planning to do.

I am to use a GA to develop parts of a creatures' sentral nerve system (an artificial neural net, that is). The creature itself will have a fixed form, and fixed sensors and motors. Therefore, simple numeric value passing between the processes is sufficient in my case, as long as it is very fast.

Quote:But I do not understand your code suggestion, especially the do-nothing method.

Regarding the "do-nothing" method, I just wanted to show some code that locks up Breve if a method is called when a simulation is not paused. Why is this so?

Hmm, I never used the Network class. Does the method call locks up breve completely or only for the time the method is evaluated?

Quote:Does the method call locks up breve completely or only for the time the method is evaluated?
Completely (or well, the method is perhaps never evaluated). Try this if you like:

@use Abstract.
@use NetworkServer.
@use PhysicalControl.

Controller SimulationWorld.

PhysicalControl : SimulationWorld {

    + variables:
        networkServer (object).
        
    + to init:
        networkServer = new NetworkServer.
        networkServer listen on-port 8000.
        
    + to do-nothing:
        return "nothing done".
}

Sorry to reply myself here, but it seems that this problem only applies to the current (Windows only perhaps?) version of breve.

I tried running the simuluation using CLI-breve (http://www.spiderland.org/breve/download/breve_windows_2.4.zip) and that works as intended.

I currently tried it and can only support your bug report: Breve 2.5d1 WinXP hangs up when the network call is made. It really looks like a http-protocol error, I am only wondering why my browser does not get a timeout.

Hey guys,
just a reminder that breve 2.5d is a development build with no guarantees on it, so there are bound to be these sorts of problems. It's definitely a good idea to test your code out with both 2.4 and 2.5d.

All in all, though, the networking code has gotten a lot of work since 2.4 and should be in much better shape when 2.5 officially rolls out.

- jon

Sorry if I was unclear in my wording here. By "current" I meant the version currently for download from the breve page (named "breveIDE 2.4 for Windows"). The CLI version works though.