- Pharo-dev - lists.pharo.org

[Pharo-project] Pharo Kernel OSProcess evaluator
by Pavel Krivanek Aug. 12, 2011

Aug. 12, 2011

Hi, I created a new job on CI server that creates a Pharo Kernel image with OSProcess loaded and simple console based evaluator. Of course something like Coral would be better ;-) Cheers -- Pavel

3 6

[Pharo-project] 1.3 link downloads 1.4 image
by Max Leske Aug. 11, 2011

Aug. 11, 2011

The "Pharo 1.3" link on the webpage (beneath "Pharo 1.3 image (unstable)") actually downloads the 1.4 image. So at the moment there is no way to get a 1.3 image from the webpage. Max

1 0

[Pharo-project] Zinc: urls without scheme
by Igor Stasenko Aug. 11, 2011

Aug. 11, 2011

'www.squeaksource.com' asZnUrl host -> nil 'http://www.squeaksource.com' asZnUrl host -> 'www.squeaksource.com' i wonder if url should have notion of default scheme and if sheme not specified, use a default one i.e. 'http:' ? 'www.squeaksource.com' asUrl authority -> 'www.squeaksource.com' 'www.squeaksource.com' asUrl scheme -> 'http' -- Best regards, Igor Stasenko AKA sig.

3 9

Re: [Pharo-project] [Seaside] Seaside on Pharo-Kernel
by Mariano Martinez Peck Aug. 11, 2011

Aug. 11, 2011

Wow. This is awesome: a working Seaside image in 4.3 MB. On Tue, Aug 9, 2011 at 3:11 PM, Pavel Krivanek <squeak3(a)continentalbrno.cz>wrote: > There is a prepared image: > > > https://ci.lille.inria.fr/pharo/view/Pharo-Kernel/job/Pharo%20Kernel%20Seas… > > -- Pavel > > On Tue, Aug 9, 2011 at 3:03 PM, Sven Van Caekenberghe <sven(a)beta9.be> > wrote: > > Hi Pavel, > > > > This is really cool! > > > > Sven > > > > On 09 Aug 2011, at 12:52, Pavel Krivanek wrote: > > > >> Hi, > >> > >> there's possible to load Seaside to the Pharo-Kernel. > >> > >> 1) Load PharoKernel-Gofer image from CI server > >> ( > https://ci.lille.inria.fr/pharo/view/Pharo-Kernel/job/Pharo%20Kernel%20Gofe… > ) > >> > >> 2) run the image with seaside.st script as an argument. That will > >> create about 4.1 MB image with basic Seaside packages and basic > >> examples. > >> > >> 3) run the image with run.st script (note that starting of the server > >> in the seaside.st script will hang, currently I have no idea why). > >> > >> 4) see if everything works at > http://localhost:8080/examples/examplebrowser > >> > >> Cheers, > >> -- Pavel > >> <run.st><seaside.st>_______________________________________________ > >> seaside mailing list > >> seaside(a)lists.squeakfoundation.org > >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > _______________________________________________ > > seaside mailing list > > seaside(a)lists.squeakfoundation.org > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > -- Mariano http://marianopeck.wordpress.com

4 3

[Pharo-project] Next target for pharo
by Noury Bouraqadi Aug. 11, 2011

Aug. 11, 2011

It's running Linux. Noury Begin forwarded message: > Date: 4 aoÃ»t 2011 06:00:16 HAEC > Subject: Raspberry Pi Interview With Eben Upton > Source: robots.net > > > > > > The robot revolution just got a little closer thanks to some of the cool devices that are coming down the pipe. One such cool device is called the Raspberry Pi. The Raspberry Pi device is basically a $25 Linux PC on a credit card sized board! This microcomputer looks perfectly suited as a low cost, micro form factor, low power, PC performance robot brain. If you think that's unbelievable, well, believe it! Sure it's not available just yet but already the Alpha Boards are being manufactured and they anticipate the devices will be available for sale later in 2011. > > I contacted the Director of the Raspberry Pi Foundation, Eben Upton, and he graciously answered some of my questions pertaining to his foundation, the Raspberry Pi device, and how the device relates to robotics. After the jump, read more about the Raspberry Pi device and read the interview by Director, Eben Upton. > Read moreâ¦ > Noury Bouraqadi http://car.mines-douai.fr/noury -- -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France -5th International Conference on Smalltalk Technologies http://www.fast.org.ar November 3th - 5th, 2011 Universidad Nacional de Quilmes (Argentina)

1 0

[Pharo-project] omit support in PetitParser
by Camillo Bruni Aug. 11, 2011

Aug. 11, 2011

I quickly hacked (with a lot of tests) support for omit in PetitParser. This should simplify some parsing efforts as an additional filtering step could be avoided. parser := ($" asParser omit, $" asParser negate star flatten, $" asParser omit) parser parse: '"asdfsd"' "yields directly #('asdfsd') " vs parser := ($" asParser, $" asParser negate star flatten, $" asParser) parser parse: '"asdfsd"' which yields #($" 'asdfsd' $") I pushed my solution to the petitparser repos. I didn't add full support for flatten. cami

4 8

[Pharo-project] Explicitly avoiding process switch
by Mariano Martinez Peck Aug. 11, 2011

Aug. 11, 2011

Hi guys. We were discussing yesterday with Marcus about the following.... I remember a problem we have in Pharo because of changing "foo == nil" to "foo isNil" in some important places like Process/Delay/Semaphore. Such change introduces a suspension point, where if I understand correctly, the scheduler can switch to another process only during method sends. #== is optimized with a special bytecode and there is no message send. Sending #isNil is a message sent, and hence we introduce a suspension point. In 99% of the cases this is not a problem. But I can imagine that there are places (mostly those related to Process/Delay/Semaphore) where this changes can be very very bad. To do some experiments, I want to remove the bytecode for #== but of course, I think I will have all these problems. And there are more. Marcus told me that some optimizations done by the compiler end up sending #==. And I also remember some code he told me (I think it was #allObjectsDo:) that would never finish because of the block closure objects creation. So...what about making the necessity of NOT sending a message or NOT introducing a suspension point more explicit? first we should have the support for that and second know each place where we need them. The most basic thing I can think of is doing something like: (ParseNode classVarNamed: 'StdSelectors') at: #== put: #bytecodedEqualEqual. Compiler recompileAll. And put a nice comment why one may want to use #optimizedEqualEqual. But again, in which places should I change #== for #bytecodedEqualEqual Any thought or idea about them is really appreciated. Thanks -- Mariano http://marianopeck.wordpress.com

1 0

Aug. 11, 2011

Hi guys I got a really strange behavior: I integrated - Issue 4607: Refactor Debugger >> content:notifying:. Thanks Camillo Bruni. http://code.google.com/p/pharo/issues/detail?id=4607 - Issue 4606: Fix drawing shadow of morphs. Thanks Igor Stasenko. http://code.google.com/p/pharo/issues/detail?id=4606 and I could not type enter on workspace I could everywhere else. I could reopen a workspace and it worked and suddenly stopped again. stef

3 4

Aug. 10, 2011

14080 ----- - Issue 4607: Refactor Debugger >> content:notifying:. Thanks Camillo Bruni. http://code.google.com/p/pharo/issues/detail?id=4607 - Issue 4606: Fix drawing shadow of morphs. Thanks Igor Stasenko. http://code.google.com/p/pharo/issues/detail?id=4606 - Issue 4607: Minor-fix-to-the-old-MCMergeBrowser. Thanks Camillo Bruni. http://code.google.com/p/pharo/issues/detail?id=4601 more to come as soon as I get some sleep :) Stef

1 0

[Pharo-project] Strange bug in text selection
by Igor Stasenko Aug. 10, 2011

Aug. 10, 2011

which leads to #basicNew: primitive fail, because it passing a negative number (no surprise, it fails). According to stack trace, a Text>> copyFrom:to: is called with arguments: start = 100 stop = 44 (instead of having start = 44 , stop = 100) it is called from MultiNewParagraph>>buildSelectionBlocksFrom:to: method. I don't know whether we should fix this method, or maybe it is better to fix #copyFrom:to: to accept inverted ranges (a simple check if stop < start then swap the end points) yet it hard to reproduce, it works ok most of the times :( To reproduce the bug, try to do following: - open a new workspace window, type an arbitrary text there - then drag a window to the bottom of desktop, so only title bar of workspace remain visible - release drag - click on the title bar and start dragging it back to make text visible -- Best regards, Igor Stasenko AKA sig.

3 2