February 2013 - Pharo-dev - lists.pharo.org

[Pharo-project] Problems with Metacello

by StÃ©phane Ducasse

Hi Dale I have two questions: first question: className usage in presence of regular package. ------------------------------------------------------------------------------------------- In the following baseline, I do not understand why I'm forced to specify the className because the configuration is based on the project name. spec project: 'OrderPreservingDictionary' with: [ spec ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ without className versionString: #stable; loads: #('Core'); repository: 'http://smalltalkhub.com/mc/Pharo/OrderPreservingDictionary/main']. does not work while spec project: 'OrderPreservingDictionary' with: [ spec className: 'ConfigurationOfOrderPreservingDictionary'; versionString: #stable; loads: #('Core'); repository: 'http://smalltalkhub.com/mc/Pharo/OrderPreservingDictionary/main']. Works baseline200: spec <version: '2.0.0-baseline'> spec for: #common do: [ spec blessing: #baseline; description: 'Migrated to SmalltalkHub and taking into account new configurations of subcomponents'; repository: 'http://smalltalkhub.com/mc/Pharo/XMLWriter/main'. spec project: 'OrderPreservingDictionary' with: [ spec className: 'ConfigurationOfOrderPreservingDictionary'; versionString: #stable; loads: #('Core'); repository: 'http://smalltalkhub.com/mc/Pharo/OrderPreservingDictionary/main']. spec package: 'XML-Writer' with: [spec requires: 'OrderPreservingDictionary']. spec group: 'default' with: #('Core'); group: 'Core' with: #('XML-Writer'); group: 'Tests' with: #() ]. spec for: #squeakCommon do: [ spec package: 'Collections-Support' with: [ spec repository: 'http://www.squeaksource.com/Pharo' ] ]. second question ----------------------- People wrote the following in the baseline spec for: #squeakCommon do: [ spec package: 'Collections-Support' with: [ spec repository: 'http://www.squeaksource.com/Pharo' ] ]. I commented the squeakCommon part because it was loading an old package in pharo! And this package is part of Pharo. Now when I comment the version I do not understand why it is still trying to load a package version because there is already a version in the image. I will remove it from the baseline but I do not understand this behavior. Packages present in the image do not take precedence? version200: spec <version: '2.0.0' imports: #('2.0.0-baseline')> spec for: #common do: [ spec blessing: #release; package: 'XML-Writer' with: 'XML-Writer-JAAyer.5' ]; " I do not understand the following line because it means that we would load an older version than the one currently in Pharo. Clearly the best way to introduce bugs and losing hours trying to understand why. for: #squeakCommon do: [ spec package: 'Collections-Support' with: 'Collections-Support-StephaneDucasse.35' ];" for: #gemstone do: [ spec package: 'Collections-Support' with: 'Collections-Support.g-OttoBehrens.45'; package: 'Collections-Tests-Support' with: 'Collections-Tests-Support.g-OttoBehrens.3' ] Now I do not understand why it loads a package when the package Stef

Feb. 16, 2013

[Pharo-project] Only 12 days left ... please help

by James Ladd

There are only 12 days left to support Redline Smalltalk. http://www.indiegogo.com/smalltalk More Smalltalks means more Smalltalkers and that is good for Pharo too. Redline targets a wide audience by using the Java Virtual Machine and source in files - removing barriers to get more Smalltalkers! Please help.

Feb. 16, 2013

Re: [Pharo-project] Pharo vm builds restored

by Igor Stasenko

On 16 February 2013 17:24, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Pharo VM built successfully from cog.tar and VMMaker-image now. Thanks for testing , Phil. > > Now, is there anything like a *Pharo* VM for IOS? Doesn't seem to be > any configuration in there. > There is, but it don't called 'pharo' yet :) > Phil > > > 2013/2/16 Camillo Bruni <camillobruni(a)gmail.com>: >> You use the wrong configuration in VMMaker (thanks to the strange naming conventions >> this happens way too easily) :/ >> >> I think you can just use Pharo.*Config instead of Cog.*Config? >> >> On 2013-02-16, at 15:18, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> >>> And inside the app, there is a CogVM executable, not a pharo one. >>> >>> Confused I am. >>> >>> Phil >>> >>> 2013/2/16 Camillo Bruni <camillobruni(a)gmail.com>: >>>> >>>> On 2013-02-16, at 14:30, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>> >>>>> Well, this is the script from hell... >>>>> >>>>> newImage.sh doesn't executes the last line: >>>>> >>>>> # ---------------------------------------------------------------------------- >>>>> # try to open the image... >>>>> set -e >>>>> openImage "$PWD/$VERSION.image" "$PWD/../codegen-scripts/LoadVMMaker.st" >>>>> rm -rf "$PWD/$VERSION.image" "$PWD/$VERSION.changes"; >>>>> openImage "$PWD/$generator.image" "$PWD/ImageConfiguration.st" >>>>> >>>>> >>>>> because openImage exits the script... >>>>> >>>>> Question: can't we run all of this headless? >>>> >>>> >>>> yes please ;) I guess I never fully tested it under unix/win and nobody really used it >>>> besides me. >>>> >>>> => run everything in headless mode >>>> => use the zeroconf scripts >>>> >>>> >>>> >>> >> >> > -- Best regards, Igor Stasenko.

Feb. 16, 2013

Re: [Pharo-project] Publishing OrderPreservingDictionary to SmalltalkHub

by stephane ducasse

I published also CharacterMap. So now I will be able to migrate XMLWriter and XMLParser and probably Soup. Stef On Feb 16, 2013, at 7:08 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > Hi guys > > just to let you know that I'm migrating OrderPreservingDictionary from SS to SmalltalkHub. > I will also add a ConfigurationOf > So that we can base other configruations on this one. > > > Stef

Feb. 16, 2013

[Pharo-project] Publishing OrderPreservingDictionary to SmalltalkHub

by StÃ©phane Ducasse

Hi guys just to let you know that I'm migrating OrderPreservingDictionary from SS to SmalltalkHub. I will also add a ConfigurationOf So that we can base other configruations on this one. Stef

Feb. 16, 2013

Re: [Pharo-project] [Failing Tests] Cleaned up failing test serialization

by Martin Dias

Yes, post materialization should be added in Debugger>>serializeStack like it's been done in HDTestReport>>serializeTestFailureContext:toFileNamed: To avoid code replication, we may create a extension method to MethodContext, #serializeOn: that receives a stream. Martin On Sat, Feb 16, 2013 at 3:31 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > yep... something like that :) > > > On Sat, Feb 16, 2013 at 3:25 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> Camillo Bruni wrote: >>> >>> On 2013-02-16, at 14:14, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> >>> >>>> >>>> On 2013-02-16, at 14:11, Ben Coman <btc(a)openInWorld.com> wrote: >>>> >>>> >>>>> >>>>> Marcus Denker wrote: >>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> To make it easy to explore why a test fails on the test server we >>>>>> serialize the stack of falling tests. >>>>>> >>>>>> With two changes this has now gotten much easier: >>>>>> >>>>>> 1) Drag and Drop support for .fuel file >>>>>> Just drag the file to the Pharo Desktop --> Debugger opens >>>>>> >>>>>> >>>>> >>>>> Could you advise how to do this from an operational image (that is, not >>>>> a CI test image). I would like to use this to demonstrate Pharo's >>>>> outstanding development environment. A killer feature would be the >>>>> debugger having a <File out> button, that a user could use to mail to >>>>> support. Does any other programming system allow this ? >>>>> >>>> >>>> you can just select "fileout / serialize stack" in the debugger >>>> somewhere. >>>> The you get a local .fuel file with the serialized stack :) >>>> >>> >>> >>> it's the last entry "File out Stack" in the right-click menu of the >>> debugger >>> >>> >> >> Brilliant! I thought the idea was obvious :) >> >> Now that sparks a following thought, what might be interesting for >> customer/support interaction would a mechanism packaging together: >> * the serialized stack >> * a manifest of all loaded ConfigurationOfXXX versions >> * the diff of any dirty ConfigurationOfXXX >> subject to user review to avoid leaking proprietary information. >> >> cheers, Ben >> >

Feb. 16, 2013

Re: [Pharo-project] Pharo vm builds restored

by phil＠highoctane.be

Pharo VM built successfully from cog.tar and VMMaker-image now. Now, is there anything like a *Pharo* VM for IOS? Doesn't seem to be any configuration in there. Phil 2013/2/16 Camillo Bruni <camillobruni(a)gmail.com>: > You use the wrong configuration in VMMaker (thanks to the strange naming conventions > this happens way too easily) :/ > > I think you can just use Pharo.*Config instead of Cog.*Config? > > On 2013-02-16, at 15:18, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> And inside the app, there is a CogVM executable, not a pharo one. >> >> Confused I am. >> >> Phil >> >> 2013/2/16 Camillo Bruni <camillobruni(a)gmail.com>: >>> >>> On 2013-02-16, at 14:30, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>> >>>> Well, this is the script from hell... >>>> >>>> newImage.sh doesn't executes the last line: >>>> >>>> # ---------------------------------------------------------------------------- >>>> # try to open the image... >>>> set -e >>>> openImage "$PWD/$VERSION.image" "$PWD/../codegen-scripts/LoadVMMaker.st" >>>> rm -rf "$PWD/$VERSION.image" "$PWD/$VERSION.changes"; >>>> openImage "$PWD/$generator.image" "$PWD/ImageConfiguration.st" >>>> >>>> >>>> because openImage exits the script... >>>> >>>> Question: can't we run all of this headless? >>> >>> >>> yes please ;) I guess I never fully tested it under unix/win and nobody really used it >>> besides me. >>> >>> => run everything in headless mode >>> => use the zeroconf scripts >>> >>> >>> >> > >

Feb. 16, 2013

Re: [Pharo-project] Pharo vm builds restored

by phil＠highoctane.be

Forget that, that file is the only one which is *already* in the build/ folder from the cog.tar, which I trashed when restarting the procedure. One more gotcha... Phil 2013/2/16 Camillo Bruni <camillobruni(a)gmail.com>: > You use the wrong configuration in VMMaker (thanks to the strange naming conventions > this happens way too easily) :/ > > I think you can just use Pharo.*Config instead of Cog.*Config? > > On 2013-02-16, at 15:18, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> And inside the app, there is a CogVM executable, not a pharo one. >> >> Confused I am. >> >> Phil >> >> 2013/2/16 Camillo Bruni <camillobruni(a)gmail.com>: >>> >>> On 2013-02-16, at 14:30, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>> >>>> Well, this is the script from hell... >>>> >>>> newImage.sh doesn't executes the last line: >>>> >>>> # ---------------------------------------------------------------------------- >>>> # try to open the image... >>>> set -e >>>> openImage "$PWD/$VERSION.image" "$PWD/../codegen-scripts/LoadVMMaker.st" >>>> rm -rf "$PWD/$VERSION.image" "$PWD/$VERSION.changes"; >>>> openImage "$PWD/$generator.image" "$PWD/ImageConfiguration.st" >>>> >>>> >>>> because openImage exits the script... >>>> >>>> Question: can't we run all of this headless? >>> >>> >>> yes please ;) I guess I never fully tested it under unix/win and nobody really used it >>> besides me. >>> >>> => run everything in headless mode >>> => use the zeroconf scripts >>> >>> >>> >> > >

Feb. 16, 2013

Re: [Pharo-project] Pharo vm builds restored

by phil＠highoctane.be

All right, this wasn't in the workspace being initialized with the .st file in the image folder. Code is generated, cmake works, but make fails. vmVersionInfo.h appears to be missing. Was there when doing the Cog thing. I'll dig. Phil 2013/2/16 Camillo Bruni <camillobruni(a)gmail.com>: > You use the wrong configuration in VMMaker (thanks to the strange naming conventions > this happens way too easily) :/ > > I think you can just use Pharo.*Config instead of Cog.*Config? > > On 2013-02-16, at 15:18, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> And inside the app, there is a CogVM executable, not a pharo one. >> >> Confused I am. >> >> Phil >> >> 2013/2/16 Camillo Bruni <camillobruni(a)gmail.com>: >>> >>> On 2013-02-16, at 14:30, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>> >>>> Well, this is the script from hell... >>>> >>>> newImage.sh doesn't executes the last line: >>>> >>>> # ---------------------------------------------------------------------------- >>>> # try to open the image... >>>> set -e >>>> openImage "$PWD/$VERSION.image" "$PWD/../codegen-scripts/LoadVMMaker.st" >>>> rm -rf "$PWD/$VERSION.image" "$PWD/$VERSION.changes"; >>>> openImage "$PWD/$generator.image" "$PWD/ImageConfiguration.st" >>>> >>>> >>>> because openImage exits the script... >>>> >>>> Question: can't we run all of this headless? >>> >>> >>> yes please ;) I guess I never fully tested it under unix/win and nobody really used it >>> besides me. >>> >>> => run everything in headless mode >>> => use the zeroconf scripts >>> >>> >>> >> > >

Feb. 16, 2013

[Pharo-project] Twibbon

by Sean P. DeNigris

http://twibbon.com/support/pharo-smalltalk -- View this message in context: http://forum.world.st/Twibbon-tp4670304.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 16, 2013