> i have seen many people propose edje as the solution to glade - as a complete > ui builder solution. i've seen them expect it to do things that elm boxes, > tables etc. etc. do and do it completely. it's very hard to do synamic layouts > (lists etc.) purely in edje. it's designed mostly around an element with a > fixed number of things (labels, etc.) and a fixed known number of states.
glade! hum, i have never seen edje as something like glade, its... pretty different, since glade is for make user-interfaces "mostly with widgets" i could say that elementary is more near than edje to be a kind-of glade By the way, im going to play a bit with elementary these days, and I was wondering if there's something like a "wireframer" for elm, so with elm you can put lots of widgets one after to other from the C code, but it is there some way to set margins of the elements? things like spacings and positionings? If im not wrong, the only way to do that is using edje instead of elm and put elm "basic" widgets inside it, right ? maybe what im saying now sounds a little more like a glade thing 2013/12/17 Carsten Haitzler <ras...@rasterman.com> > On Tue, 17 Dec 2013 08:26:52 +1000 David Seikel <onef...@gmail.com> said: > > > On Mon, 16 Dec 2013 22:45:30 +0100 dumblob <dumb...@gmail.com> wrote: > > > > > > Just as a point of interest, my experiments with using LuaJIT in EFL > > > > > > > found that the Lua stuff itself is threadsafe so long as we use a > > > > thread safe memory allocator, which LuaJIT itself provides. The > > > > memory allocator we currently use in Edje Lua is not thread safe. > > > > I've been meaning to ask, do we have a threadsafe memory allocator > > > > in Eina? > > > > > > > > You are correct though, the rest of EFL is not as thread safe. My > > > > LuaJIT experiments involved enough message passing to deal with the > > > > "marshall all your bob calls back to the mainloop" you mentioned. > > > > > > > > > > Well, it doesn't sound that bad. Did you mean the sentence """My > > > LuaJIT experiments involved enough message passing to deal with the > > > "marshall all your bob calls back to the mainloop" you mentioned.""" > > > like you've done enough message passing testing to rigorously state > > > the only problem with Edje is its thread-unsafe memory allocator? > > > > > > -- Jan Pacner > > > > My experiments mostly concentrated on using EFL and LuaJIT to run many > > thousands of Lua scripts at once, using a message passing technique for > > communication between them. As I'm the main author of the current Edje > > Lua system, a secondary goal was to see how well my results could be > > used for Edje Lua, which doesn't currently use LuaJIT. > > > > The basic "run thousands of Lua scripts at once using message passing > > for communications" part was based an an academic paper and the open > > source code that went with it. I modified their source to make it EFL > > based. It uses a worker thread system that pulls ready scripts from > > a queue. Typically a script is ready when there is a message available > > for it. > > > > I then incorporated the result into a LSL scripting engine. LSL is > > Linden Scripting Language, which was invented by Linden Research for > > their Second Life virtual world platform, and also used in OpenSim, an > > open source clean room implementation of the Second Life server > > software. It's an event based system. My version of the engine > > converts LSL scripts into Lua, compiles that, then runs them in the > > worker thread system. Using the message passing to deal with events. > > Typically a "sim" (the basic unit of virtual land) would have > > many thousands of LSL scripts running at once. > > > > While doing this I did compare usage of the memory allocator that comes > > with LuaJit and the EFL one we are using in Edje Lua. The EFL one we > > used is not thread safe, the LuaJIT one is. > > > > I've also had long discussions on this list with raster about future > > plans for Edje Lua, including BOB. This is what led me to believe that > > the message passing system I have been experimenting with would be > > suitable for dealing with marshalling Edje and Evas calls back to the > > main loop. We also discussed various other options for thread safety in > > Edje Lua. I've not done any rigorous testing of this part of the plan, > > but it is on my TODO list. Certainly BOB has no code yet, it's a > > future plan. It's hard to rigorously test non existent code for a > > future plan. > > > > In the end, what raster said is true, out of all the EFL C API, only > > some is thread safe. The EFL design does include mechanisms for > > marshalling unsafe calls to the main thread. So it doesn't matter which > > scripting language is used to wrap it, somewhere along the line this > > call marshalling will have to be taken care of. My intention with Edje > > Lua is to make that transparent to Lua scripts. > > that's the idea. threads in bob will be a new LuaL per thread - some kind > of > pool - exactly as your experiment. they can do whatever they want but only > access a subset of bound apis from efl. they can do whatever it is they > need to > do and then when done - maybe "send a table" to the mainloop for handling. > this > would be a result of all their work that the mainloop then > applies/implements. > this means you keep state changes in a single place (main loop), but can > farm > off work to threads and other cores when/if needed. you just have to > decide if > the cost of marshalling/unmarshalling/passing is significantly less than > the > actual work to do. if it is not, then chances are this kind of setup just > hurts > rather than helps. > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
