October 2019 - Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #835: Move the #errorNotKeyed message from Collection to Bag

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #835 was: SUCCESS. The Pull Request #4835 was integrated: "Move the #errorNotKeyed message from Collection to Bag" Pull request url: https://github.com/pharo-project/pharo/pull/4835 Issue Url: https://github.com/pharo-project/pharo/issues/4808 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 5, 2019

[Pharo 8.0] Build #834: 4833-Better-class-comment-for-RegexRefactorings

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #834 was: FAILURE. The Pull Request #4834 was integrated: "4833-Better-class-comment-for-RegexRefactorings" Pull request url: https://github.com/pharo-project/pharo/pull/4834 Issue Url: https://github.com/pharo-project/pharo/issues/4833 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 5, 2019

Re: [Pharo-dev] looking for the baselineoffuel

by ducasse

thanks! > On 5 Oct 2019, at 14:27, Norbert Hartl <norbert(a)hartl.name> wrote: > > https://github.com/theseion/Fuel/tree/master/repository/BaselineOfFuel.pack… <https://github.com/theseion/Fuel/tree/master/repository/BaselineOfFuel.pack…> > > Notbert > > Am 05.10.2019 um 10:05 schrieb ducasse <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>>: > >> Hi >> >> I would like to depend on fuel for a project and I cannot find the baselinein the image. >> Is there one somewhere and where can I find it. >> >> Tx >> >> >> >>

Oct. 5, 2019

Re: [Pharo-dev] looking for the baselineoffuel

by Norbert Hartl

https://github.com/theseion/Fuel/tree/master/repository/BaselineOfFuel.pack… Notbert > Am 05.10.2019 um 10:05 schrieb ducasse <stepharo(a)netcourrier.com>: > > Hi > > I would like to depend on fuel for a project and I cannot find the baselinein the image. > Is there one somewhere and where can I find it. > > Tx > > > >

Oct. 5, 2019

looking for the baselineoffuel

by ducasse

Hi I would like to depend on fuel for a project and I cannot find the baselinein the image. Is there one somewhere and where can I find it. Tx

Oct. 5, 2019

Re: [Pharo-dev] Seg Fault Pharo 7.0.3

by Sven Van Caekenberghe

> On 5 Oct 2019, at 04:48, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Sven Van Caekenberghe-2 wrote >> Are you using full screen mode ? > > The window was probably maximized, but not in fullscreen OK, that is not the same, that should work.

Oct. 5, 2019

Re: [Pharo-dev] XmlSupport on GitHub?

by ducasse

I would suggest to not wait for monty and do it. May be his life attracted in another sphere and this is ok too. Or may be he does not have cycles now. Stef > On 5 Oct 2019, at 00:09, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > Yes - this is still the current state that there only is a copy of Pharo's XML project available on Svens github account. > > I suggested in [1] to have a more central/official community place on https://github.com/pharo-contributions location > and offered a helping hand for the migration. If I remember correctly Peter offered help as well. > > But for the migration to GH it would be good to also know about Monty's github username (as I wrote in [3]) - so far there was > NO FURTHER RESPONSE from Monty's side and therefore no further activity in moving XML code to github more officially. > > Bye > T. > > [1] http://forum.world.st/Status-of-XML-Support-s-move-to-GitHub-tt5093297.html > [2] https://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2019-March/2747… > [3] https://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2019-March/2747… > > >> Gesendet: Freitag, 04. Oktober 2019 um 12:43 Uhr >> Von: "Sven Van Caekenberghe" <sven(a)stfx.eu> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: Re: [Pharo-dev] XmlSupport on GitHub? >> >> >> >>> On 4 Oct 2019, at 12:37, BenoÃ®t Verhaeghe <badetitou(a)gmail.com> wrote: >>> >>> Hello, >>> >>> I think this is what you're looking for >>> https://github.com/svenvc/XML-Support-Pharo >>> >>> (but maybe not) >> >> Indeed, this is just a dirty 'last-version-only' copy, definitively *not* the final solutions. >> >>> BenoÃ®t >>> >>> Le ven. 4 oct. 2019 Ã 12:29, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : >>> Hi, >>> >>> Did anyone port XmlSupport to GitHub? >>> >>> Cheers, >>> Tudor >>> >>> >>> -- >>> feenk.com >>> >>> âHow do you feenk today?" >>> >>> >> >> >> >

Oct. 5, 2019

Re: [Pharo-dev] BlockClosures - Equality and Things

by ducasse

Hi sean just a question since I started to finally understand for real the multiple objects that closures represent :) Would it not make sense to have internally an object (not a closure) that represent a method and that answer the method value or value: You could save this object and on potentially even generate a block if needed. I do not think that in magritte we use the closuring aspect of closure we use them as anonymous method. Stef > On 5 Oct 2019, at 04:58, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > While developing Magritte, I have a problem because blocks that are > read/written to/from strings (e.g. via Magritte forms) have a different > outerContext before and after and thus I don't know how (without an ugly > hack) to determine whether they were changed by the user. > > Question: Is there a smarter way to do block equality? > Currently in Pharo block comparison is via #==. In Squeak, there is: > BlockClosure >> #= aClosure > self == aClosure ifTrue: [^true]. > aClosure class = self class ifFalse: [^false]. > (self method == aClosure method and: [startpc = aClosure startpc > and: [self > isClean]]) "<--- this line" > ifTrue: [^true]. > ^outerContext = aClosure outerContext and: [startpc = aClosure > startpc] Do you know if they have the new closure model because we are working to move to it. > > I'm not totally sold on the implementation due to the `startpc = aClosure > startpc` the first time it appears (in the comment-marked line). With it, in > a workspace, the following is false: `[1] = [1]`, but removing that test > makes it true. I'd like something that returns true if both blocks are clean > and they "do the same thing". But I like the track it's on... > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Oct. 5, 2019

BlockClosures - Equality and Things

by Sean P. DeNigris

While developing Magritte, I have a problem because blocks that are read/written to/from strings (e.g. via Magritte forms) have a different outerContext before and after and thus I don't know how (without an ugly hack) to determine whether they were changed by the user. Question: Is there a smarter way to do block equality? Currently in Pharo block comparison is via #==. In Squeak, there is: BlockClosure >> #= aClosure self == aClosure ifTrue: [^true]. aClosure class = self class ifFalse: [^false]. (self method == aClosure method and: [startpc = aClosure startpc and: [self isClean]]) "<--- this line" ifTrue: [^true]. ^outerContext = aClosure outerContext and: [startpc = aClosure startpc] I'm not totally sold on the implementation due to the `startpc = aClosure startpc` the first time it appears (in the comment-marked line). With it, in a workspace, the following is false: `[1] = [1]`, but removing that test makes it true. I'd like something that returns true if both blocks are clean and they "do the same thing". But I like the track it's on... ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 5, 2019

Re: [Pharo-dev] Seg Fault Pharo 7.0.3

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > Are you using full screen mode ? The window was probably maximized, but not in fullscreen ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 5, 2019