- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] PharoNOS

by Torsten Bergmann

Hi Mike, tried to swap the image using the following procedure: 1. Run the following code to download latest Pharo 4.0 ZnClient new url: 'http://files.pharo.org/image/40/latest.zip'; downloadTo: '/mnt/universe/pharo-image/latest.zip'. ZipArchive extractAllIn: '/mnt/universe/pharo-image/latest.zip'. and extract to "/mnt/universe/pharo-image/" 2. Now I wanted to change /mnt/universe/image file name to point to the new image. Unfortunately I can not write or delete/recreate this file from Pharo's file browser. Can you provide the build script for the ISO also on GitHub? Thx T.

Oct. 17, 2014

Re: [Pharo-dev] OrderedDictionary and new tools, Seaside...

by Sven Van Caekenberghe

On 16 Oct 2014, at 15:01, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On 16 Oct 2014, at 14:55, phil(a)highoctane.be wrote: >> >> I am using OrderedDictionary in quite a few places. >> >> Now, I have to steam a lot of extra methods from Dictionary as the GTInspector doesn't display things properly, nor the WAInspector and its subclasses out of the box. >> NeoJSON same story, as Ston etc. >> >> OrderPreservingDictionary is quite useful. >> Yes, there is GRSmallDictionary but it also has the same issues. >> >> OrderPreservingDictionary is at least a Collection where GRSmallDictionary is a GRObject. >> >> What would be the best strategy here? >> >> We need such an ordered map all the time, it deserves a bit better. >> >> Opinions? >> > > In Pharo4, I copied OrderPreservingDictionary to OrderedDictionary. > (to have a default one in the image without disturbing clients of OrderPreservingDictionary) > > This should be improved if it something is missing. > > Marcus https://pharo.fogbugz.com/f/cases/14260/Add-gt-inspector-views-to-Ordered-I…

Oct. 17, 2014

Re: [Pharo-dev] PharoNOS

by Rafael Luque

Then, PharoNOS does not mean No Operating System, but minimun operating system? A few days ago I answered in this list about Smalltalk-based unikernels, similar to Mirage OS (http://www.openmirage.org/) Do you think PharoNOS can evolve into this kind of tool? 2014-10-17 10:28 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > I see, I dont have experience with TinyCore linux, but I do have > experience with puppy linux which I really liked and used several times on > my older pcs. Interest concept , good work :) > > Actually puppy linux is similar to what you do, in the sense that it uses > its own programming language , genie > > > https://wiki.gnome.org/action/show/Projects/Genie?action=show&redirect=Genie > > On Fri, Oct 17, 2014 at 10:59 AM, mikefilonov <mikefilonov(a)gmail.com> > wrote: > >> Yes, the idea of PharoNOS is to have the Smalltalk-only environment with >> as >> little external stuff as possible. >> >> Current PharoNOS implementation based on TinyCore Linux - the smallest >> Linux >> distro - in order to have the smallest possible system footprint. >> >> >Why not just download a small linux distro and install Pharo ? >> >> Well, basically this what PharoNOS is :) >> >> >> >> -- >> View this message in context: >> http://forum.world.st/PharoNOS-tp4784982p4785089.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >

Oct. 17, 2014

Re: [Pharo-dev] PharoNOS

by kilon alios

I see, I dont have experience with TinyCore linux, but I do have experience with puppy linux which I really liked and used several times on my older pcs. Interest concept , good work :) Actually puppy linux is similar to what you do, in the sense that it uses its own programming language , genie https://wiki.gnome.org/action/show/Projects/Genie?action=show&redirect=Genie On Fri, Oct 17, 2014 at 10:59 AM, mikefilonov <mikefilonov(a)gmail.com> wrote: > Yes, the idea of PharoNOS is to have the Smalltalk-only environment with as > little external stuff as possible. > > Current PharoNOS implementation based on TinyCore Linux - the smallest > Linux > distro - in order to have the smallest possible system footprint. > > >Why not just download a small linux distro and install Pharo ? > > Well, basically this what PharoNOS is :) > > > > -- > View this message in context: > http://forum.world.st/PharoNOS-tp4784982p4785089.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Oct. 17, 2014

Re: [Pharo-dev] PharoNOS

by mikefilonov

Yes, the idea of PharoNOS is to have the Smalltalk-only environment with as little external stuff as possible. Current PharoNOS implementation based on TinyCore Linux - the smallest Linux distro - in order to have the smallest possible system footprint. >Why not just download a small linux distro and install Pharo ? Well, basically this what PharoNOS is :) -- View this message in context: http://forum.world.st/PharoNOS-tp4784982p4785089.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 17, 2014

Re: [Pharo-dev] PharoNOS

by Damien Cassou

On Fri, Oct 17, 2014 at 3:47 AM, mikefilonov <mikefilonov(a)gmail.com> wrote: > Hm, just now get the idea to run Image chooser if > default image failed. Is it available on linux? > you have the pharo launcher that let's you download images from the web (be it on jenkins, on files.pharo.org, or on your own server) -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Oct. 17, 2014

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

by Max Leske

> On 17.10.2014, at 09:37, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > But why is Set being affected by hash? Hash is never guaranteed to be unique. Set should be affected by equality. Well, actually itâs both #hash and #=. First the set tries to find a suitable place for the element using the elements hash. If that place is already taken it then checks equality. Since the equality definition is mostly the same (same literals, same byte codes etc.), the second element is rejected because itâs already in the set. > > Doru > > On Fri, Oct 17, 2014 at 9:34 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > >> On 17.10.2014, at 02:46, Ben Coman <btc(a)openInWorld.com <mailto:btc@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… <http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p478…> >>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>. > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

Oct. 17, 2014

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