September 2014 - Pharo-dev - lists.pharo.org

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

by Max Leske

On 16.09.2014, at 09:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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 ? Ouch. Missed that. Thanks for checking! Fixed in new slice. Name: SLICE-Issue-14022-Infinite-loop-in-simple-subclasses-of-SequenceableCollection-MaxLeske.2 Author: MaxLeske Time: 16 September 2014, 10:11:57.66599 am UUID: d8315688-7ecb-4222-8216-fddbfddbb79e Ancestors: Dependencies: Collections-Abstract-MaxLeske.266, Collections-Sequenceable-MaxLeske.174 Break potential infinite loop in subclasses of SequenceableCollection by making #size a subclass responsibility > > 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] [Vm-dev] re: Parsing Pharo syntax to C/C++

by Thierry Goubier

2014-09-16 1:46 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > Ah! But! Sista has an advantage that other adaptive optimizers don't. > Because it optimizes from bytecode to bytecode it can be used during a > training phase and then switched off. > Great. Would it also be possible from the outside to make sista-like optimisations? I'm thinking of a few possibilities such as replacing some dictionary constant building code and a few others (i.e. a kind of [ ] once and the #(( )) of Dolphin) which could be handled at the user level (by tracking if it has to be recompiled if someone, say, changes the implementation of Dictionary). > > Real time applications requires an upper bound guarantee in their response >> time. In some cases, the lack of this guarantee can be just an annoyance, >> as happens in video games. In some mission critical applications the >> results can not be good, if this time constraint is not met. An example of >> a mission critical system could the flight controls of an airplane, or the >> cooling system of a nuclear reactor. >> >> For these application, it is not possible to rely in an adaptive >> optimizer that can be triggered sometimes. In these application you have to >> either: >> - Extend the language to hand optimize some performance critical sections >> of code. >> - Use another language to optimize these critical section. >> - Use another language for the whole project. >> > > The additional option is to "train" the optimizer by running the > application before deploying and capturing the optimised methods. Discuss > this with ClÃ©ment and he'll explain how straight-forward it should be. > This still leaves the latency in the Cogit when it compiles from bytecode > to machine code. But > > a) I've yet to see anybody raise JIT latency as an issue in Cog > How many instructions you spend on average in Cog per generated instruction? > b) it would be easy to extend the VM to cause the Cogit to precompile > specified methods. We could easily provide a "lock-down" facility that > would prevent Cog from discarding specific machine code methods. > That one is interesting. It sounds like a great benefit would be to have a limited API to the Cog JIT for that sort of requirements. > > And of course, you have to perform lot of profiling. >> > > Early and often :-). > > Because we can have complete control over the optimizer, and because Sista > is byetcode-to-bytecode and can hence store its results in the image in the > form of optimized methods, I believe that Sista is well-positioned for > real-time since it can be used before deployment. In fact we should > emphasise this in the papers we write on Sista. > I'm not sure of that "real-time" aspect is a good idea. More real-time than others dynamic optimisers, maybe. Note that Java Real-Time suggest turning off JIT and switch to ITC. The word you're looking for there is AoT Compiler :) Regards, Thierry

Sept. 16, 2014

Re: [Pharo-dev] Parsing Pharo syntax to C/C++

by Pavel Krivanek

Dne pondÄlÃ 15. zÃ¡ÅÃ 2014 phil(a)highoctane.be <phil(a)highoctane.be> napsal(a): > Slang has been externalized by Pavel. So, Smalltalk to C works. > > Works nicely, even if there were a few glitches (like code generated twice > at one point). > Nothing unfixable, I got the beast working. > > Allows for things like: write Slang, generate C, compile into DLL, load > DLL, run C code. All in a single shot. > > PavelKrivanek/CCodeGenerator on SmalltalkHub (which looks like super > slow/zombified). > > Phil > > I hope only super slow :-) I simply have no time for this project now. Help is welcome. -- Pavel > > > > > > > On Mon, Sep 15, 2014 at 11:28 AM, Santiago Bragagnolo < > santiagobragagnolo(a)gmail.com > <javascript:_e(%7B%7D,'cvml','santiagobragagnolo(a)gmail.com');>> wrote: > >> I may be wrong, but I think the closest thing out there is Slang. Is the >> pseudo smalltalk used to develop the VM. >> >> Also there is a project for generating C for arduino, (a project related >> with EToys), but i am not sure about how complete is. >> >> >> >> 2014-09-15 11:04 GMT+02:00 kilon alios <kilon.alios(a)gmail.com >> <javascript:_e(%7B%7D,'cvml','kilon.alios(a)gmail.com');>>: >> >>> Is there a way to convert code from pharo to c or c++ ? Does pettit >>> parser or other parsers offer such support ? >>> >> >> >

Sept. 16, 2014

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