- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Strange behavior in Pharo 3.0

by Sven Van Caekenberghe

On 16 Sep 2014, at 09:24, Max Leske <maxleske(a)gmail.com> wrote: > Slice in inbox. > > Required reimplementing #size in Stack and LinkedList. Argh, that is a bit ugly. Stack>>#size is not needed as it inherits from LinkedList, right ? Otherwise: checked and all Collection tests ran OK. > Name: SLICE-Issue-14022-Infinite-loop-in-simple-subclasses-of-SequenceableCollection-MaxLeske.1 > Author: MaxLeske > Time: 16 September 2014, 9:23:03.047607 am > UUID: a911f5cc-bc3e-4579-bbf4-ad6f61d1199c > Ancestors: > Dependencies: Collections-Abstract-MaxLeske.265, Collections-Sequenceable-MaxLeske.173, Collections-Stack-MaxLeske.8 > > Break potential infinite loop in subclasses of SequenceableCollection by making #size a subclass responsibility > > > On 16.09.2014, at 09:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Well, since SequenceableCollection overwrites #do: breaking its superclass' contract, it should also overwrite #size as subclassResponsibility - at least. That would break the loop, no ? >> >> The discussion about catching infinite recursion loops is old and comes up every couple of weeks. It should be fixed, it can be fixed IMHO, but it is a VM thing. >> >> On 16 Sep 2014, at 08:39, Max Leske <maxleske(a)gmail.com> wrote: >> >>> So first: as Sven said Sequenceable collection is abstract. >>> Still I would consider what you found a bug since it provides the implementations that produce the behavior you reported. >>> >>> I can reproduce it in a 40 with vmLatest, and the proble occurs whenever either #do: or #size is sent. >>> >>> SequenceableCollection>>do: aBlock >>> "Refer to the comment in Collection|do:.â >>> 1 to: self size do: [:index | aBlock value: (self at: index)] >>> >>> >>> Collection>>size >>> size "Answer how many elements the receiver contains.â >>> >>> | tally | >>> tally := 0. >>> self do: [:each | tally := tally + 1]. >>> ^ tally >>> >>> >>> As you can see, calling either method will produce an infinite loop which eventually crashes the VM. >>> >>> I couldnât find an open bug entry so Iâve created one: https://pharo.fogbugz.com/f/cases/14022/Infinite-loop-in-simple-subclasses-… >>> >>> Cheers, >>> Max >>> >>> On 15.09.2014, at 23:12, jdelgado(a)lsi.upc.edu wrote: >>> >>>> Hi, >>>> >>>> A student of mine has accidentaly found something interesting that may be already reported, but I do not have time to check. >>>> >>>> The thing is simple: >>>> >>>> 1) Create a class with accessors for f. >>>> >>>> SequenceableCollection subclass: #Foo >>>> instanceVariableNames: 'f' >>>> classVariableNames: '' >>>> category: 'Varios' >>>> >>>> 2) Foo class >> new: d >>>> ^self new f: (Array new: d*d) >>>> >>>> 3) Go to Workspace and inspect the following code >>>> >>>> | m | >>>> m := Foo new: 2 >>>> >>>> And Pharo crashes. Always crashes. I am using "Pharo 3.0 3" on OS X 10.6.8. I am pretty sure it is not a Smalltalk error since it works ok in Squeak and VisualWorks. >>>> >>>> So, is this a known issue? >>>> >>>> Bests, >>>> >>>> Jordi >>>> >>>> >>> >> >> > >

Sept. 16, 2014

Re: [Pharo-dev] Strange behavior in Pharo 3.0

by Max Leske

Slice in inbox. Required reimplementing #size in Stack and LinkedList. Name: SLICE-Issue-14022-Infinite-loop-in-simple-subclasses-of-SequenceableCollection-MaxLeske.1 Author: MaxLeske Time: 16 September 2014, 9:23:03.047607 am UUID: a911f5cc-bc3e-4579-bbf4-ad6f61d1199c Ancestors: Dependencies: Collections-Abstract-MaxLeske.265, Collections-Sequenceable-MaxLeske.173, Collections-Stack-MaxLeske.8 Break potential infinite loop in subclasses of SequenceableCollection by making #size a subclass responsibility On 16.09.2014, at 09:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Well, since SequenceableCollection overwrites #do: breaking its superclass' contract, it should also overwrite #size as subclassResponsibility - at least. That would break the loop, no ? > > The discussion about catching infinite recursion loops is old and comes up every couple of weeks. It should be fixed, it can be fixed IMHO, but it is a VM thing. > > On 16 Sep 2014, at 08:39, Max Leske <maxleske(a)gmail.com> wrote: > >> So first: as Sven said Sequenceable collection is abstract. >> Still I would consider what you found a bug since it provides the implementations that produce the behavior you reported. >> >> I can reproduce it in a 40 with vmLatest, and the proble occurs whenever either #do: or #size is sent. >> >> SequenceableCollection>>do: aBlock >> "Refer to the comment in Collection|do:.â >> 1 to: self size do: [:index | aBlock value: (self at: index)] >> >> >> Collection>>size >> size "Answer how many elements the receiver contains.â >> >> | tally | >> tally := 0. >> self do: [:each | tally := tally + 1]. >> ^ tally >> >> >> As you can see, calling either method will produce an infinite loop which eventually crashes the VM. >> >> I couldnât find an open bug entry so Iâve created one: https://pharo.fogbugz.com/f/cases/14022/Infinite-loop-in-simple-subclasses-… >> >> Cheers, >> Max >> >> On 15.09.2014, at 23:12, jdelgado(a)lsi.upc.edu wrote: >> >>> Hi, >>> >>> A student of mine has accidentaly found something interesting that may be already reported, but I do not have time to check. >>> >>> The thing is simple: >>> >>> 1) Create a class with accessors for f. >>> >>> SequenceableCollection subclass: #Foo >>> instanceVariableNames: 'f' >>> classVariableNames: '' >>> category: 'Varios' >>> >>> 2) Foo class >> new: d >>> ^self new f: (Array new: d*d) >>> >>> 3) Go to Workspace and inspect the following code >>> >>> | m | >>> m := Foo new: 2 >>> >>> And Pharo crashes. Always crashes. I am using "Pharo 3.0 3" on OS X 10.6.8. I am pretty sure it is not a Smalltalk error since it works ok in Squeak and VisualWorks. >>> >>> So, is this a known issue? >>> >>> Bests, >>> >>> Jordi >>> >>> >> > >

Sept. 16, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40227 Home: https://github.com/pharo-project/pharo-core

Sept. 16, 2014

[pharo-project/pharo-core] 9687d2: 40227

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 9687d2baa4530b849cb16a540616f4c1b00eba35 https://github.com/pharo-project/pharo-core/commit/9687d2baa4530b849cb16a54… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-16 (Tue, 16 Sep 2014) Changed paths: M EmbeddedFreeTypeTests.package/EmbeddedFreeTypeFontInstallerTest.class/instance/tests/testinstallAllFontsIn.st A FontInfrastructureTests.package/LogicalFontManagerTest.class/README.md A FontInfrastructureTests.package/LogicalFontManagerTest.class/definition.st A FontInfrastructureTests.package/LogicalFontManagerTest.class/instance/tests/testHasCurrentFreeTypeFontProvider.st A FontInfrastructureTests.package/extension/LogicalFontManager/instance/identityIncludesFontProvider_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script227.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40227.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40227 14020 Add test cases which check font installation process and registration on singletons https://pharo.fogbugz.com/f/cases/14020 14006 3 tests fail for AsmJit in the Pharo4 https://pharo.fogbugz.com/f/cases/14006 http://files.pharo.org/image/40/40227.zip

Sept. 16, 2014

Re: [Pharo-dev] Strange behavior in Pharo 3.0

by Sven Van Caekenberghe

Well, since SequenceableCollection overwrites #do: breaking its superclass' contract, it should also overwrite #size as subclassResponsibility - at least. That would break the loop, no ? The discussion about catching infinite recursion loops is old and comes up every couple of weeks. It should be fixed, it can be fixed IMHO, but it is a VM thing. On 16 Sep 2014, at 08:39, Max Leske <maxleske(a)gmail.com> wrote: > So first: as Sven said Sequenceable collection is abstract. > Still I would consider what you found a bug since it provides the implementations that produce the behavior you reported. > > I can reproduce it in a 40 with vmLatest, and the proble occurs whenever either #do: or #size is sent. > > SequenceableCollection>>do: aBlock > "Refer to the comment in Collection|do:.â > 1 to: self size do: [:index | aBlock value: (self at: index)] > > > Collection>>size > size "Answer how many elements the receiver contains.â > > | tally | > tally := 0. > self do: [:each | tally := tally + 1]. > ^ tally > > > As you can see, calling either method will produce an infinite loop which eventually crashes the VM. > > I couldnât find an open bug entry so Iâve created one: https://pharo.fogbugz.com/f/cases/14022/Infinite-loop-in-simple-subclasses-… > > Cheers, > Max > > On 15.09.2014, at 23:12, jdelgado(a)lsi.upc.edu wrote: > >> Hi, >> >> A student of mine has accidentaly found something interesting that may be already reported, but I do not have time to check. >> >> The thing is simple: >> >> 1) Create a class with accessors for f. >> >> SequenceableCollection subclass: #Foo >> instanceVariableNames: 'f' >> classVariableNames: '' >> category: 'Varios' >> >> 2) Foo class >> new: d >> ^self new f: (Array new: d*d) >> >> 3) Go to Workspace and inspect the following code >> >> | m | >> m := Foo new: 2 >> >> And Pharo crashes. Always crashes. I am using "Pharo 3.0 3" on OS X 10.6.8. I am pretty sure it is not a Smalltalk error since it works ok in Squeak and VisualWorks. >> >> So, is this a known issue? >> >> Bests, >> >> Jordi >> >> >

Sept. 16, 2014

Re: [Pharo-dev] Pragmas/Annotations for classes

by stepharo

What would be design of a possible solution? With a different class creation it would be possible Color subclass: #TranslucentColor instanceVariables: 'alph'; annotation: #deprecated. nothing prevent us to design something, this is just that we are stuck in the past :) Stef On 15/9/14 21:58, Torsten Bergmann wrote: > Currently only methods support pragmas in Pharo. Therefore we already had a discussion > about "Pragmas/Annotations for classes". See > > http://forum.world.st/Pragmas-Annotations-for-classes-td2282310.html > > To summarize: it would be helpfull to have them (and with them also get rid of workarounds > like specific conventions, abusing class comments, etc.). > > At that time it was not possible to add an iVar to Class, but this issue > was solved already: > https://pharo.fogbugz.com/f/cases/11596/Adding-an-iVar-to-class-Class-gives… > Must admit I havent tested in latest Pharo 4 if this is still working. > > After we now have slots and other nice extensions in Pharo again my basic > question: what about having "annotations" for a class in Pharo. I think we will > find enough use cases on annotating a class with someting useful. Even a category > or a comment could just be an annotation. > > Is there interest to have such a change for Pharo4 or are there reasons to abandon such > an idea. I guess such a change could not be provided with a simple slice. Any thoughts/decisions? > > Thanks > T. > > > >

Sept. 16, 2014

Re: [Pharo-dev] Strange behavior in Pharo 3.0

by Max Leske

And 30 has the exact same problem of course (just checked). On 16.09.2014, at 08:39, Max Leske <maxleske(a)gmail.com> wrote: > So first: as Sven said Sequenceable collection is abstract. > Still I would consider what you found a bug since it provides the implementations that produce the behavior you reported. > > I can reproduce it in a 40 with vmLatest, and the proble occurs whenever either #do: or #size is sent. > > SequenceableCollection>>do: aBlock > "Refer to the comment in Collection|do:.â > 1 to: self size do: [:index | aBlock value: (self at: index)] > > > Collection>>size > size "Answer how many elements the receiver contains.â > > | tally | > tally := 0. > self do: [:each | tally := tally + 1]. > ^ tally > > > As you can see, calling either method will produce an infinite loop which eventually crashes the VM. > > I couldnât find an open bug entry so Iâve created one: https://pharo.fogbugz.com/f/cases/14022/Infinite-loop-in-simple-subclasses-… > > Cheers, > Max > > On 15.09.2014, at 23:12, jdelgado(a)lsi.upc.edu wrote: > >> Hi, >> >> A student of mine has accidentaly found something interesting that may be already reported, but I do not have time to check. >> >> The thing is simple: >> >> 1) Create a class with accessors for f. >> >> SequenceableCollection subclass: #Foo >> instanceVariableNames: 'f' >> classVariableNames: '' >> category: 'Varios' >> >> 2) Foo class >> new: d >> ^self new f: (Array new: d*d) >> >> 3) Go to Workspace and inspect the following code >> >> | m | >> m := Foo new: 2 >> >> And Pharo crashes. Always crashes. I am using "Pharo 3.0 3" on OS X 10.6.8. I am pretty sure it is not a Smalltalk error since it works ok in Squeak and VisualWorks. >> >> So, is this a known issue? >> >> Bests, >> >> Jordi >> >> >

Sept. 16, 2014

Re: [Pharo-dev] Strange behavior in Pharo 3.0

by Max Leske

So first: as Sven said Sequenceable collection is abstract. Still I would consider what you found a bug since it provides the implementations that produce the behavior you reported. I can reproduce it in a 40 with vmLatest, and the proble occurs whenever either #do: or #size is sent. SequenceableCollection>>do: aBlock "Refer to the comment in Collection|do:.â 1 to: self size do: [:index | aBlock value: (self at: index)] Collection>>size size "Answer how many elements the receiver contains.â | tally | tally := 0. self do: [:each | tally := tally + 1]. ^ tally As you can see, calling either method will produce an infinite loop which eventually crashes the VM. I couldnât find an open bug entry so Iâve created one: https://pharo.fogbugz.com/f/cases/14022/Infinite-loop-in-simple-subclasses-… Cheers, Max On 15.09.2014, at 23:12, jdelgado(a)lsi.upc.edu wrote: > Hi, > > A student of mine has accidentaly found something interesting that may be already reported, but I do not have time to check. > > The thing is simple: > > 1) Create a class with accessors for f. > > SequenceableCollection subclass: #Foo > instanceVariableNames: 'f' > classVariableNames: '' > category: 'Varios' > > 2) Foo class >> new: d > ^self new f: (Array new: d*d) > > 3) Go to Workspace and inspect the following code > > | m | > m := Foo new: 2 > > And Pharo crashes. Always crashes. I am using "Pharo 3.0 3" on OS X 10.6.8. I am pretty sure it is not a Smalltalk error since it works ok in Squeak and VisualWorks. > > So, is this a known issue? > > Bests, > > Jordi > >

Sept. 16, 2014

Re: [Pharo-dev] Pragmas/Annotations for classes

by Marcus Denker

On 15 Sep 2014, at 21:58, Torsten Bergmann <astares(a)gmx.de> wrote: > Currently only methods support pragmas in Pharo. Therefore we already had a discussion > about "Pragmas/Annotations for classes". See > > http://forum.world.st/Pragmas-Annotations-for-classes-td2282310.html > > To summarize: it would be helpfull to have them (and with them also get rid of workarounds > like specific conventions, abusing class comments, etc.). > > At that time it was not possible to add an iVar to Class, but this issue > was solved already: > https://pharo.fogbugz.com/f/cases/11596/Adding-an-iVar-to-class-Class-gives… > Must admit I havent tested in latest Pharo 4 if this is still working. > > After we now have slots and other nice extensions in Pharo again my basic > question: what about having "annotations" for a class in Pharo. I think we will > find enough use cases on annotating a class with someting useful. Even a category > or a comment could just be an annotation. > > Is there interest to have such a change for Pharo4 or are there reasons to abandon such > an idea. I guess such a change could not be provided with a simple slice. Any thoughts/decisions? Interest: Yes. But I personally need to finish Slots+Reflectivity before being able to even think about this. So it would be nice if someone would do some prototypes about thisâ¦ Marcus

Sept. 16, 2014

Pharo Success Stories on homepage - feedback

by Torsten Bergmann

Looks like it was late when more stories were added. Some feedback: 1. The link to "Reflex vacances" does not work 2. Why do you write "Reflex vacances WAS a french platform for holiday rentals"? I think it still IS a french platform for holiday rentals. 3. CloudShoppie should have some more text. A summary is here: https://groups.google.com/forum/#!topic/comp.lang.smalltalk/f7E9pnSs_jM and here http://letsbuildkaec.challengepost.com/submissions/23789-cloud-shoppie 4. For "Sirop" the link http://www.siropglobal.com is not really a clickable link. I think it should also be ORG instead of COM: https://www.siropglobal.org/ 5. Why do "GetItMade WAS a platform to support crowdfunding for innovators", it still IS a platform to support crowdfunding. Please correct! Thanks T.

Sept. 16, 2014