- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Building Cocoa 5.x series plugins, and testing help needed.

by Philippe Marschall

On 08.09.2010 09:11, John M McIntosh wrote: > Ok, I was going to spend a few of my precious evenings going thru and rebuilding all/some of the plugins for the Cocoa V5.x series of VMs. > Maybe even update them for the Cog Stack and JIT VM. > > However to do this I need some help from the community to test the creatures after they are done. > This evening I rebuild the Locale plugin and checked it into SVN to close this Pharo issue: > > http://code.google.com/p/pharo/issues/detail?id=2660 > > Now the problem is the Smalltalk code "Locale" for talking to this plugin sucks, it doesn't actually call most of the primitives and there aren't > any tests. Obviously if no-cares about using the plugin then I can't be bothered to poke at it. > > However I did write some Objective-C code and jiggle it with a stick. > > Therefore someone should write some tests, fix the Locale Class, etc and tell me if the plugin is sane. > > You'll find the plugin in the Experimental Folder sub folder "5.x Plugins" > > http://homepage.mac.com/johnmci/.Public/experimental/5.x%20Plugins/LocalePl… > > Just unzip and drop it into the *.app/Contents/Resources/ folder > > Now this might work with Squeak 4.x VMs, I've not tried it. > It might work with 64bit VMs (5.7x), I've not tried it. > It might work on PowerPC, I've not tried it. > It should work on the 5.8x series but I've not tried it out of canadian english, metric, PST, daylight savings time, georgian calendar settings > so I have no idea if it works oh say in France where you use Euros versus $ signs? Seems to work at first glance. I'll see what I can do about the Locale class and tests. > I've not bothered ported to iOS devices since it's unclear if anyone supports the Locale class? > > Lastly I'll take suggestions on which plugin to rework next. What does SqueakFFIPrims do exactly? I sounds kinda important. Cheers Philippe

Sept. 8, 2010

Re: [Pharo-project] WebClient License Update

by Philippe Marschall

On 08.09.2010 08:35, Igor Stasenko wrote: > On 7 September 2010 21:15, Philippe Marschall <kustos(a)gmx.net> 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)? I believe I just addressed that in the previous paragraph. Cheers Philippe

Sept. 8, 2010

[Pharo-project] Why -encoding latin1 in pharo.sh?

by GÃ¶ran Krampe

Hi all! A friend of mine wondered why he couldn't copy/paste a text in UTF8 (with swedish Ã¥Ã¤Ã¶ characters in it) and paste into Pharo without getting a debugger :) It turns out that the One-Click pharo.sh uses "-encoding latin1" when it starts the VM. But the code in Clipboard>>clipboardText evidently presumes that clipboard is coming in as UTF8 always - might be the new clipboard plugin that Michael did that does that? Anyway, why is pharo.sh using "-encoding latin1"? It works fine when that option is removed. regards, GÃ¶ran

Sept. 8, 2010

[Pharo-project] Building Cocoa 5.x series plugins, and testing help needed.

by John M McIntosh

Ok, I was going to spend a few of my precious evenings going thru and rebuilding all/some of the plugins for the Cocoa V5.x series of VMs. Maybe even update them for the Cog Stack and JIT VM. However to do this I need some help from the community to test the creatures after they are done. This evening I rebuild the Locale plugin and checked it into SVN to close this Pharo issue: http://code.google.com/p/pharo/issues/detail?id=2660 Now the problem is the Smalltalk code "Locale" for talking to this plugin sucks, it doesn't actually call most of the primitives and there aren't any tests. Obviously if no-cares about using the plugin then I can't be bothered to poke at it. However I did write some Objective-C code and jiggle it with a stick. Therefore someone should write some tests, fix the Locale Class, etc and tell me if the plugin is sane. You'll find the plugin in the Experimental Folder sub folder "5.x Plugins" http://homepage.mac.com/johnmci/.Public/experimental/5.x%20Plugins/LocalePl… Just unzip and drop it into the *.app/Contents/Resources/ folder Now this might work with Squeak 4.x VMs, I've not tried it. It might work with 64bit VMs (5.7x), I've not tried it. It might work on PowerPC, I've not tried it. It should work on the 5.8x series but I've not tried it out of canadian english, metric, PST, daylight savings time, georgian calendar settings so I have no idea if it works oh say in France where you use Euros versus $ signs? I've not bothered ported to iOS devices since it's unclear if anyone supports the Locale class? Lastly I'll take suggestions on which plugin to rework next. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Sept. 8, 2010

Re: [Pharo-project] WebClient License Update

by Igor Stasenko

On 7 September 2010 21:15, Philippe Marschall <kustos(a)gmx.net> 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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 8, 2010

Re: [Pharo-project] yarg: Pharo grammar ...

by Marcus Denker

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.

Sept. 8, 2010

Re: [Pharo-project] yarg: Pharo grammar ...

by Lukas Renggli

- 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 <james_ladd(a)hotmail.com>: > 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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Sept. 8, 2010

Re: [Pharo-project] UbiquiTalk running in Pharo 1.1

by StÃ©phane Ducasse

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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 8, 2010

Re: [Pharo-project] Compiling the VM for MacOSX

by StÃ©phane Ducasse

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 >> 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. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> =========================================================================== >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 8, 2010

Re: [Pharo-project] UbiquiTalk running in Pharo 1.1

by Miguel Enrique CobÃ¡ MartÃnez

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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Sept. 8, 2010