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

[Pharo-project] Example of non-concurrent code :)
by Igor Stasenko Oct. 16, 2010

Oct. 16, 2010

mouseTrailFrom: currentBuf "Current event, a mouse event buffer, is about to be processed. If there are other similar mouse events queued up, then drop them from the queue, and report the positions inbetween." | nextEvent trail | trail := (Array new: 1) writeStream. trail nextPut: currentBuf third @ currentBuf fourth. *a* [(nextEvent := Sensor peekEvent) isNil] whileFalse: [nextEvent first = currentBuf first ifFalse: [^trail contents "different event type"]. nextEvent fifth = currentBuf fifth ifFalse: [^trail contents "buttons changed"]. nextEvent sixth = currentBuf sixth ifFalse: [^trail contents "modifiers changed"]. "nextEvent is similar. Remove it from the queue, and check the next." *b* nextEvent := Sensor nextEvent. trail nextPut: nextEvent third @ nextEvent fourth]. ^trail contents Here, the bug: first it sends #peekEvent and its not nil. Okay, then after some logic voodo, it sends nextEvent, without precaution, that it may also answer nil! So, if some other process get between these two sends (*a*, *b*) and fetch/flush all events, a code will fail, because 'nextEvent third' is DNU , when nextEvent == nil. The fix is simple: nextEvent := Sensor nextEvent. nextEvent ifNotNil: [ trail nextPut: nextEvent third @ nextEvent fourth] Both Pharo & Squeak contain this bug. But this method slightly differs from each other. -- Best regards, Igor Stasenko AKA sig.

2 1

[Pharo-project] OOP best practices
by Fernando olivero Oct. 15, 2010

Oct. 15, 2010

Hi Hernan, just wanted to get your opinion on the following method, that attempts to adhere to your "complete objects" pattern. ( ESUG 2010 TALK). PerformedExperiment>>experiment: anExperiment start: aTime stop: aStopTime participant: aParticipant tasks: aCollectionOfTasks | experiment | experiment := self new. experiment experiment: anExperiment start: aTime stop: aStopTime participant: aParticipant tasks: aCollectionOfTasks. ^ experiment In your experience, how does the pattern cope with large keyword selectors. Maybe this case is not that evident, although we should try to avoid having more than 4 instance variables anyway, i would like to get your opinion on this problem (?). Thanks, Fernando

4 8

Re: [Pharo-project] Stack should be reimplemented with Array
by StÃ©phane Ducasse Oct. 15, 2010

Oct. 15, 2010

thanks levente! this is always nice to read such kind of post since they educate us and we need that :) I want to be taught a lot :) Stef On Oct 15, 2010, at 6:33 PM, Levente Uzonyi wrote: > On Thu, 14 Oct 2010, jaayer wrote: > >> There was a post on this list back in August complaining about Stack inheriting from LinkedList. There was some discussion, but apparently no resolution, as Stack still inherits from LinkedList in the Pharo 1.2 Core Image I just downloaded. Rather than reimplementing it to forward to a contained LinkedList, I think it should use an Array internally like OrderedCollection does. An Array-based implementation of Stack would be faster than one based on LinkedList due to the basic stack operations (push, pop and top) being able to rely more on primitives. This assumes that you know roughly how a big a stack you need; if you don't, reallocating the array and copying its contents over and over again will cost you, but this is an exceptional case;-- most stacks are small and when they aren't, the programmer usually has enough information to select a reasonable stack size. >> >> Enclosed is a fileout of an Array-based Stack implementation. It trounces the LinkedList-based implementation easily, but more interestingly, it performs better than an OrderedCollection when used like a stack: >> >> Pushing is roughly ~30% faster: >> r1 :=[100000 timesRepeat: [ >> s := Stack new. >> 10 timesRepeat: [s push: #foo]]] timeToRun. >> r2 := [100000 timesRepeat: [ >> oc := OrderedCollection new. >> 10 timesRepeat: [oc addLast: #foo]]] timeToRun. >> 100 - ((r1 / r2) asFloat * 100). >> >> as is pushing + popping: >> r3 := [100000 timesRepeat: [ >> s := Stack new. >> 10 timesRepeat: [s push: #foo]. >> 10 timesRepeat: [s pop]]] timeToRun. >> r4 := [100000 timesRepeat: [ >> oc := OrderedCollection new. >> 10 timesRepeat: [oc addLast: #foo]. >> 10 timesRepeat: [oc removeLast]]] timeToRun. >> 100 - ((r3 / r4) asFloat * 100). > > Please write more realistic benchmarks. Adding 10 elements to your Stack implementation won't make it's array grow. Also the benchmark measures a lot of other stuff besides the cost of push and pop. Something like this should do it: > > "The linked Stack implementation" > (1 to: 5) collect: [ :run | > | stack | > Smalltalk garbageCollect. > stack := Stack new. > { > [ 1 to: 1000000 do: [ :each | stack push: each ] ] timeToRun. > [ 1 to: 1000000 do: [ :each | stack pop ] ] timeToRun } ] > #(#(167 88) #(169 91) #(169 88) #(166 87) #(166 88)) > > "OrderedCollection" > (1 to: 5) collect: [ :run | > | stack | > Smalltalk garbageCollect. > stack := OrderedCollection new. > { > [ 1 to: 1000000 do: [ :each | stack addLast: each ] ] timeToRun. > [ 1 to: 1000000 do: [ :each | stack removeLast ] ] timeToRun } ] > #(#(87 98) #(87 100) #(87 98) #(88 97) #(87 99)) > > "The new stack implementation" > (1 to: 5) collect: [ :run | > | stack | > Smalltalk garbageCollect. > stack := Stack new. > { > [ 1 to: 1000000 do: [ :each | stack push: each ] ] timeToRun. > [ 1 to: 1000000 do: [ :each | stack pop ] ] timeToRun } ] > #(#(89 62) #(90 63) #(89 62) #(89 62) #(89 64)) > > All benchmarks were run in the latest Squeak 4.2 alpha using the latest CogVM. > > Conclusion: OrderedCollection >> #removeLast uses #emptyCheck which is slow. Other than that the difference between OrderedCollection and an array-based stack implementation is neglible in Squeak using CogVM. > > Replacing > self emptyCheck > with > lastIndex < firstIndex ifTrue: [ self errorEmptyCollection] > in OrderedCollection >> #removeLast and running the benchmark again gives the following results: > #(#(88 65) #(90 66) #(89 66) #(88 68) #(87 66)) > > > Also please send #postCopy to super if you implement #postCopy. > > > Levente > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Re: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license
by Schwab,Wilhelm K Oct. 15, 2010

Oct. 15, 2010

Didier, I would go along with "clearly" with the code in Smalltalk; I do not have enough experience with Java to pronounce it too slow to do the job. Nor can I claim to understand what is involved in a continental weather forecast. When it comes to transforming 500,000 sample time series, I have a little more sense of it. There the problem is not so much the cost of processing one of them, it's that I have many of them to analyze and summarize. It might be that you do not address the expensive things that I use. For things like non-linear regression with modest numbers of points, the speed penalty of even Smalltalk might indeed not be a deterrent. In terms of my GPL/GSL struggle, the code most likely to be put at risk by GPL is what is needed to do least squares, root finding, and regression; it is also (however indirectly) connected to the more poorly designed parts of GSL. The transforms are relatively clean, and would be almost directly accessible with only modest improvements to Pharo. The few vector operations that I have used from BLAS can be clean-roomed with little effort. This could work out nicely. I'm not sure I agree that communication with external libraries is "unstable." I have done a lot of it for a long time with good results. It is true that our current FFI is not as good as Dolphin's, but it does work as far as it goes. It can be readily modified to provide diagnostic information that is suppressed by default and that helps a lot in getting things to work. NativeBoost and/or Alien will hopefully address callbacks and get closer to Dolphin's handling of structure field types. Bill ________________________________________ From: Didier Besset [didier(a)ieee.org] Sent: Friday, October 15, 2010 11:09 AM To: Schwab,Wilhelm K Subject: Re: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license You just have to see what is good for you. Clearly, you won't compute the weather forecast each day for whole Europe in ST or Java. However, I found that making least-square fits within the time required to refresh a screen perfecttly acceptable compared to the unstability of cross language communication. Cheers, Didier On 14/10/2010 22:36, Schwab,Wilhelm K wrote: > That is wonderful news! > > Didier, There is a natural question that arises: what are the performance implications of Smalltalk or Java? Why not C with a Smalltalk wrapper? I have not tried number crunching with Cog or NativeBoost doing some of the expensive lifting, but absent those advantages, the benefit from coding tight loops in C has been nothing short of eerie. I have never tried Java for it. If there is a speed boost to be had, would a port offend you? I am a pragmatist, so it would begin one function at a time, chosen by the type of work I do and driven by when the machine grunts. > > Thanks, > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Thursday, October 14, 2010 4:02 PM > To: Pharo Development; The general-purpose Squeak developers list; ESUG Mailing list > Cc: Didier H. Besset > Subject: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license > > I want to thanks didier for releasing the code of his book under MIT. > Thanks! > > > Begin forwarded message: > >> From: Didier Besset<didier(a)ieee.org> >> Date: October 14, 2010 8:06:52 PM GMT+02:00 >> To: StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> >> Subject: Disclaimer >> >> I hereby release the code of my book "Object Oriented Implementation of Numerical Methods" under the MIT license. >> >> Didier Besset > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

1 0

[Pharo-project] Stack should be reimplemented with Array
by jaayer Oct. 15, 2010

Oct. 15, 2010

There was a post on this list back in August complaining about Stack inheriting from LinkedList. There was some discussion, but apparently no resolution, as Stack still inherits from LinkedList in the Pharo 1.2 Core Image I just downloaded. Rather than reimplementing it to forward to a contained LinkedList, I think it should use an Array internally like OrderedCollection does. An Array-based implementation of Stack would be faster than one based on LinkedList due to the basic stack operations (push, pop and top) being able to rely more on primitives. This assumes that you know roughly how a big a stack you need; if you don't, reallocating the array and copying its contents over and over again will cost you, but this is an exceptional case;-- most stacks are small and when they aren't, the programmer usually has enough information to select a reasonable stack size. Enclosed is a fileout of an Array-based Stack implementation. It trounces the LinkedList-based implementation easily, but more interestingly, it performs better than an OrderedCollection when used like a stack: Pushing is roughly ~30% faster: r1 :=[100000 timesRepeat: [ s := Stack new. 10 timesRepeat: [s push: #foo]]] timeToRun. r2 := [100000 timesRepeat: [ oc := OrderedCollection new. 10 timesRepeat: [oc addLast: #foo]]] timeToRun. 100 - ((r1 / r2) asFloat * 100). as is pushing + popping: r3 := [100000 timesRepeat: [ s := Stack new. 10 timesRepeat: [s push: #foo]. 10 timesRepeat: [s pop]]] timeToRun. r4 := [100000 timesRepeat: [ oc := OrderedCollection new. 10 timesRepeat: [oc addLast: #foo]. 10 timesRepeat: [oc removeLast]]] timeToRun. 100 - ((r3 / r4) asFloat * 100).

3 6

[Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license
by StÃ©phane Ducasse Oct. 15, 2010

Oct. 15, 2010

I want to thanks didier for releasing the code of his book under MIT. Thanks! Begin forwarded message: > From: Didier Besset <didier(a)ieee.org> > Date: October 14, 2010 8:06:52 PM GMT+02:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Disclaimer > > I hereby release the code of my book "Object Oriented Implementation of Numerical Methods" under the MIT license. > > Didier Besset

4 4

Re: [Pharo-project] Stack should be reimplemented with Array
by StÃ©phane Ducasse Oct. 15, 2010

Oct. 15, 2010

Thanks!!! Stef On Oct 14, 2010, at 8:32 PM, jaayer wrote: > The original contains an error; it send min: where it should max:. This one contains the correction.<Stack.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

3 2

[Pharo-project] FileChooser (Squeak) = ........ (Pharo)
by Hannes Hirzel Oct. 15, 2010

Oct. 15, 2010

Hello I am porting an application from Squeak to Pharo (actually the moose-seaside-glamour image) and I wonder what the equivalent class of FileChooser is? There are five 'Chooser' classes in Pharo 1.1 but no FileChooser. Thank you for the answer in advance Hannes

2 3

[Pharo-project] Call for contribution to http://pharo-project.org/about/research
by Alexandre Bergel Oct. 15, 2010

Oct. 15, 2010

Hi! I set up http://pharo-project.org/about/research Now, it needs content. I need bibitem. Please, send me only the item that you think are relevant to the page. It makes no sense to have hundreds of item directly listed here. Feel free to comment on it. I am open to suggestion. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

[Pharo-project] what happened with Shout colors in Pharo 1.1?
by Mariano Martinez Peck Oct. 15, 2010

Oct. 15, 2010

They've changed a lot from 1.0. For example, self, super, etc, are not in "orange" or that color of 1.0. Instances variables, are blue (instead of black), the same as parameters,etc... is there a way to recover the original colors? do we wanted this change or it is accidental ? cheers mariano

1 0

Re: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license
by StÃ©phane Ducasse Oct. 15, 2010

Oct. 15, 2010

On Oct 15, 2010, at 8:42 AM, Geert Claes wrote: > > Maybe a silly question, but it is the "code" of the book "Object Oriented > Implementation of Numerical Methods", so the book itself won't be available > for free? > I do not think so but if we can get the pdf it would be really good for my free Smalltalk books collection :) Stef > > StÃ©phane Ducasse wrote: >> >> I want to thanks didier for releasing the code of his book under MIT. >> Thanks! >> >> >> Didier Besset wrote: >>> >>> Begin forwarded message: >>>> From: Didier Besset <didier(a)ieee.org> >>>> Date: October 14, 2010 8:06:52 PM GMT+02:00 >>>> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>> Subject: Disclaimer >>>> >>>> I hereby release the code of my book "Object Oriented Implementation of >>>> Numerical Methods" under the > > MIT license. >>>> >>>> Didier Besset >>> >> > -- > View this message in context: http://forum.world.st/Object-Oriented-Implementation-of-Numerical-Methods-u… > 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

2 2

[Pharo-project] Xtreams vs become:
by mkobetic＠gmail.com Oct. 15, 2010

Oct. 15, 2010

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 ?

2 3

[Pharo-project] Problem installing Magritte2
by Casimiro de Almeida Barreto Oct. 15, 2010

Oct. 15, 2010

The following: (Installer squeaksource project: 'MetacelloRepository'; packagesMatching: 'ConfigurationOfMagritte2-*') first install. ConfigurationOfMagritte2 project latestVersion load. Results in: Error: could not resolv Magritte-Model [Magritte-Model-lr.397] Then, the site: source.lukas-renggli.ch returns: Service Temporarily Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. ------------------------------------------------------------------------ Apache/2.2.14 (Ubuntu) Server at source.lukas-renggli.ch Port 80

3 2

Re: [Pharo-project] PharoKernel related issues
by StÃ©phane Ducasse Oct. 14, 2010

Oct. 14, 2010

Thanks pavel!! I'm quite busy just right now but we will have a look. Stef On Oct 14, 2010, at 1:30 PM, Pavel Krivanek wrote: > Hi, > > if you want to have modular Pharo, you should pay attention to this > issues. Please look at them and write your oppinions on best solutions > of this PharoKernel related issues. > > Issue 3103: better Morphic detection in AutoStart startUp: > http://code.google.com/p/pharo/issues/detail?id=3103 > > Issue 3104: ChangeSet class >> #fileIntoNewChangeSet: dependent on Compression > http://code.google.com/p/pharo/issues/detail?id=3104 > > Issue 3105: DeepCopier warnIverNotCopiedIn:sel: dependent on ToolSet > http://code.google.com/p/pharo/issues/detail?id=3105 > > Issue 3106: EToys resources relict in Form >> unhibernate > http://code.google.com/p/pharo/issues/detail?id=3106 > > Issue 3107: UserInterruptHandler >> handleEvent: is dependent on SoundService > http://code.google.com/p/pharo/issues/detail?id=3107 > > Issue 3108: Project >> updateLocaleDependents dependent on MenuIcons > http://code.google.com/p/pharo/issues/detail?id=3108 > > Issue 3109: TextURL >> #actOnClickFor: dependent on network > http://code.google.com/p/pharo/issues/detail?id=3109 > > Issue 3110: ProjectLauncher readDocumentAtStartup needs a setting > http://code.google.com/p/pharo/issues/detail?id=3110 > > Issue 3111: AutoStart class >> #checkForUpdates is Morphic dependent > http://code.google.com/p/pharo/issues/detail?id=3111 > > Issue 3112: ThreadSafeTranscript >> #endEntry is Morphic dependent > http://code.google.com/p/pharo/issues/detail?id=3112 > > Cheers, > -- Pavel > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Re: [Pharo-project] modal windows and unit tests
by StÃ©phane Ducasse Oct. 14, 2010

Oct. 14, 2010

yes this means that there is a infrastructural decision to make sure that UI can be controlled. >>> There are also some basic things that would need some adjustment as I >>> see it. I think core or basic classes and models shouldn't make any >>> assumptions about the UI or even if there is an UI at all. >> >> YESSSssssssss.... and a minicore will help /force us to do that (imagine an hudson script blocked because of a nice popup) > > Consider that this is not the UI framework that should decide to open > a dialog or not. If somebody tells morphic to open a window it should > open it otherwise you break all kinds of assumptions. > > If a user wants to support multiple UI frameworks (or the possibility > to disable certain UI actions), then he needs to take appropriate > action himself. OB for example uses notifications for all UI > interactions that are captured either by a morphic handler (by > default), a web handler (if you use the web interface), or by a test > handler (that builds a fake UI that doesn't display anything but gives > you a nice model to exercise the UI). > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] Why atomic stuff rules :)
by Igor Stasenko Oct. 14, 2010

Oct. 14, 2010

In the attachment an implementation of SharedQueue3, which using atomic operation. Of course , currently it is based on assumption that some stuff (like two assignments in a row) can't be interrupted. The FIFO implementation using ASWP and CAS: push: - no spins, 1 ASWP pop: - 2 spins, 1 ASWP , 1 CAS Here a simple bench i made, which pushing 100000 elements into queue using 10 different processes, and then looks how many are popped via 3 feeder processes during that time: Squeak VM. SharedQueue : SharedQueue3Test new benchManyPushersAndFeeders: SharedQueue 'Added 100000 items, processed 30000 queue items during 1928 milliseconds' SharedQueue2 : SharedQueue3Test new benchManyPushersAndFeeders: SharedQueue2 'Added 100000 items, processed 30034 queue items during 1074 milliseconds' SharedQueue3 (mine) : SharedQueue3Test new benchManyPushersAndFeeders: SharedQueue3 'Added 100000 items, processed 70229 queue items during 118 milliseconds' Cog: SharedQueue3Test new benchManyPushersAndFeeders: SharedQueue 'Added 100000 items, processed 29999 queue items during 1955 milliseconds' SharedQueue3Test new benchManyPushersAndFeeders: SharedQueue2 'Added 100000 items, processed 29997 queue items during 197 milliseconds' SharedQueue3Test new benchManyPushersAndFeeders: SharedQueue3 'Added 100000 items, processed 100000 queue items during 26 milliseconds' if anyone has better ideas how to bench throughput, send me the code. -- Best regards, Igor Stasenko AKA sig.

1 0

Re: [Pharo-project] Bug when changing superclass in latest OB?
by Simon Denier Oct. 14, 2010

Oct. 14, 2010

On 14 oct. 2010, at 19:37, Lukas Renggli wrote: > Hi Simon, > > It works for me too, the change can even be undone and redone. Also > this should be tested as part of the unit tests. > > Maybe try to load the code again and recompile all packages: > > Gofer new > squeaksource: 'rb'; > package: 'AST-Core'; > package: 'Refactoring-Core'; > package: 'Refactoring-Changes'; > package: 'Refactoring-Critics'; > package: 'Refactoring-Environment'; > load; > recompile. > > Gofer new > renggli: 'omnibrowser'; > package: 'OmniBrowser'; > package: 'OB-Standard'; > package: 'OB-Morphic'; > package: 'OB-Refactory'; > load; > recompile Indeed it works as expected when I reload+recompile. Thanks Lukas. > > > On 14 October 2010 19:23, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >> hi Simon, >> >> I cannot reproduce. It works as expected for me. >> >> Alexandre >> >> >> On 14 Oct 2010, at 12:43, Simon Denier wrote: >> >>> Hi >>> >>> Downloading the latest OB today with: >>> >>> Gofer new >>> squeaksource: 'rb'; >>> package: 'AST-Core'; >>> package: 'Refactoring-Core'; >>> package: 'Refactoring-Changes'; >>> package: 'Refactoring-Critics'; >>> package: 'Refactoring-Environment'; >>> load. >>> >>> Gofer new >>> renggli: 'omnibrowser'; >>> package: 'OmniBrowser'; >>> package: 'OB-Standard'; >>> package: 'OB-Morphic'; >>> package: 'OB-Refactory'; >>> load. >>> >>> >>> Then I change the superclass of the template of an existing class, then accept: >>> >>> Object subclass: #FileContentsBrowser >>> instanceVariableNames: 'packages infoString' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'Tools-File Contents Browser' >>> >>> >>> The superclass is not changed, instead OB changes its focus to the superclass. >>> >>> Can anyone confirm this bug? >>> >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon

1 0

[Pharo-project] Bug when changing superclass in latest OB?
by Simon Denier Oct. 14, 2010

Oct. 14, 2010

Hi Downloading the latest OB today with: Gofer new squeaksource: 'rb'; package: 'AST-Core'; package: 'Refactoring-Core'; package: 'Refactoring-Changes'; package: 'Refactoring-Critics'; package: 'Refactoring-Environment'; load. Gofer new renggli: 'omnibrowser'; package: 'OmniBrowser'; package: 'OB-Standard'; package: 'OB-Morphic'; package: 'OB-Refactory'; load. Then I change the superclass of the template of an existing class, then accept: Object subclass: #FileContentsBrowser instanceVariableNames: 'packages infoString' classVariableNames: '' poolDictionaries: '' category: 'Tools-File Contents Browser' The superclass is not changed, instead OB changes its focus to the superclass. Can anyone confirm this bug? -- Simon

3 2

[Pharo-project] Issue 3101: Wrong Monticello packages initialization order
by Pavel Krivanek Oct. 14, 2010

Oct. 14, 2010

see http://code.google.com/p/pharo/issues/detail?id=3101 Cheers, -- Pavel

2 2

Re: [Pharo-project] [squeak-dev] Re: How about atomic value-swap bytecode?
by Ralph Boland Oct. 14, 2010

Oct. 14, 2010

>> ... > 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 What does: a :=: b :=: c. mean? Perhaps anybody who does this should be shot but it must be well defined in the language (or at least defined as a syntax error) and of course the compiler must know what to do. How about it meaning: | tmp "hidden" | tmp := a. a := b. b := c. c := tmp. ? And if supported in the VM it should of course be atomic. Ralph Boland P.S. What does a := b :=: c. mean?

2 1

[Pharo-project] PharoKernel related issues
by Pavel Krivanek Oct. 14, 2010

Oct. 14, 2010

Hi, if you want to have modular Pharo, you should pay attention to this issues. Please look at them and write your oppinions on best solutions of this PharoKernel related issues. Issue 3103: better Morphic detection in AutoStart startUp: http://code.google.com/p/pharo/issues/detail?id=3103 Issue 3104: ChangeSet class >> #fileIntoNewChangeSet: dependent on Compression http://code.google.com/p/pharo/issues/detail?id=3104 Issue 3105: DeepCopier warnIverNotCopiedIn:sel: dependent on ToolSet http://code.google.com/p/pharo/issues/detail?id=3105 Issue 3106: EToys resources relict in Form >> unhibernate http://code.google.com/p/pharo/issues/detail?id=3106 Issue 3107: UserInterruptHandler >> handleEvent: is dependent on SoundService http://code.google.com/p/pharo/issues/detail?id=3107 Issue 3108: Project >> updateLocaleDependents dependent on MenuIcons http://code.google.com/p/pharo/issues/detail?id=3108 Issue 3109: TextURL >> #actOnClickFor: dependent on network http://code.google.com/p/pharo/issues/detail?id=3109 Issue 3110: ProjectLauncher readDocumentAtStartup needs a setting http://code.google.com/p/pharo/issues/detail?id=3110 Issue 3111: AutoStart class >> #checkForUpdates is Morphic dependent http://code.google.com/p/pharo/issues/detail?id=3111 Issue 3112: ThreadSafeTranscript >> #endEntry is Morphic dependent http://code.google.com/p/pharo/issues/detail?id=3112 Cheers, -- Pavel

1 0

[Pharo-project] Issue 3102: removeAllButPackages:
by Pavel Krivanek Oct. 14, 2010

Oct. 14, 2010

I started to add some PharoKernel related issues. See http://code.google.com/p/pharo/issues/detail?id=3102 -- Pavel

1 0

[Pharo-project] Xtreams tests green
by Nicolas Cellier Oct. 14, 2010

Oct. 14, 2010

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

2 1

[Pharo-project] Autotest / TDD + screencast
by laurent laffont Oct. 14, 2010

Oct. 14, 2010

Hi, Here's a first usable version of Autotest (automatic test runner, inspired by Ruby's ZentTest autotest). The goal is to have instant feedback on the code you The screencast to see it in action: http://lolgzs.free.fr/pharo/autotest_1.mpeg To load it: Gofer new squeaksource: 'Autotest'; package: 'Autotest'; load Comments are welcome as I have to rewrite it better :) Repository is read / write for those who wants to contribute. Cheers, Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/

3 3

[Pharo-project] [ANN] Pharo 1.1.1 OneClickCogVm
by Mariano Martinez Peck Oct. 13, 2010

Oct. 13, 2010

Hi. This is not an official release. I didn't do all the formal procedure for releasing a Pharo image. My idea is try to push CogVM and try to get as much as testers as possible. Try to report issues and help Eliot. For that purpose, I think having a one click image is worth it. So.....I build a Pharo dev on top of the PharoCore 1.1.1 (which has some fixes over 1.1 and the CogVM necessary changes). I build the image with exactly the same versions of the external packages than Pharo 1.1. If you want to download that this Pharo1.1.1 dev image that works with Cog here is the link: https://gforge.inria.fr/frs/download.php/27516/Pharo-1.1.1-dev10.09.1.zip In addition, and thanks to Lukas, we could generate OneClicks with CogVM. Here you can have a OneClick using the above image: https://gforge.inria.fr/frs/download.php/27524/Pharo-1.1.1-OneClickCogVM.zip Notice that this is not an official release and that there are failing/errors tests. I've already sent emails for them and hopefully someone may fix them. The only thing is not supported is the TestCoverage (since it uses objects as methods, with is not yet supported in CogVM). Cheers Mariano

9 21