May 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Playground inspector and the self variable

by Esteban A. Maringolo

2015-05-29 12:36 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > Indeed, this part of the inspector will be revisited for Pharo 5. Good. I'm sure this can be backported easily ;) > But, what exactly do you mean by " I just want to select it to run an > expression where self refers to the inspected object"? I have the strong habit of running expressions (it is, send messages) to objects directly in the inspector, in the case of the example array, I can fiddle selecting the different elements in the array and finally select the array itself ("self") to select as the receiver. I expect to write these expression on the pane of the right, even when I could do it on the pane of the left. I hope I explained myself. :) Esteban A. Maringolo

May 29, 2015

Re: [Pharo-users] Playground inspector and the self variable

by Tudor Girba

Hi, Indeed, this part of the inspector will be revisited for Pharo 5. But, what exactly do you mean by " I just want to select it to run an expression where self refers to the inspected object"? Cheers, Doru On Fri, May 29, 2015 at 5:30 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Is it okay that the Playground's inspector drills down on the self > variable indefinitely? > > It is... #(1 2 3) "Do it and go" will result in an Array being > inspected, if I click on "self" it will open a new inspector on the > side on the same object, and this can as deep as you want. > > I would block that from happening, in the raw tab, the "self" variable > shouldn't drill down, sometimes I just want to select it to run an > expression where self refers to the inspected object. > > Does it make sense what I propose? Or is there any use case where > drilling down recursively ad infinutum is useful? > > > Regards! > > Esteban A. Maringolo > > -- www.tudorgirba.com "Every thing has its own flow"

May 29, 2015

Playground inspector and the self variable

by Esteban A. Maringolo

Is it okay that the Playground's inspector drills down on the self variable indefinitely? It is... #(1 2 3) "Do it and go" will result in an Array being inspected, if I click on "self" it will open a new inspector on the side on the same object, and this can as deep as you want. I would block that from happening, in the raw tab, the "self" variable shouldn't drill down, sometimes I just want to select it to run an expression where self refers to the inspected object. Does it make sense what I propose? Or is there any use case where drilling down recursively ad infinutum is useful? Regards! Esteban A. Maringolo

May 29, 2015

Re: [Pharo-users] Is it always needed to redefine #hash message when you redefine #= message?

by Alexandre Bergel

Wow, compelling example! Alexandre > On May 29, 2015, at 12:33 PM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > Also implied, but seldom stated, is that all values used in = and hash must only be set at creation, never after. > The reason is the same, keeping hashed collection usage sane; > p := Point x: 3 y: 2. > Set add: p. > "Imaginary method" > p setX: 2. > Set includes: p -> false > > Cheers, > Henry > >> On 26 May 2015, at 9:11 , Julien Delplanque <julien(a)tamere.eu> wrote: >> >> Thanks, I understand now :) >> >> On 26/05/15 21:06, Carlo wrote: >>> Hi >>> >>> Any two objects that are = must answer the same #hash value. >>> The hash is used in any of the HashedCollection's for storage and then to find the exact element the #= is used. >>> If 2 objects are #= but their hash values are different the HashedCollection will not find the correct storage slot and you will have undefined behaviour when looking up objects. >>> >>> Out of interest, Andres Valloud wrote a whole book on 'Hashing in Smalltalk' (http://www.lulu.com/content/1455536) >>> >>> Also the Javadoc comments are pretty good in explaining the usage: >>>> The general contract of hashCode is: >>>> Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application. >>>> If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result. >>>> It is not required that if two objects are unequal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hash tables. >>>> As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. >>> Cheers >>> Carlo >>> >>> On 26 May 2015, at 8:45 PM, Julien Delplanque <julien(a)tamere.eu> wrote: >>> >>> The subject of this mail is exactly my question. >>> >>> I came to this question by looking at Object>>#= message implementation. >>> >>> """ >>> = anObject >>> "Answer whether the receiver and the argument represent the same >>> object. If = is redefined in any subclass, consider also redefining the >>> message hash." >>> >>> ^self == anObject >>> """ >>> >>> When do we need to redefine #hash message? >>> >>> Is it the right way to implement equality between two objects or is there another message that I should override? >>> >>> Regards, >>> Julien >>> >>> >>> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 29, 2015

Re: [Pharo-users] Problem with debugging methods

by Juraj Kubelka

Sure, next time it happens, I will do it. Thanks, Juraj > On May 29, 2015, at 03:23, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Can you send my an image saved in that state? > >> On 28 May 2015, at 17:27, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: >> >> Hi, >> >> regularly I cannot debug methods because nil does not understand #compilationContext in method >> RBMessageNode>>isInlined >> self methodNode compilationContext â¦ >> >> Do you face this problem? I have not found related bug on FogBugz. >> >> Thanks, >> Juraj >> >> Pharo4.0 (Moose image 5.1) >> Latest update: #40613 >> >> <Screen Shot 2015-05-28 at 12.25.18.png> > >

May 29, 2015

Re: [Pharo-users] How to move data between Pharo versions

by PBKResearch

Hello all Thanks for the comments. I should have made myself clearer in my second post (moral: donât post after midnight!). The original query related to a simple case, which I had solved, but which alerted me to the problem of incompatible versions in Fuel. The next stage of my work (still in planning, hence some vagueness in description) will involve storing objects long term on disk, presumably in serialized form, and I am still considering which serializer to use. I shall be creating large numbers of domain objects â many thousands, possibly running to millions. The instance variables of the objects will be standard Smalltalk objects â strings, arrays, ordered collections, dictionaries â and possibly other domain objects. Each object will be identified by a unique string. In any particular exercise I want to have available in the image only the objects relevant to that exercise. The proposal is to have a database on disk, possibly using PunQLite or Voyage, where the keys are the object identifiers and the database entries are serialized versions of the objects. As references to the domain objects are encountered in the input, the relevant object will be materialized from the database in the image. If I use Fuel to serialize, and if I decide to move to Pharo 5, I may have the problem of converting all the entries in the database to a new version of Fuel. If I use STON, I think there should not be a problem of version changes. I have as yet no idea whether there is any advantage for either serializer in terms of efficiency, either space or time, but at the moment I am inclined to start with STON. If the serializing and materializing are put in a separate section, it should be possible to switch later without too much effort, if it seems desirable. If there is any obvious idiocy in these proposals, please let me know. Otherwise, thanks to all for your helpful comments. Peter Kenny From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Mariano Martinez Peck Sent: 29 May 2015 02:19 To: Any question about pharo is welcome Subject: Re: [Pharo-users] How to move data between Pharo versions This thread may help you: http://forum.world.st/Fuel-version-td4823170.html Cheers, On Thu, May 28, 2015 at 9:19 PM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com> > wrote: On Fri, May 29, 2015 at 7:17 AM, Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com> > wrote: > Peter Kenny wrote >> I will have to convert all my files to the new version? As far as I can >> see, I could not do that using >> the device you suggest > > The thing is that it's only the serialization that is tied to a Fuel > version, so the workflow is (and I've done this to port my data from Pharo > 3.0 to Pharo 4.0 and then to Pharo 5.0): > > 1. In the older image with the data, upgrade Fuel to the latest version that > will load in that Pharo `ConfigurationOfFuel project stableVersion load` This does not cater for "storing object structures long term on disk." I guess the workaround is that the image used to store the objects needs to archive near the fuel files. But you'd need to be careful not to save it once you upgraded fuel versions. > 2. Serialize the data > If the Fuel version in #1 is the one that comes with the newer Pharo you're > porting to, you're done. You can now materialize in the newer Pharo version. > Otherwise... > 3. In the newer Pharo > a. Downgrade Fuel e.g `(ConfigurationOfFuel project version: > versionStringFromNumberOneAbove) load` > b. Materialize the data > c. Upgrade Fuel back to the normal version for the newer Pharo (replace > version string from 3.a. with the original version) > d. Serialize the data Some use cases may require multiple downgrades/upgrades, which could be annoying. An interesting idea might be for a new release of Fuel to rename the previous version of as OldFuel that is released in its own package. Then "some OldFuel version" could exist in parallel with the "current version." The "current version" might even be smart enough to identify the OldFuel version needed and load it into the image and continue materializing the data. A CI program might run through a range of OldFuel versions to track which remain working on future versions of Pharo. cheers -ben > > Now you can load the data into the newer Pharo. > > > Peter Kenny wrote >> could I set those to give different version numbers > > The problem is that the data format may not be compatible between the > versions. Mariano would be able to give a better answer, but I would be > afraid. What if it seems to work but corrupts your data?! > > Does the workflow I detailed make sense and cover your needs? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/How-to-move-data-between-Pharo-versions-tp4829102p482… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > -- Mariano http://marianopeck.wordpress.com

May 29, 2015

Re: [Pharo-users] Is it always needed to redefine #hash message when you redefine #= message?

by Henrik Johansen

Also implied, but seldom stated, is that all values used in = and hash must only be set at creation, never after. The reason is the same, keeping hashed collection usage sane; p := Point x: 3 y: 2. Set add: p. "Imaginary method" p setX: 2. Set includes: p -> false Cheers, Henry > On 26 May 2015, at 9:11 , Julien Delplanque <julien(a)tamere.eu> wrote: > > Thanks, I understand now :) > > On 26/05/15 21:06, Carlo wrote: >> Hi >> >> Any two objects that are = must answer the same #hash value. >> The hash is used in any of the HashedCollection's for storage and then to find the exact element the #= is used. >> If 2 objects are #= but their hash values are different the HashedCollection will not find the correct storage slot and you will have undefined behaviour when looking up objects. >> >> Out of interest, Andres Valloud wrote a whole book on 'Hashing in Smalltalk' (http://www.lulu.com/content/1455536) >> >> Also the Javadoc comments are pretty good in explaining the usage: >>> The general contract of hashCode is: >>> Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application. >>> If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result. >>> It is not required that if two objects are unequal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hash tables. >>> As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. >> Cheers >> Carlo >> >> On 26 May 2015, at 8:45 PM, Julien Delplanque <julien(a)tamere.eu> wrote: >> >> The subject of this mail is exactly my question. >> >> I came to this question by looking at Object>>#= message implementation. >> >> """ >> = anObject >> "Answer whether the receiver and the argument represent the same >> object. If = is redefined in any subclass, consider also redefining the >> message hash." >> >> ^self == anObject >> """ >> >> When do we need to redefine #hash message? >> >> Is it the right way to implement equality between two objects or is there another message that I should override? >> >> Regards, >> Julien >> >> >> > >

May 29, 2015

Re: [Pharo-users] [Pre-ANN][Job] We are looking for a "Engineer R&D"

by Marcus Denker

> On 29 May 2015, at 10:28, Martin BÃ¤hr <mbaehr(a)email.archlab.tuwien.ac.at> wrote: > > Excerpts from Marcus Denker's message of 2015-05-29 10:17:24 +0200: >> Hi, >> >> Good news: the job is not constraint by the â2 years after universityâ condition, but instead it is a >> so called âExperienced Engineerâ position: >> >> http://www.inria.fr/en/institute/recruitment/offers/find-a-position?nPostin… > > that link does not work for me, is it this one? > http://www.inria.fr/en/institute/recruitment/offers/find-a-position/%28view… > Yes! Marcus

May 29, 2015

Re: [Pharo-users] [Pre-ANN][Job] We are looking for a "Engineer R&D"

by Martin BÃ¤hr

Excerpts from Marcus Denker's message of 2015-05-29 10:17:24 +0200: > Hi, > > Good news: the job is not constraint by the â2 years after universityâ condition, but instead it is a > so called âExperienced Engineerâ position: > > http://www.inria.fr/en/institute/recruitment/offers/find-a-position?nPostin… that link does not work for me, is it this one? http://www.inria.fr/en/institute/recruitment/offers/find-a-position/%28view… greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

May 29, 2015

Re: [Pharo-users] [Pre-ANN][Job] We are looking for a "Engineer R&D"

by Marcus Denker

Hi, Good news: the job is not constraint by the â2 years after universityâ condition, but instead it is a so called âExperienced Engineerâ position: http://www.inria.fr/en/institute/recruitment/offers/find-a-position?nPostin… Marcus > On 22 May 2015, at 13:36, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > No job posting yet as we are seeing what exact kind of person we can hire. There is a certain > chance that this will not be constrained to âtwo years after universityâ. > > Job posting will be finalised next week, if you are interested (or now someone who might) > ==> please contact me already now. > > Marcus > >> On 19 May 2015, at 17:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Hi, >> >> We will put the official announce online later this weekâ¦ we are looking to fill a a âyoung engineer positionâ. >> This is for recent graduates who finished their degree 2013/2014/2015. >> >> The topic is to work for 2 years on improving âremoteâ debugging for cases like server deployment, typical >> cloud scenarios and when using embedded Pharo images (e.g. for robotics). >> >> If you are interested (or know someone who might), please contact me. >> (official announcement will be online later this week). >> >> Marcus >> >

May 29, 2015