December 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Interval protocol

by Nicolas Cellier

2012/12/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2012/12/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> On Dec 16, 2012, at 11:44 AM, Nicolas Cellier wrote: >> >>> 2012/12/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> polymorphically they are a collection with a first and last :) >>>> >>> >>> No. >>> >>> (5 to: 4) is different than (3 to: 2) because they specify a different >>> cursor position. >> >> Ok that I understand >> >>> Viewed as collection, they have no first nor last, they're just empty >>> >>> Nicolas > > Currently: > > (3 to: 2) first -> 3. > (3 to: 2) last -> 2. > > But: > (2 to: 4 by: 3) last -> 2 > > Try to guess the logic behind this... > >> >> I see. But does it make sense to have (thinking aloud)? >> (3 to: 2) start -> 3 >> (3 to: 2) end -> 2 >> probably? > > Yes, I did that refactoring in Squeak 3.9, but I was sure it would be > rejected, too many methods were changed (TextMorph ParagraphEditor & > co). See http://bugs.squeak.org/view.php?id=6454 > > You also know that breaking the classes we use for browsing/debugging > is a dangerous sport ;) > > The simplest thing would be to add a few message to TextLineInterval > (first, last, ...) and move it somewhere else in hierarchy, because I > don't think it shares that much with Interval. > - I guess we don't use much of Collection protocol in TextLineInterval > - it spoils first/last uniformity > - it can't handle Interval step > - ... > >> >> So we should improve that. >> If what I said is correct and you confirm it I will open a bug entry >> Stef >> >> > > I found http://bugs.squeak.org/view.php?id=7002 indicating that most > weirdness of Interval were corrected, but I'm quite sure it still has > other reported or non reported bugs, except hash. > > I can still do an infinite loop with to:do: and Float, > 2 - Float epsilon to: 2 by: Float epsilon/4 do: [:i | Transcript cr; > show: i printString] > > but Interval>>do: is correct: (well I warned you, some rounding occurs...) > (2 - Float epsilon to: 2 by: Float epsilon/4) do: [:i | Transcript cr; > show: i printString] > > For hash, I wonder if it would not be easier to just drop #(2 3) = (2 > to: 3) and let it answer false. > We have hasSameElementsThan: or isSameSequenceThan: for that purpose. > or we haven't (? can't remember), but should have. > Nicolas > >> >>

Dec. 16, 2012

Re: [Pharo-project] CI down?

by StÃ©phane Ducasse

Try https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/artifact/ > I wanted to grab the latest build to check for a possible bug and the CI seems to be downâ¦ > > Max

Dec. 16, 2012

Re: [Pharo-project] Interval protocol

by Nicolas Cellier

2012/12/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Dec 16, 2012, at 11:44 AM, Nicolas Cellier wrote: > >> 2012/12/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> polymorphically they are a collection with a first and last :) >>> >> >> No. >> >> (5 to: 4) is different than (3 to: 2) because they specify a different >> cursor position. > > Ok that I understand > >> Viewed as collection, they have no first nor last, they're just empty >> >> Nicolas Currently: (3 to: 2) first -> 3. (3 to: 2) last -> 2. But: (2 to: 4 by: 3) last -> 2 Try to guess the logic behind this... > > I see. But does it make sense to have (thinking aloud)? > (3 to: 2) start -> 3 > (3 to: 2) end -> 2 > probably? Yes, I did that refactoring in Squeak 3.9, but I was sure it would be rejected, too many methods were changed (TextMorph ParagraphEditor & co). See http://bugs.squeak.org/view.php?id=6454 You also know that breaking the classes we use for browsing/debugging is a dangerous sport ;) The simplest thing would be to add a few message to TextLineInterval (first, last, ...) and move it somewhere else in hierarchy, because I don't think it shares that much with Interval. - I guess we don't use much of Collection protocol in TextLineInterval - it spoils first/last uniformity - it can't handle Interval step - ... > > So we should improve that. > If what I said is correct and you confirm it I will open a bug entry > Stef > > I found http://bugs.squeak.org/view.php?id=7002 indicating that most weirdness of Interval were corrected, but I'm quite sure it still has other reported or non reported bugs, except hash. I can still do an infinite loop with to:do: and Float, 2 - Float epsilon to: 2 by: Float epsilon/4 do: [:i | Transcript cr; show: i printString] but Interval>>do: is correct: (well I warned you, some rounding occurs...) (2 - Float epsilon to: 2 by: Float epsilon/4) do: [:i | Transcript cr; show: i printString] For hash, I wonder if it would not be easier to just drop #(2 3) = (2 to: 3) and let it answer false. We have hasSameElementsThan: or isSameSequenceThan: for that purpose. Nicolas > >

Dec. 16, 2012

[Pharo-project] NativeBoost types -> anonymous subclasses issue

by Ciprian Teodorov

Hi Igor, Besides some other small comits, in NativeBoost-Core-CiprianTeodorov.103 I have changed the way anonymous subclasses of NBExternalTypeValue and NBExternalArray are created. The reason is that using the old way we would create multiple instances of the same metaclass which is not allowed in the image. BTW, I was getting this problem when trying to modify (add or remove) class instance variables of the NBExternalArray. Doing NBExternalArray class allInstances, I was clearly getting more than one instance... Now the anonymous subclasses are build using ClassBuilder>>#newSubclassOf:type:instanceVariables:from: which seems to prevent this problem from happening. What do you think? Are there other ways to get around this problem? Cheers, -- Dr. Ciprian TEODOROV IngÃ©nieur DÃ©veloppement CAO tÃ©l : 06 08 54 73 48 mail : ciprian.teodorov(a)gmail.com www.teodorov.ro

Dec. 16, 2012

Re: [Pharo-project] File out of *extension -> debugger -> bug?

by StÃ©phane Ducasse

thanks Max On Dec 16, 2012, at 2:45 PM, Max Leske wrote: > Done. > > http://code.google.com/p/pharo/issues/detail?id=7132 > > > On 16.12.2012, at 11:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> max can you add a bug entry for 2.0 so that we do not forget to fix it. >> Thx >> >> Stef >> On Dec 15, 2012, at 10:14 AM, Max Leske wrote: >> >>> Hi Sabine. >>> >>> Verified, that's a bug in 1.3. >>> >>> In 2.0 the OBSystemBrowserAdaptor isn't loaded by default (I doubt that anyone got it running (?)) and the default browser is Nautilus. So you don't actually have that option in 2.0. >>> >>> Nautillus shows extensions in separate extension categories. These can be filed out but the file will be empty (not tested in the latest build). >>> Anyone aware of this problem? >>> >>> Cheers, >>> Max >>> >>> >>> On 15.12.2012, at 09:33, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: >>> >>>> Hi, >>>> >>>> I assume, this is a bug in Pharo? >>>> I select "browse package" in the System browser and then "file out" for the >>>> category "*Extensions". >>>> Other categories work. Occurs also in "*Extensions" of other packages. >>>> >>>> Is it fixed in Pharo 2.0? >>>> >>>> Greetings >>>> Sabine >>>> >>>> 15 December 2012 9:31:37 am >>>> >>>> VM: Win32 - IX86 - 6.1 - Croquet Closure Cog VM [CoInterpreter >>>> VMMaker.oscog-eem.140] >>>> Image: Pharo1.3 [Latest update: #13327] >>>> >>>> RBPackageEnvironment(Object)>>doesNotUnderstand: #organization >>>> Receiver: RKA24 >>>> Arguments and temporary variables: >>>> aMessage: organization >>>> exception: MessageNotUnderstood: RBPackageEnvironment>>organization >>>> resumeValue: nil >>>> Receiver's instance variables: >>>> label: 'RKA24' >>>> searchStrings: nil >>>> environment: Smalltalk >>>> packages: a Set(a PackageInfo(RKA24)) >>>> >>>> ORPackageExtensionNode(OBClassCategoryNode)>>fileOut >>>> Receiver: ORPackageExtensionNode<*Extensions> >>>> Arguments and temporary variables: >>>> >>>> Receiver's instance variables: >>>> metaNode: ExtensionCategory >>>> #classes->Class >>>> #comments->ClassComment >>>> #metaclasse...etc... >>>> environment: RKA24 >>>> name: #'*Extensions' >>>> >>>> OBCmdFileOut>>execute >>>> Receiver: an OBCmdFileOut >>>> Arguments and temporary variables: >>>> >>>> Receiver's instance variables: >>>> target: ORPackageExtensionNode<*Extensions> >>>> requestor: an OBColumn(*Extensions) >>>> >>>> OBCmdFileOut(OBCommand)>>perform:orSendTo: >>>> Receiver: an OBCmdFileOut >>>> Arguments and temporary variables: >>>> aSelector: #execute >>>> anObject: an OBPluggableListMorph(35651584) >>>> Receiver's instance variables: >>>> target: ORPackageExtensionNode<*Extensions> >>>> requestor: an OBColumn(*Extensions) >>>> >>>> [| selArgCount | >>>> (selArgCount := selector numArgs) = 0 >>>> ifTrue: [target perform: selector] >>>> ifFalse: [selArgCount = arguments size >>>> ifTrue: [target perform: selector withArguments: arguments] >>>> ifFalse: [target >>>> perform: selector >>>> withArguments: (arguments copyWith: evt)]]. >>>> self changed] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: >>>> Receiver: a ToggleMenuItemMorph(634388480)'File out' >>>> Arguments and temporary variables: >>>> evt: [904@314 mouseUp 195226000 nil] >>>> selArgCount: 2 >>>> Receiver's instance variables: >>>> bounds: 768@307 corner: 964@321 >>>> owner: a MenuMorph(664535040) >>>> submorphs: #() >>>> fullBounds: 768@307 corner: 964@321 >>>> color: Color black >>>> extension: a MorphExtension (637009920) >>>> font: a StrikeFont(Bitmap DejaVu Sans 9 14) >>>> emphasis: 0 >>>> contents: 'File out' >>>> hasFocus: false >>>> isEnabled: true >>>> subMenu: nil >>>> isSelected: false >>>> target: an OBCmdFileOut >>>> selector: #perform:orSendTo: >>>> arguments: an Array(#execute an OBPluggableListMorph(35651584)) >>>> icon: Form(16x1x8) >>>> getStateSelector: nil >>>> enablementSelector: nil >>>> keyText: 'cmd+o' >>>> >>>> >>>> >>>> >>>> -- >>>> View this message in context: http://forum.world.st/File-out-of-extension-debugger-bug-tp4659339.html >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>> >>> >> >> > >

Dec. 16, 2012

Re: [Pharo-project] File out of *extension -> debugger -> bug?

by Max Leske

Done. http://code.google.com/p/pharo/issues/detail?id=7132 On 16.12.2012, at 11:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > max can you add a bug entry for 2.0 so that we do not forget to fix it. > Thx > > Stef > On Dec 15, 2012, at 10:14 AM, Max Leske wrote: > >> Hi Sabine. >> >> Verified, that's a bug in 1.3. >> >> In 2.0 the OBSystemBrowserAdaptor isn't loaded by default (I doubt that anyone got it running (?)) and the default browser is Nautilus. So you don't actually have that option in 2.0. >> >> Nautillus shows extensions in separate extension categories. These can be filed out but the file will be empty (not tested in the latest build). >> Anyone aware of this problem? >> >> Cheers, >> Max >> >> >> On 15.12.2012, at 09:33, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: >> >>> Hi, >>> >>> I assume, this is a bug in Pharo? >>> I select "browse package" in the System browser and then "file out" for the >>> category "*Extensions". >>> Other categories work. Occurs also in "*Extensions" of other packages. >>> >>> Is it fixed in Pharo 2.0? >>> >>> Greetings >>> Sabine >>> >>> 15 December 2012 9:31:37 am >>> >>> VM: Win32 - IX86 - 6.1 - Croquet Closure Cog VM [CoInterpreter >>> VMMaker.oscog-eem.140] >>> Image: Pharo1.3 [Latest update: #13327] >>> >>> RBPackageEnvironment(Object)>>doesNotUnderstand: #organization >>> Receiver: RKA24 >>> Arguments and temporary variables: >>> aMessage: organization >>> exception: MessageNotUnderstood: RBPackageEnvironment>>organization >>> resumeValue: nil >>> Receiver's instance variables: >>> label: 'RKA24' >>> searchStrings: nil >>> environment: Smalltalk >>> packages: a Set(a PackageInfo(RKA24)) >>> >>> ORPackageExtensionNode(OBClassCategoryNode)>>fileOut >>> Receiver: ORPackageExtensionNode<*Extensions> >>> Arguments and temporary variables: >>> >>> Receiver's instance variables: >>> metaNode: ExtensionCategory >>> #classes->Class >>> #comments->ClassComment >>> #metaclasse...etc... >>> environment: RKA24 >>> name: #'*Extensions' >>> >>> OBCmdFileOut>>execute >>> Receiver: an OBCmdFileOut >>> Arguments and temporary variables: >>> >>> Receiver's instance variables: >>> target: ORPackageExtensionNode<*Extensions> >>> requestor: an OBColumn(*Extensions) >>> >>> OBCmdFileOut(OBCommand)>>perform:orSendTo: >>> Receiver: an OBCmdFileOut >>> Arguments and temporary variables: >>> aSelector: #execute >>> anObject: an OBPluggableListMorph(35651584) >>> Receiver's instance variables: >>> target: ORPackageExtensionNode<*Extensions> >>> requestor: an OBColumn(*Extensions) >>> >>> [| selArgCount | >>> (selArgCount := selector numArgs) = 0 >>> ifTrue: [target perform: selector] >>> ifFalse: [selArgCount = arguments size >>> ifTrue: [target perform: selector withArguments: arguments] >>> ifFalse: [target >>> perform: selector >>> withArguments: (arguments copyWith: evt)]]. >>> self changed] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: >>> Receiver: a ToggleMenuItemMorph(634388480)'File out' >>> Arguments and temporary variables: >>> evt: [904@314 mouseUp 195226000 nil] >>> selArgCount: 2 >>> Receiver's instance variables: >>> bounds: 768@307 corner: 964@321 >>> owner: a MenuMorph(664535040) >>> submorphs: #() >>> fullBounds: 768@307 corner: 964@321 >>> color: Color black >>> extension: a MorphExtension (637009920) >>> font: a StrikeFont(Bitmap DejaVu Sans 9 14) >>> emphasis: 0 >>> contents: 'File out' >>> hasFocus: false >>> isEnabled: true >>> subMenu: nil >>> isSelected: false >>> target: an OBCmdFileOut >>> selector: #perform:orSendTo: >>> arguments: an Array(#execute an OBPluggableListMorph(35651584)) >>> icon: Form(16x1x8) >>> getStateSelector: nil >>> enablementSelector: nil >>> keyText: 'cmd+o' >>> >>> >>> >>> >>> -- >>> View this message in context: http://forum.world.st/File-out-of-extension-debugger-bug-tp4659339.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> > >

Dec. 16, 2012

[Pharo-project] CI down?

by Max Leske

I wanted to grab the latest build to check for a possible bug and the CI seems to be downâ¦ Max

Dec. 16, 2012

Re: [Pharo-project] About (backwards) Compatibility

by StÃ©phane Ducasse

+1 > but, since we take responsibility for all the packages loaded in what we call "pharo", we rather prefer not to have duplicates, so we achieve one of our goal (cleanness) while also focussing out effort. > > I'm sorry if that annoys some of you time to time, but that's the way to improve: to change. > > Also... I think you are overreacting, in pharo 2.0 we just introduced three big changes (visible to users): FS, SystemAnnouncer (who has, btw, same API than old SystemChangeNotifier) and Nautilus... that's all. All the other is infrastructure and shouldn't be a problem for anyone.

Dec. 16, 2012

Re: [Pharo-project] Interval protocol

by StÃ©phane Ducasse

On Dec 16, 2012, at 11:44 AM, Nicolas Cellier wrote: > 2012/12/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> polymorphically they are a collection with a first and last :) >> > > No. > > (5 to: 4) is different than (3 to: 2) because they specify a different > cursor position. Ok that I understand > Viewed as collection, they have no first nor last, they're just empty > > Nicolas I see. But does it make sense to have (thinking aloud)? (3 to: 2) start -> 3 (3 to: 2) end -> 2 probably? So we should improve that. If what I said is correct and you confirm it I will open a bug entry Stef

Dec. 16, 2012

Re: [Pharo-project] About (backwards) Compatibility

by StÃ©phane Ducasse

On Dec 16, 2012, at 5:44 AM, Esteban A. Maringolo wrote: > "If Henry Ford had asked his customers, they would have told him they want a > faster horse...'' > > I certainly do not want a faster horse. Excellent. Thanks this is so true. Now we are really concerned about making the life of other easier. We always pay attention as esteban said it so well: "Let me explain this once again: we are not "backward compatibility killer maniacs" :) We prefer to keep backward compatibility whenever is possible, but we don't put it as a top priority: if we find room to improve, we do it. " Now we want to build a new generation smalltalk and we cannot travel heavy because it slow us down. As an example looking for senders in a system full of obsolete classes does NOT work. Stef

Dec. 16, 2012