December 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Catalog Entries

by Alistair Grant

Hi Sven, On Wed, 19 Dec 2018 at 10:46, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > On 19 Dec 2018, at 08:50, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Hi Sven, > > > > On Tue, 18 Dec 2018 at 12:55, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> I know about master and what it means, but that is not exactly what I want. > >> > >> When you release, that is a deliberate action: you put a stamp on the current project timeline, declaring it as ready/stable enough for people to depend on. > >> > >> The master branch can further evolve after a (latest) release. It is the next release candidate. > >> > >> I would like to depend on whatever released version is the latest. See the URLs in my previous email. > > > > I think your understanding of master is different from mine. master > > should never be the next release candidate, it is only ever the latest > > GA code. > > > > In that case, you can use master to mean "the latest GA version". > > > > If you want release candidates, they should be branches off > > development (or tags). > > > > If you want to support multiple versions, e.g. be able to release a > > 4.1 after 5.0 has been released, then each version should be branched > > off master (at the GA commit for that version). > > > > If you want to know where a named GA version is (and there won't be > > further updates), it is a tag on the master branch. > > I don't think/believe there is only one right way to use git, that is part of its power. Agreed, and I can see how you read my reply that way, but I didn't mean to imply that "this is the one and only right way to do it". > In our eco system, with #stable and #bleedingEdge / #development versions of ConfigurationsOf, it is my experience that very few people test before something is released. Hence the only way to get feedback is to release. Only if something has proven itself to be stable for some time can it receive a release tag, IMHO. OK, so what I understand you're try to achieve is to have a "released" version and a "released and better tested" version. Doesn't this run the same risk of people just sticking to the "released and better tested" version, so the "released" version never gets the additional testing that's desired? > I also want to make things as simple as possible. :-) Cheers, Alistair

Dec. 19, 2018

[Pharo 7.0] Build #59: 22806 Small cleanups in EmbeddedFreeTypeFontInstallerTest

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

There is a new Pharo build available! The status of the build #59 was: SUCCESS. The Pull Request #2099 was integrated: "22806 Small cleanups in EmbeddedFreeTypeFontInstallerTest" Pull request url: https://github.com/pharo-project/pharo/pull/2099 Issue Url: https://pharo.fogbugz.com/f/cases/22806 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 19, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

> On 19 Dec 2018, at 08:50, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Sven, > > On Tue, 18 Dec 2018 at 12:55, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> I know about master and what it means, but that is not exactly what I want. >> >> When you release, that is a deliberate action: you put a stamp on the current project timeline, declaring it as ready/stable enough for people to depend on. >> >> The master branch can further evolve after a (latest) release. It is the next release candidate. >> >> I would like to depend on whatever released version is the latest. See the URLs in my previous email. > > I think your understanding of master is different from mine. master > should never be the next release candidate, it is only ever the latest > GA code. > > In that case, you can use master to mean "the latest GA version". > > If you want release candidates, they should be branches off > development (or tags). > > If you want to support multiple versions, e.g. be able to release a > 4.1 after 5.0 has been released, then each version should be branched > off master (at the GA commit for that version). > > If you want to know where a named GA version is (and there won't be > further updates), it is a tag on the master branch. I don't think/believe there is only one right way to use git, that is part of its power. In our eco system, with #stable and #bleedingEdge / #development versions of ConfigurationsOf, it is my experience that very few people test before something is released. Hence the only way to get feedback is to release. Only if something has proven itself to be stable for some time can it receive a release tag, IMHO. I also want to make things as simple as possible. > Cheers, > Alistair

Dec. 19, 2018

Re: [Pharo-dev] Catalog Entries

by Alistair Grant

Hi Sven, On Tue, 18 Dec 2018 at 12:55, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I know about master and what it means, but that is not exactly what I want. > > When you release, that is a deliberate action: you put a stamp on the current project timeline, declaring it as ready/stable enough for people to depend on. > > The master branch can further evolve after a (latest) release. It is the next release candidate. > > I would like to depend on whatever released version is the latest. See the URLs in my previous email. I think your understanding of master is different from mine. master should never be the next release candidate, it is only ever the latest GA code. In that case, you can use master to mean "the latest GA version". If you want release candidates, they should be branches off development (or tags). If you want to support multiple versions, e.g. be able to release a 4.1 after 5.0 has been released, then each version should be branched off master (at the GA commit for that version). If you want to know where a named GA version is (and there won't be further updates), it is a tag on the master branch. Cheers, Alistair

Dec. 19, 2018

Re: [Pharo-dev] Huge Critiques Area in Calypso in Pharo 7

by Denis Kudriashov

Hi Petr. Setting would be nice. I did not know about it in Nautilus Ð²Ñ, 18 Ð´ÐµÐº. 2018 Ð³. Ð² 14:44, Petr Fischer via Pharo-dev < pharo-dev(a)lists.pharo.org>: > I have that feeling too - critiques pane is annoying + occupying too much > place - what about showing critiques inline only (in the line nubers and > breakpoint markers left pane)? > > This choice existed for the old Nautilus browser - but I can't find it for > Calypso. > > pf > > > I am seeing a huge (multiline, ~ 5 to 7 lines) high 'critiques' area at > the bottom of Calypso browsers in Pharo 7 (dl today), see screenshot: > > > > > > Why is that ? I can't resize it to be smaller. > > On a smaller screen this takes up way too much space. > > Can't we have a widget to remove/collapse that area ? Not a setting. > > > > Sven > > > >

Dec. 18, 2018

Re: [Pharo-dev] Huge Critiques Area in Calypso in Pharo 7

by Denis Kudriashov

Hi Sven. I did little change in Pharo https://github.com/pharo-project/pharo/pull/2096. The best would be to have floating/docking layout of such panes like in other IDEs. Probably easy to do in Bloc but not in Morphic Ð¿Ð½, 17 Ð´ÐµÐº. 2018 Ð³. Ð² 18:52, Sven Van Caekenberghe <sven(a)stfx.eu>: > Thanks, Denis, for the swift reply. > What is the solution, though ? > What do you think should happen ? > Make the constant smaller, like the height of 1 row ? > > > On 17 Dec 2018, at 18:42, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > > Hi Sven. > > > > I checked problem and found following method: > > > > FTTableMorph >> minHeight > > ^ 100 > > > > It prevents full critiques widget to be small. > > > > There is probably a bug in morphic which does not set up this "correct" > extent by default. In my case when I browse your method in fresh image only > three rows are visible in critiques view. But as soon as I start resizing > this pane it becomes bigger and unminimizable. > > > > Ð¿Ð½, 17 Ð´ÐµÐº. 2018 Ð³. Ð² 17:14, Sven Van Caekenberghe <sven(a)stfx.eu>: > > I am seeing a huge (multiline, ~ 5 to 7 lines) high 'critiques' area at > the bottom of Calypso browsers in Pharo 7 (dl today), see screenshot: > > > > <Screenshot 2018-12-17 at 17.19.35.png> > > Why is that ? I can't resize it to be smaller. > > On a smaller screen this takes up way too much space. > > Can't we have a widget to remove/collapse that area ? Not a setting. > > > > Sven > > > > >

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

> On 18 Dec 2018, at 17:34, Ben Coman <btc(a)openinworld.com> wrote: > > To understand for future reference, just curious what you ended up doing. > At https://github.com/svenvc/ztimestamp/releases > I see the v24 tag is commit ee31f06 > > but at https://github.com/svenvc/ztimestamp/network > I see the latest-release branch is commit b18dfdf > > It looks like you v24 of ConfigurationOfZTimestamp was committed after v24 tag was created. > Intuitively I'd expect the them to be the same commit. Was there something impediment to doing that > or you have a different idea? Well, I did make a mistake, I committed the change to the ConfigurationOf on the latest-release branch, so I had to PR and merge to master. But apart from that it was a chicken-egg problem (as far as I can see), that won't happen in the future, then it will be just the merge of the release tag into the latest-release branch, as you described earlier. We'll see, learning along the way. > cheers -ben > > On Tue, 18 Dec 2018 at 23:42, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Ben, Torsten, > > I decided to go for the branch option, > > https://github.com/svenvc/ztimestamp/tree/latest-release > > I will extend the ConfigurationOf to refer to it for Pharo 6.1 and 7 > > Thanks for all the help. > > > On 18 Dec 2018, at 16:29, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > Ben wrote > >> "If the tag is edited on the server, but the local one is old" > > > > Yes - there could be an issue with this "tag moving" approach if the server is not checked > > for new tags / moved tags and the version from the local repo cache is loaded - because > > you might load an outdated while the server already has a newer "latest-release". > > > > When I think a second time I guess what Sven wants could maybe also be achieved with another > > model: > > > > - having the "master" branch for development and tagged releases 1.0, 2.0, 3.0 and so on > > - having a second "latest-release" branch where the current latest tag from master is just pulled/merged in > > Anytime you make a new release version in master you just pull it into this "latest-release" branch > > > > This has several benefits: > > > > - you can use the same stable load expression with stable URL: github://svenvc/ztimestamp:latest-release > > - you just tag in master as usual > > - when a new release was tagged in master you just switch to the "latest-release" branch, pull from master > > and push to github (easier than tag moving) > > - the graph ("Insights" -> "Network") shows you if you already pulled the latest tagged version from master > > into the "latest-release" branch and also shows you how far ahead you are with master in case of further > > development > > > > Also when the latest release has some trouble but your master development is not yet ready for a full new version > > you can hot-fix it in the "latest-release" branch to help people. Later when you are ready with another full new > > version you will have the branches resynched then anyway. > > > > I'm not sure if this model also has some drawbacks - but as it looks now this seems a better option... > > > > Bye > > T. > > > > > > > > > > > > > >

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Ben Coman

To understand for future reference, just curious what you ended up doing. At https://github.com/svenvc/ztimestamp/releases I see the v24 tag is commit ee31f06 but at https://github.com/svenvc/ztimestamp/network I see the latest-release branch is commit b18dfdf It looks like you v24 of ConfigurationOfZTimestamp was committed after v24 tag was created. Intuitively I'd expect the them to be the same commit. Was there something impediment to doing that or you have a different idea? cheers -ben On Tue, 18 Dec 2018 at 23:42, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Ben, Torsten, > > I decided to go for the branch option, > > https://github.com/svenvc/ztimestamp/tree/latest-release > > I will extend the ConfigurationOf to refer to it for Pharo 6.1 and 7 > > Thanks for all the help. > > > On 18 Dec 2018, at 16:29, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > Ben wrote > >> "If the tag is edited on the server, but the local one is old" > > > > Yes - there could be an issue with this "tag moving" approach if the > server is not checked > > for new tags / moved tags and the version from the local repo cache is > loaded - because > > you might load an outdated while the server already has a newer > "latest-release". > > > > When I think a second time I guess what Sven wants could maybe also be > achieved with another > > model: > > > > - having the "master" branch for development and tagged releases 1.0, > 2.0, 3.0 and so on > > - having a second "latest-release" branch where the current latest tag > from master is just pulled/merged in > > Anytime you make a new release version in master you just pull it into > this "latest-release" branch > > > > This has several benefits: > > > > - you can use the same stable load expression with stable URL: > github://svenvc/ztimestamp:latest-release > > - you just tag in master as usual > > - when a new release was tagged in master you just switch to the > "latest-release" branch, pull from master > > and push to github (easier than tag moving) > > - the graph ("Insights" -> "Network") shows you if you already pulled > the latest tagged version from master > > into the "latest-release" branch and also shows you how far ahead you > are with master in case of further > > development > > > > Also when the latest release has some trouble but your master > development is not yet ready for a full new version > > you can hot-fix it in the "latest-release" branch to help people. Later > when you are ready with another full new > > version you will have the branches resynched then anyway. > > > > I'm not sure if this model also has some drawbacks - but as it looks now > this seems a better option... > > > > Bye > > T. > > > > > > > > > > > > > > >

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

> On 18 Dec 2018, at 16:41, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I will extend the ConfigurationOf to refer to it for Pharo 6.1 and 7 https://github.com/svenvc/ztimestamp/commit/2eadc5d1730ca24d2a946b7b7bbb6b1… is a commit that changes ConfigurationOfZTimestamp by adding a version 24 that refers to the latest-release branch on git for pharo 6.1 and up. I copied that Config into the repos of 60 and 70. We'll see what that gives with respect to the Catalog.

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

Ben, Torsten, I decided to go for the branch option, https://github.com/svenvc/ztimestamp/tree/latest-release I will extend the ConfigurationOf to refer to it for Pharo 6.1 and 7 Thanks for all the help. > On 18 Dec 2018, at 16:29, Torsten Bergmann <astares(a)gmx.de> wrote: > > Ben wrote >> "If the tag is edited on the server, but the local one is old" > > Yes - there could be an issue with this "tag moving" approach if the server is not checked > for new tags / moved tags and the version from the local repo cache is loaded - because > you might load an outdated while the server already has a newer "latest-release". > > When I think a second time I guess what Sven wants could maybe also be achieved with another > model: > > - having the "master" branch for development and tagged releases 1.0, 2.0, 3.0 and so on > - having a second "latest-release" branch where the current latest tag from master is just pulled/merged in > Anytime you make a new release version in master you just pull it into this "latest-release" branch > > This has several benefits: > > - you can use the same stable load expression with stable URL: github://svenvc/ztimestamp:latest-release > - you just tag in master as usual > - when a new release was tagged in master you just switch to the "latest-release" branch, pull from master > and push to github (easier than tag moving) > - the graph ("Insights" -> "Network") shows you if you already pulled the latest tagged version from master > into the "latest-release" branch and also shows you how far ahead you are with master in case of further > development > > Also when the latest release has some trouble but your master development is not yet ready for a full new version > you can hot-fix it in the "latest-release" branch to help people. Later when you are ready with another full new > version you will have the branches resynched then anyway. > > I'm not sure if this model also has some drawbacks - but as it looks now this seems a better option... > > Bye > T. > > > > > >

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Torsten Bergmann

Ben wrote >"If the tag is edited on the server, but the local one is old" Yes - there could be an issue with this "tag moving" approach if the server is not checked for new tags / moved tags and the version from the local repo cache is loaded - because you might load an outdated while the server already has a newer "latest-release". When I think a second time I guess what Sven wants could maybe also be achieved with another model: - having the "master" branch for development and tagged releases 1.0, 2.0, 3.0 and so on - having a second "latest-release" branch where the current latest tag from master is just pulled/merged in Anytime you make a new release version in master you just pull it into this "latest-release" branch This has several benefits: - you can use the same stable load expression with stable URL: github://svenvc/ztimestamp:latest-release - you just tag in master as usual - when a new release was tagged in master you just switch to the "latest-release" branch, pull from master and push to github (easier than tag moving) - the graph ("Insights" -> "Network") shows you if you already pulled the latest tagged version from master into the "latest-release" branch and also shows you how far ahead you are with master in case of further development Also when the latest release has some trouble but your master development is not yet ready for a full new version you can hot-fix it in the "latest-release" branch to help people. Later when you are ready with another full new version you will have the branches resynched then anyway. I'm not sure if this model also has some drawbacks - but as it looks now this seems a better option... Bye T.

Dec. 18, 2018

[Pharo 7.0] Build #58: 22797 deprecated file does not exist should be moved to deprecated70 package

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

There is a new Pharo build available! The status of the build #58 was: FAILURE. The Pull Request #2092 was integrated: "22797 deprecated file does not exist should be moved to deprecated70 package" Pull request url: https://github.com/pharo-project/pharo/pull/2092 Issue Url: https://pharo.fogbugz.com/f/cases/22797 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 18, 2018

Re: [Pharo-dev] possible QA rule - cascading to class

by Christopher Fuhrman

Hi Ben, On Tue, 18 Dec 2018 at 14:52, Ben Coman <btc(a)openinworld.com> wrote: > In case someone close to managing the QA rules is interested... on discord > it > was suggested that this form of cascading might be a trap for newcomers. > > x := MyClass new; foo > > I've never seen similar in practice, so it might make a good QA rule. > It currently raises "Sends unknown message to global" > but I'd guess a more specific message that actually mentions > "cascading" could be possible. > > I was the one who brought it up on Discord, being it seems the forever newbie with Pharo... It's worse if you have a class-side method. The error is "Instance of X class did not understand #foo", which is evil to newbies because an "instance of [a] class" seems like it should be an object, and I *did* have a message of type "foo" defined. Here's the real case with a screenshot: [image: image.png] Cheers, Christopher > cheers -ben > >

Dec. 18, 2018

possible QA rule - cascading to class

by Ben Coman

In case someone close to managing the QA rules is interested... on discord it was suggested that this form of cascading might be a trap for newcomers. x := MyClass new; foo I've never seen similar in practice, so it might make a good QA rule. It currently raises "Sends unknown message to global" but I'd guess a more specific message that actually mentions "cascading" could be possible. cheers -ben

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

> On 18 Dec 2018, at 14:23, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Tue, 18 Dec 2018 at 21:01, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > El mar., 18 dic. 2018 a las 9:53, Sven Van Caekenberghe > (<sven(a)stfx.eu>) escribiÃ³: > > > > So let us agree on the best name then, to minimise confusion going forward. > > > > I am not sure I would go for camel case, git is typically lowercase (or so it feels), I agree 'release' should be part of the name, so > > > > last-release > > latest-release > > lastRelease > > latestRelease > > Following "gittish" conventions, IMO `latest-release` would be the > proper name because "last" suggests me there won't be more releases > afterwards. > > Good point. +1. > > But I wonder if moving tags is really a good idea. I've not practical experience with it > but reading section "If the tag is edited on the server, but the local one is old" > http://blog.iqandreas.com/git/how-to-move-tags/ > it seems potentially complicated. > > Whereas if latest-release was a branch, after you version tag your release you could do... > $ git checkout latest-release > $ git merge tagversion > $ git push > > And side benefit, latest-release would show up in the github > Insights > Network view > to easily inspect what changes have been made since latest-release. > > cheers -ben interesting. since both a branch and a moving tag look the same from the reference standpoint, this could be considered an implementation detail, the repo maintainer could switch later on, while the URL would remain github://svenvc/ztimestamp:latest-release

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Ben Coman

On Tue, 18 Dec 2018 at 21:01, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > El mar., 18 dic. 2018 a las 9:53, Sven Van Caekenberghe > (<sven(a)stfx.eu>) escribiÃ³: > > > > So let us agree on the best name then, to minimise confusion going > forward. > > > > I am not sure I would go for camel case, git is typically lowercase (or > so it feels), I agree 'release' should be part of the name, so > > > > last-release > > latest-release > > lastRelease > > latestRelease > > Following "gittish" conventions, IMO `latest-release` would be the > proper name because "last" suggests me there won't be more releases > afterwards. > Good point. +1. But I wonder if moving tags is really a good idea. I've not practical experience with it but reading section "If the tag is edited on the server, but the local one is old" http://blog.iqandreas.com/git/how-to-move-tags/ it seems potentially complicated. Whereas if latest-release was a branch, after you version tag your release you could do... $ git checkout latest-release $ git merge tagversion $ git push And side benefit, latest-release would show up in the github > Insights > Network view to easily inspect what changes have been made since latest-release. cheers -ben

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Torsten Bergmann

JOKING: "lastRelease" is fine, there is no release afterwards anymore as it is completed by 100% ;) SERIOUS: "latest-release" seems appropriate

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Esteban Maringolo

El mar., 18 dic. 2018 a las 9:53, Sven Van Caekenberghe (<sven(a)stfx.eu>) escribiÃ³: > > So let us agree on the best name then, to minimise confusion going forward. > > I am not sure I would go for camel case, git is typically lowercase (or so it feels), I agree 'release' should be part of the name, so > > last-release > latest-release > lastRelease > latestRelease Following "gittish" conventions, IMO `latest-release` would be the proper name because "last" suggests me there won't be more releases afterwards. Regards, Esteban A. Maringolo

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

So let us agree on the best name then, to minimise confusion going forward. I am not sure I would go for camel case, git is typically lowercase (or so it feels), I agree 'release' should be part of the name, so last-release latest-release lastRelease latestRelease What say you ? > On 18 Dec 2018, at 13:45, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Tue, 18 Dec 2018 at 19:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I am trying to load https://github.com/svenvc/ztimestamp/releases/latest which is actually https://github.com/svenvc/ztimestamp/releases/tag/v24 > > The following works because that is the whole idea of releases (which are just tags) > > Metacello new > baseline: 'ZTimestamp'; > repository: 'github://svenvc/ztimestamp:v24'; > load. > > But I would like to do > > Metacello new > baseline: 'ZTimestamp'; > repository: 'github://svenvc/ztimestamp:latest'; > > This might be something good to have as a community convention, > but "latest" on its own is a bit ambiguous. Reading your subsequent post > maybe "latestRelease" would be good (or "lastRelease"), > to distinguish "latestStable" which is similar but not necessarily a release. > > (or maybe I'm being too pedantic) > cheers -ben > > load. > > Maybe that is not possible, maybe that has to be done in another way. > > I know about master or other branch names, I was hoping latest was moving/tracking like https://github.com/svenvc/ztimestamp/releases/latest does > > > On 18 Dec 2018, at 12:05, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > > > > > On Tue, Dec 18, 2018 at 12:00 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > > > On 17 Dec 2018, at 20:18, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > > > Model 1: Work with a single branch and close a release using a tag as version in git > > > =================================================================================== > > > This is I guess how Iceberg, Calypso and others are maintained now. You work on a specific (development) branch and > > > use the git tagging to mark release like milestone of your project ("versions"). > > > > > > This is the model I started to maintain ConfigurationOfTealight (which you will find in catalog > > > and in https://github.com/astares/Tealight) > > > > > > So I tagged in git when I reached something shareable as you can see on the first releases: https://github.com/astares/Tealight/releases > > > and then reference this git tagged version in my ConfigurationOfTealight: > > > > > > v0_0_4: spec > > > <version: '0.0.4'> > > > > > > spec for: #'common' do: [ > > > spec blessing: #'stable'. > > > spec > > > baseline: 'Tealight' with: [ > > > spec > > > className: 'BaselineOfTealight'; > > > repository: 'github://astares/Tealight:0.0.4/repository' ]] > > > > > > > > > The advantage is that you use git to tag the releases, it is a reproducable stable version then and GitHub shows it on > > > the "releases" tab. One typically can not modify the release afterwards (which is not 100% true as git tags could be moved but this is > > > another story). > > > > > > So with this model you form and finalize/close a release by tagging in git/GitHub and reference it in your ConfigurationOf.... > > > > Would it not be possible to refer to the latest release ? For example: > > > > > github://astares/Tealight:latest/repository > > > > That way one would no longer have to update the ConfigurationOf (just like the BaselineOf does not have to be updated), just making a new release would be enough. > > > > I tried, but I get Revspec 'latest' not found. > > > > I'm following the conversation in diagonal, but if this error is raised by metacello's iceberg integration it would mean that Tealight has no commitish (tag/branch) with the name latest.

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

Yes that is what I want, I hoped it already existed, by yes we can use a tag that we move with each release. > On 18 Dec 2018, at 13:45, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi Sven, > > so if I understood you correctly you want a single branch for development - lets assume you directly use > master for that. > > If you just load the branch you get the "latest development" things that are still > work in progress. > > Then from time to time you tag a version for release: 1.0, 2.0, 3.0 in your master branch. > > If today 3.0 is your latest release they should have a load expression to load 3.0. > If tomorrow you tag a new release 4.0 you want to them to use the same load expression to > get the "latest released". > > Right? > > There is no specific meta-tag for that. But as a tag is nothing more than a string applied to a commit for later reference > you could additionally tag the commit of 3.0 with a tag "latest" or "latestRelease" and then later (after 4.0 is released) > move this tag to the commit that was used for building a new 4.0. > > I have not tried but as you could delete and/or move tags in git this should be doable in git without any > problem. Just google for "tag moving" and "git". > > Metacello itself does not care - it then will use > > Metacello new > baseline: 'ZTimestamp'; > repository: 'github://svenvc/ztimestamp:latestRelease'; > load. > > to ask git for the tag. But it is your responsibility to move the tag "latestRelease" forward manually anytime > you do a new release. > > As you usually tag locally - remember to push the tags afterwards. Double checking afterwards in GitHub helps > here. The command > > git push -f --tags > > could be helpful here. > > Hope this solves what you require. > > Thanks > Torsten > > > > > > > >> Gesendet: Dienstag, 18. Dezember 2018 um 12:54 Uhr >> Von: "Sven Van Caekenberghe" <sven(a)stfx.eu> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: Re: [Pharo-dev] Catalog Entries >> >> >> >>> On 18 Dec 2018, at 12:48, Torsten Bergmann <astares(a)gmx.de> wrote: >>> >>> Hi Sven, >>> >>> did you try to just use the branch name as in the other model. >>> >>> Metacello new >>> baseline: 'ZTimestamp'; >>> repository: 'github://svenvc/ztimestamp:master'; >>> load. >>> >>> then it should load the latest from this branch independent from the >>> tags. >>> >>> Bye >>> T. >> >> I know about master and what it means, but that is not exactly what I want. >> >> When you release, that is a deliberate action: you put a stamp on the current project timeline, declaring it as ready/stable enough for people to depend on. >> >> The master branch can further evolve after a (latest) release. It is the next release candidate. >> >> I would like to depend on whatever released version is the latest. See the URLs in my previous email. >> >> >> >

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Torsten Bergmann

Hi Sven, so if I understood you correctly you want a single branch for development - lets assume you directly use master for that. If you just load the branch you get the "latest development" things that are still work in progress. Then from time to time you tag a version for release: 1.0, 2.0, 3.0 in your master branch. If today 3.0 is your latest release they should have a load expression to load 3.0. If tomorrow you tag a new release 4.0 you want to them to use the same load expression to get the "latest released". Right? There is no specific meta-tag for that. But as a tag is nothing more than a string applied to a commit for later reference you could additionally tag the commit of 3.0 with a tag "latest" or "latestRelease" and then later (after 4.0 is released) move this tag to the commit that was used for building a new 4.0. I have not tried but as you could delete and/or move tags in git this should be doable in git without any problem. Just google for "tag moving" and "git". Metacello itself does not care - it then will use Metacello new baseline: 'ZTimestamp'; repository: 'github://svenvc/ztimestamp:latestRelease'; load. to ask git for the tag. But it is your responsibility to move the tag "latestRelease" forward manually anytime you do a new release. As you usually tag locally - remember to push the tags afterwards. Double checking afterwards in GitHub helps here. The command git push -f --tags could be helpful here. Hope this solves what you require. Thanks Torsten > Gesendet: Dienstag, 18. Dezember 2018 um 12:54 Uhr > Von: "Sven Van Caekenberghe" <sven(a)stfx.eu> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Catalog Entries > > > > > On 18 Dec 2018, at 12:48, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > Hi Sven, > > > > did you try to just use the branch name as in the other model. > > > > Metacello new > > baseline: 'ZTimestamp'; > > repository: 'github://svenvc/ztimestamp:master'; > > load. > > > > then it should load the latest from this branch independent from the > > tags. > > > > Bye > > T. > > I know about master and what it means, but that is not exactly what I want. > > When you release, that is a deliberate action: you put a stamp on the current project timeline, declaring it as ready/stable enough for people to depend on. > > The master branch can further evolve after a (latest) release. It is the next release candidate. > > I would like to depend on whatever released version is the latest. See the URLs in my previous email. > > >

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Ben Coman

On Tue, 18 Dec 2018 at 19:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I am trying to load https://github.com/svenvc/ztimestamp/releases/latest > which is actually https://github.com/svenvc/ztimestamp/releases/tag/v24 > > The following works because that is the whole idea of releases (which are > just tags) > > Metacello new > baseline: 'ZTimestamp'; > repository: 'github://svenvc/ztimestamp:v24'; > load. > > But I would like to do > > Metacello new > baseline: 'ZTimestamp'; > repository: 'github://svenvc/ztimestamp:latest'; > This might be something good to have as a community convention, but "latest" on its own is a bit ambiguous. Reading your subsequent post maybe "latestRelease" would be good (or "lastRelease"), to distinguish "latestStable" which is similar but not necessarily a release. (or maybe I'm being too pedantic) cheers -ben load. > > Maybe that is not possible, maybe that has to be done in another way. > > I know about master or other branch names, I was hoping latest was > moving/tracking like https://github.com/svenvc/ztimestamp/releases/latest > does > > > On 18 Dec 2018, at 12:05, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > > > > > > On Tue, Dec 18, 2018 at 12:00 PM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > > > > On 17 Dec 2018, at 20:18, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > > > Model 1: Work with a single branch and close a release using a tag as > version in git > > > > =================================================================================== > > > This is I guess how Iceberg, Calypso and others are maintained now. > You work on a specific (development) branch and > > > use the git tagging to mark release like milestone of your project > ("versions"). > > > > > > This is the model I started to maintain ConfigurationOfTealight (which > you will find in catalog > > > and in https://github.com/astares/Tealight) > > > > > > So I tagged in git when I reached something shareable as you can see > on the first releases: https://github.com/astares/Tealight/releases > > > and then reference this git tagged version in my > ConfigurationOfTealight: > > > > > > v0_0_4: spec > > > <version: '0.0.4'> > > > > > > spec for: #'common' do: [ > > > spec blessing: #'stable'. > > > spec > > > baseline: 'Tealight' with: [ > > > spec > > > className: 'BaselineOfTealight'; > > > repository: > 'github://astares/Tealight:0.0.4/repository' ]] > > > > > > > > > The advantage is that you use git to tag the releases, it is a > reproducable stable version then and GitHub shows it on > > > the "releases" tab. One typically can not modify the release > afterwards (which is not 100% true as git tags could be moved but this is > > > another story). > > > > > > So with this model you form and finalize/close a release by tagging in > git/GitHub and reference it in your ConfigurationOf.... > > > > Would it not be possible to refer to the latest release ? For example: > > > > > github://astares/Tealight:latest/repository > > > > That way one would no longer have to update the ConfigurationOf (just > like the BaselineOf does not have to be updated), just making a new release > would be enough. > > > > I tried, but I get Revspec 'latest' not found. > > > > I'm following the conversation in diagonal, but if this error is raised > by metacello's iceberg integration it would mean that Tealight has no > commitish (tag/branch) with the name latest. > > >

Dec. 18, 2018

[Pharo 7.0] Build #57: 22780 Fix uncategorized classes in MonticelloGUI

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

There is a new Pharo build available! The status of the build #57 was: FAILURE. The Pull Request #2078 was integrated: "22780 Fix uncategorized classes in MonticelloGUI" Pull request url: https://github.com/pharo-project/pharo/pull/2078 Issue Url: https://pharo.fogbugz.com/f/cases/22780 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

> On 18 Dec 2018, at 12:48, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi Sven, > > did you try to just use the branch name as in the other model. > > Metacello new > baseline: 'ZTimestamp'; > repository: 'github://svenvc/ztimestamp:master'; > load. > > then it should load the latest from this branch independent from the > tags. > > Bye > T. I know about master and what it means, but that is not exactly what I want. When you release, that is a deliberate action: you put a stamp on the current project timeline, declaring it as ready/stable enough for people to depend on. The master branch can further evolve after a (latest) release. It is the next release candidate. I would like to depend on whatever released version is the latest. See the URLs in my previous email.

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Torsten Bergmann

Hi Sven, did you try to just use the branch name as in the other model. Metacello new baseline: 'ZTimestamp'; repository: 'github://svenvc/ztimestamp:master'; load. then it should load the latest from this branch independent from the tags. Bye T.

Dec. 18, 2018

[Pharo 7.0] Build #56: 22760 RBRefactoryClassChange should define #isAbstract with true

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

There is a new Pharo build available! The status of the build #56 was: FAILURE. The Pull Request #2084 was integrated: "22760 RBRefactoryClassChange should define #isAbstract with true" Pull request url: https://github.com/pharo-project/pharo/pull/2084 Issue Url: https://pharo.fogbugz.com/f/cases/22760 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

I am trying to load https://github.com/svenvc/ztimestamp/releases/latest which is actually https://github.com/svenvc/ztimestamp/releases/tag/v24 The following works because that is the whole idea of releases (which are just tags) Metacello new baseline: 'ZTimestamp'; repository: 'github://svenvc/ztimestamp:v24'; load. But I would like to do Metacello new baseline: 'ZTimestamp'; repository: 'github://svenvc/ztimestamp:latest'; load. Maybe that is not possible, maybe that has to be done in another way. I know about master or other branch names, I was hoping latest was moving/tracking like https://github.com/svenvc/ztimestamp/releases/latest does > On 18 Dec 2018, at 12:05, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > On Tue, Dec 18, 2018 at 12:00 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 17 Dec 2018, at 20:18, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > Model 1: Work with a single branch and close a release using a tag as version in git > > =================================================================================== > > This is I guess how Iceberg, Calypso and others are maintained now. You work on a specific (development) branch and > > use the git tagging to mark release like milestone of your project ("versions"). > > > > This is the model I started to maintain ConfigurationOfTealight (which you will find in catalog > > and in https://github.com/astares/Tealight) > > > > So I tagged in git when I reached something shareable as you can see on the first releases: https://github.com/astares/Tealight/releases > > and then reference this git tagged version in my ConfigurationOfTealight: > > > > v0_0_4: spec > > <version: '0.0.4'> > > > > spec for: #'common' do: [ > > spec blessing: #'stable'. > > spec > > baseline: 'Tealight' with: [ > > spec > > className: 'BaselineOfTealight'; > > repository: 'github://astares/Tealight:0.0.4/repository' ]] > > > > > > The advantage is that you use git to tag the releases, it is a reproducable stable version then and GitHub shows it on > > the "releases" tab. One typically can not modify the release afterwards (which is not 100% true as git tags could be moved but this is > > another story). > > > > So with this model you form and finalize/close a release by tagging in git/GitHub and reference it in your ConfigurationOf.... > > Would it not be possible to refer to the latest release ? For example: > > > github://astares/Tealight:latest/repository > > That way one would no longer have to update the ConfigurationOf (just like the BaselineOf does not have to be updated), just making a new release would be enough. > > I tried, but I get Revspec 'latest' not found. > > I'm following the conversation in diagonal, but if this error is raised by metacello's iceberg integration it would mean that Tealight has no commitish (tag/branch) with the name latest.

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Alexandre Bergel

I believe it is important to remove obsolete entries in the catalog. Having a new empty MetaRepo for each Pharo version seems like a good strategy. Forcing people to republish their configurations when necessary is a good filtering mechanism. Cheers, Alexandre > On Dec 17, 2018, at 1:16 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > So we have the Catalog with version specific repositories for ConfigurationOfXYZ packages/classes. > > I am assuming that we will be keeping this system for at least Pharo 7 and possibly 8. > > Can one define Catalog entries using BaselineOfXYZ ? > Is that recommended ? > Or should a mostly empty ConfigurationOfXYZ be used that internally refers to the BaselineOfXYZ ? > > Sven > >

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Guillermo Polito

On Tue, Dec 18, 2018 at 12:00 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 17 Dec 2018, at 20:18, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > Model 1: Work with a single branch and close a release using a tag as > version in git > > > =================================================================================== > > This is I guess how Iceberg, Calypso and others are maintained now. You > work on a specific (development) branch and > > use the git tagging to mark release like milestone of your project > ("versions"). > > > > This is the model I started to maintain ConfigurationOfTealight (which > you will find in catalog > > and in https://github.com/astares/Tealight) > > > > So I tagged in git when I reached something shareable as you can see on > the first releases: https://github.com/astares/Tealight/releases > > and then reference this git tagged version in my ConfigurationOfTealight: > > > > v0_0_4: spec > > <version: '0.0.4'> > > > > spec for: #'common' do: [ > > spec blessing: #'stable'. > > spec > > baseline: 'Tealight' with: [ > > spec > > className: 'BaselineOfTealight'; > > repository: > 'github://astares/Tealight:0.0.4/repository' ]] > > > > > > The advantage is that you use git to tag the releases, it is a > reproducable stable version then and GitHub shows it on > > the "releases" tab. One typically can not modify the release afterwards > (which is not 100% true as git tags could be moved but this is > > another story). > > > > So with this model you form and finalize/close a release by tagging in > git/GitHub and reference it in your ConfigurationOf.... > > Would it not be possible to refer to the latest release ? For example: > > > github://astares/Tealight:latest/repository > > That way one would no longer have to update the ConfigurationOf (just like > the BaselineOf does not have to be updated), just making a new release > would be enough. > > I tried, but I get Revspec 'latest' not found. > I'm following the conversation in diagonal, but if this error is raised by metacello's iceberg integration it would mean that Tealight has no commitish (tag/branch) with the name latest.

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

> On 17 Dec 2018, at 20:18, Torsten Bergmann <astares(a)gmx.de> wrote: > > Model 1: Work with a single branch and close a release using a tag as version in git > =================================================================================== > This is I guess how Iceberg, Calypso and others are maintained now. You work on a specific (development) branch and > use the git tagging to mark release like milestone of your project ("versions"). > > This is the model I started to maintain ConfigurationOfTealight (which you will find in catalog > and in https://github.com/astares/Tealight) > > So I tagged in git when I reached something shareable as you can see on the first releases: https://github.com/astares/Tealight/releases > and then reference this git tagged version in my ConfigurationOfTealight: > > v0_0_4: spec > <version: '0.0.4'> > > spec for: #'common' do: [ > spec blessing: #'stable'. > spec > baseline: 'Tealight' with: [ > spec > className: 'BaselineOfTealight'; > repository: 'github://astares/Tealight:0.0.4/repository' ]] > > > The advantage is that you use git to tag the releases, it is a reproducable stable version then and GitHub shows it on > the "releases" tab. One typically can not modify the release afterwards (which is not 100% true as git tags could be moved but this is > another story). > > So with this model you form and finalize/close a release by tagging in git/GitHub and reference it in your ConfigurationOf.... Would it not be possible to refer to the latest release ? For example: > github://astares/Tealight:latest/repository That way one would no longer have to update the ConfigurationOf (just like the BaselineOf does not have to be updated), just making a new release would be enough. I tried, but I get Revspec 'latest' not found.

Dec. 18, 2018

[Pharo 7.0] Build #55: 22801 Small cleanups in TRBProgramNodeVisitor

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

There is a new Pharo build available! The status of the build #55 was: SUCCESS. The Pull Request #2093 was integrated: "22801 Small cleanups in TRBProgramNodeVisitor" Pull request url: https://github.com/pharo-project/pharo/pull/2093 Issue Url: https://pharo.fogbugz.com/f/cases/22801 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Ben Coman

On Tue, 18 Dec 2018 at 03:19, Torsten Bergmann <astares(a)gmx.de> wrote: > > Model 2: Work with several open branches - one per Pharo version > ================================================================ > > In DesktopManager which is on > https://github.com/astares/Pharo-DesktopManager I do it differently. I > wanted to maintain it for Pharo7 > now but wanted to still easily backport changes to Pharo 6. > > For this project I maintain therefore two special branches "pharo6" and > "pharo7" - each for a particular Pharo version. > > This allows me to maintain the differences between the Pharo 6 and Pharo 7 > version by using the two distinguished branches > and backport from the "pharo7" branch easily to the "pharo6" branch if > necessary. > In the past I've contemplated that this form might be a good way to manage cross-platform code, but also having a "master" and merge from there into each "pharo6" , "pharo7" , "squeakN" platform-branch if/when they get some git tools. The workflow might then be that users of a particular platform push can issue a PR to that particular platform-branch to make the changes easy to see, and integrate into "master" if useful. cheers -ben The second model fits better if you provide packages that you would like to > maintain for several Pharo versions from 6.0 > onwards. I now also use it to maintain "QuickAccess", "OSWindows", > "OSUnix", ... and others. >

Dec. 18, 2018

Re: [Pharo-dev] Huge Critiques Area in Calypso in Pharo 7

by Petr Fischer

I have that feeling too - critiques pane is annoying + occupying too much place - what about showing critiques inline only (in the line nubers and breakpoint markers left pane)? This choice existed for the old Nautilus browser - but I can't find it for Calypso. pf > I am seeing a huge (multiline, ~ 5 to 7 lines) high 'critiques' area at the bottom of Calypso browsers in Pharo 7 (dl today), see screenshot: > > > Why is that ? I can't resize it to be smaller. > On a smaller screen this takes up way too much space. > Can't we have a widget to remove/collapse that area ? Not a setting. > > Sven >

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

Hi Torsten, Thanks for the clear explication, I think I will most probably go for scenario 1, but it is good to at least know about scenario 2. I'll sure come back if I cannot get this working on my own. Sven > On 17 Dec 2018, at 20:18, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi Sven, > > Maybe we have better ideas when we move forward with the transition to git for the majority of external > projects. But for the time being I guess we stick to Catalog as a replacement is still not available. > It might not be the best solution - but at least it works. The only downside is that it is still dependent > on SmalltalkHub due to the MetaRepos hosted there. > > To answer your questions: > > For Pharo 7.0 there is a regular MetaRepo > > http://www.smalltalkhub.com/#!/~Pharo/MetaRepoForPharo70 > > that one can use. The (re)indexing each day is still based on providing a ConfigurationOf... there. > We will create a MetaRepoForPharo80 once Pharo 7 is released and Pharo 8 work starts. > > Catalog also does not work directly with BaselineOf - so you point from your ConfigurationOf to a BaselineOf in Github > as the examples below will demonstrate. > > So while the basic mechanism of Catalog did not change and works as before the usage of git and GitHub gives you now more > flexibility in the management of your (catalog) projects. > > I already use this for a few of my projects that I moved to GitHub and I would share some experience here. > Basically I tried now two different models: > > Model 1: Work with a single branch and close a release using a tag as version in git > =================================================================================== > This is I guess how Iceberg, Calypso and others are maintained now. You work on a specific (development) branch and > use the git tagging to mark release like milestone of your project ("versions"). > > This is the model I started to maintain ConfigurationOfTealight (which you will find in catalog > and in https://github.com/astares/Tealight) > > So I tagged in git when I reached something shareable as you can see on the first releases: https://github.com/astares/Tealight/releases > and then reference this git tagged version in my ConfigurationOfTealight: > > v0_0_4: spec > <version: '0.0.4'> > > spec for: #'common' do: [ > spec blessing: #'stable'. > spec > baseline: 'Tealight' with: [ > spec > className: 'BaselineOfTealight'; > repository: 'github://astares/Tealight:0.0.4/repository' ]] > > > The advantage is that you use git to tag the releases, it is a reproducable stable version then and GitHub shows it on > the "releases" tab. One typically can not modify the release afterwards (which is not 100% true as git tags could be moved but this is > another story). > > So with this model you form and finalize/close a release by tagging in git/GitHub and reference it in your ConfigurationOf.... > > Model 2: Work with several open branches - one per Pharo version > ================================================================ > > In DesktopManager which is on https://github.com/astares/Pharo-DesktopManager I do it differently. I wanted to maintain it for Pharo7 > now but wanted to still easily backport changes to Pharo 6. > > For this project I maintain therefore two special branches "pharo6" and "pharo7" - each for a particular Pharo version. > > So in the ConfigurationOfDesktop as you will find in MetaRepoForPharo70 I just point to the Baseline > with only the difference of the branch: > > ------------------------------------------------------------------------------------------------------------ > pharo6: spec > <version: '6.0'> > > spec for: #'common' do: [ > spec > baseline: 'DesktopManager' with: [ > spec > className: 'BaselineOfDesktopManager'; > repository: 'github://astares/Pharo-DesktopManager:pharo6/src' ]] > ------------------------------------------------------------------------------------------------------------ > pharo7: spec > <version: '7.0'> > > spec for: #'common' do: [ > spec > baseline: 'DesktopManager' with: [ > spec > className: 'BaselineOfDesktopManager'; > repository: 'github://astares/Pharo-DesktopManager:pharo7/src' ]] > ------------------------------------------------------------------------------------------------------------ > stable: spec > <symbolicVersion: #'stable'> > > spec for: #'pharo5.x' version: '0.2.0'. "old way using versioning with Monticello/Metacello and StHub" > spec for: #'pharo6.x' version: '6.0'. "still open version branch from Pharo 6 using git and GitHub" > spec for: #'pharo7.x' version: '7.0'. "still open version branch from Pharo 7 using git and GitHub" > ------------------------------------------------------------------------------------------------------------ > > This allows me to maintain the differences between the Pharo 6 and Pharo 7 version by using the two distinguished branches > and backport from the "pharo7" branch easily to the "pharo6" branch if necessary. > > As no tagging with explicit versioning is involved here the branch for each Pharo version is always open for new > additions/future fixes. > > The first model is close to what one is used to from the past: having reproducible fixed tagged versions referenced > from the ConfigurationOf... > > The second model fits better if you provide packages that you would like to maintain for several Pharo versions from 6.0 > onwards. I now also use it to maintain "QuickAccess", "OSWindows", "OSUnix", ... and others. > > Hope this helps a little bit. If not just ask. > > Have fun > T. > > >> Gesendet: Montag, 17. Dezember 2018 um 17:16 Uhr >> Von: "Sven Van Caekenberghe" <sven(a)stfx.eu> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: [Pharo-dev] Catalog Entries >> >> Hi, >> >> So we have the Catalog with version specific repositories for ConfigurationOfXYZ packages/classes. >> >> I am assuming that we will be keeping this system for at least Pharo 7 and possibly 8. >> >> Can one define Catalog entries using BaselineOfXYZ ? >> Is that recommended ? >> Or should a mostly empty ConfigurationOfXYZ be used that internally refers to the BaselineOfXYZ ? >> >> Sven >> >> >> >

Dec. 17, 2018

Re: [Pharo-dev] Catalog Entries

by Torsten Bergmann

Hi Sven, Maybe we have better ideas when we move forward with the transition to git for the majority of external projects. But for the time being I guess we stick to Catalog as a replacement is still not available. It might not be the best solution - but at least it works. The only downside is that it is still dependent on SmalltalkHub due to the MetaRepos hosted there. To answer your questions: For Pharo 7.0 there is a regular MetaRepo http://www.smalltalkhub.com/#!/~Pharo/MetaRepoForPharo70 that one can use. The (re)indexing each day is still based on providing a ConfigurationOf... there. We will create a MetaRepoForPharo80 once Pharo 7 is released and Pharo 8 work starts. Catalog also does not work directly with BaselineOf - so you point from your ConfigurationOf to a BaselineOf in Github as the examples below will demonstrate. So while the basic mechanism of Catalog did not change and works as before the usage of git and GitHub gives you now more flexibility in the management of your (catalog) projects. I already use this for a few of my projects that I moved to GitHub and I would share some experience here. Basically I tried now two different models: Model 1: Work with a single branch and close a release using a tag as version in git =================================================================================== This is I guess how Iceberg, Calypso and others are maintained now. You work on a specific (development) branch and use the git tagging to mark release like milestone of your project ("versions"). This is the model I started to maintain ConfigurationOfTealight (which you will find in catalog and in https://github.com/astares/Tealight) So I tagged in git when I reached something shareable as you can see on the first releases: https://github.com/astares/Tealight/releases and then reference this git tagged version in my ConfigurationOfTealight: v0_0_4: spec <version: '0.0.4'> spec for: #'common' do: [ spec blessing: #'stable'. spec baseline: 'Tealight' with: [ spec className: 'BaselineOfTealight'; repository: 'github://astares/Tealight:0.0.4/repository' ]] The advantage is that you use git to tag the releases, it is a reproducable stable version then and GitHub shows it on the "releases" tab. One typically can not modify the release afterwards (which is not 100% true as git tags could be moved but this is another story). So with this model you form and finalize/close a release by tagging in git/GitHub and reference it in your ConfigurationOf.... Model 2: Work with several open branches - one per Pharo version ================================================================ In DesktopManager which is on https://github.com/astares/Pharo-DesktopManager I do it differently. I wanted to maintain it for Pharo7 now but wanted to still easily backport changes to Pharo 6. For this project I maintain therefore two special branches "pharo6" and "pharo7" - each for a particular Pharo version. So in the ConfigurationOfDesktop as you will find in MetaRepoForPharo70 I just point to the Baseline with only the difference of the branch: ------------------------------------------------------------------------------------------------------------ pharo6: spec <version: '6.0'> spec for: #'common' do: [ spec baseline: 'DesktopManager' with: [ spec className: 'BaselineOfDesktopManager'; repository: 'github://astares/Pharo-DesktopManager:pharo6/src' ]] ------------------------------------------------------------------------------------------------------------ pharo7: spec <version: '7.0'> spec for: #'common' do: [ spec baseline: 'DesktopManager' with: [ spec className: 'BaselineOfDesktopManager'; repository: 'github://astares/Pharo-DesktopManager:pharo7/src' ]] ------------------------------------------------------------------------------------------------------------ stable: spec <symbolicVersion: #'stable'> spec for: #'pharo5.x' version: '0.2.0'. "old way using versioning with Monticello/Metacello and StHub" spec for: #'pharo6.x' version: '6.0'. "still open version branch from Pharo 6 using git and GitHub" spec for: #'pharo7.x' version: '7.0'. "still open version branch from Pharo 7 using git and GitHub" ------------------------------------------------------------------------------------------------------------ This allows me to maintain the differences between the Pharo 6 and Pharo 7 version by using the two distinguished branches and backport from the "pharo7" branch easily to the "pharo6" branch if necessary. As no tagging with explicit versioning is involved here the branch for each Pharo version is always open for new additions/future fixes. The first model is close to what one is used to from the past: having reproducible fixed tagged versions referenced from the ConfigurationOf... The second model fits better if you provide packages that you would like to maintain for several Pharo versions from 6.0 onwards. I now also use it to maintain "QuickAccess", "OSWindows", "OSUnix", ... and others. Hope this helps a little bit. If not just ask. Have fun T. > Gesendet: Montag, 17. Dezember 2018 um 17:16 Uhr > Von: "Sven Van Caekenberghe" <sven(a)stfx.eu> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: [Pharo-dev] Catalog Entries > > Hi, > > So we have the Catalog with version specific repositories for ConfigurationOfXYZ packages/classes. > > I am assuming that we will be keeping this system for at least Pharo 7 and possibly 8. > > Can one define Catalog entries using BaselineOfXYZ ? > Is that recommended ? > Or should a mostly empty ConfigurationOfXYZ be used that internally refers to the BaselineOfXYZ ? > > Sven > > >

Dec. 17, 2018

Re: [Pharo-dev] Huge Critiques Area in Calypso in Pharo 7

by Sven Van Caekenberghe

Thanks, Denis, for the swift reply. What is the solution, though ? What do you think should happen ? Make the constant smaller, like the height of 1 row ? > On 17 Dec 2018, at 18:42, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi Sven. > > I checked problem and found following method: > > FTTableMorph >> minHeight > ^ 100 > > It prevents full critiques widget to be small. > > There is probably a bug in morphic which does not set up this "correct" extent by default. In my case when I browse your method in fresh image only three rows are visible in critiques view. But as soon as I start resizing this pane it becomes bigger and unminimizable. > > Ð¿Ð½, 17 Ð´ÐµÐº. 2018 Ð³. Ð² 17:14, Sven Van Caekenberghe <sven(a)stfx.eu>: > I am seeing a huge (multiline, ~ 5 to 7 lines) high 'critiques' area at the bottom of Calypso browsers in Pharo 7 (dl today), see screenshot: > > <Screenshot 2018-12-17 at 17.19.35.png> > Why is that ? I can't resize it to be smaller. > On a smaller screen this takes up way too much space. > Can't we have a widget to remove/collapse that area ? Not a setting. > > Sven >

Dec. 17, 2018

Re: [Pharo-dev] Huge Critiques Area in Calypso in Pharo 7

by Denis Kudriashov

Hi Sven. I checked problem and found following method: FTTableMorph >> minHeight ^ 100 It prevents full critiques widget to be small. There is probably a bug in morphic which does not set up this "correct" extent by default. In my case when I browse your method in fresh image only three rows are visible in critiques view. But as soon as I start resizing this pane it becomes bigger and unminimizable.

Dec. 17, 2018

Re: [Pharo-dev] Huge Critiques Area in Calypso in Pharo 7

by Denis Kudriashov

Hi Sven. I checked problem and found following method: FTTableMorph >> minHeight ^ 100 It prevents full critiques widget to be small. There is probably a bug in morphic which does not set up this "correct" extent by default. In my case when I browse your method in fresh image only three rows are visible in critiques view. But as soon as I start resizing this pane it becomes bigger and unminimizable. Ð¿Ð½, 17 Ð´ÐµÐº. 2018 Ð³. Ð² 17:14, Sven Van Caekenberghe <sven(a)stfx.eu>: > I am seeing a huge (multiline, ~ 5 to 7 lines) high 'critiques' area at > the bottom of Calypso browsers in Pharo 7 (dl today), see screenshot: > > Why is that ? I can't resize it to be smaller. > On a smaller screen this takes up way too much space. > Can't we have a widget to remove/collapse that area ? Not a setting. > > Sven > >

Dec. 17, 2018

[Pharo 7.0] Build #54: 22793 Cleanup AndreasSystemProfilerTest

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

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

Dec. 17, 2018

Huge Critiques Area in Calypso in Pharo 7

by Sven Van Caekenberghe

I am seeing a huge (multiline, ~ 5 to 7 lines) high 'critiques' area at the bottom of Calypso browsers in Pharo 7 (dl today), see screenshot: Why is that ? I can't resize it to be smaller. On a smaller screen this takes up way too much space. Can't we have a widget to remove/collapse that area ? Not a setting. Sven

Dec. 17, 2018

Catalog Entries

by Sven Van Caekenberghe

Hi, So we have the Catalog with version specific repositories for ConfigurationOfXYZ packages/classes. I am assuming that we will be keeping this system for at least Pharo 7 and possibly 8. Can one define Catalog entries using BaselineOfXYZ ? Is that recommended ? Or should a mostly empty ConfigurationOfXYZ be used that internally refers to the BaselineOfXYZ ? Sven

Dec. 17, 2018

[Pharo 7.0] Build #53: 22796 Fix testResettingTheSelection

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

There is a new Pharo build available! The status of the build #53 was: FAILURE. The Pull Request #2091 was integrated: "22796 Fix testResettingTheSelection" Pull request url: https://github.com/pharo-project/pharo/pull/2091 Issue Url: https://pharo.fogbugz.com/f/cases/22796 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 17, 2018

[Pharo 7.0] Build #52: 22792 Cleanup MessageTallyTest

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

There is a new Pharo build available! The status of the build #52 was: FAILURE. The Pull Request #2087 was integrated: "22792 Cleanup MessageTallyTest" Pull request url: https://github.com/pharo-project/pharo/pull/2087 Issue Url: https://pharo.fogbugz.com/f/cases/22792 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 17, 2018

[Pharo 7.0] Build #51: 22791 Cleanup TextDiffBuilderTest

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

There is a new Pharo build available! The status of the build #51 was: FAILURE. The Pull Request #2086 was integrated: "22791 Cleanup TextDiffBuilderTest" Pull request url: https://github.com/pharo-project/pharo/pull/2086 Issue Url: https://pharo.fogbugz.com/f/cases/22791 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 17, 2018

[Pharo 7.0] Build #50: 22794 Cleanup testExtractAllKinds

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

There is a new Pharo build available! The status of the build #50 was: FAILURE. The Pull Request #2089 was integrated: "22794 Cleanup testExtractAllKinds" Pull request url: https://github.com/pharo-project/pharo/pull/2089 Issue Url: https://pharo.fogbugz.com/f/cases/22794 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 17, 2018

Re: [Pharo-dev] Pharo image don't restart

by Eliot Miranda

Hi Dario, On Sun, Dec 16, 2018 at 11:23 AM Trussardi Dario Romano < dario.trussardi(a)tiscali.it> wrote: > Ciao Eliot, > > > Hi Dario, > > if you look at the end of the PharoDebug.log you will see: > > Most recent primitives > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > ....... > ...... > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > > > So you have a recursive doesNotUnderstand: error and the system is running > out of memory. The questions are where and why? You can try and debug > this further by running the VM with --trace=259, e.g. > > pharo-vm/pharo --trace=259 my image.image > > This will produce lots of output, eventually ending in an endless stream > of doesNotUnderstand:'s. So capture the first few megabytes of output (see > e.g. head(1) ($ man head)) > > FYI > "traceFlags is a set of flags. > 1 => print trace (if something below is selected) > 2 => trace sends > 4 => trace block activations > 8 => trace interpreter primitives > 16 => trace events (context switches, GCs, etc) > 32 => trace stack overflow > 64 => send breakpoint on implicit receiver (Newspeak VM only) > 128 => check stack depth on send (simulation only) > 256 => trace linked sends " > > Alternatively you could use a debugger such as gdb and I can tell you how > to put a breakpoint on doesNotUnderstand: > > > I do this command: > > *party@party001:/opt/pharolauncher/pharo-vm$ ./pharo --trace=259 > /home/party/Pharo/images/Pharo7.0-64DTRDevErr/Pharo7.0-64DTRDevErr.image* > > *This is the output:* > > > *pthread_setschedparam failed: Operation not permitted* > *This VM uses a separate heartbeat thread to update its internal clock* > *and handle events. For best operation, this thread should run at a* > *higher priority, however the VM was unable to change the priority. The* > *effect is that heavily loaded systems may experience some latency* > *issues. If this occurs, please create the appropriate configuration* > *file in /etc/security/limits.d/ as shown below:* > *cat <<END | sudo tee /etc/security/limits.d/pharo.conf* > ** hard rtprio 2* > ** soft rtprio 2* > *END* > *and report to the pharo mailing list whether this improves behaviour.* > *You will need to log out and log back in for the limits to take effect.* > *For more information please see* > *https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux > <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux>* > *SessionManager>installNewSession* > *SessionManager>newSession* > *WorkingSession class(Behavior)>new* > *WorkingSession class(Behavior)>basicNew* > *WorkingSession>initialize* > *Object(ProtoObject)>initialize* > *OrderedCollection class>new* > *OrderedCollection class>new:* > *OrderedCollection class(Behavior)>basicNew* > *OrderedCollection class>arrayType* > *Array class>new:* > *OrderedCollection>setCollection:* > *OrderedCollection>reset* > *OrderedCollection>resetTo:* > *DateAndTime class>now* > *DateAndTime class>clock* > *Time class>microsecondClockValue* > *Time class>primUTCMicrosecondsClock* > *SmallInteger>** > *Integer>** > *SmallInteger(Integer)>isInteger* > *SmallInteger(Number)>negative* > *SmallInteger(Number)>negative* > *SmallInteger(Integer)>digitMultiply:neg:* > *DateAndTime class(Behavior)>basicNew* > *DateAndTime class>localOffset* > *DateAndTime class>localTimeZone* > *LocalTimeZone>offset* > *LocalTimeZone>primOffset* > *SmallInteger(Number)>minutes* > *Duration class>minutes:* > *Duration class>seconds:nanoSeconds:* > *Duration class(Behavior)>basicNew* > *SmallInteger(Integer)>truncated* > *SmallInteger(Number)>fractionPart* > *SmallInteger(Number)>integerPart* > *SmallInteger(Integer)>truncated* > *Duration>seconds:nanoSeconds:* > *SmallInteger(Integer)>rounded* > *DateAndTime>setJdn:seconds:nano:offset:* > *DateAndTime>normalizeSecondsAndNanos* > *SmallInteger><=* > *Integer><=* > *LargePositiveInteger(Integer)>isInteger* > *SmallInteger(Number)>negative* > *LargePositiveInteger>negative* > *SmallInteger(Number)>negative* > *SmallInteger><* > *SmallInteger(Integer)>digitCompare:* > *LargePositiveInteger(LargeInteger)>//* > *LargePositiveInteger(LargeInteger)>\\* > *WorkingSession>manager:* > *SessionManager>installSession:* > *SessionManager>currentSession* > *WorkingSession>start:* > *SmalltalkImage>vm* > *VirtualMachine>setGCParameters* > *VirtualMachine>edenSpaceSize* > *VirtualMachine>parameterAt:* > *VirtualMachine>wordSize* > *SmallFloat64(Float)>rounded* > *SmallFloat64>fractionPart* > *SmallFloat64(Float)>abs* > *SmallFloat64>truncated* > *VirtualMachine>tenuringThreshold:* > *VirtualMachine>parameterAt:put:* > *SmalltalkImage>clearExternalObjects* > *ExternalSemaphoreTable class>clearExternalObjects* > *Semaphore>critical:* > *BlockClosure>ensure:* > *BlockClosure>valueNoContextSwitch* > *Semaphore>wait* > *Array class(ArrayedCollection class)>new* > *Array class>new:* > *ExternalSemaphoreTable class>unprotectedExternalObjects:* > *SmalltalkImage>specialObjectsArray* > *Array(Object)>at:put:* > *no room in eden for allocateSmallNewSpaceSlots:format:classIndex:* > */opt/pharolauncher/pharo-vm/lib/pharo/5.0-201805090836/pharo* > *Pharo VM version: 5.0-201805090836 Wed May 9 08:54:40 UTC 2018 gcc 4.8 > [Production Spur 64-bit VM]* > *Built from: CoInterpreter VMMaker.oscog-eem.2380 uuid: > c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018* > *With: StackToRegisterMappingCogit VMMaker.oscog-eem.2380 uuid: > c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018* > *Revision: VM: 201805090836 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git > <https://github.com/OpenSmalltalk/opensmalltalk-vm.git>* > *Date: Wed May 9 10:36:12 2018 CommitHash: 334be97* > *Plugins: 201805090836 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git > <https://github.com/OpenSmalltalk/opensmalltalk-vm.git>* > *Build host: Linux travis-job-5ab63a26-b2a8-4841-93ff-7aa5dc4e571e > 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 > x86_64 x86_64 x86_64 GNU/Linux* > *plugin path: ./lib/pharo/5.0-201805090836 [default: > /opt/pharolauncher/pharo-vm/lib/pharo/5.0-201805090836/]* > > *C stack backtrace & registers:* > **./lib/pharo/5.0-201805090836/pharo[0x41b0c5]* > *./lib/pharo/5.0-201805090836/pharo(error+0xf)[0x41c7af]* > *./lib/pharo/5.0-201805090836/pharo[0x432afc]* > *./lib/pharo/5.0-201805090836/pharo[0x43f6b3]* > *./lib/pharo/5.0-201805090836/pharo[0x4485bf]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee1]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *./lib/pharo/5.0-201805090836/pharo[0x45a217]* > *./lib/pharo/5.0-201805090836/pharo[0x45aee6]* > *[0x21e78c0]* > > *Smalltalk stack dump:* > * 0x7ffdf8a345f8 I ExternalSemaphoreTable > class>unprotectedExternalObjects: 0x22044b0: a(n) ExternalSemaphoreTable > class* > * 0x7ffdf8a34640 I [] in ExternalSemaphoreTable > class>clearExternalObjects 0x22044b0: a(n) ExternalSemaphoreTable class* > * 0x7ffdf8a34690 I [] in Semaphore>critical: 0x261ec80: a(n) Semaphore* > * 0x7ffdf8a346e0 I BlockClosure>ensure: 0x1b5e2d0: a(n) BlockClosure* > * 0x7ffdf8a34730 I Semaphore>critical: 0x261ec80: a(n) Semaphore* > * 0x7ffdf8a34778 I ExternalSemaphoreTable class>clearExternalObjects > 0x22044b0: a(n) ExternalSemaphoreTable class* > * 0x7ffdf8a347b8 I SmalltalkImage>clearExternalObjects 0x220a920: a(n) > SmalltalkImage* > * 0x7ffdf8a347f8 I WorkingSession>start: 0x1b5e000: a(n) WorkingSession* > * 0x7ffdf8a34850 I SessionManager>launchSnapshot:andQuit: 0x2270a10: > a(n) SessionManager* > * 0xc4f6c50 s SessionManager>snapshot:andQuit:* > * 0xc506a18 s [] in SmalltalkImage>snapshot:andQuit:* > * 0xc515188 s CurrentExecutionEnvironment class>activate:for:* > * 0xc51b590 s > DefaultExecutionEnvironment(ExecutionEnvironment)>beActiveDuring:* > * 0xc5322e0 s DefaultExecutionEnvironment class>beActiveDuring:* > * 0xc51b648 s SmalltalkImage>snapshot:andQuit:* > * 0xc532398 s [] in WorldState class>saveSession* > * 0xc53a310 s BlockClosure>ensure:* > * 0xc552b18 s CursorWithMask(Cursor)>showWhile:* > * 0xc552bf8 s WorldState class>saveSession* > * 0xc55a110 s [] in > ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent:* > * 0xc571550 s BlockClosure>ensure:* > * 0xc571ee8 s CursorWithMask(Cursor)>showWhile:* > * 0xc571fc8 s ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent:* > * 0xc572420 s ToggleMenuItemMorph(MenuItemMorph)>mouseUp:* > * 0xc572590 s ToggleMenuItemMorph(MenuItemMorph)>handleMouseUp:* > * 0xc572648 s MouseButtonEvent>sentTo:* > * 0xc572700 s ToggleMenuItemMorph(Morph)>handleEvent:* > * 0xc5727b8 s MorphicEventDispatcher>dispatchDefault:with:* > * 0xc572870 s MorphicEventDispatcher>handleMouseUp:* > * 0xc572928 s MouseButtonEvent>sentTo:* > * 0xc5729e0 s [] in MorphicEventDispatcher>dispatchEvent:with:* > * 0xc572a98 s BlockClosure>ensure:* > * 0xc572b78 s MorphicEventDispatcher>dispatchEvent:with:* > * 0xc572c50 s ToggleMenuItemMorph(Morph)>processEvent:using:* > * 0xc572d08 s MorphicEventDispatcher>dispatchDefault:with:* > * 0xc572dc0 s MorphicEventDispatcher>handleMouseUp:* > * 0xc572ec8 s MouseButtonEvent>sentTo:* > * 0xc572f80 s [] in MorphicEventDispatcher>dispatchEvent:with:* > * 0xc573038 s BlockClosure>ensure:* > * 0xc573118 s MorphicEventDispatcher>dispatchEvent:with:* > * 0xc5731f0 s MenuMorph(Morph)>processEvent:using:* > * 0xc5732a8 s MenuMorph(Morph)>processEvent:* > * 0xc573360 s MenuMorph>handleFocusEvent:* > * 0xc573418 s [] in HandMorph>sendFocusEvent:to:clear:* > * 0xc5734d0 s BlockClosure>on:do:* > * 0xc5735d0 s WorldMorph(PasteUpMorph)>becomeActiveDuring:* > * 0xc5736c0 s HandMorph>sendFocusEvent:to:clear:* > * 0xc5737c0 s HandMorph>sendEvent:focus:clear:* > * 0xc5738b0 s HandMorph>sendMouseEvent:* > * 0xc573968 s HandMorph>handleEvent:* > * 0xc573a20 s HandMorph>processEventsFromQueue:* > * 0xc573ad8 s HandMorph>processEvents* > * 0xc573b90 s [] in WorldState>doOneCycleNowFor:* > * 0xc573c48 s Array(SequenceableCollection)>do:* > * 0xc573d20 s WorldState>handsDo:* > * 0xc573dd8 s WorldState>doOneCycleNowFor:* > * 0xc573e90 s WorldState>doOneCycleFor:* > * 0xc573f48 s WorldMorph>doOneCycle* > * 0xc574000 s WorldMorph class>doOneCycle* > * 0xc040f88 s [] in MorphicUIManager>spawnNewProcess* > * 0xc040d40 s [] in BlockClosure>newProcess* > *Most recent primitives* > *stack page bytes 8192 available headroom 5576 minimum unused headroom > 7200* > *(no room in eden for allocateSmallNewSpaceSlots:format:classIndex:)* > *Annullato (core dump creato)* > > > Are the data you expected? > No :-). Can you put your image and changes up anywhere I can get at them? Or can you put them in a zip or tar archive and email them to me? I'm curious. _,,,^..^,,,_ best, Eliot

Dec. 17, 2018

Re: [Pharo-dev] Pharo image don't restart

by Trussardi Dario Romano

Ciao Eliot, > Hi Dario, > > if you look at the end of the PharoDebug.log you will see: > > Most recent primitives > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > ....... > ...... > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > doesNotUnderstand: > > So you have a recursive doesNotUnderstand: error and the system is running out of memory. The questions are where and why? You can try and debug this further by running the VM with --trace=259, e.g. > > pharo-vm/pharo --trace=259 my image.image > > This will produce lots of output, eventually ending in an endless stream of doesNotUnderstand:'s. So capture the first few megabytes of output (see e.g. head(1) ($ man head)) > > FYI > "traceFlags is a set of flags. > 1 => print trace (if something below is selected) > 2 => trace sends > 4 => trace block activations > 8 => trace interpreter primitives > 16 => trace events (context switches, GCs, etc) > 32 => trace stack overflow > 64 => send breakpoint on implicit receiver (Newspeak VM only) > 128 => check stack depth on send (simulation only) > 256 => trace linked sends " > > Alternatively you could use a debugger such as gdb and I can tell you how to put a breakpoint on doesNotUnderstand: I do this command: party@party001:/opt/pharolauncher/pharo-vm$ ./pharo --trace=259 /home/party/Pharo/images/Pharo7.0-64DTRDevErr/Pharo7.0-64DTRDevErr.image This is the output: pthread_setschedparam failed: Operation not permitted This VM uses a separate heartbeat thread to update its internal clock and handle events. For best operation, this thread should run at a higher priority, however the VM was unable to change the priority. The effect is that heavily loaded systems may experience some latency issues. If this occurs, please create the appropriate configuration file in /etc/security/limits.d/ as shown below: cat <<END | sudo tee /etc/security/limits.d/pharo.conf * hard rtprio 2 * soft rtprio 2 END and report to the pharo mailing list whether this improves behaviour. You will need to log out and log back in for the limits to take effect. For more information please see https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux SessionManager>installNewSession SessionManager>newSession WorkingSession class(Behavior)>new WorkingSession class(Behavior)>basicNew WorkingSession>initialize Object(ProtoObject)>initialize OrderedCollection class>new OrderedCollection class>new: OrderedCollection class(Behavior)>basicNew OrderedCollection class>arrayType Array class>new: OrderedCollection>setCollection: OrderedCollection>reset OrderedCollection>resetTo: DateAndTime class>now DateAndTime class>clock Time class>microsecondClockValue Time class>primUTCMicrosecondsClock SmallInteger>* Integer>* SmallInteger(Integer)>isInteger SmallInteger(Number)>negative SmallInteger(Number)>negative SmallInteger(Integer)>digitMultiply:neg: DateAndTime class(Behavior)>basicNew DateAndTime class>localOffset DateAndTime class>localTimeZone LocalTimeZone>offset LocalTimeZone>primOffset SmallInteger(Number)>minutes Duration class>minutes: Duration class>seconds:nanoSeconds: Duration class(Behavior)>basicNew SmallInteger(Integer)>truncated SmallInteger(Number)>fractionPart SmallInteger(Number)>integerPart SmallInteger(Integer)>truncated Duration>seconds:nanoSeconds: SmallInteger(Integer)>rounded DateAndTime>setJdn:seconds:nano:offset: DateAndTime>normalizeSecondsAndNanos SmallInteger><= Integer><= LargePositiveInteger(Integer)>isInteger SmallInteger(Number)>negative LargePositiveInteger>negative SmallInteger(Number)>negative SmallInteger>< SmallInteger(Integer)>digitCompare: LargePositiveInteger(LargeInteger)>// LargePositiveInteger(LargeInteger)>\\ WorkingSession>manager: SessionManager>installSession: SessionManager>currentSession WorkingSession>start: SmalltalkImage>vm VirtualMachine>setGCParameters VirtualMachine>edenSpaceSize VirtualMachine>parameterAt: VirtualMachine>wordSize SmallFloat64(Float)>rounded SmallFloat64>fractionPart SmallFloat64(Float)>abs SmallFloat64>truncated VirtualMachine>tenuringThreshold: VirtualMachine>parameterAt:put: SmalltalkImage>clearExternalObjects ExternalSemaphoreTable class>clearExternalObjects Semaphore>critical: BlockClosure>ensure: BlockClosure>valueNoContextSwitch Semaphore>wait Array class(ArrayedCollection class)>new Array class>new: ExternalSemaphoreTable class>unprotectedExternalObjects: SmalltalkImage>specialObjectsArray Array(Object)>at:put: no room in eden for allocateSmallNewSpaceSlots:format:classIndex: /opt/pharolauncher/pharo-vm/lib/pharo/5.0-201805090836/pharo Pharo VM version: 5.0-201805090836 Wed May 9 08:54:40 UTC 2018 gcc 4.8 [Production Spur 64-bit VM] Built from: CoInterpreter VMMaker.oscog-eem.2380 uuid: c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018 With: StackToRegisterMappingCogit VMMaker.oscog-eem.2380 uuid: c76d37e1-445c-4e34-9796-fc836dfd50c9 May 9 2018 Revision: VM: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Wed May 9 10:36:12 2018 CommitHash: 334be97 Plugins: 201805090836 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Build host: Linux travis-job-5ab63a26-b2a8-4841-93ff-7aa5dc4e571e 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux plugin path: ./lib/pharo/5.0-201805090836 [default: /opt/pharolauncher/pharo-vm/lib/pharo/5.0-201805090836/] C stack backtrace & registers: *./lib/pharo/5.0-201805090836/pharo[0x41b0c5] ./lib/pharo/5.0-201805090836/pharo(error+0xf)[0x41c7af] ./lib/pharo/5.0-201805090836/pharo[0x432afc] ./lib/pharo/5.0-201805090836/pharo[0x43f6b3] ./lib/pharo/5.0-201805090836/pharo[0x4485bf] ./lib/pharo/5.0-201805090836/pharo[0x45aee1] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] ./lib/pharo/5.0-201805090836/pharo[0x45a217] ./lib/pharo/5.0-201805090836/pharo[0x45aee6] [0x21e78c0] Smalltalk stack dump: 0x7ffdf8a345f8 I ExternalSemaphoreTable class>unprotectedExternalObjects: 0x22044b0: a(n) ExternalSemaphoreTable class 0x7ffdf8a34640 I [] in ExternalSemaphoreTable class>clearExternalObjects 0x22044b0: a(n) ExternalSemaphoreTable class 0x7ffdf8a34690 I [] in Semaphore>critical: 0x261ec80: a(n) Semaphore 0x7ffdf8a346e0 I BlockClosure>ensure: 0x1b5e2d0: a(n) BlockClosure 0x7ffdf8a34730 I Semaphore>critical: 0x261ec80: a(n) Semaphore 0x7ffdf8a34778 I ExternalSemaphoreTable class>clearExternalObjects 0x22044b0: a(n) ExternalSemaphoreTable class 0x7ffdf8a347b8 I SmalltalkImage>clearExternalObjects 0x220a920: a(n) SmalltalkImage 0x7ffdf8a347f8 I WorkingSession>start: 0x1b5e000: a(n) WorkingSession 0x7ffdf8a34850 I SessionManager>launchSnapshot:andQuit: 0x2270a10: a(n) SessionManager 0xc4f6c50 s SessionManager>snapshot:andQuit: 0xc506a18 s [] in SmalltalkImage>snapshot:andQuit: 0xc515188 s CurrentExecutionEnvironment class>activate:for: 0xc51b590 s DefaultExecutionEnvironment(ExecutionEnvironment)>beActiveDuring: 0xc5322e0 s DefaultExecutionEnvironment class>beActiveDuring: 0xc51b648 s SmalltalkImage>snapshot:andQuit: 0xc532398 s [] in WorldState class>saveSession 0xc53a310 s BlockClosure>ensure: 0xc552b18 s CursorWithMask(Cursor)>showWhile: 0xc552bf8 s WorldState class>saveSession 0xc55a110 s [] in ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: 0xc571550 s BlockClosure>ensure: 0xc571ee8 s CursorWithMask(Cursor)>showWhile: 0xc571fc8 s ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: 0xc572420 s ToggleMenuItemMorph(MenuItemMorph)>mouseUp: 0xc572590 s ToggleMenuItemMorph(MenuItemMorph)>handleMouseUp: 0xc572648 s MouseButtonEvent>sentTo: 0xc572700 s ToggleMenuItemMorph(Morph)>handleEvent: 0xc5727b8 s MorphicEventDispatcher>dispatchDefault:with: 0xc572870 s MorphicEventDispatcher>handleMouseUp: 0xc572928 s MouseButtonEvent>sentTo: 0xc5729e0 s [] in MorphicEventDispatcher>dispatchEvent:with: 0xc572a98 s BlockClosure>ensure: 0xc572b78 s MorphicEventDispatcher>dispatchEvent:with: 0xc572c50 s ToggleMenuItemMorph(Morph)>processEvent:using: 0xc572d08 s MorphicEventDispatcher>dispatchDefault:with: 0xc572dc0 s MorphicEventDispatcher>handleMouseUp: 0xc572ec8 s MouseButtonEvent>sentTo: 0xc572f80 s [] in MorphicEventDispatcher>dispatchEvent:with: 0xc573038 s BlockClosure>ensure: 0xc573118 s MorphicEventDispatcher>dispatchEvent:with: 0xc5731f0 s MenuMorph(Morph)>processEvent:using: 0xc5732a8 s MenuMorph(Morph)>processEvent: 0xc573360 s MenuMorph>handleFocusEvent: 0xc573418 s [] in HandMorph>sendFocusEvent:to:clear: 0xc5734d0 s BlockClosure>on:do: 0xc5735d0 s WorldMorph(PasteUpMorph)>becomeActiveDuring: 0xc5736c0 s HandMorph>sendFocusEvent:to:clear: 0xc5737c0 s HandMorph>sendEvent:focus:clear: 0xc5738b0 s HandMorph>sendMouseEvent: 0xc573968 s HandMorph>handleEvent: 0xc573a20 s HandMorph>processEventsFromQueue: 0xc573ad8 s HandMorph>processEvents 0xc573b90 s [] in WorldState>doOneCycleNowFor: 0xc573c48 s Array(SequenceableCollection)>do: 0xc573d20 s WorldState>handsDo: 0xc573dd8 s WorldState>doOneCycleNowFor: 0xc573e90 s WorldState>doOneCycleFor: 0xc573f48 s WorldMorph>doOneCycle 0xc574000 s WorldMorph class>doOneCycle 0xc040f88 s [] in MorphicUIManager>spawnNewProcess 0xc040d40 s [] in BlockClosure>newProcess Most recent primitives stack page bytes 8192 available headroom 5576 minimum unused headroom 7200 (no room in eden for allocateSmallNewSpaceSlots:format:classIndex:) Annullato (core dump creato) Are the data you expected? Thanks, Dario

Dec. 16, 2018

[Pharo 7.0] Build #49: 22786 - Unused result in testExecutionOfWrongFFIMethodShouldRaiseAnError

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

There is a new Pharo build available! The status of the build #49 was: FAILURE. The Pull Request #2081 was integrated: "22786 - Unused result in testExecutionOfWrongFFIMethodShouldRaiseAnError" Pull request url: https://github.com/pharo-project/pharo/pull/2081 Issue Url: https://pharo.fogbugz.com/f/cases/22786 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 16, 2018

[Pharo 7.0] Build #48: 22782-Bag-comments-deserve-executable-comments

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

There is a new Pharo build available! The status of the build #48 was: SUCCESS. The Pull Request #2080 was integrated: "22782-Bag-comments-deserve-executable-comments" Pull request url: https://github.com/pharo-project/pharo/pull/2080 Issue Url: https://pharo.fogbugz.com/f/cases/22782 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 16, 2018

Re: [Pharo-dev] Pharo image don't restart

by Eliot Miranda

Hi Dario, if you look at the end of the PharoDebug.log you will see: Most recent primitives doesNotUnderstand: doesNotUnderstand: doesNotUnderstand: doesNotUnderstand: doesNotUnderstand: doesNotUnderstand: doesNotUnderstand: doesNotUnderstand: doesNotUnderstand: ....... ...... doesNotUnderstand: doesNotUnderstand: doesNotUnderstand: doesNotUnderstand: doesNotUnderstand: doesNotUnderstand: doesNotUnderstand: doesNotUnderstand: doesNotUnderstand: doesNotUnderstand: doesNotUnderstand: So you have a recursive doesNotUnderstand: error and the system is running out of memory. The questions are where and why? You can try and debug this further by running the VM with --trace=259, e.g. pharo-vm/pharo --trace=259 my image.image This will produce lots of output, eventually ending in an endless stream of doesNotUnderstand:'s. So capture the first few megabytes of output (see e.g. head(1) ($ man head)) FYI "traceFlags is a set of flags. 1 => print trace (if something below is selected) 2 => trace sends 4 => trace block activations 8 => trace interpreter primitives 16 => trace events (context switches, GCs, etc) 32 => trace stack overflow 64 => send breakpoint on implicit receiver (Newspeak VM only) 128 => check stack depth on send (simulation only) 256 => trace linked sends " Alternatively you could use a debugger such as gdb and I can tell you how to put a breakpoint on doesNotUnderstand: On Fri, Dec 14, 2018 at 3:42 AM Trussardi Dario Romano < dario.trussardi(a)tiscali.it> wrote: > Some consideration: > > > At 12 December: > > I work all day with the image. > > at: 19:xx I save the image without any problem. > > But after saved the image the system begin > *unstable.* > > > > > > > > > > > *When the mouse go on the windows summary bar ( at the bottom of the Pharo > window ) the image crash. Some time i can launch - relaunch the same image > from the PharoLauncher ( the pharo run but was unstable ) at: 19:45 After > reload the unstable image ( as mentioned above ) i do the save command > ( saving it on itself ) and the system crash. After this crash ( when i do > the image save command ), i have not been able to launch the image. I do > not know the status of this image ( I call this corrupt image ) At 13 > December: A) From pharoLauncher i launch the corrupt image some time,* > * the shell report the issue, * > > > > > > > > > * but don't create the crash.dmp file. B) After copy the pharoLauncher > corrupt image into Pharo7.0-64DTRDevErr entry i do this: > /opt/pharolauncher/pharo-vm$ ./pharo --eden 15207744 > /home/party/Pharo/images/Pharo7.0-64DTRDevErr/Pharo7.0-64DTRDevErr.image > the shell report: * > > *pthread_setschedparam failed: Operation not permitted* > > *This VM uses a separate heartbeat thread to update its internal clock* > > *and handle events. For best operation, this thread should run at a* > > *higher priority, however the VM was unable to change the priority. The* > > *effect is that heavily loaded systems may experience some latency* > > *issues. If this occurs, please create the appropriate configuration* > > *file in /etc/security/limits.d/ as shown below:* > > > *cat <<END | sudo tee /etc/security/limits.d/pharo.conf* > > ** hard rtprio 2* > > ** soft rtprio 2* > > *END* > > > *and report to the pharo mailing list whether this improves behaviour.* > > > *You will need to log out and log back in for the limits to take effect.* > > *For more information please see* > > *...........r3732#linux* > > *Errore di segmentazione (core dump creato)* > > > > > > > * C) i have a PharoDebug.log but has the size of 16MB. How can I send it > to you? This is the status of the problematic. Thanks, Dario * > -- _,,,^..^,,,_ best, Eliot

Dec. 15, 2018

[Pharo 7.0] Build #47: 22778 Tag Monticello-OldDataStreamCompatibility in Manifest

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

There is a new Pharo build available! The status of the build #47 was: SUCCESS. The Pull Request #2077 was integrated: "22778 Tag Monticello-OldDataStreamCompatibility in Manifest" Pull request url: https://github.com/pharo-project/pharo/pull/2077 Issue Url: https://pharo.fogbugz.com/f/cases/22778 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 15, 2018

Re: [Pharo-dev] Pharo & Windows 10

by Cyril Ferlicot

On Sat 15 Dec 2018 at 15:12, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Where is the PR? > Hi, https://github.com/pharo-project/pharo/pull/1985 I guess itâs this one. > Cheers, > Doru > > > > -- Cyril Ferlicot https://ferlicot.fr

Dec. 15, 2018

Re: [Pharo-dev] Pharo & Windows 10

by Tudor Girba

Hi, Where is the PR? Cheers, Doru > On Dec 15, 2018, at 5:26 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Yes, the copyBits problem is THE problem that is stopping us to release P7 (I said time before that Athens is still not working, and the only thing FFI-based still not working in windows 64bit). > The crash problem is easily workaroundable by executing: > > FFIExternalEnumeration allSubclassesDo: #initializeEnumeration. > FFIExternalStructure allSubclassesDo: #compileFields. > > (There is a PR to fix the real problem there, but still not integrated). > > Esteban > >> On 14 Dec 2018, at 23:21, John Brant <brant(a)refactoryworkers.com> wrote: >> >> Is anyone using a recent Pharo with Windows 10? I'm using >> Pharo-7.0.0+rc1.build.44.sha.d3be1c018447fa5f7ba666cea7aff396f36d4309 >> (64 Bit) and am getting crashes whenever I try to commit anything using >> Iceberg. This seems to be a recent issue -- if I open an image from a >> few weeks ago, it works. >> >> Also, when I reopen the image, and the try to open the "Code Changes" it >> fails with: >> ------------------------ >> GrafPort(Object)>>error: >> GrafPort(BitBlt)>>copyBits >> GrafPort>>copyBits >> GrafPort>>image:at:sourceRect:rule: >> FormCanvas>>image:at:sourceRect:rule: >> FormCanvas(Canvas)>>drawImage:at:sourceRect: >> FormCanvas(Canvas)>>drawImage:at: >> HiRulerBuilder>>form >> HiRulerController>>buildRulerForm >> HiRulerController>>refreshRuler >> HiRulerController>>values: >> HiRulerController>>updateFromTree >> [ hiedraRulerController updateFromTree ] in >> EpLogNodeGraphPresenter>>initializeHiedraController in Block: [ >> hiedraRulerController updateFromTree ] >> BlockClosure>>cull: >> BlockClosure>>cull:cull: >> BlockClosure>>cull:cull:cull: >> BlockClosure>>cull:cull:cull:cull: >> [ :announcement :ann | >> aBlock >> cull: announcement newValue >> cull: announcement oldValue >> cull: announcement >> cull: ann ] in CollectionValueHolder(Model)>>whenChangedDo: in Block: [ >> :announcement :ann | ... >> BlockClosure>>cull:cull: >> [ action cull: anAnnouncement cull: announcer ] in >> AnnouncementSubscription>>deliver: in Block: [ action cull: >> anAnnouncement cull: announcer ] >> BlockClosure>>on:do: >> BlockClosure>>on:fork: >> AnnouncementSubscription>>deliver: >> [ "Ensure delivery to remaining announcements" subscription deliver: >> anAnnouncement ] in SubscriptionRegistry>>deliver:to:startingAt: in >> Block: [ "Ensure delivery to remaining announcements" sub...etc... >> BlockClosure>>ifCurtailed: >> SubscriptionRegistry>>deliver:to:startingAt: >> SubscriptionRegistry>>deliver:to: >> SubscriptionRegistry>>deliver: >> Announcer>>announce: >> CollectionValueHolder(NewValueHolder)>>valueChanged: >> ------------------------ >> This issue existed in the image I have from a few weeks ago. >> >> I've tried using the latest vm's from both files.pharo.org and bintray.com. >> >> >> John Brant >> > > -- www.feenk.com "Reasonable is what we are accustomed with."

Dec. 15, 2018

[Pharo 7.0] Build #46: 22756-Yourself-comment-is-wrong-

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

There is a new Pharo build available! The status of the build #46 was: SUCCESS. The Pull Request #2079 was integrated: "22756-Yourself-comment-is-wrong-" Pull request url: https://github.com/pharo-project/pharo/pull/2079 Issue Url: https://pharo.fogbugz.com/f/cases/22756 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 15, 2018

Re: [Pharo-dev] Pharo & Windows 10

by Esteban Lorenzano

Yes, the copyBits problem is THE problem that is stopping us to release P7 (I said time before that Athens is still not working, and the only thing FFI-based still not working in windows 64bit). The crash problem is easily workaroundable by executing: FFIExternalEnumeration allSubclassesDo: #initializeEnumeration. FFIExternalStructure allSubclassesDo: #compileFields. (There is a PR to fix the real problem there, but still not integrated). Esteban > On 14 Dec 2018, at 23:21, John Brant <brant(a)refactoryworkers.com> wrote: > > Is anyone using a recent Pharo with Windows 10? I'm using > Pharo-7.0.0+rc1.build.44.sha.d3be1c018447fa5f7ba666cea7aff396f36d4309 > (64 Bit) and am getting crashes whenever I try to commit anything using > Iceberg. This seems to be a recent issue -- if I open an image from a > few weeks ago, it works. > > Also, when I reopen the image, and the try to open the "Code Changes" it > fails with: > ------------------------ > GrafPort(Object)>>error: > GrafPort(BitBlt)>>copyBits > GrafPort>>copyBits > GrafPort>>image:at:sourceRect:rule: > FormCanvas>>image:at:sourceRect:rule: > FormCanvas(Canvas)>>drawImage:at:sourceRect: > FormCanvas(Canvas)>>drawImage:at: > HiRulerBuilder>>form > HiRulerController>>buildRulerForm > HiRulerController>>refreshRuler > HiRulerController>>values: > HiRulerController>>updateFromTree > [ hiedraRulerController updateFromTree ] in > EpLogNodeGraphPresenter>>initializeHiedraController in Block: [ > hiedraRulerController updateFromTree ] > BlockClosure>>cull: > BlockClosure>>cull:cull: > BlockClosure>>cull:cull:cull: > BlockClosure>>cull:cull:cull:cull: > [ :announcement :ann | > aBlock > cull: announcement newValue > cull: announcement oldValue > cull: announcement > cull: ann ] in CollectionValueHolder(Model)>>whenChangedDo: in Block: [ > :announcement :ann | ... > BlockClosure>>cull:cull: > [ action cull: anAnnouncement cull: announcer ] in > AnnouncementSubscription>>deliver: in Block: [ action cull: > anAnnouncement cull: announcer ] > BlockClosure>>on:do: > BlockClosure>>on:fork: > AnnouncementSubscription>>deliver: > [ "Ensure delivery to remaining announcements" subscription deliver: > anAnnouncement ] in SubscriptionRegistry>>deliver:to:startingAt: in > Block: [ "Ensure delivery to remaining announcements" sub...etc... > BlockClosure>>ifCurtailed: > SubscriptionRegistry>>deliver:to:startingAt: > SubscriptionRegistry>>deliver:to: > SubscriptionRegistry>>deliver: > Announcer>>announce: > CollectionValueHolder(NewValueHolder)>>valueChanged: > ------------------------ > This issue existed in the image I have from a few weeks ago. > > I've tried using the latest vm's from both files.pharo.org and bintray.com. > > > John Brant >

Dec. 15, 2018

Re: [Pharo-dev] Pharo image don't restart

by Trussardi Dario Romano

Ciao, > I did not notice the link in the previous link. I got the PharoDebug.log file. > It is very big because there are a lot of traces there. > > The last one is the following. > Does it correspond to your crash? Yes, 12 December 2018 6:47.......... 6:xxx it's the time when I started having problems > To be sure, you could rename this file and try to run again your image to see if we have logs. OK. I rename the file. When i Launch the corrupt image the system don't create the new PharoDebug.log As this point ( but maybe it happened even before ) when from PharoLauncher on the corrupt image i select the Show in folder menu option the shell report: (nautilus:17273): GLib-GIO-CRITICAL **: g_dbus_interface_skeleton_unexport: assertion 'interface_->priv->connections != NULL' failed (nautilus:17273): GLib-GIO-CRITICAL **: g_dbus_interface_skeleton_unexport: assertion 'interface_->priv->connections != NULL' failed (nautilus:17273): Gtk-CRITICAL **: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed (nautilus:17273): GLib-GObject-WARNING **: invalid (NULL) pointer instance (nautilus:17273): GLib-GObject-CRITICAL **: g_signal_connect_object: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed Thanks, Dario P.S. In the /etc/sysctl.conf i add this entry ( can they somehow interfere? ) kernel.shmmax=6442450944 kernel.shmall=1572864

Dec. 15, 2018

[Pharo 7.0] Build #45: 22723-Ugly-triangles-in-trees-with-medium-fontsUntitled

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

There is a new Pharo build available! The status of the build #45 was: SUCCESS. The Pull Request #2038 was integrated: "22723-Ugly-triangles-in-trees-with-medium-fontsUntitled" Pull request url: https://github.com/pharo-project/pharo/pull/2038 Issue Url: https://pharo.fogbugz.com/f/cases/22723 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 15, 2018

Re: [Pharo-dev] Pharo & Windows 10

by Cyril Ferlicot

On Fri 14 Dec 2018 at 23:22, John Brant <brant(a)refactoryworkers.com> wrote: > Is anyone using a recent Pharo with Windows 10? I'm using > Pharo-7.0.0+rc1.build.44.sha.d3be1c018447fa5f7ba666cea7aff396f36d4309 > (64 Bit) and am getting crashes whenever I try to commit anything using > Iceberg. This seems to be a recent issue -- if I open an image from a > few weeks ago, it works. Hello, I think this is a known issue on the 64bits Windows version. Itâs one of the remaining issue before releasing a stable version of Pharo on Windows 64bits. Thank you for the report! > > Also, when I reopen the image, and the try to open the "Code Changes" it > fails with: > ------------------------ > GrafPort(Object)>>error: > GrafPort(BitBlt)>>copyBits > GrafPort>>copyBits > GrafPort>>image:at:sourceRect:rule: > FormCanvas>>image:at:sourceRect:rule: > FormCanvas(Canvas)>>drawImage:at:sourceRect: > FormCanvas(Canvas)>>drawImage:at: > HiRulerBuilder>>form > HiRulerController>>buildRulerForm > HiRulerController>>refreshRuler > HiRulerController>>values: > HiRulerController>>updateFromTree > [ hiedraRulerController updateFromTree ] in > EpLogNodeGraphPresenter>>initializeHiedraController in Block: [ > hiedraRulerController updateFromTree ] > BlockClosure>>cull: > BlockClosure>>cull:cull: > BlockClosure>>cull:cull:cull: > BlockClosure>>cull:cull:cull:cull: > [ :announcement :ann | > aBlock > cull: announcement newValue > cull: announcement oldValue > cull: announcement > cull: ann ] in CollectionValueHolder(Model)>>whenChangedDo: in > Block: [ > :announcement :ann | ... > BlockClosure>>cull:cull: > [ action cull: anAnnouncement cull: announcer ] in > AnnouncementSubscription>>deliver: in Block: [ action cull: > anAnnouncement cull: announcer ] > BlockClosure>>on:do: > BlockClosure>>on:fork: > AnnouncementSubscription>>deliver: > [ "Ensure delivery to remaining announcements" subscription deliver: > anAnnouncement ] in SubscriptionRegistry>>deliver:to:startingAt: in > Block: [ "Ensure delivery to remaining announcements" sub...etc... > BlockClosure>>ifCurtailed: > SubscriptionRegistry>>deliver:to:startingAt: > SubscriptionRegistry>>deliver:to: > SubscriptionRegistry>>deliver: > Announcer>>announce: > CollectionValueHolder(NewValueHolder)>>valueChanged: > ------------------------ > This issue existed in the image I have from a few weeks ago. > > I've tried using the latest vm's from both files.pharo.org and bintray.com > . > > > John Brant > > -- Cyril Ferlicot https://ferlicot.fr

Dec. 14, 2018

Pharo & Windows 10

by John Brant

Is anyone using a recent Pharo with Windows 10? I'm using Pharo-7.0.0+rc1.build.44.sha.d3be1c018447fa5f7ba666cea7aff396f36d4309 (64 Bit) and am getting crashes whenever I try to commit anything using Iceberg. This seems to be a recent issue -- if I open an image from a few weeks ago, it works. Also, when I reopen the image, and the try to open the "Code Changes" it fails with: ------------------------ GrafPort(Object)>>error: GrafPort(BitBlt)>>copyBits GrafPort>>copyBits GrafPort>>image:at:sourceRect:rule: FormCanvas>>image:at:sourceRect:rule: FormCanvas(Canvas)>>drawImage:at:sourceRect: FormCanvas(Canvas)>>drawImage:at: HiRulerBuilder>>form HiRulerController>>buildRulerForm HiRulerController>>refreshRuler HiRulerController>>values: HiRulerController>>updateFromTree [ hiedraRulerController updateFromTree ] in EpLogNodeGraphPresenter>>initializeHiedraController in Block: [ hiedraRulerController updateFromTree ] BlockClosure>>cull: BlockClosure>>cull:cull: BlockClosure>>cull:cull:cull: BlockClosure>>cull:cull:cull:cull: [ :announcement :ann | aBlock cull: announcement newValue cull: announcement oldValue cull: announcement cull: ann ] in CollectionValueHolder(Model)>>whenChangedDo: in Block: [ :announcement :ann | ... BlockClosure>>cull:cull: [ action cull: anAnnouncement cull: announcer ] in AnnouncementSubscription>>deliver: in Block: [ action cull: anAnnouncement cull: announcer ] BlockClosure>>on:do: BlockClosure>>on:fork: AnnouncementSubscription>>deliver: [ "Ensure delivery to remaining announcements" subscription deliver: anAnnouncement ] in SubscriptionRegistry>>deliver:to:startingAt: in Block: [ "Ensure delivery to remaining announcements" sub...etc... BlockClosure>>ifCurtailed: SubscriptionRegistry>>deliver:to:startingAt: SubscriptionRegistry>>deliver:to: SubscriptionRegistry>>deliver: Announcer>>announce: CollectionValueHolder(NewValueHolder)>>valueChanged: ------------------------ This issue existed in the image I have from a few weeks ago. I've tried using the latest vm's from both files.pharo.org and bintray.com. John Brant

Dec. 14, 2018

Re: [Pharo-dev] Pharo image don't restart

by Christophe Demarey

I did not notice the link in the previous link. I got the PharoDebug.log file. It is very big because there are a lot of traces there. The last one is the following. Does it correspond to your crash? To be sure, you could rename this file and try to run again your image to see if we have logs. âââââââââââââ THERE_BE_DRAGONS_HERE Halt 12 December 2018 6:47:50.168135 pm VM: unix - x86_64 - linux-gnu - CoInterpreter VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 VM: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jun 28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Image: Pharo7.0.0alpha [Build information: Pharo-7.0.0+alpha.build.1271.sha.7e89f61c1e268f08b871d6c9bf4c64536cca6c32 (64 Bit)] MATimedIvaModel(Object)>>halt Receiver: a MATimedIvaModel : 1 August 2014 Arguments and temporary variables: Receiver's instance variables: data: 1 August 2014 bloccato: true aliquotaIva: 20 symbolIva: '20' MATimedIvaModel(MATimedInstanceModel)>>blockAtData Receiver: a MATimedIvaModel : 1 August 2014 Arguments and temporary variables: Receiver's instance variables: data: 1 August 2014 bloccato: true aliquotaIva: 20 symbolIva: '20' MASelectorAccessor>>read: Receiver: (MASelectorAccessor read: #blockAtData write: #blockAtData:) Arguments and temporary variables: aModel: a MATimedIvaModel : 1 August 2014 Receiver's instance variables: properties: nil readSelector: #blockAtData writeSelector: #blockAtData: MADescribedColumn(MAColumn)>>valueFor: Receiver: a MADescribedColumn Arguments and temporary variables: aRow: a MATimedIvaModel : 1 August 2014 Receiver's instance variables: properties: a Dictionary() report: a MAReport accessor: (MASelectorAccessor read: #blockAtData write: #blockAtData:) description: a MABooleanDescription label: 'Bloccato' comment: 'Definisce se co...etc... MADescribedColumn>>valueFor: Receiver: a MADescribedColumn Arguments and temporary variables: aRow: a MATimedIvaModel : 1 August 2014 Receiver's instance variables: properties: a Dictionary() report: a MAReport accessor: (MASelectorAccessor read: #blockAtData write: #blockAtData:) description: a MABooleanDescription label: 'Bloccato' comment: 'Definisce se co...etc... MADescribedColumn(MAColumn)>>renderCellContent:on: Receiver: a MADescribedColumn Arguments and temporary variables: anObject: a MATimedIvaModel : 1 August 2014 html: a WAHtmlCanvas Receiver's instance variables: properties: a Dictionary() report: a MAReport accessor: (MASelectorAccessor read: #blockAtData write: #blockAtData:) description: a MABooleanDescription label: 'Bloccato' comment: 'Definisce se co...etc... MessageSend>>valueWithEnoughArguments: Receiver: MessageSend(#renderCellContent:on: -> a MADescribedColumn) Arguments and temporary variables: anArray: an Array(a MATimedIvaModel : 1 August 2014 a WAHtmlCanvas 7) args: an Array(a MATimedIvaModel : 1 August 2014 a WAHtmlCanvas) Receiver's instance variables: receiver: a MADescribedColumn selector: #renderCellContent:on: arguments: #() [ self renderer valueWithEnoughArguments: (Array with: anObject with: html with: anInteger) ] in MADescribedColumn(MAColumn)>>renderCell:index:on: Receiver: a MADescribedColumn Arguments and temporary variables: anObject: a MATimedIvaModel : 1 August 2014 anInteger: 7 html: a WAHtmlCanvas Receiver's instance variables: properties: a Dictionary() report: a MAReport accessor: (MASelectorAccessor read: #blockAtData write: #blockAtData:) description: a MABooleanDescription label: 'Bloccato' comment: 'Definisce se co...etc... BlockClosure>>renderOn: Receiver: [ self renderer valueWithEnoughArguments: (Array with: anObject with: html with: anIntege...etc... Arguments and temporary variables: aRenderer: a WAHtmlCanvas Receiver's instance variables: outerContext: MADescribedColumn(MAColumn)>>renderCell:index:on: startpc: 103 numArgs: 0 WAHtmlCanvas(WARenderer)>>render: Receiver: a WAHtmlCanvas Arguments and temporary variables: anObject: [ self renderer valueWithEnoughArguments: (Array with: anObject with...etc... Receiver's instance variables: context: a WARenderContext lastId: nil currentBrush: nil parentBrush: a WATableDataTag WAHtmlCanvas(WACanvas)>>render: Receiver: a WAHtmlCanvas Arguments and temporary variables: anObject: [ self renderer valueWithEnoughArguments: (Array with: anObject with...etc... Receiver's instance variables: context: a WARenderContext lastId: nil currentBrush: nil parentBrush: a WATableDataTag [ self before. canvas render: anObject. self after ] in WATableDataTag(WATagBrush)>>with: Receiver: a WATableDataTag Arguments and temporary variables: anObject: [ self renderer valueWithEnoughArguments: (Array with: anObject with...etc... Receiver's instance variables: canvas: a WAHtmlCanvas parent: a WAGenericTag closed: false attributes: a WAHtmlAttributes('class'->'textCenter required') BlockClosure>>renderOn: Receiver: [ self before. canvas render: anObject. self after ] Arguments and temporary variables: aRenderer: a WAHtmlCanvas Receiver's instance variables: outerContext: WATableDataTag(WATagBrush)>>with: startpc: 98 numArgs: 0 WAHtmlCanvas(WARenderer)>>render: Receiver: a WAHtmlCanvas Arguments and temporary variables: anObject: [ self before. canvas render: anObject. self after ] Receiver's instance variables: context: a WARenderContext lastId: nil currentBrush: nil parentBrush: a WATableDataTag WAHtmlCanvas(WACanvas)>>render: Receiver: a WAHtmlCanvas Arguments and temporary variables: anObject: [ self before. canvas render: anObject. self after ] Receiver's instance variables: context: a WARenderContext lastId: nil currentBrush: nil parentBrush: a WATableDataTag WAHtmlCanvas(WACanvas)>>nest: Receiver: a WAHtmlCanvas Arguments and temporary variables: aBlock: [ self before. canvas render: anObject. self after ] Receiver's instance variables: context: a WARenderContext lastId: nil currentBrush: nil parentBrush: a WATableDataTag WATableDataTag(WABrush)>>with: Receiver: a WATableDataTag Arguments and temporary variables: aBlock: [ self before. canvas render: anObject. self after ] Receiver's instance variables: canvas: a WAHtmlCanvas parent: a WAGenericTag closed: false attributes: a WAHtmlAttributes('class'->'textCenter required') WATableDataTag(WATagBrush)>>with: Receiver: a WATableDataTag Arguments and temporary variables: anObject: [ self renderer valueWithEnoughArguments: (Array with: anObject with...etc... Receiver's instance variables: canvas: a WAHtmlCanvas parent: a WAGenericTag closed: false attributes: a WAHtmlAttributes('class'->'textCenter required') MADescribedColumn(MAColumn)>>renderCell:index:on: Receiver: a MADescribedColumn Arguments and temporary variables: anObject: a MATimedIvaModel : 1 August 2014 anInteger: 7 html: a WAHtmlCanvas Receiver's instance variables: properties: a Dictionary() report: a MAReport accessor: (MASelectorAccessor read: #blockAtData write: #blockAtData:) description: a MABooleanDescription label: 'Bloccato' comment: 'Definisce se co...etc... [ :col | col renderCell: row index: index on: html ] in [ self visibleColumns do: [ :col | col renderCell: row index: index on: html ] ] in [ :index :row | html tableRow class: (self rowStyleForNumber: index); with: [ self visibleColumns do: [ :col | col renderCell: row index: index on: html ] ] ] in MAReport>>renderTableBodyOn: Receiver: a MAReport Arguments and temporary variables: html: a WAHtmlCanvas index: 7 row: a MATimedIvaModel : 1 August 2014 col: a MADescribedColumn Receiver's instance variables: decoration: a WAValueHolder contents: a MAReport rows: a SortedCollection(a MATimedIvaModel : 18 December 2018 a MATimedIvaModel...etc... cache: an Array(a MATimedIvaModel : 18 December 2018 a MATimedIvaModel : 13 Dec...etc... columns: an Array(a MADescribedColumn a MADescribedColumn a MADescribedColumn a...etc... properties: a Dictionary(#sortEnabled->true ) backtracked: a Dictionary(#batchPage->1 ) Array(SequenceableCollection)>>do: Receiver: an Array(a MADescribedColumn a MADescribedColumn a MADescribedColumn a MADescribedColumn a...etc... Arguments and temporary variables: aBlock: [ :col | col renderCell: row index: index on: html ] index: 2 Receiver's instance variables: an Array(a MADescribedColumn a MADescribedColumn a MADescribedColumn a MADescribedColumn a...etc... [ self visibleColumns do: [ :col | col renderCell: row index: index on: html ] ] in [ :index :row | html tableRow class: (self rowStyleForNumber: index); with: [ self visibleColumns do: [ :col | col renderCell: row index: index on: html ] ] ] in MAReport>>renderTableBodyOn: Receiver: a MAReport Arguments and temporary variables: html: a WAHtmlCanvas index: 7 row: a MATimedIvaModel : 1 August 2014 Receiver's instance variables: decoration: a WAValueHolder contents: a MAReport rows: a SortedCollection(a MATimedIvaModel : 18 December 2018 a MATimedIvaModel...etc... cache: an Array(a MATimedIvaModel : 18 December 2018 a MATimedIvaModel : 13 Dec...etc... columns: an Array(a MADescribedColumn a MADescribedColumn a MADescribedColumn a...etc... properties: a Dictionary(#sortEnabled->true ) backtracked: a Dictionary(#batchPage->1 ) BlockClosure>>renderOn: Receiver: [ self visibleColumns do: [ :col | col renderCell: row index: index on: html ] ] Arguments and temporary variables: aRenderer: a WAHtmlCanvas Receiver's instance variables: outerContext: [ :index :row | html tableRow class: (self rowStyleForNumber: i...etc... startpc: 191 numArgs: 0 WAHtmlCanvas(WARenderer)>>render: Receiver: a WAHtmlCanvas Arguments and temporary variables: anObject: [ self visibleColumns do: [ :col | col renderCell: row index: inde...etc... Receiver's instance variables: context: a WARenderContext lastId: nil currentBrush: nil parentBrush: a WATableDataTag WAHtmlCanvas(WACanvas)>>render: Receiver: a WAHtmlCanvas Arguments and temporary variables: anObject: [ self visibleColumns do: [ :col | col renderCell: row index: inde...etc... Receiver's instance variables: context: a WARenderContext lastId: nil currentBrush: nil parentBrush: a WATableDataTag [ self before. canvas render: anObject. self after ] in WAGenericTag(WATagBrush)>>with: Receiver: a WAGenericTag Arguments and temporary variables: anObject: [ self visibleColumns do: [ :col | col renderCell: row index: inde...etc... Receiver's instance variables: canvas: a WAHtmlCanvas parent: a WAGenericTag closed: false attributes: a WAHtmlAttributes('class'->'odd') tag: 'tr' BlockClosure>>renderOn: Receiver: [ self before. canvas render: anObject. self after ] Arguments and temporary variables: aRenderer: a WAHtmlCanvas Receiver's instance variables: outerContext: WAGenericTag(WATagBrush)>>with: startpc: 98 numArgs: 0 WAHtmlCanvas(WARenderer)>>render: Receiver: a WAHtmlCanvas Arguments and temporary variables: anObject: [ self before. canvas render: anObject. self after ] Receiver's instance variables: context: a WARenderContext lastId: nil currentBrush: nil parentBrush: a WATableDataTag WAHtmlCanvas(WACanvas)>>render: Receiver: a WAHtmlCanvas Arguments and temporary variables: anObject: [ self before. canvas render: anObject. self after ] Receiver's instance variables: context: a WARenderContext lastId: nil currentBrush: nil parentBrush: a WATableDataTag WAHtmlCanvas(WACanvas)>>nest: Receiver: a WAHtmlCanvas Arguments and temporary variables: aBlock: [ self before. canvas render: anObject. self after ] Receiver's instance variables: context: a WARenderContext lastId: nil currentBrush: nil parentBrush: a WATableDataTag WAGenericTag(WABrush)>>with: Receiver: a WAGenericTag Arguments and temporary variables: aBlock: [ self before. canvas render: anObject. self after ] Receiver's instance variables: canvas: a WAHtmlCanvas parent: a WAGenericTag closed: false attributes: a WAHtmlAttributes('class'->'odd') tag: 'tr' WAGenericTag(WATagBrush)>>with: Receiver: a WAGenericTag Arguments and temporary variables: anObject: [ self visibleColumns do: [ :col | col renderCell: row index: inde...etc... Receiver's instance variables: canvas: a WAHtmlCanvas parent: a WAGenericTag closed: false attributes: a WAHtmlAttributes('class'->'odd') tag: 'tr' [ :index :row | html tableRow class: (self rowStyleForNumber: index); with: [ self visibleColumns do: [ :col | col renderCell: row index: index on: html ] ] ] in MAReport>>renderTableBodyOn: Receiver: a MAReport Arguments and temporary variables: html: a WAHtmlCanvas index: 7 row: a MATimedIvaModel : 1 August 2014 Receiver's instance variables: decoration: a WAValueHolder contents: a MAReport rows: a SortedCollection(a MATimedIvaModel : 18 December 2018 a MATimedIvaModel...etc... cache: an Array(a MATimedIvaModel : 18 December 2018 a MATimedIvaModel : 13 Dec...etc... columns: an Array(a MADescribedColumn a MADescribedColumn a MADescribedColumn a...etc... properties: a Dictionary(#sortEnabled->true ) backtracked: a Dictionary(#batchPage->1 ) Array(SequenceableCollection)>>keysAndValuesDo: Receiver: an Array(a MATimedIvaModel : 18 December 2018 a MATimedIvaModel : 13 December 2018 a MATim...etc... Arguments and temporary variables: aBlock: [ :index :row | html tableRow class: (self rowStyleForNumber: index);...etc... index: 7 Receiver's instance variables: an Array(a MATimedIvaModel : 18 December 2018 a MATimedIvaModel : 13 December 2018 a MATim...etc... MAReport>>renderTableBodyOn: Receiver: a MAReport Arguments and temporary variables: html: a WAHtmlCanvas Receiver's instance variables: decoration: a WAValueHolder contents: a MAReport rows: a SortedCollection(a MATimedIvaModel : 18 December 2018 a MATimedIvaModel...etc... cache: an Array(a MATimedIvaModel : 18 December 2018 a MATimedIvaModel : 13 Dec...etc... columns: an Array(a MADescribedColumn a MADescribedColumn a MADescribedColumn a...etc... properties: a Dictionary(#sortEnabled->true ) backtracked: a Dictionary(#batchPage->1 ) [ self showBody ifTrue: [ self renderTableBodyOn: html ] ] in MAReport>>renderTableOn: Receiver: a MAReport Arguments and temporary variables: html: a WAHtmlCanvas Receiver's instance variables: decoration: a WAValueHolder contents: a MAReport rows: a SortedCollection(a MATimedIvaModel : 18 December 2018 a MATimedIvaModel...etc... cache: an Array(a MATimedIvaModel : 18 December 2018 a MATimedIvaModel : 13 Dec...etc... columns: an Array(a MADescribedColumn a MADescribedColumn a MADescribedColumn a...etc... properties: a Dictionary(#sortEnabled->true ) backtracked: a Dictionary(#batchPage->1 ) BlockClosure>>renderOn: Receiver: [ self showBody ifTrue: [ self renderTableBodyOn: html ] ] Arguments and temporary variables: aRenderer: a WAHtmlCanvas Receiver's instance variables: outerContext: MAReport>>renderTableOn: startpc: 275 numArgs: 0 WAHtmlCanvas(WARenderer)>>render: Receiver: a WAHtmlCanvas Arguments and temporary variables: anObject: [ self showBody ifTrue: [ self renderTableBodyOn: html ] ] Receiver's instance variables: context: a WARenderContext lastId: nil currentBrush: nil parentBrush: a WATableDataTag WAHtmlCanvas(WACanvas)>>render: Receiver: a WAHtmlCanvas Arguments and temporary variables: anObject: [ self showBody ifTrue: [ self renderTableBodyOn: html ] ] Receiver's instance variables: context: a WARenderContext lastId: nil currentBrush: nil parentBrush: a WATableDataTag --- The full stack --- MATimedIvaModel(Object)>>halt MATimedIvaModel(MATimedInstanceModel)>>blockAtData MASelectorAccessor>>read: MADescribedColumn(MAColumn)>>valueFor: MADescribedColumn>>valueFor: MADescribedColumn(MAColumn)>>renderCellContent:on: MessageSend>>valueWithEnoughArguments: [ self renderer valueWithEnoughArguments: (Array with: anObject with: html with: anInteger) ] in MADescribedColumn(MAColumn)>>renderCell:index:on: BlockClosure>>renderOn: WAHtmlCanvas(WARenderer)>>render: WAHtmlCanvas(WACanvas)>>render: [ self before. canvas render: anObject. self after ] in WATableDataTag(WATagBrush)>>with: BlockClosure>>renderOn: WAHtmlCanvas(WARenderer)>>render: WAHtmlCanvas(WACanvas)>>render: WAHtmlCanvas(WACanvas)>>nest: WATableDataTag(WABrush)>>with: WATableDataTag(WATagBrush)>>with: MADescribedColumn(MAColumn)>>renderCell:index:on: [ :col | col renderCell: row index: index on: html ] in [ self visibleColumns do: [ :col | col renderCell: row index: index on: html ] ] in [ :index :row | html tableRow class: (self rowStyleForNumber: index); with: [ self visibleColumns do: [ :col | col renderCell: row index: index on: html ] ] ] in MAReport>>renderTableBodyOn: Array(SequenceableCollection)>>do: [ self visibleColumns do: [ :col | col renderCell: row index: index on: html ] ] in [ :index :row | html tableRow class: (self rowStyleForNumber: index); with: [ self visibleColumns do: [ :col | col renderCell: row index: index on: html ] ] ] in MAReport>>renderTableBodyOn: BlockClosure>>renderOn: WAHtmlCanvas(WARenderer)>>render: WAHtmlCanvas(WACanvas)>>render: [ self before. canvas render: anObject. self after ] in WAGenericTag(WATagBrush)>>with: BlockClosure>>renderOn: WAHtmlCanvas(WARenderer)>>render: WAHtmlCanvas(WACanvas)>>render: WAHtmlCanvas(WACanvas)>>nest: WAGenericTag(WABrush)>>with: WAGenericTag(WATagBrush)>>with: [ :index :row | html tableRow class: (self rowStyleForNumber: index); with: [ self visibleColumns do: [ :col | col renderCell: row index: index on: html ] ] ] in MAReport>>renderTableBodyOn: Array(SequenceableCollection)>>keysAndValuesDo: MAReport>>renderTableBodyOn: [ self showBody ifTrue: [ self renderTableBodyOn: html ] ] in MAReport>>renderTableOn: BlockClosure>>renderOn: WAHtmlCanvas(WARenderer)>>render: WAHtmlCanvas(WACanvas)>>render: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ self before. canvas render: anObject. self after ] in WAGenericTag(WATagBrush)>>with: BlockClosure>>renderOn: WAHtmlCanvas(WARenderer)>>render: WAHtmlCanvas(WACanvas)>>render: WAHtmlCanvas(WACanvas)>>nest: WAGenericTag(WABrush)>>with: WAGenericTag(WATagBrush)>>with: WAHtmlCanvas>>tableBody: MAReport>>renderTableOn: [ self renderTableOn: html ] in MAReport>>renderContentOn: BlockClosure>>renderOn: WAHtmlCanvas(WARenderer)>>render: WAHtmlCanvas(WACanvas)>>render: [ self before. canvas render: anObject. self after ] in WATableTag(WATagBrush)>>with: BlockClosure>>renderOn: WAHtmlCanvas(WARenderer)>>render: WAHtmlCanvas(WACanvas)>>render: WAHtmlCanvas(WACanvas)>>nest: WATableTag(WABrush)>>with: WATableTag(WATagBrush)>>with: MAReport>>renderContentOn: WARenderVisitor>>visitPainter: WARenderVisitor(WAPainterVisitor)>>visitPresenter: WARenderVisitor(WAPainterVisitor)>>visitComponent: MAReport(WAComponent)>>accept: WARenderVisitor(WAVisitor)>>visit: WARenderingGuide(WAPresenterGuide)>>visitPainter: WARenderingGuide(WAPainterVisitor)>>visitPresenter: WARenderingGuide(WAPainterVisitor)>>visitComponent: MAReport(WAComponent)>>accept: WARenderingGuide(WAPainterVisitor)>>visitDecorationsOfComponent: MAReport(WAComponent)>>acceptDecorated: WARenderingGuide(WAPresenterGuide)>>visit: MAReport(WAPainter)>>renderWithContext: MAReport(WAPainter)>>renderOn: WAHtmlCanvas(WARenderer)>>render: WAHtmlCanvas(WACanvas)>>render: MAOneToManyComponent>>renderViewerOn: MAOneToManyComponent>>renderEditorOn: MAOneToManyComponent(MAElementComponent)>>renderContentOn: WARenderVisitor>>visitPainter: WARenderVisitor(WAPainterVisitor)>>visitPresenter: WARenderVisitor(WAPainterVisitor)>>visitComponent: MAOneToManyComponent(WAComponent)>>accept: WARenderVisitor(WAVisitor)>>visit: WARenderingGuide(WAPresenterGuide)>>visitPainter: WARenderingGuide(WAPainterVisitor)>>visitPresenter: WARenderingGuide(WAPainterVisitor)>>visitComponent: MAOneToManyComponent(WAComponent)>>accept: WARenderingGuide(WAPainterVisitor)>>visitDecorationsOfComponent: MAOneToManyComponent(WAComponent)>>acceptDecorated: WARenderingGuide(WAPresenterGuide)>>visit: MAOneToManyComponent(WAPainter)>>renderWithContext: MAOneToManyComponent(WAPainter)>>renderOn: WAHtmlCanvas(WARenderer)>>render: WAHtmlCanvas(WACanvas)>>render: MATableRenderer(MAComponentRenderer)>>basicRenderControl: [ self basicRenderControl: aDescription ] in MATableRenderer>>renderControl: BlockClosure>>renderOn: WAHtmlCanvas(WARenderer)>>render: WAHtmlCanvas(WACanvas)>>render: [ self before. canvas render: anObject. self after ] in WATableDataTag(WATagBrush)>>with: BlockClosure>>renderOn: WAHtmlCanvas(WARenderer)>>render: WAHtmlCanvas(WACanvas)>>render: WAHtmlCanvas(WACanvas)>>nest: WATableDataTag(WABrush)>>with: WATableDataTag(WATagBrush)>>with: MATableRenderer>>renderControl: MATableRenderer>>renderElementRow: [ self renderElementRow: aDescription ] in MATableRenderer>>renderElement: BlockClosure>>renderOn: WAHtmlCanvas(WARenderer)>>render: WAHtmlCanvas(WACanvas)>>render: [ self before. canvas render: anObject. self after ] in WAGenericTag(WATagBrush)>>with: BlockClosure>>renderOn: WAHtmlCanvas(WARenderer)>>render: WAHtmlCanvas(WACanvas)>>render: WAHtmlCanvas(WACanvas)>>nest: WAGenericTag(WABrush)>>with: WAGenericTag(WATagBrush)>>with: WAHtmlCanvas>>tableRow: MATableRenderer>>renderElement: MATableRenderer(MAComponentRenderer)>>visitElementDescription: MATableRenderer(MAVisitor)>>visitReferenceDescription: MATableRenderer(MAVisitor)>>visitRelationDescription: MATableRenderer(MAVisitor)>>visitToManyRelationDescription: MAToManyRelationDescription>>acceptMagritte: MATableRenderer(MAVisitor)>>visit: [ :each | self visit: each ] in MATableRenderer(MAVisitor)>>visitAll: SortedCollection(OrderedCollection)>>do: MAPriorityContainer(MAContainer)>>do: MATableRenderer(MAVisitor)>>visitAll: MATableRenderer(MAComponentRenderer)>>renderContainer: [ super renderContainer: aDescription ] in MATableRenderer>>renderContainer: BlockClosure>>renderOn: WAHtmlCanvas(WARenderer)>>render: WAHtmlCanvas(WACanvas)>>render: [ self before. canvas render: anObject. self after ] in WATableTag(WATagBrush)>>with: BlockClosure>>renderOn: WAHtmlCanvas(WARenderer)>>render: WAHtmlCanvas(WACanvas)>>render: WAHtmlCanvas(WACanvas)>>nest: WATableTag(WABrush)>>with: WATableTag(WATagBrush)>>with: MATableRenderer>>renderContainer: MATableRenderer(MAComponentRenderer)>>visitContainer: MATableRenderer(MAVisitor)>>visitPriorityContainer: MAPriorityContainer>>acceptMagritte: MATableRenderer(MAVisitor)>>visit: MATableRenderer(MAComponentRenderer)>>component:on: MATableRenderer class(MAComponentRenderer class)>>component:on: MAContainerComponent>>renderContentOn: WARenderVisitor>>visitPainter: WARenderVisitor(WAPainterVisitor)>>visitPresenter: WARenderVisitor(WAPainterVisitor)>>visitComponent: MAContainerComponent(WAComponent)>>accept: WARenderVisitor(WAVisitor)>>visit: WARenderingGuide(WAPresenterGuide)>>visitPainter: WARenderingGuide(WAPainterVisitor)>>visitPresenter: WARenderingGuide(WAPainterVisitor)>>visitComponent: MAContainerComponent(WAComponent)>>accept: MAContainerComponent(WAPresenter)>>renderUndecoratedWithContext: MAFormDecoration(WADecoration)>>renderNextOn: MAFormDecoration(WADecoration)>>renderContentOn: [ super renderContentOn: html. self renderButtonsOn: html ] in MAFormDecoration(MAContainerDecoration)>>renderContentOn: BlockClosure>>renderOn: WAHtmlCanvas(WARenderer)>>render: WAHtmlCanvas(WACanvas)>>render: [ self before. canvas render: anObject. self after ] in WAFormTag(WATagBrush)>>with: BlockClosure>>renderOn: WAHtmlCanvas(WARenderer)>>render: WAHtmlCanvas(WACanvas)>>render: WAHtmlCanvas(WACanvas)>>nest: WAFormTag(WABrush)>>with: WAFormTag(WATagBrush)>>with: MAFormDecoration(MAContainerDecoration)>>renderContentOn: WARenderVisitor>>visitPainter: WARenderVisitor(WAPainterVisitor)>>visitPresenter: WARenderVisitor(WAPainterVisitor)>>visitDecoration: MAFormDecoration(WADecoration)>>accept: WARenderVisitor(WAVisitor)>>visit: WARenderingGuide(WAPresenterGuide)>>visitPainter: WARenderingGuide(WAPainterVisitor)>>visitPresenter: WARenderingGuide(WAPainterVisitor)>>visitDecoration: MAFormDecoration(WADecoration)>>accept: MAFormDecoration(WAPresenter)>>renderUndecoratedWithContext: MAValidationDecoration(WADecoration)>>renderNextOn: MAValidationDecoration(WADecoration)>>renderContentOn: MAValidationDecoration>>renderContentOn: WARenderVisitor>>visitPainter: WARenderVisitor(WAPainterVisitor)>>visitPresenter: WARenderVisitor(WAPainterVisitor)>>visitDecoration: MAValidationDecoration(WADecoration)>>accept: WARenderVisitor(WAVisitor)>>visit: WARenderingGuide(WAPresenterGuide)>>visitPainter: WARenderingGuide(WAPainterVisitor)>>visitPresenter: WARenderingGuide(WAPainterVisitor)>>visitDecoration: MAValidationDecoration(WADecoration)>>accept: MAValidationDecoration(WAPresenter)>>renderUndecoratedWithContext: WAMessageDecoration(WADecoration)>>renderNextOn: WAMessageDecoration>>renderContentOn: -- and more not shown --------------------------------------------------------------------------------- âââââââââââââ > Le 14 dÃ©c. 2018 Ã 14:05, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> a Ã©crit : > > >>> ...........r3732#linux >>> Errore di segmentazione (core dump creato) >>> >>> C) i have a PharoDebug.log but has the size of 16MB. >>> >>> How can I send it to you? >> >> you can try something like https://wetransfer.com <https://wetransfer.com/> > can you download the PharoDebug.log > > from link into my previous email? > > The PharoDebug.log. > > You can view it? > > Dario ................................................ > Questo messaggio contiene i seguenti allegati: > > PharoDebug.log[15.24 MB] > > Dimensioni totali dei file inviati:15.24 MB > Ciao, > > Dario

Dec. 14, 2018

[Pharo 7.0] Build #44: 22772-chooseExistingFileReferenceextensionspathpreview-returning-wrong-FileReference

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

There is a new Pharo build available! The status of the build #44 was: FAILURE. The Pull Request #2075 was integrated: "22772-chooseExistingFileReferenceextensionspathpreview-returning-wrong-FileReference" Pull request url: https://github.com/pharo-project/pharo/pull/2075 Issue Url: https://pharo.fogbugz.com/f/cases/22772 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 14, 2018

Re: [Pharo-dev] Pharo image don't restart

by Trussardi Dario Romano

>> ...........r3732#linux >> Errore di segmentazione (core dump creato) >> >> C) i have a PharoDebug.log but has the size of 16MB. >> >> How can I send it to you? > > you can try something like https://wetransfer.com can you download the PharoDebug.log from link into my previous email? The PharoDebug.log. You can view it? Dario ................................................ Questo messaggio contiene i seguenti allegati: PharoDebug.log[15.24 MB] Dimensioni totali dei file inviati:15.24 MB Ciao, Dario

Dec. 14, 2018

[Pharo 7.0] Build #43: 22744 Package manifest ManifestFuel should be tagged and commented

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

There is a new Pharo build available! The status of the build #43 was: FAILURE. The Pull Request #2052 was integrated: "22744 Package manifest ManifestFuel should be tagged and commented" Pull request url: https://github.com/pharo-project/pharo/pull/2052 Issue Url: https://pharo.fogbugz.com/f/cases/22744 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 14, 2018

[Pharo 7.0] Build #42: 22754-Exception-while-opening-a-MCSubDirectoryRepository

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

There is a new Pharo build available! The status of the build #42 was: SUCCESS. The Pull Request #2062 was integrated: "22754-Exception-while-opening-a-MCSubDirectoryRepository" Pull request url: https://github.com/pharo-project/pharo/pull/2062 Issue Url: https://pharo.fogbugz.com/f/cases/22754 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 14, 2018

Re: [Pharo-dev] Pharo image don't restart

by Christophe Demarey

> Le 14 dÃ©c. 2018 Ã 12:41, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> a Ã©crit : > > Some consideration: > > > At 12 December: > > I work all day with the image. > > at: 19:xx I save the image without any problem. > > But after saved the image the system begin unstable. > > When the mouse go on the windows summary bar ( at the bottom of the Pharo window ) the image crash. > > Some time i can launch - relaunch the same image from the PharoLauncher ( the pharo run but was unstable ) > > at: 19:45 After reload the unstable image ( as mentioned above ) > > i do the save command ( saving it on itself ) and the system crash. > > After this crash ( when i do the image save command ), > > i have not been able to launch the image. > > I do not know the status of this image ( I call this corrupt image ) > > > At 13 December: > > A) From pharoLauncher i launch the corrupt image some time, > > the shell report the issue, > > <errorePharo.txt> > > but don't create the crash.dmp file. > > > > B) After copy the pharoLauncher corrupt image into Pharo7.0-64DTRDevErr entry > > i do this: > > /opt/pharolauncher/pharo-vm$ ./pharo --eden 15207744 /home/party/Pharo/images/Pharo7.0-64DTRDevErr/Pharo7.0-64DTRDevErr.image > > the shell report: > > pthread_setschedparam failed: Operation not permitted > This VM uses a separate heartbeat thread to update its internal clock > and handle events. For best operation, this thread should run at a > higher priority, however the VM was unable to change the priority. The > effect is that heavily loaded systems may experience some latency > issues. If this occurs, please create the appropriate configuration > file in /etc/security/limits.d/ as shown below: > > cat <<END | sudo tee /etc/security/limits.d/pharo.conf > * hard rtprio 2 > * soft rtprio 2 > END > > and report to the pharo mailing list whether this improves behaviour. > > You will need to log out and log back in for the limits to take effect. > For more information please see > ...........r3732#linux > Errore di segmentazione (core dump creato) > > C) i have a PharoDebug.log but has the size of 16MB. > > How can I send it to you? you can try something like https://wetransfer.com

Dec. 14, 2018

Re: [Pharo-dev] Pharo image don't restart

by Trussardi Dario Romano

Some consideration: At 12 December: I work all day with the image. at: 19:xx I save the image without any problem. But after saved the image the system begin unstable. When the mouse go on the windows summary bar ( at the bottom of the Pharo window ) the image crash. Some time i can launch - relaunch the same image from the PharoLauncher ( the pharo run but was unstable ) at: 19:45 After reload the unstable image ( as mentioned above ) i do the save command ( saving it on itself ) and the system crash. After this crash ( when i do the image save command ), i have not been able to launch the image. I do not know the status of this image ( I call this corrupt image ) At 13 December: A) From pharoLauncher i launch the corrupt image some time, the shell report the issue, but don't create the crash.dmp file. B) After copy the pharoLauncher corrupt image into Pharo7.0-64DTRDevErr entry i do this: /opt/pharolauncher/pharo-vm$ ./pharo --eden 15207744 /home/party/Pharo/images/Pharo7.0-64DTRDevErr/Pharo7.0-64DTRDevErr.image the shell report: pthread_setschedparam failed: Operation not permitted This VM uses a separate heartbeat thread to update its internal clock and handle events. For best operation, this thread should run at a higher priority, however the VM was unable to change the priority. The effect is that heavily loaded systems may experience some latency issues. If this occurs, please create the appropriate configuration file in /etc/security/limits.d/ as shown below: cat <<END | sudo tee /etc/security/limits.d/pharo.conf * hard rtprio 2 * soft rtprio 2 END and report to the pharo mailing list whether this improves behaviour. You will need to log out and log back in for the limits to take effect. For more information please see ...........r3732#linux Errore di segmentazione (core dump creato) C) i have a PharoDebug.log but has the size of 16MB. How can I send it to you? This is the status of the problematic. Thanks, Dario

Dec. 14, 2018

[Pharo 7.0] Build #41: 22764 Cleanup EmbeddedFreeType-Tests and EmbeddedFreeType

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

There is a new Pharo build available! The status of the build #41 was: SUCCESS. The Pull Request #2068 was integrated: "22764 Cleanup EmbeddedFreeType-Tests and EmbeddedFreeType" Pull request url: https://github.com/pharo-project/pharo/pull/2068 Issue Url: https://pharo.fogbugz.com/f/cases/22764 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 14, 2018

Re: [Pharo-dev] Pharo image don't restart

by dario.trussardi＠tiscali.it

The PharoDebug.log. You can view it? Dario ................................................ Questo messaggio contiene i seguenti allegati: PharoDebug.log[15.24 MB] Dimensioni totali dei file inviati:15.24 MB Per scaricarli fai click sul link seguente: http://mail.tiscali.it/bigattachments/?c=dab58fa12765311a72d7a919d118e2b1 Allega Maxi Ã¨ il servizio di Tiscali WebMail che permette di allegare file, fino a 2GB, senza problemi di superamento dei limiti delle normali caselle e-mail. Ti ricordiamo che questo link sara' valido fino al giorno 17/12/2018 ................................................ Con OpenStar hai Giga, SMS e i minuti che vuoi da 4,99â¬ al mese, per sempre. Cambi gratis quando e come vuoi e in piÃ¹ hai 10â¬ di credito omaggio e 6 mesi di INFINTY! http://tisca.li/myopen

Dec. 14, 2018

[Pharo 7.0] Build #40: 22769-KeyboardKey-classunixVirtualKeyTable-uses-KeyTable-instead-of-UnixKeyTable-

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

There is a new Pharo build available! The status of the build #40 was: FAILURE. The Pull Request #2074 was integrated: "22769-KeyboardKey-classunixVirtualKeyTable-uses-KeyTable-instead-of-UnixKeyTable-" Pull request url: https://github.com/pharo-project/pharo/pull/2074 Issue Url: https://pharo.fogbugz.com/f/cases/22769 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 14, 2018

[Pharo 7.0] Build #39: 22728-Add-enough-informations-to-Metacello-to-load-a-project-from-a-gitlab-deployed-with-non-default-ssh-port

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

There is a new Pharo build available! The status of the build #39 was: SUCCESS. The Pull Request #2041 was integrated: "22728-Add-enough-informations-to-Metacello-to-load-a-project-from-a-gitlab-deployed-with-non-default-ssh-port" Pull request url: https://github.com/pharo-project/pharo/pull/2041 Issue Url: https://pharo.fogbugz.com/f/cases/22728 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 14, 2018

[Pharo 7.0] Build #38: 22767 Categorize uncategorized classes in Tool-Finder

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

There is a new Pharo build available! The status of the build #38 was: SUCCESS. The Pull Request #2070 was integrated: "22767 Categorize uncategorized classes in Tool-Finder" Pull request url: https://github.com/pharo-project/pharo/pull/2070 Issue Url: https://pharo.fogbugz.com/f/cases/22767 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 14, 2018

[Pharo 7.0] Build #37: 22766-Transcript-window-is-leaking

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

There is a new Pharo build available! The status of the build #37 was: SUCCESS. The Pull Request #2071 was integrated: "22766-Transcript-window-is-leaking" Pull request url: https://github.com/pharo-project/pharo/pull/2071 Issue Url: https://pharo.fogbugz.com/f/cases/22766 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 14, 2018

glamorous toolkit: v0.4.0

by Tudor Girba

Hi, Things are moving fast in the glamorous land. We now reached v0.4.0: https://gtoolkit.com There are several significant advances in this version. The first thing to note is that v0.4.0 is a reproducible version that can be loaded with: Metacello new baseline: 'GToolkit'; repository: 'github://feenkcom/gtoolkit:v0.4.0/src'; load. https://github.com/feenkcom/gtoolkit/releases/tag/v0.4.0 The version was created with Releaser the new member of GT that is able to release deeply nested projects: https://twitter.com/girba/status/1073407418460225536 The rest of the environment has seen a few key changes as well: - Documenter received support for dynamic markup edit. This is an almost magic ability that makes the markup appear when the cursor nears the markup. With this we have reached a seamless experience that supports both viewing without markup and editing on demand. https://twitter.com/feenkcom/status/1067879286143676419 - Playground uses Coder and snippets are now collapsable. https://twitter.com/feenkcom/status/1070806168459767809 - The Inspector updates when the code changes. https://twitter.com/feenkcom/status/1072581283925159936 https://twitter.com/feenkcom/status/1072107898900238337 - The Meta view from Inspector was enhanced to show the super classes and method categories, each of these act list filters. On top of that, we can also filter methods by name. https://twitter.com/feenkcom/status/1072223641583149057 A more complete list of issues we addressed is found here: https://github.com/feenkcom/gtoolkit/milestone/2?closed=1 Please do let us know what you think .. and, of course, what you feel. Have fun, The feenk team -- www.feenk.com âHow do you feenk today?"

Dec. 14, 2018

Re: [Pharo-dev] Pharo image don't restart

by Trussardi Dario Romano

Ciao, > >> Le 13 dÃ©c. 2018 Ã 17:31, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> a Ã©crit : >> >> Ciao, >> >>> Hi, >>> >>> The problem seems to come from: "no room in eden for allocateSmallNewSpaceSlots:format:classIndex:" >>> Eden is a part of the heap where new objects are allocated. >>> Basically, it appears that Pharo cannot create objects any more. >>> You can get information about gc and eden space here: >>> >>> Could you try to run your image in headless mode to see if it starts? >>> ex: >>> >>> I would try to start your image with a bigger size for the eden. >>> ClÃ©ment recommends to do: Smalltalk vm parameterAt: 45 put: (Smalltalk vm parameterAt: 44) * 4. >>> but it means you need an image that is started â¦ >>> >>> You can also set it as an argument to the VM: --eden <size>[mk] >>> >>> You could try with âeden 15207744 for example: >>> ~/Documents/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo --eden 15207744 ~/Documents/Pharo/images/Pharo\ 7.0\ -\ 64bit\ $development\ version$/Pharo\ 7.0\ -\ 64bit\ $development\ version$.image >> >> After copy the pharoLauncher entry with the error into Pharo7.0-64DTRDevErr entry >> >> i do this: >> >> /opt/pharolauncher/pharo-vm$ ./pharo --eden 15207744 /home/party/Pharo/images/Pharo7.0-64DTRDevErr/Pharo7.0-64DTRDevErr.image >> >> the shell report: >> >> pthread_setschedparam failed: Operation not permitted >> >> ***** This VM uses a separate heartbeat thread to update its internal clock >> and handle events. For best operation, this thread should run at a >> higher priority, however the VM was unable to change the priority. The >> effect is that heavily loaded systems may experience some latency >> issues. If this occurs, please create the appropriate configuration >> file in /etc/security/limits.d/ as shown below: >> >> cat <<END | sudo tee /etc/security/limits.d/pharo.conf >> * hard rtprio 2 >> * soft rtprio 2 >> END >> >> and report to the pharo mailing list whether this improves behaviour. >> >> You will need to log out and log back in for the limits to take effect. >> For more information please see >> ...........r3732#linux >> Errore di segmentazione (core dump creato) >> >> Any idea about it? > > So you have a segmentation fault. It means the image tries to access a memory address outside the memory range of its process. > using gdb on the core dump could help to have more clues: https://www.cprogramming.com/debugging/segfaults.html Tomorrow i investigate about it. > Do you also have a segmentation fault if you run the image without the eden parameter? No without eden parameter the system report the basic error >> The ***** message required some action ? > > this message is just a warning. If you want to avoid it, just execute this as root: >> cat <<END | sudo tee /etc/security/limits.d/pharo.conf >> * hard rtprio 2 >> * soft rtprio 2 >> END > >> P.S. I have to conclude that there is no solution? > > For now, it is too early to have a conclusion because we do not know what caused the crash. > As Eliot said, it could be useful to get the crash.dmp file and the PharoDebug.log file. The crash.dmp is not create. ( If i right do the command to create it : From pharoLauncher i launch the corrupt image some time, the shell report the issue, but don't create the crash.dmp file). For PharoDebug.log i'm not in office, I'll check tomorrow. Thanks, Dario

Dec. 13, 2018

Re: [Pharo-dev] Pharo image don't restart

by Christophe Demarey

> Le 13 dÃ©c. 2018 Ã 17:31, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> a Ã©crit : > > Ciao, > >> Hi, >> >> The problem seems to come from: "no room in eden for allocateSmallNewSpaceSlots:format:classIndex:" >> Eden is a part of the heap where new objects are allocated. >> Basically, it appears that Pharo cannot create objects any more. >> You can get information about gc and eden space here: https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-colle… <https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-colle…> >> >> Could you try to run your image in headless mode to see if it starts? >> ex: >> >> I would try to start your image with a bigger size for the eden. >> ClÃ©ment recommends to do: Smalltalk vm parameterAt: 45 put: (Smalltalk vm parameterAt: 44) * 4. >> but it means you need an image that is started â¦ >> >> You can also set it as an argument to the VM: --eden <size>[mk] >> >> You could try with âeden 15207744 for example: >> ~/Documents/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo --eden 15207744 ~/Documents/Pharo/images/Pharo\ 7.0\ -\ 64bit\ $development\ version$/Pharo\ 7.0\ -\ 64bit\ $development\ version$.image > > After copy the pharoLauncher entry with the error into Pharo7.0-64DTRDevErr entry > > i do this: > > /opt/pharolauncher/pharo-vm$ ./pharo --eden 15207744 /home/party/Pharo/images/Pharo7.0-64DTRDevErr/Pharo7.0-64DTRDevErr.image > > the shell report: > > pthread_setschedparam failed: Operation not permitted > > ***** This VM uses a separate heartbeat thread to update its internal clock > and handle events. For best operation, this thread should run at a > higher priority, however the VM was unable to change the priority. The > effect is that heavily loaded systems may experience some latency > issues. If this occurs, please create the appropriate configuration > file in /etc/security/limits.d/ as shown below: > > cat <<END | sudo tee /etc/security/limits.d/pharo.conf > * hard rtprio 2 > * soft rtprio 2 > END > > and report to the pharo mailing list whether this improves behaviour. > > You will need to log out and log back in for the limits to take effect. > For more information please see > ...........r3732#linux > Errore di segmentazione (core dump creato) > > Any idea about it? So you have a segmentation fault. It means the image tries to access a memory address outside the memory range of its process. using gdb on the core dump could help to have more clues: https://www.cprogramming.com/debugging/segfaults.html <https://www.cprogramming.com/debugging/segfaults.html> Do you also have a segmentation fault if you run the image without the eden parameter? > The ***** message required some action ? this message is just a warning. If you want to avoid it, just execute this as root: > cat <<END | sudo tee /etc/security/limits.d/pharo.conf > * hard rtprio 2 > * soft rtprio 2 > END > P.S. I have to conclude that there is no solution? For now, it is too early to have a conclusion because we do not know what caused the crash. As Eliot said, it could be useful to get the crash.dmp file and the PharoDebug.log file.

Dec. 13, 2018

Re: [Pharo-dev] Pharo image don't restart

by Trussardi Dario Romano

Ciao, > Hi All, > > On Dec 13, 2018, at 5:40 AM, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > >> Hi, >> >> The problem seems to come from: "no room in eden for allocateSmallNewSpaceSlots:format:classIndex:" > > Then there should be a crash.dmp file that includes a stack trace. Iâm surprised the VM exists by this path; I would expect the system to retry the allocation with an old space allocation that should work. > > So, Dario, please keep a copy of your image and changes. And please email me the crash.dmp file. Create a clean one by deleting it first and then running the system until it fails and exits. Multiple exits append to the crash.dmp file so it can end up being quite large. OK. From pharoLauncher i launch the corrupt image some time, the shell report the issue, but don't create the crash.dmp file. Thanks, Dario > >> Eden is a part of the heap where new objects are allocated. >> Basically, it appears that Pharo cannot create objects any more. >> You can get information about gc and eden space here: https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-colle… >> >> Could you try to run your image in headless mode to see if it starts? >> ex: >> >> I would try to start your image with a bigger size for the eden. >> ClÃ©ment recommends to do: Smalltalk vm parameterAt: 45 put: (Smalltalk vm parameterAt: 44) * 4. >> but it means you need an image that is started â¦ >> >> You can also set it as an argument to the VM: --eden <size>[mk] >> >> You could try with âeden 15207744 for example: >> ~/Documents/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo --eden 15207744 ~/Documents/Pharo/images/Pharo\ 7.0\ -\ 64bit\ $development\ version$/Pharo\ 7.0\ -\ 64bit\ $development\ version$.image >> >> Regards, >> Christophe >> >> >>> Le 13 dÃ©c. 2018 Ã 09:25, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> a Ã©crit : >>> >>> Ciao, >>> >>> i have a Ubuntu system >>> where i defined a Pharo 7.0 - 64bit image managed with PharoLauncher. >>> >>> I work with it for a month and all work fine. >>> >>> Now after a save the image the system begin unstabled. >>> >>> When the mouse go on the windows summary bar ( at the bottom of the Pharo window ) the image go down. >>> >>> The first time i can launch the same image from the PharoLauncher, >>> >>> but after a new image save ( the image go down ) i can't relaunch the image. >>> >>> When i do the launch the pharoLauch shell report: >>> >>> <errorePharo.txt> >>> >>> I have some important work in the image ( and i don't have a backup ) >>> >>> Some consideration? >>> >>> Thanks, >>> Dario >>> >>

Dec. 13, 2018

Re: [Pharo-dev] [Vm-dev] LibC system pops up a CMD.exe window in Windows 10 (Pharo 6.1)

by Nicolas Cellier

Unfortunately you are right, thru system() call, there's no way to avoid the window popping up AFAIK. The library you are using, whatever it is, should invoke lower level API. The one from Levente (as indicated by Guile) souds OK from a rapid scan of source code. https://github.com/astares/Pharo-OS-Windows is not very far either with some little modifications, and is FFI based. so it's just a matter of picking code from here and there until libraries are powerful enough... IMO, there's no point in maintaining N different libraries, each with own flaw. I've always seen such fragmentation as a weakness (IOW it's a failure of core library to provide standard useful feature). I can understand that one alternative is FFI based, the other plugin based. But at the end, each should do the right thing or die. Le jeu. 13 dÃ©c. 2018 Ã 17:44, Christopher Fuhrman < christopher.fuhrman(a)inria.fr> a Ã©crit : > > On Wed, 12 Dec 2018 at 11:55, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >> Hi all, >> >> I think that Christopher and Peter are talking about ProcessWrapper and >> not OSProcess, >> > > Thanks to all who answered. I'm primarily interested in staying with LibC > because of its simplicity, robustness and its cross-platform compatibility > (although I have yet to run some of my code on Linux). From what I > understand after talking with Esteban, the ffi call to system() > in msvcrt.dll doesn't have any way to specify the Windows' option for the > CMD.EXE window, e.g., SW_HIDE. > > I have other ideas that maybe a future VM could implementation could > consider (if that's where the change would need to go), including > specifying a SETENV variable that is pharo-LibC-specific for turning on/off > the CMD.exe window. > > Christopher > > >> which is fetched from here: >> >> http://leves.web.elte.hu/ProcessWrapper/ >> >> I think this was originally Levente's work? >> The source code is stored in a zip next to the dll in the same server, no >> history attached to it. >> >> Guille >> >> On Wed, Dec 12, 2018 at 12:30 AM Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> >>> >>> Hi Nicolas, >>> >>> On Tue, Dec 11, 2018 at 5:43 AM Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>>> >>>> I've checked: it's a one liner to be changed in >>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/Win3… >>>> near line 826 >>>> >>> >>> So what changes do you want exactly? I'm happy to do the >>> Smalltalk/Slang writing (adding the parameter, etc) but I don't know what >>> result you'd like to see. Can you post the body of the function as you'd >>> like to see it or the lines around line 826? >>> >>> >>>> Since this is generated code from VMMaker, the code has to be changed >>>> in slang. >>>> IMO, there should be a boolean argument (optional) telling if we want >>>> to open the console or not. >>>> IMO false by default would be a good thing, though true for backward >>>> compatibility is also a possible alternative... >>>> >>>> Le mar. 11 dÃ©c. 2018 Ã 12:56, Nicolas Cellier < >>>> nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : >>>> >>>>> It is possible, ask stack overflow >>>>> >>>>> https://stackoverflow.com/questions/4743559/how-to-execute-child-console-pr… >>>>> >>>>> https://stackoverflow.com/questions/18841971/hide-console-window-while-runn… >>>>> >>>>> I've recently "fixed" my own script in Visualworks so as to use these >>>>> low level API (already procided by VW) >>>>> >>>>> BOOL CreateProcessW( >>>>> LPCWSTR imageName, >>>>> LPCWSTR commandLine, >>>>> struct SECURITY_ATTRIBUTES *pSecurity, >>>>> struct SECURITY_ATTRIBUTES *tSecurity, >>>>> BOOL inheritHandles, >>>>> DWORD creationFlags, >>>>> LPVOID environment, >>>>> LPWSTR currentDirectoryName, >>>>> struct STARTUPINFO *startupInfo, >>>>> struct PROCESS_INFORMATION *processInfo) >>>>> >>>>> First argument is fullpath to cmd.exe (take it from environment >>>>> variable 'ComSpec') >>>>> Second argument is '/u /c ' , 'your command here encoded in utf16' >>>>> Security arguments are nil and nil >>>>> inheritHandles is true >>>>> creationFlags is zero >>>>> environment is nil >>>>> currentDirectoryName is nil >>>>> >>>>> startupInfo is more involved: it must be used to pass the pair of >>>>> pipes (handles) for input/output: >>>>> struct STARTUPINFO { >>>>> DWORD cb; >>>>> LPTSTR lpReserved; >>>>> LPTSTR lpDesktop; >>>>> LPTSTR lpTitle; >>>>> DWORD dwX; >>>>> DWORD dwY; >>>>> DWORD dwXSize; >>>>> DWORD dwYSize; >>>>> DWORD dwXCountChars; >>>>> DWORD dwYCountChars; >>>>> DWORD dwFillAttribute; >>>>> DWORD dwFlags; >>>>> WORD wShowWindow; >>>>> WORD cbReserved2; >>>>> LPBYTE lpReserved2; >>>>> HANDLE hStdInput; >>>>> HANDLE hStdOutput; >>>>> HANDLE hStdError; >>>>> } >>>>> >>>>> You initialize it with void GetStartupInfoW(LPSTARTUPINFO >>>>> lpStartupInfo) >>>>> IMPORTANT: set wShowWindow to 0, >>>>> and then pass the input/output/error handles in last three fields. >>>>> >>>>> processInfo will contain information on output and must be allocated >>>>> struct PROCESS_INFORMATION { >>>>> HANDLE hProcess; >>>>> HANDLE hThread; >>>>> DWORD dwProcessId; >>>>> DWORD dwThreadId; >>>>> } >>>>> >>>>> you can then get exit status thru BOOL GetExitCodeProcess call, close >>>>> the pipes, etc... >>>>> >>>>> >>>>> Le mar. 11 dÃ©c. 2018 Ã 10:08, Christopher Fuhrman < >>>>> christopher.fuhrman(a)inria.fr> a Ã©crit : >>>>> >>>>>> Thanks Peter. That looks like a cool package. I guess I will live >>>>>> with it for now, because I don't want to code too much of a >>>>>> platform-specific solution (yet). >>>>>> >>>>>> On Mon, 10 Dec 2018 at 21:16, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>>>> >>>>>>> This is normal (and much lamented) behavior of cmd. There's >>>>>>> https://github.com/astares/Pharo-OS-Windows which implements parts >>>>>>> of the WinAPI... with which one can create headless windows. (I think it >>>>>>> should be also available in the catalog). >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> On Mon, Dec 10, 2018 at 11:47 AM Christopher Fuhrman < >>>>>>> christopher.fuhrman(a)inria.fr> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> My Git data mining API in Pharo 6.1 uses "LibC uniqueInstance >>>>>>>> system: 'some commands'" which has an annoying side effect of popping up a >>>>>>>> window (which steals the GUI focus in Windows 10). Maybe it's the same on >>>>>>>> MacOS and Linux? >>>>>>>> >>>>>>>> As such, I can't use my Windows PC to do anything else when the >>>>>>>> mining process is running (it can take several minutes). I'm not able to >>>>>>>> use Pharo's OSProcess or OSSubprocess because they don't support Windows >>>>>>>> (yet?). >>>>>>>> >>>>>>>> I tried creating a separate Windows Desktop (feature of Windows >>>>>>>> 10), but the CMD.EXE window manages to pop up there, too - almost seems >>>>>>>> like a windows bug. >>>>>>>> >>>>>>>> Does anyone know of a way to have the LibC window not pop up? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Christopher >>>>>>>> >>>>>>> >>> _,,,^..^,,,_ >>> best, Eliot >>> >> >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> French National Center for Scientific Research - *http://www.cnrs.fr >> <http://www.cnrs.fr>* >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 >> >

Dec. 13, 2018

Re: [Pharo-dev] Pharo image don't restart

by Eliot Miranda

Hi All, > On Dec 13, 2018, at 5:40 AM, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > > Hi, > > The problem seems to come from: "no room in eden for allocateSmallNewSpaceSlots:format:classIndex:" Then there should be a crash.dmp file that includes a stack trace. Iâm surprised the VM exists by this path; I would expect the system to retry the allocation with an old space allocation that should work. So, Dario, please keep a copy of your image and changes. And please email me the crash.dmp file. Create a clean one by deleting it first and then running the system until it fails and exits. Multiple exits append to the crash.dmp file so it can end up being quite large. > Eden is a part of the heap where new objects are allocated. > Basically, it appears that Pharo cannot create objects any more. > You can get information about gc and eden space here: https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-colle… > > Could you try to run your image in headless mode to see if it starts? > ex: > > I would try to start your image with a bigger size for the eden. > ClÃ©ment recommends to do: Smalltalk vm parameterAt: 45 put: (Smalltalk vm parameterAt: 44) * 4. > but it means you need an image that is started â¦ > > You can also set it as an argument to the VM: --eden <size>[mk] > > You could try with âeden 15207744 for example: > ~/Documents/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo --eden 15207744 ~/Documents/Pharo/images/Pharo\ 7.0\ -\ 64bit\ $development\ version$/Pharo\ 7.0\ -\ 64bit\ $development\ version$.image > > Regards, > Christophe > > >> Le 13 dÃ©c. 2018 Ã 09:25, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> a Ã©crit : >> >> Ciao, >> >> i have a Ubuntu system >> where i defined a Pharo 7.0 - 64bit image managed with PharoLauncher. >> >> I work with it for a month and all work fine. >> >> Now after a save the image the system begin unstabled. >> >> When the mouse go on the windows summary bar ( at the bottom of the Pharo window ) the image go down. >> >> The first time i can launch the same image from the PharoLauncher, >> >> but after a new image save ( the image go down ) i can't relaunch the image. >> >> When i do the launch the pharoLauch shell report: >> >> <errorePharo.txt> >> >> I have some important work in the image ( and i don't have a backup ) >> >> Some consideration? >> >> Thanks, >> Dario >> >

Dec. 13, 2018

Re: [Pharo-dev] Application entrypoints

by Eliot Miranda

Hi Ben, On Wed, Dec 12, 2018 at 6:41 PM Ben Coman <btc(a)openinworld.com> wrote: > A question was asked on discord... "I know how to start the lights out > example, > and feed my objects test data with the testing framework, but how does one > start > something like ChineseCheckers? How does one find the entry point? > Is there a convention on naming a starting place?" > > I remember having similar thoughts when starting in Pharo. > > One convention I have seen is that amongst all the classes presumably > prefixed "CC" > one class would stand out being named for the application without the > prefix. > e.g. class "ChineseCheckers". That is only a narrow chance for a > namespace conflict, > the the risk still remains. > > I suggested another path would have a package tag "Application" > (i.e. "ChineseCheckers-Application") that contains a single class > which has an #open method on the class-side. > The tag "Application" sorts high up on the package-tags and is > self-descriptive. > But I've not seen that used before, so while I think its a good idea, its > not really a convention. > Conventions are only useful if they are broadly understood. > > So I'm wondering what other things people do to draw attention to their > application entry points. > I use a combination of class-side categories (instance creation, examples, api, etc) and class comments. e.g. in the class comment for StackInterpreterSimulator in VMMaker you'll find: | vm | vm := StackInterpreterSimulator newWithOptions: #(). vm openOn: '/Users/eliot/Squeak/Squeak4.4/trunk44.image'. vm setBreakSelector: #&. vm openAsMorph; run But the above is hard to find. I buy Doru's examples approach. Usually interesting objects are used in some kind of context and there may be a flow that the above illustrates, instantiation => initialization => use. All this is possible with examples, and examples have a pragma to identify them to tools. So I would push the examples direction. I guess the kernel of this approach is to create a method that creates and uses some object, and that is labelled with a specific pragma identifying it as an example. It can then serve as both a test and an example to users. > cheers -ben > _,,,^..^,,,_ best, Eliot

Dec. 13, 2018

Re: [Pharo-dev] [Vm-dev] LibC system pops up a CMD.exe window in Windows 10 (Pharo 6.1)

by Christopher Fuhrman

On Wed, 12 Dec 2018 at 11:55, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi all, > > I think that Christopher and Peter are talking about ProcessWrapper and > not OSProcess, > Thanks to all who answered. I'm primarily interested in staying with LibC because of its simplicity, robustness and its cross-platform compatibility (although I have yet to run some of my code on Linux). From what I understand after talking with Esteban, the ffi call to system() in msvcrt.dll doesn't have any way to specify the Windows' option for the CMD.EXE window, e.g., SW_HIDE. I have other ideas that maybe a future VM could implementation could consider (if that's where the change would need to go), including specifying a SETENV variable that is pharo-LibC-specific for turning on/off the CMD.exe window. Christopher > which is fetched from here: > > http://leves.web.elte.hu/ProcessWrapper/ > > I think this was originally Levente's work? > The source code is stored in a zip next to the dll in the same server, no > history attached to it. > > Guille > > On Wed, Dec 12, 2018 at 12:30 AM Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> >> Hi Nicolas, >> >> On Tue, Dec 11, 2018 at 5:43 AM Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> >>> I've checked: it's a one liner to be changed in >>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/Win3… >>> near line 826 >>> >> >> So what changes do you want exactly? I'm happy to do the Smalltalk/Slang >> writing (adding the parameter, etc) but I don't know what result you'd like >> to see. Can you post the body of the function as you'd like to see it or >> the lines around line 826? >> >> >>> Since this is generated code from VMMaker, the code has to be changed in >>> slang. >>> IMO, there should be a boolean argument (optional) telling if we want to >>> open the console or not. >>> IMO false by default would be a good thing, though true for backward >>> compatibility is also a possible alternative... >>> >>> Le mar. 11 dÃ©c. 2018 Ã 12:56, Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com> a Ã©crit : >>> >>>> It is possible, ask stack overflow >>>> >>>> https://stackoverflow.com/questions/4743559/how-to-execute-child-console-pr… >>>> >>>> https://stackoverflow.com/questions/18841971/hide-console-window-while-runn… >>>> >>>> I've recently "fixed" my own script in Visualworks so as to use these >>>> low level API (already procided by VW) >>>> >>>> BOOL CreateProcessW( >>>> LPCWSTR imageName, >>>> LPCWSTR commandLine, >>>> struct SECURITY_ATTRIBUTES *pSecurity, >>>> struct SECURITY_ATTRIBUTES *tSecurity, >>>> BOOL inheritHandles, >>>> DWORD creationFlags, >>>> LPVOID environment, >>>> LPWSTR currentDirectoryName, >>>> struct STARTUPINFO *startupInfo, >>>> struct PROCESS_INFORMATION *processInfo) >>>> >>>> First argument is fullpath to cmd.exe (take it from environment >>>> variable 'ComSpec') >>>> Second argument is '/u /c ' , 'your command here encoded in utf16' >>>> Security arguments are nil and nil >>>> inheritHandles is true >>>> creationFlags is zero >>>> environment is nil >>>> currentDirectoryName is nil >>>> >>>> startupInfo is more involved: it must be used to pass the pair of pipes >>>> (handles) for input/output: >>>> struct STARTUPINFO { >>>> DWORD cb; >>>> LPTSTR lpReserved; >>>> LPTSTR lpDesktop; >>>> LPTSTR lpTitle; >>>> DWORD dwX; >>>> DWORD dwY; >>>> DWORD dwXSize; >>>> DWORD dwYSize; >>>> DWORD dwXCountChars; >>>> DWORD dwYCountChars; >>>> DWORD dwFillAttribute; >>>> DWORD dwFlags; >>>> WORD wShowWindow; >>>> WORD cbReserved2; >>>> LPBYTE lpReserved2; >>>> HANDLE hStdInput; >>>> HANDLE hStdOutput; >>>> HANDLE hStdError; >>>> } >>>> >>>> You initialize it with void GetStartupInfoW(LPSTARTUPINFO lpStartupInfo) >>>> IMPORTANT: set wShowWindow to 0, >>>> and then pass the input/output/error handles in last three fields. >>>> >>>> processInfo will contain information on output and must be allocated >>>> struct PROCESS_INFORMATION { >>>> HANDLE hProcess; >>>> HANDLE hThread; >>>> DWORD dwProcessId; >>>> DWORD dwThreadId; >>>> } >>>> >>>> you can then get exit status thru BOOL GetExitCodeProcess call, close >>>> the pipes, etc... >>>> >>>> >>>> Le mar. 11 dÃ©c. 2018 Ã 10:08, Christopher Fuhrman < >>>> christopher.fuhrman(a)inria.fr> a Ã©crit : >>>> >>>>> Thanks Peter. That looks like a cool package. I guess I will live with >>>>> it for now, because I don't want to code too much of a platform-specific >>>>> solution (yet). >>>>> >>>>> On Mon, 10 Dec 2018 at 21:16, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>>> >>>>>> This is normal (and much lamented) behavior of cmd. There's >>>>>> https://github.com/astares/Pharo-OS-Windows which implements parts >>>>>> of the WinAPI... with which one can create headless windows. (I think it >>>>>> should be also available in the catalog). >>>>>> >>>>>> Peter >>>>>> >>>>>> On Mon, Dec 10, 2018 at 11:47 AM Christopher Fuhrman < >>>>>> christopher.fuhrman(a)inria.fr> wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> My Git data mining API in Pharo 6.1 uses "LibC uniqueInstance >>>>>>> system: 'some commands'" which has an annoying side effect of popping up a >>>>>>> window (which steals the GUI focus in Windows 10). Maybe it's the same on >>>>>>> MacOS and Linux? >>>>>>> >>>>>>> As such, I can't use my Windows PC to do anything else when the >>>>>>> mining process is running (it can take several minutes). I'm not able to >>>>>>> use Pharo's OSProcess or OSSubprocess because they don't support Windows >>>>>>> (yet?). >>>>>>> >>>>>>> I tried creating a separate Windows Desktop (feature of Windows 10), >>>>>>> but the CMD.EXE window manages to pop up there, too - almost seems like a >>>>>>> windows bug. >>>>>>> >>>>>>> Does anyone know of a way to have the LibC window not pop up? >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Christopher >>>>>>> >>>>>> >> _,,,^..^,,,_ >> best, Eliot >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 >

Dec. 13, 2018

Re: [Pharo-dev] Pharo image don't restart

by Trussardi Dario Romano

Ciao, > Hi, > > The problem seems to come from: "no room in eden for allocateSmallNewSpaceSlots:format:classIndex:" > Eden is a part of the heap where new objects are allocated. > Basically, it appears that Pharo cannot create objects any more. > You can get information about gc and eden space here: https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-colle… > > Could you try to run your image in headless mode to see if it starts? > ex: > > I would try to start your image with a bigger size for the eden. > ClÃ©ment recommends to do: Smalltalk vm parameterAt: 45 put: (Smalltalk vm parameterAt: 44) * 4. > but it means you need an image that is started â¦ > > You can also set it as an argument to the VM: --eden <size>[mk] > > You could try with âeden 15207744 for example: > ~/Documents/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo --eden 15207744 ~/Documents/Pharo/images/Pharo\ 7.0\ -\ 64bit\ $development\ version$/Pharo\ 7.0\ -\ 64bit\ $development\ version$.image After copy the pharoLauncher entry with the error into Pharo7.0-64DTRDevErr entry i do this: /opt/pharolauncher/pharo-vm$ ./pharo --eden 15207744 /home/party/Pharo/images/Pharo7.0-64DTRDevErr/Pharo7.0-64DTRDevErr.image the shell report: pthread_setschedparam failed: Operation not permitted ***** This VM uses a separate heartbeat thread to update its internal clock and handle events. For best operation, this thread should run at a higher priority, however the VM was unable to change the priority. The effect is that heavily loaded systems may experience some latency issues. If this occurs, please create the appropriate configuration file in /etc/security/limits.d/ as shown below: cat <<END | sudo tee /etc/security/limits.d/pharo.conf * hard rtprio 2 * soft rtprio 2 END and report to the pharo mailing list whether this improves behaviour. You will need to log out and log back in for the limits to take effect. For more information please see ...........r3732#linux Errore di segmentazione (core dump creato) Any idea about it? The ***** message required some action ? I need to configure some operating system value ? Thanks, Dario P.S. I have to conclude that there is no solution?

Dec. 13, 2018

Re: [Pharo-dev] Problem loading a branch of my pharo fork in an image

by Thomas Dupriez

I retried what I described below, but this time I cloned my pharo fork using the "Clone from github" option instead of the "Clone remote repository". It's better, but not perfect. here are the differences: - the pharo repo is marked as "Detached working Copy" instead of "Fetch required. Unknown 67dc1e8" - the changes to the WorldState class>>debugOn: were loaded this time - however, the package I had added to my branch (BreakpointBrowser) was not present, and not shown among the packages iceberg showed when double-clickig on the pharo repo Thomas Dupriez On 13/12/2018 16:18, Thomas Dupriez wrote: > Hello, > > I loaded a branch of my pharo fork in an image using iceberg, but the > method I was interested in did not change for some reason (my branch's > latest commit changes this method, but these changes were not visible > in the image I loaded my branch in). > > Does someone has an idea of what could have happened? Did I do > something wrong? > > Here's what I did step-by-step if that helps: > > - fresh pharo 7 image > - open iceberg > - repair repository "pharo" > - Clicked "Clone again this repository" > - Chose "Clone remote repository", and put the url of my pharo fork: > "https://github.com/dupriezt/pharo" > - ok > - wait for loading bar to complete > - pharo repo is marked as "Fetch required. Unknown 67dc1e8" > - repair repository "pharo" > - chose "Discard local changes and checkout an existing branch" > - chose the branch "BreakpointBrowser" from the "origin" remote > - Clicked "checkout" on the checkout preview window > - wait for loading bar to complete > - browse the method WorldState class>>debugOn: > - It is different from the last commit I made to this branch > (https://github.com/dupriezt/pharo/commit/ead94e32f138eb435a95cd889f77ca39d4…) > > Thomas Dupriez > >

Dec. 13, 2018

Re: [Pharo-dev] Application entrypoints

by Tim Mackinnon

Actually - kind of related, how does one know how to reset a framework like Seaside, or Zinc etc. Iâve been thinking about proposing frameworks should have a #reset like pragma and then the system menu could find them and show the reset menu for all frameworks that provide it. I think applications could do a similar thing - have an #applicationStart pragma and then there could be an applications menu that listed them all in a convenient menu. Tim Sent from my iPhone > On 13 Dec 2018, at 08:38, nanqueti <nicolas.anquetil(a)inria.fr> wrote: > > > we could also use the "script:" annotation, and the system browser > could show it at the class level (it already shows at the method level) > > nicolas > >> On Thu, 2018-12-13 at 10:40 +0800, Ben Coman wrote: >> A question was asked on discord... "I know how to start the lights >> out example, >> and feed my objects test data with the testing framework, but how >> does one start >> something like ChineseCheckers? How does one find the entry point? >> Is there a convention on naming a starting place?" >> >> I remember having similar thoughts when starting in Pharo. >> >> One convention I have seen is that amongst all the classes presumably >> prefixed "CC" >> one class would stand out being named for the application without the >> prefix. >> e.g. class "ChineseCheckers". That is only a narrow chance for a >> namespace conflict, >> the the risk still remains. >> >> I suggested another path would have a package tag "Application" >> (i.e. "ChineseCheckers-Application") that contains a single class >> which has an #open method on the class-side. >> The tag "Application" sorts high up on the package-tags and is self- >> descriptive. >> But I've not seen that used before, so while I think its a good idea, >> its not really a convention. >> Conventions are only useful if they are broadly understood. >> >> So I'm wondering what other things people do to draw attention to >> their application entry points. >> >> cheers -ben > -- > Nicolas Anquetil > RMod team -- Inria Lille > >

Dec. 13, 2018

Problem loading a branch of my pharo fork in an image

by Thomas Dupriez

Hello, I loaded a branch of my pharo fork in an image using iceberg, but the method I was interested in did not change for some reason (my branch's latest commit changes this method, but these changes were not visible in the image I loaded my branch in). Does someone has an idea of what could have happened? Did I do something wrong? Here's what I did step-by-step if that helps: - fresh pharo 7 image - open iceberg - repair repository "pharo" - Clicked "Clone again this repository" - Chose "Clone remote repository", and put the url of my pharo fork: "https://github.com/dupriezt/pharo" - ok - wait for loading bar to complete - pharo repo is marked as "Fetch required. Unknown 67dc1e8" - repair repository "pharo" - chose "Discard local changes and checkout an existing branch" - chose the branch "BreakpointBrowser" from the "origin" remote - Clicked "checkout" on the checkout preview window - wait for loading bar to complete - browse the method WorldState class>>debugOn: - It is different from the last commit I made to this branch (https://github.com/dupriezt/pharo/commit/ead94e32f138eb435a95cd889f77ca39d4…) Thomas Dupriez

Dec. 13, 2018

â¹Programmingâº 2019 Combined Call for Workshop Submissions

by Fabio Niephaus

=========================================================================== â¹Programmingâº 2019 Combined Call for Workshop Submissions =========================================================================== To build a community and to foster an environment where participants can exchange ideas and experiences related to practical software development, â¹Programmingâº will host a number of workshops, during the days before the main conference. The workshops will provide a collaborative forum to exchange recent and/or preliminary results, to conduct intensive discussions on a particular topic, or to coordinate efforts between representatives of a technical community. They are intended as a forum for lively discussion of innovative ideas, recent progress, or practical experience on programming and applied software development in general for specific aspects, specific problems, or domain-specific needs. We also encourage practical, hands-on workshops in which participants actually experience one or several aspects of practical software development. The following workshops are co-located with â¹Programmingâº 2019. MoreVMsâ19: Workshop on Modern Language Runtimes, Ecosystems, and VMs --------------------------------------------------------------------------- MoreVMsâ19 aims to bring together industrial and academic programmers to discuss the design, implementation, and usage of modern languages and runtimes. Possible topics include reuse of language runtimes, modular implementation, language design, and compilation strategies. Call: https://2019.programming-conference.org/track/MoreVMs-2019 Extended Abstract Deadline: 11 Jan 2019 PX/19 5th Edition of the Programming Experience Workshop --------------------------------------------------------------------------- The Programming Experience (PX) Workshop is about what happens in that room when programmers sit down in front of computers and produce code, especially in an exploratory way. We are interested in this experience of programming and how to improve and evolve it. Call: https://2019.programming-conference.org/track/px-2019-papers Submission Deadline: 27 Jan 2019 VPT 2019: Seventh International Workshop on Program Transformation and Verification --------------------------------------------------------------------------- The aim of the workshop is to bring together researchers working in the fields of Program Verification and Program Transformation. There is a great potential for beneficial interactions between these two area. The workshop will provide a forum where researchers from these fields may interact and foster new developments. The workshop solicits research, position, application, and system description papers with a special emphasis on case studies, demonstrating viability of the interactions between the research fields of program transformation and program verification in a broad sense. Call: http://refal.botik.ru/vpt/vpt2019/ Submission Deadline: 8 Jan 2019 LANGETIâ19: Languages and Tools for Next Generation Testing --------------------------------------------------------------------------- The LANGETI workshop invites for submission of research papers and tool demonstrations developing new languages and tools that explore novel techniques to test next generation applications. We specially encourage new ideas on testing and its application domain that will spark discussion during the workshop. Call: https://2019.programming-conference.org/track/langeti-2019-papers Submission Deadline: 11 Jan 2019 PASSâ19: Workshop on Programming Across the System Stack (PASS) â19 --------------------------------------------------------------------------- PASSâ19 seeks contributions at the interaction of programming languages and computer systems, such as programming abstractions for emerging platforms, runtime performance and energy optimization, software tool support for systems, systems-level reasoning and verification, language-based security, and systems programming and debugging. Call: https://2019.programming-conference.org/home/PASS-2019 Submission Deadline: 15 Jan 2019 ICW 2019: Interconnecting Code Workshop --------------------------------------------------------------------------- Modern computer systems are often loosely coupled compositions of heterogeneous components. An important part of modern programming is the art, science, and engineering of interconnecting disparate code components to offer larger services in a reliable and scalable manner. The goal of this workshop is to facilitate an ongoing discussion, and advance the state of the art of interconnecting code. Call: https://2019.programming-conference.org/track/icw-2019-papers Initial Abstract Deadline: 11 Jan 2019 Salon des RefusÃ©s 2019 --------------------------------------------------------------------------- Salon des RefusÃ©s was an 1863 exhibition of artworks rejected from the official Paris Salon. We bring the same to programming research, creating a space for interesting ideas that are difficult to reduce to a proof or a naive measurement. Call: https://shift-society.org/salon/call-for-papers Submission Deadline: 7 Jan 2019 MiniPLoP 2019 --------------------------------------------------------------------------- Patterns are a systematic way to capture the experience of experts about good designs or best practices and document these nuggets of wisdom in an accessible way for peers. You can submit papers with 2-3 patterns for a discussion in a Writerâs Workshop session. Call: https://2019.programming-conference.org/track/PLOP-2019-papers Submission Deadline: 31 Jan 2019 ProWebâ19: 3rd International Workshop on Programming Technology for the Future Web --------------------------------------------------------------------------- ProWebâ19 is a forum for researchers and practitioners to share and discuss advances in programming technology (i.e., frameworks, libraries, programming languages, program analyses and development tools) for implementing web applications and for maintaining their quality over time, as well as experience reports about the use of state-of-the-art technology for the web. Call: https://2019.programming-conference.org/track/proweb-2019-papers Submission Deadline: 15 Jan 2019

Dec. 13, 2018

[Pharo 7.0] Build #36: 22762 Cleanup TextEditorTest

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

There is a new Pharo build available! The status of the build #36 was: FAILURE. The Pull Request #2066 was integrated: "22762 Cleanup TextEditorTest" Pull request url: https://github.com/pharo-project/pharo/pull/2066 Issue Url: https://pharo.fogbugz.com/f/cases/22762 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 13, 2018

Re: [Pharo-dev] Pharo image don't restart

by Christophe Demarey

Hi, The problem seems to come from: "no room in eden for allocateSmallNewSpaceSlots:format:classIndex:" Eden is a part of the heap where new objects are allocated. Basically, it appears that Pharo cannot create objects any more. You can get information about gc and eden space here: https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-colle… <https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-colle…> Could you try to run your image in headless mode to see if it starts? ex: I would try to start your image with a bigger size for the eden. ClÃ©ment recommends to do: Smalltalk vm parameterAt: 45 put: (Smalltalk vm parameterAt: 44) * 4. but it means you need an image that is started â¦ You can also set it as an argument to the VM: --eden <size>[mk] You could try with âeden 15207744 for example: ~/Documents/Pharo/vms/70-x64/Pharo.app/Contents/MacOS/Pharo --eden 15207744 ~/Documents/Pharo/images/Pharo\ 7.0\ -\ 64bit\ $development\ version$/Pharo\ 7.0\ -\ 64bit\ $development\ version$.image Regards, Christophe > Le 13 dÃ©c. 2018 Ã 09:25, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> a Ã©crit : > > Ciao, > > i have a Ubuntu system > where i defined a Pharo 7.0 - 64bit image managed with PharoLauncher. > > I work with it for a month and all work fine. > > Now after a save the image the system begin unstabled. > > When the mouse go on the windows summary bar ( at the bottom of the Pharo window ) the image go down. > > The first time i can launch the same image from the PharoLauncher, > > but after a new image save ( the image go down ) i can't relaunch the image. > > When i do the launch the pharoLauch shell report: > > <errorePharo.txt> > > I have some important work in the image ( and i don't have a backup ) > > Some consideration? > > Thanks, > Dario >

Dec. 13, 2018

[Pharo 7.0] Build #35: 22763 Tag classes in Text-Diff package

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

There is a new Pharo build available! The status of the build #35 was: SUCCESS. The Pull Request #2067 was integrated: "22763 Tag classes in Text-Diff package" Pull request url: https://github.com/pharo-project/pharo/pull/2067 Issue Url: https://pharo.fogbugz.com/f/cases/22763 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 13, 2018

Re: [Pharo-dev] Pharo image don't restart

by Trussardi Dario Romano

Ciao, > Ciao, >> You don't mention that you rebooted, so just try that first. > > sorry but I do not understand what you mean. > > In any case i rebooted the system. ( restart ) > > Yes, thats what I meant. Always the easiest thing to try. > > > The PharoLauncher launch command on the Pharo 7.0 -64development image report the same error. >> I have some important work in the image ( and i don't have a backup ) >> >> Some consideration? > > > I'm not in a position to diagnose the error, but perhaps help you recover your work. Can someone help me? It's very important.....!!! > In PharoLauncher, if you right-click on the image you are trying to launch, > then choose "Show in folder" then browse to "pharo-local/ombu-sessions" > and you should see some files. If you create a fresh image and copy those to the same location there, > the go World menu > Tools > Code Changes and see if you find your work. > Check out the filters. Possibly useful... > * Show only latest changes > * Show only changes in this package Thanks. OK, i see the methods ..... ( i need to understand what i can do with these ..... ) But in the image i have the data base with real data...... and ...... Stupidly I lost the version that started with the launcher, saving it on itself after it began to have problems...... Thanks, Dario

Dec. 13, 2018

Re: [Pharo-dev] periodic auto actions on bug tracker

by Marcus Denker

> On 13 Dec 2018, at 03:35, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Marcus Denker-4 wrote >>> I support the auto-closing of old tickets to avoid bug bankruptcy >> ... >> Yes, that is a good idea. > > I thought we already did that. Don't we even have a stale/timeout tag to > distinguish from other reasons for closing and help find them again later if > needed? > We close them with a timeout tag. But we do not send a public mail âhey, these tickets will be closed next weekâ. Only the *owner* gets a message on closing. Marcus

Dec. 13, 2018

Re: [Pharo-dev] Pharo image don't restart

by Ben Coman

On Thu, 13 Dec 2018 at 18:04, Trussardi Dario Romano < dario.trussardi(a)tiscali.it> wrote: > Ciao, > > You don't mention that you rebooted, so just try that first. > > > sorry but I do not understand what you mean. > > In any case i rebooted the system. ( restart ) > Yes, thats what I meant. Always the easiest thing to try. > > The PharoLauncher launch command on the Pharo 7.0 -64development image report > the same error. > > >> * I have some important work in the image ( and i don't have a backup ) >> Some consideration?* >> > I'm not in a position to diagnose the error, but perhaps help you recover your work. In PharoLauncher, if you right-click on the image you are trying to launch, then choose "Show in folder" then browse to "pharo-local/ombu-sessions" and you should see some files. If you create a fresh image and copy those to the same location there, the go World menu > Tools > Code Changes and see if you find your work. Check out the filters. Possibly useful... * Show only latest changes * Show only changes in this package HTH cheers -ben

Dec. 13, 2018

Re: [Pharo-dev] Pharo image don't restart

by Trussardi Dario Romano

Ciao, > You don't mention that you rebooted, so just try that first. sorry but I do not understand what you mean. In any case i rebooted the system. ( restart ) The PharoLauncher launch command on the Pharo 7.0 -64development image report the same error. Thanks, Dario > > cheers -ben > > P.S. Quick summary for others, the error is... > "no room in eden for allocateSmallNewSpaceSlots:format:classIndex:" > > Top of Smalltalk stack dump: > 0x7ffeec4c4a88 I ExternalSemaphoreTable class>unprotectedExternalObjects: 0x1d044b0: a(n) ExternalSemaphoreTable class > 0x7ffeec4c4ad0 I [] in ExternalSemaphoreTable class>clearExternalObjects 0x1d044b0: a(n) ExternalSemaphoreTable class > 0x7ffeec4c4b20 I [] in Semaphore>critical: 0x211ec80: a(n) Semaphore > 0x7ffeec4c4b70 I BlockClosure>ensure: 0x165e2d0: a(n) BlockClosure > 0x7ffeec4c4bc0 I Semaphore>critical: 0x211ec80: a(n) Semaphore > 0x7ffeec4c4c08 I ExternalSemaphoreTable class>clearExternalObjects 0x1d044b0: a(n) ExternalSemaphoreTable class > 0x7ffeec4c4c48 I SmalltalkImage>clearExternalObjects 0x1d0a920: a(n) SmalltalkImage > 0x7ffeec4c4c88 I WorkingSession>start: 0x165e000: a(n) WorkingSession > 0x7ffeec4c4ce0 I SessionManager>launchSnapshot:andQuit: 0x1d70a10: a(n) SessionManager > 0xbff6c50 s SessionManager>snapshot:andQuit: > 0xc006a18 s [] in SmalltalkImage>snapshot:andQuit: > > > > On Thu, 13 Dec 2018 at 16:26, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> wrote: > Ciao, > > i have a Ubuntu system > where i defined a Pharo 7.0 - 64bit image managed with PharoLauncher. > > I work with it for a month and all work fine. > > Now after a save the image the system begin unstabled. > > When the mouse go on the windows summary bar ( at the bottom of the Pharo window ) the image go down. > > The first time i can launch the same image from the PharoLauncher, > > but after a new image save ( the image go down ) i can't relaunch the image. > > When i do the launch the pharoLauch shell report: > > > I have some important work in the image ( and i don't have a backup ) > > Some consideration? > > Thanks, > Dario >

Dec. 13, 2018

Re: [Pharo-dev] Pharo image don't restart

by Ben Coman

You don't mention that you rebooted, so just try that first. cheers -ben P.S. Quick summary for others, the error is... "no room in eden for allocateSmallNewSpaceSlots:format:classIndex:" Top of Smalltalk stack dump: 0x7ffeec4c4a88 I ExternalSemaphoreTable class>unprotectedExternalObjects: 0x1d044b0: a(n) ExternalSemaphoreTable class 0x7ffeec4c4ad0 I [] in ExternalSemaphoreTable class>clearExternalObjects 0x1d044b0: a(n) ExternalSemaphoreTable class 0x7ffeec4c4b20 I [] in Semaphore>critical: 0x211ec80: a(n) Semaphore 0x7ffeec4c4b70 I BlockClosure>ensure: 0x165e2d0: a(n) BlockClosure 0x7ffeec4c4bc0 I Semaphore>critical: 0x211ec80: a(n) Semaphore 0x7ffeec4c4c08 I ExternalSemaphoreTable class>clearExternalObjects 0x1d044b0: a(n) ExternalSemaphoreTable class 0x7ffeec4c4c48 I SmalltalkImage>clearExternalObjects 0x1d0a920: a(n) SmalltalkImage 0x7ffeec4c4c88 I WorkingSession>start: 0x165e000: a(n) WorkingSession 0x7ffeec4c4ce0 I SessionManager>launchSnapshot:andQuit: 0x1d70a10: a(n) SessionManager 0xbff6c50 s SessionManager>snapshot:andQuit: 0xc006a18 s [] in SmalltalkImage>snapshot:andQuit: On Thu, 13 Dec 2018 at 16:26, Trussardi Dario Romano < dario.trussardi(a)tiscali.it> wrote: > > > > > > > > *Ciao, i have a Ubuntu system where i defined a Pharo 7.0 - 64bit image > managed with PharoLauncher. I work with it for a month and all work fine. > Now after a save the image the system begin unstabled. When the mouse go on > the windows summary bar ( at the bottom of the Pharo window ) the image go > down. The first time i can launch the same image from the PharoLauncher, > but after a new image save ( the image go down ) i can't relaunch the > image. When i do the launch the pharoLauch shell report:* > > > > > > > * I have some important work in the image ( and i don't have a backup ) > Some consideration? Thanks, Dario* >

Dec. 13, 2018

Re: [Pharo-dev] Application entrypoints

by nanqueti

we could also use the "script:" annotation, and the system browser could show it at the class level (it already shows at the method level) nicolas On Thu, 2018-12-13 at 10:40 +0800, Ben Coman wrote: > A question was asked on discord... "I know how to start the lights > out example, > and feed my objects test data with the testing framework, but how > does one start > something like ChineseCheckers? How does one find the entry point? > Is there a convention on naming a starting place?" > > I remember having similar thoughts when starting in Pharo. > > One convention I have seen is that amongst all the classes presumably > prefixed "CC" > one class would stand out being named for the application without the > prefix. > e.g. class "ChineseCheckers". That is only a narrow chance for a > namespace conflict, > the the risk still remains. > > I suggested another path would have a package tag "Application" > (i.e. "ChineseCheckers-Application") that contains a single class > which has an #open method on the class-side. > The tag "Application" sorts high up on the package-tags and is self- > descriptive. > But I've not seen that used before, so while I think its a good idea, > its not really a convention. > Conventions are only useful if they are broadly understood. > > So I'm wondering what other things people do to draw attention to > their application entry points. > > cheers -ben -- Nicolas Anquetil RMod team -- Inria Lille

Dec. 13, 2018

Pharo image don't restart

by Trussardi Dario Romano

Ciao, i have a Ubuntu system where i defined a Pharo 7.0 - 64bit image managed with PharoLauncher. I work with it for a month and all work fine. Now after a save the image the system begin unstabled. When the mouse go on the windows summary bar ( at the bottom of the Pharo window ) the image go down. The first time i can launch the same image from the PharoLauncher, but after a new image save ( the image go down ) i can't relaunch the image. When i do the launch the pharoLauch shell report: I have some important work in the image ( and i don't have a backup ) Some consideration? Thanks, Dario

Dec. 13, 2018

Application entrypoints

by Ben Coman

A question was asked on discord... "I know how to start the lights out example, and feed my objects test data with the testing framework, but how does one start something like ChineseCheckers? How does one find the entry point? Is there a convention on naming a starting place?" I remember having similar thoughts when starting in Pharo. One convention I have seen is that amongst all the classes presumably prefixed "CC" one class would stand out being named for the application without the prefix. e.g. class "ChineseCheckers". That is only a narrow chance for a namespace conflict, the the risk still remains. I suggested another path would have a package tag "Application" (i.e. "ChineseCheckers-Application") that contains a single class which has an #open method on the class-side. The tag "Application" sorts high up on the package-tags and is self-descriptive. But I've not seen that used before, so while I think its a good idea, its not really a convention. Conventions are only useful if they are broadly understood. So I'm wondering what other things people do to draw attention to their application entry points. cheers -ben

Dec. 13, 2018

Re: [Pharo-dev] periodic auto actions on bug tracker

by Sean P. DeNigris

Marcus Denker-4 wrote >> I support the auto-closing of old tickets to avoid bug bankruptcy > ... > Yes, that is a good idea. I thought we already did that. Don't we even have a stale/timeout tag to distinguish from other reasons for closing and help find them again later if needed? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 13, 2018

Re: [Pharo-users] [ANN] Pharo Newsletter December 2018

by Alexandre Bergel

Hi Marcus! Maybe a news about the first 6 chapters of Agile Artificial Intelligence. https://agileartificialintelligence.github.io/ Cheers Alexandre http://bergel.eu > Le 12 dÃ©c. 2018 Ã 05:17, Marcus Denker <marcus.denker(a)inria.fr> a Ã©crit : > > > >> On 11 Dec 2018, at 14:08, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Hi, >> >> Last we the Pharo Newsletter December 2018 was send. >> >> You can find the archived version now here: >> >> https://mailchi.mp/pharo/pharo-newsletter-december-2018 >> > > I am looking for content for the January newsletter. > > e.g. if you know a library that has not yet been listed, or just one where some new version has been released. > Or people could write âlargerâ articles (a paragraph or two) about their favourite things. > > Or maybe there are videos that would be nice to be added to the newsletter? > > Marcus

Dec. 13, 2018

Re: [Pharo-users] [ANN] Git Thermite integration with Iceberg

by Alexandre Bergel

It would be really great to have feedback. Please, providing feedback is key to enable innovation in this community! Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Dec 12, 2018, at 12:21 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > > Hello, > > Some time ago I presented Git Thermite in this mailing. Git Thermite is a tool for visualizing Git commits that I am making for my master thesis. Now I have managed to integrate Git Thermite with Iceberg. > > GitHub page: https://github.com/ronsaldo/pharo-git-thermite <https://github.com/ronsaldo/pharo-git-thermite> > Demo video: https://www.youtube.com/watch?v=TdBHpdyFgZE <https://www.youtube.com/watch?v=TdBHpdyFgZE> > Visualization learning material: https://github.com/ronsaldo/pharo-git-thermite/blob/master/doc/learning-mat… <https://github.com/ronsaldo/pharo-git-thermite/blob/master/doc/learning-mat…> > Feedback: https://docs.google.com/forms/d/e/1FAIpQLSeir6VlE3bR78oRsNAp9eHLkUn2Q016wEl… <https://docs.google.com/forms/d/e/1FAIpQLSeir6VlE3bR78oRsNAp9eHLkUn2Q016wEl…> > > Pharo 7 installation doIt: > > Metacello new > baseline: 'Thermite'; > repository: 'github://ronsaldo/pharo-git-thermite/src'; > load > Please, I would love to get some usage feedback through the Google form :-) > > Best regards, > Ronie

Dec. 12, 2018

[Pharo 7.0] Build #34: 22753-RBParseErrorNode-should-pretty-print-the-faulty-text-if-it-has-it

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

There is a new Pharo build available! The status of the build #34 was: SUCCESS. The Pull Request #2061 was integrated: "22753-RBParseErrorNode-should-pretty-print-the-faulty-text-if-it-has-it" Pull request url: https://github.com/pharo-project/pharo/pull/2061 Issue Url: https://pharo.fogbugz.com/f/cases/22753 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 12, 2018