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

Re: [Pharo-project] OOP best practices

by Fernando olivero

So a "smart template" created by the debugger would just do the following, when defining the following Class method: performedExperiment := PerformedExperiment for: anExperiment startedAt: aStartTime stopedAt: aStopTime madeBy: aParticipant "Not sure what participant is, so maybe madeBy is not a good name" with: aCollectionOfTasks. DNU => HIT CREATE BUTTON => Automatically create the following methods 1) PerformedExperiment class >> for: anExperiment startedAt: aStartTime stopedAt: aStopTime madeBy: aParticipant with: aCollectionOfTasks. | instance | instance := self new. instance initializeFor: anExperiment startedAt: aStartTime stopedAt: aStopTime madeBy: aParticipant with: aCollectionOfTasks. ^ instance 2) PerformedExperiment>> initializeFor: anExperiment startedAt: aStartTime stopedAt: aStopTime madeBy: aParticipant with: aCollectionOfTasks. self shouldBeImplemented On Oct 14, 2010, at 10:35 PM, Hernan Wilkinson wrote: > Hi Fernando, > I think that you are saying that having too many parameter could be a problem for understanding the message, is that right? > I mean, having too many inst var as you say, it is a smell of bad design, and having too many parameters also, so I guess we agree on that. > About reading the code, from the sender point of view, if you don't have an instance creation message that creates a "complete" object, then you would do something like this: > > performedExperiment := PerformedExperiment new > experimient: anExperiment; > start: aStartTime ; > stop: aStopTime ; > participant: aParticipant; > tasks: aCollectionOfTasks; > yourself. > > With an inst. creation message that returns a complete object, you would use it like this: > > performedExperiment := PerformedExperiment > experimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks. > > So, it is basically the same but with less messages and less error prone (in the former you can forget to send a message, ie. stop: and nobody will complain immediately, but in the last one you wont make that mistake, or if you doit you will get a dnu immediately). > > About the implementation of the inst. creation message, it is true that it could bother a little the reading, but when there are so many parameters I format the code this way: > > PerformedExperiment class>>experimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks > > ^self new initializeExperimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks > > that makes it more readable. > Also look that there is an initializeXxx message to distinguish it from the inst. creation message. This helps when analyzing code automatically (ie. initialize messages should only be sent from the class side) or generating code automatically on the debugger with the create button (as the enhancement 3099 that I sent the other day, the debugger could be smart enough to realize it is an initialization message so it could provide a better template than just a "self shouldBeImplemented"). > I the meantime, I would suggest another name for the message you are using as example, something easier to read like: > > performedExperiment := PerformedExperiment > for: anExperiment > startedAt: aStartTime > stopedAt: aStopTime > madeBy: aParticipant "Not sure what participant is, so maybe madeBy is not a good name" > with: aCollectionOfTasks. > > I think it reads better. With the former you have duplicated "names" like "experimient: anExperiment", "start: anStartTime", etc., with the last one you don't have that problem. > > Hope it helps, let me know what you think! > > Hernan. > > > On Thu, Oct 14, 2010 at 4:48 PM, Fernando olivero <fernando.olivero(a)usi.ch> wrote: > 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 > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com > > <ATT00001..txt>

Oct. 14, 2010

Re: [Pharo-project] OOP best practices

by Fernando olivero

THANKS Hernan! With the example i've got to understand the correct usage of the pattern now. Which of course i will follow from now on, given the benefits from having complete objects! ( no messy ifNil checks for starters!, etc...) On Oct 14, 2010, at 10:35 PM, Hernan Wilkinson wrote: > Hi Fernando, > I think that you are saying that having too many parameter could be a problem for understanding the message, is that right? > I mean, having too many inst var as you say, it is a smell of bad design, and having too many parameters also, so I guess we agree on that. > About reading the code, from the sender point of view, if you don't have an instance creation message that creates a "complete" object, then you would do something like this: > > performedExperiment := PerformedExperiment new > experimient: anExperiment; > start: aStartTime ; > stop: aStopTime ; > participant: aParticipant; > tasks: aCollectionOfTasks; > yourself. > > With an inst. creation message that returns a complete object, you would use it like this: > > performedExperiment := PerformedExperiment > experimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks. > > So, it is basically the same but with less messages and less error prone (in the former you can forget to send a message, ie. stop: and nobody will complain immediately, but in the last one you wont make that mistake, or if you doit you will get a dnu immediately). > > About the implementation of the inst. creation message, it is true that it could bother a little the reading, but when there are so many parameters I format the code this way: > > PerformedExperiment class>>experimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks > > ^self new initializeExperimient: anExperiment > start: aStartTime > stop: aStopTime > participant: aParticipant > tasks: aCollectionOfTasks > > that makes it more readable. > Also look that there is an initializeXxx message to distinguish it from the inst. creation message. This helps when analyzing code automatically (ie. initialize messages should only be sent from the class side) or generating code automatically on the debugger with the create button (as the enhancement 3099 that I sent the other day, the debugger could be smart enough to realize it is an initialization message so it could provide a better template than just a "self shouldBeImplemented"). > I the meantime, I would suggest another name for the message you are using as example, something easier to read like: > > performedExperiment := PerformedExperiment > for: anExperiment > startedAt: aStartTime > stopedAt: aStopTime > madeBy: aParticipant "Not sure what participant is, so maybe madeBy is not a good name" > with: aCollectionOfTasks. > > I think it reads better. With the former you have duplicated "names" like "experimient: anExperiment", "start: anStartTime", etc., with the last one you don't have that problem. > > Hope it helps, let me know what you think! > > Hernan. > > > On Thu, Oct 14, 2010 at 4:48 PM, Fernando olivero <fernando.olivero(a)usi.ch> wrote: > 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 > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com > > <ATT00001..txt>

Oct. 14, 2010

Re: [Pharo-project] OOP best practices

by Alexandre Bergel

> PerformedExperiment>>experiment: anExperiment start: aTime stop: aStopTime participant: aParticipant tasks: aCollectionOfTasks I guess you meant PerformedExperiment class >>experiment: ... Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 14, 2010

Re: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license

by Schwab,Wilhelm K

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

Oct. 14, 2010

Re: [Pharo-project] OOP best practices

by Hernan Wilkinson

Hi Fernando, I think that you are saying that having too many parameter could be a problem for understanding the message, is that right? I mean, having too many inst var as you say, it is a smell of bad design, and having too many parameters also, so I guess we agree on that. About reading the code, from the sender point of view, if you don't have an instance creation message that creates a "complete" object, then you would do something like this: performedExperiment := PerformedExperiment new experimient: anExperiment; start: aStartTime ; stop: aStopTime ; participant: aParticipant; tasks: aCollectionOfTasks; yourself. With an inst. creation message that returns a complete object, you would use it like this: performedExperiment := PerformedExperiment experimient: anExperiment start: aStartTime stop: aStopTime participant: aParticipant tasks: aCollectionOfTasks. So, it is basically the same but with less messages and less error prone (in the former you can forget to send a message, ie. stop: and nobody will complain immediately, but in the last one you wont make that mistake, or if you doit you will get a dnu immediately). About the implementation of the inst. creation message, it is true that it could bother a little the reading, but when there are so many parameters I format the code this way: PerformedExperiment class>>experimient: anExperiment start: aStartTime stop: aStopTime participant: aParticipant tasks: aCollectionOfTasks ^self new initializeExperimient: anExperiment start: aStartTime stop: aStopTime participant: aParticipant tasks: aCollectionOfTasks that makes it more readable. Also look that there is an initializeXxx message to distinguish it from the inst. creation message. This helps when analyzing code automatically (ie. initialize messages should only be sent from the class side) or generating code automatically on the debugger with the create button (as the enhancement 3099 that I sent the other day, the debugger could be smart enough to realize it is an initialization message so it could provide a better template than just a "self shouldBeImplemented"). I the meantime, I would suggest another name for the message you are using as example, something easier to read like: performedExperiment := PerformedExperiment for: anExperiment startedAt: aStartTime stopedAt: aStopTime madeBy: aParticipant "Not sure what participant is, so maybe madeBy is not a good name" with: aCollectionOfTasks. I think it reads better. With the former you have duplicated "names" like "experimient: anExperiment", "start: anStartTime", etc., with the last one you don't have that problem. Hope it helps, let me know what you think! Hernan. On Thu, Oct 14, 2010 at 4:48 PM, Fernando olivero <fernando.olivero(a)usi.ch>wrote: > 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 > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

Oct. 14, 2010

Re: [Pharo-project] Stack should be reimplemented with Array

by StÃ©phane Ducasse

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

Oct. 14, 2010

Re: [Pharo-project] PharoKernel related issues

by StÃ©phane Ducasse

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

Oct. 14, 2010

Re: [Pharo-project] modal windows and unit tests

by StÃ©phane Ducasse

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

Oct. 14, 2010

[Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license

by StÃ©phane Ducasse

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

Oct. 14, 2010

Re: [Pharo-project] Stack should be reimplemented with Array

by jaayer

---- On Thu, 14 Oct 2010 10:51:31 -0700 Eliot Miranda wrote ---- >*No*. Â Stack and OrderedCollection differ *usefully*. Â Adding an item to a Stack is always O(1). Â Adding an item to an OrderedCollection is O(N) because when the array overflows a new one must be allocated and the old objects copied to the new. Â Why not apply your speedups to OrderedCollection, or is that not possible? Â If not possible, then come up with a new name and add that. Â Please /don't/ change Stack. Yes, that point was made in the prior discussion regarding Stack and its superclass in defense of having such a class at all when OrderedCollection is already there. Further, you are correct that I am suggesting we trade guaranteed O(1) complexity when pushing/popping for worst-case O(n) complexity. However, asymptotic analysis does not the whole story tell, as it ignores the underlying constants, and in the real world, when n is small enough, the constants *do* matter. As it turns out, "small enough" in this case means a Stack created with the default initial capacity of 10 grown incrementally into one big enough to hold 500,000-1,000,000 elements. I ran the following benchmark with both versions, and the array-based Stack was ~60% faster when grown big enough to contain 100,000 elements, slightly faster for 500,000 elements, and two to three times slower for a million elements: s := nil. Smalltalk garbageCollect. [s := Stack new. 100000 timesRepeat: [s push: #foo]] timeToRun. s := nil. Smalltalk garbageCollect. [s := Stack new. 500000 timesRepeat: [s push: #foo]] timeToRun. s := nil. Smalltalk garbageCollect. [s := Stack new. 1000000 timesRepeat: [s push: #foo]] timeToRun. That means that even if you unknowingly create an enormous Stack without specifying the right size, you still come out ahead for at least the first 500,000 elements. Of course, the Array-based stack never deallocates any of its memory, which means a worst case of 2 * n memory complexity (where n is the largest number of elements a given Stack ever held). But as I said in my initial post, most Stacks are small, and when they aren't, you often have enough information to choose an appropriate size. If you really need constant time and memory complexity, which I argue is the exception, why not just use LinkedList directly with #addLast: and #removeLast to simulate a Stack as people did and still do with OrderedCollection? The rueful requirement that LinkList elements inherit from Link is gone. Stack, if it is to exist at all, should support *fast* push and pop operations. The current implementation does not. This one does, and should replace it.

Oct. 14, 2010

[Pharo-project] Why atomic stuff rules :)

by Igor Stasenko

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.

Oct. 14, 2010

[Pharo-project] OOP best practices

by Fernando olivero

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

Oct. 14, 2010

Re: [Pharo-project] Stack should be reimplemented with Array

by jaayer

The original contains an error; it send min: where it should max:. This one contains the correction.

Oct. 14, 2010

Re: [Pharo-project] Stack should be reimplemented with Array

by Eliot Miranda

2010/10/14 jaayer <jaayer(a)zoho.com> > 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. > *No*. Stack and OrderedCollection differ *usefully*. Adding an item to a Stack is always O(1). Adding an item to an OrderedCollection is O(N) because when the array overflows a new one must be allocated and the old objects copied to the new. Why not apply your speedups to OrderedCollection, or is that not possible? If not possible, then come up with a new name and add that. Please /don't/ change Stack. > > 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). > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 14, 2010

Re: [Pharo-project] Bug when changing superclass in latest OB?

by Simon Denier

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

Oct. 14, 2010

[Pharo-project] Stack should be reimplemented with Array

by jaayer

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

Oct. 14, 2010

Re: [Pharo-project] Bug when changing superclass in latest OB?

by Lukas Renggli

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

Oct. 14, 2010

Re: [Pharo-project] Bug when changing superclass in latest OB?

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 14, 2010

[Pharo-project] Bug when changing superclass in latest OB?

by Simon Denier

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

Oct. 14, 2010

Re: [Pharo-project] Issue 3101: Wrong Monticello packages initialization order

by Pavel Krivanek

Hi Alexandre, I attached a test to the issue record. Thanks for the poke ;-) Cheers, -- Pavel On Thu, Oct 14, 2010 at 2:00 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > Hi Pavel, > > It would be cool to have a test for this... > > Alexandre > > > On 14 Oct 2010, at 06:04, Pavel Krivanek wrote: > >> see http://code.google.com/p/pharo/issues/detail?id=3101 >> >> Cheers, >> -- Pavel >> _______________________________________________ >> 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 >

Oct. 14, 2010

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

by Igor Stasenko

On 14 October 2010 16:36, Ralph Boland <rpboland(a)gmail.com> wrote: >>> ... > >> 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? If we define that a result of expression (x :=: y) is a value of right operand, then expression like: a :=: b :=: c. will be parsed as: a :=: *err* ( b :=: c ) and you'll get an error 'lvalue expression expected' at *err*. > > 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? it will mean same as: a:= (b :=: c) > > _______________________________________________ > 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.

Oct. 14, 2010

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

by Ralph Boland

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

Oct. 14, 2010

Re: [Pharo-project] Issue 3101: Wrong Monticello packages initialization order

by Alexandre Bergel

Hi Pavel, It would be cool to have a test for this... Alexandre On 14 Oct 2010, at 06:04, Pavel Krivanek wrote: > see http://code.google.com/p/pharo/issues/detail?id=3101 > > Cheers, > -- Pavel > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 14, 2010

[Pharo-project] PharoKernel related issues

by Pavel Krivanek

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

Oct. 14, 2010

[Pharo-project] Issue 3102: removeAllButPackages:

by Pavel Krivanek

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

Oct. 14, 2010