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

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