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

Re: [Pharo-dev] PharoNOS

by Torsten Bergmann

> Isn't it what Pharocloud is all about? ;) Partly because in enterprise environments you may want to run apps in intranet/own network only. Bye T.

Oct. 17, 2014

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

by Tudor Girba

But why is Set being affected by hash? Hash is never guaranteed to be unique. Set should be affected by equality. Doru On Fri, Oct 17, 2014 at 9:34 AM, Max Leske <maxleske(a)gmail.com> wrote: > > On 17.10.2014, at 02:46, Ben Coman <btc(a)openInWorld.com> wrote: > > Richard Sargent wrote: > > Eliot Miranda-2 wrote > > On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent < > > richard.sargent@ > > wrote: > One of the best things about Smalltalk is how easily we can say what we > mean. I think you would be better off creating a method named something > like > #hasSameEffectAs: to answer what you are presently using #= to do, and > change #= to answer the, in my opinion, more sensible "is the same as" > that > we conventionally think of #= meaning. > > But that's the point. #= has to mean something and having it mean #== > isn't useful, so one has to choose some value-based semantic for > CompiledMethod>>#= and the one that's there is useful. Defining what #= > means for some value type is far easier than defining what it might mean > for something as complex as a CompiledMethod. The definition in > Squeak/Pharo has been useful to me in implementing a closure-based system, > so I'm unapologetic about the current definition. It is a good one but it > doesn't preclude defining others. > > An interesting response. You ignored the point that e.g. #hasSameEffectAs: > provides greater clarity and add an argument against something I didn't > say. > I also don't think defining equality for a CompiledMethod is particularly > difficult. If I were to recompile a method's source code, I would get a new > instance of a CompiledMethod that would, in my opinion, be equal to the one > already installed in the class (and perhaps cached in the VM's > optimizations). So one would be able to say that we would not replace an > existing CompiledMethod with an equal one. The current implementation of #= > has no such characteristic, since it proclaims a CompiledMethod named #a to > be equal to one named #z. > > > @Richard > > That doesn't seem to be a good example for what your trying to say. > Given... > > [1] SomeClass>>a "original instance" > ^1 > > [2] SomeClass>>a "recompiled instance" > ^1 > > [3] SomeClass>>z > ^1 > > ...you seem to be saying that its useful to know if [1]=[2], > but imply that is invalidated by [2]=[3] ? > > But [1]=[2] remains true, and just as useful for your example. > > > @Max > > I guess to call it a bug, you bumped into a different use case > where [2]=[3] is problematic. Can you describe that? > > > Well, not problematic. Once you accept that neither selector nor class are > part of a CompiledMethod it is obvious that two instances with the same > byte codes produce the same hash. > > The actual problem is more one of understanding and use. The following > code answers a collection with the CompiledMethods Collection>>add:, > Collection>>do: and Collection>>remove:ifAbsent: > > Collection methods select: #isAbstract. > > > All three CompiledMethods are implemented as â^ self > subclassResponsibilityâ, so they have the same byte codes. Now, if you take > that collection and make a set out of it youâll lose Collection>>do: since > #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because > the number of arguments is calculated into the hash (actually the > CompiledMethod header is). > > So, as long as you think of CompiledMethods as objects that have a name, > it looks like a bug and in my opinion this behaviour is something that > messes with the mind of newcomers. Just a (silly) idea: something like a > CompiledMethodWrapper might solve the problem (at least from the user > perspective; everything is slightly different from the VM perspective :) ), > as it could hold on to the class and the selector independently of the > actual CompiledMethod. > > In the end however, one doesnât work with compiled methods a lot and the > hash situation is unlikely to cause a lot of problems (people working with > CompiledMethod usually know what they are doing). > > Cheers, > Max > > > > cheers -ben > > > The blue book say #= means "Answer whether the receiver and the argument > represent the same component." The current implementation does so only for > some, in my opinion, counter-intuitive definition of "same component". > -- > View this message in context: > http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p478… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 17, 2014

Re: [Pharo-dev] Playground and its current usability in Pharo4.0 Latest update: #40307

by Esteban Lorenzano

> On 17 Oct 2014, at 02:40, Ben Coman <btc(a)openInWorld.com> wrote: > > Sven Van Caekenberghe wrote: >> On 16 Oct 2014, at 22:34, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> On Thu, Oct 16, 2014 at 10:23 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> I too miss the old workspace sometimes. Mostly for "printIt". Playgrounds printIt-popup is good, but sometimes I want exactly that: "print it". >>> On "Esc", the popup closes , but the code is still selected. Most of the time I >>> want to go on typing, but first I have to unselect the code. >>> >>> Suggestions: >>> on "Esc" close the popup and unselect the current selection >>> >>> Good point. >> +1 >>> on "Enter" insert the printIt-result. >>> >>> Indeed, this is something I thought of, too. However, I am not convinced that the frequency of needing to insert the result of "print it" warrants a shortcut > > I often have a few lines of snippets listed in a Workspace that I want to compare the results, or copy/paste the lot to some documentation. > I was thinking of asking for a <pin> icon/button, but inserting as text is a better idea. > >>> that can be so easily use (i.e., Enter can be used also for adding a line). Right now, if you want to insert, you do Cmd+c, Esc, Cmd+v. > > I would go for <space> rather than <enter>, since intuitively that keeps you on the same line. but also enter means âacceptâ in everybodyâs brain (and other tools prefer that over space). anyway, +1 to thatâ¦ is something that I really miss. Esteban > > >> I also don't think 'Print It' is not that common, and if you use it you want the output to be in a comment anyway so the syntax highlighting doesn't make everything red. > > When the result is inserted, surrounding it by comment quotes is a good idea. > > cheers -ben > > >> I also wanted to add that the whole idea of GT-Tools is to do a lot and even more powerful things based on a few simple concepts. >> We are currently making lots of small usability changes, which is all good, but we have to guard the simplicity. > >

Oct. 17, 2014

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

by Max Leske

> On 17.10.2014, at 02:46, Ben Coman <btc(a)openInWorld.com> wrote: > > Richard Sargent wrote: >> Eliot Miranda-2 wrote >>> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent < >>> richard.sargent@ >>>> wrote: >>>> One of the best things about Smalltalk is how easily we can say what we >>>> mean. I think you would be better off creating a method named something >>>> like >>>> #hasSameEffectAs: to answer what you are presently using #= to do, and >>>> change #= to answer the, in my opinion, more sensible "is the same as" >>>> that >>>> we conventionally think of #= meaning. >>>> >>> But that's the point. #= has to mean something and having it mean #== >>> isn't useful, so one has to choose some value-based semantic for >>> CompiledMethod>>#= and the one that's there is useful. Defining what #= >>> means for some value type is far easier than defining what it might mean >>> for something as complex as a CompiledMethod. The definition in >>> Squeak/Pharo has been useful to me in implementing a closure-based system, >>> so I'm unapologetic about the current definition. It is a good one but it >>> doesn't preclude defining others. >> An interesting response. You ignored the point that e.g. #hasSameEffectAs: >> provides greater clarity and add an argument against something I didn't say. >> I also don't think defining equality for a CompiledMethod is particularly >> difficult. If I were to recompile a method's source code, I would get a new >> instance of a CompiledMethod that would, in my opinion, be equal to the one >> already installed in the class (and perhaps cached in the VM's >> optimizations). So one would be able to say that we would not replace an >> existing CompiledMethod with an equal one. The current implementation of #= >> has no such characteristic, since it proclaims a CompiledMethod named #a to >> be equal to one named #z. > > @Richard > > That doesn't seem to be a good example for what your trying to say. > Given... > > [1] SomeClass>>a "original instance" > ^1 > > [2] SomeClass>>a "recompiled instance" > ^1 > > [3] SomeClass>>z > ^1 > > ...you seem to be saying that its useful to know if [1]=[2], > but imply that is invalidated by [2]=[3] ? > > But [1]=[2] remains true, and just as useful for your example. > > > @Max > > I guess to call it a bug, you bumped into a different use case > where [2]=[3] is problematic. Can you describe that? Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash. The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent: Collection methods select: #isAbstract. All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is). So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod. In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing). Cheers, Max > > > cheers -ben > > >> The blue book say #= means "Answer whether the receiver and the argument >> represent the same component." The current implementation does so only for >> some, in my opinion, counter-intuitive definition of "same component". >> -- >> View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p478… >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 17, 2014

Re: [Pharo-dev] Playground and its current usability in Pharo4.0 Latest update: #40307

by Esteban Lorenzano

> On 16 Oct 2014, at 22:58, Torsten Bergmann <astares(a)gmx.de> wrote: > > Tudor wrote: >> Indeed. This was a discussion I wanted to spawn as well. I would prefer to change the name from Workspace to Playground in the World Menu. The reason is >that the Playground is such a distinct departure from the Workspace that it deserves a different name. > > I do not think it is a departure from the Workspace concept. > > Therefore I would keep "Workspace" for the menu item name and the window name. It would be enough if the initial > tab is called "Playground" because one can play in the code pane (or do serious stuff). > > This way we would keep up with a known concept (also from other IDE's), it meets what people would expect and > no books would have to be rewritten ;) > > BTW: Squeak had a goodie with something similar back in the days (cant remember the name). It was neat as one > could assemble different objects and different object representations in one navigateable window. > > >>> I would suggest to use the well known order "Cut","Copy","Paste". >> Thanks for noticing. This will be fixed. > > Thanks! > >> Indeed, we had a debate about the name. I proposed the solution 3b you mention, but it was decided >> that it would be too confusing to change the Cmd+i action at this time, and we chose "Go" to be >> the name of the action that is mapped on Cmd+g. > > Here we agree - I would have choosen 3b as well. Decided by whom? Did I miss the discussion in the > list or was it offlist? basically, it was decided by me (and the course of the actionsâ¦ I did not forced anyone :P). My reasons remain but I have to say: 1) Survey reflected a clear position towards what now is called 3b 2) We are still making testsâ¦ nothing is written in stone and we are looking for better ways to do thingsâ¦ so that can change again (and again, and again, and like that until we are happy) > >>> ...icons... >> This is a known issue and we will look at it soon. > > Sounds good. > >> At the moment, GT is an external project and the contributions should happen directly in its repository. > > Then please add me to the repo. Still the process is unclear - will I still provide a slice with > issue number or will I change the config. > > It is not very lucky that this process was started (without discussion/announcement/description first > and only for specific packages). > > Thx > T. >

Oct. 17, 2014

Re: [Pharo-dev] Playground and its current usability in Pharo4.0 Latest update: #40307

by Esteban Lorenzano

> On 16 Oct 2014, at 21:01, phil(a)highoctane.be wrote: > > I'd like to have the old workspace as it is for quick commands and as a kind of CLI where I do not need all the noise of the right part of the playground. > > And the playground for what it is meant to do. > > These two things are *not* for the same use case. yes, they should. If they are not then we have an error somewhere. Could you elaborate a bit on why they are not fulfilling same usecase for you? cheers, Esteban ps: In the future (not in pharo4, certainly), old workspace and inspectors will be removed from environment, so we need to make sure the new ones can do the job correctly. > > > âPhil

Oct. 17, 2014

Re: [Pharo-dev] PharoNOS

by kilon alios

so the advantage of using this is that is a slim down linux distro with Pharo included ? Why not just download a small linux distro and install Pharo ? On Fri, Oct 17, 2014 at 10:14 AM, mikefilonov <mikefilonov(a)gmail.com> wrote: > Thank you Torsten. Great ideas :) I made a to-do list for this project not > to > forget anything > https://trello.com/b/JXtcf2Ye/pharonos > > >Yes, I have the following quick setup scenario in mind: downlod the ISO, > start a virtual computer > >with it (in virtualization software or on a cloud server). Use the Pharo > based setup wizard (see above) > >to setup keyboard layout, give a fixed IP, adjust the clock, ... > >and download a premade Seaside (or other webframework image) from CI. Now > run on port 80, configure >another > >port and give a name to the machine in the network. This way one could > easily setup virtualized > >network machines to provide network delivered applications. > > Isn't it what Pharocloud is all about? ;) > > > > > -- > View this message in context: > http://forum.world.st/PharoNOS-tp4784982p4785075.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Oct. 17, 2014

Re: [Pharo-dev] PharoNOS

by mikefilonov

Thank you Torsten. Great ideas :) I made a to-do list for this project not to forget anything https://trello.com/b/JXtcf2Ye/pharonos >Yes, I have the following quick setup scenario in mind: downlod the ISO, start a virtual computer >with it (in virtualization software or on a cloud server). Use the Pharo based setup wizard (see above) >to setup keyboard layout, give a fixed IP, adjust the clock, ... >and download a premade Seaside (or other webframework image) from CI. Now run on port 80, configure >another >port and give a name to the machine in the network. This way one could easily setup virtualized >network machines to provide network delivered applications. Isn't it what Pharocloud is all about? ;) -- View this message in context: http://forum.world.st/PharoNOS-tp4784982p4785075.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 17, 2014

Re: [Pharo-dev] Mysteries of the compiler

by Eliot Miranda

On Thu, Oct 16, 2014 at 11:53 PM, Marcus Denker <marcus.denker(a)gmail.com> wrote: > On 16 Oct 2014 at 22:07:03, Nicolai Hess (nicolaihess(a)web.de) wrote: > > 2014-10-16 17:40 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> >> >> >> While in the write we need to mark: >> >> >> >> lookupVariableForWrite: aVariableNode >> >> >> >> | var | >> >> >> >> var := scope lookupVar: aVariableNode name. >> >> >> >> var ifNil: [^var]. >> >> var isSpecialVariable ifTrue: [ self storeIntoSpecialVariable: >> aVariableNode ]. >> >> var isWritable ifFalse: [ self storeIntoReadOnlyVariable: >> aVariableNode ]. >> >> >> >> var isTemp ifTrue: [ >> >> "when in a loop, all writes escape" >> >> scope outerScope isInsideOptimizedLoop ifTrue: [ var >> markEscapingWrite ]. >> >> "else only escaping when they will end up in different >> closures" >> >> (var scope outerNotOptimizedScope ~= scope >> outerNotOptimizedScope) >> >> ifTrue: [ var markEscapingWrite]]. >> >> ^var >> >> >> >> >> >> I checked that all Opal tests that are failing are actually testing >> wrong, and I double checked >> >> that all those methods are now compiled like with the old old compilerâ¦ >> >> Now recompilng the image. >> > >> > Hmmâ¦ nopeâ¦. something wrong. >> > >> >> the âouterScopeâ was wrong. >> >> So without that, I can recompile the image and your example is compiled >> without temp vectorsâ¦ >> >> Marcus >> > > good! > I'll open an issue on fogbugz and create a slice with your changes. > > about reordering of tempvars: > It would be nice if the order preserves, but I think we can live with it. > > Yes, we should order them. But keep in mind that this does not mean that > you > > can access them via âat: indexâ. The index is âvirtualâ, so var3 can be > actually var2, > > because the *real* var2 lives together with var1 in a tempVector (which is > now var1). > > Knowledge has to come from somewhereâ¦ e.g. the DebuggerMethodMap builds up > > a description, while we (for now) just delegate to the AST (+scopes + > semantic vars). > > this means that > > #tempAt: > > sees always the real world. e.g. a method with 3 vars where they are all > in the tempVector, > > tempAt:2 will raise an error. > > namedTempAt: does what the old one did. > Not quite. What namedTempAt:[put:] do is access the temps in the order they appear in the list answered by ContextPart>>tempNames which is self debuggerMap tempNamesForContext: self. This is a flattened list that includes both direct and indirect temps. This is also the list that the Squeak debugger uses to populate the bottom-right context inspector in the debugger. namedTempAt:[put:] matches tempAt:[put:] until you get to an indirect temp. In a method the Squeak compiler always puts the indirect temps after all the direct temps, so the two match until the first indirect temp. But in a closure the situation is potentially much more complex because indirection vectors can be part of a closure's copied values, so it may have any number of indirection vectors copied form outer scopes, its own local direct temps and its own local indirect temps. The copied values get pushed after the arguments and before the local temps. So the ordering potentially gets complicated. This now can get confused in the Opal case with the changing order, which > we should fix. > > (and yes, we should check how much slower the AST bases scheme is for > accessing > > temps by offset... we could cache a representation similar to what the old > DebuggerMethodMap > > does). > Or use DebuggerMethodMap, rewriting the code to make it more comprehensible... Why reinvent the wheel? > > Although there is an issue with the debugger: > 14058 <https://pharo.fogbugz.com/default.asp?14058> Inconsistent > information in debugger > I solved that one by using tempvar names instead if the index, but > this has another issue (sometimes the last (or most nested) tempvar is > always nil). > > The real error is, EyeDebuggerContextInspector does recognizes if the > index changes > (somewhere in EyeDebuggerContextInspector>>#updateList it > compares the new elements (with new indices) with the old elements list > and skips the update) > > Okâ¦ that could be fixed with ordered temp names? > > Marcus > > > > -- best, Eliot

Oct. 17, 2014

Re: [Pharo-dev] Mysteries of the compiler

by Marcus Denker

On 16 Oct 2014 at 22:07:03, Nicolai Hess (nicolaihess(a)web.de) wrote: 2014-10-16 17:40 GMT+02:00 Marcus DenkerÂ <marcus.denker(a)inria.fr>: >> >> While in the write we need to mark: >> >> lookupVariableForWrite: aVariableNode >> >>Â Â Â | var | >> >>Â Â Â var := scope lookupVar: aVariableNode name. >> >>Â Â Â var ifNil: [^var]. >>Â Â Â var isSpecialVariable ifTrue: [ self storeIntoSpecialVariable: aVariableNode ]. >>Â Â Â var isWritable ifFalse: [ self storeIntoReadOnlyVariable: aVariableNode ]. >> >>Â Â Â var isTemp ifTrue: [ >>Â Â Â Â Â Â Â "when in a loop, all writes escape" >>Â Â Â Â Â Â Â scope outerScope isInsideOptimizedLoop ifTrue: [ var markEscapingWrite ]. >>Â Â Â Â Â Â Â "else only escaping when they will end up in different closures" >>Â Â Â Â Â Â Â (var scope outerNotOptimizedScope ~= scope outerNotOptimizedScope) >>Â Â Â Â Â Â Â Â Â Â Â ifTrue: [ var markEscapingWrite]]. >>Â Â Â ^var >> >> >> I checked that all Opal tests that are failing are actually testing wrong, and I double checked >> that all those methods are now compiled like with the old old compilerâ¦ >> Now recompilng the image. > > Hmmâ¦ nopeâ¦. something wrong. > the âouterScopeâ was wrong. So without that, I can recompile the image and your example is compiled without temp vectorsâ¦ Â Â Â Â Marcus good! I'll open an issue on fogbugz and create a slice with your changes. about reordering of tempvars: It would be nice if the order preserves, but I think we can live with it. Yes, we should order them. But keep in mind that this does not mean that you can access them via âat: indexâ. The index is âvirtualâ, so var3 can be actually var2, because the *real* var2 lives together with var1 in a tempVector (which is now var1). Knowledge has to come from somewhereâ¦ e.g. the DebuggerMethodMap builds up a description, while we (for now) just delegate to the AST (+scopes + sematic vars). this means thatÂ #tempAt: sees always the real world. e.g. a method with 3 vars where they are all in the tempVector, tempAt:2 will raise an error. namedTempAt: does what the old one did. This now can get confused in the Opal case with the changing order, which we should fix. (and yes, we should check how much slower the AST bases scheme is for accessing temps by offset... we could cache a representation similar to what the old DebuggerMethodMap does). Although there is an issue with the debugger: 14058Â Inconsistent information in debugger I solved that one by using tempvar names instead if the index, but this has another issue (sometimes the last (or most nested) tempvar is always nil). The real error is, EyeDebuggerContextInspector does recognizes if the index changes (somewhere in EyeDebuggerContextInspector>>#updateList it compares the new elements (with new indices) with the old elements list and skips the update) Okâ¦ that could be fixed with ordered temp names? Â Marcus

Oct. 17, 2014