- Pharo-dev - lists.pharo.org

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

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

by Pavel Krivanek

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

Oct. 14, 2010

Re: [Pharo-project] [SPAM] [squeak-dev] Xtreams tests green

by Sven Van Caekenberghe

On 13 Oct 2010, at 21:29, Nicolas Cellier wrote: > 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 :) Super! > 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, +1 > 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. You earned it. > Nicolas Sven

Oct. 14, 2010