Re: [simspark-devel] SimSpark Gui, Re-/Initializing Spark

[Hedayat V. <hed...@gm...>]

Hi Patrick,



/*Patrick Geib <Pat...@on...>*/ wrote on Fri, 20 Apr 2012 
13:29:39 +0200:
> Hi,
> Im currently on the finishing line for the project. There are only two 
> things left to do: Loading plugins als dynamic libraries and making 
> the project build like the others (besides, i named the Gui-Core 
> library "Carbon"... Apple cant keep the name forever i hope^^).
> Except for these points the Wiki documentation is quite complete right 
> now (i will add some tutorials and a video introduction to the Gui 
> though).
That's great. Specially that it is documented. :)


>
> The problem with the SimSpark handling was only avoidable, not 
> solveable... At the moment there can only be one instance of SimSpark, 
> so there is only one ruby "context". There is indeed a way to simulate 
> a second ruby context by using a wrapper that forwards every command 
> and access to a namespace in the main context... but this would 
> require a lot of changes in the core libraries... . Anyway, after a 
> few restrictions, this is not the main problem anymore. The only major 
> drawback that remains is that its impossible to reset SimSpark 
> completely so you cannot run different simulations in the Gui without 
> restarting it completely (for example a Soccer Simulation and 
> afterwards a Mars-Rover Simulation).
> I will add an entry to the Wiki that points out which parts of 
> SimSpark would need a rework to make this possible. Sadly, this would 
> be a LOT of parts, because many of the libs and objects are not safely 
> removeable from the Scene Graph.
Thanks for the description, and for adding the info to the wiki.


>
> For the final upload i have two questions:
> 1) I used the most recent C++ standard for my code, which means i for 
> example have double closing template brackets ( 
> "shared_ptr<QList<int>> myList;" ) and used the auto keyword ( " for 
> (auto it = myList.begin(); it != myList.end)=; it++)... " ). If this 
> should be a problem for older compilers i would nee to change this 
> before uploading. I hope w are not using 10years+ old compilers ;) ?
Hmmm... which version of the GCC is the first version which supports both?
Anyway, your code is completely separate from rcssserver3d and simspark, 
right? If it make simspark and rcssserver3d not supporting older 
compilers, it might be considered an issue for a while. Do you know what 
is the first Ubuntu version which supports this syntax? (since most of 
RoboCuppers are using Ubuntu AFAIK). But if it is all new code, I think 
that's fine!


> 2) To be able to control the scripts externally, i changed many of the 
> scripts (for example spark.rb). I added for example log functions in 
> the spark script and made the rcssserver3d script extendable by 
> additional scripts. I could simply upload the changed scripts as 
> replacements for the old ones (in the new branch), or upload both of 
> them with different names. For the default simulation (NaoSoccer) the 
> new versions of the scripts behave just like the old ones so replacing 
> should be no problem.
If it doesn't affect the default simulation, IMHO it is fine to update 
the current scripts.

>
> I hope ill be finished in two weeks and put it in a new branch of the 
> SVN together with the modifications and the Bullet physics 
> implementation of Peter.
It's great to hear that we have Bullet support too! :)

Good luck,
Hedayat

>
> Best Regards,
> Patrick
>
> Am 18.04.2012 21:53, schrieb Hedayat Vatankhah:
>>
>> Hi Patrick,
>>
>> Sorry for the *long* silence about your email. Can I ask what 
>> happened finally? :P
>>
>> Anyway, about the ruby script engine: AFIAK, there are no 'contexts' 
>> there, so all Ruby calls are using the same ruby context. And if I 
>> remember correctly, you should not access it at the same time from 
>> separate threads. Besides, since there is only one context (if it is 
>> correct!), you might be unable to have separate instances of the 
>> system simultaneously (consider if two different instances want to 
>> assign different values to a single variable). Therefore, you might 
>> need to somehow! run different instances of Ruby engine, or maybe 
>> using a 'namespace' concept to create separate contexts for different 
>> instances of the Spark engine inside a single Ruby context. I wonder 
>> if you've already passed this problem! :D And I'm interested to know 
>> about the final solution in that case. :)
>>
>>
>> I'll try to read all the related wiki pages you've created in a few 
>> days. :P
>>
>>
>> Regards,
>>
>> Hedayat
>>
>>
>> /*Patr ick Geib <Pat...@on...>*/ wrote on Tue, 20 Dec 2011 
>> 12:50:00 +0900:
>>> Hi,
>>>
>>> Im continuing on the SimSpark Gui Project but i think i *might* have hit
>>> a roadblock. I hope it is nothing or at least solvable without changing
>>> zeitgeist too much, so heres the problem:
>>>
>>> The Gui is currently designed to start and watch different threads that
>>> might either be internal or external monitors, agents and (one) server.
>>> The concept is meant to define new Simulation Setups containing those
>>> threads, some scripts modifying the execution of the threads (e.g.
>>> loading NaoSoccer etc.) and loading different GuiPlugins for each
>>> Simulation without having to write new compilable projects or edit
>>> script files. So i wrote a more general class SimSpark derived from
>>> Spark (just als those in rcssserver3d etc), where i add resource
>>> locations and scripts at runtime. So far, executing the server as
>>> separate thread in the gui works without a problem.
>>> But now i need to start, stop and/or restart multiple instances of
>>> SimSpark at once or after another, for example restarting the Core or
>>> initializing two SimSpark objects at the same time for a distict server
>>> and a monitor. But zeitgeist crashes when it is initialized again after
>>> being closed, because there are some static properties and leftover
>>> references to the previous Core. While rsgedit avoids this problem by
>>> never actually removing its single Spark instance (but resetting it),
>>> this wont work in my case since i need more than one instance at the
>>> same time. I can seek and replace static references and objects in
>>> zeitgeist, oxygen and kerosin, but i dont know if the script interface
>>> is able to deal with multiple simulation/script servers anyway. In the
>>> ruby wrappers there dont seem to be any distict Ruby-Contexts but only
>>> one single interface. If so, is it possible to wrap the ruby calls
>>> without changing the whole core? Or will the interface work with
>>> different Script-Servers accessing it? I just need to know this before i
>>> attempt to rewrite parts of zeitgeist and oxygen.
>>>
>>> Of course there is the possibility of integrated monitors and agents in
>>> the server itself. But i definitely want to support external processes
>>> and (gui-)internal threads first. When not relying on the direct control
>>> of the core but using the tcp/ip commands first i can cover two kinds of
>>> execution (as thread in the gui, as process observed by the gui) at the
>>> same time. I dont know if i have time to implement both server-internal
>>> and external monitors and agents right away, so i want to stick with the
>>> more important kind. This way, both observing and controlling externally
>>> started processes (rcssagent3d.exe etc..), and integrating them into the
>>> gui to display and debug them in one window would be possible.
>>>
>>> Please tell me if you have some advice on how to deal with the
>>> situation. Also, you might want to have a look at
>>> http://simspark.sourceforge.net/wiki/index.php/Graphical_User_Interface
>>> . If you have concerns ideas and/or wishes, you can always comment or
>>> edit on the project page describing the main features of the gui. It is
>>> meant to be used someday after all, so feedback from those who might
>>> want to use (and extend!) it is always appreciated xD
>>>
>>> Best regards,
>>> Patrick Geib
>>>
>>> ------------------------------------------------------------------------------
>>> Write once. Port to many.
>>> Get the SDK and tools to simplify cross-platform app development. Create
>>> new or port existing apps to sell to consumers worldwide. Explore the
>>> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
>>> http://p.sf.net/sfu/intel-appdev
>>> _______________________________________________
>>> Simspark Generic Physical MAS Simulator
>>> simspark-devel mailing list
>>> sim...@li...
>>> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>