In response to my novel below ... I fixed it, turns out it was my own silly fault this time. I wasn't processing the return values from the script function calls that cross the network properly.
On Wed, 13 Jan 2016 20:47:56 +1000 David Seikel <onef...@gmail.com> wrote: > On Wed, 13 Jan 2016 10:28:25 +0100 Stefan Schmidt > <ste...@osg.samsung.com> wrote: > > > Hello. > > > > On 13/01/16 10:17, David Seikel wrote: > > > Wow, this is the first time in about a year that an EFL release > > > has NOT broken my highly experimental, based on beta API, > > > SledjHamr virtual world project. Congratulations guys and gals. > > > B-) > > > > That is good to hear! > > > > > > > > On the other hand, I'm still trying to fix up all the breakage > > > from previous releases. lol > > > > > This one not :( > > > > Besides all these b0rkers jokes we are trying not to break things. > > From alpha1 onwards I really try to make sure we uncover the > > problems we might have to avoid regressions in the release. From my > > point of view it looks like the kind of regressions we have are > > mostly around behaviour changes. Actual API breaks seem to be under > > control. > > > > Does this correlate with what you are seeing? > > Keep in mind that my SledjHamr project is expected to take years to > complete, and has been under development (on and off, mostly off) > already for years. It's due to this expectation that I'm using the > beta stuff in the first place. I expect the beta APIs I've been using > will be well and truly stable before I can get a release out. > > In the early days, yes API breaks where common. These where easy to > fix though, look it up in the docs, or look at changes to examples, > just make the compiler happy. > > These days it is more behaviour changes that's the problem. These can > be tricky to sort out. For example, one I "fixed" from the previous > release (or perhaps the one before that) is that the Elementary > toolbar on my main window would not display, even though the toolbars > on the child windows displayed fine. Both use the same code. So I > wrapped it in it's own child window for now, that's just big enough > to show the toolbar. Just a work around for now. While Elementary > might be stable, I'm using it via Eo, so the problem might be in Eo. > > Another recent bug fix was that the 3D models where not turning up. I > can't recall off the top of my head how I fixed that. Evas_3D isn't > stable, so I expect problems every now and then. Also in Evas_3D, I > was using the example cube and sphere code originally. Some time last > year the ability to click on that cube or sphere stopped working, > around about the time primitives where added to Evas_3D. I fixed this > by switching to primitives, and clicks work fine now. > > There have been many other issues like those. > > The one remaining problem, though it's entirely possible it's masking > more, is to do with very complex communication between the client, > world server, and script server. I think, proving to be tricky to > track down. Some of the stuff is working, but I should be getting a > dialogue popping up as the result of interacting with a script, and > that isn't working now. I know the dialogue itself works, popping it > up other ways is fine. > > > > The following novel describes how complex this is. Skip it if you > like. lol > > I start the client, it tries to connect to a world server (local only > for testing), if it can't find one, it starts one, then tries again. > The world server does the same thing for the script server, try to > connect, on failure, start one. > > Once it's all up and running, the world server tells the script server > to start compiling all the scripts it finds in the world. These are > ordinary LSL scripts (Linden Scripting Language), as invented for > Second Life (SL) by Linden Labs. Commonly used open source scripts > are what I'm testing with. I'm trying to maintain backwards > compatibility with both that and the OpenSim (OS) variation of LSL. > It's common to have thousands of these scripts in one 256 x 256 meter > region, or even dozens on an avatar. > > LSL is a .... insert REALLY STRONG SWEAR WORDS here ... of a language, > trying to do stuff often involves multiple scripts communicating with > each other. The script server translates them into Lua, then uses > LuaJIT to compile them. The script server tells the world server when > each script is done compiling, the world server then tells the script > server to actually run them. Which it does, using LuaJIT. I wrote a > worker thread system to run these scripts, as LSL is event driven. So > script response to events is expected to be short. This is actually > part of the spec of LSL. Anyone trying an endless loop in LSL should > expect their script to be terminated. > > As an aside, I'm doing things this way coz I feel that LuaJIT, being > the fastest scripting language, could do a far better job than normal > LSL, which is usually compiled to Mono. If I remember correctly (been > a while since I did the last benchmarks), SL and OS both take many > seconds to compile an average script, my compiler is compiling > hundreds per second. I haven't benchmarked running performance yet, > but I expect a decent speed up. OS has a similar arrangement, but > translates to C# and compiles to Mono; no one knows what SL does, > other than use Mono. SL used to compile the scripts client side, > using their own runtime, but they switched to compiling to Mono. > This is why these days you can select either option in SL. > > So these normal, everyday, LSL scripts toss messages back and forth > between themselves, mostly due to memory limits and lack of a library > mechanism, and toss messages to the world server to get it to do stuff > to the world. The world server tosses events to the script server, > which are passed onto the scripts. Stuff that involves interacting > with the user gets messages tossed between all three. > > The main scripts I'm testing with are called MLP, Multi Love Pose, > scripts used for sex. I chose them coz they actually exercise a large > part of the system in a staged way (so I don't have to implement > everything at once), they are popular, and are known to be slow. > Plus, I'm familiar with them, having worked with them in the past. > When they start up, they mostly just sit idle until someone clicks on > the object they are in. Then a half dozen scripts start loading data > into themselves from "notecards" also stored in the object, spewing > logging info to the chat console. After a while, they are ready. A > second click is supposed to pop up a dialogue where the user can then > decide what to do. Usually the user will then select a pose from the > dialogue, and the scripts will create "pose balls" in world, which the > user/s then sit on. Second Life and OpenSim users will be familiar > with how this works in world. > > Right now, only some of those messages to the chat console actually > appear, and the dialogue no longer pops up. It used to work as far as > interacting with the dialogue, and getting more dialogues. The part > that creates objects in world in response to scripts hasn't been > written yet. I don't even have avatars yet, so no one's sitting on > anything. > -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
