On Mon, 18 Jan 2016 12:36:12 +1000 David Seikel <onef...@gmail.com> said:
> 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. aha! pebkac :) but seriously - we dont want to break efl. we try not to. but we need people to call us out on a break EARLY. preferably during development (follow git master) or at least when stefan puts out alphas and betas. i know if i notice something break behavior-wise or stability wise AS we develop - i look into it. so tell us what is wrong preferably as soon as possible after when it goes wrong. :) > 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. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
