Re: [E-devel] e17 issue: EDJE not finding LUA on MacOS-X Leopard
On Fri, 2 Apr 2010 07:47:45 +0200 (CEST) Vincent Torri wrote: > > > On Fri, 2 Apr 2010, Carsten Haitzler (The Rasterman) wrote: > > > On Fri, 2 Apr 2010 08:56:26 +0800 Tom Haste > > said: > > > >> So... > >> > >> We're adding a patch that packagers use to make LUA install > >> correctly, so wouldnt that make E more difficult to package? Since > >> its effecting the install of LUA? Its early in the morning here so > >> it may just be my squishy morning brain not understanding the idea. > > > > no no no.. WE are not adding the patch. WE are just assuming the > > lua install is "sane" (ie provides a .pc file etc.) and expect the > > installed lua to be patched and set up properly. :) > > technically speaking, the problem is the same than zlib or libjpeg, > and we never complained that they don't have a .pc file. It would be > easier, of course, to have one (btw, zlib 1.2.4 has one, now. The > libjpeg maintainer does not want to add one, though) At least you don't need to patch their Makefile to get dynamic libraries however. And Lua _removed_ the .pc that was there. Regards, nash -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 issue: EDJE not finding LUA on MacOS-X Leopard
On Fri, 2 Apr 2010, Carsten Haitzler (The Rasterman) wrote: > On Fri, 2 Apr 2010 08:56:26 +0800 Tom Haste said: > >> So... >> >> We're adding a patch that packagers use to make LUA install correctly, >> so wouldnt that make E more difficult to package? Since its effecting >> the install of LUA? Its early in the morning here so it may just be my >> squishy morning brain not understanding the idea. > > no no no.. WE are not adding the patch. WE are just assuming the lua install > is > "sane" (ie provides a .pc file etc.) and expect the installed lua to be > patched > and set up properly. :) technically speaking, the problem is the same than zlib or libjpeg, and we never complained that they don't have a .pc file. It would be easier, of course, to have one (btw, zlib 1.2.4 has one, now. The libjpeg maintainer does not want to add one, though) Vincent -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 issue: EDJE not finding LUA on MacOS-X Leopard
On Thu, 1 Apr 2010, Dave Ray wrote: > 2) with patchfile: > > ./autogen.sh produces: > ... > checking for LUA... no > checking for LUA... no > checking for LUA... no > checking for LUA... no > ... > [autogen.sh finishes without error] > [make fails with "ld: symbols not found"] in which directory ? src/lib or src/bin ? Vincent -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Coverflow / Pictureflow for Elementary/EFL ?
On Fri, 2 Apr 2010 11:30:20 +0800 Brian Wang said: > On Fri, Apr 2, 2010 at 10:52 AM, Carsten Haitzler > wrote: > > On Fri, 2 Apr 2010 09:11:46 +0800 Brian Wang > > said: > > > >> On Fri, Apr 2, 2010 at 8:58 AM, Carsten Haitzler > >> wrote: > >> > On Fri, 2 Apr 2010 08:45:24 +0800 Brian Wang > >> > said: > >> > > >> >> Hello list, > >> >> > >> >> Is there a coverflow/pictureflow widget available for Elementary or EFL? > >> >> I've done my search but didn't find any. > >> >> Advice, please. > >> >> > >> >> Thanks in advance. :-) > >> > > >> > no :( > >> > >> OK. That saves me time for searching. :-) > >> I guess with evas_map, it should not be too difficult to come up with > >> a draft implementation (hopefully). > > > > have u seen expedite? :) > > I just did. :-) You mean Test 42 (42 - Image Map 3D Flow)? > It looks good except for the jigsaw edges (maybe there's a smooth > option?) and the movements/animation seem to be different from Aqqle's > coverflow. :-) > Nice code base. Thanks for the pointers. :-) yeah. it's far from perfect - it was a quick and dirty test - and yes. there is no anti-aliasing on edges of maps. you can get this to an extent with smooth maps and making the content 1 pixel smaller than the boundary of the map object. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] cleanup of server/svn access accounts.
Carsten Haitzler (The Rasterman) wrote: > On Thu, 01 Apr 2010 21:29:50 -0400 Jose Gonzalez said: > > No 'trolls' here man. People really should know *clearly* who the gate-keepers are, who controls what, what the project's aims and goals are, etc. >>> dude. by now, having founded and run this project for over 13 years... i >>> think i have the right to not have to go explain myself to you, or this >>> list, or ESPECIALLY anyone on the list of accounts to remove. you should >>> know better. >>> >>> >>> >>As you say.. But it's not about who to remove if you want to or not, >> (and of course they won't care), it's about saying clearly that it's you >> not some ambiguous "we". >> > > for you information... this was discussed on irc amongst several people tho > are core developers and long time contributors. just because you were not > there > doesn't mean i have to go detailing who i have talked to, who i am, who this > "we is" etc. etc. > No, you don't have to go detailing anything to me... I simply asked you to be less ambiguous as to who this "we" referred to. Thanks for clarifying. > i am not creating some government or corporate-level bureaucracy to details > which committee had a meeting when and who attended, publish the minutes of > that meeting and so on to keep you happy. you will have to trust the fact > that this has been discussed as indicated and there was an agreement and that > someone is TAKING ACTION. there's too much stuff in this world that ends up in > endless discussion groups and never gets ACTED on. this project is about > DOING > things. why is that so? because *I* am about doing things. and the people who > join this project are doing so because they ALSO want to DO things. if they > want to just hang about and endlessly discuss - there are a lot of government > think tanks and countless other online forums to go discuss things forever > because having the meeting to discuss the discussion then to have the > conference to propose the solutions to then discuss them in further meetings > and so on and never DO anything. > > i'm DOING something. i have put this up in the wider forum after the small > discussion with a few other people and offering a way to get off the nuke > list. > i someone thinks that removing access is a woeful sin and i should be punished > and beaten for even considering it - how dare i do that nd ask people for > their > opinions, then... let them come forth and say so. > > suffice to say there is a FACT - accounts are dormant or have never been used > for a long period of time. i noticed them when using the e dev "database" for > finding people, and in the process i spotted quite a few who have had accounts > added long ago and never committed a single thing. they have no business > needing svn access. i also checked last login times on the servers, and did a > more extensive hunt through ALL developers there and came up with this list. i > mentioned that i found this to several other developers on irc - and they all > agreed there needs to be a clean. this is that clean. be happy i didn't just > unceremoniously nuke the accounts with no notice. it's tempting to do so to > get > this off my todo list. i am being nice and friendly, offering an opportunity > for those people to say "oh hey! oh! i need it because of X and i haven't used > it because of Y" and i'll happily remove them from the "nuke" list if those > reasons seem acceptable. > > Of course most of the people in that list won't care if you remove their svn access. But some there were basically the core e-developers for many years.. and many of those no longer contribute because of issues with the way the project is 'run'. Don't you see that there's a recurring problem here? Do you want that to repeat itself yet again, or do you want to be able to keep core developers? >>> name them and get a quote from them that's why they left. i challenge you. >>> you are the only one who keeps saying this. even if they have beeen >>> developers for many years - they dont USE their accounts. there is NO >>> REASON to keep them. we advertise out developers on our website. it's >>> generated from our svn access list. if these people are not doing anything >>> they get removed. if they are unreasonable they will get upset - and then >>> there is all the more reason to be happy they stopped doing anything. if >>> they are reasonable they are happy to have the account removed and if they >>> ever want one again, they can ask. it means we get to at least have a more >>> accurate face of "who is doing what". >>> >>> >>> >>I'll leave the issue alone since it appears that no one else here >> sees any problems. >> >> >> Auto Insurance Quotes Enter Zip Code and Compare Rates! How Much Can You
Re: [E-devel] Coverflow / Pictureflow for Elementary/EFL ?
On Fri, Apr 2, 2010 at 10:52 AM, Carsten Haitzler wrote: > On Fri, 2 Apr 2010 09:11:46 +0800 Brian Wang said: > >> On Fri, Apr 2, 2010 at 8:58 AM, Carsten Haitzler >> wrote: >> > On Fri, 2 Apr 2010 08:45:24 +0800 Brian Wang >> > said: >> > >> >> Hello list, >> >> >> >> Is there a coverflow/pictureflow widget available for Elementary or EFL? >> >> I've done my search but didn't find any. >> >> Advice, please. >> >> >> >> Thanks in advance. :-) >> > >> > no :( >> >> OK. That saves me time for searching. :-) >> I guess with evas_map, it should not be too difficult to come up with >> a draft implementation (hopefully). > > have u seen expedite? :) I just did. :-) You mean Test 42 (42 - Image Map 3D Flow)? It looks good except for the jigsaw edges (maybe there's a smooth option?) and the movements/animation seem to be different from Aqqle's coverflow. :-) Nice code base. Thanks for the pointers. :-) > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > -- brian -- Cool-Karaoke - The smallest recording studio, in your palm, open-sourced http://cool-idea.com.tw/ iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Coverflow / Pictureflow for Elementary/EFL ?
On Fri, 2 Apr 2010 09:11:46 +0800 Brian Wang said: > On Fri, Apr 2, 2010 at 8:58 AM, Carsten Haitzler wrote: > > On Fri, 2 Apr 2010 08:45:24 +0800 Brian Wang > > said: > > > >> Hello list, > >> > >> Is there a coverflow/pictureflow widget available for Elementary or EFL? > >> I've done my search but didn't find any. > >> Advice, please. > >> > >> Thanks in advance. :-) > > > > no :( > > OK. That saves me time for searching. :-) > I guess with evas_map, it should not be too difficult to come up with > a draft implementation (hopefully). have u seen expedite? :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] cleanup of server/svn access accounts.
On Thu, 01 Apr 2010 21:29:50 -0400 Jose Gonzalez said: > > >> No 'trolls' here man. People really should know *clearly* > >> who the gate-keepers are, who controls what, what the > >> project's aims and goals are, etc. > >> > > > > dude. by now, having founded and run this project for over 13 years... i > > think i have the right to not have to go explain myself to you, or this > > list, or ESPECIALLY anyone on the list of accounts to remove. you should > > know better. > > > > >As you say.. But it's not about who to remove if you want to or not, > (and of course they won't care), it's about saying clearly that it's you > not some ambiguous "we". for you information... this was discussed on irc amongst several people tho are core developers and long time contributors. just because you were not there doesn't mean i have to go detailing who i have talked to, who i am, who this "we is" etc. etc. i am not creating some government or corporate-level bureaucracy to details which committee had a meeting when and who attended, publish the minutes of that meeting and so on to keep you happy. you will have to trust the fact that this has been discussed as indicated and there was an agreement and that someone is TAKING ACTION. there's too much stuff in this world that ends up in endless discussion groups and never gets ACTED on. this project is about DOING things. why is that so? because *I* am about doing things. and the people who join this project are doing so because they ALSO want to DO things. if they want to just hang about and endlessly discuss - there are a lot of government think tanks and countless other online forums to go discuss things forever because having the meeting to discuss the discussion then to have the conference to propose the solutions to then discuss them in further meetings and so on and never DO anything. i'm DOING something. i have put this up in the wider forum after the small discussion with a few other people and offering a way to get off the nuke list. i someone thinks that removing access is a woeful sin and i should be punished and beaten for even considering it - how dare i do that nd ask people for their opinions, then... let them come forth and say so. suffice to say there is a FACT - accounts are dormant or have never been used for a long period of time. i noticed them when using the e dev "database" for finding people, and in the process i spotted quite a few who have had accounts added long ago and never committed a single thing. they have no business needing svn access. i also checked last login times on the servers, and did a more extensive hunt through ALL developers there and came up with this list. i mentioned that i found this to several other developers on irc - and they all agreed there needs to be a clean. this is that clean. be happy i didn't just unceremoniously nuke the accounts with no notice. it's tempting to do so to get this off my todo list. i am being nice and friendly, offering an opportunity for those people to say "oh hey! oh! i need it because of X and i haven't used it because of Y" and i'll happily remove them from the "nuke" list if those reasons seem acceptable. > >> Of course most of the people in that list won't care if > >> you remove their svn access. But some there were basically > >> the core e-developers for many years.. and many of those > >> no longer contribute because of issues with the way the project > >> is 'run'. > >> > >>Don't you see that there's a recurring problem here? > >> Do you want that to repeat itself yet again, or do you want > >> to be able to keep core developers? > >> > > > > name them and get a quote from them that's why they left. i challenge you. > > you are the only one who keeps saying this. even if they have beeen > > developers for many years - they dont USE their accounts. there is NO > > REASON to keep them. we advertise out developers on our website. it's > > generated from our svn access list. if these people are not doing anything > > they get removed. if they are unreasonable they will get upset - and then > > there is all the more reason to be happy they stopped doing anything. if > > they are reasonable they are happy to have the account removed and if they > > ever want one again, they can ask. it means we get to at least have a more > > accurate face of "who is doing what". > > > > >I'll leave the issue alone since it appears that no one else here > sees any problems. > > > > > Get Free Email with Video Mail & Video Chat! > http://www.juno.com/freeemail?refcd=JUTAGOUT1FREM0210 > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > ht
Re: [E-devel] e17 issue: EDJE not finding LUA on MacOS-X Leopard
On Fri, 2 Apr 2010 08:56:26 +0800 Tom Haste said: > So... > > We're adding a patch that packagers use to make LUA install correctly, > so wouldnt that make E more difficult to package? Since its effecting > the install of LUA? Its early in the morning here so it may just be my > squishy morning brain not understanding the idea. no no no.. WE are not adding the patch. WE are just assuming the lua install is "sane" (ie provides a .pc file etc.) and expect the installed lua to be patched and set up properly. :) > On 2 April 2010 08:22, Carsten Haitzler wrote: > > On Thu, 1 Apr 2010 16:21:51 -0700 Dave Ray said: > > > >> Thanks, I am not aware of any patch for MacOS-X but I would be happy > >> to create one , although I might need some help. > > > > use the same ones linux distros use - look at the debian ones for example. > > > > http://packages.debian.org/lenny/lua5.1 > > > > and specifically: > > > > http://ftp.de.debian.org/debian/pool/main/l/lua5.1/lua5.1_5.1.3-1.diff.gz > > > > sure. the patch also contains things to add debian packaging info into the > > tree > > - but within that patch is what you need to 1. build shared libs, 2. > > provide .pc files that are correct and usable. > > > >> In the mean time, I have used other work-arounds that have allowed me > >> to compile and install the packages. > >> > >> FYI "Fink" (as described on the E MacOSX page) is an older X11 > >> implementation on MacOS that has been out of date and unsupported for > >> at least 2 years (actually Fink has many problems and was abandoned). > >> Apple's latest X11 implementation is excellent, much more compatible > >> than before, and does not require Fink. E16 compiles and runs great > >> just using the default Darwin environment, and I am very close to > >> getting E17 to work. I plan to make a binary install package for MacOS > >> and to help update the Enlightenment MacOS-X page as soon as I have a > >> working wm. That page is very out of date. > >> > >> -Dave > >> > >> > >> > >> > >> On Apr 1, 2010, at 3:33 PM, Carsten Haitzler (The Rasterman) wrote: > >> > >> > On Thu, 1 Apr 2010 15:11:55 -0700 Dave Ray said: > >> > > >> > see my previous mail. lua as-is from upstream is insufficient. you > >> > need to > >> > patch it like linux distributions do to make it sane. > >> > > >> >> Thans for taking the time to make this diff. Sadly it does not seem > >> >> to > >> >> fix the problem. I tried compiling EDJE with and without the patch > >> >> and > >> >> with a number of different ENV options with the following results: > >> >> > >> >> my normal environment: > >> >> LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib > >> >> [ lua located at /usr/local/lib/liblua.a ] > >> >> > >> >> 1) without patchfile: > >> >> > >> >> ./autogen.sh produces: > >> >> ... > >> >> checking for LUA... no > >> >> checking for LUA... no > >> >> checking for LUA... no > >> >> checking for LUA... no > >> >> configure: error: unable to find Lua > >> >> > >> >> 2) with patchfile: > >> >> > >> >> ./autogen.sh produces: > >> >> ... > >> >> checking for LUA... no > >> >> checking for LUA... no > >> >> checking for LUA... no > >> >> checking for LUA... no > >> >> ... > >> >> [autogen.sh finishes without error] > >> >> [make fails with "ld: symbols not found"] > >> >> > >> >> 3) with patchfile: > >> >> LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib -llua (<- > >> >> added - > >> >> llua) > >> >> ./autogen.sh produces: > >> >> ... > >> >> checking for LUA... no > >> >> checking for LUA... no > >> >> checking for LUA... no > >> >> checking for LUA... no > >> >> ... > >> >> [autogen.sh finishes without error] > >> >> [make finishes without error, but might not have LUA linked] > >> >> > >> >> 4) with patchfile: > >> >> LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib (<- without - > >> >> llua) > >> >> LUA_CFLAGS=-I/usr/local/include > >> >> LUA_LIBS=-L/usr/local/lib > >> >> > >> >> ./autogen.sh produces: > >> >> ... > >> >> checking for LUA... yes > >> >> ... > >> >> [autogen.sh finishes without error] > >> >> [make fails with "ld: symbols not found"] > >> >> > >> >> 5) with patchfile: > >> >> LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib -llua (<- > >> >> added - > >> >> llua) > >> >> LUA_CFLAGS=-I/usr/local/include > >> >> LUA_LIBS=-L/usr/local/lib > >> >> > >> >> ./autogen.sh produces: > >> >> ... > >> >> checking for LUA... yes > >> >> ... > >> >> [autogen.sh finishes without error] > >> >> [make finishes without error] > >> >> > >> >> From there on, I have to set new environment variables for every > >> >> package I need to compile that uses LUA or EDJE. > >> >> [package-name]_CFLAGS=-I/usr/local/include > >> >> [package-name]_LIBS=-L/usr/local/lib -llua > >> >> > >> >> This is what I was reporting yesterday. > >> >> > >> >> By the way this is using the latest source in svn. > >> >> > >> >> Dave > >> >> > >> >> > >> >> On Mar 31, 2010, at 9:20 PM, Vincent Torri wrote: > >> >> > >> >>> > >> >>> 1) patch edje with the attached f
Re: [E-devel] cleanup of server/svn access accounts.
On Thursday, 01 April 2010, at 21:29:50 (-0400), Jose Gonzalez wrote: >As you say.. But it's not about who to remove if you want to or > not, (and of course they won't care), it's about saying clearly that > it's you not some ambiguous "we". You can count me in that "we" as well. I fully support what he's proposing, as do the other developers who were present when the topic came up. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- "'Cause I want it all or nothing at all. There's nowhere left to fall; when you reach the bottom, it's now or never. Is it all, or are we just friends? Is this how it ends -- with a simple telephone call? You leave me here with nothing at all?" -- O-Town, "All or Nothing" -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Coverflow / Pictureflow for Elementary/EFL ?
On Fri, Apr 2, 2010 at 8:58 AM, Carsten Haitzler wrote: > On Fri, 2 Apr 2010 08:45:24 +0800 Brian Wang said: > >> Hello list, >> >> Is there a coverflow/pictureflow widget available for Elementary or EFL? >> I've done my search but didn't find any. >> Advice, please. >> >> Thanks in advance. :-) > > no :( OK. That saves me time for searching. :-) I guess with evas_map, it should not be too difficult to come up with a draft implementation (hopefully). > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > -- brian -- Cool-Karaoke - The smallest recording studio, in your palm, open-sourced http://cool-idea.com.tw/ iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] cleanup of server/svn access accounts.
>> No 'trolls' here man. People really should know *clearly* >> who the gate-keepers are, who controls what, what the >> project's aims and goals are, etc. >> > > dude. by now, having founded and run this project for over 13 years... i think > i have the right to not have to go explain myself to you, or this list, or > ESPECIALLY anyone on the list of accounts to remove. you should know better. > > As you say.. But it's not about who to remove if you want to or not, (and of course they won't care), it's about saying clearly that it's you not some ambiguous "we". >> Of course most of the people in that list won't care if >> you remove their svn access. But some there were basically >> the core e-developers for many years.. and many of those >> no longer contribute because of issues with the way the project >> is 'run'. >> >>Don't you see that there's a recurring problem here? >> Do you want that to repeat itself yet again, or do you want >> to be able to keep core developers? >> > > name them and get a quote from them that's why they left. i challenge you. you > are the only one who keeps saying this. even if they have beeen developers for > many years - they dont USE their accounts. there is NO REASON to keep them. we > advertise out developers on our website. it's generated from our svn access > list. if these people are not doing anything they get removed. if they are > unreasonable they will get upset - and then there is all the more reason to > be happy they stopped doing anything. if they are reasonable they are happy to > have the account removed and if they ever want one again, they can ask. it > means we get to at least have a more accurate face of "who is doing what". > > I'll leave the issue alone since it appears that no one else here sees any problems. Get Free Email with Video Mail & Video Chat! http://www.juno.com/freeemail?refcd=JUTAGOUT1FREM0210 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 issue: EDJE not finding LUA on MacOS-X Leopard
On Fri, Apr 2, 2010 at 12:56 AM, Tom Haste wrote: > So... > > We're adding a patch that packagers use to make LUA install correctly, > so wouldnt that make E more difficult to package? Since its effecting > the install of LUA? Its early in the morning here so it may just be my > squishy morning brain not understanding the idea. > No, distributions already patch it and we are pointing someone to those patches so he can install Lua from upstream correctly. > Toma. > > > On 2 April 2010 08:22, Carsten Haitzler wrote: >> On Thu, 1 Apr 2010 16:21:51 -0700 Dave Ray said: >> >>> Thanks, I am not aware of any patch for MacOS-X but I would be happy >>> to create one , although I might need some help. >> >> use the same ones linux distros use - look at the debian ones for example. >> >> http://packages.debian.org/lenny/lua5.1 >> >> and specifically: >> >> http://ftp.de.debian.org/debian/pool/main/l/lua5.1/lua5.1_5.1.3-1.diff.gz >> >> sure. the patch also contains things to add debian packaging info into the >> tree >> - but within that patch is what you need to 1. build shared libs, 2. >> provide .pc files that are correct and usable. >> >>> In the mean time, I have used other work-arounds that have allowed me >>> to compile and install the packages. >>> >>> FYI "Fink" (as described on the E MacOSX page) is an older X11 >>> implementation on MacOS that has been out of date and unsupported for >>> at least 2 years (actually Fink has many problems and was abandoned). >>> Apple's latest X11 implementation is excellent, much more compatible >>> than before, and does not require Fink. E16 compiles and runs great >>> just using the default Darwin environment, and I am very close to >>> getting E17 to work. I plan to make a binary install package for MacOS >>> and to help update the Enlightenment MacOS-X page as soon as I have a >>> working wm. That page is very out of date. >>> >>> -Dave >>> >>> >>> >>> >>> On Apr 1, 2010, at 3:33 PM, Carsten Haitzler (The Rasterman) wrote: >>> >>> > On Thu, 1 Apr 2010 15:11:55 -0700 Dave Ray said: >>> > >>> > see my previous mail. lua as-is from upstream is insufficient. you >>> > need to >>> > patch it like linux distributions do to make it sane. >>> > >>> >> Thans for taking the time to make this diff. Sadly it does not seem >>> >> to >>> >> fix the problem. I tried compiling EDJE with and without the patch >>> >> and >>> >> with a number of different ENV options with the following results: >>> >> >>> >> my normal environment: >>> >> LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib >>> >> [ lua located at /usr/local/lib/liblua.a ] >>> >> >>> >> 1) without patchfile: >>> >> >>> >> ./autogen.sh produces: >>> >> ... >>> >> checking for LUA... no >>> >> checking for LUA... no >>> >> checking for LUA... no >>> >> checking for LUA... no >>> >> configure: error: unable to find Lua >>> >> >>> >> 2) with patchfile: >>> >> >>> >> ./autogen.sh produces: >>> >> ... >>> >> checking for LUA... no >>> >> checking for LUA... no >>> >> checking for LUA... no >>> >> checking for LUA... no >>> >> ... >>> >> [autogen.sh finishes without error] >>> >> [make fails with "ld: symbols not found"] >>> >> >>> >> 3) with patchfile: >>> >> LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib -llua (<- >>> >> added - >>> >> llua) >>> >> ./autogen.sh produces: >>> >> ... >>> >> checking for LUA... no >>> >> checking for LUA... no >>> >> checking for LUA... no >>> >> checking for LUA... no >>> >> ... >>> >> [autogen.sh finishes without error] >>> >> [make finishes without error, but might not have LUA linked] >>> >> >>> >> 4) with patchfile: >>> >> LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib (<- without - >>> >> llua) >>> >> LUA_CFLAGS=-I/usr/local/include >>> >> LUA_LIBS=-L/usr/local/lib >>> >> >>> >> ./autogen.sh produces: >>> >> ... >>> >> checking for LUA... yes >>> >> ... >>> >> [autogen.sh finishes without error] >>> >> [make fails with "ld: symbols not found"] >>> >> >>> >> 5) with patchfile: >>> >> LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib -llua (<- >>> >> added - >>> >> llua) >>> >> LUA_CFLAGS=-I/usr/local/include >>> >> LUA_LIBS=-L/usr/local/lib >>> >> >>> >> ./autogen.sh produces: >>> >> ... >>> >> checking for LUA... yes >>> >> ... >>> >> [autogen.sh finishes without error] >>> >> [make finishes without error] >>> >> >>> >> From there on, I have to set new environment variables for every >>> >> package I need to compile that uses LUA or EDJE. >>> >> [package-name]_CFLAGS=-I/usr/local/include >>> >> [package-name]_LIBS=-L/usr/local/lib -llua >>> >> >>> >> This is what I was reporting yesterday. >>> >> >>> >> By the way this is using the latest source in svn. >>> >> >>> >> Dave >>> >> >>> >> >>> >> On Mar 31, 2010, at 9:20 PM, Vincent Torri wrote: >>> >> >>> >>> >>> >>> 1) patch edje with the attached file : >>> >>> >>> >>> put that file in edje/, then: >>> >>> >>> >>> patch -p0 < edje_lua.diff >>> >>> >>> >>> 2) set CFLAGS accordingly: >>> >>> >>> >>> export CFLAGS="$CFLAGS -
Re: [E-devel] cleanup of server/svn access accounts.
On Thu, 01 Apr 2010 20:57:39 -0400 Jose Gonzalez said: >Carsten wrote: > > > On Thu, 01 Apr 2010 16:56:44 -0400 Jose Gonzalez said: > > > > don't feed the troll. > > > > > > No 'trolls' here man. People really should know *clearly* > who the gate-keepers are, who controls what, what the > project's aims and goals are, etc. dude. by now, having founded and run this project for over 13 years... i think i have the right to not have to go explain myself to you, or this list, or ESPECIALLY anyone on the list of accounts to remove. you should know better. > Of course most of the people in that list won't care if > you remove their svn access. But some there were basically > the core e-developers for many years.. and many of those > no longer contribute because of issues with the way the project > is 'run'. > >Don't you see that there's a recurring problem here? > Do you want that to repeat itself yet again, or do you want > to be able to keep core developers? name them and get a quote from them that's why they left. i challenge you. you are the only one who keeps saying this. even if they have beeen developers for many years - they dont USE their accounts. there is NO REASON to keep them. we advertise out developers on our website. it's generated from our svn access list. if these people are not doing anything they get removed. if they are unreasonable they will get upset - and then there is all the more reason to be happy they stopped doing anything. if they are reasonable they are happy to have the account removed and if they ever want one again, they can ask. it means we get to at least have a more accurate face of "who is doing what". > >>Carsten wrote: > >> > >> > >>> i recently found quite a number of accounts we have for svn commit access > >>> that are simply 100% inactive (never used once for anything) or have been > >>> inactive for what i consider "a while" with no good reason for that. > >>> here's the list. if you are on it expect your account to be removed > >>> some-time soon, unless you come up with a good reason why not. this isn't > >>> anything personal - so please don't be offended. we just don't want to > >>> maintain access for people who are not > >>> > >>Just to eliminate some ambiguity here, can you be more specific as to > >> who is "we"? > >> > >> > >>> using it or no longer use it... or who simply don't need it. it's not a > >>> right, it's a privilege (and it can be removed at any time... for any > >>> reason). it's > >>> > >>Is it the same "we" above that decides who can be added or "removed > >> at any time > >> ... for any reason"? > >> > >> > >>> also a security risk to our servers, so the fewer people who have svn/ssh > >>> access, the better. note - this process was only semi-automated. i > >>> actually looked at the accounts and their svn history, etc. so i may have > >>> oopsied. tell me if i have > >>> > >>> now... the list: > >>> > >>> 3v1n0 > >>> andrunko > >>> andyetitmoves > >>> balony > >>> belisarivs > >>> benr > >>> chaos > >>> codewarrior > >>> cpuid > >>> dm > >>> essiene > >>> e-taro > >>> glassy > >>> handyande > >>> kacper > >>> laBrute > >>> leviathan > >>> lofwyrm > >>> lok > >>> lsobral > >>> metrics > >>> moom > >>> nasa01 > >>> nerochiaro > >>> obfuscated > >>> pithlit > >>> ptomaine > >>> quan74 > >>> rhapsodhy > >>> romanhornik > >>> sativas > >>> shadoi > >>> slackd00d > >>> sndev > >>> tick > >>> tilman > >>> troback > >>> werkt > >>> xenith > >>> xprodigy > >>> xstasi > >>> cobra > >>> rephorm > >>> > >>> > > "Your Government Bailout" > USA Gov gave billions to stimulate economy & relieve DEBT. Claim yours > http://thirdpartyoffers.juno.com/TGL3141/4bb53c01b25e678d9fst03duc > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Coverflow / Pictureflow for Elementary/EFL ?
On Fri, 2 Apr 2010 08:45:24 +0800 Brian Wang said: > Hello list, > > Is there a coverflow/pictureflow widget available for Elementary or EFL? > I've done my search but didn't find any. > Advice, please. > > Thanks in advance. :-) no :( -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 issue: EDJE not finding LUA on MacOS-X Leopard
So... We're adding a patch that packagers use to make LUA install correctly, so wouldnt that make E more difficult to package? Since its effecting the install of LUA? Its early in the morning here so it may just be my squishy morning brain not understanding the idea. Toma. On 2 April 2010 08:22, Carsten Haitzler wrote: > On Thu, 1 Apr 2010 16:21:51 -0700 Dave Ray said: > >> Thanks, I am not aware of any patch for MacOS-X but I would be happy >> to create one , although I might need some help. > > use the same ones linux distros use - look at the debian ones for example. > > http://packages.debian.org/lenny/lua5.1 > > and specifically: > > http://ftp.de.debian.org/debian/pool/main/l/lua5.1/lua5.1_5.1.3-1.diff.gz > > sure. the patch also contains things to add debian packaging info into the > tree > - but within that patch is what you need to 1. build shared libs, 2. > provide .pc files that are correct and usable. > >> In the mean time, I have used other work-arounds that have allowed me >> to compile and install the packages. >> >> FYI "Fink" (as described on the E MacOSX page) is an older X11 >> implementation on MacOS that has been out of date and unsupported for >> at least 2 years (actually Fink has many problems and was abandoned). >> Apple's latest X11 implementation is excellent, much more compatible >> than before, and does not require Fink. E16 compiles and runs great >> just using the default Darwin environment, and I am very close to >> getting E17 to work. I plan to make a binary install package for MacOS >> and to help update the Enlightenment MacOS-X page as soon as I have a >> working wm. That page is very out of date. >> >> -Dave >> >> >> >> >> On Apr 1, 2010, at 3:33 PM, Carsten Haitzler (The Rasterman) wrote: >> >> > On Thu, 1 Apr 2010 15:11:55 -0700 Dave Ray said: >> > >> > see my previous mail. lua as-is from upstream is insufficient. you >> > need to >> > patch it like linux distributions do to make it sane. >> > >> >> Thans for taking the time to make this diff. Sadly it does not seem >> >> to >> >> fix the problem. I tried compiling EDJE with and without the patch >> >> and >> >> with a number of different ENV options with the following results: >> >> >> >> my normal environment: >> >> LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib >> >> [ lua located at /usr/local/lib/liblua.a ] >> >> >> >> 1) without patchfile: >> >> >> >> ./autogen.sh produces: >> >> ... >> >> checking for LUA... no >> >> checking for LUA... no >> >> checking for LUA... no >> >> checking for LUA... no >> >> configure: error: unable to find Lua >> >> >> >> 2) with patchfile: >> >> >> >> ./autogen.sh produces: >> >> ... >> >> checking for LUA... no >> >> checking for LUA... no >> >> checking for LUA... no >> >> checking for LUA... no >> >> ... >> >> [autogen.sh finishes without error] >> >> [make fails with "ld: symbols not found"] >> >> >> >> 3) with patchfile: >> >> LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib -llua (<- >> >> added - >> >> llua) >> >> ./autogen.sh produces: >> >> ... >> >> checking for LUA... no >> >> checking for LUA... no >> >> checking for LUA... no >> >> checking for LUA... no >> >> ... >> >> [autogen.sh finishes without error] >> >> [make finishes without error, but might not have LUA linked] >> >> >> >> 4) with patchfile: >> >> LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib (<- without - >> >> llua) >> >> LUA_CFLAGS=-I/usr/local/include >> >> LUA_LIBS=-L/usr/local/lib >> >> >> >> ./autogen.sh produces: >> >> ... >> >> checking for LUA... yes >> >> ... >> >> [autogen.sh finishes without error] >> >> [make fails with "ld: symbols not found"] >> >> >> >> 5) with patchfile: >> >> LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib -llua (<- >> >> added - >> >> llua) >> >> LUA_CFLAGS=-I/usr/local/include >> >> LUA_LIBS=-L/usr/local/lib >> >> >> >> ./autogen.sh produces: >> >> ... >> >> checking for LUA... yes >> >> ... >> >> [autogen.sh finishes without error] >> >> [make finishes without error] >> >> >> >> From there on, I have to set new environment variables for every >> >> package I need to compile that uses LUA or EDJE. >> >> [package-name]_CFLAGS=-I/usr/local/include >> >> [package-name]_LIBS=-L/usr/local/lib -llua >> >> >> >> This is what I was reporting yesterday. >> >> >> >> By the way this is using the latest source in svn. >> >> >> >> Dave >> >> >> >> >> >> On Mar 31, 2010, at 9:20 PM, Vincent Torri wrote: >> >> >> >>> >> >>> 1) patch edje with the attached file : >> >>> >> >>> put that file in edje/, then: >> >>> >> >>> patch -p0 < edje_lua.diff >> >>> >> >>> 2) set CFLAGS accordingly: >> >>> >> >>> export CFLAGS="$CFLAGS -I/my/lua/prefix/include" >> >>> >> >>> 3) set LDFLAGS accordingly: >> >>> >> >>> export LDFLAGS="$LDFLAGS -L/my/lua/prefix/lib" >> >>> >> >>> note that there is no -llua anymore >> >>> >> >>> 4) run 'make', it should launch autoconf and other autotools >> >>> automatically >> >>> >> >>> 5) if edje compiles: >> >>> >> >>> go to elementary
Re: [E-devel] cleanup of server/svn access accounts.
On 2 April 2010 08:57, Jose Gonzalez wrote: > Carsten wrote: > >> On Thu, 01 Apr 2010 16:56:44 -0400 Jose Gonzalez said: >> >> don't feed the troll. >> >> > > No 'trolls' here man. People really should know *clearly* > who the gate-keepers are, who controls what, what the > project's aims and goals are, etc. > > Of course most of the people in that list won't care if > you remove their svn access. But some there were basically > the core e-developers for many years.. and many of those > no longer contribute because of issues with the way the project > is 'run'. > > Don't you see that there's a recurring problem here? > Do you want that to repeat itself yet again, or do you want > to be able to keep core developers? Core developers are those with the most commits in the last month/week. This changes over time as people come and go. Its the way open source projects work. People put in what they can/want and then continue along lifes path. Those that are dedicated will hang around longer. A lot of the people on that list are indeed old school E devs that have done a lot. Im sure if the winds of life blew them back in our direction, they would get access back in a snap. The fact is, if you stop contributing to the source, then you dont NEED commit access to the source. Id be happy if raster was in charge of the SVN access, seeing as it is his project. And as such, he should be the one that makes these decisions. I also dont mind if major contributors add extra developers; as long as they remain responsible for the people they add, and remove them if they leave the project. To quote the original email "unless you come up with a good reason why not"; you didnt make a good point as to why not so far. And lets keep on topic of the thread, or start another thread. Toma. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 issue: EDJE not finding LUA on MacOS-X Leopard
On Thu, 1 Apr 2010 16:21:51 -0700 Dave Ray said: > Thanks, I am not aware of any patch for MacOS-X but I would be happy > to create one , although I might need some help. use the same ones linux distros use - look at the debian ones for example. http://packages.debian.org/lenny/lua5.1 and specifically: http://ftp.de.debian.org/debian/pool/main/l/lua5.1/lua5.1_5.1.3-1.diff.gz sure. the patch also contains things to add debian packaging info into the tree - but within that patch is what you need to 1. build shared libs, 2. provide .pc files that are correct and usable. > In the mean time, I have used other work-arounds that have allowed me > to compile and install the packages. > > FYI "Fink" (as described on the E MacOSX page) is an older X11 > implementation on MacOS that has been out of date and unsupported for > at least 2 years (actually Fink has many problems and was abandoned). > Apple's latest X11 implementation is excellent, much more compatible > than before, and does not require Fink. E16 compiles and runs great > just using the default Darwin environment, and I am very close to > getting E17 to work. I plan to make a binary install package for MacOS > and to help update the Enlightenment MacOS-X page as soon as I have a > working wm. That page is very out of date. > > -Dave > > > > > On Apr 1, 2010, at 3:33 PM, Carsten Haitzler (The Rasterman) wrote: > > > On Thu, 1 Apr 2010 15:11:55 -0700 Dave Ray said: > > > > see my previous mail. lua as-is from upstream is insufficient. you > > need to > > patch it like linux distributions do to make it sane. > > > >> Thans for taking the time to make this diff. Sadly it does not seem > >> to > >> fix the problem. I tried compiling EDJE with and without the patch > >> and > >> with a number of different ENV options with the following results: > >> > >> my normal environment: > >> LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib > >> [ lua located at /usr/local/lib/liblua.a ] > >> > >> 1) without patchfile: > >> > >> ./autogen.sh produces: > >> ... > >> checking for LUA... no > >> checking for LUA... no > >> checking for LUA... no > >> checking for LUA... no > >> configure: error: unable to find Lua > >> > >> 2) with patchfile: > >> > >> ./autogen.sh produces: > >> ... > >> checking for LUA... no > >> checking for LUA... no > >> checking for LUA... no > >> checking for LUA... no > >> ... > >> [autogen.sh finishes without error] > >> [make fails with "ld: symbols not found"] > >> > >> 3) with patchfile: > >> LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib -llua(<- > >> added - > >> llua) > >> ./autogen.sh produces: > >> ... > >> checking for LUA... no > >> checking for LUA... no > >> checking for LUA... no > >> checking for LUA... no > >> ... > >> [autogen.sh finishes without error] > >> [make finishes without error, but might not have LUA linked] > >> > >> 4) with patchfile: > >> LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib (<- without - > >> llua) > >> LUA_CFLAGS=-I/usr/local/include > >> LUA_LIBS=-L/usr/local/lib > >> > >> ./autogen.sh produces: > >> ... > >> checking for LUA... yes > >> ... > >> [autogen.sh finishes without error] > >> [make fails with "ld: symbols not found"] > >> > >> 5) with patchfile: > >> LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib -llua(<- > >> added - > >> llua) > >> LUA_CFLAGS=-I/usr/local/include > >> LUA_LIBS=-L/usr/local/lib > >> > >> ./autogen.sh produces: > >> ... > >> checking for LUA... yes > >> ... > >> [autogen.sh finishes without error] > >> [make finishes without error] > >> > >> From there on, I have to set new environment variables for every > >> package I need to compile that uses LUA or EDJE. > >> [package-name]_CFLAGS=-I/usr/local/include > >> [package-name]_LIBS=-L/usr/local/lib -llua > >> > >> This is what I was reporting yesterday. > >> > >> By the way this is using the latest source in svn. > >> > >> Dave > >> > >> > >> On Mar 31, 2010, at 9:20 PM, Vincent Torri wrote: > >> > >>> > >>> 1) patch edje with the attached file : > >>> > >>> put that file in edje/, then: > >>> > >>> patch -p0 < edje_lua.diff > >>> > >>> 2) set CFLAGS accordingly: > >>> > >>> export CFLAGS="$CFLAGS -I/my/lua/prefix/include" > >>> > >>> 3) set LDFLAGS accordingly: > >>> > >>> export LDFLAGS="$LDFLAGS -L/my/lua/prefix/lib" > >>> > >>> note that there is no -llua anymore > >>> > >>> 4) run 'make', it should launch autoconf and other autotools > >>> automatically > >>> > >>> 5) if edje compiles: > >>> > >>> go to elementary directory > >>> run 'make maintainer-clean' > >>> run './autogen.sh' > >>> run 'make' > >>> > >>> tell me if there are errors > >>> > >>> Vincent > >> > >> > >> -- > >> Download Intel® Parallel Studio Eval > >> Try the new software tools for yourself. Speed compiling, find bugs > >> proactively, and fine-tune applications for parallel performance. > >> See why Intel Parall
[E-devel] Coverflow / Pictureflow for Elementary/EFL ?
Hello list, Is there a coverflow/pictureflow widget available for Elementary or EFL? I've done my search but didn't find any. Advice, please. Thanks in advance. :-) brian -- brian -- Cool-Karaoke - The smallest recording studio, in your palm, open-sourced http://cool-idea.com.tw/ iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] cleanup of server/svn access accounts.
Carsten wrote: > On Thu, 01 Apr 2010 16:56:44 -0400 Jose Gonzalez said: > > don't feed the troll. > > No 'trolls' here man. People really should know *clearly* who the gate-keepers are, who controls what, what the project's aims and goals are, etc. Of course most of the people in that list won't care if you remove their svn access. But some there were basically the core e-developers for many years.. and many of those no longer contribute because of issues with the way the project is 'run'. Don't you see that there's a recurring problem here? Do you want that to repeat itself yet again, or do you want to be able to keep core developers? >>Carsten wrote: >> >> >>> i recently found quite a number of accounts we have for svn commit access >>> that are simply 100% inactive (never used once for anything) or have been >>> inactive for what i consider "a while" with no good reason for that. here's >>> the list. if you are on it expect your account to be removed some-time >>> soon, unless you come up with a good reason why not. this isn't anything >>> personal - so please don't be offended. we just don't want to maintain >>> access for people who are not >>> >>Just to eliminate some ambiguity here, can you be more specific as to >> who is "we"? >> >> >>> using it or no longer use it... or who simply don't need it. it's not a >>> right, it's a privilege (and it can be removed at any time... for any >>> reason). it's >>> >>Is it the same "we" above that decides who can be added or "removed >> at any time >> ... for any reason"? >> >> >>> also a security risk to our servers, so the fewer people who have svn/ssh >>> access, the better. note - this process was only semi-automated. i actually >>> looked at the accounts and their svn history, etc. so i may have oopsied. >>> tell me if i have >>> >>> now... the list: >>> >>> 3v1n0 >>> andrunko >>> andyetitmoves >>> balony >>> belisarivs >>> benr >>> chaos >>> codewarrior >>> cpuid >>> dm >>> essiene >>> e-taro >>> glassy >>> handyande >>> kacper >>> laBrute >>> leviathan >>> lofwyrm >>> lok >>> lsobral >>> metrics >>> moom >>> nasa01 >>> nerochiaro >>> obfuscated >>> pithlit >>> ptomaine >>> quan74 >>> rhapsodhy >>> romanhornik >>> sativas >>> shadoi >>> slackd00d >>> sndev >>> tick >>> tilman >>> troback >>> werkt >>> xenith >>> xprodigy >>> xstasi >>> cobra >>> rephorm >>> >>> "Your Government Bailout" USA Gov gave billions to stimulate economy & relieve DEBT. Claim yours http://thirdpartyoffers.juno.com/TGL3141/4bb53c01b25e678d9fst03duc -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 issue: EDJE not finding LUA on MacOS-X Leopard
Thanks, I am not aware of any patch for MacOS-X but I would be happy to create one , although I might need some help. In the mean time, I have used other work-arounds that have allowed me to compile and install the packages. FYI "Fink" (as described on the E MacOSX page) is an older X11 implementation on MacOS that has been out of date and unsupported for at least 2 years (actually Fink has many problems and was abandoned). Apple's latest X11 implementation is excellent, much more compatible than before, and does not require Fink. E16 compiles and runs great just using the default Darwin environment, and I am very close to getting E17 to work. I plan to make a binary install package for MacOS and to help update the Enlightenment MacOS-X page as soon as I have a working wm. That page is very out of date. -Dave On Apr 1, 2010, at 3:33 PM, Carsten Haitzler (The Rasterman) wrote: > On Thu, 1 Apr 2010 15:11:55 -0700 Dave Ray said: > > see my previous mail. lua as-is from upstream is insufficient. you > need to > patch it like linux distributions do to make it sane. > >> Thans for taking the time to make this diff. Sadly it does not seem >> to >> fix the problem. I tried compiling EDJE with and without the patch >> and >> with a number of different ENV options with the following results: >> >> my normal environment: >> LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib >> [ lua located at /usr/local/lib/liblua.a ] >> >> 1) without patchfile: >> >> ./autogen.sh produces: >> ... >> checking for LUA... no >> checking for LUA... no >> checking for LUA... no >> checking for LUA... no >> configure: error: unable to find Lua >> >> 2) with patchfile: >> >> ./autogen.sh produces: >> ... >> checking for LUA... no >> checking for LUA... no >> checking for LUA... no >> checking for LUA... no >> ... >> [autogen.sh finishes without error] >> [make fails with "ld: symbols not found"] >> >> 3) with patchfile: >> LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib -llua(<- >> added - >> llua) >> ./autogen.sh produces: >> ... >> checking for LUA... no >> checking for LUA... no >> checking for LUA... no >> checking for LUA... no >> ... >> [autogen.sh finishes without error] >> [make finishes without error, but might not have LUA linked] >> >> 4) with patchfile: >> LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib (<- without - >> llua) >> LUA_CFLAGS=-I/usr/local/include >> LUA_LIBS=-L/usr/local/lib >> >> ./autogen.sh produces: >> ... >> checking for LUA... yes >> ... >> [autogen.sh finishes without error] >> [make fails with "ld: symbols not found"] >> >> 5) with patchfile: >> LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib -llua(<- >> added - >> llua) >> LUA_CFLAGS=-I/usr/local/include >> LUA_LIBS=-L/usr/local/lib >> >> ./autogen.sh produces: >> ... >> checking for LUA... yes >> ... >> [autogen.sh finishes without error] >> [make finishes without error] >> >> From there on, I have to set new environment variables for every >> package I need to compile that uses LUA or EDJE. >> [package-name]_CFLAGS=-I/usr/local/include >> [package-name]_LIBS=-L/usr/local/lib -llua >> >> This is what I was reporting yesterday. >> >> By the way this is using the latest source in svn. >> >> Dave >> >> >> On Mar 31, 2010, at 9:20 PM, Vincent Torri wrote: >> >>> >>> 1) patch edje with the attached file : >>> >>> put that file in edje/, then: >>> >>> patch -p0 < edje_lua.diff >>> >>> 2) set CFLAGS accordingly: >>> >>> export CFLAGS="$CFLAGS -I/my/lua/prefix/include" >>> >>> 3) set LDFLAGS accordingly: >>> >>> export LDFLAGS="$LDFLAGS -L/my/lua/prefix/lib" >>> >>> note that there is no -llua anymore >>> >>> 4) run 'make', it should launch autoconf and other autotools >>> automatically >>> >>> 5) if edje compiles: >>> >>> go to elementary directory >>> run 'make maintainer-clean' >>> run './autogen.sh' >>> run 'make' >>> >>> tell me if there are errors >>> >>> Vincent >> >> >> -- >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> ___ >> 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 > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-
Re: [E-devel] cleanup of server/svn access accounts.
Bring the axe down I say. Im certain all those people would put the security of the project over their token SVN access. On that topic, I hope everyone has changed their passwords lately :) A good password is one that keeps changing. Toma. On 2 April 2010 06:37, Carsten Haitzler wrote: > On Thu, 01 Apr 2010 16:56:44 -0400 Jose Gonzalez said: > > don't feed the troll. > >> Carsten wrote: >> >> > i recently found quite a number of accounts we have for svn commit access >> > that are simply 100% inactive (never used once for anything) or have been >> > inactive for what i consider "a while" with no good reason for that. here's >> > the list. if you are on it expect your account to be removed some-time >> > soon, unless you come up with a good reason why not. this isn't anything >> > personal - so please don't be offended. we just don't want to maintain >> > access for people who are not >> >> Just to eliminate some ambiguity here, can you be more specific as to >> who is "we"? >> >> > using it or no longer use it... or who simply don't need it. it's not a >> > right, it's a privilege (and it can be removed at any time... for any >> > reason). it's >> >> Is it the same "we" above that decides who can be added or "removed >> at any time >> ... for any reason"? >> >> > also a security risk to our servers, so the fewer people who have svn/ssh >> > access, the better. note - this process was only semi-automated. i actually >> > looked at the accounts and their svn history, etc. so i may have oopsied. >> > tell me if i have >> > >> > now... the list: >> > >> > 3v1n0 >> > andrunko >> > andyetitmoves >> > balony >> > belisarivs >> > benr >> > chaos >> > codewarrior >> > cpuid >> > dm >> > essiene >> > e-taro >> > glassy >> > handyande >> > kacper >> > laBrute >> > leviathan >> > lofwyrm >> > lok >> > lsobral >> > metrics >> > moom >> > nasa01 >> > nerochiaro >> > obfuscated >> > pithlit >> > ptomaine >> > quan74 >> > rhapsodhy >> > romanhornik >> > sativas >> > shadoi >> > slackd00d >> > sndev >> > tick >> > tilman >> > troback >> > werkt >> > xenith >> > xprodigy >> > xstasi >> > cobra >> > rephorm >> > >> >> >> #1 Key to Debt Relief: >> Government money is available to stop Debt! The key is finding it. >> http://thirdpartyoffers.juno.com/TGL3141/4bb5038e437470a32st04duc >> > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore Dispatcher
On Thu, 1 Apr 2010 22:42:28 +0200 Andreas Volz said: > > On Sun, 27 Jan 2008 10:30:34 +0100 Andreas Volz > > babbled: > > > > Von: Carsten Haitzler (The Rasterman) > > > > hmm - wondering what u were trying to solve here? > > > > > Hello, > > > > > > some time ago I wrote a little GUI dispatcher for async sygnals in > > > ecore. Read more about it here: > > > > > > http://andreasvolz.wordpress.com/2008/01/24/a-gui-dispatcher-for-asynchronous-updates-with-ecore/ > > > > > > Perhaps someone has the same problem and is happy about it. Do you > > > think the functions fit into the ecore library? > > > > > > regards > > > Andreas > > Hello Raster, > > for some reason I missed this very old mail and now I give you the > answer. I use the ecore dispatcher helper functions often to dispatch > some asynchronous input (e.g. from joystick thread) to my applications. > Nothing really new, but puts some often used ecore functions behind an > easier interface. isn't this ecore_pipe() ? :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 issue: EDJE not finding LUA on MacOS-X Leopard
On Thu, 1 Apr 2010 15:11:55 -0700 Dave Ray said: see my previous mail. lua as-is from upstream is insufficient. you need to patch it like linux distributions do to make it sane. > Thans for taking the time to make this diff. Sadly it does not seem to > fix the problem. I tried compiling EDJE with and without the patch and > with a number of different ENV options with the following results: > > my normal environment: > LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib > [ lua located at /usr/local/lib/liblua.a ] > > 1) without patchfile: > > ./autogen.sh produces: > ... > checking for LUA... no > checking for LUA... no > checking for LUA... no > checking for LUA... no > configure: error: unable to find Lua > > 2) with patchfile: > > ./autogen.sh produces: > ... > checking for LUA... no > checking for LUA... no > checking for LUA... no > checking for LUA... no > ... > [autogen.sh finishes without error] > [make fails with "ld: symbols not found"] > > 3) with patchfile: > LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib -llua(<- added - > llua) > ./autogen.sh produces: > ... > checking for LUA... no > checking for LUA... no > checking for LUA... no > checking for LUA... no > ... > [autogen.sh finishes without error] > [make finishes without error, but might not have LUA linked] > > 4) with patchfile: > LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib (<- without -llua) > LUA_CFLAGS=-I/usr/local/include > LUA_LIBS=-L/usr/local/lib > > ./autogen.sh produces: > ... > checking for LUA... yes > ... > [autogen.sh finishes without error] > [make fails with "ld: symbols not found"] > > 5) with patchfile: > LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib -llua(<- added - > llua) > LUA_CFLAGS=-I/usr/local/include > LUA_LIBS=-L/usr/local/lib > > ./autogen.sh produces: > ... > checking for LUA... yes > ... > [autogen.sh finishes without error] > [make finishes without error] > > From there on, I have to set new environment variables for every > package I need to compile that uses LUA or EDJE. > [package-name]_CFLAGS=-I/usr/local/include > [package-name]_LIBS=-L/usr/local/lib -llua > > This is what I was reporting yesterday. > > By the way this is using the latest source in svn. > > Dave > > > On Mar 31, 2010, at 9:20 PM, Vincent Torri wrote: > > > > > 1) patch edje with the attached file : > > > > put that file in edje/, then: > > > > patch -p0 < edje_lua.diff > > > > 2) set CFLAGS accordingly: > > > > export CFLAGS="$CFLAGS -I/my/lua/prefix/include" > > > > 3) set LDFLAGS accordingly: > > > > export LDFLAGS="$LDFLAGS -L/my/lua/prefix/lib" > > > > note that there is no -llua anymore > > > > 4) run 'make', it should launch autoconf and other autotools > > automatically > > > > 5) if edje compiles: > > > > go to elementary directory > > run 'make maintainer-clean' > > run './autogen.sh' > > run 'make' > > > > tell me if there are errors > > > > Vincent > > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > 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 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] cleanup of server/svn access accounts.
On Thu, 01 Apr 2010 16:56:44 -0400 Jose Gonzalez said: don't feed the troll. >Carsten wrote: > > > i recently found quite a number of accounts we have for svn commit access > > that are simply 100% inactive (never used once for anything) or have been > > inactive for what i consider "a while" with no good reason for that. here's > > the list. if you are on it expect your account to be removed some-time > > soon, unless you come up with a good reason why not. this isn't anything > > personal - so please don't be offended. we just don't want to maintain > > access for people who are not > >Just to eliminate some ambiguity here, can you be more specific as to > who is "we"? > > > using it or no longer use it... or who simply don't need it. it's not a > > right, it's a privilege (and it can be removed at any time... for any > > reason). it's > >Is it the same "we" above that decides who can be added or "removed > at any time > ... for any reason"? > > > also a security risk to our servers, so the fewer people who have svn/ssh > > access, the better. note - this process was only semi-automated. i actually > > looked at the accounts and their svn history, etc. so i may have oopsied. > > tell me if i have > > > > now... the list: > > > > 3v1n0 > > andrunko > > andyetitmoves > > balony > > belisarivs > > benr > > chaos > > codewarrior > > cpuid > > dm > > essiene > > e-taro > > glassy > > handyande > > kacper > > laBrute > > leviathan > > lofwyrm > > lok > > lsobral > > metrics > > moom > > nasa01 > > nerochiaro > > obfuscated > > pithlit > > ptomaine > > quan74 > > rhapsodhy > > romanhornik > > sativas > > shadoi > > slackd00d > > sndev > > tick > > tilman > > troback > > werkt > > xenith > > xprodigy > > xstasi > > cobra > > rephorm > > > > > #1 Key to Debt Relief: > Government money is available to stop Debt! The key is finding it. > http://thirdpartyoffers.juno.com/TGL3141/4bb5038e437470a32st04duc > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 issue: EDJE not finding LUA on MacOS-X Leopard
Thans for taking the time to make this diff. Sadly it does not seem to fix the problem. I tried compiling EDJE with and without the patch and with a number of different ENV options with the following results: my normal environment: LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib [ lua located at /usr/local/lib/liblua.a ] 1) without patchfile: ./autogen.sh produces: ... checking for LUA... no checking for LUA... no checking for LUA... no checking for LUA... no configure: error: unable to find Lua 2) with patchfile: ./autogen.sh produces: ... checking for LUA... no checking for LUA... no checking for LUA... no checking for LUA... no ... [autogen.sh finishes without error] [make fails with "ld: symbols not found"] 3) with patchfile: LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib -llua(<- added - llua) ./autogen.sh produces: ... checking for LUA... no checking for LUA... no checking for LUA... no checking for LUA... no ... [autogen.sh finishes without error] [make finishes without error, but might not have LUA linked] 4) with patchfile: LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib (<- without -llua) LUA_CFLAGS=-I/usr/local/include LUA_LIBS=-L/usr/local/lib ./autogen.sh produces: ... checking for LUA... yes ... [autogen.sh finishes without error] [make fails with "ld: symbols not found"] 5) with patchfile: LDFLAGS=-L/usr/lib -L/usr/X11/lib -L/usr/local/lib -llua(<- added - llua) LUA_CFLAGS=-I/usr/local/include LUA_LIBS=-L/usr/local/lib ./autogen.sh produces: ... checking for LUA... yes ... [autogen.sh finishes without error] [make finishes without error] From there on, I have to set new environment variables for every package I need to compile that uses LUA or EDJE. [package-name]_CFLAGS=-I/usr/local/include [package-name]_LIBS=-L/usr/local/lib -llua This is what I was reporting yesterday. By the way this is using the latest source in svn. Dave On Mar 31, 2010, at 9:20 PM, Vincent Torri wrote: > > 1) patch edje with the attached file : > > put that file in edje/, then: > > patch -p0 < edje_lua.diff > > 2) set CFLAGS accordingly: > > export CFLAGS="$CFLAGS -I/my/lua/prefix/include" > > 3) set LDFLAGS accordingly: > > export LDFLAGS="$LDFLAGS -L/my/lua/prefix/lib" > > note that there is no -llua anymore > > 4) run 'make', it should launch autoconf and other autotools > automatically > > 5) if edje compiles: > > go to elementary directory > run 'make maintainer-clean' > run './autogen.sh' > run 'make' > > tell me if there are errors > > Vincent -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore Dispatcher
> On Sun, 27 Jan 2008 10:30:34 +0100 Andreas Volz > babbled: > > Von: Carsten Haitzler (The Rasterman) > > hmm - wondering what u were trying to solve here? > > > Hello, > > > > some time ago I wrote a little GUI dispatcher for async sygnals in > > ecore. Read more about it here: > > > > http://andreasvolz.wordpress.com/2008/01/24/a-gui-dispatcher-for-asynchronous-updates-with-ecore/ > > > > Perhaps someone has the same problem and is happy about it. Do you > > think the functions fit into the ecore library? > > > > regards > > Andreas Hello Raster, for some reason I missed this very old mail and now I give you the answer. I use the ecore dispatcher helper functions often to dispatch some asynchronous input (e.g. from joystick thread) to my applications. Nothing really new, but puts some often used ecore functions behind an easier interface. regards Andreas -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] cleanup of server/svn access accounts.
Carsten wrote: > i recently found quite a number of accounts we have for svn commit access that > are simply 100% inactive (never used once for anything) or have been inactive > for what i consider "a while" with no good reason for that. here's the list. > if > you are on it expect your account to be removed some-time soon, unless you > come up with a good reason why not. this isn't anything personal - so please > don't be offended. we just don't want to maintain access for people who are > not > Just to eliminate some ambiguity here, can you be more specific as to who is "we"? > using it or no longer use it... or who simply don't need it. it's not a right, > it's a privilege (and it can be removed at any time... for any reason). it's > Is it the same "we" above that decides who can be added or "removed at any time ... for any reason"? > also a security risk to our servers, so the fewer people who have svn/ssh > access, the better. note - this process was only semi-automated. i actually > looked at the accounts and their svn history, etc. so i may have oopsied. tell > me if i have > > now... the list: > > 3v1n0 > andrunko > andyetitmoves > balony > belisarivs > benr > chaos > codewarrior > cpuid > dm > essiene > e-taro > glassy > handyande > kacper > laBrute > leviathan > lofwyrm > lok > lsobral > metrics > moom > nasa01 > nerochiaro > obfuscated > pithlit > ptomaine > quan74 > rhapsodhy > romanhornik > sativas > shadoi > slackd00d > sndev > tick > tilman > troback > werkt > xenith > xprodigy > xstasi > cobra > rephorm > #1 Key to Debt Relief: Government money is available to stop Debt! The key is finding it. http://thirdpartyoffers.juno.com/TGL3141/4bb5038e437470a32st04duc -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] elm hoversel patch2
On Thu, 1 Apr 2010 03:22:32 -0400 Michael Blumenkrantz wrote: > Hi, > > Same patch as before, but fixed return values (thanks vtorri!) > > zmike (discomfi...@freenode) Just ignore these, handling through irc and this patch file is wrong anyway. Late night coding defeats me yet again... -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: englebass trunk/efreet/src/lib
On Thu, 1 Apr 2010, Enlightenment SVN wrote: > Log: > efreet: fancy alloca include in common header I hope that you didn't break Windows compilation with that move. I have to check that Vincent > Author: englebass > Date: 2010-04-01 12:32:41 -0700 (Thu, 01 Apr 2010) > New Revision: 47664 > > Modified: > trunk/efreet/src/lib/efreet_ini.c trunk/efreet/src/lib/efreet_private.h > > Modified: trunk/efreet/src/lib/efreet_ini.c > === > --- trunk/efreet/src/lib/efreet_ini.c 2010-04-01 19:32:29 UTC (rev 47663) > +++ trunk/efreet/src/lib/efreet_ini.c 2010-04-01 19:32:41 UTC (rev 47664) > @@ -12,23 +12,6 @@ > #include > #include > > -#ifdef HAVE_ALLOCA_H > -# include > -#elif defined __GNUC__ > -# define alloca __builtin_alloca > -#elif defined _AIX > -# define alloca __alloca > -#elif defined _MSC_VER > -# include > -# define alloca _alloca > -#else > -# include > -# ifdef __cplusplus > -extern "C" > -# endif > -void *alloca (size_t); > -#endif > - > #include > > #include "Efreet.h" > > Modified: trunk/efreet/src/lib/efreet_private.h > === > --- trunk/efreet/src/lib/efreet_private.h 2010-04-01 19:32:29 UTC (rev > 47663) > +++ trunk/efreet/src/lib/efreet_private.h 2010-04-01 19:32:41 UTC (rev > 47664) > @@ -4,6 +4,24 @@ > > #include > > +#ifdef HAVE_ALLOCA_H > +# include > +#elif defined __GNUC__ > +# define alloca __builtin_alloca > +#elif defined _AIX > +# define alloca __alloca > +#elif defined _MSC_VER > +# include > +# define alloca _alloca > +#else > +# include > +# ifdef __cplusplus > +extern "C" > +# endif > +void *alloca (size_t); > +#endif > + > + > /** > * @file efreet_private.h > * @brief Contains methods and defines that are private to the Efreet > > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > enlightenment-svn mailing list > enlightenment-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-svn > > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns trunk/e/src/bin
On Thu, Apr 1, 2010 at 10:48 AM, Enlightenment SVN
wrote:
> Log:
> Use item->label in places where we can. I don't know how this was
> overlooked all this time. This fixes a bug where getting item->label
> was always returning NULL.
>
> Can someone please check the eina_stringshare usage here ? Thanks :)
> + if (si)
> + {
> + if (si->label) eina_stringshare_del(si->label);
> + si->label = eina_stringshare_add(label);
> + edje_object_part_text_set(si->o_base, "e.text.label", label);
> + }
if (eina_stringshare_replace(&si->label, label))
edje_object_part_text_set(si->o_base, "e.text.label", label);
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] elm hoversel patch
Hi,
Attached is a small patch which (correctly?) implements the
hoversel_expanded_get() function along with proper documentation. It
returns EINA_TRUE if the hoversel is expanded by checking to see if
wd->hover is non-null.
zmike (discomfi...@freenode)--- Elementary.h.in 2010-04-01 03:11:24.0 -0400
+++ Elementary.h.in.old 2010-04-01 03:11:54.0 -0400
@@ -746,7 +746,6 @@
EAPI Evas_Object *elm_hoversel_icon_get(const Evas_Object *obj);
EAPI void elm_hoversel_hover_begin(Evas_Object *obj);
EAPI void elm_hoversel_hover_end(Evas_Object *obj);
- EAPI Eina_Boolelm_hoversel_state_get(Evas_Object *obj);
EAPI void elm_hoversel_clear(Evas_Object *obj);
EAPI const Eina_List * elm_hoversel_items_get(const Evas_Object *obj);
EAPI Elm_Hoversel_Item *elm_hoversel_item_add(Evas_Object *obj, const char *label, const char *icon_file, Elm_Icon_Type icon_type, Evas_Smart_Cb func, const void *data);
--- elc_hoversel.c.old 2010-04-01 03:12:44.0 -0400
+++ elc_hoversel.c 2010-04-01 03:09:54.0 -0400
@@ -425,6 +425,25 @@
}
/**
+ * Returns whether the hoversel is expanded.
+ *
+ * This will return EINA_TRUE if the hoversel is expanded or
+ * EINA_FALSE if it is not expanded.
+ * @param obj The hoversel object
+ *
+ * @ingroup Hoversel
+ */
+
+EAPI Eina_Bool
+elm_hoversel_state_get(Evas_Object *obj)
+{
+ ELM_CHECK_WIDTYPE(obj, widtype);
+ Widget_Data *wd = elm_widget_data_get(obj);
+ if (!wd) return;
+ return (wd->hover) ? 1 : 0;
+}
+
+/**
* Remove all the items from the given hoversel object.
*
* This will remove all the children items from the hoversel. (should not be
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 issue: EDJE not finding LUA on MacOS-X Leopard
On Wed, Mar 31, 2010 at 7:09 PM, Carsten Haitzler wrote: > On Wed, 31 Mar 2010 14:57:52 -0700 Dave Ray said: > >> >> On Mar 31, 2010, at 1:05 PM, Vincent Torri wrote: >> >> > On Wed, 31 Mar 2010, Dave Ray wrote: >> >>> if you just configured with >> >>> LUA_CFLAGS="-I/my/prefix/include" LUA_LIBS="-L/my/prefix/lib" ./ >> >>> configure >> >>> then it's normal. >> >>> Try >> >>> LUA_CFLAGS="-I/my/prefix/include" LUA_LIBS="-L/my/prefix/lib - >> >>> llua" ./configure >> > >> > did you read **carefully** the above line. See the >> > >> > -llua >> >> No I didn't read carefully. My bad. Ok, I retried it with -llua and >> EDJE compiled just fine. Thanks you! >> >> I share your frustration with the LUA implementation. > > this is a fundamental issue with lua upstream. they simply don't want to join > the modern world. if you want to use lua upstream directly-as-is... you will > continue to have such problems. i know i'm in no mood to work around such > silliness. ALL they need to do is provide a .pc file - a single tiny text > file. > the work has already been done for them by several linux distributions. it > gets > patched to provide this file and to also build shared libraries (.so's > vs .a's). > as such my suggestion is to find and adopt the patches applied by linux > distributions to your lua install. sanity will then be restored. What about adding the lua source as a single file in Edje? It's pretty common for projects to do that, since Edje is not supposed to run arbitrary Lua scripts, why bother having that as a dependency? By design Lua is an embeddable language/runtime. A trimmed version without some libs that aren't enabled can be around 90k. Edje itself weights around 600k on my system. Again, just a thought. They are not "refusing to join the modern world". It's you that are choosing not to follow their guidelines and embed lua ;) []s Eduardo. >> As it turns out, other packages for e17 that I compile after EDJE run >> into similar problems. In order to compile Elementary I had to >> manually set ELEMENTARY_CFLAGS and ELEMENTARY_LIBS and manually add - >> llua. >> >> I seem to be on my way to success for installing e17, but standard >> usage of "configure, make, sudo make install" don't work with anything >> that has a Lua dependency. >> >> -Dave >> >> -- >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> ___ >> 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 > > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] elm hoversel patch2
Hi,
Same patch as before, but fixed return values (thanks vtorri!)
zmike (discomfi...@freenode)--- Elementary.h.in 2010-04-01 03:11:24.0 -0400
+++ Elementary.h.in.old 2010-04-01 03:11:54.0 -0400
@@ -746,7 +746,6 @@
EAPI Evas_Object *elm_hoversel_icon_get(const Evas_Object *obj);
EAPI void elm_hoversel_hover_begin(Evas_Object *obj);
EAPI void elm_hoversel_hover_end(Evas_Object *obj);
- EAPI Eina_Boolelm_hoversel_state_get(Evas_Object *obj);
EAPI void elm_hoversel_clear(Evas_Object *obj);
EAPI const Eina_List * elm_hoversel_items_get(const Evas_Object *obj);
EAPI Elm_Hoversel_Item *elm_hoversel_item_add(Evas_Object *obj, const char *label, const char *icon_file, Elm_Icon_Type icon_type, Evas_Smart_Cb func, const void *data);
--- elc_hoversel.c.old 2010-04-01 03:12:44.0 -0400
+++ elc_hoversel.c 2010-04-01 03:09:54.0 -0400
@@ -425,6 +425,25 @@
}
/**
+ * Returns whether the hoversel is expanded.
+ *
+ * This will return EINA_TRUE if the hoversel is expanded or
+ * EINA_FALSE if it is not expanded.
+ * @param obj The hoversel object
+ *
+ * @ingroup Hoversel
+ */
+
+EAPI Eina_Bool
+elm_hoversel_state_get(Evas_Object *obj)
+{
+ ELM_CHECK_WIDTYPE(obj, widtype);
+ Widget_Data *wd = elm_widget_data_get(obj);
+ if (!wd) return EINA_FALSE;
+ return (wd->hover) ? EINA_TRUE : EINA_FALSE;
+}
+
+/**
* Remove all the items from the given hoversel object.
*
* This will remove all the children items from the hoversel. (should not be
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: tiago trunk/TMP/st/elementary/src/edje_externals
On Thu, Apr 1, 2010 at 6:22 AM, Enlightenment SVN
wrote:
> Log:
> Free params in Toolbar external
> Author: tiago
> Date: 2010-04-01 07:22:21 -0700 (Thu, 01 Apr 2010)
> New Revision: 47644
>
> Modified:
> trunk/TMP/st/elementary/src/edje_externals/elm_toolbar.c
>
> Modified: trunk/TMP/st/elementary/src/edje_externals/elm_toolbar.c
> ===
> --- trunk/TMP/st/elementary/src/edje_externals/elm_toolbar.c 2010-04-01
> 10:44:30 UTC (rev 47643)
> +++ trunk/TMP/st/elementary/src/edje_externals/elm_toolbar.c 2010-04-01
> 14:22:21 UTC (rev 47644)
> @@ -107,7 +107,9 @@
> static void
> external_toolbar_params_free(void *params)
> {
> - return;
> + Elm_Params_Entry *mem = params;
> +
> + free(mem);
> }
WTF... Entry??? In toolbar... i broke the build :-(
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: barbieri IN trunk/emotion: . data m4 src src/edje_external src/lib
On Wed, Mar 31, 2010 at 9:10 PM, Iván Briano (Sachiel) wrote: > On Thu, Apr 1, 2010 at 5:04 AM, Vincent Torri wrote: >> >> >> On Thu, 1 Apr 2010, Iván Briano (Sachiel) wrote: >> >>> On Thu, Apr 1, 2010 at 4:22 AM, Vincent Torri wrote: On Wed, 31 Mar 2010, Enlightenment SVN wrote: > Log: > Initial support for Emotion as Edje EXTERNAL. would you be interested in an m4 macro to simplify the integration of edje_external in configure.ac ? >>> >>> Are you selling those cheap? If so, I don't see any problem with >>> having it. >> >> who would sell that stuff except me ? :) Well, that can save some work if >> you want to add edje externals to epdf, eps, ertf, and other libs, for >> example >> > > Probably a good idea, also helps if anyone wants to export their own > stuff that way. yes! -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
