On Mon, 18 Jan 2016 14:50:10 +1000 David Seikel <onef...@gmail.com> wrote:
> On Mon, 18 Jan 2016 13:18:14 +0900 Carsten Haitzler (The Rasterman) > <ras...@rasterman.com> wrote: > > > 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. > > These days I usually try to compile from git after alpha, beta, and > final releases. If I'm not otherwise busy, I'll then try to test my > SledjHamr project. I'd been very busy last year. Hopefully not so > busy this year, and next year I'll try to officially semi-retire. > > > so tell us what is wrong preferably as soon as possible after when > > it goes wrong. :) Now that my script engine is in better shape, I'll go back to investigating this toolbar thing I mentioned before. I'm gonna have to investigate it a bit more (maybe it got solved this release?) Here's some basics, in case it triggers an "AHA!" from someone - This is a combination Elementary / Evas_3D parent window, using opengl_xll as the engine. EO is used (mostly). ELM_WIN_BASIC is used for all windows. It used to work that I could attach a Elementary toolbar to the parent window, and to the child windows. Last release (or perhaps several releases ago) the parent window toolbar would not show. I made a quick workaround by adding a new child window for the toolbar to live in. Which is clunky. There's all manner of complications involving Evas_3D, ePhysics, Lua, and no doubt other things. I'll see if its fixed now, if not, I'll see if I can cut out a short example. > Nah, I prefer to see if it's pebkac first. B-) > > At least my network code got a decent refactor out of this. SledjHamr > is all highly experimental code, so I often just throw together shit, > play with it until I figure out what works, than rewrite it properly. > After several years, I expect some small part of it might get to the > point where it's no longer experimental, then I can move that small > part to the so far empty master branch. > > Now I think I'll throw together a shit script engine tester, play > around with it to see what works, but leave the rewrite until later. > I have a few ideas of things I can test that I might break again in > future. lol That was useful. Shook out a few bugs in my script engine. It also showed up that I'm not being consistent in throwing around LSL and Lua messages between the servers. I'll have to sort that out. > > > 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. > > > > > > -- 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
