[Pharo-project] WebClient License Update
Hi - After careful consideration I've decided to put WebClient under the MIT license, and updated the repository at http://www.squeaksource.com/WebClient.html to reflect the license change. If you're curious why I'm making the change, the answer is really that the code isn't all that unique and even though I'm not done with it it's good enough to be released and by now I simply get more benefits from it being thoroughly tested by as many people as possible. That and the (to me surprising) amount of interest that WebClient has received in combination with the (to me disturbing) lack of due diligence that many users of WebClient apparently have. I think we can all take away a lesson from this little incident that even if you find some random code on the net it doesn't mean it's up for grabs. Also, if I may be so bold, let me propose the "2 step process to eternal license happiness". It's really simple: [ ] Did we check the license of the package? [ ] Did we contact the author of the package? If you check off the above two steps whenever you're about to use some third-party code, I think you'll find that situations like the one we've encountered here are virtually impossible. Attach the steps to the bug tracker if you must, but follow them. Since you know how to verify the license status on your own, let me add the second step of the process and once more repeat that I would rather keep WebClient an externally loadable package. If at all possible I urge you to look at what has been done with HTTPSocket in Squeak and adopt a similar approach; that is provide a minimal internal HTTP interface and allow third-party libraries (WebClient or other) to hook into this interface. There is really no need to have everything tied together at the hip; HTTPSocket is a reasonable facade for HTTP requests in the kernel. Regarding write access to the WebClient repository, I'm not a fan of making repos world-writable (this is really a sign of abandonware) but due to the license I'm fine with granting Sven and Philippe write access if they want it (drop me a note if you do). Cheers, - Andreas ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient License Update
Thanks. > Hi - > > After careful consideration I've decided to put WebClient under the MIT > license, and updated the repository at > http://www.squeaksource.com/WebClient.html to reflect the license change. > > If you're curious why I'm making the change, the answer is really that the > code isn't all that unique and even though I'm not done with it it's good > enough to be released and by now I simply get more benefits from it being > thoroughly tested by as many people as possible. That and the (to me > surprising) amount of interest that WebClient has received in combination > with the (to me disturbing) lack of due diligence that many users of > WebClient apparently have. I think we can all take away a lesson from this > little incident that even if you find some random code on the net it doesn't > mean it's up for grabs. > > Also, if I may be so bold, let me propose the "2 step process to eternal > license happiness". It's really simple: > > [ ] Did we check the license of the package? > [ ] Did we contact the author of the package? > > If you check off the above two steps whenever you're about to use some > third-party code, I think you'll find that situations like the one we've > encountered here are virtually impossible. Attach the steps to the bug > tracker if you must, but follow them. > > Since you know how to verify the license status on your own, let me add the > second step of the process and once more repeat that I would rather keep > WebClient an externally loadable package. If at all possible I urge you to > look at what has been done with HTTPSocket in Squeak and adopt a similar > approach; that is provide a minimal internal HTTP interface and allow > third-party libraries (WebClient or other) to hook into this interface. we will look at that. And do not worry I think that everybody learn a lesson in the process. > There is really no need to have everything tied together at the hip; > HTTPSocket is a reasonable facade for HTTP requests in the kernel. > > Regarding write access to the WebClient repository, I'm not a fan of making > repos world-writable (this is really a sign of abandonware) but due to the > license I'm fine with granting Sven and Philippe write access if they want it > (drop me a note if you do). > > Cheers, > - Andreas > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] glamorous theme :)
Laurent, On 07 Sep 2010, at 08:47, laurent laffont wrote: > Using Glamourous I hardly see which button is focused in System Browser > between instance or class. > So I've made mistakes several times yesterday :) You could try my subclass, it tries to solve that problem (to my taste anyway; Des goûts et des couleurs, on ne dispute / discute pas). It is in SqueakSource ADayAtTheBeach package Pharo-Hacking-Sven (it has 2 subclasses, one for the Pro theme as well). Sven ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [SPAM] Re: [Moose-dev] glamorous theme :)
On 06 Sep 2010, at 22:10, Adrian Lienhard wrote: > So, so now we have 2 themes that appear to be better than the one we use > now... I suggest to choose one, maybe adapt it slightly, and integrate it > into Pharo 1.2. > > Personally, I prefer Glamorous over the Pro theme [1] (I just miss the round > corners like Alex :). The dark buttons of the Pro theme look cool at first, > but they are very dominant. > > How do we proceed? I would include a small number of well maintained/supported themes. Of course, every image needs a default, but choice is good here (it is the whole point). Sven ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Vote for the best Smalltalk book of the last 5 years...
I forgot to mention that the deadline is until wednesday 15 september at noon. On Sep 6, 2010, at 5:07 PM, Stéphane Ducasse wrote: > Dear Pharoers :) > > this year ESUG would like to reward effort made in book publications. Since > we want to push new books but that it takes time to write books we will > take into account a window of 5 years. So you are requested to vote for the > best book of the last 5 years. > > http://www.surveymonkey.com/s/Q2LKKDT > > Stef on the behalf of the ESUG board. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] UbiquiTalk running in Pharo 1.1
Thanks Sean. Noury On 6 sept. 2010, at 23:03, Sean P. DeNigris wrote: > > The updated rST and UbiquiTalk versions now live in their main repos (thanks > to Noury for access). The installation script is now: > > Gofer new > squeaksource: 'KomHttpServer'; > package: 'DynamicBindings'; > package: 'KomServices'; > load. > > Gofer new > squeaksource: 'rST'; > package: 'rST'; > load. > > Gofer new > squeaksource: 'OSProcess'; > package: 'OSProcess'; > load. > > Gofer new > squeaksource: 'UbiquiTalk'; > package: 'UbiquiTalk-Platform.pharo'; > package: 'UbiquiTalk-Utilities'; "depends on Platform" > package: 'UbiquiTalk-Kernel'; "depends on Utilities" > package: 'UbiquiTalk-Cache'; "depends on Kernel" > package: 'UbiquiTalk-GUI'; "depends on Kernel" > package: 'UbiquiTalk-Plugins'; "depends on Kernel" > package: 'UbiquiTalk-PDA'; > package: 'UbiquiTalk-Property Editors'; > package: 'UbiquiTalk-Tests'; > package: 'UTAllServices'; > load. > > Sean > -- > View this message in context: > http://forum.world.st/UbiquiTalk-running-in-Pharo-1-1-tp2400767p2528879.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Noury ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] UbiquiTalk running in Pharo 1.1
On 6 sept. 2010, at 23:26, Sean P. DeNigris wrote: > > > Miguel Enrique Cobá Martínez-2 wrote: >> >> This begs for a ConfigurationOfUbiquiTalk :) >> > > Yes, I didn't want to "take the time" to make one, and it probably took > longer to list it all out, lol. > > One of the complications is that Squeak 4.1, which I also work in, does not > include Metacello by default, so I have to write an Installer script. I > still find it confusing and frustrating that there are both Gofer and > Installer. Why don't we standardize on one or merge them? > BTW, currently at Douai we don't have much man-power. So, we decided to work only on Pharo. Noury ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Please help!! Error: There is no free space in this set!'
In 1.1 running all test with GlorpDBX and Seaside will raise this exception. However I have not been able to reproduce the error reliably. Like it says in the error reports is seems that updating the tally value is somehow broken. -- Panu ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Please help!! Error: There is no free space in this set!'
Yes, to fix it you haev to evaluate: DBXPlatform disableAutomaticConnectionReleaseOnGC this will not store the connections in the weakregistry so you have to be sure to properly disconnect the connections On Tue, Sep 7, 2010 at 10:25 AM, Panu Suominen wrote: > In 1.1 running all test with GlorpDBX and Seaside will raise this > exception. > However I have not been able to reproduce the error reliably. Like it > says in the error reports is seems that updating the tally value is somehow > broken. > > -- > Panu > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Moose-dev] Re: Redirect compiler warnings to file
Philippe Marschall wrote: And an easy way to redirect to sdtout or stderr would help for things like Hudson. I found that in Dolphin when I was running with Cruise Control, that I installed a subclassed Transcript that logged both to the screen and to a file. I wonder if that might be an easy fix for Pharo? Tim ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Pharo-users] Vote for the best Smalltalk book of the last 5 years...
On Tue, Sep 7, 2010 at 09:59, stephane ducasse wrote: > I forgot to mention that the deadline is until wednesday 15 september at noon. Not to nag you, but I think you must also specify a timezone, or at least say in which place in the world are you waiting for this noon to happen. Cheers P. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient License Update
Cool! Alexandre On 7 Sep 2010, at 03:03, Andreas Raab wrote: > Hi - > > After careful consideration I've decided to put WebClient under the MIT > license, and updated the repository at > http://www.squeaksource.com/WebClient.html to reflect the license change. > > If you're curious why I'm making the change, the answer is really that the > code isn't all that unique and even though I'm not done with it it's good > enough to be released and by now I simply get more benefits from it being > thoroughly tested by as many people as possible. That and the (to me > surprising) amount of interest that WebClient has received in combination > with the (to me disturbing) lack of due diligence that many users of > WebClient apparently have. I think we can all take away a lesson from this > little incident that even if you find some random code on the net it doesn't > mean it's up for grabs. > > Also, if I may be so bold, let me propose the "2 step process to eternal > license happiness". It's really simple: > > [ ] Did we check the license of the package? > [ ] Did we contact the author of the package? > > If you check off the above two steps whenever you're about to use some > third-party code, I think you'll find that situations like the one we've > encountered here are virtually impossible. Attach the steps to the bug > tracker if you must, but follow them. > > Since you know how to verify the license status on your own, let me add the > second step of the process and once more repeat that I would rather keep > WebClient an externally loadable package. If at all possible I urge you to > look at what has been done with HTTPSocket in Squeak and adopt a similar > approach; that is provide a minimal internal HTTP interface and allow > third-party libraries (WebClient or other) to hook into this interface. There > is really no need to have everything tied together at the hip; HTTPSocket is > a reasonable facade for HTTP requests in the kernel. > > Regarding write access to the WebClient repository, I'm not a fan of making > repos world-writable (this is really a sign of abandonware) but due to the > license I'm fine with granting Sven and Philippe write access if they want it > (drop me a note if you do). > > Cheers, > - Andreas > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient License Update
Thanks you very much Andreas. And yes, I agree we learned something. About the two steps you mention, is what I did with regarding SPDF, so we now have (unfortunately) the certainty that can not use it. About WebClient, as you know because I write you asking permit, I'm using on my product WebPostAutomation and I've extended (or at least documented) the way to make "posts" using multipart/form-data. And WebClient works very well, really thanks by license it as MIT. Cheers. Germán. 2010/9/7 Andreas Raab : > Hi - > > After careful consideration I've decided to put WebClient under the MIT > license, and updated the repository at > http://www.squeaksource.com/WebClient.html to reflect the license change. > > If you're curious why I'm making the change, the answer is really that the > code isn't all that unique and even though I'm not done with it it's good > enough to be released and by now I simply get more benefits from it being > thoroughly tested by as many people as possible. That and the (to me > surprising) amount of interest that WebClient has received in combination > with the (to me disturbing) lack of due diligence that many users of > WebClient apparently have. I think we can all take away a lesson from this > little incident that even if you find some random code on the net it doesn't > mean it's up for grabs. > > Also, if I may be so bold, let me propose the "2 step process to eternal > license happiness". It's really simple: > > [ ] Did we check the license of the package? > [ ] Did we contact the author of the package? > > If you check off the above two steps whenever you're about to use some > third-party code, I think you'll find that situations like the one we've > encountered here are virtually impossible. Attach the steps to the bug > tracker if you must, but follow them. > > Since you know how to verify the license status on your own, let me add the > second step of the process and once more repeat that I would rather keep > WebClient an externally loadable package. If at all possible I urge you to > look at what has been done with HTTPSocket in Squeak and adopt a similar > approach; that is provide a minimal internal HTTP interface and allow > third-party libraries (WebClient or other) to hook into this interface. > There is really no need to have everything tied together at the hip; > HTTPSocket is a reasonable facade for HTTP requests in the kernel. > > Regarding write access to the WebClient repository, I'm not a fan of making > repos world-writable (this is really a sign of abandonware) but due to the > license I'm fine with granting Sven and Philippe write access if they want > it (drop me a note if you do). > > Cheers, > - Andreas > -- = Germán S. Arduino Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com = ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Compiling the VM for MacOSX
Hi! I followed the instruction given on: http://book.pharo-project.org/book/Virtual-Machine/Building/BuildVMOnOSX 134 errors are reported. Below the first line of the report: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Building target “Squeak VM Universal” of project “SqueakVMUNIXPATHS” with configuration “Development” — (134 errors) cd /Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer /Developer/usr/bin/gcc-4.2 -x c -arch i386 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wmissing-prototypes -Wmissing-braces -Wparentheses -Wunused-function -Wunused-label -Wunused-parameter -Wunused-variable -Wunused-value -Wsign-compare -DHAVE_NANOSLEEP -DEXTERNALPRIMSDEBUG -DTARGET_API_MAC_CARBON -DSQUEAK_BUILTIN_PLUGIN -DHAVE_SYS_TIME_H -isysroot /Developer/SDKs/MacOSX10.5.sdk -mfix-and-continue -mmacosx-version-min=10.5 -gdwarf-2 "-I/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/build/SqueakVMUNIXPATHS.build/Development/Squeak VM Universal.build/Squeak VM Opt.hmap" -DLSB_FIRST -mtune=prescott -march=pentium-m -mfpmath=sse -DUSE_INLINE_MEMORY_ACCESSORS -F/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/build/Development -F/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks -I/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/build/Development/include -I/Developer/SDKs/MacOSX10.5.sdk/Developer/Headers/FlatCarbon "-I/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/build/SqueakVMUNIXPATHS.build/Development/Squeak VM Universal.build/DerivedSources/i386" "-I/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/build/SqueakVMUNIXPATHS.build/Development/Squeak VM Universal.build/DerivedSources" -c /Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/src/vm/intplugins/ADPCMCodecPlugin/ADPCMCodecPlugin.c -o "/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/build/SqueakVMUNIXPATHS.build/Development/Squeak VM Universal.build/Objects-normal/i386/ADPCMCodecPlugin.o" i686-apple-darwin9-gcc-4.2.1: /Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/src/vm/intplugins/ADPCMCodecPlugin/ADPCMCodecPlugin.c: No such file or directory i686-apple-darwin9-gcc-4.2.1: warning: '-x c' after last input file has no effect i686-apple-darwin9-gcc-4.2.1: no input files i686-apple-darwin9-gcc-4.2.1: no input files i686-apple-darwin9-gcc-4.2.1: no input files i686-apple-darwin9-gcc-4.2.1: no input files i686-apple-darwin9-gcc-4.2.1: no input files -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Is there something wrong I did? Help is highly appreciated... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Compiling the VM for MacOSX
"Unlike to the GNU/Linux platforms the Mac OSX way don't have pre-generated source, then if you want to recompile the VM you must generate the src from VMMaker (refer to VMMaker Chapter to do that)." I guess you skipped this step? Cheers, Henry Den 07.09.2010 15:18, skrev Alexandre Bergel: > Hi! > > I followed the instruction given on: > http://book.pharo-project.org/book/Virtual-Machine/Building/BuildVMOnOSX > 134 errors are reported. > > Below the first line of the report: > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Building target “Squeak VM Universal” of project “SqueakVMUNIXPATHS” with > configuration “Development” — (134 errors) > cd /Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer > /Developer/usr/bin/gcc-4.2 -x c -arch i386 -fmessage-length=0 -pipe > -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wmissing-prototypes > -Wmissing-braces -Wparentheses -Wunused-function -Wunused-label > -Wunused-parameter -Wunused-variable -Wunused-value -Wsign-compare > -DHAVE_NANOSLEEP -DEXTERNALPRIMSDEBUG -DTARGET_API_MAC_CARBON > -DSQUEAK_BUILTIN_PLUGIN -DHAVE_SYS_TIME_H -isysroot > /Developer/SDKs/MacOSX10.5.sdk -mfix-and-continue -mmacosx-version-min=10.5 > -gdwarf-2 > "-I/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/build/SqueakVMUNIXPATHS.build/Development/Squeak > VM Universal.build/Squeak VM Opt.hmap" -DLSB_FIRST -mtune=prescott > -march=pentium-m -mfpmath=sse -DUSE_INLINE_MEMORY_ACCESSORS > -F/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/build/Development > -F/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks > > -I/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/build/Development/include > -I/Developer/SDKs/MacOSX10.5.sdk/Developer/Headers/FlatCarbon > "-I/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/build/SqueakVMUNIXPATHS.build/Development/Squeak > VM Universal.build/DerivedSources/i386" > "-I/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/build/SqueakVMUNIXPATHS.build/Development/Squeak > VM Universal.build/DerivedSources" -c > /Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/src/vm/intplugins/ADPCMCodecPlugin/ADPCMCodecPlugin.c > -o > "/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/build/SqueakVMUNIXPATHS.build/Development/Squeak > VM Universal.build/Objects-normal/i386/ADPCMCodecPlugin.o" > i686-apple-darwin9-gcc-4.2.1: > /Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/src/vm/intplugins/ADPCMCodecPlugin/ADPCMCodecPlugin.c: > No such file or directory > i686-apple-darwin9-gcc-4.2.1: warning: '-x c' after last input file has no > effect > i686-apple-darwin9-gcc-4.2.1: no input files > i686-apple-darwin9-gcc-4.2.1: no input files > i686-apple-darwin9-gcc-4.2.1: no input files > i686-apple-darwin9-gcc-4.2.1: no input files > i686-apple-darwin9-gcc-4.2.1: no input files > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Is there something wrong I did? > > Help is highly appreciated... > > Cheers, > Alexandre > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Moose-dev] Re: Redirect compiler warnings to file
probably note. And this si not surprising a ssystem without systematic engineering over 10 years cannot compete with one that got it. We will fix that but this will take some time and effort Stef On Sep 7, 2010, at 11:20 AM, TimM wrote: > Philippe Marschall wrote: > >> And an easy way to redirect to sdtout or stderr would help for things >> like Hudson. > > I found that in Dolphin when I was running with Cruise Control, that I > installed a subclassed Transcript that logged both to the screen and to a > file. > > I wonder if that might be an easy fix for Pharo? > > Tim > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] UbiquiTalk running in Pharo 1.1
El mar, 07-09-2010 a las 07:57 +0200, Levente Uzonyi escribió: > On Mon, 6 Sep 2010, Miguel Enrique Cobá Martínez wrote: > > > > > snip > > "Installer AFAIK does a lot of things, so in a way it was bloated, that > was the reason for gofer showing up (also the fact that installer didn't > unload packages and gofer does, I think)." > > Installer can unload Monticello packages (besides being able to load stuff > from sources which are not used by Pharo users) and I'm pretty sure it > does it the same way as Gofer does (this is a feature of MC). Exactly, that is the reason that I put AFAIK, and the reason I said it was bloated. The fact that you can download from a Mantis, squeakmap, GOODs, a magma repo, universes or a ftp repo has little impact if 99% of the times you are downloading from http repos squeaksource and gemstone. :) Cheers > > > Levente > ___ Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b7
John M McIntosh wrote: I've stuck a version (5.8b7) of the cocoa based os-x squeak cog JIT based VM in my experimental folder. Please ensure drawing looks sane, and how it interacts with the mouse and keyboard seems viable. http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b7.app.zip I finished the open/GL tuning and based on benchmarking I simplified the explicit flush required when a Smalltalk Morphic draw cycle fails to do a flush. Lastly I cross check the source code to ensure it compiles correctly for the iOS platform. -- === John M. McIntoshTwitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com == Hi John, I found something strange with reported file creation and modification time. The values answered by #primLookupEntryIn:index: are (Tested on Squeak 4.1, Mac OS 10.5.8): 4.2.4 VM (Stack VM): 3461318674 3461318674 newFile 3449660476 3447966888 Squeak 4.2.4beta1U.app 3460975777 3460916669 Squeak.app 3460551046 3460551046 Squeak4.1.image 3449660435 3448977726 SqueakV41.sources 5.8b7 (Cog experimental VM) 3461314066 3461314066 newFile 3447962280 3447962280 Squeak 4.2.4beta1U.app 3460912061 3460912061 Squeak.app 3448973124 3460546438 Squeak4.1.image 3448973118 3448973118 SqueakV41.sources Take for instance SqueakV41.sources: DateAndTime fromSeconds: 3449660435 2010-04-25T15:00:35-03:00 DateAndTime fromSeconds: 3448977726 2010-04-17T17:22:06-03:00 "This is the correct one according to Finder, 4.2.4 modification time" DateAndTime fromSeconds: 3448973118 2010-04-17T16:05:18-03:00 DateAndTime fromSeconds: 3448973118 2010-04-17T16:05:18-03:00 So I'm, getting incorrect time info in the FileList. Something else I see is that 4.2.4 VM answers the same value for creation and modification time for some files, while 5.8b7 answers the same value for other files. (Why?) For the newly created "newFile", both answer the same value for creation and modification time. The correct value is (again) the one answered by 4.2.4. I'm at the ART time zone. Thanks, Juan Vuletich ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Compiling the VM for MacOSX
> "Unlike to the GNU/Linux platforms the Mac OSX way don't have pre-generated > source, then if you want to recompile the VM you must generate the src from > VMMaker (refer to VMMaker Chapter to do that)." > > I guess you skipped this step? thanks Henrik. Right, I unfortunately skipped this. Now, I am almost done, only one error left: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= mkdir "/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/build/Development/Squeak VM Opt.app/Contents/MacOS" cd /Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM setenv MACOSX_DEPLOYMENT_TARGET 10.5 /Developer/usr/bin/gcc-4.2 -arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk -L/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/build/Development -F/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/build/Development -F/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks -filelist "/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/build/SqueakVMUNIXPATHS.build/Development/Squeak VM Universal.build/Objects-normal/i386/Squeak VM Opt.LinkFileList" -mmacosx-version-min=10.5 -framework CoreFoundation -framework Carbon -framework OpenGL -framework AGL -framework QuickTime -framework CoreAudio -framework AudioToolbox -framework IOKit -framework Foundation -framework Cocoa -framework ApplicationServices -prebind -o "/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/build/Development/Squeak VM Opt.app/Contents/MacOS/Squeak VM Opt" Undefined symbols: "_setMicroSecondsandOffset", referenced from: _primitiveUtcWithOffset in interp.o ld: symbol(s) not found collect2: ld returned 1 exit status -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Where this _setMicroSecondsandOffset is defined? No idea whether this is related or not, but I had to leave TestOSAPlugin out when generating the vm code. This plugin cannot be produced apparently, a class is missing. Cheers, Alexandre > > Cheers, > Henry > > Den 07.09.2010 15:18, skrev Alexandre Bergel: >> Hi! >> >> I followed the instruction given on: >> >> http://book.pharo-project.org/book/Virtual-Machine/Building/BuildVMOnOSX >> >> 134 errors are reported. >> >> Below the first line of the report: >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> Building target “Squeak VM Universal” of project “SqueakVMUNIXPATHS” with >> configuration “Development” — (134 errors) >> cd /Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer >> /Developer/usr/bin/gcc-4.2 -x c -arch i386 -fmessage-length=0 -pipe >> -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wmissing-prototypes >> -Wmissing-braces -Wparentheses -Wunused-function -Wunused-label >> -Wunused-parameter -Wunused-variable -Wunused-value -Wsign-compare >> -DHAVE_NANOSLEEP -DEXTERNALPRIMSDEBUG -DTARGET_API_MAC_CARBON >> -DSQUEAK_BUILTIN_PLUGIN -DHAVE_SYS_TIME_H -isysroot >> /Developer/SDKs/MacOSX10.5.sdk -mfix-and-continue -mmacosx-version-min=10.5 >> -gdwarf-2 >> "-I/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/build/SqueakVMUNIXPATHS.build/Development/Squeak >> VM Universal.build/Squeak VM Opt.hmap" -DLSB_FIRST -mtune=prescott >> -march=pentium-m -mfpmath=sse -DUSE_INLINE_MEMORY_ACCESSORS >> -F/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/build/Development >> >> -F/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks >> >> -I/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/build/Development/include >> -I/D >> eveloper/SDKs/MacOSX10.5.sdk/Developer/Headers/FlatCarbon >> "-I/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/build/SqueakVMUNIXPATHS.build/Development/Squeak >> VM Universal.build/DerivedSources/i386" >> "-I/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/build/SqueakVMUNIXPATHS.build/Development/Squeak >> VM Universal.build/DerivedSources" -c >> /Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/src/vm/intplugins/ADPCMCodecPlugin/ADPCMCodecPlugin.c >> -o >> "/Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/build/SqueakVMUNIXPATHS.build/Development/Squeak >> VM Universal.build/Objects-normal/i386/ADPCMCodecPlugin.o" >> i686-apple-darwin9-gcc-4.2.1: >> /Users/alexandrebergel/Desktop/SqueakVM/MyOwnVM/Developer/src/vm/intplugins/ADPCMCodecPlugin/ADPCMCodecPlugin.c: >> No such file or directory >> i686-apple-darwin9-gcc-4.2.1: warning: '-x c' after last input file has no >> effect >> i686-apple-darwin9-gcc-4.2.1: no input files >> i686-apple-darwin9-gcc-4.2.1: no input files >> i686-apple-darwin9-gcc-4.2.1: no input files >> i686-apple-darwin9-gcc-4.2.1: no input files >> i686-apple-darwin9-gcc-4.2.1: no input files >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >> Is there something wrong I did? >> >> Help is highly appreciated... >> >> Cheers, >> Alexandre >> >> > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.in
Re: [Pharo-project] WebClient License Update
On 07.09.2010 09:03, Andreas Raab wrote: > Hi - > > After careful consideration I've decided to put WebClient under the MIT > license, and updated the repository at > http://www.squeaksource.com/WebClient.html to reflect the license change. > > If you're curious why I'm making the change, the answer is really that > the code isn't all that unique and even though I'm not done with it it's > good enough to be released and by now I simply get more benefits from it > being thoroughly tested by as many people as possible. That and the (to > me surprising) amount of interest that WebClient has received in > combination with the (to me disturbing) lack of due diligence that many > users of WebClient apparently have. I think we can all take away a > lesson from this little incident that even if you find some random code > on the net it doesn't mean it's up for grabs. > > Also, if I may be so bold, let me propose the "2 step process to eternal > license happiness". It's really simple: > > [ ] Did we check the license of the package? > [ ] Did we contact the author of the package? > > If you check off the above two steps whenever you're about to use some > third-party code, I think you'll find that situations like the one we've > encountered here are virtually impossible. Attach the steps to the bug > tracker if you must, but follow them. > > Since you know how to verify the license status on your own, let me add > the second step of the process and once more repeat that I would rather > keep WebClient an externally loadable package. If at all possible I urge > you to look at what has been done with HTTPSocket in Squeak and adopt a > similar approach; that is provide a minimal internal HTTP interface and > allow third-party libraries (WebClient or other) to hook into this > interface. There is really no need to have everything tied together at > the hip; HTTPSocket is a reasonable facade for HTTP requests in the kernel. > > Regarding write access to the WebClient repository, I'm not a fan of > making repos world-writable (this is really a sign of abandonware) but > due to the license I'm fine with granting Sven and Philippe write access > if they want it (drop me a note if you do). Did you change your position towards #squeakToUtf8 and string concatenation (I didn't follow the entire previous thread)? Otherwise it would probably make more sense if I continue sending patches. Now don't get me wrong, you're of course allowed to write code whichever way you see fit and reject anything that doesn't follow this. But the same goes for me. And for me it's important that code loads without any overrides. So I'm probably going to set up a WebClientPharo or WebClientPhilippe or something repository. Cheers Philippe ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Compiling the VM for MacOSX
Ah well actually you are attempting to build an obsolete VM. However we might
as well ensure you can do that for historical reasons.
I'm not sure why the setMicroSecondsandOffset does not resolve into a default
setMicroSecondsandOffset in the interp.c
since mine has
/* A default substitute for unimplemented ioUtcWithOffset external
function. */
sqInt setMicroSecondsandOffset(sqLong * microSeconds, int * utcOffset) {
flag("toRemove");
return -1;
}
However buried in a email message from last March is a slight error which
prevented the ioUtcWithOffset() defined in sqMacTime.c
from being used. Therefore I've altered sqMacTime.c & sqPlatformSpecific.h
in the Mac OS carbon SVN tree. You should check
out a new copy of that.
Ok, so building an obsolete VM might be fun and let's see if you can do it, but
you should build a 5.x VM from the iOS tree.
See platform/iOS/vm/SqueakPureObjc.xcodeproj in order to build
SqueakPureObjc The cocoa based 5.x VM for OSX 32bit & 64bit
supporting a 32bit image format
SqueakPureObjc64*64 The cocoa based 5.x VM for OSX 64bit supporting a 64bit
image format
SqueakNoOGLIPhone The cocoa based 2.x VM for the iOS devices
Also lurking in there is the
SqueakPureObjcCogVM.xcodeproj
which lets you build:
SqueakNoOGLIPhone The cocoa based Cog Stack Based VM for iOS devices
SqueakPureObjc The cocoa based Cog JIT VM for OSX 32bit.
However that xcodeproj is still a work in progress and Eliot and I are still
merging changes.
Later open SqueakPureObjc.xcodeproj
compile link you'll find a pre-existing src file that is somewhat current.
Swap in a newer one if needbe.
On 2010-09-07, at 10:00 AM, Alexandre Bergel wrote:
> Undefined symbols:
> "_setMicroSecondsandOffset", referenced from:
> _primitiveUtcWithOffset in interp.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> Where this _setMicroSecondsandOffset is defined?
>
> No idea whether this is related or not, but I had to leave TestOSAPlugin out
> when generating the vm code. This plugin cannot be produced apparently, a
> class is missing.
>
> Cheers,
> Alexandre
--
===
John M. McIntoshTwitter: squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===
smime.p7s
Description: S/MIME cryptographic signature
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b9
I've stuck a version (5.8b9) of the cocoa based os-x squeak cog JIT based VM in my experimental folder. http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b9.app.zip Changes are: (a) Slight changes to the Open/GL code in hopes to make it work better on 10.5 machines (b) Add ioUtcWithOffset (c) Application quit menu, quit from dock, or window close now triggers a Areithfa Ffenestri window event saying the window is closing. Most images (I guess?) look for that and prompt the user to save or not-save the image and/or quit. People producing Squeak Images should confirm the behaviour is what they expect. (d) print problems with cmd-shift-key not correctly working CMD-SHIFT-n as an example. (e) Code sign app -- === John M. McIntoshTwitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === smime.p7s Description: S/MIME cryptographic signature ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] glamorous theme :)
Hi Laurent, On the Macbook Pro monitor it works well, but indeed, I also thought this would be a problem on less strong monitors. I now updated the color to get a stronger shade of blue. Cheers, Doru On 7 Sep 2010, at 08:47, laurent laffont wrote: > Hi Doru, > > Using Glamourous I hardly see which button is focused in System Browser > between instance or class. So I've made mistakes several times yesterday :) > > I really like this theme, especially on a slow computer. > > > Cheers, > > Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ > > > On Sat, Sep 4, 2010 at 11:18 PM, Tudor Girba wrote: > Hi, > > Over the past week I worked on a new theme for Pharo called the Glamorous > Theme :). The theme is developed in the context of the Glamour project, and > its goal is to create a look that: > - does not look like a specific operating system. In particular, the icons > should be operating system agnostic, because, for example, people in Windows > are confused by the red, yellow, green buttons of apple. > - uses a limited amount of colors and effects. > > It is still work in progress, but you can get the current version by > executing: > > Gofer new >squeaksource: 'Glamour'; >package: 'Glamour-Morphic-Theme'; >load. > GLMUITheme defaultSettings: nil. > GLMUITheme beCurrent. > GLMUITheme setPreferredWorldBackground. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of problem > understanding." > > > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it." ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [Moose-dev] glamorous theme :)
Sven wrote: >I would include a small number of well maintained/supported >themes. >Of course, every image needs a default, but choice is good here (it is the >whole point). This is something I have to disagree strongly with. Choice in themes does not work for us. We don't have the manpower to maintain them. In user interfaces, consistency is good, and I want one good theme, not ten bad or mediocre. Stephan Eggermont ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] glamorous theme :)
On Tue, Sep 7, 2010 at 9:48 PM, Tudor Girba wrote:
> Hi Laurent,
>
> On the Macbook Pro monitor it works well, but indeed, I also thought this
> would be a problem on less strong monitors.
>
> I now updated the color to get a stronger shade of blue.
>
What do you think of this one (with a pressed look) ?
buttonSelectedFillStyleFor: aButton
"Return the normal button fillStyle for the given button."
| toptop top bottom base |
base := self glamorousBaseColorFor: aButton.
toptop := base muchDarker.
top := base.
bottom := (self glamorousLightSelectionColorFor: aButton) muchLighter.
^(GradientFillStyle ramp: {
0.0->toptop.
0.1->top.
0.9->bottom.})
origin: aButton bounds origin;
direction: 0 @ aButton height;
radial: false
Laurent Laffont
http://pharocasts.blogspot.com/
http://magaloma.blogspot.com/
>
> Cheers,
> Doru
>
>
> On 7 Sep 2010, at 08:47, laurent laffont wrote:
>
> > Hi Doru,
> >
> > Using Glamourous I hardly see which button is focused in System Browser
> between instance or class. So I've made mistakes several times yesterday :)
> >
> > I really like this theme, especially on a slow computer.
> >
> >
> > Cheers,
> >
> > Laurent Laffont
> >
> > http://pharocasts.blogspot.com/
> > http://magaloma.blogspot.com/
> >
> >
> > On Sat, Sep 4, 2010 at 11:18 PM, Tudor Girba
> wrote:
> > Hi,
> >
> > Over the past week I worked on a new theme for Pharo called the Glamorous
> Theme :). The theme is developed in the context of the Glamour project, and
> its goal is to create a look that:
> > - does not look like a specific operating system. In particular, the
> icons should be operating system agnostic, because, for example, people in
> Windows are confused by the red, yellow, green buttons of apple.
> > - uses a limited amount of colors and effects.
> >
> > It is still work in progress, but you can get the current version by
> executing:
> >
> > Gofer new
> >squeaksource: 'Glamour';
> >package: 'Glamour-Morphic-Theme';
> >load.
> > GLMUITheme defaultSettings: nil.
> > GLMUITheme beCurrent.
> > GLMUITheme setPreferredWorldBackground.
> >
> > Cheers,
> > Doru
> >
> > --
> > www.tudorgirba.com
> >
> > "Problem solving efficiency grows with the abstractness level of problem
> understanding."
> >
> >
> >
> >
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
>
> --
> www.tudorgirba.com
>
> "It's not what we do that matters most, it's how we do it."
>
>
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] glamorous theme :)
It's not bad, but and I do not use this metaphor in the theme. As I said, the
goal of the theme is to be really simple and to exercise the minimum amount of
graphical variables that would still enable the distinction between the
different ui states. The theme is not quite where I would like it to be, but
definitely the "pressed button" would introduce another graphical variable that
is not really needed from my point of view.
Cheers,
Doru
On 7 Sep 2010, at 22:37, laurent laffont wrote:
> On Tue, Sep 7, 2010 at 9:48 PM, Tudor Girba wrote:
> Hi Laurent,
>
> On the Macbook Pro monitor it works well, but indeed, I also thought this
> would be a problem on less strong monitors.
>
> I now updated the color to get a stronger shade of blue.
>
> What do you think of this one (with a pressed look) ?
>
> buttonSelectedFillStyleFor: aButton
> "Return the normal button fillStyle for the given button."
>
> | toptop top bottom base |
> base := self glamorousBaseColorFor: aButton.
> toptop := base muchDarker.
> top := base.
> bottom := (self glamorousLightSelectionColorFor: aButton) muchLighter.
>
> ^(GradientFillStyle ramp: {
> 0.0->toptop.
> 0.1->top.
> 0.9->bottom.})
> origin: aButton bounds origin;
> direction: 0 @ aButton height;
> radial: false
>
>
>
> Laurent Laffont
>
> http://pharocasts.blogspot.com/
> http://magaloma.blogspot.com/
>
>
>
> Cheers,
> Doru
>
>
> On 7 Sep 2010, at 08:47, laurent laffont wrote:
>
> > Hi Doru,
> >
> > Using Glamourous I hardly see which button is focused in System Browser
> > between instance or class. So I've made mistakes several times yesterday :)
> >
> > I really like this theme, especially on a slow computer.
> >
> >
> > Cheers,
> >
> > Laurent Laffont
> >
> > http://pharocasts.blogspot.com/
> > http://magaloma.blogspot.com/
> >
> >
> > On Sat, Sep 4, 2010 at 11:18 PM, Tudor Girba wrote:
> > Hi,
> >
> > Over the past week I worked on a new theme for Pharo called the Glamorous
> > Theme :). The theme is developed in the context of the Glamour project, and
> > its goal is to create a look that:
> > - does not look like a specific operating system. In particular, the icons
> > should be operating system agnostic, because, for example, people in
> > Windows are confused by the red, yellow, green buttons of apple.
> > - uses a limited amount of colors and effects.
> >
> > It is still work in progress, but you can get the current version by
> > executing:
> >
> > Gofer new
> >squeaksource: 'Glamour';
> >package: 'Glamour-Morphic-Theme';
> >load.
> > GLMUITheme defaultSettings: nil.
> > GLMUITheme beCurrent.
> > GLMUITheme setPreferredWorldBackground.
> >
> > Cheers,
> > Doru
> >
> > --
> > www.tudorgirba.com
> >
> > "Problem solving efficiency grows with the abstractness level of problem
> > understanding."
> >
> >
> >
> >
> > ___
> > Pharo-project mailing list
> > Pharo-project@lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
>
> --
> www.tudorgirba.com
>
> "It's not what we do that matters most, it's how we do it."
>
>
--
www.tudorgirba.com
"Relationships are of two kinds: those we choose and those that happen. They
both matter."
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] primitive 65 failures
Why does primitive 65 (#next) include a test on the position vs. read length and sometimes fall back on indexing the collection? I have been creating my own stream for serial ports, and it was driving me nuts. After staring at the obvious (the primitive was failing sooner than I expected), I finally looked at Dolphin and saw the same test and fallback. Doing the analogous things in my code left it working a lot better than it had been. What gives? Are we perhaps suffering from a primitive that fails too easily and is running slow code as a result, or is there a "valid" reason for the primitive to fail? Bill ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] primitive 65 failures
On Tue, Sep 7, 2010 at 2:13 PM, Schwab,Wilhelm K wrote: > Why does primitive 65 (#next) include a test on the position vs. read > length and sometimes fall back on indexing the collection? I have been > creating my own stream for serial ports, and it was driving me nuts. After > staring at the obvious (the primitive was failing sooner than I expected), I > finally looked at Dolphin and saw the same test and fallback. Doing the > analogous things in my code left it working a lot better than it had been. > > What gives? Are we perhaps suffering from a primitive that fails too > easily and is running slow code as a result, or is there a "valid" reason > for the primitive to fail? > Bill, try removing use of the primitive and see if you can see any slowdown in the system. If you don't (as I've also) then perhaps the primitive is a bad idea anyway. 2¢ Eliot > > Bill > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Compiling the VM for MacOSX
Thanks, it works fine now.
I use an obsolete version? Strange. I downloaded the lastest version of
VMMaker. By the way, the produced vm is fairly slow. I do not know whether
there is an option somewhere for inline or something...
Thanks,
Alexandre
On 7 Sep 2010, at 15:05, John M McIntosh wrote:
> Ah well actually you are attempting to build an obsolete VM. However we might
> as well ensure you can do that for historical reasons.
>
> I'm not sure why the setMicroSecondsandOffset does not resolve into a default
> setMicroSecondsandOffset in the interp.c
> since mine has
> /*A default substitute for unimplemented ioUtcWithOffset external
> function. */
>
> sqInt setMicroSecondsandOffset(sqLong * microSeconds, int * utcOffset) {
> flag("toRemove");
> return -1;
> }
>
>
> However buried in a email message from last March is a slight error which
> prevented the ioUtcWithOffset() defined in sqMacTime.c
> from being used. Therefore I've altered sqMacTime.c & sqPlatformSpecific.h
> in the Mac OS carbon SVN tree. You should check
> out a new copy of that.
>
> Ok, so building an obsolete VM might be fun and let's see if you can do it,
> but you should build a 5.x VM from the iOS tree.
>
> See platform/iOS/vm/SqueakPureObjc.xcodeproj in order to build
> SqueakPureObjcThe cocoa based 5.x VM for OSX 32bit &
> 64bit supporting a 32bit image format
> SqueakPureObjc64*64 The cocoa based 5.x VM for OSX 64bit supporting a 64bit
> image format
> SqueakNoOGLIPhone The cocoa based 2.x VM for the iOS devices
>
> Also lurking in there is the
> SqueakPureObjcCogVM.xcodeproj
> which lets you build:
> SqueakNoOGLIPhone The cocoa based Cog Stack Based VM for iOS devices
> SqueakPureObjcThe cocoa based Cog JIT VM for OSX
> 32bit.
> However that xcodeproj is still a work in progress and Eliot and I are still
> merging changes.
>
>
> Later open SqueakPureObjc.xcodeproj
> compile link you'll find a pre-existing src file that is somewhat current.
> Swap in a newer one if needbe.
>
>
> On 2010-09-07, at 10:00 AM, Alexandre Bergel wrote:
>
>> Undefined symbols:
>> "_setMicroSecondsandOffset", referenced from:
>> _primitiveUtcWithOffset in interp.o
>> ld: symbol(s) not found
>> collect2: ld returned 1 exit status
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>
>> Where this _setMicroSecondsandOffset is defined?
>>
>> No idea whether this is related or not, but I had to leave TestOSAPlugin out
>> when generating the vm code. This plugin cannot be produced apparently, a
>> class is missing.
>>
>> Cheers,
>> Alexandre
>
> --
> ===
> John M. McIntoshTwitter: squeaker68882
> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
> ===
>
>
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Compiling the VM for MacOSX
On 2010-09-07, at 3:44 PM, Alexandre Bergel wrote: > Thanks, it works fine now. > > I use an obsolete version? Strange. I downloaded the lastest version of > VMMaker. By the way, the produced vm is fairly slow. I do not know whether > there is an option somewhere for inline or something... > > Thanks, > Alexandre Ah, you'll need to explain which VM you built? Also when you build you get to pick between DEBUG and Deployment/Release in OS-X and I assure you the DEBUG version is 10x slower than the non-debug one. Now. VMMaker translates a subset of Smalltalk known as Slang to C code. This is the core of the Virtual Machine and processes Smalltalk byte codes it reads from the Squeak Image to perform some obscure task... As Block Closures and Cog JIT work , UTC time, etc, have been added in the last year that has resulted in new versions of VMMaker since we are changing the functionality of the VM. However the VM is decoupled from the issue of the supporting platform, which progresses at a different rate. In order to run the VM on a particular hardware device/software platform the person wanting to port the VM has to follow documentation such as found as http://isqueak.org/PlatformVMAPI to create the platform specific API to enable a user of the device to enter UI input and have the VM produce some form of output (may or may not be visual). The 'Mac OS' folder contains platform code to build a carbon based OS-X system which has it's roots in Apple's OS 7.5.x from 1991. This evolved over the years to support OS-X as an 'OS-X legacy carbon application' and is known as the 3.x series before MacIntel machines, and 4.x after MacIntel with 4.2.5 being the last shipped version. In June of 2008 the ESUG board provided funding to assist in the development of the platform files for the iPhone, further funding granted in October of 2009 enabled us to rebuild a new set of platform files for OS-X and iOS that (a) Bring the macintosh os-x platform support code up to the latest version of API support using Cocoa. (b) Enable the ability of the VM & API to run in 32 bit or 64 bit mode on MacIntel or PowerPC. * (c) Enable the ability to run the VM in 64 bit mode working with a 32 bit image (d) Enable the ability to run the VM in 64 bit mode working with a 64 bit image. (e) Rewrite the Squeak in the Browser api to work with Apple's 64 bit requirements. *Cough* pending... This resulted in the current 5.x series, which support 32bit/64bit VM on os-x against a 32bit or 64bit image, or a 32bit VM with 32bit image on iOS devices. Work from teleplace also offers a 32bit vm in stack or JIT implementation against a 32bit image. *Apple did not supply 64bit versions of the GUI for the PowerPC which makes it impossible to offer a 64bit compiled VM on the PowerPC because one lacks a Graphical User Interface. -- === John M. McIntoshTwitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === smime.p7s Description: S/MIME cryptographic signature ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] UbiquiTalk running in Pharo 1.1
Miguel Enrique Cobá Martínez-2 wrote: > > Exactly, that is the reason that I put AFAIK, and the reason I said it > was bloated. The fact that you can download from a Mantis, squeakmap, > GOODs, a magma repo, universes or a ftp repo has little impact if 99% of > the times you are downloading from http repos squeaksource and > gemstone. :) > [thinking out loud] This sounds like a great reason to clean and modularize, but why a whole new thing. -- View this message in context: http://forum.world.st/UbiquiTalk-running-in-Pharo-1-1-tp2400767p2530693.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] yarg: Pharo grammar ...
This is Yet Another Request for the Grammar to Pharo/Squeak Smalltalk? I have seen this: http://wiki.squeak.org/squeak/409 but it is very old and doesn't appear to cater for Pharo/Squeak additions. Can someone point me to a more recent grammar? Rgs, James. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] UbiquiTalk running in Pharo 1.1
El mar, 07-09-2010 a las 19:22 -0700, Sean P. DeNigris escribió: > > Miguel Enrique Cobá Martínez-2 wrote: > > > > Exactly, that is the reason that I put AFAIK, and the reason I said it > > was bloated. The fact that you can download from a Mantis, squeakmap, > > GOODs, a magma repo, universes or a ftp repo has little impact if 99% of > > the times you are downloading from http repos squeaksource and > > gemstone. :) > > > > [thinking out loud] This sounds like a great reason to clean and modularize, > but why a whole new thing. Yes I agree, but those download/install options are in Installer-Core :) so maybe splitting the core in Installer-ReallyCore (or Installer-Atom :) would be the way. Anyway, Gofer was created by Lukas, maybe because he could, maybe because the maintainer of Installer wasn't reachable, whatever. The fact is that nothing of those features have been missed since gofer is widely used in Pharo. So maybe they were really not needed. Less is more. Cheers > -- > View this message in context: > http://forum.world.st/UbiquiTalk-running-in-Pharo-1-1-tp2400767p2530693.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Compiling the VM for MacOSX
alex do not forget to update the web page with the information you learned.
On Sep 8, 2010, at 12:44 AM, Alexandre Bergel wrote:
> Thanks, it works fine now.
>
> I use an obsolete version? Strange. I downloaded the lastest version of
> VMMaker. By the way, the produced vm is fairly slow. I do not know whether
> there is an option somewhere for inline or something...
>
> Thanks,
> Alexandre
>
>
> On 7 Sep 2010, at 15:05, John M McIntosh wrote:
>
>> Ah well actually you are attempting to build an obsolete VM. However we
>> might as well ensure you can do that for historical reasons.
>>
>> I'm not sure why the setMicroSecondsandOffset does not resolve into a
>> default setMicroSecondsandOffset in the interp.c
>> since mine has
>> /* A default substitute for unimplemented ioUtcWithOffset external
>> function. */
>>
>> sqInt setMicroSecondsandOffset(sqLong * microSeconds, int * utcOffset) {
>> flag("toRemove");
>> return -1;
>> }
>>
>>
>> However buried in a email message from last March is a slight error which
>> prevented the ioUtcWithOffset() defined in sqMacTime.c
>> from being used. Therefore I've altered sqMacTime.c &
>> sqPlatformSpecific.h in the Mac OS carbon SVN tree. You should check
>> out a new copy of that.
>>
>> Ok, so building an obsolete VM might be fun and let's see if you can do it,
>> but you should build a 5.x VM from the iOS tree.
>>
>> See platform/iOS/vm/SqueakPureObjc.xcodeproj in order to build
>> SqueakPureObjc The cocoa based 5.x VM for OSX 32bit &
>> 64bit supporting a 32bit image format
>> SqueakPureObjc64*64 The cocoa based 5.x VM for OSX 64bit supporting a 64bit
>> image format
>> SqueakNoOGLIPhoneThe cocoa based 2.x VM for the iOS devices
>>
>> Also lurking in there is the
>> SqueakPureObjcCogVM.xcodeproj
>> which lets you build:
>> SqueakNoOGLIPhoneThe cocoa based Cog Stack Based VM for iOS devices
>> SqueakPureObjc The cocoa based Cog JIT VM for OSX
>> 32bit.
>> However that xcodeproj is still a work in progress and Eliot and I are still
>> merging changes.
>>
>>
>> Later open SqueakPureObjc.xcodeproj
>> compile link you'll find a pre-existing src file that is somewhat current.
>> Swap in a newer one if needbe.
>>
>>
>> On 2010-09-07, at 10:00 AM, Alexandre Bergel wrote:
>>
>>> Undefined symbols:
>>> "_setMicroSecondsandOffset", referenced from:
>>>_primitiveUtcWithOffset in interp.o
>>> ld: symbol(s) not found
>>> collect2: ld returned 1 exit status
>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>>>
>>> Where this _setMicroSecondsandOffset is defined?
>>>
>>> No idea whether this is related or not, but I had to leave TestOSAPlugin
>>> out when generating the vm code. This plugin cannot be produced apparently,
>>> a class is missing.
>>>
>>> Cheers,
>>> Alexandre
>>
>> --
>> ===
>> John M. McIntoshTwitter: squeaker68882
>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
>> ===
>>
>>
>>
>>
>> ___
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> ___
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] UbiquiTalk running in Pharo 1.1
sean I do not know your computer but mine does not have a 5 inches floppy, 3.5 floppy, serial port, RS2332. Does it answer your question? Side remark: lukas probably write gofer because he needed something - well written - robust - small with only the code he needs - with tests so he did it and instead of keeping it for himself he accepted the **hassle** - to get pointed as a bad guy, - merge our changes And we all thank him for that! Lukas and other continue to rewrite everything you want :) I have a long list in my pocket (changelist, messageset, ...) So changes is good, non backward compatibility is good (look at apple). Let us face it and learn. Stef > > > Miguel Enrique Cobá Martínez-2 wrote: >> >> Exactly, that is the reason that I put AFAIK, and the reason I said it >> was bloated. The fact that you can download from a Mantis, squeakmap, >> GOODs, a magma repo, universes or a ftp repo has little impact if 99% of >> the times you are downloading from http repos squeaksource and >> gemstone. :) >> > > [thinking out loud] This sounds like a great reason to clean and modularize, > but why a whole new thing. > -- > View this message in context: > http://forum.world.st/UbiquiTalk-running-in-Pharo-1-1-tp2400767p2530693.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] yarg: Pharo grammar ...
- Check out the Parser/Scanner classes in every PharoDev image. - Check out the RBParser/RBScanner classes in the package AST-Core in every Pharo image. - Check out the class PPSmalltalkGrammar in the package PetitSmalltalk (http://scg.unibe.ch/research/helvetia/petitparser) which is an executable Smalltalk grammar that almost looks like an EBNF. Lukas 2010/9/8 James Ladd : > This is Yet Another Request for the Grammar to Pharo/Squeak Smalltalk? > > I have seen this: http://wiki.squeak.org/squeak/409 but it is very old and > doesn't appear to > cater for Pharo/Squeak additions. > > Can someone point me to a more recent grammar? > > Rgs, James. > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] yarg: Pharo grammar ...
On Sep 8, 2010, at 4:51 AM, James Ladd wrote: > This is Yet Another Request for the Grammar to Pharo/Squeak Smalltalk? > > I have seen this: http://wiki.squeak.org/squeak/409 but it is very old and > doesn't appear to > cater for Pharo/Squeak additions. > > Can someone point me to a more recent grammar? Lukas did a grammar for Smalltalk with PetitParser. This has many additional benefits over a traditional dead form of EBNF that it is -> executable. It's just Smallltak. Smalltalk grammar described in Smalltalk. So executing this code, you have a parser. -> reflective dynamic grammar. After executing, the parser is a graph of smaller parser=objects that you can inspect, modify and compose. http://www.lukas-renggli.ch/blog/petitparser-1 http://scg.unibe.ch/archive/papers/Reng10cDynamicGrammars.pdf Gofer new renggli: 'petit'; package: 'PetitParser'; load. Gofer new renggli: 'petit'; package: 'PetitSmalltalk'; load. Alternatively, I will send you the SmaCC grammar we originally used in the compiler. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient License Update
On 7 September 2010 21:15, Philippe Marschall wrote: > On 07.09.2010 09:03, Andreas Raab wrote: >> Hi - >> >> After careful consideration I've decided to put WebClient under the MIT >> license, and updated the repository at >> http://www.squeaksource.com/WebClient.html to reflect the license change. >> >> If you're curious why I'm making the change, the answer is really that >> the code isn't all that unique and even though I'm not done with it it's >> good enough to be released and by now I simply get more benefits from it >> being thoroughly tested by as many people as possible. That and the (to >> me surprising) amount of interest that WebClient has received in >> combination with the (to me disturbing) lack of due diligence that many >> users of WebClient apparently have. I think we can all take away a >> lesson from this little incident that even if you find some random code >> on the net it doesn't mean it's up for grabs. >> >> Also, if I may be so bold, let me propose the "2 step process to eternal >> license happiness". It's really simple: >> >> [ ] Did we check the license of the package? >> [ ] Did we contact the author of the package? >> >> If you check off the above two steps whenever you're about to use some >> third-party code, I think you'll find that situations like the one we've >> encountered here are virtually impossible. Attach the steps to the bug >> tracker if you must, but follow them. >> >> Since you know how to verify the license status on your own, let me add >> the second step of the process and once more repeat that I would rather >> keep WebClient an externally loadable package. If at all possible I urge >> you to look at what has been done with HTTPSocket in Squeak and adopt a >> similar approach; that is provide a minimal internal HTTP interface and >> allow third-party libraries (WebClient or other) to hook into this >> interface. There is really no need to have everything tied together at >> the hip; HTTPSocket is a reasonable facade for HTTP requests in the kernel. >> >> Regarding write access to the WebClient repository, I'm not a fan of >> making repos world-writable (this is really a sign of abandonware) but >> due to the license I'm fine with granting Sven and Philippe write access >> if they want it (drop me a note if you do). > > Did you change your position towards #squeakToUtf8 and string > concatenation (I didn't follow the entire previous thread)? Otherwise it > would probably make more sense if I continue sending patches. > > Now don't get me wrong, you're of course allowed to write code whichever > way you see fit and reject anything that doesn't follow this. But the > same goes for me. And for me it's important that code loads without any > overrides. So I'm probably going to set up a WebClientPharo or > WebClientPhilippe or something repository. > How about extra package in same repository (WebClient)? This is, of course, if you can't avoid it. > Cheers > Philippe > > > ___ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
