- Pharo-users - lists.pharo.org

Re: [Pharo-users] FLMethodChanged: Materialization error. Method DmQuartalsplan>>#initialize: changed its bytecodes.

by Mariano Martinez Peck

HI Johannes, Could I see the source of the DmQuartalsplan>>#initialize: ? I think I workaround may be to do a Fuel replacement to replace the sortedCollection with an OrderedCollection and then a post initialize method. But again, probably seeing if the closure of the sorted collection is clean or not may have different behaviors. Cheers, On Mon, Mar 21, 2016 at 3:09 PM, Johannes Brauer <brauer(a)nordakademie.de> wrote: > Hi, > > I am trying to port a pharo2 application to pharo4. Therefore I have to > migrate some fuel files from version 1.9 to 1.9.4. I've done this using the > script shown in the EnterprisePharo Book in my pharo2 image, no problem. > But trying to load the migrated fuel file into my pharo4 image I get the > error message shown above. The source code of the initialize methods is the > same in both images, of course. But the byte codes differ: > > Pharo2: > 37 <70> self > 38 <42> pushLit: SortedCollection > 39 <8F 02 00 08> closureNumCopied: 0 numArgs: 2 bytes 43 to 50 > â¦ > > Pharo4: > 37 <70> self > 38 <40> pushLit: SortedCollection > 39 <8F 02 00 08> closureNumCopied: 0 > â¦ > > What can I do? > Johannes > > -- Mariano http://marianopeck.wordpress.com

March 21, 2016

FLMethodChanged: Materialization error. Method DmQuartalsplan>>#initialize: changed its bytecodes.

by Johannes Brauer

Hi, I am trying to port a pharo2 application to pharo4. Therefore I have to migrate some fuel files from version 1.9 to 1.9.4. I've done this using the script shown in the EnterprisePharo Book in my pharo2 image, no problem. But trying to load the migrated fuel file into my pharo4 image I get the error message shown above. The source code of the initialize methods is the same in both images, of course. But the byte codes differ: Pharo2: 37 <70> self 38 <42> pushLit: SortedCollection 39 <8F 02 00 08> closureNumCopied: 0 numArgs: 2 bytes 43 to 50 â¦ Pharo4: 37 <70> self 38 <40> pushLit: SortedCollection 39 <8F 02 00 08> closureNumCopied: 0 â¦ What can I do? Johannes

March 21, 2016

Re: [Pharo-users] BaselineOf's and Loose Dependencies

by Sean P. DeNigris

Dale Henrichs-3 wrote > First, congratulations! Thanks!! Dale Henrichs-3 wrote > A baseline is associated with a "git version", so there is no need to > "pin the version down in a specific version" Yes, but I'm not talking about a version of my main project, but a version of a dependent project. Dale Henrichs-3 wrote > in a "git project" you > have the option of changing the specific version associated with a > baseline on "every commit" .... Again, yes, but what I want to do (and what I understood as best practice in the past) is to defer the linking to a specific version until I release a stable version of my main project. That is, while I'm developing, I can be much looser with my tracking of loose dependencies, e.g. commonly it is enough to specify that I always want #stable. Of course, symbolic dependencies are not a good idea for release versions, so I will want to override the loose dependency with a specific numbered version. Unfortunately, while I'm no longer getting the mentioned error, my override seems to be ignored - `ConfigurationOfBabyPhexample project stableVersion record loadDirective.` reports that the #stable version of BabyMock (1.3) will be loaded instead of the version 1.2 that I specified in my configuration. I created an issue in my GitHub project where it might be easier to reference the code (https://github.com/seandenigris/Baby-Phexample/issues/1) or we can continue to discuss here. ----- Cheers, Sean -- View this message in context: http://forum.world.st/BaselineOf-s-and-Loose-Dependencies-tp4885749p4885766… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 21, 2016

Re: [Pharo-users] BaselineOf's and Loose Dependencies

by Dale Henrichs

Sean (and others) I don't always keep up-to-date with the posts on the pharo list, so if you have a Metacello-related question, put Metacello in the subject line and I'll have a better chance of seeing the message ... Dale On 3/21/16 8:15 AM, Sean P. DeNigris wrote: > I know this is not technically a Pharo question, but I'm in China on my > honeymoon and can't access the Metacello Google group! > > There was a pattern in pre-BaselineOf Metacello where one would define > dependencies loosely in the #baselineXyz:, and then pin them to a specific > version in the #versionAbc:. > > For example: > baseline100: spec > ... > project: 'BabyMock' with: [ > spec > className: #ConfigurationOfBabyMock; > versionString: #'stable'; > repository: 'http://smalltalkhub.com/mc/zeroflag/BabyMock/main/' ] > ... > and then: > version10: spec > ... > spec > project: 'BabyMock' with: '1.2' > ... > > How does one handle this sort of thing with #baseline:import:? > > This is what I came up with: > version10: spec > ... > baseline: 'BabyPhexample' > with: [ > spec > repository: > > 'github://seandenigris/Baby-Phexample:INSERT-SHA-HERE/repository' ]; > import: 'BabyPhexample'. > spec > project: 'BabyMock' with: '1.2' > ... > But I got this error from the last line: MessageNotUnderstood: receiver of > "fetchUsing:" is nil > > Thanks. > > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/BaselineOf-s-and-Loose-Dependencies-tp4885749.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

March 21, 2016

Re: [Pharo-users] BaselineOf's and Loose Dependencies

by Dale Henrichs

First, congratulations! A baseline is associated with a "git version", so there is no need to "pin the version down in a specific version" ... in a "git project" you have the option of changing the specific version associated with a baseline on "every commit" .... So you would specify the BabyMock project as you would in the baseline*: method from your ConfigurationOf and "override" the versionString in place: spec configuration: 'BabyMock' with: [ spec versionString: '1.2'; repository: 'http://smalltalkhub.com/mc/zeroflag/BabyMock/main/' ] Note, that I'm using the more modern form of project specification.... the above is equivalent to: spec project: 'BabyMock' with: [ spec className: #'ConfigurationOfBabyMock'; versionString: '1.2'; repository ] Dale On 3/21/16 8:15 AM, Sean P. DeNigris wrote: > I know this is not technically a Pharo question, but I'm in China on my > honeymoon and can't access the Metacello Google group! > > There was a pattern in pre-BaselineOf Metacello where one would define > dependencies loosely in the #baselineXyz:, and then pin them to a specific > version in the #versionAbc:. > > For example: > baseline100: spec > ... > project: 'BabyMock' with: [ > spec > className: #ConfigurationOfBabyMock; > versionString: #'stable'; > repository: 'http://smalltalkhub.com/mc/zeroflag/BabyMock/main/' ] > ... > and then: > version10: spec > ... > spec > project: 'BabyMock' with: '1.2' > ... > > How does one handle this sort of thing with #baseline:import:? > > This is what I came up with: > version10: spec > ... > baseline: 'BabyPhexample' > with: [ > spec > repository: > > 'github://seandenigris/Baby-Phexample:INSERT-SHA-HERE/repository' ]; > import: 'BabyPhexample'. > spec > project: 'BabyMock' with: '1.2' > ... > But I got this error from the last line: MessageNotUnderstood: receiver of > "fetchUsing:" is nil > > Thanks. > > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/BaselineOf-s-and-Loose-Dependencies-tp4885749.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

March 21, 2016

Re: [Pharo-users] [Pillar] Logo for Pillar

by Esteban A. Maringolo

I don't like it. It's more an illustration than an actual iso/logotype. Sorry. I didn't know there was a logo for Pillar, and though it's not fantastic, it is nice and continues with the style of a Pharo thing. Regards! Esteban A. Maringolo 2016-03-21 11:05 GMT-03:00 Thibault ARLOING <thibault.arloing(a)hotmail.fr>: > oh I didn't see either that pillar had a logo. > Moreover, he is better. > > thanks > > ________________________________________ > De : Pharo-users <pharo-users-bounces(a)lists.pharo.org> de la part de Damien Cassou <damien.cassou(a)inria.fr> > EnvoyÃ© : lundi 21 mars 2016 14:19 > Ã : Yuriy Tymchuk; Any question about pharo is welcome > Objet : Re: [Pharo-users] [Pillar] Logo for Pillar > > Yuriy Tymchuk <yuriy.tymchuk(a)me.com> writes: > >> IMHO itâs too airy, to much free area. By the way, have you seen the previous logo? >> https://github.com/pillar-markup > > I didn't know Pillar already had a logo :-). Thanks > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > >

March 21, 2016

BaselineOf's and Loose Dependencies

by Sean P. DeNigris

I know this is not technically a Pharo question, but I'm in China on my honeymoon and can't access the Metacello Google group! There was a pattern in pre-BaselineOf Metacello where one would define dependencies loosely in the #baselineXyz:, and then pin them to a specific version in the #versionAbc:. For example: baseline100: spec ... project: 'BabyMock' with: [ spec className: #ConfigurationOfBabyMock; versionString: #'stable'; repository: 'http://smalltalkhub.com/mc/zeroflag/BabyMock/main/' ] ... and then: version10: spec ... spec project: 'BabyMock' with: '1.2' ... How does one handle this sort of thing with #baseline:import:? This is what I came up with: version10: spec ... baseline: 'BabyPhexample' with: [ spec repository: 'github://seandenigris/Baby-Phexample:INSERT-SHA-HERE/repository' ]; import: 'BabyPhexample'. spec project: 'BabyMock' with: '1.2' ... But I got this error from the last line: MessageNotUnderstood: receiver of "fetchUsing:" is nil Thanks. ----- Cheers, Sean -- View this message in context: http://forum.world.st/BaselineOf-s-and-Loose-Dependencies-tp4885749.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

March 21, 2016

Re: [Pharo-users] [Pharo-dev] DeprecationAssistant

by Yuriy Tymchuk

Oh, thatâs an interesting use case. Itâs not easy no make predictions further in stack so by default it is assumed that the change should happen in the method that has called the deprecated one. In fact usually this should help with the method deprecation, and in the particular case we are dealing with a class deprecation hacked as a method deprecation :) But itâs good that now I know more use cases ;) Uko > On 21 Mar 2016, at 14:56, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Ah okay! > But how does the system resolve it ? I mean, the class RTLabelled does not refer to RTLabeled. So, what is the magic behind your tool? > > I found an interesting situation. Look at this: > > <Screen Shot 2016-03-21 at 10.53.09 AM.png> > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Mar 21, 2016, at 10:19 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >> >> Hi Alex, >> >> this is not about criticsâ¦ >> >> If you have a method like >> >> labeledObject >> ^ RTLabelled new >> >> in the latest roassal image and you will execute it, you will get a debugger deprecation warning with an option to fix that. >> >> Cheers. >> Uko >> >>> On 21 Mar 2016, at 14:07, Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: >>> >>> Hi! >>> >>> I cannot figure out what I should expect after loading DeprecationAssistant. I have loaded it and created a method: >>> -=-=-=-=-=-=-=-=-= >>> foo >>> self deprecated: 'use bar insteadâ >>> -=-=-=-=-=-=-=-=-= >>> >>> Is there anything that should be displayed in the critic list? >>> >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>>> On Mar 21, 2016, at 9:59 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>>> >>>> HI everyone, >>>> >>>> last week Iâve created a little tool that automates deprecation resolution. The goal is to provide a help based on the existing code (no need for extra actions). You can read more here: http://blog.yuriy.tymch.uk/2016/03/deprecationassistant-aiding-developers.h… <http://blog.yuriy.tymch.uk/2016/03/deprecationassistant-aiding-developers.h…> >>>> >>>> You can install and try it out with: >>>> Metacello new >>>> repository: 'github://Uko/DeprecationAssistant' <github://Uko/DeprecationAssistant'>; >>>> baseline: 'DeprecationAssistant'; >>>> load >>>> >>>> This will add additional actions to the debugger once you will get a deprecation warning. >>>> >>>> Have fun! >>>> Cheers. >>>> Uko >>> >> >

March 21, 2016

Re: [Pharo-users] [Pillar] Logo for Pillar

by Thibault ARLOING

oh I didn't see either that pillar had a logo. Moreover, he is better. thanks ________________________________________ De : Pharo-users <pharo-users-bounces(a)lists.pharo.org> de la part de Damien Cassou <damien.cassou(a)inria.fr> EnvoyÃ© : lundi 21 mars 2016 14:19 Ã : Yuriy Tymchuk; Any question about pharo is welcome Objet : Re: [Pharo-users] [Pillar] Logo for Pillar Yuriy Tymchuk <yuriy.tymchuk(a)me.com> writes: > IMHO itâs too airy, to much free area. By the way, have you seen the previous logo? > https://github.com/pillar-markup I didn't know Pillar already had a logo :-). Thanks -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

March 21, 2016

Re: [Pharo-users] [Pharo-dev] DeprecationAssistant

by Alexandre Bergel

Ah okay! But how does the system resolve it ? I mean, the class RTLabelled does not refer to RTLabeled. So, what is the magic behind your tool? I found an interesting situation. Look at this: Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Mar 21, 2016, at 10:19 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi Alex, > > this is not about criticsâ¦ > > If you have a method like > > labeledObject > ^ RTLabelled new > > in the latest roassal image and you will execute it, you will get a debugger deprecation warning with an option to fix that. > > Cheers. > Uko > >> On 21 Mar 2016, at 14:07, Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: >> >> Hi! >> >> I cannot figure out what I should expect after loading DeprecationAssistant. I have loaded it and created a method: >> -=-=-=-=-=-=-=-=-= >> foo >> self deprecated: 'use bar insteadâ >> -=-=-=-=-=-=-=-=-= >> >> Is there anything that should be displayed in the critic list? >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >>> On Mar 21, 2016, at 9:59 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: >>> >>> HI everyone, >>> >>> last week Iâve created a little tool that automates deprecation resolution. The goal is to provide a help based on the existing code (no need for extra actions). You can read more here: http://blog.yuriy.tymch.uk/2016/03/deprecationassistant-aiding-developers.h… <http://blog.yuriy.tymch.uk/2016/03/deprecationassistant-aiding-developers.h…> >>> >>> You can install and try it out with: >>> Metacello new >>> repository: 'github://Uko/DeprecationAssistant' <github://Uko/DeprecationAssistant'>; >>> baseline: 'DeprecationAssistant'; >>> load >>> >>> This will add additional actions to the debugger once you will get a deprecation warning. >>> >>> Have fun! >>> Cheers. >>> Uko >> >

March 21, 2016