Re: [simspark-devel] PAL_draft

[Joschka B. <jos...@am...>]

Hi,

On Oct 23, 2008, at 4:34 AM, Hedayat Vatankhah wrote:

> Hi,
>> Hmm, in that case, we should think about whether PAL is really the
>> best choice for us. We could only take it as an inspiration and
>> implement our own, hopefully more complete, abstraction for the
>> engines we would like to integerate (ODE, Bullet, and PhysX in my
>> case). What do you think?
> I'm not sure, maybe Ben knows better than me now. What do you think  
> Ben?
> I think we should try to reuse the available code as much as  
> possible; but in that case I think we should feel free to modify PAL  
> as we wish. So, we will probably come up with a derivation of PAL  
> inside our project or (depending on the PAL developer) we will  
> essentially develop PAL alongside our project.
>

Yes, this would be a possibility. I just thought, if PAL restricts us  
too much and we don't need to take care of integrating that many  
different engines, it might be easier for us to develop something on  
our own. But I agree that we should take advantage as much as possible  
of what's there already.

>
> "Zigorat Team" <zig...@gm...> wrote on 10/21/2008 12:37:06 AM:
>> Hi all
>>
>>   I agree with Joschka on restructuring directories and cleaning up  
>> the codes.
> OK, I'll start with a suggestion and some questions. First, my  
> proposed directory structure (still needs work!):
>

Thanks for getting the discussion started :-)

> spark/
>     doc/
>     plugin/
>     kerosin/
>     oxygen/
>     salt/
>     zeitgeist/
>     spark/
>     utility/
>     test/
>         agenttest/

I think agenttest was from the spheres simulator, but I might be  
wrong...

>
>         coretest/
>         ...
>         (test apps)
>     data/
>         rsg/  (including common rsg files like boxspheres/ directory)
>         ros/
>     windows/
>     macosX/

Sounds good.

>
> gendot/
>
> rsgedit/
>     res/
>     doc/

This might become a directory 'gui' inside simspark, but that depends  
on what we decide about the GUI. It seems to me that rsgedit could be  
a good starting point for an integrated GUI, and the ZigoratAssistant  
could replace monitorspark, but we should discuss about that.

>
>
> soccer/     (propose a better name: simspark-soccer,  
> rcssserver3d, ... ?)

Right, we could maybe use rcssserver3d here.

>
>     doc/
>     agentspark/
>     monitorspark/
>     simspark/    (I think we should rename this application,  
> rcssserver3d might be a condidate!)

I would be in favor of keeping simspark: the name has been used in  
several papers, and it's not soccer specific. Since agentspark,  
monitorspark, and simspark, are not soccer specific (we only used them  
for that so far), maybe we should take them out of the soccer  
directory. What do you think?

But then the question is: what should be left in the soccer directory?  
Only the plugins and the data? How about the soccer-specific agent  
behaviors and initialization files for simspark? Difficult... don't  
have a good solution now either :-(

>
>     plugin/
>     data/
>         rsg/
>         ros/
>     linux/
>     windows/
>     macosX/
>
> Now, some questions:
> 1. Are we going to use a new build system (instead of autotools)?

I would be very much in favor of that (for instance using Scons).

>
> 2. Do we want to separate building spark from other apps? Currently  
> in simspark CVS, spark and contrib directories have separate build  
> structures (you should build them independently). This way, we can  
> split the server package to more than one package: a library package  
> (spark directory, creating simspark package), rsgedit package, and  
> rcssserver3d package. But something like gendot is too small, so we  
> may put such small applications in a directory (like contrib/  
> directory in simspark CVS),  maybe with a name such as "simspark- 
> utilities" or  a better name.

This sounds good.

> Another option is to rename spark/test/ to spark/apps/ and put  
> gendot there.
> But if we are going to provide a single package containing all  
> source code,  having one build system for the complete project might  
> be better and is simpler for the users.

That's also true. How about having a complete build system, but  
splitting the packages?

>
> 3. spark's libraries (kerosin, ...) might be moved to spark/lib/ sub- 
> directory!
>

Good idea, I think.

>>   There is a slight problem I've been noticing since a long time  
>> ago, which the ruby files with the options in them, are installed  
>> in typical application installation folder, like /usr/local/bin,  
>> which makes it hard to change the simulators options, as they are  
>> needed. I suggest some of the configuration files be moved to the  
>> local folder of ~/.rcssserver3D/
> I think it's a good suggestion. We can do what is currently done  
> with files such as kerosin.rb: copying the installed configuration  
> files into ~/.rcssserver3D if they don't exist, and using  
> ~/.rcssserver3D files when available.

Sounds reasonable.

Cheers,
Joschka