Re: [opensource-dev] State machine class
State machines are very useful, but the use case you gave is an example of a user application that should be coded in an attached script. The fact that the viewer does not yet have attached client-side scripting is not a reason for putting the user application directly into the viewer. It's a reason for adding client-side scripting first. State-switching applications for the viewer would then become trivial to write as a user process, in any language of the user's choice. We were working on such a design for the viewer within AWG many moons ago --- some details are given here, and the many advantages listed: https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft . We were also examining that kind of structure for user scripts in Imprudence: http://imprudenceviewer.org/wiki/Image:Plugin_system_flow_APIs.png . We're long past the refactoring sell-by date for this excessively monolithic client. The viewer is buggy as a direct consequence of its size and bloat --- there is no escaping that relationship in today's seat-of-pants software methodologies. Adding more things into the main code should be avoided at all costs, unless those things are central to its operation. Anything that is not central should be factored out into attached processes, and this is particularly true in the case of any facility that does not have a high speed requirement, such as your example. It would avoid bloat and be much more flexible. The right question to be asking at this stage is why Lindens are currently designing client-side scripting *behind closed doors* in their internal Firefly project. *Secrecy in design should have no place in an open source viewer.* In this instance it impacts directly on your suggestion, since state switching is so easy to do in an attached user script. I believe that Firefly should be stripped of its sekrit internal status and the design addressed here in this opensource-dev community, where it belongs. Given client-side scripting, adding a state machine into the core code would then become moot. Morgaine. == On Thu, Feb 11, 2010 at 4:59 PM, Aleric Inglewood < aleric.inglew...@gmail.com> wrote: > Hi, with the eye on supporting plugins, I'd like to add a 'tool' to the > viewer: > A state machine. > > I'd add a base class from which others can derive their own classes. > A new state machine would then be started by creating one or more objects > of those types. > > It would be a class that supports a chain of asynchronous actions (and > queries). > The object would run in the main thread and be called under the "Idle" > header (fasttimers). > The object will know an 'idle' state (when it's waiting for data) during > which it will > use no significant CPU. > > The user (developer, you) would provide an enum with states for your object > and switch between states by calling a method (ie, set_state(new_state)). > If it is necessary to wait, you can call the idle() method, which will idle > until data is available (detected elsewhere) causing the state machine to > continue the current state. > > As an example, consider a series of actions like walking to a certain > place, > creating a prim there (or rezzing something) and then sitting on it. Or, > wanting > to do some calculation on a number of selected prims (for which you have to > wait till all data of the selected prims has arrived). Well... the > applications are > limitless of course; just what plugins need ;). > > It won't be ALL that is needed for plugins, but it would be a good start, > because > this isn't wirrten/available before someone starts to write something for a > plugin, > the wheel will be reinvented over and over again. > > Any comments? :) > > Aleric > > > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] State machine class
Morgaine, I *completely* agree with you! [?] One of the two main reasons, if not the only two, that we need this state machine approach *is* for client-side scripting and for plugins. Both are infinite flexible in nature and require in principle hooks into the viewer code to *control* the viewer on a level that goes way beyond a blocking function call. The best approach to look at this is the following: If we have to wait for a server packet, it blocks. Currently there is no general way to wait for server-packet-events, hence you *cannot* implement client-side scripting. The state machine is so core and so basic, it's the core at the basis of much MORE code that is needed before you can even start to implement client-side scripting. Thus, since it was always my main goal to use this for client-side scripting (and sorry, but any 'secret' work that I never heard of before from whoever is working on it on this list has to be ignored), I assume you now agree with me that this would a great thing to have, since it will make it possible, in the end to provide hooks into the viewer in The Right Way(tm) that will allow us to write a client-side scripting implementation, which in turn will allow plugins to be able to actually control the viewer. I don't HAVE client-side scripting yet, so I have written code that uses this state machine on a higher level, but that was just to get a feeling of what is needed. I think I'm now ready to write that base class. On Mon, Feb 15, 2010 at 11:29 AM, Morgaine wrote: > State machines are very useful, but the use case you gave is an example of > a user application that should be coded in an attached script. The fact > that the viewer does not yet have attached client-side scripting is not a > reason for putting the user application directly into the viewer. It's a > reason for adding client-side scripting first. > > State-switching applications for the viewer would then become trivial to > write as a user process, in any language of the user's choice. We were > working on such a design for the viewer within AWG many moons ago --- some > details are given here, and the many advantages listed: > https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft . We > were also examining that kind of structure for user scripts in Imprudence: > http://imprudenceviewer.org/wiki/Image:Plugin_system_flow_APIs.png . > We're long past the refactoring sell-by date for this excessively monolithic > client. > > The viewer is buggy as a direct consequence of its size and bloat --- there > is no escaping that relationship in today's seat-of-pants software > methodologies. Adding more things into the main code should be avoided at > all costs, unless those things are central to its operation. Anything that > is not central should be factored out into attached processes, and this is > particularly true in the case of any facility that does not have a high > speed requirement, such as your example. It would avoid bloat and be much > more flexible. > > The right question to be asking at this stage is why Lindens are currently > designing client-side scripting *behind closed doors* in their internal > Firefly project. *Secrecy in design should have no place in an open > source viewer.* In this instance it impacts directly on your suggestion, > since state switching is so easy to do in an attached user script. > > I believe that Firefly should be stripped of its sekrit internal status and > the design addressed here in this opensource-dev community, where it > belongs. Given client-side scripting, adding a state machine into the core > code would then become moot. > > > Morgaine. > > > > > == > > On Thu, Feb 11, 2010 at 4:59 PM, Aleric Inglewood < > aleric.inglew...@gmail.com> wrote: > >> Hi, with the eye on supporting plugins, I'd like to add a 'tool' to the >> viewer: >> A state machine. >> >> I'd add a base class from which others can derive their own classes. >> A new state machine would then be started by creating one or more objects >> of those types. >> >> It would be a class that supports a chain of asynchronous actions (and >> queries). >> The object would run in the main thread and be called under the "Idle" >> header (fasttimers). >> The object will know an 'idle' state (when it's waiting for data) during >> which it will >> use no significant CPU. >> >> The user (developer, you) would provide an enum with states for your >> object >> and switch between states by calling a method (ie, set_state(new_state)). >> If it is necessary to wait, you can call the idle() method, which will >> idle >> until data is available (detected elsewhere) causing the state machine to >> continue the current state. >> >> As an example, consider a series of actions like walking to a certain >> place, >> creating a prim there (or rezzing something) and then sitting on it. Or, >> wanting >> to do some calculation on a number of selected prims (for which you ha
Re: [opensource-dev] State machine class
On Mon, Feb 15, 2010 at 1:15 PM, Aleric Inglewood < aleric.inglew...@gmail.com> wrote: > (sorry, but any 'secret' work that I never heard of before from whoever is > working on it on this list has to be ignored), Just because you haven't heard about something doesn't mean that others haven't. Lindens have mentioned their internal Firefly client-side scripting project at several of their Office Hours now, for example at Q Linden's. While the project name and purpose are known, the details are a closely guarded secret. This is highly inappropriate given that it will determine the structure of the open source viewer to which this list is dedicated. It's treating the opensource-dev community as nothing more than code and debug monkeys, dancing to the LL design tune. That's not a healthy relationship with open source communities. It's also out of step with claims that 2010 is going to see a new openness from Lindens. Firefly is a bad start. Client-side scripting is one of the most crucial features that the community should be discussing, because it will impact on almost everything about the viewer. It's massive. Morgaine. == The most important aspect of any non-trivial software system is its design, since that determines everything else. On Mon, Feb 15, 2010 at 1:15 PM, Aleric Inglewood < aleric.inglew...@gmail.com> wrote: > Morgaine, I *completely* agree with you! [?] > > One of the two main reasons, if not the only two, that we need this state > machine approach *is* for client-side scripting and for plugins. Both are > infinite flexible in nature and require in principle hooks into the viewer > code to *control* the viewer on a level that goes way beyond a blocking > function call. > > The best approach to look at this is the following: If we have to wait for > a server packet, it blocks. Currently there is no general way to wait for > server-packet-events, hence you *cannot* implement client-side scripting. > > The state machine is so core and so basic, it's the core at the basis of > much MORE code that is needed before you can even start to implement > client-side scripting. > > Thus, since it was always my main goal to use this for client-side > scripting (and sorry, but any 'secret' work that I never heard of before > from whoever is working on it on this list has to be ignored), I assume you > now agree with me that this would a great thing to have, since it will make > it possible, in the end to provide hooks into the viewer in The Right > Way(tm) that will allow us to write a client-side scripting implementation, > which in turn will allow plugins to be able to actually control the viewer. > > I don't HAVE client-side scripting yet, so I have written code that uses > this state machine on a higher level, but that was just to get a feeling of > what is needed. I think I'm now ready to write that base class. > > > On Mon, Feb 15, 2010 at 11:29 AM, Morgaine > wrote: > >> State machines are very useful, but the use case you gave is an example of >> a user application that should be coded in an attached script. The fact >> that the viewer does not yet have attached client-side scripting is not a >> reason for putting the user application directly into the viewer. It's a >> reason for adding client-side scripting first. >> >> State-switching applications for the viewer would then become trivial to >> write as a user process, in any language of the user's choice. We were >> working on such a design for the viewer within AWG many moons ago --- some >> details are given here, and the many advantages listed: >> https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft . We >> were also examining that kind of structure for user scripts in Imprudence: >> http://imprudenceviewer.org/wiki/Image:Plugin_system_flow_APIs.png . >> We're long past the refactoring sell-by date for this excessively monolithic >> client. >> >> The viewer is buggy as a direct consequence of its size and bloat --- >> there is no escaping that relationship in today's seat-of-pants software >> methodologies. Adding more things into the main code should be avoided at >> all costs, unless those things are central to its operation. Anything that >> is not central should be factored out into attached processes, and this is >> particularly true in the case of any facility that does not have a high >> speed requirement, such as your example. It would avoid bloat and be much >> more flexible. >> >> The right question to be asking at this stage is why Lindens are currently >> designing client-side scripting *behind closed doors* in their internal >> Firefly project. *Secrecy in design should have no place in an open >> source viewer.* In this instance it impacts directly on your suggestion, >> since state switching is so easy to do in an attached user script. >> >> I believe that Firefly should be stripped of its sekrit internal status >> and the design addressed here in this op
[opensource-dev] retrieving scripts attached to an object
Hi all, as a proof of concept i was creating a floater which instantiated by a button on the Pie Menu in that floater i've created a Button in which i was try to get all inventory items attached to the selected object but, i found that it gives no script items although there're two script files "Note: i didn't open these files just press on New Script" now, sometimes when i opened these files first then press my button it gives results here's my button code: InventoryObjectList inventory_list; object->getInventoryContents(inventory_list); llinfos<<"Loop on inv_objects "< obj=*inv_obj; llinfos<<"Type : "
Re: [opensource-dev] State machine class
On Mon, Feb 15, 2010 at 1:15 PM, Aleric Inglewood < aleric.inglew...@gmail.com> wrote: > Morgaine, I *completely* agree with you! [?] > > One of the two main reasons, if not the only two, that we need this state > machine approach *is* for client-side scripting and for plugins. Both are > infinite flexible in nature and require in principle hooks into the viewer > code to *control* the viewer on a level that goes way beyond a blocking > function call. > > The best approach to look at this is the following: If we have to wait for > a server packet, it blocks. Currently there is no general way to wait for > server-packet-events, hence you *cannot* implement client-side scripting. > > The state machine is so core and so basic, it's the core at the basis of > much MORE code that is needed before you can even start to implement > client-side scripting. > **IFF** a state machine is required infrastructure in the viewer code before client-side scripting can be implemented, then I agree with you wholeheartedly. That claim has not yet been justified though. I would be * very* interested in seeing a design for client-side scripting that is based on a core state machine. The designs that I have been looking at do not require a state machine, because they use a stateless core. All state is maintained in the scripts themselves, and the viewer core doesn't need to be concerned with their state. It's much cleaner because the scripts can use normal blocking calls in normal languages --- all that comes for free with external processes, and benefits automatically from multiple cores. It's not the only way to skin a cat though, so I welcome discussion about alternative approaches. Assuming of course that Lindens open up the design process for client-side scripting in the first place ... Morgaine On Mon, Feb 15, 2010 at 1:15 PM, Aleric Inglewood < aleric.inglew...@gmail.com> wrote: > Morgaine, I *completely* agree with you! [?] > > One of the two main reasons, if not the only two, that we need this state > machine approach *is* for client-side scripting and for plugins. Both are > infinite flexible in nature and require in principle hooks into the viewer > code to *control* the viewer on a level that goes way beyond a blocking > function call. > > The best approach to look at this is the following: If we have to wait for > a server packet, it blocks. Currently there is no general way to wait for > server-packet-events, hence you *cannot* implement client-side scripting. > > The state machine is so core and so basic, it's the core at the basis of > much MORE code that is needed before you can even start to implement > client-side scripting. > > Thus, since it was always my main goal to use this for client-side > scripting (and sorry, but any 'secret' work that I never heard of before > from whoever is working on it on this list has to be ignored), I assume you > now agree with me that this would a great thing to have, since it will make > it possible, in the end to provide hooks into the viewer in The Right > Way(tm) that will allow us to write a client-side scripting implementation, > which in turn will allow plugins to be able to actually control the viewer. > > I don't HAVE client-side scripting yet, so I have written code that uses > this state machine on a higher level, but that was just to get a feeling of > what is needed. I think I'm now ready to write that base class. > > > On Mon, Feb 15, 2010 at 11:29 AM, Morgaine > wrote: > >> State machines are very useful, but the use case you gave is an example of >> a user application that should be coded in an attached script. The fact >> that the viewer does not yet have attached client-side scripting is not a >> reason for putting the user application directly into the viewer. It's a >> reason for adding client-side scripting first. >> >> State-switching applications for the viewer would then become trivial to >> write as a user process, in any language of the user's choice. We were >> working on such a design for the viewer within AWG many moons ago --- some >> details are given here, and the many advantages listed: >> https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft . We >> were also examining that kind of structure for user scripts in Imprudence: >> http://imprudenceviewer.org/wiki/Image:Plugin_system_flow_APIs.png . >> We're long past the refactoring sell-by date for this excessively monolithic >> client. >> >> The viewer is buggy as a direct consequence of its size and bloat --- >> there is no escaping that relationship in today's seat-of-pants software >> methodologies. Adding more things into the main code should be avoided at >> all costs, unless those things are central to its operation. Anything that >> is not central should be factored out into attached processes, and this is >> particularly true in the case of any facility that does not have a high >> speed requirement, such a
Re: [opensource-dev] Fwd: State machine class
That's a very hard-wired approach, and it achieves nothing that cannot be
done much more simply and safely in user scripting processes. When things
go wrong with scripts, you don't want them going wrong in the core viewer.
A bad script running as an external process can simply be terminated ---
that's a much cleaner and safer approach.
What's more, your method handles only the simplest of state scripting
requirements directly, because the state switching conditions will
necessarily be of limited complexity and predefined in C++ code --- the
scripts themselves would have to set up more complex conditional triggers on
the fly by orchestrating multiple sub-states.
That is totally unnecessary, and a weak approach. If you let each script
maintain its own state in the normal manner for sequential programs, and
merely send it the events to which it has subscribed, then the script can
implement arbitrary conditional state switching very simply using
conventional programming.
Morgaine.
On Sun, Feb 14, 2010 at 11:27 PM, Aleric Inglewood <
aleric.inglew...@gmail.com> wrote:
> Ugh, seems this didn't go to the list... forwarding it there.
>
> -- Forwarded message --
> From: Aleric Inglewood
> Date: Mon, Feb 15, 2010 at 12:22 AM
> Subject: Re: [opensource-dev] State machine class
> To: Melinda Green
>
>
> I am already using it :p.
> This proposal is the direct result of practical experience, showing me that
> this is needed.
>
> But before I start to write example code that uses it, allow me to stay
> abstract.
>
> Didn't get much (other) reactions, so I thought I'd add some more details.
>
> The idea is to have objects that go through a series of (usually)
> sequential states:
>
> CONSTRUCTOR
> |
> v
>INIT
> |
> v
> custom states .
> .|
> .|
> .v
> custom states ->ABORT
> ||
> |<---'
> v
>DONE
>
>
> 'CONSTRUCTOR' would be an uninitialized state and never really executed
> (the 'state' variable during construction of the object). Obviously it
> would
> be in balance with it's destructor.
>
> 'INIT' would be the first state of the object when 'run'.
> If the whole finishes successfully, we end up in the state 'DONE',
> which cleanup in balance with INIT, and anything that is expected
> to be left over from going to the states successfully.
>
> The ABORT state is a state that will cleanup anything that might
> be left-over from an abort.
>
> The main thread ''runs' the object from it's 'Idle' state by calling
> gIdleCallbacks.addFunction(...) for this object.
>
> The main loop of such a StateMachine object would then look
> like something like:
>
> switch(mState)
> {
> case INIT:
> init();
> set_state(WAIT_FOR_FOO);
> case WAIT_FOR_FOO;
> if (!foo())
> idle();
> set_state(DO_MORE);
> case DO_MORE:
> do_it();
> set_state(WAIT_FOR_BAR);
> case WAIT_FOR_BAR:
> if (!bar())
> idle();
> set_state(DONE);
> case DONE:
> cleanup();
> }
>
> As you see, this gives a compact and clear code where the flow is intuitive
> (top down), but asynchronus and "blocking", without actually blocking the
> main loop.
>
> One of the major advantages is these objects are reusable; for example, one
> could write an object that checks if some inventory folder exists, if not
> creates it, and then (or when it already exists) waits till it's contents
> are available. Lets call this object SyncFolder(std::string const& name).
>
> Then another StateMachine object can use it (for example) as follows:
>
> class MyStateMachine : public LLStateMachine {
> SyncFolder mSyncFolder;
> ...
> virtual void init();
> virtual void abort();
> virtual void done();
> };
>
> void MyStateMachine::init()
> {
> mSyncFolder.set_name(folder_name);
> }
>
> bool MyStateMachine::mainloop()
> {
> // INIT, DONE and ABORT are handled by the base class.
> switch(mState)
> {
> case WAIT_FOR_FOO:
> if (!foo())
> idle();
> set_state(SYNC_FOLDER);
> case SYNC_FOLDER:
> if (!mSyncFolder()) // Returns true when DONE
> break;
> case REZ_ITEM_FROM_FOLDER:
> do_rez();
> }
> }
>
>
> One could create a large number of such objects that do simple tasks, and
> then use those to build
> objects that do more complex tasks.
>
>
> On Thu, Feb 11, 2010 at 6:56 PM, Melinda Green
> wrote:
>
>> Sounds like a solution in search of a problem. I suggest that in order to
>> get it incorporated as core, that you create at least one compelling
>> solution built on it that people want enough to incorporate the whole thing.
>> If you can't come up with one then it probably doesn't belong there because
>> without a compelling example, nobody is going to realize it's there or to
>> trust it or know how to use it.
>>
>> Just my L$5,
>> -Melinda
>>
>
>
> ___
Re: [opensource-dev] retrieving scripts attached to an object
Could it be that you don't select the prim?
If it isn't selected, the contents aren't synced.
On Mon, Feb 15, 2010 at 04:47:14PM +0200, Mahmoud Ismail wrote:
>
>
>
> Hi all,
>
> as a proof of concept i was creating a floater which instantiated by a button
> on the Pie Menu
> in that floater i've created a Button in which i was try to get all inventory
> items attached to the selected object
>
> but, i found that it gives no script items although there're two script files
> "Note: i didn't open these files just press on New Script"
> now, sometimes when i opened these files first then press my button it gives
> results
>
> here's my button code:
>
>InventoryObjectList inventory_list;
> object->getInventoryContents(inventory_list);
> llinfos<<"Loop on inv_objects "< for(InventoryObjectList::iterator inv_obj=inventory_list.begin() ;inv_obj!=
> inventory_list.end();++inv_obj)
> {
> LLPointer obj=*inv_obj;
> llinfos<<"Type : " getName()< }
>
> anyone could tell me why i've to open the script file in order to be known as
> an inventory item for that object
>
> another request, if anyone have any material could help me in understanding of
> the workflow of the scripting module (from creating scripts till saving)
> please
> pass it.
>
> thanks in advance,
>
> Best Regards,
> Mahmoud Ismal
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
--
Carlo Wood
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] step by step guide to compiling snowglobe
Is there a step by step guide to compiling. I can use any windows OS or version of .NET. Please help, James _ Hotmail: Powerful Free email with security by Microsoft. http://clk.atdmt.com/GBL/go/201469230/direct/01/___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Problems compiling snowglobe
Hello, Im trying to compile snowglobe with VS2005, on windows 7, first one is: "Error 1 Error result 1 returned from 'C:\WINDOWS\system32\cmd.exe'." apparently on the "lscript_compile" project. And the other error is: "Error 2 fatal error LNK1104: cannot open file '..\lscript\lscript_compile\relwithdebinfo\lscript_compile.lib' secondlife-bin" Any ideas? Thanks. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] step by step guide to compiling snowglobe
I haven't compiled the viewer myself, but most of what I've seen on the list points to the wiki. http://wiki.secondlife.com/wiki/Compiling_and_Patching_Snowglobe_%28Linux%29 Some searching of the wiki of your own may turn up something more relevant to your interests. And I'm sure any problems you may encounter will happily be addressed by this list. -Stickman On Mon, Feb 15, 2010 at 12:47 PM, james ross wrote: > Is there a step by step guide to compiling. I can use any windows OS or > version of .NET. > > Please help, > James > > > Hotmail: Powerful Free email with security by Microsoft. Get it now. > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
