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

Accommodation for Pharo Days

by Sven Van Caekenberghe

Hi, We just booked our accommodation for the Pharo Days and we noticed that general availability of rooms was pretty low. So it is probably a good idea to book on time. To help the organisers, please register on time for the conference itself too. Sven http://pharodays2015.pharo.org

Jan. 8, 2015

Re: [Pharo-users] Metacello does not load the expected version from ConfigOf

by Usman Bhatti

On Wed, Jan 7, 2015 at 8:25 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > Usman, > > No, I appreciate your patience:) If creating your own configuration works > for you then that is a good route to go... > > Sharing your image will make it much easier for me to get the bottom of > this (on my own schedule:), so please send me a link for accessing your > image and I'll dig into this in more detail when I have time ... > Here is the image. https://dl.dropboxusercontent.com/u/11804892/downgrade-with-metacello.zip You just need to execute the script in the workspace/playground to reproduce the problem (i.e. launching the directive to load PP 1.51 and that not happening). > If you find yourself stuck and needing the `downgrade directive` again, > I'll bump up the priority ... > I can still wait till next week. If you could have a look by then, it'll be great. tx. Usman > > > Dale > > > On 01/07/2015 09:19 AM, Usman Bhatti wrote: > > > > On Tue, Jan 6, 2015 at 6:56 PM, Dale Henrichs < > dale.henrichs(a)gemtalksystems.com> wrote: > >> >> On 1/6/15 7:16 AM, Usman Bhatti wrote: >> >> Dale, >> >> I couldn't make it work with the upgraded Metacello and the script you >> provided. >> >> Steps I did: >> >> 1. Download moose image: >> https://ci.inria.fr/moose/job/moose-5.0/ >> >> 2. Update my Metacello to the 'full' version: >> Metacello new >> baseline: 'Metacello'; >> repository: 'github://dalehenrich/metacello-work:master/repository'; >> get. >> Metacello new >> baseline: 'Metacello'; >> repository: 'github://dalehenrich/metacello-work:master/repository'; >> onConflict: [:ex | ex allow]; >> load >> >> 3. File in the ConfigurationOfDummyParser (see the first message in the >> thread). >> >> 4. Run this script to downgrade to PetitParser version 1.51 >> >> Metacello new >> configuration: 'DummyParser'; >> version: '1.0'; >> repository: '???'; >> onDowngradeUseIncoming: #('PetitParser'); >> load. >> >> The desired version is still not loaded, am I missing something here? >> >> Good question, I don't have a lot of time today to spend time trying to >> reproduce your problem, but if you send me a copy of the Transcript >> produced while doing the load I might be able to spot the problem ... >> > > It looks to me that the downgrade command is not working. Whenever I > point to the version preceding the one loaded, the packages are not fetched. > > I am attaching here two files. > > The first (Transcript-PP151) is the output of the transcript as you > asked. You can see that PetitParser packages as defined by the version 1.51 > are not fetched. All that is loaded is Glamour because the version 1.51 of > PetitParser loads the latest packages of Glamour. The load works because it > is an upgrade from the current version of Glamour which is a stable. > > When I saw that only Glamour packages are loaded, I thought of testing > Glamour downgrade too to see if the problem is specific to PetitParser. You > can see the result in the second file (Transcript-downgrade-glamour). No > packages of Glamour are fetched because the configuration tries to > downgrade it (stable is more recent than 3.0.0 which I try to load). > > In my opinion, downgrade is not working as required. If you want I can > share my image thru dropbox so that you can have a look to see what might > be wrong. > > >> >> >> regards, >> >> A question: I always use Metacello with ConfigOf and have never used >> the scripting API myself or saw it being used elsewhere. >> Can you provide a link that describes the use cases for both: ConfigOf >> vs. Scripting API? >> >> I've noticed the same thing:) >> >> My "elevator pitch" for the script api goes like this: >> 1. The scripting api maintains a registry of the actual project >> versions loaded into the image, >> making #currentVersion obsolete. #currentVersion is bad because it >> does a calculation of >> the current version that can be very slow and sometimes completely >> incorrect. >> 2. The old api has rules that it follows when loading projects (i.e., >> newer projects always win) and >> there is no mechanism for altering those rules. The scripting api >> provides mechanisms for >> for bending those rules to fit your needs ... like allowing a >> downgrade of a project. >> >> Part of the reason that people haven't changed has to do with how >> incredibly difficult it is to change the existing inertia. Another part of >> it is that I continue to support the old way of doing things, so there is >> no explicit motivation to change. >> >> If you look back 2-3 years in the archives of the Metacello mailing >> list[1] you should be able to find a number of posts where I make a more >> detailed cases for the scripting api:) >> >> At the end of the day, it isn't important to me to "get people to use the >> scripting api," as I said, I continue to support using the old api. I >> figure that when enough people start asking questions about how to "bend >> the Metacello rules" that folks will begin to use the "new" scripting api:) >> > > So, what I learn is that I am trying to bend the rules of Metacello > which is a rare use case :). I am thinking of avoiding this downgrading > altogether by forking to create my own ConfigOf that loads the correct > versions. Downgrading might be an anti-pattern. > > Thank you for your patient so far :) > > regards. > > > >> >> Dale >> [1] https://groups.google.com/forum/#!forum/metacello >> > > >

Jan. 8, 2015

Re: [Pharo-users] Question about loading Roassal2 in Pharo4

by stepharo

You understand what I wrote in the Pharo vision document about the process that we should get automated and in place before really be fully modular. Stef > Hi, > > Let's not panic :). > > The situation is like this: > - in Pharo 4, we have ConfigurationOfGlamourCore loaded which does not > have the Roassal2 presentation > - to get the Roassal2 presentation, you have to load > ConfigurationOfGlamour (so, the full Glamour) > - an extra problem can come from the configurations in the image not > being the latest versions so there can be loading incompatibilities > due to that. That is why, for the current Moose jobs we load manually > the latest versions of the ConfigurationOf* classes (fun). > - then you can use the GT-InspectorExtensions-CoreRoassal > > > This situation has to improve, but in the meantime, you can use the > gtoolkit or the moose 5.1 image which already has everything loaded > correctly. > > Cheers, > Doru > > > On Wed, Jan 7, 2015 at 2:26 PM, Alexandre Bergel > <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>> wrote: > > You also need Glamour-Roassal2-Presentations. But the last version > does not seem to load. > > Any idea how to fix this situation? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > On Jan 7, 2015, at 10:22 AM, Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>> wrote: > > > > Thx. > > > > I loaded GT-InspectorExtensions-CoreRoassal-AndreiChis.25 > > > > but then I get > > > > Author: SvenVanCaekenberghe > > Date: 2015-01-07T14:20:37.659713+01:00 > > > > GLMCompositePresentation(Object)>>doesNotUnderstand: #roassal2 > > RTView>>gtInspectorViewIn: > > [ :eachPragma | > > (eachPragma selector findTokens: $:) size = 1 > > ifTrue: [ self perform: eachPragma selector with: composite ]. > > (eachPragma selector findTokens: $:) size = 2 > > ifTrue: [ self perform: eachPragma selector with: > composite with: aGTInspector ] ] in > RTView(Object)>>gtInspectorPresentationsIn:inContext: > > Array(SequenceableCollection)>>do: > > RTView(Object)>>gtInspectorPresentationsIn:inContext: > > [ :d | each gtInspectorPresentationsIn: d inContext: self ] in [ > :x | (GLMCompositePresentation new with: [ :d | each > gtInspectorPresentationsIn: d inContext: self ]) startOn: x ] in [ > :a :each | > > a title: [ self printObjectAsAnItem: each ]. > > a dynamicActions: [ :aPresentation | each gtInspectorActions > asOrderedCollection ]. > > a titleAction: [ :aPresentation | self closeActionFor: > aPresentation ]. > > a dynamic > > display: [ :x | (GLMCompositePresentation new with: [ :d | > each gtInspectorPresentationsIn: d inContext: self ]) startOn: x ] > ] in [ :browser | > > browser fixedSizePanes: self class numberOfInspectorPanes. > > browser > > show: [ :a :each | > > a title: [ self printObjectAsAnItem: each ]. > > a dynamicActions: [ :aPresentation | each > gtInspectorActions asOrderedCollection ]. > > a titleAction: [ :aPresentation | self > closeActionFor: aPresentation ]. > > a dynamic > > display: [ :x | (GLMCompositePresentation > new with: [ :d | each gtInspectorPresentationsIn: d inContext: > self ]) startOn: x ] ] ] in GTInspector>>compose > > GLMCompositePresentation(GLMPresentation)>>with: > > [ :x | (GLMCompositePresentation new with: [ :d | each > gtInspectorPresentationsIn: d inContext: self ]) startOn: x ] in [ > :a :each | > > a title: [ self printObjectAsAnItem: each ]. > > a dynamicActions: [ :aPresentation | each gtInspectorActions > asOrderedCollection ]. > > a titleAction: [ :aPresentation | self closeActionFor: > aPresentation ]. > > a dynamic > > display: [ :x | (GLMCompositePresentation new with: [ :d | > each gtInspectorPresentationsIn: d inContext: self ]) startOn: x ] > ] in [ :browser | > > browser fixedSizePanes: self class numberOfInspectorPanes. > > browser > > show: [ :a :each | > > a title: [ self printObjectAsAnItem: each ]. > > a dynamicActions: [ :aPresentation | each > gtInspectorActions asOrderedCollection ]. > > a titleAction: [ :aPresentation | self > closeActionFor: aPresentation ]. > > a dynamic > > display: [ :x | (GLMCompositePresentation > new with: [ :d | each gtInspectorPresentationsIn: d inContext: > self ]) startOn: x ] ] ] in GTInspector>>compose > > BlockClosure>>glamourValueWithArgs: > > BlockClosure(Object)>>glamourValue: > > GLMDynamicPresentation(GLMPresentation)>>displayValue > > GLMDynamicPresentation>>currentPresentation > > GLMMorphicDynamicRenderer>>render: > > GLMMorphicDynamicRenderer class(GLMMorphicWidgetRenderer > class)>>render:from: > > GLMMorphicRenderer>>renderDynamicPresentation: > > GLMDynamicPresentation>>renderGlamorouslyOn: > > GLMMorphicRenderer(GLMRenderer)>>render: > > GLMMorphicTabbedRenderer(GLMMorphicWidgetRenderer)>>renderObject: > > > GLMMorphicTabbedRenderer(GLMMorphicWidgetRenderer)>>renderWithTitleOrNil: > > GLMMorphicTabbedRenderer>>render: > > GLMMorphicTabbedRenderer class(GLMMorphicWidgetRenderer > class)>>render:from: > > GLMMorphicRenderer>>renderTabbedCompositePresentation: > > GLMTabbedArrangement>>renderGlamorouslyOn: > > GLMCompositePresentation>>renderGlamorouslyOn: > > GLMMorphicRenderer(GLMRenderer)>>render: > > GLMMorphicPaneRenderer(GLMMorphicWidgetRenderer)>>renderObject: > > GLMMorphicPaneRenderer>>renderContainerFor: > > GLMMorphicPaneRenderer>>render: > > GLMMorphicPaneRenderer class(GLMMorphicWidgetRenderer > class)>>render:from: > > GLMMorphicRenderer>>renderPane: > > GLMPane>>renderGlamorouslyOn: > > GLMMorphicRenderer(GLMRenderer)>>render: > > GLMMorphicPagerRenderer(GLMMorphicWidgetRenderer)>>renderObject: > > GLMMorphicPagerRenderer>>actOnPaneReplaced: > > MessageSend>>value: > > MessageSend>>cull: > > MessageSend>>cull:cull: > > [ action cull: anAnnouncement cull: announcer ] in > AnnouncementSubscription>>deliver: > > BlockClosure>>on:do: > > [ Processor terminateActive ] in on: exception fork: handlerAction > > "Activate the receiver. In case of exception, fork a new > process, which will handle an error. > > An original process will continue running as if receiver > evaluation finished and answered nil, > > i.e., an expression like: > > > > [ self error: 'some error'] on: Error fork: [:ex | 123 ] > > > > will always answer nil for original process, not 123. > > > > The context stack , starting from context which sent this > message to receiver and > > up to the top of the stack will be transferred to forked > process, with handlerAction on top. > > (so when the forked process will be resuming, it will > enter the handlerAction) > > " > > > > ^ self > > on: exception > > do: [ :ex | > > | copy onDoCtx process handler bottom > thisCtx | > > onDoCtx := thisContext. > > thisCtx := onDoCtx home. "find the > context on stack for which this method's is sender" > > [ onDoCtx sender == thisCtx ] > > whileFalse: [ > > onDoCtx := onDoCtx sender. > > onDoCtx > > ifNil: [ > > "Can't find our home context. seems like we're already forked > > and handling another exception in > new thread. In this case, just pass it through handler." > > ^ handlerAction cull: ex ] ]. > > bottom := [ Processor terminateActive ] > asContext. > > onDoCtx privSender: bottom. > > handler := [ handlerAction cull: ex ] > asContext. > > handler privSender: thisContext sender. > > (Process forContext: handler priority: > Processor activePriority) resume. "cut the stack of current > process" > > thisContext privSender: thisCtx. > > nil ] in BlockClosure>>on:fork: > > > >> On 07 Jan 2015, at 14:15, Andrei Chis > <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> > wrote: > >> > >> Hi, > >> > >> There is one extra package that you need to load from the > GToolkit repository: GT-InspectorExtensions-CoreRoassal > >> It contains all the inspector extensions that depend on roassal > and thus cannot be integrated into Pharo. > >> > >> > >> Cheers, > >> Andrei > >> > >> On Wed, Jan 7, 2015 at 1:35 PM, Sven Van Caekenberghe > <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > >> Hi, > >> > >> I just loaded Roassal2 in Pharo4 using the following expression: > >> > >> Gofer it > >> smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; > >> configurationOf: 'Roassal2'; > >> loadStable. > >> > >> When I try one of the examples I see that I am missing some GT > presentations specific to Roassal. How should I load those ? > >> > >> <Screen Shot 2015-01-07 at 13.34.11.png> > >> > >> Thx, > >> > >> Sven > >> > >> > >> > >> > > > > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Jan. 8, 2015

Re: [Pharo-users] Metacello does not load the expected version from ConfigOf

by Dale Henrichs

Usman, No, I appreciate your patience:) If creating your own configuration works for you then that is a good route to go... Sharing your image will make it much easier for me to get the bottom of this (on my own schedule:), so please send me a link for accessing your image and I'll dig into this in more detail when I have time ... If you find yourself stuck and needing the `downgrade directive` again, I'll bump up the priority ... Dale On 01/07/2015 09:19 AM, Usman Bhatti wrote: > > > On Tue, Jan 6, 2015 at 6:56 PM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> wrote: > > > On 1/6/15 7:16 AM, Usman Bhatti wrote: >> Dale, >> >> I couldn't make it work with the upgraded Metacello and the >> script you provided. >> >> Steps I did: >> >> 1. Download moose image: >> https://ci.inria.fr/moose/job/moose-5.0/ >> >> 2. Update my Metacello to the 'full' version: >> Metacello new >> baseline: 'Metacello'; >> repository: >> 'github://dalehenrich/metacello-work:master/repository'; >> get. >> Metacello new >> baseline: 'Metacello'; >> repository: >> 'github://dalehenrich/metacello-work:master/repository'; >> onConflict: [:ex | ex allow]; >> load >> >> 3. File in the ConfigurationOfDummyParser (see the first message >> in the thread). >> >> 4. Run this script to downgrade to PetitParser version 1.51 >> >> Metacello new >> configuration: 'DummyParser'; >> version: '1.0'; >> repository: '???'; >> onDowngradeUseIncoming: #('PetitParser'); >> load. >> >> The desired version is still not loaded, am I missing something here? > Good question, I don't have a lot of time today to spend time > trying to reproduce your problem, but if you send me a copy of the > Transcript produced while doing the load I might be able to spot > the problem ... > > > It looks to me that the downgrade command is not working. Whenever I > point to the version preceding the one loaded, the packages are not > fetched. > > I am attaching here two files. > > The first (Transcript-PP151) is the output of the transcript as you > asked. You can see that PetitParser packages as defined by the version > 1.51 are not fetched. All that is loaded is Glamour because the > version 1.51 of PetitParser loads the latest packages of Glamour. The > load works because it is an upgrade from the current version of > Glamour which is a stable. > > When I saw that only Glamour packages are loaded, I thought of testing > Glamour downgrade too to see if the problem is specific to > PetitParser. You can see the result in the second file > (Transcript-downgrade-glamour). No packages of Glamour are fetched > because the configuration tries to downgrade it (stable is more recent > than 3.0.0 which I try to load). > > In my opinion, downgrade is not working as required. If you want I can > share my image thru dropbox so that you can have a look to see what > might be wrong. > > >> >> regards, >> >> A question: I always use Metacello with ConfigOf and have never >> used the scripting API myself or saw it being used elsewhere. >> Can you provide a link that describes the use cases for both: >> ConfigOf vs. Scripting API? > I've noticed the same thing:) > > My "elevator pitch" for the script api goes like this: > 1. The scripting api maintains a registry of the actual project > versions loaded into the image, > making #currentVersion obsolete. #currentVersion is bad > because it does a calculation of > the current version that can be very slow and sometimes > completely incorrect. > 2. The old api has rules that it follows when loading projects > (i.e., newer projects always win) and > there is no mechanism for altering those rules. The > scripting api provides mechanisms for > for bending those rules to fit your needs ... like allowing > a downgrade of a project. > > Part of the reason that people haven't changed has to do with how > incredibly difficult it is to change the existing inertia. Another > part of it is that I continue to support the old way of doing > things, so there is no explicit motivation to change. > > If you look back 2-3 years in the archives of the Metacello > mailing list[1] you should be able to find a number of posts where > I make a more detailed cases for the scripting api:) > > At the end of the day, it isn't important to me to "get people to > use the scripting api," as I said, I continue to support using the > old api. I figure that when enough people start asking questions > about how to "bend the Metacello rules" that folks will begin to > use the "new" scripting api:) > > > So, what I learn is that I am trying to bend the rules of Metacello > which is a rare use case :). I am thinking of avoiding this > downgrading altogether by forking to create my own ConfigOf that loads > the correct versions. Downgrading might be an anti-pattern. > > Thank you for your patient so far :) > > regards. > > > Dale > [1] https://groups.google.com/forum/#!forum/metacello > <https://groups.google.com/forum/#%21forum/metacello> > >

Jan. 7, 2015

Re: [Pharo-users] ZnHTTPSTests>>#testTransfers fails

by Mark Rizun

Good to know, thanks. 2015-01-07 19:54 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi Mark, > > It is a torture test, downloading differently sized files from a know > source, stressing the handling of multiple buffers/chunks internally in the > HTTPS streams. > > Tests like these sometimes fail because of networking problems in the VMs > running the CI machinery. 99.99% of the time this resolves on the next run. > > Sven > > > On 07 Jan 2015, at 18:10, Mark Rizun <mrizun(a)gmail.com> wrote: > > > > Hi, > > > > In case 14254 validation report says that ZnHTTPSTests>>#testTransfers > > fails. > > However when I merged slice and tested it, the test was green. > > Can I somehow solve this, or maybe it's something with system? > > Btw, just interesting, what this test is responsible for? > > > > Thanks, > > Mark > > > > > > > > -- > > View this message in context: > http://forum.world.st/ZnHTTPSTests-testTransfers-fails-tp4798216.html > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > >

Jan. 7, 2015

Re: [Pharo-users] ZnHTTPSTests>>#testTransfers fails

by Sven Van Caekenberghe

Hi Mark, It is a torture test, downloading differently sized files from a know source, stressing the handling of multiple buffers/chunks internally in the HTTPS streams. Tests like these sometimes fail because of networking problems in the VMs running the CI machinery. 99.99% of the time this resolves on the next run. Sven > On 07 Jan 2015, at 18:10, Mark Rizun <mrizun(a)gmail.com> wrote: > > Hi, > > In case 14254 validation report says that ZnHTTPSTests>>#testTransfers > fails. > However when I merged slice and tested it, the test was green. > Can I somehow solve this, or maybe it's something with system? > Btw, just interesting, what this test is responsible for? > > Thanks, > Mark > > > > -- > View this message in context: http://forum.world.st/ZnHTTPSTests-testTransfers-fails-tp4798216.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Jan. 7, 2015

Making the halo around windows preview more contrasted

by Offray Vladimir Luna CÃ¡rdenas

Hi all, As usual, when I put the mouse over the name of a window, a small preview appears with a grey allow with the full name of the window, but letters are white surrounded by a pale grey making the full name really difficult to read. There is any way to increase the contrast there between font and background? Thanks, Offray

Jan. 7, 2015

Re: [Pharo-users] Metacello does not load the expected version from ConfigOf

by Usman Bhatti

On Tue, Jan 6, 2015 at 6:56 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > > On 1/6/15 7:16 AM, Usman Bhatti wrote: > > Dale, > > I couldn't make it work with the upgraded Metacello and the script you > provided. > > Steps I did: > > 1. Download moose image: > https://ci.inria.fr/moose/job/moose-5.0/ > > 2. Update my Metacello to the 'full' version: > Metacello new > baseline: 'Metacello'; > repository: 'github://dalehenrich/metacello-work:master/repository'; > get. > Metacello new > baseline: 'Metacello'; > repository: 'github://dalehenrich/metacello-work:master/repository'; > onConflict: [:ex | ex allow]; > load > > 3. File in the ConfigurationOfDummyParser (see the first message in the > thread). > > 4. Run this script to downgrade to PetitParser version 1.51 > > Metacello new > configuration: 'DummyParser'; > version: '1.0'; > repository: '???'; > onDowngradeUseIncoming: #('PetitParser'); > load. > > The desired version is still not loaded, am I missing something here? > > Good question, I don't have a lot of time today to spend time trying to > reproduce your problem, but if you send me a copy of the Transcript > produced while doing the load I might be able to spot the problem ... > It looks to me that the downgrade command is not working. Whenever I point to the version preceding the one loaded, the packages are not fetched. I am attaching here two files. The first (Transcript-PP151) is the output of the transcript as you asked. You can see that PetitParser packages as defined by the version 1.51 are not fetched. All that is loaded is Glamour because the version 1.51 of PetitParser loads the latest packages of Glamour. The load works because it is an upgrade from the current version of Glamour which is a stable. When I saw that only Glamour packages are loaded, I thought of testing Glamour downgrade too to see if the problem is specific to PetitParser. You can see the result in the second file (Transcript-downgrade-glamour). No packages of Glamour are fetched because the configuration tries to downgrade it (stable is more recent than 3.0.0 which I try to load). In my opinion, downgrade is not working as required. If you want I can share my image thru dropbox so that you can have a look to see what might be wrong. > > > regards, > > A question: I always use Metacello with ConfigOf and have never used the > scripting API myself or saw it being used elsewhere. > Can you provide a link that describes the use cases for both: ConfigOf vs. > Scripting API? > > I've noticed the same thing:) > > My "elevator pitch" for the script api goes like this: > 1. The scripting api maintains a registry of the actual project versions > loaded into the image, > making #currentVersion obsolete. #currentVersion is bad because it > does a calculation of > the current version that can be very slow and sometimes completely > incorrect. > 2. The old api has rules that it follows when loading projects (i.e., > newer projects always win) and > there is no mechanism for altering those rules. The scripting api > provides mechanisms for > for bending those rules to fit your needs ... like allowing a > downgrade of a project. > > Part of the reason that people haven't changed has to do with how > incredibly difficult it is to change the existing inertia. Another part of > it is that I continue to support the old way of doing things, so there is > no explicit motivation to change. > > If you look back 2-3 years in the archives of the Metacello mailing > list[1] you should be able to find a number of posts where I make a more > detailed cases for the scripting api:) > > At the end of the day, it isn't important to me to "get people to use the > scripting api," as I said, I continue to support using the old api. I > figure that when enough people start asking questions about how to "bend > the Metacello rules" that folks will begin to use the "new" scripting api:) > So, what I learn is that I am trying to bend the rules of Metacello which is a rare use case :). I am thinking of avoiding this downgrading altogether by forking to create my own ConfigOf that loads the correct versions. Downgrading might be an anti-pattern. Thank you for your patient so far :) regards. > > Dale > [1] https://groups.google.com/forum/#!forum/metacello >

Jan. 7, 2015

Re: [Pharo-users] ZnHTTPSTests>>#testTransfers fails

by Mark Rizun

The links for issue: https://pharo.fogbugz.com/f/cases/14254/AST-method-replaceWith-does-not-cha… and report: https://ci.inria.fr/pharo/job/Pharo-4.0-Issue-Validator/21421//artifact/val… 2015-01-07 19:10 GMT+02:00 Mark Rizun <mrizun(a)gmail.com>: > Hi, > > In case 14254 validation report says that ZnHTTPSTests>>#testTransfers > fails. > However when I merged slice and tested it, the test was green. > Can I somehow solve this, or maybe it's something with system? > Btw, just interesting, what this test is responsible for? > > Thanks, > Mark > > > > -- > View this message in context: > http://forum.world.st/ZnHTTPSTests-testTransfers-fails-tp4798216.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Jan. 7, 2015

ZnHTTPSTests>>#testTransfers fails

by Mark Rizun

Hi, In case 14254 validation report says that ZnHTTPSTests>>#testTransfers fails. However when I merged slice and tested it, the test was green. Can I somehow solve this, or maybe it's something with system? Btw, just interesting, what this test is responsible for? Thanks, Mark -- View this message in context: http://forum.world.st/ZnHTTPSTests-testTransfers-fails-tp4798216.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Jan. 7, 2015