- Pharo-dev - lists.pharo.org

[Pharo-project] BUG report

by HwaJong Oh

I have experienced Autotest-LaurentLaffont.62.mcz does not display any test results, while Autotest-jl.61.mcz does. -- View this message in context: http://forum.world.st/Autotest-TDD-screencast-tp2243786p2994899.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 14, 2010

Re: [Pharo-project] Issue 3090: Context not included in ImageSegment when saving morph to file

by Sheridan Mahoney

Oct. 14, 2010

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.1.1 OneClickCogVm

by GermÃ¡n Arduino

Forgot this mail, now found the other thread talking about this.....Sorry. 2010/10/13 GermÃ¡n Arduino <garduino(a)gmail.com>: > This is what is happening here with Ubuntu 10.04, but I've libuuid1 installed. > > What I should do to use Cog ? > > Thanks. > > > 2010/9/30 Levente Uzonyi <leves(a)elte.hu>: >> On Thu, 30 Sep 2010, laurent laffont wrote: >> >>> On up to date ArchLinux, 32 bits. >>> >>> 1. Open One Click >>> 2. Open MonticelloBrowser >>> 3. Save a packages (Tests for ex.) in package cache >>> 4. Dialog to enter commit message opens, click ok >>> 5. crash >>> >>> It reminds me about the UUID plugin as external problem. It should be >>> built >>> as internal. >> >> No, it shouldn't. It immediately crashes, if libuuid is not available, which >> happens to be the case on some 64-bit version of Debian and Ubuntu. >> >> >> Levente >> > -- ================================================= GermÃ¡n S. ArduinoÂ <gsa @ arsol.net>Â Â Twitter: garduino Arduino Software & Web HostingÂ Â http://www.arduinosoftware.com PasswordsProÂ http://www.passwordspro.com =================================================

Oct. 13, 2010

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.1.1 OneClickCogVm

by GermÃ¡n Arduino

This is what is happening here with Ubuntu 10.04, but I've libuuid1 installed. What I should do to use Cog ? Thanks. 2010/9/30 Levente Uzonyi <leves(a)elte.hu>: > On Thu, 30 Sep 2010, laurent laffont wrote: > >> On up to date ArchLinux, 32 bits. >> >> 1. Open One Click >> 2. Open MonticelloBrowser >> 3. Save a packages (Tests for ex.) in package cache >> 4. Dialog to enter commit message opens, click ok >> 5. crash >> >> It reminds me about the UUID plugin as external problem. It should be >> built >> as internal. > > No, it shouldn't. It immediately crashes, if libuuid is not available, which > happens to be the case on some 64-bit version of Debian and Ubuntu. > > > Levente >

Oct. 13, 2010

Re: [Pharo-project] Xtreams vs become:

by Nicolas Cellier

2010/10/13 <mkobetic(a)gmail.com>: > Michael and I talked about this today a bit and here's what we're thinking about doing. > We're inheriting the become: behavior from the collection growing APIs in VW and it doesn't make sense to work around that there. Consequently the only (relevant) become: that we do in Xtreams code is the one in CollectionWriteStream>>close. If we're not eliminating the become: from growing then ripping it out of closing creates a strange inconsistency. > > At the same time nothing is preventing the Squeak port to do away with the become:s altogether. After all the terminals are meant to be dialect specific and so the two ports will just be different in this regard. It's probably worth highlighting in the comments/docs that assuming the "become:" semantics of growing makes one's code non-portable. This way one can both get the the traditional behavior in VW, but at the same time Squeak doesn't have to suffer unnecessarily. > > To remove the "become" assumption in the test suite, I'll rewrite all the ReadWriteTests splitting them up into writing and reading part, which will allow creating the input after writing into the output is already done. That way we don't care if the collection streams use become or not. Something like: > > testBlah > > Â Â Â Â self write: [ :output | .... ] > Â Â Â Â Â Â Â Â read: [ :input | ... ] > > Good enough ? > Seems fair to me. Nicolas > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 13, 2010

[Pharo-project] Xtreams vs become:

by mkobetic＠gmail.com

Michael and I talked about this today a bit and here's what we're thinking about doing. We're inheriting the become: behavior from the collection growing APIs in VW and it doesn't make sense to work around that there. Consequently the only (relevant) become: that we do in Xtreams code is the one in CollectionWriteStream>>close. If we're not eliminating the become: from growing then ripping it out of closing creates a strange inconsistency. At the same time nothing is preventing the Squeak port to do away with the become:s altogether. After all the terminals are meant to be dialect specific and so the two ports will just be different in this regard. It's probably worth highlighting in the comments/docs that assuming the "become:" semantics of growing makes one's code non-portable. This way one can both get the the traditional behavior in VW, but at the same time Squeak doesn't have to suffer unnecessarily. To remove the "become" assumption in the test suite, I'll rewrite all the ReadWriteTests splitting them up into writing and reading part, which will allow creating the input after writing into the output is already done. That way we don't care if the collection streams use become or not. Something like: testBlah self write: [ :output | .... ] read: [ :input | ... ] Good enough ?

Oct. 13, 2010

[Pharo-project] Xtreams tests green

by Nicolas Cellier

So I updated Squeak Xtreams to synchronize with Martin's latest changes in public store... Tests are now green, and there is no lingering process :) If you update, you might have to reinitialize XTEncoder and its subclasses (may be force Encoders := nil manually) - I don't trust MC too much with this regard... The manual step might be necessary because I switched to Symbol rather than String for specifyinh an encoding. I did not deviate from VW version, apart: - changing the #timeout:server:client: comment - changing FileWriteStream comment: isPositionable <Boolean> false when the file is open in append mode todo: SocketRead/WriteStream would be nice, streaming on directory contents too - I did not do it, because a simple test like #isDirectory is all but obvious using FileDirectory :( The InterpretedStream (for reading writing binary data) shouldn't be that hard. I'm making a pause tonight. Nicolas

Oct. 13, 2010

Re: [Pharo-project] [squeak-dev] Re: How about atomic value-swap bytecode?

by Igor Stasenko

2010/10/13 Levente Uzonyi <leves(a)elte.hu>: > On Tue, 12 Oct 2010, Igor Stasenko wrote: > >> On 12 October 2010 16:51, Levente Uzonyi <leves(a)elte.hu> wrote: >>> >>> On Tue, 12 Oct 2010, Igor Stasenko wrote: >>> >>>> Hello, i just thought, that it would be cool to have a special bytecode, >>>> which guarantees atomicity for swapping values between two variables. >>>> >>>> To swap two values, you usually do: >>>> >>>> | var1 var2 temp | >>>> >>>> temp := var1. >>>> var1 := var2. >>>> var2 := temp. >>>> >>>> But since its non-atomic, a process can be interrupted and such >>>> operation >>>> is not thread-safe. >>>> >>>> In order to make it thread safe, you must add even more boilerplate: >>>> >>>> | var1 var2 temp | >>>> >>>> semaphore critical: [ >>>> Â temp := var1. >>>> Â var1 := var2. >>>> Â var2 := temp. >>>> ] >>> >>> An alternative solution: >>> >>> | a b | >>> a := 1. >>> b := 2. >>> [ >>> Â Â Â Â | tmp | >>> Â Â Â Â tmp := a. >>> Â Â Â Â a := b. >>> Â Â Â Â b := tmp ] valueUnpreemptively >>> >> >> Yeah, another boilerplate under the hood, also highly dependent from >> scheduling nuances :) > > I don't get the "dependency from scheduling nuances part", but here's my > idea: i don't like the code, which assuming that scheduling works in some specific way, or some code can't be interrupted in the middle. See Semaphore>>critical: for excersise. | caught | caught := false. ^[ caught := true. self wait. mutuallyExcludedBlock value ] ensure: [ caught ifTrue: [self signal] ] this code assuming that between caught := true. and self wait. no interrupt possible. But if it is, then the above implementation is incorrect. > > Add the compiler changes to support :=: as atomic swap. We don't really need > a bytecode for now, since a sequence of assignments is currently atomic. So > the compiler could compile :=: as three assignments using a hidden temporary > variable. On other systems, :=: can be compiled differently. > For same reason, there is no any guarantees from VM side that three assignments in a row will be atomic: storing pointer could trigger a root check, and if roots table is full, it could trigger GC, and after GC, there is a finalization semaphore, which could switch an active process immediately. VM is evolving and subject to change. Having a clear rule which guarantees a specific behavior is far more beneficial comparing to intimate knowledge about how VM works (now). > > Levente > >> >> valueUnpreemptively >> Â Â Â Â "Evaluate the receiver (block), without the possibility of >> preemption >> by higher priority processes. Use this facility VERY sparingly!" >> Â Â Â Â "Think about using Block>>valueUninterruptably first, and think >> about >> using Semaphore>>critical: before that, and think about redesigning >> your application even before that! >> Â Â Â Â After you've done all that thinking, go right ahead and use it..." >> Â Â Â Â | activeProcess oldPriority result | >> Â Â Â Â activeProcess := Processor activeProcess. >> Â Â Â Â oldPriority := activeProcess priority. >> Â Â Â Â activeProcess priority: Processor highestPriority. >> Â Â Â Â result := self ensure: [activeProcess priority: oldPriority]. >> Â Â Â Â "Yield after restoring priority to give the preempted processes a >> chance to run" >> Â Â Â Â Processor yield. >> Â Â Â Â ^result >>> >>> Levente >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- Best regards, Igor Stasenko AKA sig.

Oct. 13, 2010

[Pharo-project] Iliad 0.9.1 released

by Nicolas Petton

Hi, We are happy to announce the release of Iliad 0.9.1 for GNU Smalltalk, Pharo and Squeak. This is a bug fix release. Download & installation instructions can be found at http://www.iliadproject.org/pages/Download. The website also received some love and is now wearing a new design. Happy Iliad hacking, Nicolas Petton & SÃ©bastien Audier

Oct. 13, 2010

Re: [Pharo-project] [squeak-dev] OCompletion usability

by Chris Muller

+1. cmd+j is essential. As are the other unconventional editor features;; cmd+h, g, and e... On Sun, Oct 10, 2010 at 7:06 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hi all, > Thanks to Levente, I activated OCompletion in trunk. > It's nice when typing a text from scratch (like in a workspace). > But when modifying an existing text, not that great. > > The feature I most miss is the ability to overwrite a word fragment > and hit cmd+j to repeat the replacement. > Would it be possible to restore this behavior ? > > Nicolas > >

Oct. 13, 2010