- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: Issue 584 in pharo: SqueakPageCache generateURL -> DNU because pathForFile is not defined on ServerFile

by Alain Plantec

StÃ©phane Ducasse a Ã©crit : > I was thinking to move ObjectOut and little friends out of kernel and > out them in a dedicated package > Then clean MorphObjectOut. > There would be nice examples of reflective uses of Smalltalk but I'm > not sure that they still work. > Now I would do the following: > remove > BookMorph > TabbedPalette > SqueakPageCache > why not keep also SqueakPageCache then if SqueakPage is to be kept ?

June 8, 2009

Re: [Pharo-project] New Extensible Inspector for Pharo-Core

by Frederic Pluquet

> > > - get the view inpesctor (flash behavior) > > > > I don't understand what it means. > > you select in your tree an object bring a menu and click flash and > oops you see you widgets flashing. > Check the viewExplorer... sent in the list by "steven wirts" It is done in the last published version of NewInspector :) A new menu item "Flash" appears for Morph instances (Cmd-f works also). FrÃ©d

June 8, 2009

Re: [Pharo-project] New Extensible Inspector for Pharo-Core

by StÃ©phane Ducasse

On Jun 8, 2009, at 10:53 PM, Frederic Pluquet wrote: > Hello, > > frederick what I would love to have is a > - merge between the explorer and the inspector > > This is, no ? :) ok I did not load your code :) > > > - get the view inpesctor (flash behavior) > > I don't understand what it means. you select in your tree an object bring a menu and click flash and oops you see you widgets flashing. Check the viewExplorer... sent in the list by "steven wirts" > > > - get trippy like navigation (when you select an iv of an > element > that you can go over all the elements looking only > at the iv you selected) > > You can select an object (an instVar value, a method, ... any item > of the tree) and select "Add as root" in the contextual menu (or Cmd- > a). You can also delete a root item (menu "Remove from roots" or Cmd- > a). > > It is not exactly a trippy-like navigation, but you can inspect only > some sub-objects if you want. > > > - see the morph in the pane when this is a morph :) > > Good idea but it is no simple to implement (I want to work only with > Pluggeable*Spec classes and no directly with Morphs). > > FrÃ©d > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 8, 2009

Re: [Pharo-project] swapMouseButtons doesn't work

by StÃ©phane Ducasse

in 10331 core swapMouseButtons ^ self valueOfFlag: #swapMouseButtons ifAbsent: [ OSPlatform current platformFamily ~= #Windows ] On Jun 8, 2009, at 8:10 PM, Mariano Martinez Peck wrote: > I don't get it. I see Pharo 9.06.1 which is based on 10234 and this > is the implementation: > > swapMouseButtons > ^ self > valueOfFlag: #swapMouseButtons > ifAbsent: [false] > > > But, you said you change to > > > swapMouseButtons > ^ self > valueOfFlag: #swapMouseButtons > ifAbsent: [ > OSPlatform current platformFamily ~= #Windows ] > > in 10319 > > > So, maybe it has been overriden? > > Cheers, > > Mariano > > On Sun, Jun 7, 2009 at 5:16 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > In issue #838 I changed the implementation to be platform specific as > follows: > > swapMouseButtons > ^ self > valueOfFlag: #swapMouseButtons > ifAbsent: [ > OSPlatform current platformFamily ~= #Windows ] > > which means that for Unix swapping is enabled (returns true). > > If I understand you correctly, however, for Unix it should be > disabled. Is this correct? > > So the correct implementation would be to test for > > OSPlatform current platformFamily = #Mac (or similar) > > Adrian > > On Jun 7, 2009, at 19:08 , Mariano Martinez Peck wrote: > > > Hi folks: I had an Pharo 10318 and then updat to 10328 in Linux and > > swapMouseButtons seems to be wrong. For the "right button" I have to > > press > > the mouse wheel button. I tried this things: > > > > Preferences setPreference: #swapMouseButtons toValue: true. > > Preferences setPreference: #swapMouseButtons toValue: false. > > Preferences enable: #swapMouseButtons. > > Preferences disable: #swapMouseButtons. > > InputSensor swapMouseButtons: false. > > InputSensor swapMouseButtons: true. > > > > No one do nothing. > > > > I saw http://code.google.com/p/pharo/issues/detail?id=838 and seems > > to be > > changed in 10319 > > > > However, this is not working well in Linux. What I had to do to make > > it work > > is this: > > > > Rewrite Preferences>>swapMouseButtons to this: > > > > swapMouseButtons > > ^ self > > valueOfFlag: #swapMouseButtons > > ifAbsent: [self break. > > OSPlatform current platformFamily = #Windows > > ifTrue: [false]. > > OSPlatform current platformFamily = #Unix > > ifTrue: [false] ] > > > > > > And then do: > > > > InputEventSensor swapMouseButtons: false > > > > In addition 10324 dev seems to work ok for me out of the box. Can > be a > > problem of updating from an older version ? > > > > What can be the problem? > > > > Thanks > > > > Mariano > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 8, 2009

Re: [Pharo-project] About super initialize

by StÃ©phane Ducasse

Mine too. I have some serious doubt about the TTCompositeGlyph subclass of TGlyph when the initialize is not called. On Jun 8, 2009, at 10:08 PM, Alain Plantec wrote: > Damien Cassou a Ã©crit : >> On Mon, Jun 8, 2009 at 6:13 PM, StÃ©phane >> Ducasse<stephane.ducasse(a)inria.fr> wrote: >> >>> I was thinking that it would be nice to >>> check all the initialize methods that are not doing a super call, >>> and >>> fix them. >>> >> >> Are we sure that no #initialize method avoid calling super initialize >> on purpose? >> > Hi Damien, > my opinion is that such a situation reveals a design problem which > should be fixed. > but it is only my opinion. > Cheers > alain > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 8, 2009

Re: [Pharo-project] New Extensible Inspector for Pharo-Core

by Frederic Pluquet

Hello, > frederick what I would love to have is a > - merge between the explorer and the inspector This is, no ? :) > > - get the view inpesctor (flash behavior) I don't understand what it means. > > - get trippy like navigation (when you select an iv of an element > that you can go over all the elements looking only > at the iv you selected) You can select an object (an instVar value, a method, ... any item of the tree) and select "Add as root" in the contextual menu (or Cmd-a). You can also delete a root item (menu "Remove from roots" or Cmd-a). It is not exactly a trippy-like navigation, but you can inspect only some sub-objects if you want. > - see the morph in the pane when this is a morph :) > Good idea but it is no simple to implement (I want to work only with Pluggeable*Spec classes and no directly with Morphs). FrÃ©d

June 8, 2009

Re: [Pharo-project] About super initialize

by StÃ©phane Ducasse

> If ever you want to change these messages, please run some benchmark ok but when you have a class 4 level deep that has subclasses and an initialize and ... it means that when we will change its superclass Model we will get some bugs. I do not think that we will hev speed impact but yes we should run that. Still I have the impression that for direct subclasses of Object super initialize is unnecessary

June 8, 2009

Re: [Pharo-project] About super initialize

by StÃ©phane Ducasse

On Jun 8, 2009, at 6:36 PM, Damien Cassou wrote: > On Mon, Jun 8, 2009 at 6:13 PM, StÃ©phane > Ducasse<stephane.ducasse(a)inria.fr> wrote: >> I was thinking that it would be nice to >> check all the initialize methods that are not doing a super call, and >> fix them. > > Are we sure that no #initialize method avoid calling super initialize > on purpose? most of them predate the new/initialize patterns. on all the changes alain did I found so far only one mistake :) stef > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 8, 2009

Re: [Pharo-project] Syntax error loading Coral

by StÃ©phane Ducasse

> Hi all, > > I tried to load Coral in the latest dev image using ScriptLoader > and I got a syntax error in > "UnixProcess>>argsAsFlatArrayAndOffsets:". I guess it is an UTF-8 > problem. > Any ideas for a solution ? Not right on top of my head but this is cool that you tried it. I want to write pharo scripts to rename my iPhoto pictures and lot more. > > #Luc > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 8, 2009

Re: [Pharo-project] About EndOfStream notification [was Streams - #nextLine]

by StÃ©phane Ducasse

On Jun 8, 2009, at 9:32 PM, Nicolas Cellier wrote: > About this subject, here is a little reflexion explaining why > Notification are not my preferred solution anymore > (though I defended it at http://bugs.squeak.org/view.php?id=6755 ). > > > If you remember animated discussions about EndOfStream, then you might > say Oh no, not again! no if we can learn something in the process discussion is always worth. > > However, my opinion has evolved closer to Andreas' one. this > > > It still don't find == nil a good solution for generic Stream (though > acceptable for character streams). > Neither do I reject the idea of catching an EndOfStream : it can be > efficient if the event is rare > (in other words, if the stream is long, or if there are many wrappers, > each testing == nil or atEnd). > > What I find a big mistake now is to generalize use of an Exception > with a default action. > I know, this default action is for backward compatibility (answer > nil). > But let's take an example showing how it can be bad: > > First load ConnectEndOfStream-M6755-nice.1.cs and > RepeatUntil-M6755-nice.1.cs from > http://bugs.squeak.org/view.php?id=6755 > Then try this: > > | str sum buffer char | > str := '123 456 798' readStream. > sum := 0. > buffer := WriteStream on: (String new: 16). > > [char := str next. > char isSeparator > ifTrue: [buffer isEmpty > ifFalse: > [sum := sum + buffer contents asNumber. > buffer reset]] > ifFalse: [buffer nextPut: char]] > repeatUntil: EndOfStream. > buffer isEmpty ifFalse: [sum := sum + buffer contents.]. > ^sum > > Yes, it just split a string on separators, convert every packet into a > number and sum the numbers. > The example is silly, don't comment on that. There are plenty other > ways to split a String. > > The problem is that the loop will stop after first number... > What's going on? > Well, asNumber uses a readStream to perform the conversion, reads past > end, and signals an EndOfStream... > > That is bad... > I should have protected the Exception handling with: > > | str sum buffer char | > str := '123 456 798' readStream. > sum := 0. > buffer := WriteStream on: (String new: 16). > > [[char := str next. > char isSeparator > ifTrue: [buffer isEmpty > ifFalse: > [sum := sum + buffer contents asNumber. > buffer reset]] > ifFalse: [buffer nextPut: char]] > repeat] on: EndOfStream do: [:exc | exc receiver == str ifTrue: [exc > return] ifFalse: [exc pass]]. > buffer isEmpty ifFalse: [sum := sum + buffer contents.]. > ^sum > > Oh yes, easy. But imagine now that str is a wrapper on a FileStream... > (for example an InflateStream). Yeap it does not scale well in complexity for something that should be quite simple: there is not element anymore. :) > > Exception handling soon becomes hard to write, because you might have > to walk up the Context stack... > > There are better examples where I want Exceptions, so I'd like the > choice to be in programmers hands. > - 1) Raising an EndOfStream Exception (and not a Notification as I > suggested) should be optional > - 2) The Exception should not have a default action. > > The simple thing to do is to add an endOfStreamAction instanceVariable > to Stream or ReadStream. > If a read past end is attempted, then ^endOfStreamAction value. > > nil value = nil, so letting this inst var uninitialized will lead to > backward compatibility (at minimal cost concerning efficieny!). > filling the inst var with a block comes to mind immediately, and among > natural choice is: > Stream>>willSignalEndOfStream > self endOfStreamAction: [EndOfStream signal] > > There might be more work for Stream wrappers, but that sounds a cheap > and efficient idea to reconcile both worlds. > > What will protect above code example from an internal low level > EndOfStream? > Nothing, but the fact that programmers using explicitely > #willSignalEndOfStream will know what they do! > Either they will protect with a handling block, or advertise enough > that the code might generate spurious EndOfStream on malformed > inputs... sounds like a good compromise. > > > Of course, I must remind: use Exception handling pattern but don't > abuse. Programming with these deserve great care! > > Cheers > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 8, 2009