March 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Pharo launcher in homebrew cask

by Serge Stinckwich

Great ! Thank you Filip On Mon, Mar 21, 2016 at 9:09 PM, Filip Krikava <krikava(a)gmail.com> wrote: > Hi, > > I find Pharo launcher incredibly useful and I was surprised not to find it > in homebrew cask [1]. Pharo itself is there. I have therefore created a PR: > https://github.com/caskroom/homebrew-cask/pull/19956 > > /cheers > Filip > > [1] https://github.com/caskroom/homebrew-cask -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

March 21, 2016

Pharo launcher in homebrew cask

by Filip Krikava

Hi, I find Pharo launcher incredibly useful and I was surprised not to find it in homebrew cask [1]. Pharo itself is there. I have therefore created a PR: https://github.com/caskroom/homebrew-cask/pull/19956 /cheers Filip [1] https://github.com/caskroom/homebrew-cask

March 21, 2016

[ANN] GNU Dr. Geo 16.03

by Hilaire

I am please to announce[1] release 16.03 of Dr. Geo, ready to download[2]. Main changes are (details in the change log[3]): - Bugs fix, mainly in the Smalltalk programming interface and related - New features - New translations "Dr. Geo, a software to design & manipulate interactive geometric sketches. It helps kids to explore geometry. Distributed with its source code it is modify-me-ready." Happy hacking with Dr. Geo! Hilaire [1] http://forum.drgeo.eu/Dr-Geo-16-03c-td4024903.html [2] http://drgeo.eu/download [3] http://drgeo.eu/changelog -- Dr. Geo http://drgeo.eu

March 21, 2016

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

by Mariano Martinez Peck

On Mon, Mar 21, 2016 at 3:51 PM, Johannes Brauer <brauer(a)nordakademie.de> wrote: > > Am 21.03.2016 um 19:19 schrieb Mariano Martinez Peck < > marianopeck(a)gmail.com>: > > HI Johannes, > > Could I see the source of the DmQuartalsplan>>#initialize: ? > > yes, of course: > 'From Pharo4.0 of 18 March 2013 [Latest update: #40626] on 21 March 2016 > at 6:19:38.568095 pm'! > > !DmQuartalsplan methodsFor: 'initialize-release' stamp: ' 15/1/14 15:24'! > initialize: einQuartal > self > lehrveranstaltungen: > (SortedCollection > sortBlock: [:x :y | x modul modulNummer <= y modul modulNummer]). > self quartal: einQuartal! ! > > I am not sure if the following will work. Please backup your image file and all your fuel files. But...what if you try to implement: DmQuartalsplan >> fuelReplacement | copy | copy := self copy. copy lehrveranstaltungen: copy lehrveranstaltungen asOrderedCollection. ^ copy And finally, at the image where you are materializing, you could implement: DmQuartalsplan >> fuelAfterMaterialization self lehrveranstaltungen: (self lehrveranstaltungen asSortedCollection: [:x :y | x modul modulNummer <= y modul modulNummer]) Once the migration is done, you can discard #fuelReplacement and #fuelAfterMaterialization if you want. I never tried this approach, so I am not sure ;) > > Joh. > > > 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 > > > -- Mariano http://marianopeck.wordpress.com

March 21, 2016

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

by Johannes Brauer

Am 21.03.2016 um 19:19 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com<mailto:marianopeck@gmail.com>>: HI Johannes, Could I see the source of the DmQuartalsplan>>#initialize: ? yes, of course: 'From Pharo4.0 of 18 March 2013 [Latest update: #40626] on 21 March 2016 at 6:19:38.568095 pm'! !DmQuartalsplan methodsFor: 'initialize-release' stamp: ' 15/1/14 15:24'! initialize: einQuartal self lehrveranstaltungen: (SortedCollection sortBlock: [:x :y | x modul modulNummer <= y modul modulNummer]). self quartal: einQuartal! ! Joh. 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<mailto:brauer@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<http://marianopeck.wordpress.com/>

March 21, 2016

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