June 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo 4 and Roassal

by Alejandro Infante

It is loaded in Pharo4, but in order to verify that it is up to date, Metacello needs to check the ConfigurationOf for the required version and that fails. Alejandro > On Jun 20, 2015, at 10:29 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > I think this is because the latest glamour core was not in the base imageâ¦ I do not remember exactly. > > Alexandre > > >> On Jun 20, 2015, at 10:25 PM, Alejandro Infante <alejandroinfante91(a)gmail.com> wrote: >> >> Exactly, all the customized views are dependent of GlamourCore and also the Easel depends on Glamour for showing the examples. >> >> Alejandro >> >>> On Jun 20, 2015, at 10:22 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> >>> Alejandro, >>> >>> I do not remember why Roassal depends on Glamour? >>> I guess this is because of the GTInspector? >>> >>> Alexandre >>> >>>> On Jun 19, 2015, at 8:11 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: >>>> >>>> On 19-06-15 07:11, Alejandro Infante wrote: >>>>> Hi, >>>>> I did that because when using: >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> Gofer it >>>>> smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; >>>>> configurationOf: 'Roassal2'; >>>>> loadStable >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> It was installing 1.52 even though the stable version of Roassal was 1.12. >>>>> Instead if I used: >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> Gofer new smalltalkhubUser: 'ObjectProfile' >>>>> project: 'Roassal2'; >>>>> package: 'ConfigurationOfRoassal2'; >>>>> load. >>>>> ((Smalltalk at: #ConfigurationOfRoassal2) project version: #stable) load >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> I was getting the right version (1.12). >>>> >>>> Gofer>>loadStable does not use the >>>> >>>> ConfigurationOfRoassal2 class>>loadStable >>>> >>>> (which is undefined, but many configurations define as >>>> >>>> self project load: #stable >>>> >>>> but loadVersion: #stable, which uses the latest version marked #stable. >>>> >>>> So yes, that is something you'd want to fix in place. >>>> And warn about on the mailing list. >>>> >>>> In this version 1.12 then we see that Roassal is tightly coupled to >>>> an old version of GlamourCore. So either ConfigurationOfRoassal2 >>>> needs to add a new #stable version every time GlamourCore #stable >>>> for Pharo 4 is updated, or it should depend on GlamourCore #stable. >>>> And ConfigurationOfGlamourCore has actually the same problem, as >>>> #stable currently depends on an old version of Rubric. So that >>>> should have been one or two versions more. And please note that >>>> this is for the released Pharo 4, where we are only supposed to >>>> backport important fixes. >>>> >>>> I strongly suggest to make ConfigurationOfGlamourCore #stable >>>> depend on ConfigurationOfRubric #stable, and to make ConfigurationOfRoassal2 depend on ConfigurationOfGlamourCore #stable. >>>> >>>> Depending on #stable instead of #release1 or so works out ok >>>> here as long there is not supposed to be a new release for Pharo 4. >>>> >>>> Stephan >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

June 21, 2015

Re: [Pharo-dev] Pharo 4 and Roassal

by Alexandre Bergel

I think this is because the latest glamour core was not in the base imageâ¦ I do not remember exactly. Alexandre > On Jun 20, 2015, at 10:25 PM, Alejandro Infante <alejandroinfante91(a)gmail.com> wrote: > > Exactly, all the customized views are dependent of GlamourCore and also the Easel depends on Glamour for showing the examples. > > Alejandro > >> On Jun 20, 2015, at 10:22 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >> Alejandro, >> >> I do not remember why Roassal depends on Glamour? >> I guess this is because of the GTInspector? >> >> Alexandre >> >>> On Jun 19, 2015, at 8:11 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: >>> >>> On 19-06-15 07:11, Alejandro Infante wrote: >>>> Hi, >>>> I did that because when using: >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> Gofer it >>>> smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; >>>> configurationOf: 'Roassal2'; >>>> loadStable >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> It was installing 1.52 even though the stable version of Roassal was 1.12. >>>> Instead if I used: >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> Gofer new smalltalkhubUser: 'ObjectProfile' >>>> project: 'Roassal2'; >>>> package: 'ConfigurationOfRoassal2'; >>>> load. >>>> ((Smalltalk at: #ConfigurationOfRoassal2) project version: #stable) load >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> I was getting the right version (1.12). >>> >>> Gofer>>loadStable does not use the >>> >>> ConfigurationOfRoassal2 class>>loadStable >>> >>> (which is undefined, but many configurations define as >>> >>> self project load: #stable >>> >>> but loadVersion: #stable, which uses the latest version marked #stable. >>> >>> So yes, that is something you'd want to fix in place. >>> And warn about on the mailing list. >>> >>> In this version 1.12 then we see that Roassal is tightly coupled to >>> an old version of GlamourCore. So either ConfigurationOfRoassal2 >>> needs to add a new #stable version every time GlamourCore #stable >>> for Pharo 4 is updated, or it should depend on GlamourCore #stable. >>> And ConfigurationOfGlamourCore has actually the same problem, as >>> #stable currently depends on an old version of Rubric. So that >>> should have been one or two versions more. And please note that >>> this is for the released Pharo 4, where we are only supposed to >>> backport important fixes. >>> >>> I strongly suggest to make ConfigurationOfGlamourCore #stable >>> depend on ConfigurationOfRubric #stable, and to make ConfigurationOfRoassal2 depend on ConfigurationOfGlamourCore #stable. >>> >>> Depending on #stable instead of #release1 or so works out ok >>> here as long there is not supposed to be a new release for Pharo 4. >>> >>> Stephan >>> >>> >>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 21, 2015

New Cog VMs available

by Eliot Miranda

... at http://www.mirandabanda.org/files/Cog/VM/VM.r3386 CogVM binaries as per VMMaker.oscog-eem.1370/r3386 Add the ARMv5/ARMv6 Cog Spur JIT VM! Add explicit read barriers to primitives which access an argument as the receiver (i.e. the mirror primitives). Don't check if the actual receiver is used. Simplify failure where appropriate cuz the primitives will be retried. Add -fwrapv to all linux gcc builds (to insist on 2's complement arithmetic) and add makeallclean, making makeall do the dirty build. Provide a -exitonwarn command line switch for the Mac and Unix VMs to allow for CI testing of asserts. Unix: restore the SCCS revision after the version number in -version output. Spur: Remember to count shrink requests Cogit: Fix bug in rewriting compiler primitives on module unload, etc. The old code didn't change the assignment to the primitiveFunctionPointer, which is needed for correct management of failing primitive calls on Spur. Simplify the post compile hook to eliminate the label parameter; this is local to the Cogit. ARM Cogit: Use out-of-line literals for compactness. -- best, Eliot

June 21, 2015

Re: [Pharo-dev] Pharo 4 and Roassal

by Alejandro Infante

Exactly, all the customized views are dependent of GlamourCore and also the Easel depends on Glamour for showing the examples. Alejandro > On Jun 20, 2015, at 10:22 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Alejandro, > > I do not remember why Roassal depends on Glamour? > I guess this is because of the GTInspector? > > Alexandre > >> On Jun 19, 2015, at 8:11 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> On 19-06-15 07:11, Alejandro Infante wrote: >>> Hi, >>> I did that because when using: >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> Gofer it >>> smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; >>> configurationOf: 'Roassal2'; >>> loadStable >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> It was installing 1.52 even though the stable version of Roassal was 1.12. >>> Instead if I used: >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> Gofer new smalltalkhubUser: 'ObjectProfile' >>> project: 'Roassal2'; >>> package: 'ConfigurationOfRoassal2'; >>> load. >>> ((Smalltalk at: #ConfigurationOfRoassal2) project version: #stable) load >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> I was getting the right version (1.12). >> >> Gofer>>loadStable does not use the >> >> ConfigurationOfRoassal2 class>>loadStable >> >> (which is undefined, but many configurations define as >> >> self project load: #stable >> >> but loadVersion: #stable, which uses the latest version marked #stable. >> >> So yes, that is something you'd want to fix in place. >> And warn about on the mailing list. >> >> In this version 1.12 then we see that Roassal is tightly coupled to >> an old version of GlamourCore. So either ConfigurationOfRoassal2 >> needs to add a new #stable version every time GlamourCore #stable >> for Pharo 4 is updated, or it should depend on GlamourCore #stable. >> And ConfigurationOfGlamourCore has actually the same problem, as >> #stable currently depends on an old version of Rubric. So that >> should have been one or two versions more. And please note that >> this is for the released Pharo 4, where we are only supposed to >> backport important fixes. >> >> I strongly suggest to make ConfigurationOfGlamourCore #stable >> depend on ConfigurationOfRubric #stable, and to make ConfigurationOfRoassal2 depend on ConfigurationOfGlamourCore #stable. >> >> Depending on #stable instead of #release1 or so works out ok >> here as long there is not supposed to be a new release for Pharo 4. >> >> Stephan >> >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

June 21, 2015

Re: [Pharo-dev] Pharo 4 and Roassal

by Alexandre Bergel

Alejandro, I do not remember why Roassal depends on Glamour? I guess this is because of the GTInspector? Alexandre > On Jun 19, 2015, at 8:11 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 19-06-15 07:11, Alejandro Infante wrote: >> Hi, >> I did that because when using: >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Gofer it >> smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; >> configurationOf: 'Roassal2'; >> loadStable >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> It was installing 1.52 even though the stable version of Roassal was 1.12. >> Instead if I used: >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Gofer new smalltalkhubUser: 'ObjectProfile' >> project: 'Roassal2'; >> package: 'ConfigurationOfRoassal2'; >> load. >> ((Smalltalk at: #ConfigurationOfRoassal2) project version: #stable) load >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> I was getting the right version (1.12). > > Gofer>>loadStable does not use the > > ConfigurationOfRoassal2 class>>loadStable > > (which is undefined, but many configurations define as > > self project load: #stable > > but loadVersion: #stable, which uses the latest version marked #stable. > > So yes, that is something you'd want to fix in place. > And warn about on the mailing list. > > In this version 1.12 then we see that Roassal is tightly coupled to > an old version of GlamourCore. So either ConfigurationOfRoassal2 > needs to add a new #stable version every time GlamourCore #stable > for Pharo 4 is updated, or it should depend on GlamourCore #stable. > And ConfigurationOfGlamourCore has actually the same problem, as > #stable currently depends on an old version of Rubric. So that > should have been one or two versions more. And please note that > this is for the released Pharo 4, where we are only supposed to > backport important fixes. > > I strongly suggest to make ConfigurationOfGlamourCore #stable > depend on ConfigurationOfRubric #stable, and to make ConfigurationOfRoassal2 depend on ConfigurationOfGlamourCore #stable. > > Depending on #stable instead of #release1 or so works out ok > here as long there is not supposed to be a new release for Pharo 4. > > Stephan > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 21, 2015

getting the history of a method?

by Alexandre Bergel

Hi! I have the following: Object subclass: #A. A compile: 'foo ^ 5'. A compile: 'foo ^ 10'. (A >> #foo) asHistoricalRingDefinition But I have no idea how I can get the two time stamps of A>>foo and the two source code? I cannot figure out what is the difference between asPassiveRingDefinition, asActiveRingDefinition, asFullRingDefinitionâ¦ These methods all return a RGMethodDefinition. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 21, 2015

[OT] Webassembly (next step after asm.js)

by Torsten Bergmann

Looks like the web is getting its bytecode, no need for intermediary JavaScript: https://blog.mozilla.org/luke/2015/06/17/webassembly/ https://brendaneich.com/2015/06/from-asm-js-to-webassembly/

June 20, 2015

Re: [Pharo-dev] [ANN] NeoConsole

by Alexandre Bergel

Excellent Amazing job Alexandre > Le 19 juin 2015 Ã 06:15, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : > > Hi, > > NeoConsole is a small, standalone package that offers a command line (a.k.a. a REPL) interface to a headless Pharo image. > > It contains a number of extendable commands and metrics that allow you to execute arbitrary Pharo code for result (introspection and debugging) or side effect (to manipulate the live, running image). There is a history mechanism, you can refer to previous evaluation results and there is a primitive describe mechanism (like a one level inspect). The metrics system allows you to consult a number of predefined values. There is decent error handling. > > Here is a screencast showing how this feels in practice: > > https://www.youtube.com/watch?v=tAtYff6_X_4 > > The movie shows how to start from scratch, downloading Pharo, installing NeoConsole, running a headless image with the REPL installed in the background. Next, an HTTP server is added to the image and later a specific response is added as well. (You can speed up the movie, if you want). > > Obviously this has been done before, and this is not the definitive solution in this area. For example, readline support (allowing you to edit your input) would be fantastic. A true command line inspector and debugger would be super as well. These are standard features in Lisp and would be totally possible in Pharo too. > > I just needed this for myself, liked the result and thought it would be worth sharing. > > Sven > > PS: > > Security warning: this service opens up your image for access to those with access to your local network (i.e. those logged in to your machine), without any further authenication, allowing them to do absolutely anything. Think and make sure that you know what you are doing. > >

June 20, 2015

Re: [Pharo-dev] Pay attention recent changes in the source manager can lead to loss of code

by Hilaire

Le 19/06/2015 21:43, stepharo a Ã©crit : > I experienced that and lost my changes. > > Stef > > Which image leads to this problem? Source manager : Change sorter or Change history? Or something else? Thanks Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

June 20, 2015

Re: [Pharo-dev] http://mc.stfx.eu/ZincHTTPComponents

by Damien Cassou

Sven Van Caekenberghe <sven(a)stfx.eu> writes: > Just a quick note to help you all keep your sanity: the last days > there was a problem with the http://mc.stfx.eu/ZincHTTPComponents > repository. It hit 1000 entries, which was an internal limit for AWS > S3 that is used as the backing store for mc.stfx.eu. I had to work > around that (see Zinc-AWS if you are interested). Of course, it took a > while to realise what was happening, it was all pretty weird ;-) TLDR; > things should be back to normal now. thank you very much Sven. Your work is important. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

June 20, 2015