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
