October 2010 - Pharo-dev - lists.pharo.org

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

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

by Schwab,Wilhelm K

FWIW, Dolphin has (or at least had in earlier versions - I can check later if it matters) an analog to #valueUnpreemptively. Something like that is likely to be more portable than new syntax or a new bytecode. Any VW experts care to comment on what might be available there? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Wednesday, October 13, 2010 1:00 PM To: The general-purpose Squeak developers list Cc: Pharo Development Subject: Re: [Pharo-project] [squeak-dev] Re: How about atomic value-swap bytecode? 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: 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. 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. > >

Oct. 13, 2010

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

by Levente Uzonyi

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: 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. 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. > >

Oct. 13, 2010

[Pharo-project] FreeType fonts scan annoyance on windows

by Igor Stasenko

If you're on Windows, a freetype searching fonts everywhere on all drive letters. This causes opening annoying 'Insert disk in drive X:' dialog. guessWindowsFontFolderPath "Guess the location of the Windows font folder" | possibles | possibles := Set new. 'cdefghijklmnopqrstuvwxyz' do:[:drive | #('\windows\fonts' '\winnt\fonts') do:[:path | | d | (d := FileDirectory on: drive asString, ':', path) exists ifTrue:[possibles add: d]]]. possibles := possibles asSortedCollection: [:a :b | a directoryEntry creationTime >= b directoryEntry creationTime]. possibles ifNotEmpty:[^possibles first pathName]. ^nil Here what i found occasionally, when read ReadFile() function documentation in MSDN: If you are attempting to read from a floppy drive that does not have a floppy disk, the system displays a message box that prompts the user to retry the operation. To prevent the system from displaying this message box, call the SetErrorMode function with SEM_NOOPENFILEERRORBOX. But it will require changing VM to call SetErrorMode() during startup to prevent these promts from appearing. -- Best regards, Igor Stasenko AKA sig.

Oct. 13, 2010