Re: [E-devel] (no subject)
On Wed, 4 Oct 2023 16:13:13 -0300 Aira said: > How can I start?have already subscribed to the email list Start what? -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
hello On Wed, Oct 4, 2023 at 9:11 PM Aira wrote: > > How can I start?have already subscribed to the email list what do you want to do ? Vincent ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] (no subject)
How can I start?have already subscribed to the email list ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] (no subject)
How can I start? ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] (no subject)
Hi guys, I’m noticing a bit of tensions through some diffs I’m seeing come through the pipeline. I think two points to make here are the following: Firstly English might not be the native language spoken by some so one needs to keep this in mind that when reading their English some wording they use might come out as harsh and abrasive when that would not have been the intention. Secondly from text Alone one cannot fully understand what their emotion they want to put forth really is. Through text that is easily lost. If anyone takes anything out of what I’m sending I hope that these two points will come to mind. Regards, Jonathan Aquilina Owner managing director Phone (356) 20330099 Mobile (356) 79957942 Email sa...@eagleeyet.net ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] (no subject)
"Adopt the pace of nature: her secret is patience." Ralph Waldo Emerson Hello fellow Terminology enthusiasts! With 95 new commits, Terminology 1.6.0 is ready. It packs UI improvements around tabs and splits, a welcome wizard to adjust the scaling factor, translation updates and its load of fixes. During development of this release, Terminology's Twitter account @_Terminology_ was created. == Additions == * Show title tab on splits, depending on configuration * Show tabs that had a bell rang and had not been focused * Add wizard on new configuration to set scaling * Add scale configuration in the Settings panel * Add Polish translation == Improvements == * Themes: make tab title readable based on theme default colors * Move the tab selector on the tab line * Be able to select and copy tabs * Better handle stalled unix socket when using one terminology with multiple instances * Change `typop` behavior to queue files in case there are multiple files to look at * Update Italian translation == Fixes == * Fix live selections in the scrollback * Fix unticking `auto-hide cursor` not working * Fix memory leaks related to looking for links under the mouse * Ensure Terminology compiles with `EFL-1.20` * Fix link detection over spaces * Fix tab selector no longer taking into account the new destination * Fix crash when using `typop` with multiple files * No longer set environment variable `DESKTOP_STARTUP_ID` as it may no longer be accurate * Allow tabs to be pasted The tarball can be found at : - https://download.enlightenment.org/rel/apps/terminology/terminology-1.6.0.tar.xz - https://downloads.terminolo.gy/terminology-1.6.0.tar.xz sha256sum: b95cb05653afe0dad77fc038a8d5276c02a9c08d64ac97ddf0cee8087d27bd77 Happy compiling! ( https://xkcd.com/303/ ) -- Boris Faure Pointer Arithmetician signature.asc Description: PGP signature ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] (no subject)
Hello, I have been testing the new E18 on my notebook, which has an Intel GMA 3150 graphics chip, and it is terribly slow. I have been searching for a solution on Google but all I found was this: On Sun, 1 Dec 2013 19:29:49 -0600 Jeff Hoogland JeffHoogland@... said: It is in fact the 3150 THAT would be your problem then. that gpu is the black sheep of the intel gpu family. it's half accelerated. it has a hw fragment shader but NOT a hw vertex shader. it is the ONLY gpu i know of that does this. they either have both, or none. in the case of none - evas gl engine fails to init. :) what you see if intel's driver using a software fallback vertex shader emulation. there isn't much to be done here. the difference between e17 and e18 is that e18 exposes more geometry to the gpu. in all cases except the 3150, this is in fact highly efficient and saves memory and overhead. the whole reason you can now do shaped borders with no extra major cost in e18 is because we do this. even keith packard advises to ignore that gpu and pretend it never existed. :) and he works at intel. :) Basically, I am wondering if there is some way of limiting the geometry, and not completely disabling OpenGL, maybe some intel patch, I am not very savvy in OpenGL or E so basically I wouldn't know where to start looking to make such a patch. As I saw E is a window manager that tries to be light and well, it is basically for older/less powerfull computers (as I understand, and the reason I started using it), and a lot of notebooks are using this GMA 3150 chipset, so I think it would be a shame if this problem is simply ignored. Regards -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
On Tue, 17 Dec 2013 01:50:15 +0100 Thanatermesis thanatermesis.e...@gmail.com said: 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 elm has frames. use elm_frame with the pad styles. pad_small, pad_medium, pad_large, pad_huge. put child in a frame, put frame where u would put child. this way teh theme decides what padding should be for the ui look feel and it scales too. :) 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
Re: [E-devel] (no subject)
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. Nice, this is what I wanted to know. Now it's apparent it's (and will be) possible to use pure pthreads from C without EFL thread-wrappers under the condition the programmer passes explicitly serialized messages (using thread-safe serializing C functions) to those thread-unsafe C functions. My intention with Edje Lua is to make that transparent to Lua scripts. Great idea, keep going! Thank you guys for participation in this discussion. All my concerns are clarified. -- 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=84349831iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
Hello, On Tue, Dec 17, 2013 at 9:54 PM, dumblob dumb...@gmail.com wrote: 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. Nice, this is what I wanted to know. Now it's apparent it's (and will be) possible to use pure pthreads from C without EFL thread-wrappers under the condition the programmer passes explicitly serialized messages (using thread-safe serializing C functions) to those thread-unsafe C functions. I would still recommend you to use at minima Eina_Thread infrastructure so you get portability out of the box. Also Ecore_Thread provide all the infrastructure needed to synchronize with the main loop with the minimum possible cost (limit the number of wake up in the main loop and the amount of data marshaled to fd to the bare minimum). Current limitation that I do think is annoying is the lack of mechanism to transmit data between thread. That would be an improvement for future, that would make those thread close to some mini main loop. -- Cedric BAIL -- 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=84349831iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
On 12/18/2013 11:53 AM, Cedric BAIL wrote: Hello, On Tue, Dec 17, 2013 at 9:54 PM, dumblob dumb...@gmail.com wrote: 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. Nice, this is what I wanted to know. Now it's apparent it's (and will be) possible to use pure pthreads from C without EFL thread-wrappers under the condition the programmer passes explicitly serialized messages (using thread-safe serializing C functions) to those thread-unsafe C functions. I would still recommend you to use at minima Eina_Thread infrastructure so you get portability out of the box. Also Ecore_Thread provide all the infrastructure needed to synchronize with the main loop with the minimum possible cost (limit the number of wake up in the main loop and the amount of data marshaled to fd to the bare minimum). Current limitation that I do think is annoying is the lack of mechanism to transmit data between thread. That would be an improvement for future, that would make those thread close to some mini main loop. That would be cool, Qt can do that with a combination of its threads and signal, slot mechanism. If you have a signal connected to a slot in a different thread, when the signal is triggered the slot is called the next time it's thread runs through the event loop. Stuff like that makes writing threaded code quite sane and relatively easy. -- 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=84349831iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
On Mon, 16 Dec 2013 08:39:47 +0100 dumblob dumb...@gmail.com said: Thank you. If I got it correctly, it will be possible to use BÖBs C API from parallel threads without being afraid something will break up. That's neat and I'll look forward to testing first alpha versions in a few years :). no - unlikely unless we got to lots of effort to make the c api threadsafe. most of efl is not threadsafe. only eina and eet are, with ecore (some of it) optionally. since bob will interface directly to evas - thus evas's api would need to be threadsafe for bob to be threadafe and... we're not likely doing this. marshall all your bob calls back to the mainloop and do them there. we have plenty of infra for just that without any locks. 2013/12/16 Carsten Haitzler ras...@rasterman.com On Mon, 16 Dec 2013 06:25:54 +0100 Thanatermesis thanatermesis.e...@gmail.com said: slight problem is that in the process of ensuring edje does its job, the over-engineering made it look like something different, and that is where suddenly it looks bad because people use it as something different then find all the creaky edge cases. Can you tell me which creaky edge cases ? I never found edge bad designed or anything wrong at all on it, im talking of course about the edge that I met a good number of years ago but i assume that we still having the same one, just more improved :) For what something different people wanted to use it ? 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. bob is accepting that reality and trying to make something closer to what people have expected edje to be. And what expects people edje to be ? above. they expect it to be a replacement for glade and/or qml etc. etc. 2013/12/16 Carsten Haitzler ras...@rasterman.com On Sun, 15 Dec 2013 17:48:37 +0100 dumblob dumb...@gmail.com said: bob would not be bob if it was not tied to a single specific language. lua (via luajit) is at least the target we think is best. basically instead of implementing stuff with edc to design ui elements, you use lua to do the same. lua is a data file. it is what implements the abstraction. the idea is that bob COMES with a small mountain of pre-made lua bobjects that already work (and build on top of each-other via inheritance or other mechanisms). the other side of bob is a c library with c apis. just like efl is today. no different. you expose state/data to bob from the c side (and bob can expose data/state back to you). bob (the c library) handles the infra for this - threading infra too, mainloop integration, sandboxing etc. etc. bob is fundamentally no different to edje in the very high level design. the difference is what is under the covers. how state is held/handled. how state/data is exchanged/shared, how data is implemented (edc + embryo lua atm and bob would just be plain luajit with the above infra). bob is a result of lessons learned from edje over the years. edje was designed as nothing more than a smart png with layers. eg a psd or xcf file really. a png that can resize intelligently (not just stretch) as well as throw in some simple states of that image (normal, activated, disabled) and some transitions. that was edje's design goal and intent. of course it was over-engineered for the job to ensure it covers that job as fully as it can. slight problem is that in the process of ensuring edje does its job, the over-engineering made it look like something different, and that is where suddenly it looks bad because people use it as something different then find all the creaky edge cases. bob is accepting that reality and trying to make something closer to what people have expected edje to be. Hi, I've recently come across https://phab.enlightenment.org/w/bob/ and I wonder if BÖB is going to be usable in other programming languages than Lua (e.g. pure C without Lua, in Google Gos gorutines mapped to real threads, in pthreads generally etc.). It seems, the implementation will be tightly coupled with Lua and some specific form of IPC while abandoning simple interface for external bindings to languages with built-in parallelism. I'm afraid it will not be possible to make e.g. such bindings for Dao ( http://daovm.net/) which would support the DaoVM parallel threads/tasklets. In other words, I'm
Re: [E-devel] (no subject)
On Mon, 16 Dec 2013 20:43:05 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Mon, 16 Dec 2013 08:39:47 +0100 dumblob dumb...@gmail.com said: Thank you. If I got it correctly, it will be possible to use BÖBs C API from parallel threads without being afraid something will break up. That's neat and I'll look forward to testing first alpha versions in a few years :). no - unlikely unless we got to lots of effort to make the c api threadsafe. most of efl is not threadsafe. only eina and eet are, with ecore (some of it) optionally. since bob will interface directly to evas - thus evas's api would need to be threadsafe for bob to be threadafe and... we're not likely doing this. marshall all your bob calls back to the mainloop and do them there. we have plenty of infra for just that without any locks. 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. 2013/12/16 Carsten Haitzler ras...@rasterman.com On Mon, 16 Dec 2013 06:25:54 +0100 Thanatermesis thanatermesis.e...@gmail.com said: slight problem is that in the process of ensuring edje does its job, the over-engineering made it look like something different, and that is where suddenly it looks bad because people use it as something different then find all the creaky edge cases. Can you tell me which creaky edge cases ? I never found edge bad designed or anything wrong at all on it, im talking of course about the edge that I met a good number of years ago but i assume that we still having the same one, just more improved :) For what something different people wanted to use it ? 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. bob is accepting that reality and trying to make something closer to what people have expected edje to be. And what expects people edje to be ? above. they expect it to be a replacement for glade and/or qml etc. etc. 2013/12/16 Carsten Haitzler ras...@rasterman.com On Sun, 15 Dec 2013 17:48:37 +0100 dumblob dumb...@gmail.com said: bob would not be bob if it was not tied to a single specific language. lua (via luajit) is at least the target we think is best. basically instead of implementing stuff with edc to design ui elements, you use lua to do the same. lua is a data file. it is what implements the abstraction. the idea is that bob COMES with a small mountain of pre-made lua bobjects that already work (and build on top of each-other via inheritance or other mechanisms). the other side of bob is a c library with c apis. just like efl is today. no different. you expose state/data to bob from the c side (and bob can expose data/state back to you). bob (the c library) handles the infra for this - threading infra too, mainloop integration, sandboxing etc. etc. bob is fundamentally no different to edje in the very high level design. the difference is what is under the covers. how state is held/handled. how state/data is exchanged/shared, how data is implemented (edc + embryo lua atm and bob would just be plain luajit with the above infra). bob is a result of lessons learned from edje over the years. edje was designed as nothing more than a smart png with layers. eg a psd or xcf file really. a png that can resize intelligently (not just stretch) as well as throw in some simple states of that image (normal, activated, disabled) and some transitions. that was edje's design goal and intent. of course it was over-engineered for the job to ensure it covers that job as fully as it can. slight problem is that in the process of ensuring edje does its job, the over-engineering made it look like something different, and that is where suddenly it looks bad because people use it as something
Re: [E-devel] (no subject)
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 -- 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=84349831iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
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. -- 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 -- 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=84349831iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
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
Re: [E-devel] (no subject)
Hello, On Tue, Dec 17, 2013 at 5:46 AM, David Seikel onef...@gmail.com wrote: On Mon, 16 Dec 2013 20:43:05 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Mon, 16 Dec 2013 08:39:47 +0100 dumblob dumb...@gmail.com said: Thank you. If I got it correctly, it will be possible to use BÖBs C API from parallel threads without being afraid something will break up. That's neat and I'll look forward to testing first alpha versions in a few years :). no - unlikely unless we got to lots of effort to make the c api threadsafe. most of efl is not threadsafe. only eina and eet are, with ecore (some of it) optionally. since bob will interface directly to evas - thus evas's api would need to be threadsafe for bob to be threadafe and... we're not likely doing this. marshall all your bob calls back to the mainloop and do them there. we have plenty of infra for just that without any locks. 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? Depend what you are looking for. If an eina_mempool does fit your need, then they are threadsafe. If you are need a more general purpose allocator, malloc should be fine. 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. Care to share the code of your experiment, I am quite interested in it. -- Cedric BAIL -- 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=84349831iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
On Tue, 17 Dec 2013 10:43:03 +0900 Cedric BAIL cedric.b...@free.fr wrote: Hello, On Tue, Dec 17, 2013 at 5:46 AM, David Seikel onef...@gmail.com wrote: On Mon, 16 Dec 2013 20:43:05 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Mon, 16 Dec 2013 08:39:47 +0100 dumblob dumb...@gmail.com said: Thank you. If I got it correctly, it will be possible to use BÖBs C API from parallel threads without being afraid something will break up. That's neat and I'll look forward to testing first alpha versions in a few years :). no - unlikely unless we got to lots of effort to make the c api threadsafe. most of efl is not threadsafe. only eina and eet are, with ecore (some of it) optionally. since bob will interface directly to evas - thus evas's api would need to be threadsafe for bob to be threadafe and... we're not likely doing this. marshall all your bob calls back to the mainloop and do them there. we have plenty of infra for just that without any locks. 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? Depend what you are looking for. If an eina_mempool does fit your need, then they are threadsafe. If you are need a more general purpose allocator, malloc should be fine. I'll look into that next time I work on this stuff. 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. Care to share the code of your experiment, I am quite interested in it. I had posted it to this list before - https://github.com/onefang/SledjHamr/tree/experimental/LuaSL It's part of the SledjHamr project, which is itself a motley collection of bits and pieces that should eventually merge into my vision of how virtual worlds should work. I've not touched it for months, but I should soon be able to get back to it, say early next year. -- 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 -- 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=84349831iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] (no subject)
Hi, I've recently come across https://phab.enlightenment.org/w/bob/ and I wonder if BÖB is going to be usable in other programming languages than Lua (e.g. pure C without Lua, in Google Gos gorutines mapped to real threads, in pthreads generally etc.). It seems, the implementation will be tightly coupled with Lua and some specific form of IPC while abandoning simple interface for external bindings to languages with built-in parallelism. I'm afraid it will not be possible to make e.g. such bindings for Dao ( http://daovm.net/) which would support the DaoVM parallel threads/tasklets. In other words, I'm not sure, if all public methods/functions of the BÖB API will be thread-safe and fully independent from Lua. Maybe I'm wrong about the goal of EFL 2.0, but I think, tightly coupling only with Lua will certainly limit the utilization of these great libraries. Does anyone have some more accurate and detailed information? Kind regards -- Jan Pacner -- 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=84349831iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
On Sun, 15 Dec 2013 17:48:37 +0100 dumblob dumb...@gmail.com said: bob would not be bob if it was not tied to a single specific language. lua (via luajit) is at least the target we think is best. basically instead of implementing stuff with edc to design ui elements, you use lua to do the same. lua is a data file. it is what implements the abstraction. the idea is that bob COMES with a small mountain of pre-made lua bobjects that already work (and build on top of each-other via inheritance or other mechanisms). the other side of bob is a c library with c apis. just like efl is today. no different. you expose state/data to bob from the c side (and bob can expose data/state back to you). bob (the c library) handles the infra for this - threading infra too, mainloop integration, sandboxing etc. etc. bob is fundamentally no different to edje in the very high level design. the difference is what is under the covers. how state is held/handled. how state/data is exchanged/shared, how data is implemented (edc + embryo lua atm and bob would just be plain luajit with the above infra). bob is a result of lessons learned from edje over the years. edje was designed as nothing more than a smart png with layers. eg a psd or xcf file really. a png that can resize intelligently (not just stretch) as well as throw in some simple states of that image (normal, activated, disabled) and some transitions. that was edje's design goal and intent. of course it was over-engineered for the job to ensure it covers that job as fully as it can. slight problem is that in the process of ensuring edje does its job, the over-engineering made it look like something different, and that is where suddenly it looks bad because people use it as something different then find all the creaky edge cases. bob is accepting that reality and trying to make something closer to what people have expected edje to be. Hi, I've recently come across https://phab.enlightenment.org/w/bob/ and I wonder if BÖB is going to be usable in other programming languages than Lua (e.g. pure C without Lua, in Google Gos gorutines mapped to real threads, in pthreads generally etc.). It seems, the implementation will be tightly coupled with Lua and some specific form of IPC while abandoning simple interface for external bindings to languages with built-in parallelism. I'm afraid it will not be possible to make e.g. such bindings for Dao ( http://daovm.net/) which would support the DaoVM parallel threads/tasklets. In other words, I'm not sure, if all public methods/functions of the BÖB API will be thread-safe and fully independent from Lua. Maybe I'm wrong about the goal of EFL 2.0, but I think, tightly coupling only with Lua will certainly limit the utilization of these great libraries. Does anyone have some more accurate and detailed information? Kind regards -- Jan Pacner -- 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=84349831iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - 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=84349831iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
slight problem is that in the process of ensuring edje does its job, the over-engineering made it look like something different, and that is where suddenly it looks bad because people use it as something different then find all the creaky edge cases. Can you tell me which creaky edge cases ? I never found edge bad designed or anything wrong at all on it, im talking of course about the edge that I met a good number of years ago but i assume that we still having the same one, just more improved :) For what something different people wanted to use it ? bob is accepting that reality and trying to make something closer to what people have expected edje to be. And what expects people edje to be ? 2013/12/16 Carsten Haitzler ras...@rasterman.com On Sun, 15 Dec 2013 17:48:37 +0100 dumblob dumb...@gmail.com said: bob would not be bob if it was not tied to a single specific language. lua (via luajit) is at least the target we think is best. basically instead of implementing stuff with edc to design ui elements, you use lua to do the same. lua is a data file. it is what implements the abstraction. the idea is that bob COMES with a small mountain of pre-made lua bobjects that already work (and build on top of each-other via inheritance or other mechanisms). the other side of bob is a c library with c apis. just like efl is today. no different. you expose state/data to bob from the c side (and bob can expose data/state back to you). bob (the c library) handles the infra for this - threading infra too, mainloop integration, sandboxing etc. etc. bob is fundamentally no different to edje in the very high level design. the difference is what is under the covers. how state is held/handled. how state/data is exchanged/shared, how data is implemented (edc + embryo lua atm and bob would just be plain luajit with the above infra). bob is a result of lessons learned from edje over the years. edje was designed as nothing more than a smart png with layers. eg a psd or xcf file really. a png that can resize intelligently (not just stretch) as well as throw in some simple states of that image (normal, activated, disabled) and some transitions. that was edje's design goal and intent. of course it was over-engineered for the job to ensure it covers that job as fully as it can. slight problem is that in the process of ensuring edje does its job, the over-engineering made it look like something different, and that is where suddenly it looks bad because people use it as something different then find all the creaky edge cases. bob is accepting that reality and trying to make something closer to what people have expected edje to be. Hi, I've recently come across https://phab.enlightenment.org/w/bob/ and I wonder if BÖB is going to be usable in other programming languages than Lua (e.g. pure C without Lua, in Google Gos gorutines mapped to real threads, in pthreads generally etc.). It seems, the implementation will be tightly coupled with Lua and some specific form of IPC while abandoning simple interface for external bindings to languages with built-in parallelism. I'm afraid it will not be possible to make e.g. such bindings for Dao ( http://daovm.net/) which would support the DaoVM parallel threads/tasklets. In other words, I'm not sure, if all public methods/functions of the BÖB API will be thread-safe and fully independent from Lua. Maybe I'm wrong about the goal of EFL 2.0, but I think, tightly coupling only with Lua will certainly limit the utilization of these great libraries. Does anyone have some more accurate and detailed information? Kind regards -- Jan Pacner -- 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=84349831iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - 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=84349831iu=/4140/ostg.clktrk
Re: [E-devel] (no subject)
On Mon, 16 Dec 2013 06:25:54 +0100 Thanatermesis thanatermesis.e...@gmail.com said: slight problem is that in the process of ensuring edje does its job, the over-engineering made it look like something different, and that is where suddenly it looks bad because people use it as something different then find all the creaky edge cases. Can you tell me which creaky edge cases ? I never found edge bad designed or anything wrong at all on it, im talking of course about the edge that I met a good number of years ago but i assume that we still having the same one, just more improved :) For what something different people wanted to use it ? 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. bob is accepting that reality and trying to make something closer to what people have expected edje to be. And what expects people edje to be ? above. they expect it to be a replacement for glade and/or qml etc. etc. 2013/12/16 Carsten Haitzler ras...@rasterman.com On Sun, 15 Dec 2013 17:48:37 +0100 dumblob dumb...@gmail.com said: bob would not be bob if it was not tied to a single specific language. lua (via luajit) is at least the target we think is best. basically instead of implementing stuff with edc to design ui elements, you use lua to do the same. lua is a data file. it is what implements the abstraction. the idea is that bob COMES with a small mountain of pre-made lua bobjects that already work (and build on top of each-other via inheritance or other mechanisms). the other side of bob is a c library with c apis. just like efl is today. no different. you expose state/data to bob from the c side (and bob can expose data/state back to you). bob (the c library) handles the infra for this - threading infra too, mainloop integration, sandboxing etc. etc. bob is fundamentally no different to edje in the very high level design. the difference is what is under the covers. how state is held/handled. how state/data is exchanged/shared, how data is implemented (edc + embryo lua atm and bob would just be plain luajit with the above infra). bob is a result of lessons learned from edje over the years. edje was designed as nothing more than a smart png with layers. eg a psd or xcf file really. a png that can resize intelligently (not just stretch) as well as throw in some simple states of that image (normal, activated, disabled) and some transitions. that was edje's design goal and intent. of course it was over-engineered for the job to ensure it covers that job as fully as it can. slight problem is that in the process of ensuring edje does its job, the over-engineering made it look like something different, and that is where suddenly it looks bad because people use it as something different then find all the creaky edge cases. bob is accepting that reality and trying to make something closer to what people have expected edje to be. Hi, I've recently come across https://phab.enlightenment.org/w/bob/ and I wonder if BÖB is going to be usable in other programming languages than Lua (e.g. pure C without Lua, in Google Gos gorutines mapped to real threads, in pthreads generally etc.). It seems, the implementation will be tightly coupled with Lua and some specific form of IPC while abandoning simple interface for external bindings to languages with built-in parallelism. I'm afraid it will not be possible to make e.g. such bindings for Dao ( http://daovm.net/) which would support the DaoVM parallel threads/tasklets. In other words, I'm not sure, if all public methods/functions of the BÖB API will be thread-safe and fully independent from Lua. Maybe I'm wrong about the goal of EFL 2.0, but I think, tightly coupling only with Lua will certainly limit the utilization of these great libraries. Does anyone have some more accurate and detailed information? Kind regards -- Jan Pacner -- 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=84349831iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net
Re: [E-devel] (no subject)
Thank you. If I got it correctly, it will be possible to use BÖBs C API from parallel threads without being afraid something will break up. That's neat and I'll look forward to testing first alpha versions in a few years :). 2013/12/16 Carsten Haitzler ras...@rasterman.com On Mon, 16 Dec 2013 06:25:54 +0100 Thanatermesis thanatermesis.e...@gmail.com said: slight problem is that in the process of ensuring edje does its job, the over-engineering made it look like something different, and that is where suddenly it looks bad because people use it as something different then find all the creaky edge cases. Can you tell me which creaky edge cases ? I never found edge bad designed or anything wrong at all on it, im talking of course about the edge that I met a good number of years ago but i assume that we still having the same one, just more improved :) For what something different people wanted to use it ? 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. bob is accepting that reality and trying to make something closer to what people have expected edje to be. And what expects people edje to be ? above. they expect it to be a replacement for glade and/or qml etc. etc. 2013/12/16 Carsten Haitzler ras...@rasterman.com On Sun, 15 Dec 2013 17:48:37 +0100 dumblob dumb...@gmail.com said: bob would not be bob if it was not tied to a single specific language. lua (via luajit) is at least the target we think is best. basically instead of implementing stuff with edc to design ui elements, you use lua to do the same. lua is a data file. it is what implements the abstraction. the idea is that bob COMES with a small mountain of pre-made lua bobjects that already work (and build on top of each-other via inheritance or other mechanisms). the other side of bob is a c library with c apis. just like efl is today. no different. you expose state/data to bob from the c side (and bob can expose data/state back to you). bob (the c library) handles the infra for this - threading infra too, mainloop integration, sandboxing etc. etc. bob is fundamentally no different to edje in the very high level design. the difference is what is under the covers. how state is held/handled. how state/data is exchanged/shared, how data is implemented (edc + embryo lua atm and bob would just be plain luajit with the above infra). bob is a result of lessons learned from edje over the years. edje was designed as nothing more than a smart png with layers. eg a psd or xcf file really. a png that can resize intelligently (not just stretch) as well as throw in some simple states of that image (normal, activated, disabled) and some transitions. that was edje's design goal and intent. of course it was over-engineered for the job to ensure it covers that job as fully as it can. slight problem is that in the process of ensuring edje does its job, the over-engineering made it look like something different, and that is where suddenly it looks bad because people use it as something different then find all the creaky edge cases. bob is accepting that reality and trying to make something closer to what people have expected edje to be. Hi, I've recently come across https://phab.enlightenment.org/w/bob/ and I wonder if BÖB is going to be usable in other programming languages than Lua (e.g. pure C without Lua, in Google Gos gorutines mapped to real threads, in pthreads generally etc.). It seems, the implementation will be tightly coupled with Lua and some specific form of IPC while abandoning simple interface for external bindings to languages with built-in parallelism. I'm afraid it will not be possible to make e.g. such bindings for Dao ( http://daovm.net/) which would support the DaoVM parallel threads/tasklets. In other words, I'm not sure, if all public methods/functions of the BÖB API will be thread-safe and fully independent from Lua. Maybe I'm wrong about the goal of EFL 2.0, but I think, tightly coupling only with Lua will certainly limit the utilization of these great libraries. Does anyone have some more accurate and detailed information? Kind regards -- Jan Pacner -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance
Re: [E-devel] (no subject)
On Wed, Feb 13, 2013 at 12:18 AM, Cedric BAIL cedric.b...@free.fr wrote: On Wed, Feb 13, 2013 at 9:36 AM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann d.willm...@samsung.com wrote: Hello, beware, the switch to Git will be happening soon! We will migrate efl, elementary and enlightenment one-by-one and send mails with specific details when each will happen. For the time when we are using Git here is a really small list of what you need to change: First setup Git as it will need to know your name and email (global here means per-user) $ git config --global user.name Jane Doe $ git config --global user.email jane...@example.com Useful commands: To get the repository, run $ git clone ssh://g...@phab.enlightenment.org/reponame - (svn checkout) The names will be announced as we switch - the first ones will most likely be core/efl.git, core/elementary.git and core/enlightenment.git To update to the newest version $ git pull --rebase - (svn update) To commit all local changes $ git commit -a $ git push - (svn ci) OR (better) if you just want to commit specific files $ git add files $ git commit $ git push - (svn ci files) Here's more Git for SVN users: http://git-scm.com/course/svn.html If you want to know more I recommend reading (part of) the Git book at http://git-scm.com/book I even recommend reading it if you don't want to know more. A sneak peek of the awesomeness that awaits you at the other side of that link: # Enable color in diffs, etc. (should be default by now) $ git config --global color.ui true # Change your editor if you don't like what $EDITOR points to $ git config --global core.editor vim # Configure shortcuts for commands $ git config --global alias.ci commit These were the very basics of how to work with Git on a technical level. In the following paragraphs I want to introduce some common work flows that I think are useful to adopt. If you don't understand it all - that's okay. It's not a MUST. But please feel free to ask if anything is unclear. Structure of the repositories - Official: These branches will be fast-forward only (you cannot rewrite history/commits that have been published to the server). This is what people expect from official branches and the same behaviour as with SVN. Once commits are made you cannot uncommit something - only revert. * master is what trunk used to be. All official development happens there. * For a stabilization branch we will have packagename-version branching off of master. This is analog to the way SVN branches were used in the past. An example would be elementary-1.7 * Git tags will mark the exact commit that was used for a release. As such these commits will usually reside within the release branches or be the starting point for one. Tags will follow the naming scheme vversion, so for example v1.7.5. Topic branches: * In each repository every developer with commit access will be able to push/update branches in their own namespace (devs/name/*). These branches will allow non-fastforward updates and no one should expect these to be stable. * This is a testing ground for developers where new features can be developed, debugged and shared with fellow developers. Ideally any new feature would live in its own branch until it matures and is merged into master. It's a nice proposal, but what about master branch permissions ? Every developer would be allowed to push stuff on there (with a flow similar to svn) ? Or we'll try to establish some kind of policy about it (maintainers, review, etc) ? We did have some discussion and sharing idea about that during fosdem. The consensus is that we were not ready as a group of developers to move to that kind of organisation. Instead something that maybe would fit us more is a release cycle and development process based on time. 1 week of feature addition 2 week of bug fixing This cycle would be repeated 3 times, then followed by : a release candidate 2 additional weeks of stabilization (maybe another RC) a beta 1 additional week of polishing release (if everything is good of course) Of course we don't start a feature addition cycle if current master branch is unstable. The hope is to be on a more rapid development cycle, but still stable and avoiding glacial era like we have before each release. Finally it should give us a good release every 3 months. It should not change our workflow to much and still be an improvement over our current model. Any though or improvement about it ? Or a better proposal ? It sounds good. Let's try it =) -- Cedric BAIL -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more.
Re: [E-devel] (no subject)
On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann d.willm...@samsung.com wrote: Hello, beware, the switch to Git will be happening soon! We will migrate efl, elementary and enlightenment one-by-one and send mails with specific details when each will happen. For the time when we are using Git here is a really small list of what you need to change: First setup Git as it will need to know your name and email (global here means per-user) $ git config --global user.name Jane Doe $ git config --global user.email jane...@example.com Useful commands: To get the repository, run $ git clone ssh://g...@phab.enlightenment.org/reponame - (svn checkout) The names will be announced as we switch - the first ones will most likely be core/efl.git, core/elementary.git and core/enlightenment.git To update to the newest version $ git pull --rebase - (svn update) To commit all local changes $ git commit -a $ git push - (svn ci) OR (better) if you just want to commit specific files $ git add files $ git commit $ git push - (svn ci files) Here's more Git for SVN users: http://git-scm.com/course/svn.html If you want to know more I recommend reading (part of) the Git book at http://git-scm.com/book I even recommend reading it if you don't want to know more. A sneak peek of the awesomeness that awaits you at the other side of that link: # Enable color in diffs, etc. (should be default by now) $ git config --global color.ui true # Change your editor if you don't like what $EDITOR points to $ git config --global core.editor vim # Configure shortcuts for commands $ git config --global alias.ci commit These were the very basics of how to work with Git on a technical level. In the following paragraphs I want to introduce some common work flows that I think are useful to adopt. If you don't understand it all - that's okay. It's not a MUST. But please feel free to ask if anything is unclear. Structure of the repositories - Official: These branches will be fast-forward only (you cannot rewrite history/commits that have been published to the server). This is what people expect from official branches and the same behaviour as with SVN. Once commits are made you cannot uncommit something - only revert. * master is what trunk used to be. All official development happens there. * For a stabilization branch we will have packagename-version branching off of master. This is analog to the way SVN branches were used in the past. An example would be elementary-1.7 * Git tags will mark the exact commit that was used for a release. As such these commits will usually reside within the release branches or be the starting point for one. Tags will follow the naming scheme vversion, so for example v1.7.5. Topic branches: * In each repository every developer with commit access will be able to push/update branches in their own namespace (devs/name/*). These branches will allow non-fastforward updates and no one should expect these to be stable. * This is a testing ground for developers where new features can be developed, debugged and shared with fellow developers. Ideally any new feature would live in its own branch until it matures and is merged into master. Hey Daniel, It's a nice proposal, but what about master branch permissions ? Every developer would be allowed to push stuff on there (with a flow similar to svn) ? Or we'll try to establish some kind of policy about it (maintainers, review, etc) ? Local branches: * Go nuts. Branches are cheap and merging/rebasing them is easy as well. It's a good way to try out some small things while keeping other development separate. Commits best practices: I will probably be laughed at (at best) or thrown out of the project for bringing this up, but here goes. Because of the way git integrates with email it is encouraged to write a commit message with a one-line summary, a blank line and then a body describing the commit in greater detail. Most of you will ask More than one line? Why would I need more than one line to write 'Fix, fix, spankies!'. You have a point, but I would actually want to push for commit messages that are a little longer than that. I know some will refuse to adopt that, but I would still like to see everyone else setting a good example. If you want a good example of how to write and structure your commits and messages I recommend taking a look at QT. I would be really happy (almost ecstatic with joy) if we could have more commit messages that include the problem and what was done. Example: Fix memory leak in function xyz If the allocation of foo fails the error path doesn't clean up correctly which leads to variable bla being leaked. Clean up correctly and exit. Similarly, the individual commits shouldn't be too large. I don't want you to commit every line change separately, but git allows you to commit a bunch
Re: [E-devel] (no subject)
On Wed, Feb 13, 2013 at 9:36 AM, Bruno Dilly bdi...@profusion.mobi wrote: On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann d.willm...@samsung.com wrote: Hello, beware, the switch to Git will be happening soon! We will migrate efl, elementary and enlightenment one-by-one and send mails with specific details when each will happen. For the time when we are using Git here is a really small list of what you need to change: First setup Git as it will need to know your name and email (global here means per-user) $ git config --global user.name Jane Doe $ git config --global user.email jane...@example.com Useful commands: To get the repository, run $ git clone ssh://g...@phab.enlightenment.org/reponame - (svn checkout) The names will be announced as we switch - the first ones will most likely be core/efl.git, core/elementary.git and core/enlightenment.git To update to the newest version $ git pull --rebase - (svn update) To commit all local changes $ git commit -a $ git push - (svn ci) OR (better) if you just want to commit specific files $ git add files $ git commit $ git push - (svn ci files) Here's more Git for SVN users: http://git-scm.com/course/svn.html If you want to know more I recommend reading (part of) the Git book at http://git-scm.com/book I even recommend reading it if you don't want to know more. A sneak peek of the awesomeness that awaits you at the other side of that link: # Enable color in diffs, etc. (should be default by now) $ git config --global color.ui true # Change your editor if you don't like what $EDITOR points to $ git config --global core.editor vim # Configure shortcuts for commands $ git config --global alias.ci commit These were the very basics of how to work with Git on a technical level. In the following paragraphs I want to introduce some common work flows that I think are useful to adopt. If you don't understand it all - that's okay. It's not a MUST. But please feel free to ask if anything is unclear. Structure of the repositories - Official: These branches will be fast-forward only (you cannot rewrite history/commits that have been published to the server). This is what people expect from official branches and the same behaviour as with SVN. Once commits are made you cannot uncommit something - only revert. * master is what trunk used to be. All official development happens there. * For a stabilization branch we will have packagename-version branching off of master. This is analog to the way SVN branches were used in the past. An example would be elementary-1.7 * Git tags will mark the exact commit that was used for a release. As such these commits will usually reside within the release branches or be the starting point for one. Tags will follow the naming scheme vversion, so for example v1.7.5. Topic branches: * In each repository every developer with commit access will be able to push/update branches in their own namespace (devs/name/*). These branches will allow non-fastforward updates and no one should expect these to be stable. * This is a testing ground for developers where new features can be developed, debugged and shared with fellow developers. Ideally any new feature would live in its own branch until it matures and is merged into master. It's a nice proposal, but what about master branch permissions ? Every developer would be allowed to push stuff on there (with a flow similar to svn) ? Or we'll try to establish some kind of policy about it (maintainers, review, etc) ? We did have some discussion and sharing idea about that during fosdem. The consensus is that we were not ready as a group of developers to move to that kind of organisation. Instead something that maybe would fit us more is a release cycle and development process based on time. 1 week of feature addition 2 week of bug fixing This cycle would be repeated 3 times, then followed by : a release candidate 2 additional weeks of stabilization (maybe another RC) a beta 1 additional week of polishing release (if everything is good of course) Of course we don't start a feature addition cycle if current master branch is unstable. The hope is to be on a more rapid development cycle, but still stable and avoiding glacial era like we have before each release. Finally it should give us a good release every 3 months. It should not change our workflow to much and still be an improvement over our current model. Any though or improvement about it ? Or a better proposal ? -- Cedric BAIL -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list
Re: [E-devel] (no subject)
On Wed, Feb 13, 2013 at 12:18 AM, Cedric BAIL cedric.b...@free.fr wrote: Of course we don't start a feature addition cycle if current master branch is unstable. The hope is to be on a more rapid development cycle, but still stable and avoiding glacial era like we have before each release. Finally it should give us a good release every 3 months. It should not change our workflow to much and still be an improvement over our current model. Any though or improvement about it ? Or a better proposal ? The question was whether we'll all have write permission to the master branch and push stuff there as we do with SVN or if we'll keep our own repositories and have someone(s) integrate them into upstream. -- Cedric BAIL -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
On Wed, 13 Feb 2013 01:00:26 -0200 Iván Briano sachi...@gmail.com wrote: On Wed, Feb 13, 2013 at 12:18 AM, Cedric BAIL cedric.b...@free.fr wrote: Of course we don't start a feature addition cycle if current master branch is unstable. The hope is to be on a more rapid development cycle, but still stable and avoiding glacial era like we have before each release. Finally it should give us a good release every 3 months. It should not change our workflow to much and still be an improvement over our current model. Any though or improvement about it ? Or a better proposal ? The question was whether we'll all have write permission to the master branch and push stuff there as we do with SVN or if we'll keep our own repositories and have someone(s) integrate them into upstream. -- Cedric BAIL Having reviewer(s) who are the only people with commit access to certain repos may work for some side projects that we have, but, despite it being a good idea in theory, there's no real way for us to do it for larger components. We just don't have the manpower for it, and the reviewers, who must then also be our most knowledgeable developers, will immediately be buried with code to review and be unable to do any work of their own. Just ask raster about his backlog if you doubt this. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
On Wed, Feb 13, 2013 at 12:00 PM, Iván Briano sachi...@gmail.com wrote: On Wed, Feb 13, 2013 at 12:18 AM, Cedric BAIL cedric.b...@free.fr wrote: Of course we don't start a feature addition cycle if current master branch is unstable. The hope is to be on a more rapid development cycle, but still stable and avoiding glacial era like we have before each release. Finally it should give us a good release every 3 months. It should not change our workflow to much and still be an improvement over our current model. Any though or improvement about it ? Or a better proposal ? The question was whether we'll all have write permission to the master branch and push stuff there as we do with SVN or if we'll keep our own repositories and have someone(s) integrate them into upstream. My answer is maybe not clear enough, but nobody will be a gate keeper in that proposal. We will rely on developer good will. -- Cedric BAIL -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
On Wed, 13 Feb 2013 12:08:44 +0900 Cedric BAIL cedric.b...@free.fr said: On Wed, Feb 13, 2013 at 12:00 PM, Iván Briano sachi...@gmail.com wrote: On Wed, Feb 13, 2013 at 12:18 AM, Cedric BAIL cedric.b...@free.fr wrote: Of course we don't start a feature addition cycle if current master branch is unstable. The hope is to be on a more rapid development cycle, but still stable and avoiding glacial era like we have before each release. Finally it should give us a good release every 3 months. It should not change our workflow to much and still be an improvement over our current model. Any though or improvement about it ? Or a better proposal ? The question was whether we'll all have write permission to the master branch and push stuff there as we do with SVN or if we'll keep our own repositories and have someone(s) integrate them into upstream. My answer is maybe not clear enough, but nobody will be a gate keeper in that proposal. We will rely on developer good will. yes - no gatekeepers. you either have push access (equivalent to svn commit access), play nice and behave (or be kicked out of having access), or you do not (and then you submit patches). -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
On Wed, 13 Feb 2013 12:35:10 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Wed, 13 Feb 2013 12:08:44 +0900 Cedric BAIL cedric.b...@free.fr said: On Wed, Feb 13, 2013 at 12:00 PM, Iván Briano sachi...@gmail.com wrote: On Wed, Feb 13, 2013 at 12:18 AM, Cedric BAIL cedric.b...@free.fr wrote: Of course we don't start a feature addition cycle if current master branch is unstable. The hope is to be on a more rapid development cycle, but still stable and avoiding glacial era like we have before each release. Finally it should give us a good release every 3 months. It should not change our workflow to much and still be an improvement over our current model. Any though or improvement about it ? Or a better proposal ? The question was whether we'll all have write permission to the master branch and push stuff there as we do with SVN or if we'll keep our own repositories and have someone(s) integrate them into upstream. My answer is maybe not clear enough, but nobody will be a gate keeper in that proposal. We will rely on developer good will. yes - no gatekeepers. you either have push access (equivalent to svn commit access), play nice and behave (or be kicked out of having access), or you do not (and then you submit patches). Business as usual, and it's worked OK for us so far. Should keep working for us. Don't think we have ever kicked out anyone from SVN access? Not counting those that kicked themselves out. -- 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 -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
On Wed, 13 Feb 2013 13:53:35 +1000 David Seikel onef...@gmail.com said: On Wed, 13 Feb 2013 12:35:10 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Wed, 13 Feb 2013 12:08:44 +0900 Cedric BAIL cedric.b...@free.fr said: On Wed, Feb 13, 2013 at 12:00 PM, Iván Briano sachi...@gmail.com wrote: On Wed, Feb 13, 2013 at 12:18 AM, Cedric BAIL cedric.b...@free.fr wrote: Of course we don't start a feature addition cycle if current master branch is unstable. The hope is to be on a more rapid development cycle, but still stable and avoiding glacial era like we have before each release. Finally it should give us a good release every 3 months. It should not change our workflow to much and still be an improvement over our current model. Any though or improvement about it ? Or a better proposal ? The question was whether we'll all have write permission to the master branch and push stuff there as we do with SVN or if we'll keep our own repositories and have someone(s) integrate them into upstream. My answer is maybe not clear enough, but nobody will be a gate keeper in that proposal. We will rely on developer good will. yes - no gatekeepers. you either have push access (equivalent to svn commit access), play nice and behave (or be kicked out of having access), or you do not (and then you submit patches). Business as usual, and it's worked OK for us so far. Should keep working for us. Don't think we have ever kicked out anyone from SVN access? Not counting those that kicked themselves out. correct. if it ain't broke, don't fix it. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] (no subject)
Hello, beware, the switch to Git will be happening soon! We will migrate efl, elementary and enlightenment one-by-one and send mails with specific details when each will happen. For the time when we are using Git here is a really small list of what you need to change: First setup Git as it will need to know your name and email (global here means per-user) $ git config --global user.name Jane Doe $ git config --global user.email jane...@example.com Useful commands: To get the repository, run $ git clone ssh://g...@phab.enlightenment.org/reponame - (svn checkout) The names will be announced as we switch - the first ones will most likely be core/efl.git, core/elementary.git and core/enlightenment.git To update to the newest version $ git pull --rebase - (svn update) To commit all local changes $ git commit -a $ git push - (svn ci) OR (better) if you just want to commit specific files $ git add files $ git commit $ git push - (svn ci files) Here's more Git for SVN users: http://git-scm.com/course/svn.html If you want to know more I recommend reading (part of) the Git book at http://git-scm.com/book I even recommend reading it if you don't want to know more. A sneak peek of the awesomeness that awaits you at the other side of that link: # Enable color in diffs, etc. (should be default by now) $ git config --global color.ui true # Change your editor if you don't like what $EDITOR points to $ git config --global core.editor vim # Configure shortcuts for commands $ git config --global alias.ci commit These were the very basics of how to work with Git on a technical level. In the following paragraphs I want to introduce some common work flows that I think are useful to adopt. If you don't understand it all - that's okay. It's not a MUST. But please feel free to ask if anything is unclear. Structure of the repositories - Official: These branches will be fast-forward only (you cannot rewrite history/commits that have been published to the server). This is what people expect from official branches and the same behaviour as with SVN. Once commits are made you cannot uncommit something - only revert. * master is what trunk used to be. All official development happens there. * For a stabilization branch we will have packagename-version branching off of master. This is analog to the way SVN branches were used in the past. An example would be elementary-1.7 * Git tags will mark the exact commit that was used for a release. As such these commits will usually reside within the release branches or be the starting point for one. Tags will follow the naming scheme vversion, so for example v1.7.5. Topic branches: * In each repository every developer with commit access will be able to push/update branches in their own namespace (devs/name/*). These branches will allow non-fastforward updates and no one should expect these to be stable. * This is a testing ground for developers where new features can be developed, debugged and shared with fellow developers. Ideally any new feature would live in its own branch until it matures and is merged into master. Local branches: * Go nuts. Branches are cheap and merging/rebasing them is easy as well. It's a good way to try out some small things while keeping other development separate. Commits best practices: I will probably be laughed at (at best) or thrown out of the project for bringing this up, but here goes. Because of the way git integrates with email it is encouraged to write a commit message with a one-line summary, a blank line and then a body describing the commit in greater detail. Most of you will ask More than one line? Why would I need more than one line to write 'Fix, fix, spankies!'. You have a point, but I would actually want to push for commit messages that are a little longer than that. I know some will refuse to adopt that, but I would still like to see everyone else setting a good example. If you want a good example of how to write and structure your commits and messages I recommend taking a look at QT. I would be really happy (almost ecstatic with joy) if we could have more commit messages that include the problem and what was done. Example: Fix memory leak in function xyz If the allocation of foo fails the error path doesn't clean up correctly which leads to variable bla being leaked. Clean up correctly and exit. Similarly, the individual commits shouldn't be too large. I don't want you to commit every line change separately, but git allows you to commit a bunch of stuff locally before pushing it upstream. What was one large commit in SVN can be broken up into several smaller ones in Git. This makes commits much easier to review (as does a proper commit message, hint, hint). If you do have a larger feature that requires tens of commits please don't just dump them into upstream Git at once, but develop them publicly in a topic branch (see topic branches) and merge them when they are
Re: [E-devel] (no subject)
As a humble e tester many thanks for the info. Tarball -cvs -svn - git. still enjoying the ride and the result! Cheers M On 11 February 2013 17:07, Daniel Willmann d.willm...@samsung.com wrote: Hello, beware, the switch to Git will be happening soon! We will migrate efl, elementary and enlightenment one-by-one and send mails with specific details when each will happen. For the time when we are using Git here is a really small list of what you need to change: First setup Git as it will need to know your name and email (global here means per-user) $ git config --global user.name Jane Doe $ git config --global user.email jane...@example.com Useful commands: To get the repository, run $ git clone ssh://g...@phab.enlightenment.org/reponame - (svn checkout) The names will be announced as we switch - the first ones will most likely be core/efl.git, core/elementary.git and core/enlightenment.git To update to the newest version $ git pull --rebase - (svn update) To commit all local changes $ git commit -a $ git push - (svn ci) OR (better) if you just want to commit specific files $ git add files $ git commit $ git push - (svn ci files) Here's more Git for SVN users: http://git-scm.com/course/svn.html If you want to know more I recommend reading (part of) the Git book at http://git-scm.com/book I even recommend reading it if you don't want to know more. A sneak peek of the awesomeness that awaits you at the other side of that link: # Enable color in diffs, etc. (should be default by now) $ git config --global color.ui true # Change your editor if you don't like what $EDITOR points to $ git config --global core.editor vim # Configure shortcuts for commands $ git config --global alias.ci commit These were the very basics of how to work with Git on a technical level. In the following paragraphs I want to introduce some common work flows that I think are useful to adopt. If you don't understand it all - that's okay. It's not a MUST. But please feel free to ask if anything is unclear. Structure of the repositories - Official: These branches will be fast-forward only (you cannot rewrite history/commits that have been published to the server). This is what people expect from official branches and the same behaviour as with SVN. Once commits are made you cannot uncommit something - only revert. * master is what trunk used to be. All official development happens there. * For a stabilization branch we will have packagename-version branching off of master. This is analog to the way SVN branches were used in the past. An example would be elementary-1.7 * Git tags will mark the exact commit that was used for a release. As such these commits will usually reside within the release branches or be the starting point for one. Tags will follow the naming scheme vversion, so for example v1.7.5. Topic branches: * In each repository every developer with commit access will be able to push/update branches in their own namespace (devs/name/*). These branches will allow non-fastforward updates and no one should expect these to be stable. * This is a testing ground for developers where new features can be developed, debugged and shared with fellow developers. Ideally any new feature would live in its own branch until it matures and is merged into master. Local branches: * Go nuts. Branches are cheap and merging/rebasing them is easy as well. It's a good way to try out some small things while keeping other development separate. Commits best practices: I will probably be laughed at (at best) or thrown out of the project for bringing this up, but here goes. Because of the way git integrates with email it is encouraged to write a commit message with a one-line summary, a blank line and then a body describing the commit in greater detail. Most of you will ask More than one line? Why would I need more than one line to write 'Fix, fix, spankies!'. You have a point, but I would actually want to push for commit messages that are a little longer than that. I know some will refuse to adopt that, but I would still like to see everyone else setting a good example. If you want a good example of how to write and structure your commits and messages I recommend taking a look at QT. I would be really happy (almost ecstatic with joy) if we could have more commit messages that include the problem and what was done. Example: Fix memory leak in function xyz If the allocation of foo fails the error path doesn't clean up correctly which leads to variable bla being leaked. Clean up correctly and exit. Similarly, the individual commits shouldn't be too large. I don't want you to commit every line change separately, but git allows you to commit a bunch of stuff locally before pushing it upstream. What was one large commit in SVN can be broken up into several smaller ones in Git.
[E-devel] (no subject)
anyone here who knows how to start development using efl in vala? I have access to vapi files, i just don't know how to use it yet... I will also appreciate it if anyone can instruct me on using vapi files thank you :) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
2012/3/3 Michael Blumenkrantz michael.blumenkra...@gmail.com:
On Sat, 3 Mar 2012 13:19:24 +0900
Bluezery ohpo...@gmail.com wrote:
Hello,
This patch is for reading socks version5 proxy from global variables.
This is almost same as previous socks version4.
discomfitor can help to review this patch.
Thanks.
hmm I could be reading this wrong, but it looks to me that this does not allow
for socks4a (proxy DNS lookups) inheritance from global proxies? other than
that it looks good
I add checking socks4a protocol.
I cannot find exactly what is socks5h protocol.
But I think that socks5h (CURLPROXY_SOCKS5_HOSTNAME) may be enhanced
sock5 for resolving such as socks4a.
So socks5h checking is also added.
Anyway, I am sorry for no title and duplicated mail. :(
--
BRs,
Kim.
Index: src/lib/ecore_con/ecore_con_url.c
===
--- src/lib/ecore_con/ecore_con_url.c (리비전 68637)
+++ src/lib/ecore_con/ecore_con_url.c (작업 사본)
@@ -151,6 +151,8 @@ ecore_con_url_pipeline_get(void)
return EINA_FALSE;
}
+extern Ecore_Con_Socks *_ecore_con_proxy_global;
+
EAPI Ecore_Con_Url *
ecore_con_url_new(const char *url)
{
@@ -182,22 +184,41 @@ ecore_con_url_new(const char *url)
return NULL;
}
+ // Read socks proxy
url_con-proxy_type = -1;
- if (_ecore_con_proxy_global)
+ if (_ecore_con_proxy_global _ecore_con_proxy_global-ip
+ (_ecore_con_proxy_global-version == 4 ||
+_ecore_con_proxy_global-version == 5))
{
-if (_ecore_con_proxy_global-ip)
+char proxy[256];
+char host[256];
+
+if (_ecore_con_proxy_global-version == 5)
{
- char host[128];
- if (_ecore_con_proxy_global-port 0
- _ecore_con_proxy_global-port = 65535)
- snprintf(host, sizeof(host), socks4://%s:%d,
-_ecore_con_proxy_global-ip,
-_ecore_con_proxy_global-port);
- else
- snprintf(host, sizeof(host), socks4://%s,
-_ecore_con_proxy_global-ip);
- ecore_con_url_proxy_set(url_con, host);
+ if (_ecore_con_proxy_global-lookup)
+snprintf(host, sizeof(host), socks5h://%s,
+ _ecore_con_proxy_global-ip);
+ else snprintf(host, sizeof(host), socks5://%s,
+ _ecore_con_proxy_global-ip);
+ }
+else if (_ecore_con_proxy_global-version == 4)
+ {
+ if (_ecore_con_proxy_global-lookup)
+snprintf(host, sizeof(host), socks4a://%s,
+ _ecore_con_proxy_global-ip);
+ else snprintf(host, sizeof(host), socks4://%s,
+ _ecore_con_proxy_global-ip);
}
+
+if (_ecore_con_proxy_global-port 0
+_ecore_con_proxy_global-port = 65535)
+ snprintf(proxy, sizeof(proxy), %s:%d, host,
+_ecore_con_proxy_global-port);
+else snprintf(proxy, sizeof(proxy), %s, host);
+
+ecore_con_url_proxy_set(url_con, proxy);
+ecore_con_url_proxy_username_set(url_con,
+ _ecore_con_proxy_global-username);
}
ret = curl_easy_setopt(url_con-curl_easy, CURLOPT_ENCODING, gzip,deflate);
@@ -1118,17 +1139,20 @@ ecore_con_url_proxy_set(Ecore_Con_Url *u
if (vers-version_num 0x71507)
{
url_con-proxy_type = CURLPROXY_HTTP;
- if (strstr(proxy, socks4)) url_con-proxy_type = CURLPROXY_SOCKS4;
- else if (strstr(proxy, socks4a))
+ if (strstr(proxy, socks4a))
url_con-proxy_type = CURLPROXY_SOCKS4A;
- else if (strstr(proxy, socks5))
- url_con-proxy_type = CURLPROXY_SOCKS5;
+ else if (strstr(proxy, socks4))
+ url_con-proxy_type = CURLPROXY_SOCKS4;
else if (strstr(proxy, socks5h))
url_con-proxy_type = CURLPROXY_SOCKS5_HOSTNAME;
- res = curl_easy_setopt(url_con-curl_easy, CURLOPT_PROXYTYPE, url_con-proxy_type);
+ else if (strstr(proxy, socks5))
+ url_con-proxy_type = CURLPROXY_SOCKS5;
+ res = curl_easy_setopt(url_con-curl_easy, CURLOPT_PROXYTYPE,
+url_con-proxy_type);
if (res != CURLE_OK)
{
- ERR(curl proxy type setting failed: %s, curl_easy_strerror(res));
+ ERR(curl proxy type setting failed: %s,
+ curl_easy_strerror(res));
url_con-proxy_type = -1;
return EINA_FALSE;
}
@@ -1253,6 +1277,7 @@ _ecore_con_url_event_url_complete(Ecore_
if (curlmsg (curlmsg-data.result == CURLE_OK))
curl_easy_getinfo(curlmsg-easy_handle, CURLINFO_RESPONSE_CODE, status);
+ else ERR(Curl message have errors: %d,
Re: [E-devel] (no subject)
On Sat, 3 Mar 2012 23:02:58 +0900 Bluezery ohpo...@gmail.com wrote: 2012/3/3 Michael Blumenkrantz michael.blumenkra...@gmail.com: On Sat, 3 Mar 2012 13:19:24 +0900 Bluezery ohpo...@gmail.com wrote: Hello, This patch is for reading socks version5 proxy from global variables. This is almost same as previous socks version4. discomfitor can help to review this patch. Thanks. hmm I could be reading this wrong, but it looks to me that this does not allow for socks4a (proxy DNS lookups) inheritance from global proxies? other than that it looks good I add checking socks4a protocol. I cannot find exactly what is socks5h protocol. But I think that socks5h (CURLPROXY_SOCKS5_HOSTNAME) may be enhanced sock5 for resolving such as socks4a. So socks5h checking is also added. Anyway, I am sorry for no title and duplicated mail. :( Good patch, committed. You are correct, socks5h is just socks5 with proxy DNS. It is not an actual protocol, just the name that the author of cURL gave to socks5 with hostname lookup because there is no name since it is just part of base socks5. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] (no subject)
Hello,
This patch is for reading socks version5 proxy from global variables.
This is almost same as previous socks version4.
discomfitor can help to review this patch.
Thanks.
--
BRs,
Kim.
Index: src/lib/ecore_con/ecore_con_url.c
===
--- src/lib/ecore_con/ecore_con_url.c (리비전 68637)
+++ src/lib/ecore_con/ecore_con_url.c (작업 사본)
@@ -151,6 +151,8 @@ ecore_con_url_pipeline_get(void)
return EINA_FALSE;
}
+extern Ecore_Con_Socks *_ecore_con_proxy_global;
+
EAPI Ecore_Con_Url *
ecore_con_url_new(const char *url)
{
@@ -182,22 +184,31 @@ ecore_con_url_new(const char *url)
return NULL;
}
+ // Read socks proxy
url_con-proxy_type = -1;
- if (_ecore_con_proxy_global)
- {
-if (_ecore_con_proxy_global-ip)
- {
- char host[128];
- if (_ecore_con_proxy_global-port 0
- _ecore_con_proxy_global-port = 65535)
- snprintf(host, sizeof(host), socks4://%s:%d,
-_ecore_con_proxy_global-ip,
-_ecore_con_proxy_global-port);
- else
- snprintf(host, sizeof(host), socks4://%s,
-_ecore_con_proxy_global-ip);
- ecore_con_url_proxy_set(url_con, host);
- }
+ if (_ecore_con_proxy_global _ecore_con_proxy_global-ip
+ (_ecore_con_proxy_global-version == 4 ||
+_ecore_con_proxy_global-version == 5))
+ {
+char proxy[256];
+char host[256];
+
+if (_ecore_con_proxy_global-version == 5)
+ snprintf(host, sizeof(host), socks5://%s,
+_ecore_con_proxy_global-ip);
+else if (_ecore_con_proxy_global-version == 4)
+ snprintf(host, sizeof(host), socks4://%s,
+_ecore_con_proxy_global-ip);
+
+if (_ecore_con_proxy_global-port 0
+_ecore_con_proxy_global-port = 65535)
+ snprintf(proxy, sizeof(proxy), %s:%d, host,
+_ecore_con_proxy_global-port);
+else snprintf(proxy, sizeof(proxy), %s, host);
+
+ecore_con_url_proxy_set(url_con, proxy);
+ecore_con_url_proxy_username_set(url_con,
+ _ecore_con_proxy_global-username);
}
ret = curl_easy_setopt(url_con-curl_easy, CURLOPT_ENCODING, gzip,deflate);
@@ -1118,17 +1129,20 @@ ecore_con_url_proxy_set(Ecore_Con_Url *u
if (vers-version_num 0x71507)
{
url_con-proxy_type = CURLPROXY_HTTP;
- if (strstr(proxy, socks4)) url_con-proxy_type = CURLPROXY_SOCKS4;
- else if (strstr(proxy, socks4a))
+ if (strstr(proxy, socks4a))
url_con-proxy_type = CURLPROXY_SOCKS4A;
- else if (strstr(proxy, socks5))
- url_con-proxy_type = CURLPROXY_SOCKS5;
+ else if (strstr(proxy, socks4))
+ url_con-proxy_type = CURLPROXY_SOCKS4;
else if (strstr(proxy, socks5h))
url_con-proxy_type = CURLPROXY_SOCKS5_HOSTNAME;
- res = curl_easy_setopt(url_con-curl_easy, CURLOPT_PROXYTYPE, url_con-proxy_type);
+ else if (strstr(proxy, socks5))
+ url_con-proxy_type = CURLPROXY_SOCKS5;
+ res = curl_easy_setopt(url_con-curl_easy, CURLOPT_PROXYTYPE,
+url_con-proxy_type);
if (res != CURLE_OK)
{
- ERR(curl proxy type setting failed: %s, curl_easy_strerror(res));
+ ERR(curl proxy type setting failed: %s,
+ curl_easy_strerror(res));
url_con-proxy_type = -1;
return EINA_FALSE;
}
@@ -1253,6 +1267,7 @@ _ecore_con_url_event_url_complete(Ecore_
if (curlmsg (curlmsg-data.result == CURLE_OK))
curl_easy_getinfo(curlmsg-easy_handle, CURLINFO_RESPONSE_CODE, status);
+ else ERR(Curl message have errors: %d, curlmsg-data.result);
e-status = status;
e-url_con = url_con;
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
On Sat, 3 Mar 2012 13:19:24 +0900 Bluezery ohpo...@gmail.com wrote: Hello, This patch is for reading socks version5 proxy from global variables. This is almost same as previous socks version4. discomfitor can help to review this patch. Thanks. hmm I could be reading this wrong, but it looks to me that this does not allow for socks4a (proxy DNS lookups) inheritance from global proxies? other than that it looks good -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
Thanks. I just removed 'libglu1-xorg-dev' from that page. Daniel Juyung Seo (SeoZ) On Thu, May 5, 2011 at 6:52 PM, sangho park gouach...@gmail.com wrote: you can find the change log on xorg source package. xorg (1:7.6+4ubuntu1) natty; urgency=low [ Timo Aaltonen ] * Merge from Debian unstable. Remaining Ubuntu changes: ... * Removed transitional xlibmesa-gl*, libglu1-* packages, they have only 'Suggests' or 'Recommends' rdepends left, and other packages available that replace them. Date: Thu, 5 May 2011 11:29:59 +0900 From: Daniel Juyung Seo seojuyu...@gmail.com Subject: [E-devel] (no subject) To: enlightenment-devel@lists.sourceforge.net Message-ID: banlktinwdquoxhoaym+xmbnofmrnbgb...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi, I can't find libglu1-xorg-dev package in my Ubuntu 11.04 machine. It's described in http://trac.enlightenment.org/e/wiki/Ubuntu Any reason? Thanks. Daniel Juyung Seo (SeoZ) -- -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
maybe the name is a bit different 2011/5/5 Daniel Juyung Seo seojuyu...@gmail.com Oops. (no subject). My bad :) Daniel Juyung Seo (SeoZ) On Thu, May 5, 2011 at 11:29 AM, Daniel Juyung Seo seojuyu...@gmail.com wrote: Hi, I can't find libglu1-xorg-dev package in my Ubuntu 11.04 machine. It's described in http://trac.enlightenment.org/e/wiki/Ubuntu Any reason? Thanks. Daniel Juyung Seo (SeoZ) -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Regards. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
2011/5/5 Daniel Juyung Seo seojuyu...@gmail.com Hi, I can't find libglu1-xorg-dev package in my Ubuntu 11.04 machine. It's described in http://trac.enlightenment.org/e/wiki/Ubuntu Any reason? Thanks. Daniel Juyung Seo (SeoZ) -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel maybe this one : libglu1-mesa-dev -- Nicolas Aguirre Mail: aguirre.nico...@gmail.com Web: http://enna.geexbox.org Blog: http://dev.enlightenment.fr/~captainigloo/ -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
you can find the change log on xorg source package. xorg (1:7.6+4ubuntu1) natty; urgency=low [ Timo Aaltonen ] * Merge from Debian unstable. Remaining Ubuntu changes: ... * Removed transitional xlibmesa-gl*, libglu1-* packages, they have only 'Suggests' or 'Recommends' rdepends left, and other packages available that replace them. Date: Thu, 5 May 2011 11:29:59 +0900 From: Daniel Juyung Seo seojuyu...@gmail.com Subject: [E-devel] (no subject) To: enlightenment-devel@lists.sourceforge.net Message-ID: banlktinwdquoxhoaym+xmbnofmrnbgb...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi, I can't find libglu1-xorg-dev package in my Ubuntu 11.04 machine. It's described in http://trac.enlightenment.org/e/wiki/Ubuntu Any reason? Thanks. Daniel Juyung Seo (SeoZ) -- -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] (no subject)
Hi, I can't find libglu1-xorg-dev package in my Ubuntu 11.04 machine. It's described in http://trac.enlightenment.org/e/wiki/Ubuntu Any reason? Thanks. Daniel Juyung Seo (SeoZ) -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
Oops. (no subject). My bad :) Daniel Juyung Seo (SeoZ) On Thu, May 5, 2011 at 11:29 AM, Daniel Juyung Seo seojuyu...@gmail.com wrote: Hi, I can't find libglu1-xorg-dev package in my Ubuntu 11.04 machine. It's described in http://trac.enlightenment.org/e/wiki/Ubuntu Any reason? Thanks. Daniel Juyung Seo (SeoZ) -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] (no subject)
Dear Elementary developers.
It's a bugfix patch and adding new functionality for wrapmode changing at
elm_label.
1. bugfix strbuf_key_value_replace which is internal function
2. add wrapmode change api (wordwrap or charwrap)
Thank you.
---
Hyoyoung CHANG
Engineer
SAMSUNG ELECTRONICS, Co., Ltd.
E-mail: hyoyoung.ch...@samsung.com
---
From 08a36f6733ca41668a9e4b38ba95bf3c92abfab6 Mon Sep 17 00:00:00 2001
From: Hyoyoung Chang hyoyoung.ch...@samsung.com
Date: Tue, 11 Jan 2011 15:17:08 +0900
Subject: [PATCH 2/3] bugfix and improve tag searching in
_strbuf_key_value_replace
---
src/lib/elm_label.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/src/lib/elm_label.c b/src/lib/elm_label.c
index 5240cec..288e7de 100644
--- a/src/lib/elm_label.c
+++ b/src/lib/elm_label.c
@@ -260,17 +260,12 @@ _strbuf_key_value_replace(Eina_Strbuf *srcbuf, const char
*key, const char *valu
if (curlocater)
{
replocater = curlocater + key_len + 1;
- while ((*replocater != '=') (replocater))
-replocater++;
- while ((*replocater)
- (*replocater != ' ')
- (*replocater != ''))
+ while ((*replocater) (*replocater != ' ') (*replocater
!= ''))
replocater++;
- if ((replocater - curlocater) (key_len + 1))
+ if (replocater - curlocater key_len)
{
- replocater--;
eina_strbuf_append_n(diffbuf, curlocater,
replocater-curlocater);
}
--
1.7.1
From d1af20b5e33f773048d810fb8d2b24eafe88c88e Mon Sep 17 00:00:00 2001
From: Hyoyoung Chang hyoyoung.ch...@samsung.com
Date: Tue, 11 Jan 2011 15:33:18 +0900
Subject: [PATCH 3/3] add wrapmode changing API
---
data/themes/default.edc | 49 +++
src/lib/Elementary.h.in |2 +
src/lib/elm_label.c | 59 +++
3 files changed, 110 insertions(+), 0 deletions(-)
diff --git a/data/themes/default.edc b/data/themes/default.edc
index e457e5d..330abb1 100644
--- a/data/themes/default.edc
+++ b/data/themes/default.edc
@@ -1403,6 +1403,14 @@ collections {
tag: b + font=Sans:style=Bold;
tag: tab \t;
}
+ style { name: textblock_charwrap_style;
+base: font=Sans font_size=10 color=#000 wrap=char
text_class=label;
+tag: br \n;
+tag: ps ps;
+tag: hilight + font=Sans:style=Bold;
+tag: b + font=Sans:style=Bold;
+tag: tab \t;
+ }
}
parts {
part { name: label.swallow.background;
@@ -1458,8 +1466,28 @@ collections {
min: 0 1;
}
}
+ description { state: charwrap_mode 0.0;
+ text {
+ style: textblock_style;
+ min: 0 1;
+ }
+ }
}
}
+ programs {
+ program { name: default_wrap;
+signal: elm,state,default;
+source: elm;
+action: STATE_SET default 0.0;
+target: elm.text;
+ }
+ program { name: char_wrap;
+signal: elm,state,charwrap;
+source: elm;
+action: STATE_SET charwrap_mode 0.0;
+target: elm.text;
+ }
+ }
}
group { name: elm/label/base_wrap_ellipsis/default;
@@ -1487,8 +1515,29 @@ collections {
min: 0 1;
}
}
+ description { state: charwrap_mode 0.0;
+ fixed: 0 1;
+ text {
+ style: textblock_charwrap_style;
+ min: 0 1;
+ }
+ }
}
}
+ programs {
+ program { name: default_wrap;
+signal: elm,state,default;
+source: elm;
+action: STATE_SET default 0.0;
+target: elm.text;
+ }
+ program { name: char_wrap;
+signal: elm,state,charwrap;
+source: elm;
+action: STATE_SET charwrap_mode 0.0;
+target: elm.text;
+ }
+ }
}
group { name: elm/label/base/marker;
diff --git a/src/lib/Elementary.h.in b/src/lib/Elementary.h.in
index 8e6bba3..722a3cd 100644
--- a/src/lib/Elementary.h.in
+++ b/src/lib/Elementary.h.in
@@ -813,6 +813,8 @@ extern C {
EAPI void elm_label_text_align_set(Evas_Object *obj, const char
*alignmode) EINA_ARG_NONNULL(1);
EAPI void elm_label_background_color_set(Evas_Object *obj, unsigned
int r, unsigned int g, unsigned int b, unsigned int a) EINA_ARG_NONNULL(1);
EAPI void
[E-devel] (no subject)
Hello there.
This is a small patch for elm_animator.
Please review and apply this to upstream.
The main modification are as follows.
1. Since the concept of curve in/out was wrong, those functions are
rearranged. It was just my mistake. You can find the operation order of
elm_animator_curve_in_out is reversed in origin code.
2. Added Dog-tag field for safe using.
Thank you.
Hermet
Index: elm_animator.c
===
--- elm_animator.c (revision 54276)
+++ elm_animator.c (working copy)
@@ -7,9 +7,11 @@
*
* Support normalized frame value for animation.
*/
+#define MAGIC_OBJ_ANIMATOR 0x4070
struct _Animator
{
+ int magic;
Evas_Object *parent;
Ecore_Animator *animator;
double begin_time;
@@ -34,7 +36,9 @@ static unsigned int _animator_compute_reverse_repe
static unsigned int _animator_compute_no_reverse_repeat_count(unsigned int
cnt);
static Eina_Bool _animator_animate_cb(void *data);
static void _delete_animator(Elm_Animator *animator);
-static void _animator_parent_del(void *data, Evas *evas, Evas_Object *obj,
void *event);
+static void _animator_parent_del(void *data, Evas *evas __UNUSED__,
+Evas_Object *obj __UNUSED__,
+void *event __UNUSED__);
static unsigned int
_animator_compute_reverse_repeat_count(unsigned int cnt)
@@ -58,21 +62,21 @@ static double
_animator_curve_in_out(double frame)
{
if (frame 0.5)
- return _animator_curve_out(frame * 2) * 0.5;
+ return _animator_curve_in(frame * 2) * 0.5;
else
- return (_animator_curve_in(frame * 2 - 1) * 0.5) + 0.5;
+ return (_animator_curve_out(frame * 2 - 1) * 0.5) + 0.5;
}
static double
_animator_curve_in(double frame)
{
- return sqrt(1 - pow(frame - 1, 2));
+ return 1 - sqrt(1 - pow(frame, 2));
}
static double
_animator_curve_out(double frame)
{
- return 1 - sqrt(1 - pow(frame, 2));
+ return sqrt(1 - pow(frame - 1, 2));
}
static void
@@ -88,29 +92,31 @@ _delete_animator(Elm_Animator *animator)
static Eina_Bool
_animator_animate_cb(void *data)
{
- Elm_Animator *animator = (Elm_Animator *) data;
+ double elapsed_time, frame;
+ Elm_Animator *animator = (Elm_Animator *) data;
animator-cur_time = ecore_loop_time_get();
- double elapsed_time = animator-cur_time - animator-begin_time;
+ elapsed_time = animator-cur_time - animator-begin_time;
+
if (elapsed_time animator-duration)
- elapsed_time = animator-duration;
+ elapsed_time = animator-duration;
- double frame = animator-curve_op(elapsed_time / animator-duration);
+ frame = animator-curve_op(elapsed_time / animator-duration);
//Reverse?
if (animator-auto_reverse)
{
if (!(animator-cur_repeat_cnt % 2))
- frame = 1 - frame;
+ frame = 1 - frame;
}
if (animator-duration 0)
- animator-animator_op(animator-animator_arg, animator, frame);
+ animator-animator_op(animator-animator_arg, animator, frame);
//Not end. Keep going.
if (elapsed_time animator-duration)
- return ECORE_CALLBACK_RENEW;
+ return ECORE_CALLBACK_RENEW;
//Repeat and reverse and time done!
if (!animator-cur_repeat_cnt)
@@ -118,7 +124,7 @@ _animator_animate_cb(void *data)
animator-on_animating = EINA_FALSE;
_delete_animator(animator);
if (animator-completion_op)
- animator-completion_op(animator-completion_arg);
+ animator-completion_op(animator-completion_arg);
return ECORE_CALLBACK_CANCEL;
}
@@ -129,8 +135,9 @@ _animator_animate_cb(void *data)
return ECORE_CALLBACK_RENEW;
}
-static void
-_animator_parent_del(void *data, Evas *evas __UNUSED__, Evas_Object *obj
__UNUSED__, void *event __UNUSED__)
+static void
+_animator_parent_del(void *data, Evas *evas __UNUSED__,
+Evas_Object *obj __UNUSED__, void *event __UNUSED__)
{
elm_animator_del(data);
}
@@ -138,7 +145,7 @@ _animator_animate_cb(void *data)
/**
* Get the value of reverse mode.
*
- * @param animator Animator object
+ * @param[in] animator Animator object
* @return EINA_TRUE is reverse mode
*
* @ingroup Animator
@@ -146,14 +153,15 @@ _animator_animate_cb(void *data)
EAPI Eina_Bool
elm_animator_auto_reverse_get(const Elm_Animator *animator)
{
- if (!animator) return EINA_FALSE;
+ if (!animator || (animator-magic != MAGIC_OBJ_ANIMATOR))
+ return EINA_FALSE;
return animator-auto_reverse;
}
/**
* Get the value of repeat count.
*
- * @param animator Animator object
+ * @param[in] animator Animator object
* @return Repeat count
*
* @ingroup Animator
@@ -161,63 +169,68 @@ elm_animator_auto_reverse_get(const Elm_Animator *
EAPI unsigned int
elm_animator_repeat_get(const Elm_Animator *animator)
{
- if (!animator) return EINA_FALSE;
+ if (!animator || (animator-magic !=
[E-devel] (no subject)
Heres a little patch to add a 'Favorites' button to EFM_nav. The icon is taken from the default theme for favorite. Big thanks to ptomaine for making the home path easier to find :) The code could do with a review since it was just a copy n paste hack to be honest. Thanks, Toma. (Lets try this again with an upload.) http://members.iinet.net.au/~haste/e17/efm_nav_fav.tar.gz - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
In cvs, slightly modified. Thanks :) Toma wrote: Heres a little patch to add a 'Favorites' button to EFM_nav. The icon is taken from the default theme for favorite. Big thanks to ptomaine for making the home path easier to find :) The code could do with a review since it was just a copy n paste hack to be honest. Thanks, Toma. (Lets try this again with an upload.) http://members.iinet.net.au/~haste/e17/efm_nav_fav.tar.gz - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] (no subject)
Project: Eterm: CVS https://sourceforge.net/cvs/?group_id=212 On sourceforge.net Under the section for Anonymous CVS Access it says web-based CVS repository viewer. I know it says it right after ..to see which modules are available.. but your eye gets drawn to the highlighted phrase and that link goes to the cvs repository for the www site: http://cvs.sourceforge.net/viewcvs.py/eterm/ RiverRat on #Edevelop, -- Tres --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] (no subject)
Hi there, I recently installed e17 from cvs, and have a couple of problems I wanted to report! I checked the TODO list, and found my first one: * sometimes windows that get shut down/closed get unparented but the whole border stays around - something is keeping extra references maybe? it is hidden, until you flip desktops then it appears again - but with no client around. currently they have a dangling reference - need to find out WHO added that ref and didnt remove it (i haven't seen this for ages now) I'm only writing because of that last bit in brackets ;) What happens is that when I close windows like terminals or firefox by clicking in the X in the top right hand corner of the window, it seems to close, but remains in the Window list dialogue in the menu, and in the ALT TAB list. If I switch desktops I see the window frame, with the top bar flashing red. I can then minimise it but NOT close it. ok, second issue is simply that when i start emblem, it crashes. I've tried nuking ~/.e and rebuilding enlightenment from cvs but it still happens. Essentially, when i open it, I see no images (even if I add some background files to ~/.e/e/backgrounds/) and if I drag the window it distorts. I can't click on anything. I can however close it without problems. Hope this helps!! Feel free to ask me for any further clarifications. Matt --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] (no subject)
[EMAIL PROTECTED] Cc: Bcc: Subject: Re: [E-devel] e16.6 is out Reply-To: In-Reply-To: [EMAIL PROTECTED] On Thu 06 Nov 2003, Carsten Haitzler wrote: On Thu, 06 Nov 2003 01:03:44 +0100 Kim Woelders [EMAIL PROTECTED] babbled: Changes since e16.6-pre8: Don't overwrite file.menu and user_apps.menu when regenerating menus. Fixed click-to-focus bug introduced in pre8. Fixed problem with applications that de-iconify their windows introduced in pre5. Thanks to all for contributions, bug reports, testing, suggestions, and support! Have fun :-) ok cool. excellent! SUGOII! lets do announcement soon then on e.org and try to ignore the /.ing e.org will get :) Congratulations to everyone who made this release a success :) I think Kim deserves special compliements for the work he has done on this release :) -- Ibukun Olumuyiwa http://xcomputerman.com Wisdom is the principal thing; therefore get wisdom: and with all thy getting get understanding. - Proverbs 4:7 --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] (no subject)
* Ibukun Olumuyiwa ([EMAIL PROTECTED]) wrote: Congratulations to everyone who made this release a success :) I think Kim deserves special compliements for the work he has done on this release :) Thanks a lot for this release. I've started using e16 again as of this morning 8) Alan Schmitt -- The hacker: someone who figured things out and made something cool happen. pgp0.pgp Description: PGP signature
