- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Build 739 breaks project load initialization order?

by Max Leske

I can confirm that class side #initialization is broken. Don't know since when though. Cheers, Max On 29 March 2018 at 08:28:00, Martin McClure (martin(a)hand2mouse.com) wrote: Good to know. In my case, however, I'm always loading code into a fresh image where these classes don't previously exist, so I would think that #initialize would always be sent. On 03/28/2018 10:32 PM, Sven Van Caekenberghe wrote: > class side #initialize is only send by MC if the incoming source code is different, has changed. I always add a date in a comment to be sure. > >> On 29 Mar 2018, at 04:47, Martin McClure <martin(a)hand2mouse.com> wrote: >> >> On 03/28/2018 04:35 PM, Martin McClure wrote: >>> I have a project that loads via Metacello in builds up through build >>> 738. In 739 the load fails with DNU. >>> >>> The failure is in a method I have specified via a #postLoadDoIt:. It >>> fails because it sends a message to a pool variable, which is nil. >>> However, it should not be nil because it should have been initialized by >>> a class-side #initialize method in a prerequisite package. >>> >>> Again, this worked up through build 738. Any idea what changed in 739 >>> that would cause this, and is this change intentional? >> Odd, I don't see any code changes that would be likely to have caused this. >> >> Is the expected behavior of Metacello to send #initialize to classes in >> prerequisite packages before running a #postLoadDoIt in a package? I'd >> think so, but am starting to wonder if this is perhaps unordered and >> I've just been lucky... >> >> -Martin >

March 29, 2018

Re: [Pharo-dev] Build 739 breaks project load initialization order?

by Martin McClure

Good to know. In my case, however, I'm always loading code into a fresh image where these classes don't previously exist, so I would think that #initialize would always be sent. On 03/28/2018 10:32 PM, Sven Van Caekenberghe wrote: > class side #initialize is only send by MC if the incoming source code is different, has changed. I always add a date in a comment to be sure. > >> On 29 Mar 2018, at 04:47, Martin McClure <martin(a)hand2mouse.com> wrote: >> >> On 03/28/2018 04:35 PM, Martin McClure wrote: >>> I have a project that loads via Metacello in builds up through build >>> 738. In 739 the load fails with DNU. >>> >>> The failure is in a method I have specified via a #postLoadDoIt:. It >>> fails because it sends a message to a pool variable, which is nil. >>> However, it should not be nil because it should have been initialized by >>> a class-side #initialize method in a prerequisite package. >>> >>> Again, this worked up through build 738. Any idea what changed in 739 >>> that would cause this, and is this change intentional? >> Odd, I don't see any code changes that would be likely to have caused this. >> >> Is the expected behavior of Metacello to send #initialize to classes in >> prerequisite packages before running a #postLoadDoIt in a package? I'd >> think so, but am starting to wonder if this is perhaps unordered and >> I've just been lucky... >> >> -Martin >

March 29, 2018

Re: [Pharo-dev] Build 739 breaks project load initialization order?

by Sven Van Caekenberghe

class side #initialize is only send by MC if the incoming source code is different, has changed. I always add a date in a comment to be sure. > On 29 Mar 2018, at 04:47, Martin McClure <martin(a)hand2mouse.com> wrote: > > On 03/28/2018 04:35 PM, Martin McClure wrote: >> I have a project that loads via Metacello in builds up through build >> 738. In 739 the load fails with DNU. >> >> The failure is in a method I have specified via a #postLoadDoIt:. It >> fails because it sends a message to a pool variable, which is nil. >> However, it should not be nil because it should have been initialized by >> a class-side #initialize method in a prerequisite package. >> >> Again, this worked up through build 738. Any idea what changed in 739 >> that would cause this, and is this change intentional? > Odd, I don't see any code changes that would be likely to have caused this. > > Is the expected behavior of Metacello to send #initialize to classes in > prerequisite packages before running a #postLoadDoIt in a package? I'd > think so, but am starting to wonder if this is perhaps unordered and > I've just been lucky... > > -Martin

March 29, 2018

Re: [Pharo-dev] Build 739 breaks project load initialization order?

by Martin McClure

On 03/28/2018 04:35 PM, Martin McClure wrote: > I have a project that loads via Metacello in builds up through build > 738. In 739 the load fails with DNU. > > The failure is in a method I have specified via a #postLoadDoIt:. It > fails because it sends a message to a pool variable, which is nil. > However, it should not be nil because it should have been initialized by > a class-side #initialize method in a prerequisite package. > > Again, this worked up through build 738. Any idea what changed in 739 > that would cause this, and is this change intentional? Odd, I don't see any code changes that would be likely to have caused this. Is the expected behavior of Metacello to send #initialize to classes in prerequisite packages before running a #postLoadDoIt in a package? I'd think so, but am starting to wonder if this is perhaps unordered and I've just been lucky... -Martin

March 29, 2018

Re: [Pharo-dev] [Reflectivity] change regarding announcement in Pharo7

by Tudor Girba

Hi, Interesting. What exactly is slow? The installation of a meta link? How slower is it? Cheers, Doru > On Mar 28, 2018, at 4:03 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > One questionable (but practical) thing that MetaLinks have is that they announce (MetalinkChanged) when they are installed or uninstalled. > This is nice for being able to show them in the UI (and e.g. the Watcher implemented with them). > > But it is very very slowâ¦ so I now made it an option: > > https://github.com/pharo-project/pharo/pull/1160 > > it is by default off, but can be turned on reflectively at any point. > > > e.g. the link of the execution counter now looks like this: > > link := MetaLink new > metaObject: self; > selector: #increase; > optionAnnounce: true. > > It has announcing enable so that the browser refreshes when it gets added or removed. > > Marcus -- www.tudorgirba.com www.feenk.com "Speaking louder won't make the point worthier."

March 29, 2018

Build 739 breaks project load initialization order?

by Martin McClure

I have a project that loads via Metacello in builds up through build 738. In 739 the load fails with DNU. The failure is in a method I have specified via a #postLoadDoIt:. It fails because it sends a message to a pool variable, which is nil. However, it should not be nil because it should have been initialized by a class-side #initialize method in a prerequisite package. Again, this worked up through build 738. Any idea what changed in 739 that would cause this, and is this change intentional? Thanks, -Martin

March 28, 2018

Re: [Pharo-dev] Some segfault crashes and freezes when trying to re-run saved pharo 7 images

by Eliot Miranda

Hi Holger, On Mon, Mar 26, 2018 at 8:32 AM, Holger Freyther <holger(a)freyther.de> wrote: > > > > On 26. Mar 2018, at 00:00, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > Hi Holger, > > Hey! > > > > Is the intent of CCallOut with: aBlock to collect and defer > deallocations until the block completes? I think it's nice but complex and > wonder how general it is. But it seems like it would impact a lot of code > and require a lot of effort changing existing code bases. My handle scheme > is only intended to fix the issue of images crashing on startup. The > problems with crashing on startup being a) one loses one's work and b) the > issue is hard to debug. That, for me, motivates something like the simple > fix I p[roposed. I'm not standing in the way of something more beautiful, > but I do believe that one shouldn't make the perfect the enemy of the good. > > By all means, let's have a smart pointer! It will be beneficial for > freetype and many other places. Nobody likes crashing images (for a mistake > made in a previous run). > > > My intent with the CCallOut is inhibit image saving until the code is > outside a sequence of (interruptible, hence the backward jump int the > example) C calls working with one or more pieces of manually managed > memory. But maybe it is best to call it by what it does instead of finding > a name of where it is used. > > I can't come up with a better example right now. But I think a > Smartpointer wouldn't be of much help with a sequence of strtok calls. > > word := CStringAPI strtok: cStringPtr safeBytes separator: '\r'. > [word isNil] whileFalse: [ > word = 'Foo'... > word = 'Bla'... > word := CStringAPI strtok: nil separator: '\r' > ------------- Image Save happening right here and word is not nil ----- > ]. > > I hope this is more clear. > Right. So the VM could have a flag that, when set, causes the snapshot primitive to fail, and that flag would be cleared only when all FFI cals had unwound. Would that be enough? What would you have the image do if snapshot fails because FFI calls are in progress? > holger > _,,,^..^,,,_ best, Eliot

March 28, 2018

Re: [Pharo-dev] [ANN] HighchartsSt and ba-st Web Stack new versions available

by Sean P. DeNigris

gcotelli wrote > We're happy to announce a new version of the Highcharts JS Wrapper and the > Web Stack hosted at https://github.com/ba-st/. Sounds great, thanks! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 28, 2018

[ANN] HighchartsSt and ba-st Web Stack new versions available

by Gabriel Cotelli

Hi, We're happy to announce a new version of the Highcharts JS Wrapper and the Web Stack hosted at https://github.com/ba-st/. This is a multi-release announcement of the following related project versions: - HighchartsSt <https://github.com/ba-st/HighchartsSt> v6.0.0 - Updated Highcharts and Highstock JS libraries to version 6.0.3 - Improved Importing Tools - Improved Travis CI integration - Willow <https://github.com/ba-st/Willow> v7.0.0. Changes since latest announcement: - Added composition of table row commands - Refactored a bunch of common utilities into it's own project - Improved JSScript extensions - Willow-Bootstrap <https://github.com/ba-st/Willow-Bootstrap> v7.0.0 - Updated Willow base support to v7.0.0 - Improved Radio Web Views - Willow-JQueryUI <https://github.com/ba-st/Willow-JQueryUI> v6.0.0 - Updated Willow base support to v7.0.0 - Improved Radio Web Views - Willow-SpinKit <https://github.com/ba-st/Willow-SpinKit> v4.0.0 - Updated Willow base support to v7.0.0 - Willow-Playground <https://github.com/ba-st/Willow-Playground/> v3.0.0 - Updated dependencies to the latest versions - You can now grab a ready to use image from the releases page - RenoirSt <https://github.com/ba-st/RenoirSt> v4.1.0 - Add another way of creating descendant combinators for cases when the right part of the expression needs parenthesis - Updated dependencies SemanticUI <https://github.com/ba-st/Willow-SemanticUI> and Materialize CSS <https://github.com/fortizpenaloza/Willow-Materialize> integration are still a work in progress. Find a more detailed changelog and migration instructions on the release pages of each repository. Special thanks to Ignacio Martinez <https://github.com/nachomf> and Juan Escalada <https://github.com/JuanEscalada> for contributing some of the new features. Also to Maxi Tabacman and Mariano Martinez Peck for the Highcharts update. Anyone interested in joining our ba-st projects <https://github.com/ba-st/> is welcomed, and you can also get some interesting ideas in crafting lint rules to support team coding standards <https://medium.com/mercap-tech-blog/supporting-team-coding-standards-af2701…> . Regards, Gabriel Cotelli, Maxi Tabacman and all the contributors.

March 28, 2018

[Pharo 7.0-dev] Build #739: 21620-Modularize-Pharo-Launcher-dependent-Baselines

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

There is a new Pharo build available! The status of the build #739 was: SUCCESS. The Pull Request #1130 was integrated: "21620-Modularize-Pharo-Launcher-dependent-Baselines" Pull request url: https://github.com/pharo-project/pharo/pull/1130 Issue Url: https://pharo.fogbugz.com/f/cases/21620 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 28, 2018