October 2013 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] ee26c3: 30521

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: ee26c3a454be5ecb199f0447700a856def4bde24 https://github.com/pharo-project/pharo-core/commit/ee26c3a454be5ecb199f0447… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-10-25 (Fri, 25 Oct 2013) Changed paths: M Morphic-Base.package/MenuMorph.class/instance/construction/addList_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script176.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30521.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Traits.package/TBehavior.class/instance/accessing method dictionary/localSelectors.st Log Message: ----------- 30521 11995 MenuMorph>>addList: sends #iconNamed: to an instance of Pharo3Theme, which raises a warning of deprecation. https://pharo.fogbugz.com/f/cases/11995 #localSelectors add to Trait so cleanup is possible in a second step http://files.pharo.org/image/30/30521.zip

Oct. 25, 2013

[pharo-project/pharo-core]

by GitHub

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

Oct. 25, 2013

RB AST node positions off by one or more characters with Opal ?

by Goubier Thierry

Hi all, has anybody noticed that, when getting node positions from a RB parse of the AST, they seem to be off by one character or more? It happens in smart suggestions type of commands for me, but it seems to also happens when the compiler tries to remove unused temporaries and garbles up the temp declaration line? (In the latest 3.0, of course :)) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Oct. 25, 2013

DeepCopier>>isItTimeToCheckVariables

by Martin Dias

Hi, This method in DeepCopier has no senders (in Pharo 3) and it's the only who references the class variable NextVariableCheckTime. The time stamp says 1999... Unused code to remove? isItTimeToCheckVariables | now isIt | NextVariableCheckTime ifNil: [ NextVariableCheckTime := Time totalSeconds. ^ true]. now := Time totalSeconds. isIt := NextVariableCheckTime < now. isIt ifTrue: ["update time for next check" NextVariableCheckTime := now + self intervalForChecks]. ^isIt Cheers, MartÃn

Oct. 25, 2013

Re: [Pharo-dev] VM for Athens Graphics

by Norbert Hartl

Am 24.10.2013 um 12:51 schrieb Igor Stasenko <siguctua(a)gmail.com>: > > > > On 24 October 2013 08:24, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 23.10.2013 um 23:28 schrieb Igor Stasenko <siguctua(a)gmail.com>: > >> >> >> >> On 23 October 2013 23:13, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>> >>> Well implementing ARM-FFI is largely orthogonal to Athens. >>> Yes, i am happily using it for Cairo and it lets me customize /rethink things as they go >>> without need to touch VM. Which means much faster development process and feedback etc. >>> But since Athens API is settled down more or less, now it is quite possible to implement a plugin >>> for different backend, knowing that it won't require huge changes later. >> >> Ok I was not aware you were thinking about that. So this is good to have this path in my radar. >> >> Yes, this is actually what we discussed recently with Esteban about possible alternatives and >> low-hanging fruits :) >> >>> Concerning ARM: >>> - Damien Pollet works on ARM assembler for ASMJit. >>> as soon as it working, we can try doing something with it. >>> >>> But in addition, what i would like to do is to move more towards platform-neutral FFI implementation, >>> using low-level assembler DSL which is platform neutral. There's a work started on it >>> as part of Mate project, but it is yet far from finished. >> >> I would love that. >> Now I guess that I'm correct to say that even with it the fact that it would generate assembly on the fly >> would make it a no go for iPad and friends. >> >> I thought that esteban and you thought about generating the "assembly once for all for Ipda and putting it in file" >> so that we do not have the "assembly generation" problem? >> >> that's a big question, whether such idea fits into apple technicians/politicans heads or not. >> Do you think we have enough time/resources to waste on implementing such mechanism >> only to discover later that Apple says 'over my dead body'? >> The point is that generating code, saving it to file, and then loading that file as DLL, >> is largely a hack. >> You either allowed to run your own generated code or not.. because from security perspective, >> the fact that you first stored it into file and then load it back doesn't changes a tiny bit. > > You store the code in a file in order to rip off the code generation part from your image. That would make it comply to apples policies. Same goes for the compiler. You are also not allowed to download a library and use it in your program. I think the plot is that apps get examined before they are allowed to be in the appstore. Changing the runtime would break this certification of the binary and apple would loose control because everybody would add a clean binary to the examination process and then they would load everything else when the user opens the app for the first time. So there is some sense in this. It is just a different way of thinking that we find annoying. > The sense is that i'm not changing NativeBoost each time i using it, so i am not "changing the runtime". > It is pure fallacy to consider code as something else than just simple data. > Sure thing, if i mutate the codebase by loading external code from random source later (and this is what we regularly do with our images) > then the contract is broken. But not in case when all my code and i'm not changing it in any way. The fact it using code generation doesn't means it will turn into something else if i don't want to. > It is all about if you have the possibility to change the runtime at runtime or not. If you put native code into a file and remove everything that might change it you have the runtime apple wants. For me this is not philosophical debate so I donât go into details. I donât even like coming close to defend the way apple does it. Coming from the system side I just have two hearts beating in my chest. The old one (the security/dark side) tells me you have to restrict everything to be safe. The other/new one tells me: Screw the dark side. Weâll get nowhere with this attitude, let us invent stuff instead of fear stuff. Norbert > > Norbert > >> From design perspective, it is crutch, which don't really buys anything (why on earth, anyone would want to deal with files >> and OS, if he could just run code which already in memory?). >> > > > > -- > Best regards, > Igor Stasenko.

Oct. 25, 2013

Re: [Pharo-dev] ensureCreateDirectory?

by Norbert Hartl

Am 25.10.2013 um 10:11 schrieb Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > So action=create object=directory > you want to be sure that you create a directory? > What if it already exists? > Since you want to be sure to create, will you erase and re-create? > You see the kind of misunderstanding this could create... > IOW, self ensureCreateMisunderstanding > +1 I didnât like it in the first place. It is just confusing. And probably an example how hard it can be if two or more non-native speaker try to find something that makes sense. Norbert > > 2013/10/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Consistency > ensureActionObject > > ensureCreateDirectory > ensureCreateFile > > We discuss a lot with camillo when we did it and I think that this is good right now. > > > Out of curiosity, what was the motivation behind Issue 10924: Simplifying > > ensure* and create protocol? > > > > For me #ensureCreateDirectory is less intention revealing than > > #ensureDirectory because the "ensure" means "create only if necessary", not > > "definitely create" a directory. What am I missing? Thanks. > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: http://forum.world.st/ensureCreateDirectory-tp4716925.html > > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > >

Oct. 25, 2013

Re: [Pharo-dev] ensureCreateDirectory?

by Nicolas Cellier

So action=create object=directory you want to be sure that you create a directory? What if it already exists? Since you want to be sure to create, will you erase and re-create? You see the kind of misunderstanding this could create... IOW, self ensureCreateMisunderstanding 2013/10/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Consistency > ensureActionObject > > ensureCreateDirectory > ensureCreateFile > > We discuss a lot with camillo when we did it and I think that this is good > right now. > > > Out of curiosity, what was the motivation behind Issue 10924: Simplifying > > ensure* and create protocol? > > > > For me #ensureCreateDirectory is less intention revealing than > > #ensureDirectory because the "ensure" means "create only if necessary", > not > > "definitely create" a directory. What am I missing? Thanks. > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/ensureCreateDirectory-tp4716925.html > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > >

Oct. 25, 2013

Re: [Pharo-dev] UpdatingMenuMorph

by Camille Teruel

On 25 oct. 2013, at 09:50, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I was only use in stupid halos and the code is not really good. > Now if somebody does a pass on it we could readd it to the basis. (right now I just put it back for the sound package - but the sound package shows it agesâ¦ the code looks strange). > > floatPrecisionForDecimalPlaces: places > "Answer the floatPrecision that corresponds to the given number of decimal places" > > ^ places caseOf: > {[0]->[1] . > [1]->[0.1] . > [2]->[0.01] . > [3]->[0.001] . > [4]->[0.0001] . > [5]->[0.00001] . > [6]->[0.000001] . > [7]->[0.0000001] . > [8]->[0.00000001] . > [9]->[0.000000001]} > otherwise: > [(10.0 raisedTo: places negated) asFloat] Ha yes, I remember this one :D ! > > " > (0 to: 6) collect: [:i | Utilities floatPrecisionForDecimalPlaces: i] > (-10 to: 20) collect: [:i | Utilities floatPrecisionForDecimalPlaces: i] > " > > like decimalPlaces: > > valueFromContents > "Return a new value from the current contents string." > > format = #symbol ifTrue: [^ lastValue]. > format = #string ifTrue: [^ contents]. > ^ self class evaluatorClass evaluate: contents > > setPrecision > "Allow the user to specify a number of decimal places. This UI is > invoked from a menu. Nowadays the precision can be set by simple > type-in, making this menu approach mostly obsolete. However, it's > still useful for read-only readouts, where type-in is not allowed." > | aMenu | > aMenu := UIManager default > newMenuIn: self for: self. > aMenu > addTitle: ('How many decimal places? (currently {1})' translated format: {self decimalPlaces}). > 0 > to: 5 > do: [:places | aMenu > add: places asString > target: self > selector: #setDecimalPlaces: > argument: places]. > aMenu popUpInWorld > > > > > >> >> On 24 oct. 2013, at 22:07, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >>> What happened to it and why? I'm porting TWM to 3.0 and didn't find any >>> mention of removal on the dev or issue mailing list... Thanks. >> >> It was removed in 30507. >> The decision to remove it has been made during the august sprint. >> I just remember that I did the job. >> Does someone remember why? >> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> View this message in context: http://forum.world.st/UpdatingMenuMorph-tp4716928.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >>> >> >

Oct. 25, 2013

Re: [Pharo-dev] UpdatingMenuMorph

by StÃ©phane Ducasse

I was only use in stupid halos and the code is not really good. Now if somebody does a pass on it we could readd it to the basis. (right now I just put it back for the sound package - but the sound package shows it agesâ¦ the code looks strange). floatPrecisionForDecimalPlaces: places "Answer the floatPrecision that corresponds to the given number of decimal places" ^ places caseOf: {[0]->[1] . [1]->[0.1] . [2]->[0.01] . [3]->[0.001] . [4]->[0.0001] . [5]->[0.00001] . [6]->[0.000001] . [7]->[0.0000001] . [8]->[0.00000001] . [9]->[0.000000001]} otherwise: [(10.0 raisedTo: places negated) asFloat] " (0 to: 6) collect: [:i | Utilities floatPrecisionForDecimalPlaces: i] (-10 to: 20) collect: [:i | Utilities floatPrecisionForDecimalPlaces: i] " like decimalPlaces: valueFromContents "Return a new value from the current contents string." format = #symbol ifTrue: [^ lastValue]. format = #string ifTrue: [^ contents]. ^ self class evaluatorClass evaluate: contents setPrecision "Allow the user to specify a number of decimal places. This UI is invoked from a menu. Nowadays the precision can be set by simple type-in, making this menu approach mostly obsolete. However, it's still useful for read-only readouts, where type-in is not allowed." | aMenu | aMenu := UIManager default newMenuIn: self for: self. aMenu addTitle: ('How many decimal places? (currently {1})' translated format: {self decimalPlaces}). 0 to: 5 do: [:places | aMenu add: places asString target: self selector: #setDecimalPlaces: argument: places]. aMenu popUpInWorld > > On 24 oct. 2013, at 22:07, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > >> What happened to it and why? I'm porting TWM to 3.0 and didn't find any >> mention of removal on the dev or issue mailing list... Thanks. > > It was removed in 30507. > The decision to remove it has been made during the august sprint. > I just remember that I did the job. > Does someone remember why? > >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/UpdatingMenuMorph-tp4716928.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >

Oct. 25, 2013

Re: [Pharo-dev] ensureCreateDirectory?

by StÃ©phane Ducasse

Consistency ensureActionObject ensureCreateDirectory ensureCreateFile We discuss a lot with camillo when we did it and I think that this is good right now. > Out of curiosity, what was the motivation behind Issue 10924: Simplifying > ensure* and create protocol? > > For me #ensureCreateDirectory is less intention revealing than > #ensureDirectory because the "ensure" means "create only if necessary", not > "definitely create" a directory. What am I missing? Thanks. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/ensureCreateDirectory-tp4716925.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Oct. 25, 2013