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

Re: [Pharo-dev] Did the selection in Playground or rubric change?

by Tim Mackinnon

Actually I played around with all of that stuff and got it working well - but I got scared off with how to contribute with the new process etc. I can look again when the Xmas holidays kick in, and see if my small changes work in a 7.x image - I found that I could get the AST to work, but I had to add a little heuristic to it and if I found nothing and there was a selection then it worked the old way. Tim > On 12 Dec 2017, at 13:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Yes, I have it already on my list of things to fixâ¦ (not issue tracker entry yet, will add one). > > Marcus > >> On 12 Dec 2017, at 13:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> just type >> >> margins: Put the cursor here and press command + M or command + N >> in the past >> margins: was selected and used. >> >> What you see is that we cannot rely on the AST. >> Now selecting items is boring. >> >> Stef >> >> On Tue, Dec 12, 2017 at 1:47 PM, Pavel Krivanek >> <pavel.krivanek(a)gmail.com> wrote: >>> Hi, >>> >>> Andrew improved that so it now works on AST and provides better results. If >>> you have some code where it does not work, please try to describe the >>> particular case so we can fix it. >>> >>> -- Pavel >>> >>> 2017-12-12 13:31 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>>> >>>> Hi >>>> >>>> usually in previous version we could put the cursor on the line and >>>> get senders and implementors without having to select the code. >>>> Now this super cool features does not work anymore. >>>> >>>> Is it only my image? >>>> >>>> Stef >>>> >>> >> > >

Dec. 13, 2017

Re: [Pharo-dev] Epicea feedback - save points

by Ben Coman

Hi Stef, I think that is incorrect. Its easy to be certain... 1. Open Epicea 2. Save and continue 3. Open Epicea and observe there is no difference cheers -ben On 13 December 2017 at 17:59, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I think that epicea save point are the list elements on the left. > > > On Wed, Dec 13, 2017 at 9:05 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Same for me. I thought the last save point would be the last session in > the list but I donât think that is really true. So Iâm confused by Epicea, > too. > > > > Norbert > > > >> Am 13.12.2017 um 08:27 schrieb Ben Coman <btc(a)openinworld.com>: > >> > >> When I'm in need Epicea, the common scenario is that I've working in > the same session of an Image most of the day, or even days, and I've done > something stupid to lock up the UI, and its only been an hour since my last > save point (force of habit). When I review Epicea, "Filter > Show latest > changes" its still ahrd to determine which changes I'm missing. What I've > just realised is I miss the visibility of the Save Point in the old changes > system. I'd find it really useful for the save points to be show in the > changes list, and also a filter I'd find really useful is "Shows latest > changes since last save". > >> > >> > >> cheers -ben > > > >

Dec. 13, 2017

[Website] Updated Linux download instructions

by Marcus Denker

Hi, I have updated the download instruction with the infos from https://pharo.fogbugz.com/f/cases/20799/Update-Linux-Download-instructions Here are the two pages: https://pharo.org/gnu-linux-installation-64 https://pharo.org/gnu-linux-installation <https://pharo.org/gnu-linux-installation> for the 32 bit version I opted to list the package based installation first as the zip file is quite complex (requiring manual setup). TODO - add a pointe to get.pharo.org <http://get.pharo.org/> - add two to actually start Pharo for all cases. - Check https://pharo.fogbugz.com/f/cases/20147/ <https://pharo.fogbugz.com/f/cases/20147/> - Check if some linux infos from http://pharo.org/download <http://pharo.org/download> should not be better moved to the linux page. Marcus

Dec. 13, 2017

Re: [Pharo-dev] Moving from mc to tonel?

by stephan

On 05-12-17 08:59, Peter UhnÃ¡k wrote: > > In my case, it turned out to be a non-UTF8 encoded character in one > of the commit messages. > > I've ran into this problem in a sister project (tonel-migration), and do > not have a proper resolution yet. I was forcing everything to be > unicode, so I need a better way to read and write encoded strings. :< To be exact, exactly none of the older commits will be UTF8 encoded. For most it doesn't matter as they are ASCII, but if we want to have a change of converting older french or german code (or japanese), we need support for what was done with WideString. That probably needs a look in the squeak mailing list archives. Stephan

Dec. 13, 2017

Re: [Pharo-dev] spurious characters in class comments

by Stephane Ducasse

Yes I saw that too and this is probably an iceberg glitch or revealing a copy paste. On Wed, Dec 13, 2017 at 8:10 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > IMHO this would be the case if the sourde code is written in utf-8 but read > in latin1. > > Norbert > > Am 12.12.2017 um 23:41 schrieb Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com>: > > Take a look at Dictionary.class.st for example > > https://github.com/pharo-project/pharo/blob/bc8b9658958f4464189cf3e7fffd8c9… > > on line 10: > > IÃÆÃÆÃâÃâÃÆÃâÃâÃ am use when we need a collection of objects which I can > access with a key. For example if you associate some words with a > definition, the word will be the key and the definition will be the value. > Both of them can be any kind of objects. > > At each commit, the number of odd characters increases...

Dec. 13, 2017

Re: [Pharo-dev] odd behaviour dragging method between protocols

by Stephane Ducasse

Same here. It is a bug. Now I would like to deprecate Nautilus and use Calypso but but but we need to make sure that documentation is better and that we can have a spec based calypso because we do not want to rewrite everything again with bloc. stef On Wed, Dec 13, 2017 at 8:32 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > Happened to me too. > I think. I sometimes thought hey where is that method gone, couldn't > remember I deleted it. > > Am 13.12.2017 03:42 schrieb "Ben Coman" <btc(a)openinworld.com>: > > > I could just be having a brain freeze, but just sharing in case > anyone else is similarly going mad... > a few times recently in Nautilus I've dragged a method from the fourth pane > and dropped it on a protocol in the third pane and the method disappeared > from the system. Luckily its easily recovered from Tools > Code Changes, > where it shows as deleted. But its weird that a delete could be triggered > from the action I (thought I) performed. > > I've yet to detect a pattern. Unfortunately its kind of > blink-and-you-miss-it. > Its not until a second later when selecting the target protocol > that the behaviour becomes apparent. > > This is in 60527-64, Unix built on Jul 20 2017 20:40:36 Compiler: 4.6.3 > > cheers -ben > >

Dec. 13, 2017

Re: [Pharo-dev] Epicea feedback - save points

by Stephane Ducasse

I think that epicea save point are the list elements on the left. On Wed, Dec 13, 2017 at 9:05 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > Same for me. I thought the last save point would be the last session in the list but I donât think that is really true. So Iâm confused by Epicea, too. > > Norbert > >> Am 13.12.2017 um 08:27 schrieb Ben Coman <btc(a)openinworld.com>: >> >> When I'm in need Epicea, the common scenario is that I've working in the same session of an Image most of the day, or even days, and I've done something stupid to lock up the UI, and its only been an hour since my last save point (force of habit). When I review Epicea, "Filter > Show latest changes" its still ahrd to determine which changes I'm missing. What I've just realised is I miss the visibility of the Save Point in the old changes system. I'd find it really useful for the save points to be show in the changes list, and also a filter I'd find really useful is "Shows latest changes since last save". >> >> >> cheers -ben >

Dec. 13, 2017

About a shared trello board

by Stephane Ducasse

Hi I'm thinking that we are not good at communicating and coordinating effort I would like start a (read only) and welcome contributions on demand trello board so that we know each others on what parts of pharo we are currently working and what are the next steps. Does it make sense for you guys? Stef

Dec. 13, 2017

Re: [Pharo-dev] Epicea feedback - save points

by Norbert Hartl

Same for me. I thought the last save point would be the last session in the list but I donât think that is really true. So Iâm confused by Epicea, too. Norbert > Am 13.12.2017 um 08:27 schrieb Ben Coman <btc(a)openinworld.com>: > > When I'm in need Epicea, the common scenario is that I've working in the same session of an Image most of the day, or even days, and I've done something stupid to lock up the UI, and its only been an hour since my last save point (force of habit). When I review Epicea, "Filter > Show latest changes" its still ahrd to determine which changes I'm missing. What I've just realised is I miss the visibility of the Save Point in the old changes system. I'd find it really useful for the save points to be show in the changes list, and also a filter I'd find really useful is "Shows latest changes since last save". > > > cheers -ben

Dec. 13, 2017

Re: [Pharo-dev] odd behaviour dragging method between protocols

by Nicolai Hess

Happened to me too. I think. I sometimes thought hey where is that method gone, couldn't remember I deleted it. Am 13.12.2017 03:42 schrieb "Ben Coman" <btc(a)openinworld.com>: I could just be having a brain freeze, but just sharing in case anyone else is similarly going mad... a few times recently in Nautilus I've dragged a method from the fourth pane and dropped it on a protocol in the third pane and the method disappeared from the system. Luckily its easily recovered from Tools > Code Changes, where it shows as deleted. But its weird that a delete could be triggered from the action I (thought I) performed. I've yet to detect a pattern. Unfortunately its kind of blink-and-you-miss-it. Its not until a second later when selecting the target protocol that the behaviour becomes apparent. This is in 60527-64, Unix built on Jul 20 2017 20:40:36 Compiler: 4.6.3 cheers -ben

Dec. 13, 2017

Epicea feedback - save points

by Ben Coman

When I'm in need Epicea, the common scenario is that I've working in the same session of an Image most of the day, or even days, and I've done something stupid to lock up the UI, and its only been an hour since my last save point (force of habit). When I review Epicea, "Filter > Show latest changes" its still ahrd to determine which changes I'm missing. What I've just realised is I miss the visibility of the Save Point in the old changes system. I'd find it really useful for the save points to be show in the changes list, and also a filter I'd find really useful is "Shows latest changes since last save". cheers -ben

Dec. 13, 2017

Re: [Pharo-dev] spurious characters in class comments

by Norbert Hartl

IMHO this would be the case if the sourde code is written in utf-8 but read in latin1. Norbert > Am 12.12.2017 um 23:41 schrieb Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > > Take a look at Dictionary.class.st for example > > https://github.com/pharo-project/pharo/blob/bc8b9658958f4464189cf3e7fffd8c9… > > on line 10: > > IÃÆÃÆÃâÃâÃÆÃâÃâÃ am use when we need a collection of objects which I can access with a key. For example if you associate some words with a definition, the word will be the key and the definition will be the value. Both of them can be any kind of objects. > > At each commit, the number of odd characters increases...

Dec. 13, 2017

odd behaviour dragging method between protocols

by Ben Coman

I could just be having a brain freeze, but just sharing in case anyone else is similarly going mad... a few times recently in Nautilus I've dragged a method from the fourth pane and dropped it on a protocol in the third pane and the method disappeared from the system. Luckily its easily recovered from Tools > Code Changes, where it shows as deleted. But its weird that a delete could be triggered from the action I (thought I) performed. I've yet to detect a pattern. Unfortunately its kind of blink-and-you-miss-it. Its not until a second later when selecting the target protocol that the behaviour becomes apparent. This is in 60527-64, Unix built on Jul 20 2017 20:40:36 Compiler: 4.6.3 cheers -ben

Dec. 13, 2017

spurious characters in class comments

by Nicolas Cellier

Take a look at Dictionary.class.st for example https://github.com/pharo-project/pharo/blob/bc8b9658958f4464189cf3e7fffd8c9… on line 10: IÃÆÃÆÃâÃâÃÆÃâÃâÃ am use when we need a collection of objects which I can access with a key. For example if you associate some words with a definition, the word will be the key and the definition will be the value. Both of them can be any kind of objects. At each commit, the number of odd characters increases...

Dec. 12, 2017

[Pharo 7.0-dev] Build #378: 20866-revert-retryTimes-parameter-on-CI

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

There is a new Pharo build available! The status of the build #378 was: SUCCESS. The Pull Request #600 was integrated: "20866-revert-retryTimes-parameter-on-CI" Pull request url: https://github.com/pharo-project/pharo/pull/600 Issue Url: https://pharo.fogbugz.com/f/cases/20866 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Todd Blanchard

I'm kind of trying to figure out when I'd want that operation. groupsWithSeparatorsWhereSeparatatorsMatch: feels like it says what it does > On Dec 12, 2017, at 10:19 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > > On 12 December 2017 at 20:03, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: > > > 2017-12-12 13:01 GMT+01:00 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>>: > Ben Coman wrote > > > > But after pondering a while for a better name, I wonder what is wrong with > > the existing? > > Googling "define aggregate" provides... > > aggregate (noun) = a whole formed by combining several separate > > elements. > > aggregate (verb) = form or group into a class or cluster. > > > > The separate elements are runs defined by the block. > > The existing name seems quite precise to me. > > > > cheers -ben > > When I read aggregateRuns:, I think the opposite; something combining > different runs into a single entity, not something that splits a single > collection into constituent runs... > > okay. I can understand that perspective. > > > Something like (split/collect)runsAccordingTo: sounds more descriptive to my > ears, at least. > > Cheers, > Henry > > > > I like groupBy: but in Squeak groupBy: produces a dictionary with unique keys ignoring the multiple sequences... > split already carries the meaning of preserving the sequences, but we have to tell to split at a change of value.... > Run is also quite explicit... > > groupByRuns: / splitRuns: > > +1 > groupByRuns: is good. > > cheers -ben

Dec. 12, 2017

Re: [Pharo-dev] Does pharo build not retry anymore?

by Pavel Krivanek

The variable value was reverted to the original value. Thanks. -- Pavel 2017-12-12 20:13 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Yes, with Marcus we decreased the retryTimes variable two weeks ago to 1 > because in that time the validations were in really bad shape and literally > every validation failed on some random issue and the retries caused > enormous build times. It was producing more troubles than profit. It > probably can be reverted now because the main problem of the validation > instability was suppressed. I will prepare a PR. > > -- Pavel > > 2017-12-12 18:52 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> I see that we are retrying tests only once, which is causing most (if not >> all) pull requests to fail sporadically... >> >> Maybe it got lost because of a mistake? >> >> Also, I'd like that changes in the build process are discussed in the >> mailing list from time to time... I've put a lot of effort into making it >> work and if we have regressions I'd like to understand them... >> >> Guille >> >> -- >> >> >> >> 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 <+33%206%2052%2070%2066%2013> >> > >

Dec. 12, 2017

Re: [Pharo-dev] I love the launcher!!!!

by Alexandre Bergel

Your email made me try Pharo Launcher. I love it too! It replaces all my scripts to download the VM and the last images. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Nov 23, 2017, at 5:51 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi > > I love the PharoLauncher. > It helps me to manage my parallel development and projects. > > We should put a link on the Pharo web site because > > http://files.pharo.org/platform/launcher/ > > is arcane. > > Stef >

Dec. 12, 2017

Re: [Pharo-dev] Does pharo build not retry anymore?

by Pavel Krivanek

Yes, with Marcus we decreased the retryTimes variable two weeks ago to 1 because in that time the validations were in really bad shape and literally every validation failed on some random issue and the retries caused enormous build times. It was producing more troubles than profit. It probably can be reverted now because the main problem of the validation instability was suppressed. I will prepare a PR. -- Pavel 2017-12-12 18:52 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > I see that we are retrying tests only once, which is causing most (if not > all) pull requests to fail sporadically... > > Maybe it got lost because of a mistake? > > Also, I'd like that changes in the build process are discussed in the > mailing list from time to time... I've put a lot of effort into making it > work and if we have regressions I'd like to understand them... > > Guille > > -- > > > > 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 <+33%206%2052%2070%2066%2013> >

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Ben Coman

On 12 December 2017 at 20:03, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2017-12-12 13:01 GMT+01:00 Henrik Sperre Johansen < > henrik.s.johansen(a)veloxit.no>: > >> Ben Coman wrote >> > >> > But after pondering a while for a better name, I wonder what is wrong >> with >> > the existing? >> > Googling "define aggregate" provides... >> > aggregate (noun) = a whole formed by combining several separate >> > elements. >> > aggregate (verb) = form or group into a class or cluster. >> > >> > The separate elements are runs defined by the block. >> > The existing name seems quite precise to me. >> > >> > cheers -ben >> >> When I read aggregateRuns:, I think the opposite; something combining >> different runs into a single entity, not something that splits a single >> collection into constituent runs... >> > okay. I can understand that perspective. > >> Something like (split/collect)runsAccordingTo: sounds more descriptive >> to my >> ears, at least. >> >> Cheers, >> Henry >> >> >> > I like groupBy: but in Squeak groupBy: produces a dictionary with unique > keys ignoring the multiple sequences... > split already carries the meaning of preserving the sequences, but we have > to tell to split at a change of value.... > Run is also quite explicit... > > groupByRuns: / splitRuns: > +1 groupByRuns: is good. cheers -ben

Dec. 12, 2017

Does pharo build not retry anymore?

by Guillermo Polito

I see that we are retrying tests only once, which is causing most (if not all) pull requests to fail sporadically... Maybe it got lost because of a mistake? Also, I'd like that changes in the build process are discussed in the mailing list from time to time... I've put a lot of effort into making it work and if we have regressions I'd like to understand them... Guille -- 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. 12, 2017

Re: [Pharo-dev] Linux vm packages

by Marcus Denker

> On 12 Dec 2017, at 17:32, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > On Tue, Dec 12, 2017 at 5:15 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> I have added the information to the 64bit download page for now (the other >> comes next). >> >> http://pharo.org/web/gnu-linux-installation-64 >> >> I wonder if we continue to announce a âdefault downloadâ (the zip) if it is >> much easier to use these? >> > > I am just wondering, > > What if I use zero conf to get my 32bits vm? > > Will I be able to follow the instructions of the page, then dl and use > a vm via zero conf without installing extra dependencies? > That is the problem: you need to install all the 32bit libraries first. Same for running what is now called the âdefault downloadâ 32 bit on current Linux. This makes is quite hard to explainâ¦ Marcus

Dec. 12, 2017

Re: [Pharo-dev] Linux vm packages

by Cyril Ferlicot

On Tue, Dec 12, 2017 at 5:15 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > I have added the information to the 64bit download page for now (the other > comes next). > > http://pharo.org/web/gnu-linux-installation-64 > > I wonder if we continue to announce a âdefault downloadâ (the zip) if it is > much easier to use these? > I am just wondering, What if I use zero conf to get my 32bits vm? Will I be able to follow the instructions of the page, then dl and use a vm via zero conf without installing extra dependencies? -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Dec. 12, 2017

Re: [Pharo-dev] Linux vm packages

by Marcus Denker

I have added the information to the 64bit download page for now (the other comes next). http://pharo.org/web/gnu-linux-installation-64 <http://pharo.org/web/gnu-linux-installation-64> I wonder if we continue to announce a âdefault downloadâ (the zip) if it is much easier to use these? > On 27 Nov 2017, at 09:22, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > I can edit the website, I can put al needed infos there. > > (but sometimes I am not be able to generate actions out of discussions on the mailing list, > there is just so much going onâ¦ so if something does not happen this just means I do > not know that it should happenâ¦) > >> On 26 Nov 2017, at 13:52, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >> >> Can we change linux installation instructions on the web site? I can't believe they aren't there, yet. Here is the description. >> >> http://forum.world.st/Latest-Debian-Ubuntu-and-CentOS-packages-of-the-pharo… <http://forum.world.st/Latest-Debian-Ubuntu-and-CentOS-packages-of-the-pharo…> >> >> This describes what to do for some linux distributions not only ubuntu. In the mail there are opensuse URLs. The all contain the word "latest" which means the development version. If this is exchanged with "stable" you get the stable version. The rest stays the same. >> >> I really should have checked this. Because it is just stupid that people spend a lot of work into that and it is not used nor published. >> >> If I can help please say so!!!! >> >> Norbert >> >

Dec. 12, 2017

Re: [Pharo-dev] Do we have this iterator?

by Martin Dias

If your input was a string instead of a list of lines, you had: '[^4]*4|.+' asRegex matchesIn: '1234123123456' >>> "an OrderedCollection('1234' '1231234' '56')" MartÃn On Tue, Dec 12, 2017 at 9:33 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Thanks sean. > I will build it because for example I had list of lines and I needed > to split the input depending > on patterns inside the lines.... and sadly this was not for an advent of > code. > > Rmoders suggested > aggregateRuns: > splitOn: > but this is not the same. > > > Stef > > On Tue, Dec 12, 2017 at 2:33 AM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > Stephane Ducasse-3 wrote > >> #(1 2 3 4 1 2 3 5 6 ) consumeUntil: [:each | each = 4) > >>>>> {#(1 2 3 4) . #( 1 2 3 5 6 )} > > > > The shortest kernel thing I could come up with took two steps: `{ #(1 2 > 3 4 > > 1 2 3 5 6 ) copyUpThrough: 4. > > #(1 2 3 4 1 2 3 5 6 ) copyAfter: 4 }`. The splitting messages seem to all > > eat the separator. > > > > > > > > ----- > > Cheers, > > Sean > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837. > html > > > >

Dec. 12, 2017

[Pharo 7.0-dev] Build #377: 20773 - Unused temps in BlockClosure value, value:, value:value:, ...

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

There is a new Pharo build available! The status of the build #377 was: SUCCESS. The Pull Request #558 was integrated: "20773 - Unused temps in BlockClosure value, value:, value:value:, ..." Pull request url: https://github.com/pharo-project/pharo/pull/558 Issue Url: https://pharo.fogbugz.com/f/cases/20773 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 12, 2017

[Pharo 7.0-dev] Build #376: 20860-Cursor-webLink-is-initialized-wrongly-and-transparent

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

There is a new Pharo build available! The status of the build #376 was: FAILURE. The Pull Request #598 was integrated: "20860-Cursor-webLink-is-initialized-wrongly-and-transparent" Pull request url: https://github.com/pharo-project/pharo/pull/598 Issue Url: https://pharo.fogbugz.com/f/cases/20860 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Cyril Ferlicot

On Tue, Dec 12, 2017 at 10:23 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > do you have some proposals for a better name for the message named > #aggregateRuns? > > (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns: [ :each | each = 4]) > >>> #(#(1 2 3) #(4) #(1 2 3 5 6)). > > (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns: [ :each | each = 4]) > >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). > > ((1 to: 12) aggregateRuns: [ :each | (each \\ 3) = 0]) > >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). > > The current comment is: > "Answer a new collection of the same species as the > receiver with elements being collections (of the receiver > species) containing those elements of the receiver > for which the given block consecutively evaluates to > the same object." > > https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollect… > > Cheers, > -- Pavel divideOn:? -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Dec. 12, 2017

Re: [Pharo-dev] [Pharo-users] [TechTalk] Topics Wanted for 2018!

by Marcus Denker

Ok! Pharo TechTalk: Genetic Algorithms https://association.pharo.org/event-2757884 > On 11 Dec 2017, at 21:56, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Yes! > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Dec 7, 2017, at 10:53 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> What about Tuesday 30th Jan? >> >>> On 7 Dec 2017, at 02:06, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> >>> Hi Marcus! >>> >>> Thanks for pushing the community! >>> If there is a free slot at the end of January, I can do another tech talk on AI technique. I am thinking about a lecture on Genetic Algorithm and Genetic Programming. >>> >>> Let me know... >>> >>> Alexandre >>> >>> >>>> On Dec 1, 2017, at 7:58 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>>> >>>> Hi, >>>> >>>> As you know, we are trying to have one Pharo tech-talk per month. >>>> >>>> The idea is to use this for >>>> -> mini âLecturesâ >>>> -> Demos of interesting Projects >>>> -> Just some interesting topic to discuss with audio chat on Discord >>>> >>>> You can see the past topics here: >>>> >>>> http://pharo.org/TechTalk >>>> >>>> We will soon define the dates for the first half of 2018. If you want to do a techtalk >>>> yourself (give a presentation / Demo or moderate a discussion), feel free to contact >>>> me! You are able to pick a date that works best for you. >>>> >>>> >>>> Marcus >>> >>> >> >> >

Dec. 12, 2017

Re: [Pharo-dev] Did the selection in Playground or rubric change?

by Marcus Denker

Yes, I have it already on my list of things to fixâ¦ (not issue tracker entry yet, will add one). Marcus > On 12 Dec 2017, at 13:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > just type > > margins: Put the cursor here and press command + M or command + N > in the past > margins: was selected and used. > > What you see is that we cannot rely on the AST. > Now selecting items is boring. > > Stef > > On Tue, Dec 12, 2017 at 1:47 PM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: >> Hi, >> >> Andrew improved that so it now works on AST and provides better results. If >> you have some code where it does not work, please try to describe the >> particular case so we can fix it. >> >> -- Pavel >> >> 2017-12-12 13:31 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>> >>> Hi >>> >>> usually in previous version we could put the cursor on the line and >>> get senders and implementors without having to select the code. >>> Now this super cool features does not work anymore. >>> >>> Is it only my image? >>> >>> Stef >>> >> >

Dec. 12, 2017

Re: [Pharo-dev] How do you merge branches using Iceberg?

by Esteban Lorenzano

> On 12 Dec 2017, at 14:03, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > mmmmm ok. And let me ask (I don't have another example at hand now to test) ... with metacello integration enabled, would that ALSO reload the packages from git into my image? no > or it would only do the git-side of the merge ? yes > > Thanks in advance, > > On Tue, Dec 12, 2017 at 9:47 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > is not very clear, but you can use the history window for that (yeah, it needs to be better, etc., etc.) > > Esteban > > >> On 12 Dec 2017, at 13:32, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: >> >> Let's say I have xxx and then I created branch xxx-mariano. Every in a while, I want to merge latest xxx into my xxx-mariano. I haven't found a way to do this in Iceberg (I am using 0.6.2 on Pharo 6.1). I had to go to console, do the git merge there and then from Iceberg I had to "reload all packages". >> >> Is there a better way of doing this? >> >> Thanks, >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/> > > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Dec. 12, 2017

Re: [Pharo-dev] Did the selection in Playground or rubric change?

by Pavel Krivanek

We probably should use a fallback with the old behavior. -- Pavel 2017-12-12 13:52 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > just type > > margins: Put the cursor here and press command + M or command + N > in the past > margins: was selected and used. > > What you see is that we cannot rely on the AST. > Now selecting items is boring. > > Stef > > On Tue, Dec 12, 2017 at 1:47 PM, Pavel Krivanek > <pavel.krivanek(a)gmail.com> wrote: > > Hi, > > > > Andrew improved that so it now works on AST and provides better results. > If > > you have some code where it does not work, please try to describe the > > particular case so we can fix it. > > > > -- Pavel > > > > 2017-12-12 13:31 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> > >> Hi > >> > >> usually in previous version we could put the cursor on the line and > >> get senders and implementors without having to select the code. > >> Now this super cool features does not work anymore. > >> > >> Is it only my image? > >> > >> Stef > >> > > > >

Dec. 12, 2017

Re: [Pharo-dev] How do you merge branches using Iceberg?

by Mariano Martinez Peck

mmmmm ok. And let me ask (I don't have another example at hand now to test) ... with metacello integration enabled, would that ALSO reload the packages from git into my image? or it would only do the git-side of the merge ? Thanks in advance, On Tue, Dec 12, 2017 at 9:47 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > is not very clear, but you can use the history window for that (yeah, it > needs to be better, etc., etc.) > > Esteban > > > On 12 Dec 2017, at 13:32, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > Let's say I have xxx and then I created branch xxx-mariano. Every in a > while, I want to merge latest xxx into my xxx-mariano. I haven't found a > way to do this in Iceberg (I am using 0.6.2 on Pharo 6.1). I had to go to > console, do the git merge there and then from Iceberg I had to "reload all > packages". > > Is there a better way of doing this? > > Thanks, > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Dec. 12, 2017

Re: [Pharo-dev] Did the selection in Playground or rubric change?

by Stephane Ducasse

just type margins: Put the cursor here and press command + M or command + N in the past margins: was selected and used. What you see is that we cannot rely on the AST. Now selecting items is boring. Stef On Tue, Dec 12, 2017 at 1:47 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > Andrew improved that so it now works on AST and provides better results. If > you have some code where it does not work, please try to describe the > particular case so we can fix it. > > -- Pavel > > 2017-12-12 13:31 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> Hi >> >> usually in previous version we could put the cursor on the line and >> get senders and implementors without having to select the code. >> Now this super cool features does not work anymore. >> >> Is it only my image? >> >> Stef >> >

Dec. 12, 2017

Re: [Pharo-dev] [Ann] New Calypso version 0.8

by Denis Kudriashov

2017-12-12 13:25 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi Denis, > > Congratulations on the new release! Two quick question: > > 1) does this work on latest Pharo 6.1 ; > Yes > 2) Is it safe to update images with Calypso already installed by doing the > same baseline loading as the original installation ? > I think not. But I not try. I just have impression that complex updates are not properly work in Pharo. All package structure is changed and it can be a problem for such update. > > Thanks > > On Tue, Dec 12, 2017 at 9:05 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> Hello. >> >> I glad announce new Calypso version. It is a big refactoring on >> navigation model and browser pluggability. >> >> Look for details in my blog http://dionisiydk.blogspot.fr/ >> 2017/12/new-calypso-version-08-is-out.html. >> >> Now I start document new design and will post progress on it. >> >> Notice: this version is not adopted for TelePharo and Cargo. It will be >> done soon. >> >> Best regards, >> Denis >> > > > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 12, 2017

Re: [Pharo-dev] Did the selection in Playground or rubric change?

by Pavel Krivanek

Hi, Andrew improved that so it now works on AST and provides better results. If you have some code where it does not work, please try to describe the particular case so we can fix it. -- Pavel 2017-12-12 13:31 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi > > usually in previous version we could put the cursor on the line and > get senders and implementors without having to select the code. > Now this super cool features does not work anymore. > > Is it only my image? > > Stef > >

Dec. 12, 2017

Re: [Pharo-dev] How do you merge branches using Iceberg?

by Esteban Lorenzano

is not very clear, but you can use the history window for that (yeah, it needs to be better, etc., etc.) Esteban > On 12 Dec 2017, at 13:32, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > Let's say I have xxx and then I created branch xxx-mariano. Every in a while, I want to merge latest xxx into my xxx-mariano. I haven't found a way to do this in Iceberg (I am using 0.6.2 on Pharo 6.1). I had to go to console, do the git merge there and then from Iceberg I had to "reload all packages". > > Is there a better way of doing this? > > Thanks, > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Dec. 12, 2017

Re: [Pharo-dev] Do we have this iterator?

by Stephane Ducasse

Thanks sean. I will build it because for example I had list of lines and I needed to split the input depending on patterns inside the lines.... and sadly this was not for an advent of code. Rmoders suggested aggregateRuns: splitOn: but this is not the same. Stef On Tue, Dec 12, 2017 at 2:33 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Stephane Ducasse-3 wrote >> #(1 2 3 4 1 2 3 5 6 ) consumeUntil: [:each | each = 4) >>>>> {#(1 2 3 4) . #( 1 2 3 5 6 )} > > The shortest kernel thing I could come up with took two steps: `{ #(1 2 3 4 > 1 2 3 5 6 ) copyUpThrough: 4. > #(1 2 3 4 1 2 3 5 6 ) copyAfter: 4 }`. The splitting messages seem to all > eat the separator. > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Dec. 12, 2017

How do you merge branches using Iceberg?

by Mariano Martinez Peck

Let's say I have xxx and then I created branch xxx-mariano. Every in a while, I want to merge latest xxx into my xxx-mariano. I haven't found a way to do this in Iceberg (I am using 0.6.2 on Pharo 6.1). I had to go to console, do the git merge there and then from Iceberg I had to "reload all packages". Is there a better way of doing this? Thanks, -- Mariano http://marianopeck.wordpress.com

Dec. 12, 2017

Did the selection in Playground or rubric change?

by Stephane Ducasse

Hi usually in previous version we could put the cursor on the line and get senders and implementors without having to select the code. Now this super cool features does not work anymore. Is it only my image? Stef

Dec. 12, 2017

Re: [Pharo-dev] [Ann] New Calypso version 0.8

by Mariano Martinez Peck

Hi Denis, Congratulations on the new release! Two quick question: 1) does this work on latest Pharo 6.1 ; 2) Is it safe to update images with Calypso already installed by doing the same baseline loading as the original installation ? Thanks On Tue, Dec 12, 2017 at 9:05 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello. > > I glad announce new Calypso version. It is a big refactoring on navigation > model and browser pluggability. > > Look for details in my blog http://dionisiydk.blogspot.fr/ > 2017/12/new-calypso-version-08-is-out.html. > > Now I start document new design and will post progress on it. > > Notice: this version is not adopted for TelePharo and Cargo. It will be > done soon. > > Best regards, > Denis > -- Mariano http://marianopeck.wordpress.com

Dec. 12, 2017

[Ann] New Calypso version 0.8

by Denis Kudriashov

Hello. I glad announce new Calypso version. It is a big refactoring on navigation model and browser pluggability. Look for details in my blog http://dionisiydk.blogspot.fr/2017/12/new-calypso-version-08-is-out.html. Now I start document new design and will post progress on it. Notice: this version is not adopted for TelePharo and Cargo. It will be done soon. Best regards, Denis

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Nicolas Cellier

2017-12-12 13:01 GMT+01:00 Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no>: > Ben Coman wrote > > > > But after pondering a while for a better name, I wonder what is wrong > with > > the existing? > > Googling "define aggregate" provides... > > aggregate (noun) = a whole formed by combining several separate > > elements. > > aggregate (verb) = form or group into a class or cluster. > > > > The separate elements are runs defined by the block. > > The existing name seems quite precise to me. > > > > cheers -ben > > When I read aggregateRuns:, I think the opposite; something combining > different runs into a single entity, not something that splits a single > collection into constituent runs... > > Something like (split/collect)runsAccordingTo: sounds more descriptive to > my > ears, at least. > > Cheers, > Henry > > > I like groupBy: but in Squeak groupBy: produces a dictionary with unique keys ignoring the multiple sequences... split already carries the meaning of preserving the sequences, but we have to tell to split at a change of value.... Run is also quite explicit... groupByRuns: / splitRuns: > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Henrik Sperre Johansen

Ben Coman wrote > > But after pondering a while for a better name, I wonder what is wrong with > the existing? > Googling "define aggregate" provides... > aggregate (noun) = a whole formed by combining several separate > elements. > aggregate (verb) = form or group into a class or cluster. > > The separate elements are runs defined by the block. > The existing name seems quite precise to me. > > cheers -ben When I read aggregateRuns:, I think the opposite; something combining different runs into a single entity, not something that splits a single collection into constituent runs... Something like (split/collect)runsAccordingTo: sounds more descriptive to my ears, at least. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Ben Coman

On 12 December 2017 at 17:23, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > do you have some proposals for a better name for the message named > #aggregateRuns? > > (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns: [ :each | each = 4]) > >>> #(#(1 2 3) #(4) #(1 2 3 5 6)). > > (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns: [ :each | each = 4]) > >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). > > ((1 to: 12) aggregateRuns: [ :each | (each \\ 3) = 0]) > >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). > > The current comment is: > "Answer a new collection of the same species as the > receiver with elements being collections (of the receiver > species) containing those elements of the receiver > for which the given block consecutively evaluates to > the same object." > > https://pharo.fogbugz.com/f/cases/20864/add-examples-to- > SequenceableCollection-aggregateRuns > > Split is almost an obvious choice, except I feel the same as Norbert that "split methods operate on separators which are not included in the result." Maybe "groupSomethingXXX"... But after pondering a while for a better name, I wonder what is wrong with the existing? Googling "define aggregate" provides... aggregate (noun) = a whole formed by combining several separate elements. aggregate (verb) = form or group into a class or cluster. The separate elements are runs defined by the block. The existing name seems quite precise to me. cheers -ben

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Norbert Hartl

Sorry, Iâm not sure what Iâve read but it does not seem to be the mail of Pavel :) Norbert > Am 12.12.2017 um 11:05 schrieb Norbert Hartl <norbert(a)hartl.name>: > > For me split methods operate on separators which are not included in the result. So name it splitXXX might not be the best idea. And I think it should be more explicit. When the matching elements are included in the result it needs to indicate where the are added. So it is rather something like > > xxxAfter: > > because the collection is separated after the matching element. What the method does is oppositional to flattenXXX. So if we would have the opposite term of flatten that might be a good candidate. Then it would be something like > > roughenAfter: > > :) Ok, stupid name but you got the idea. > > Norbert > > > > > >> Am 12.12.2017 um 10:50 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> #splitWhile: because the block does not define separators but its value indicates runs ? >> >>> On 12 Dec 2017, at 10:34, Thomas Dupriez <thomas.dupriez(a)ens-paris-saclay.fr> wrote: >>> >>> #(1 2 3 4 1 2 3 5 6 ) splitWhen: [ :each | each = 4] >>> >>> >>> Le 12/12/2017 Ã 10:23, Pavel Krivanek a Ã©crit : >>>> Hi, >>>> >>>> do you have some proposals for a better name for the message named #aggregateRuns? >>>> >>>> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns: [ :each | each = 4]) >>>>>>> #(#(1 2 3) #(4) #(1 2 3 5 6)). >>>> >>>> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns: [ :each | each = 4]) >>>>>>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). >>>> >>>> ((1 to: 12) aggregateRuns: [ :each | (each \\ 3) = 0]) >>>>>>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). >>>> >>>> The current comment is: >>>> "Answer a new collection of the same species as the >>>> receiver with elements being collections (of the receiver >>>> species) containing those elements of the receiver >>>> for which the given block consecutively evaluates to >>>> the same object." >>>> >>>> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollect… >>>> >>>> Cheers, >>>> -- Pavel >>> >>>

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Pavel Krivanek

If short names not work, what about to use something more descriptive like #splitToGroupsThatAlternatelySafisfy: -- Pavel 2017-12-12 10:23 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Hi, > > do you have some proposals for a better name for the message named > #aggregateRuns? > > (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns: [ :each | each = 4]) > >>> #(#(1 2 3) #(4) #(1 2 3 5 6)). > > (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns: [ :each | each = 4]) > >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). > > ((1 to: 12) aggregateRuns: [ :each | (each \\ 3) = 0]) > >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). > > The current comment is: > "Answer a new collection of the same species as the > receiver with elements being collections (of the receiver > species) containing those elements of the receiver > for which the given block consecutively evaluates to > the same object." > > https://pharo.fogbugz.com/f/cases/20864/add-examples-to- > SequenceableCollection-aggregateRuns > > Cheers, > -- Pavel >

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Thomas Dupriez

Oups, spoke too fast. My bad. I mean that I don't really see a 'matching element' here, it's more that the collection is cut whenever the block given as argument evaluates to a different value. Le 12/12/2017 Ã 11:11, Thomas Dupriez a Ã©critÂ : > Hm, aggregateRuns: separates the collection both after and before the > separator. > > #(1 2 3 4 1 2 4 5 6 ) aggregateRuns:Â [ :each | each = 4] > > -> Â Â #(#(1 2 3) #(4) #(1 2) #(4) #(5 6)) > > > Le 12/12/2017 Ã 11:05, Norbert Hartl a Ã©critÂ : >> For me split methods operate on separators which are not included in >> the result. So name it splitXXX might not be the best idea. And I >> think it should be more explicit. When the matching elements are >> included in the result it needs to indicate where the are added. So >> it is rather something like >> >> xxxAfter: >> >> because the collection is separated after the matching element. What >> the method does is oppositional to flattenXXX. So if we would have >> the opposite term of flatten that might be a good candidate. Then it >> would be something like >> >> roughenAfter: >> >> :) Ok, stupid name but you got the idea. >> >> Norbert >> >> >> >> >> >>> Am 12.12.2017 um 10:50 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> #splitWhile: because the block does not define separators but its >>> value indicates runs ? >>> >>>> On 12 Dec 2017, at 10:34, Thomas Dupriez >>>> <thomas.dupriez(a)ens-paris-saclay.fr> wrote: >>>> >>>> #(1 2 3 4 1 2 3 5 6 ) splitWhen:Â [ :each | each = 4] >>>> >>>> >>>> Le 12/12/2017 Ã 10:23, Pavel Krivanek a Ã©crit : >>>>> Hi, >>>>> >>>>> do you have some proposals for a better name for the message named >>>>> #aggregateRuns? >>>>> >>>>> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns:Â [ :each | each = 4]) >>>>>>>> #(#(1 2 3) #(4) #(1 2 3 5 6)). >>>>> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns:Â [ :each | each = 4]) >>>>>>>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). >>>>> ((1 to: 12) aggregateRuns:Â [ :each | (each \\ 3) = 0]) >>>>>>>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). >>>>> The current comment is: >>>>> "Answer a new collection of the same species as the >>>>> receiver with elements being collections (of the receiver >>>>> species) containing those elements of the receiver >>>>> for which the given block consecutively evaluates to >>>>> the same object." >>>>> >>>>> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollect… >>>>> >>>>> >>>>> Cheers, >>>>> -- Pavel >>>> >

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Thomas Dupriez

Hm, aggregateRuns: separates the collection both after and before the separator. #(1 2 3 4 1 2 4 5 6 ) aggregateRuns:Â [ :each | each = 4] -> Â Â #(#(1 2 3) #(4) #(1 2) #(4) #(5 6)) Le 12/12/2017 Ã 11:05, Norbert Hartl a Ã©critÂ : > For me split methods operate on separators which are not included in the result. So name it splitXXX might not be the best idea. And I think it should be more explicit. When the matching elements are included in the result it needs to indicate where the are added. So it is rather something like > > xxxAfter: > > because the collection is separated after the matching element. What the method does is oppositional to flattenXXX. So if we would have the opposite term of flatten that might be a good candidate. Then it would be something like > > roughenAfter: > > :) Ok, stupid name but you got the idea. > > Norbert > > > > > >> Am 12.12.2017 um 10:50 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> #splitWhile: because the block does not define separators but its value indicates runs ? >> >>> On 12 Dec 2017, at 10:34, Thomas Dupriez <thomas.dupriez(a)ens-paris-saclay.fr> wrote: >>> >>> #(1 2 3 4 1 2 3 5 6 ) splitWhen: [ :each | each = 4] >>> >>> >>> Le 12/12/2017 Ã 10:23, Pavel Krivanek a Ã©crit : >>>> Hi, >>>> >>>> do you have some proposals for a better name for the message named #aggregateRuns? >>>> >>>> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns: [ :each | each = 4]) >>>>>>> #(#(1 2 3) #(4) #(1 2 3 5 6)). >>>> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns: [ :each | each = 4]) >>>>>>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). >>>> ((1 to: 12) aggregateRuns: [ :each | (each \\ 3) = 0]) >>>>>>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). >>>> The current comment is: >>>> "Answer a new collection of the same species as the >>>> receiver with elements being collections (of the receiver >>>> species) containing those elements of the receiver >>>> for which the given block consecutively evaluates to >>>> the same object." >>>> >>>> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollect… >>>> >>>> Cheers, >>>> -- Pavel >>>

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Norbert Hartl

For me split methods operate on separators which are not included in the result. So name it splitXXX might not be the best idea. And I think it should be more explicit. When the matching elements are included in the result it needs to indicate where the are added. So it is rather something like xxxAfter: because the collection is separated after the matching element. What the method does is oppositional to flattenXXX. So if we would have the opposite term of flatten that might be a good candidate. Then it would be something like roughenAfter: :) Ok, stupid name but you got the idea. Norbert > Am 12.12.2017 um 10:50 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > #splitWhile: because the block does not define separators but its value indicates runs ? > >> On 12 Dec 2017, at 10:34, Thomas Dupriez <thomas.dupriez(a)ens-paris-saclay.fr> wrote: >> >> #(1 2 3 4 1 2 3 5 6 ) splitWhen: [ :each | each = 4] >> >> >> Le 12/12/2017 Ã 10:23, Pavel Krivanek a Ã©crit : >>> Hi, >>> >>> do you have some proposals for a better name for the message named #aggregateRuns? >>> >>> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns: [ :each | each = 4]) >>>>>> #(#(1 2 3) #(4) #(1 2 3 5 6)). >>> >>> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns: [ :each | each = 4]) >>>>>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). >>> >>> ((1 to: 12) aggregateRuns: [ :each | (each \\ 3) = 0]) >>>>>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). >>> >>> The current comment is: >>> "Answer a new collection of the same species as the >>> receiver with elements being collections (of the receiver >>> species) containing those elements of the receiver >>> for which the given block consecutively evaluates to >>> the same object." >>> >>> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollect… >>> >>> Cheers, >>> -- Pavel >> >>

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Thomas Dupriez

#splitByGroupingWhile: The 'split' indicates it's a method to split a collection, and the 'GroupingWhile' expresses how it's done: by grouping elements while they make the block evaluate to the same value. Le 12/12/2017 Ã 10:50, Sven Van Caekenberghe a Ã©critÂ : > #splitWhile: because the block does not define separators but its value indicates runs ? > >> On 12 Dec 2017, at 10:34, Thomas Dupriez <thomas.dupriez(a)ens-paris-saclay.fr> wrote: >> >> #(1 2 3 4 1 2 3 5 6 ) splitWhen: [ :each | each = 4] >> >> >> Le 12/12/2017 Ã 10:23, Pavel Krivanek a Ã©crit : >>> Hi, >>> >>> do you have some proposals for a better name for the message named #aggregateRuns? >>> >>> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns: [ :each | each = 4]) >>> >>> #(#(1 2 3) #(4) #(1 2 3 5 6)). >>> >>> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns: [ :each | each = 4]) >>> >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). >>> >>> ((1 to: 12) aggregateRuns: [ :each | (each \\ 3) = 0]) >>> >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). >>> >>> The current comment is: >>> "Answer a new collection of the same species as the >>> receiver with elements being collections (of the receiver >>> species) containing those elements of the receiver >>> for which the given block consecutively evaluates to >>> the same object." >>> >>> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollect… >>> >>> Cheers, >>> -- Pavel >>

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Sven Van Caekenberghe

#splitWhile: because the block does not define separators but its value indicates runs ? > On 12 Dec 2017, at 10:34, Thomas Dupriez <thomas.dupriez(a)ens-paris-saclay.fr> wrote: > > #(1 2 3 4 1 2 3 5 6 ) splitWhen: [ :each | each = 4] > > > Le 12/12/2017 Ã 10:23, Pavel Krivanek a Ã©crit : >> Hi, >> >> do you have some proposals for a better name for the message named #aggregateRuns? >> >> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns: [ :each | each = 4]) >> >>> #(#(1 2 3) #(4) #(1 2 3 5 6)). >> >> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns: [ :each | each = 4]) >> >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). >> >> ((1 to: 12) aggregateRuns: [ :each | (each \\ 3) = 0]) >> >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). >> >> The current comment is: >> "Answer a new collection of the same species as the >> receiver with elements being collections (of the receiver >> species) containing those elements of the receiver >> for which the given block consecutively evaluates to >> the same object." >> >> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollect… >> >> Cheers, >> -- Pavel > >

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Pavel Krivanek

maybe something in the direction of splitOnThresholds:? 2017-12-12 10:38 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > We already have #splitOn: with slightly different behavior: > > (#(1 2 3 4 1 2 3 5 6 ) splitOn: [ :each | each = 4]) > > So splitOnEach: and splitWhen: would be probably confusing > > 2017-12-12 10:34 GMT+01:00 Thomas Dupriez <thomas.dupriez@ens-paris- > saclay.fr>: > >> #(1 2 3 4 1 2 3 5 6 ) splitWhen: [ :each | each = 4] >> >> >> >> Le 12/12/2017 Ã 10:23, Pavel Krivanek a Ã©crit : >> >>> Hi, >>> >>> do you have some proposals for a better name for the message named >>> #aggregateRuns? >>> >>> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns: [ :each | each = 4]) >>> >>> #(#(1 2 3) #(4) #(1 2 3 5 6)). >>> >>> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns: [ :each | each = 4]) >>> >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). >>> >>> ((1 to: 12) aggregateRuns: [ :each | (each \\ 3) = 0]) >>> >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). >>> >>> The current comment is: >>> "Answer a new collection of the same species as the >>> receiver with elements being collections (of the receiver >>> species) containing those elements of the receiver >>> for which the given block consecutively evaluates to >>> the same object." >>> >>> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-Sequ >>> enceableCollection-aggregateRuns >>> >>> Cheers, >>> -- Pavel >>> >> >> >> >

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Pavel Krivanek

We already have #splitOn: with slightly different behavior: (#(1 2 3 4 1 2 3 5 6 ) splitOn: [ :each | each = 4]) So splitOnEach: and splitWhen: would be probably confusing 2017-12-12 10:34 GMT+01:00 Thomas Dupriez < thomas.dupriez(a)ens-paris-saclay.fr>: > #(1 2 3 4 1 2 3 5 6 ) splitWhen: [ :each | each = 4] > > > > Le 12/12/2017 Ã 10:23, Pavel Krivanek a Ã©crit : > >> Hi, >> >> do you have some proposals for a better name for the message named >> #aggregateRuns? >> >> (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns: [ :each | each = 4]) >> >>> #(#(1 2 3) #(4) #(1 2 3 5 6)). >> >> (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns: [ :each | each = 4]) >> >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). >> >> ((1 to: 12) aggregateRuns: [ :each | (each \\ 3) = 0]) >> >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). >> >> The current comment is: >> "Answer a new collection of the same species as the >> receiver with elements being collections (of the receiver >> species) containing those elements of the receiver >> for which the given block consecutively evaluates to >> the same object." >> >> https://pharo.fogbugz.com/f/cases/20864/add-examples-to-Sequ >> enceableCollection-aggregateRuns >> >> Cheers, >> -- Pavel >> > > >

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Thomas Dupriez

#(1 2 3 4 1 2 3 5 6 ) splitWhen:Â [ :each | each = 4] Le 12/12/2017 Ã 10:23, Pavel Krivanek a Ã©critÂ : > Hi, > > do you have some proposals for a better name for the message named > #aggregateRuns? > > (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns:Â [ :each | each = 4]) > Â Â >>> #(#(1 2 3) #(4) #(1 2 3 5 6)). > > (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns:Â [ :each | each = 4]) > Â Â >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). > > ((1 to: 12) aggregateRuns:Â [ :each | (each \\ 3) = 0]) > Â Â >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). > > The current comment is: > "Answer a new collection of the same species as the > receiver with elements being collections (of the receiver > species) containing those elements of the receiver > for which the given block consecutively evaluates to > the same object." > > https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollect… > > Cheers, > -- Pavel

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Denis Kudriashov

Hi #(1 2 3 4 1 2 3 5 6 ) collectGroupsWhere: [ :each | each = 4]) 2017-12-12 10:23 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Hi, > > do you have some proposals for a better name for the message named > #aggregateRuns? > > (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns: [ :each | each = 4]) > >>> #(#(1 2 3) #(4) #(1 2 3 5 6)). > > (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns: [ :each | each = 4]) > >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). > > ((1 to: 12) aggregateRuns: [ :each | (each \\ 3) = 0]) > >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). > > The current comment is: > "Answer a new collection of the same species as the > receiver with elements being collections (of the receiver > species) containing those elements of the receiver > for which the given block consecutively evaluates to > the same object." > > https://pharo.fogbugz.com/f/cases/20864/add-examples-to- > SequenceableCollection-aggregateRuns > > Cheers, > -- Pavel >

Dec. 12, 2017

Re: [Pharo-dev] better name for #aggregateRuns:

by Alistair Grant

Hi Pavel, On 12 December 2017 at 10:23, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > do you have some proposals for a better name for the message named > #aggregateRuns? > > (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns: [ :each | each = 4]) > >>> #(#(1 2 3) #(4) #(1 2 3 5 6)). > > (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns: [ :each | each = 4]) > >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). > > ((1 to: 12) aggregateRuns: [ :each | (each \\ 3) = 0]) > >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). > > The current comment is: > "Answer a new collection of the same species as the > receiver with elements being collections (of the receiver > species) containing those elements of the receiver > for which the given block consecutively evaluates to > the same object." > > https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollect… > > Cheers, > -- Pavel #groupAround: #selectAround: Cheers, Alistair

Dec. 12, 2017

better name for #aggregateRuns:

by Pavel Krivanek

Hi, do you have some proposals for a better name for the message named #aggregateRuns? (#(1 2 3 4 1 2 3 5 6 ) aggregateRuns: [ :each | each = 4]) >>> #(#(1 2 3) #(4) #(1 2 3 5 6)). (#(1 2 3 4 1 2 3 4 5 6 ) aggregateRuns: [ :each | each = 4]) >>> #(#(1 2 3) #(4) #(1 2 3) #(4) #(5 6)). ((1 to: 12) aggregateRuns: [ :each | (each \\ 3) = 0]) >>> #(#(1 2) #(3) #(4 5) #(6) #(7 8) #(9) #(10 11) #(12)). The current comment is: "Answer a new collection of the same species as the receiver with elements being collections (of the receiver species) containing those elements of the receiver for which the given block consecutively evaluates to the same object." https://pharo.fogbugz.com/f/cases/20864/add-examples-to-SequenceableCollect… Cheers, -- Pavel

Dec. 12, 2017

Re: [Pharo-dev] loading from github changes lgit classes?

by Denis Kudriashov

2017-12-12 8:52 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > I think this was added because on windows if we did not rebuild accessors, > some offsets were nil in external structures. Can that still be an issue? > Not only Windows. Problem was in Pharo 6 where external OSWindow not worked because of nil offsets. And Bloc solved it by manual initialisation after loading code. > > Cheers, > Andrei > > On Tue, Dec 12, 2017 at 7:39 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> >> >> On 12 Dec 2017, at 04:29, Martin Dias <tinchodias(a)gmail.com> wrote: >> >> Should the rebuild changes be logged? >> Maybe we can have EpMonitor suspendDuring: [â¦] >> >> >> no they not. >> what should be suspended is field regeneration on bloc config ;) >> >> Esteban >> >> >> MartÃn >> >> On Mon, Dec 11, 2017 at 6:42 PM, Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> >>> :) This looks interesting: >>> >>> So, postload of bloc and some classes (MozEnum, SpartaCairoEnum) doing a >>> rebuild with this author. >>> >>> 2017-12-11 22:27 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>> >>>> honestly, this should not be happening. >>>> Now, I have no idea why it is happening at all ;) >>>> >>>> I mean, there is no automatic process that would have a UFFI name there >>>> (the only place where this can happen is on #rebuildFieldAccessors and that >>>> will use an UFFIGenerator author, not just UFFI. >>>> And also that method needs to be executed by handâ¦ >>>> >>>> weirdâ¦ can you search for UFFI in system? >>>> >>>> Esteban >>>> >>>> On 11 Dec 2017, at 22:00, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>>> >>>> It happens not only from lgit-classes but from other FFI-Subclasses >>>> too, for example AthensCairoMatrix. >>>> >>>> And some methods have a strange version history (see screenshot). >>>> The timestamp of all of the UFFI changes are during loading gtoolkit. >>>> Maybe during loading we have multiple reinitializations that will >>>> recreate autogenerated methods, again and again ? >>>> >>>> 2017-12-11 21:49 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>> >>>>> But these aren't method changes. >>>>> The class definition is changed. (see screenshot) >>>>> It looks like it adds new class variables, even though they were >>>>> alreday in the original fresh image. >>>>> >>>>> >>>>> 2017-12-11 13:49 GMT+01:00 Max Leske <maxleske(a)gmail.com>: >>>>> >>>>>> Without taking a closer look, those are probably auto generated >>>>>> methods. >>>>>> >>>>>> Max >>>>>> >>>>>> >>>>>> >>>>>> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaihess(a)gmail.com) >>>>>> wrote: >>>>>> >>>>>> How come, loading a github project writes strange code change entries >>>>>> for classes >>>>>> like >>>>>> LGitFetchOptions >>>>>> LGitRemoteCallbacks >>>>>> ... >>>>>> >>>>>> For example, in a Pharo 6.1 image I load bloc like this: >>>>>> >>>>>> Metacello new >>>>>> baseline: 'Bloc'; >>>>>> repository: 'github://pharo-graphics/Bloc:pharo6.1/src'; >>>>>> load: #core >>>>>> >>>>>> In my Epicea code change window I see this entries (see screenshot). >>>>>> And the final "new" version of this classes, (class definitions) just >>>>>> look like the >>>>>> original class definition in a fresh image. >>>>>> >>>>>> >>>>>> >>>>> >>>> <PharoScreenshot.1.png> >>>> >>>> >>>> >>> >> >> >

Dec. 12, 2017

Re: [Pharo-dev] loading from github changes lgit classes?

by Esteban Lorenzano

> On 12 Dec 2017, at 08:52, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > I think this was added because on windows if we did not rebuild accessors, some offsets were nil in external structures. Can that still be an issue? it should not. and even if thatâs the case, you do not need to regenerate accessors: executing #compileFields instead #rebuildFieldAccessors should solve any initialisation problems without actually regenerate all structures, which is what you are doing :) Esteban > > Cheers, > Andrei > > On Tue, Dec 12, 2017 at 7:39 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > >> On 12 Dec 2017, at 04:29, Martin Dias <tinchodias(a)gmail.com <mailto:tinchodias@gmail.com>> wrote: >> >> Should the rebuild changes be logged? >> Maybe we can have EpMonitor suspendDuring: [â¦] > > no they not. > what should be suspended is field regeneration on bloc config ;) > > Esteban > >> >> MartÃn >> >> On Mon, Dec 11, 2017 at 6:42 PM, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >> :) This looks interesting: >> >> So, postload of bloc and some classes (MozEnum, SpartaCairoEnum) doing a rebuild with this author. >> >> 2017-12-11 22:27 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> honestly, this should not be happening. >> Now, I have no idea why it is happening at all ;) >> >> I mean, there is no automatic process that would have a UFFI name there (the only place where this can happen is on #rebuildFieldAccessors and that will use an UFFIGenerator author, not just UFFI. >> And also that method needs to be executed by handâ¦ >> >> weirdâ¦ can you search for UFFI in system? >> >> Esteban >> >>> On 11 Dec 2017, at 22:00, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >>> >>> It happens not only from lgit-classes but from other FFI-Subclasses too, for example AthensCairoMatrix. >>> >>> And some methods have a strange version history (see screenshot). >>> The timestamp of all of the UFFI changes are during loading gtoolkit. >>> Maybe during loading we have multiple reinitializations that will recreate autogenerated methods, again and again ? >>> >>> 2017-12-11 21:49 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>>: >>> But these aren't method changes. >>> The class definition is changed. (see screenshot) >>> It looks like it adds new class variables, even though they were alreday in the original fresh image. >>> >>> >>> 2017-12-11 13:49 GMT+01:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: >>> Without taking a closer look, those are probably auto generated methods. >>> >>> Max >>> >>> >>> >>> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>) wrote: >>> >>>> How come, loading a github project writes strange code change entries for classes >>>> like >>>> LGitFetchOptions >>>> LGitRemoteCallbacks >>>> ... >>>> >>>> For example, in a Pharo 6.1 image I load bloc like this: >>>> >>>> Metacello new >>>> baseline: 'Bloc'; >>>> repository: 'github://pharo-graphics/Bloc: <>pharo6.1/src'; >>>> load: #core >>>> >>>> In my Epicea code change window I see this entries (see screenshot). >>>> And the final "new" version of this classes, (class definitions) just look like the >>>> original class definition in a fresh image. >>>> >>>> >>> >>> >>> <PharoScreenshot.1.png> >> >> >> > >

Dec. 12, 2017

Re: [Pharo-dev] loading from github changes lgit classes?

by Andrei Chis

I think this was added because on windows if we did not rebuild accessors, some offsets were nil in external structures. Can that still be an issue? Cheers, Andrei On Tue, Dec 12, 2017 at 7:39 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 12 Dec 2017, at 04:29, Martin Dias <tinchodias(a)gmail.com> wrote: > > Should the rebuild changes be logged? > Maybe we can have EpMonitor suspendDuring: [â¦] > > > no they not. > what should be suspended is field regeneration on bloc config ;) > > Esteban > > > MartÃn > > On Mon, Dec 11, 2017 at 6:42 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> :) This looks interesting: >> >> So, postload of bloc and some classes (MozEnum, SpartaCairoEnum) doing a >> rebuild with this author. >> >> 2017-12-11 22:27 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> honestly, this should not be happening. >>> Now, I have no idea why it is happening at all ;) >>> >>> I mean, there is no automatic process that would have a UFFI name there >>> (the only place where this can happen is on #rebuildFieldAccessors and that >>> will use an UFFIGenerator author, not just UFFI. >>> And also that method needs to be executed by handâ¦ >>> >>> weirdâ¦ can you search for UFFI in system? >>> >>> Esteban >>> >>> On 11 Dec 2017, at 22:00, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >>> >>> It happens not only from lgit-classes but from other FFI-Subclasses too, >>> for example AthensCairoMatrix. >>> >>> And some methods have a strange version history (see screenshot). >>> The timestamp of all of the UFFI changes are during loading gtoolkit. >>> Maybe during loading we have multiple reinitializations that will >>> recreate autogenerated methods, again and again ? >>> >>> 2017-12-11 21:49 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>> >>>> But these aren't method changes. >>>> The class definition is changed. (see screenshot) >>>> It looks like it adds new class variables, even though they were >>>> alreday in the original fresh image. >>>> >>>> >>>> 2017-12-11 13:49 GMT+01:00 Max Leske <maxleske(a)gmail.com>: >>>> >>>>> Without taking a closer look, those are probably auto generated >>>>> methods. >>>>> >>>>> Max >>>>> >>>>> >>>>> >>>>> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaihess(a)gmail.com) >>>>> wrote: >>>>> >>>>> How come, loading a github project writes strange code change entries >>>>> for classes >>>>> like >>>>> LGitFetchOptions >>>>> LGitRemoteCallbacks >>>>> ... >>>>> >>>>> For example, in a Pharo 6.1 image I load bloc like this: >>>>> >>>>> Metacello new >>>>> baseline: 'Bloc'; >>>>> repository: 'github://pharo-graphics/Bloc:pharo6.1/src'; >>>>> load: #core >>>>> >>>>> In my Epicea code change window I see this entries (see screenshot). >>>>> And the final "new" version of this classes, (class definitions) just >>>>> look like the >>>>> original class definition in a fresh image. >>>>> >>>>> >>>>> >>>> >>> <PharoScreenshot.1.png> >>> >>> >>> >> > >

Dec. 12, 2017

Re: [Pharo-dev] loading from github changes lgit classes?

by Esteban Lorenzano

> On 12 Dec 2017, at 04:29, Martin Dias <tinchodias(a)gmail.com> wrote: > > Should the rebuild changes be logged? > Maybe we can have EpMonitor suspendDuring: [â¦] no they not. what should be suspended is field regeneration on bloc config ;) Esteban > > MartÃn > > On Mon, Dec 11, 2017 at 6:42 PM, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: > :) This looks interesting: > > So, postload of bloc and some classes (MozEnum, SpartaCairoEnum) doing a rebuild with this author. > > 2017-12-11 22:27 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > honestly, this should not be happening. > Now, I have no idea why it is happening at all ;) > > I mean, there is no automatic process that would have a UFFI name there (the only place where this can happen is on #rebuildFieldAccessors and that will use an UFFIGenerator author, not just UFFI. > And also that method needs to be executed by handâ¦ > > weirdâ¦ can you search for UFFI in system? > > Esteban > >> On 11 Dec 2017, at 22:00, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >> >> It happens not only from lgit-classes but from other FFI-Subclasses too, for example AthensCairoMatrix. >> >> And some methods have a strange version history (see screenshot). >> The timestamp of all of the UFFI changes are during loading gtoolkit. >> Maybe during loading we have multiple reinitializations that will recreate autogenerated methods, again and again ? >> >> 2017-12-11 21:49 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>>: >> But these aren't method changes. >> The class definition is changed. (see screenshot) >> It looks like it adds new class variables, even though they were alreday in the original fresh image. >> >> >> 2017-12-11 13:49 GMT+01:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: >> Without taking a closer look, those are probably auto generated methods. >> >> Max >> >> >> >> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>) wrote: >> >>> How come, loading a github project writes strange code change entries for classes >>> like >>> LGitFetchOptions >>> LGitRemoteCallbacks >>> ... >>> >>> For example, in a Pharo 6.1 image I load bloc like this: >>> >>> Metacello new >>> baseline: 'Bloc'; >>> repository: 'github://pharo-graphics/Bloc: <>pharo6.1/src'; >>> load: #core >>> >>> In my Epicea code change window I see this entries (see screenshot). >>> And the final "new" version of this classes, (class definitions) just look like the >>> original class definition in a fresh image. >>> >>> >> >> >> <PharoScreenshot.1.png> > > >

Dec. 12, 2017

Re: [Pharo-dev] loading from github changes lgit classes?

by Esteban Lorenzano

this is a problem on Bloc configuration: unlike NativeBoost, UFFI fields accessors do NOT need to be regenerated each time, so that chunk of code is incorrect. Esteban > On 11 Dec 2017, at 22:42, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > :) This looks interesting: > > So, postload of bloc and some classes (MozEnum, SpartaCairoEnum) doing a rebuild with this author. > > 2017-12-11 22:27 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > honestly, this should not be happening. > Now, I have no idea why it is happening at all ;) > > I mean, there is no automatic process that would have a UFFI name there (the only place where this can happen is on #rebuildFieldAccessors and that will use an UFFIGenerator author, not just UFFI. > And also that method needs to be executed by handâ¦ > > weirdâ¦ can you search for UFFI in system? > > Esteban > >> On 11 Dec 2017, at 22:00, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: >> >> It happens not only from lgit-classes but from other FFI-Subclasses too, for example AthensCairoMatrix. >> >> And some methods have a strange version history (see screenshot). >> The timestamp of all of the UFFI changes are during loading gtoolkit. >> Maybe during loading we have multiple reinitializations that will recreate autogenerated methods, again and again ? >> >> 2017-12-11 21:49 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>>: >> But these aren't method changes. >> The class definition is changed. (see screenshot) >> It looks like it adds new class variables, even though they were alreday in the original fresh image. >> >> >> 2017-12-11 13:49 GMT+01:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: >> Without taking a closer look, those are probably auto generated methods. >> >> Max >> >> >> >> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>) wrote: >> >>> How come, loading a github project writes strange code change entries for classes >>> like >>> LGitFetchOptions >>> LGitRemoteCallbacks >>> ... >>> >>> For example, in a Pharo 6.1 image I load bloc like this: >>> >>> Metacello new >>> baseline: 'Bloc'; >>> repository: 'github://pharo-graphics/Bloc: <>pharo6.1/src'; >>> load: #core >>> >>> In my Epicea code change window I see this entries (see screenshot). >>> And the final "new" version of this classes, (class definitions) just look like the >>> original class definition in a fresh image. >>> >>> >> >> >> <PharoScreenshot.1.png> > > > <PharoScreenshot.3.png>

Dec. 12, 2017

Re: [Pharo-dev] Weird ZnClient benchmarking result

by Stephane Ducasse

sven did you submit a fix to get a clearer printout? Stef On Sun, Dec 10, 2017 at 7:14 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > @ Henrik > > Arg, arg, arg, yes of course. > I actually did think about that, but still did not look carefully enough !! > Really stupid of me. > > It is even worse because I wrote that code ... > > Now, the #printOn: of BenchmarkResult is much clearer, less confusing: > > ZnClient new in: [ :client | > [ client get: 'http://localhost:8080' ] benchFor: 5 seconds ]. > > a BenchmarkResult(14,732 iterations in 5 seconds. 2,946 per second) > > vs > > ZnClient new in: [ :client | > client loggingOff. > [ client get: 'http://localhost:8080' ] benchFor: 5 seconds ]. > > a BenchmarkResult(42 iterations in 5 seconds 88 milliseconds. 8.255 per second) > > Still the same issue with $, and $. in frequency, but the iteration count is crystal clear. > > The reason #bench works like that is backwards compatibility at the time we introduced that. > > @ Ben > > Yes, I should have looked at the other side as well, to confirm things actually happened as I imagined them (the did not). > > Thx and sorry for the noise. > > Sven > >> On 10 Dec 2017, at 18:00, Henrik-Nergaard <draagren(a)outlook.com> wrote: >> >> Hi Sven, >> >> What you are seeing is most likely a $, vs $. issue. >> See BenchmarkResult >>#printFrequenceOn: it uses both decimal and thousand >> separators. >> >> If i run this code: >> ----------------------------------------- >> | counter | >> counter := >> ZnClient new in: [ :client | >> client loggingOff. >> [ client get: 'http://localhost:8080'. counter ] bench >> ]. >> counter. >> ----------------------------------------- >> >> Then i get 9035 ('1,773 per second') when no inspector is open, and only 22 >> ('5.995 per second') when inspecting the logs. >> >> Best regards, >> Henrik >> >> >> >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> > >

Dec. 12, 2017

Re: [Pharo-dev] loading from github changes lgit classes?

by Martin Dias

Should the rebuild changes be logged? Maybe we can have EpMonitor suspendDuring: [...] MartÃn On Mon, Dec 11, 2017 at 6:42 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > :) This looks interesting: > > So, postload of bloc and some classes (MozEnum, SpartaCairoEnum) doing a > rebuild with this author. > > 2017-12-11 22:27 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> honestly, this should not be happening. >> Now, I have no idea why it is happening at all ;) >> >> I mean, there is no automatic process that would have a UFFI name there >> (the only place where this can happen is on #rebuildFieldAccessors and that >> will use an UFFIGenerator author, not just UFFI. >> And also that method needs to be executed by handâ¦ >> >> weirdâ¦ can you search for UFFI in system? >> >> Esteban >> >> On 11 Dec 2017, at 22:00, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> It happens not only from lgit-classes but from other FFI-Subclasses too, >> for example AthensCairoMatrix. >> >> And some methods have a strange version history (see screenshot). >> The timestamp of all of the UFFI changes are during loading gtoolkit. >> Maybe during loading we have multiple reinitializations that will >> recreate autogenerated methods, again and again ? >> >> 2017-12-11 21:49 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >>> But these aren't method changes. >>> The class definition is changed. (see screenshot) >>> It looks like it adds new class variables, even though they were alreday >>> in the original fresh image. >>> >>> >>> 2017-12-11 13:49 GMT+01:00 Max Leske <maxleske(a)gmail.com>: >>> >>>> Without taking a closer look, those are probably auto generated methods. >>>> >>>> Max >>>> >>>> >>>> >>>> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaihess(a)gmail.com) >>>> wrote: >>>> >>>> How come, loading a github project writes strange code change entries >>>> for classes >>>> like >>>> LGitFetchOptions >>>> LGitRemoteCallbacks >>>> ... >>>> >>>> For example, in a Pharo 6.1 image I load bloc like this: >>>> >>>> Metacello new >>>> baseline: 'Bloc'; >>>> repository: 'github://pharo-graphics/Bloc:pharo6.1/src'; >>>> load: #core >>>> >>>> In my Epicea code change window I see this entries (see screenshot). >>>> And the final "new" version of this classes, (class definitions) just >>>> look like the >>>> original class definition in a fresh image. >>>> >>>> >>>> >>> >> <PharoScreenshot.1.png> >> >> >> >

Dec. 12, 2017

Re: [Pharo-dev] Do we have this iterator?

by Sean P. DeNigris

Stephane Ducasse-3 wrote > #(1 2 3 4 1 2 3 5 6 ) consumeUntil: [:each | each = 4) >>>> {#(1 2 3 4) . #( 1 2 3 5 6 )} The shortest kernel thing I could come up with took two steps: `{ #(1 2 3 4 1 2 3 5 6 ) copyUpThrough: 4. #(1 2 3 4 1 2 3 5 6 ) copyAfter: 4 }`. The splitting messages seem to all eat the separator. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 12, 2017

Re: [Pharo-dev] gtInspector+FastTable enhancement requests

by Stephane Ducasse

Esteban At Brest, I will meet the guy that did the google summer of code. He was sick the last two months but he wants to release his enhancements. So this is good. Stef On Mon, Dec 11, 2017 at 10:29 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > I thin there were some FT improvements we should integrate ? > > Esteban > > On 10 Dec 2017, at 09:51, Ben Coman <btc(a)openinworld.com> wrote: > > Feedback for GT'ers... > > I'm probably ab-using FastTable support in gtInspector, > but as a quick hack during initial prototyping it was *very* nice > to be able review retrieved data as a table of instances > with a column per instance variable. > > Some enhancements that would make this even better... > 1. Horizontal scroll bar - There are columns past the right margin that I > can't get to for lack of one. > 2. Column resizing to shift subsequent columns, which could provide another > path to seeing the hidden columns. > 3. Individual column width auto-fit - like in Excel where you double-click > the edge > https://www.youtube.com/watch?v=Yeb8emsjtf4 > 4. All columns auto-fit > 5. Auto-fit columns prior to first opening. > 6. Being able to split column labels over two lines - to allow for thinner > columns > > For a demonstration, > could you please load the attached ST fileout (its small), > and also... > Gofer it > smalltalkhubUser: 'SvenVanCaekenberghe' project: 'Neo'; > configurationOf: 'NeoJSON'; > loadStable. > > Then inspect.... > BittrexMarket getAll. > > cheers -ben > <Demo.zip> > >

Dec. 11, 2017

Do we have this iterator?

by Stephane Ducasse

Hi Did a lot of manual parsing today and I wonder if consumeUntil: would not have helped me. #(1 2 3 4 1 2 3 5 6 ) consumeUntil: [:each | each = 4) >>> {#(1 2 3 4) . #( 1 2 3 5 6 )} Stef

Dec. 11, 2017

Re: [Pharo-dev] loading from github changes lgit classes?

by Nicolai Hess

:) This looks interesting: So, postload of bloc and some classes (MozEnum, SpartaCairoEnum) doing a rebuild with this author. 2017-12-11 22:27 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > honestly, this should not be happening. > Now, I have no idea why it is happening at all ;) > > I mean, there is no automatic process that would have a UFFI name there > (the only place where this can happen is on #rebuildFieldAccessors and that > will use an UFFIGenerator author, not just UFFI. > And also that method needs to be executed by handâ¦ > > weirdâ¦ can you search for UFFI in system? > > Esteban > > On 11 Dec 2017, at 22:00, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > It happens not only from lgit-classes but from other FFI-Subclasses too, > for example AthensCairoMatrix. > > And some methods have a strange version history (see screenshot). > The timestamp of all of the UFFI changes are during loading gtoolkit. > Maybe during loading we have multiple reinitializations that will recreate > autogenerated methods, again and again ? > > 2017-12-11 21:49 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> But these aren't method changes. >> The class definition is changed. (see screenshot) >> It looks like it adds new class variables, even though they were alreday >> in the original fresh image. >> >> >> 2017-12-11 13:49 GMT+01:00 Max Leske <maxleske(a)gmail.com>: >> >>> Without taking a closer look, those are probably auto generated methods. >>> >>> Max >>> >>> >>> >>> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaihess(a)gmail.com) >>> wrote: >>> >>> How come, loading a github project writes strange code change entries >>> for classes >>> like >>> LGitFetchOptions >>> LGitRemoteCallbacks >>> ... >>> >>> For example, in a Pharo 6.1 image I load bloc like this: >>> >>> Metacello new >>> baseline: 'Bloc'; >>> repository: 'github://pharo-graphics/Bloc:pharo6.1/src'; >>> load: #core >>> >>> In my Epicea code change window I see this entries (see screenshot). >>> And the final "new" version of this classes, (class definitions) just >>> look like the >>> original class definition in a fresh image. >>> >>> >>> >> > <PharoScreenshot.1.png> > > >

Dec. 11, 2017

Re: [Pharo-dev] loading from github changes lgit classes?

by Esteban Lorenzano

honestly, this should not be happening. Now, I have no idea why it is happening at all ;) I mean, there is no automatic process that would have a UFFI name there (the only place where this can happen is on #rebuildFieldAccessors and that will use an UFFIGenerator author, not just UFFI. And also that method needs to be executed by handâ¦ weirdâ¦ can you search for UFFI in system? Esteban > On 11 Dec 2017, at 22:00, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > It happens not only from lgit-classes but from other FFI-Subclasses too, for example AthensCairoMatrix. > > And some methods have a strange version history (see screenshot). > The timestamp of all of the UFFI changes are during loading gtoolkit. > Maybe during loading we have multiple reinitializations that will recreate autogenerated methods, again and again ? > > 2017-12-11 21:49 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>>: > But these aren't method changes. > The class definition is changed. (see screenshot) > It looks like it adds new class variables, even though they were alreday in the original fresh image. > > > 2017-12-11 13:49 GMT+01:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: > Without taking a closer look, those are probably auto generated methods. > > Max > > > > On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>) wrote: > >> How come, loading a github project writes strange code change entries for classes >> like >> LGitFetchOptions >> LGitRemoteCallbacks >> ... >> >> For example, in a Pharo 6.1 image I load bloc like this: >> >> Metacello new >> baseline: 'Bloc'; >> repository: 'github://pharo-graphics/Bloc:pharo6.1/src'; >> load: #core >> >> In my Epicea code change window I see this entries (see screenshot). >> And the final "new" version of this classes, (class definitions) just look like the >> original class definition in a fresh image. >> >> > > > <PharoScreenshot.1.png>

Dec. 11, 2017

Re: [Pharo-dev] loading from github changes lgit classes?

by Nicolai Hess

It happens not only from lgit-classes but from other FFI-Subclasses too, for example AthensCairoMatrix. And some methods have a strange version history (see screenshot). The timestamp of all of the UFFI changes are during loading gtoolkit. Maybe during loading we have multiple reinitializations that will recreate autogenerated methods, again and again ? 2017-12-11 21:49 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > But these aren't method changes. > The class definition is changed. (see screenshot) > It looks like it adds new class variables, even though they were alreday > in the original fresh image. > > > 2017-12-11 13:49 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > >> Without taking a closer look, those are probably auto generated methods. >> >> Max >> >> >> >> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaihess(a)gmail.com) >> wrote: >> >> How come, loading a github project writes strange code change entries for >> classes >> like >> LGitFetchOptions >> LGitRemoteCallbacks >> ... >> >> For example, in a Pharo 6.1 image I load bloc like this: >> >> Metacello new >> baseline: 'Bloc'; >> repository: 'github://pharo-graphics/Bloc:pharo6.1/src'; >> load: #core >> >> In my Epicea code change window I see this entries (see screenshot). >> And the final "new" version of this classes, (class definitions) just >> look like the >> original class definition in a fresh image. >> >> >> >

Dec. 11, 2017

Re: [Pharo-dev] [Pharo-users] [TechTalk] Topics Wanted for 2018!

by Alexandre Bergel

Yes! Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Dec 7, 2017, at 10:53 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > What about Tuesday 30th Jan? > >> On 7 Dec 2017, at 02:06, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >> Hi Marcus! >> >> Thanks for pushing the community! >> If there is a free slot at the end of January, I can do another tech talk on AI technique. I am thinking about a lecture on Genetic Algorithm and Genetic Programming. >> >> Let me know... >> >> Alexandre >> >> >>> On Dec 1, 2017, at 7:58 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> Hi, >>> >>> As you know, we are trying to have one Pharo tech-talk per month. >>> >>> The idea is to use this for >>> -> mini âLecturesâ >>> -> Demos of interesting Projects >>> -> Just some interesting topic to discuss with audio chat on Discord >>> >>> You can see the past topics here: >>> >>> http://pharo.org/TechTalk >>> >>> We will soon define the dates for the first half of 2018. If you want to do a techtalk >>> yourself (give a presentation / Demo or moderate a discussion), feel free to contact >>> me! You are able to pick a date that works best for you. >>> >>> >>> Marcus >> >> > >

Dec. 11, 2017

Re: [Pharo-dev] [Pharo 7.0-dev] Build #332: 20759 Unused temps in Metacello classes

by Dale Henrichs

Sorry for the delay ... I am looking at merging this issue into Metacello ... a couple failed tests need to be rerun to see where we stand ... On 11/27/17 12:54 PM, Torsten Bergmann wrote: > Yes - I submitted a PR to Metacello too: https://github.com/Metacello/metacello/pull/473 > > Who is able to merge it there? > > >> Gesendet: Montag, 27. November 2017 um 09:16 Uhr >> Von: "Marcus Denker" <marcus.denker(a)inria.fr> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: Re: [Pharo-dev] [Pharo 7.0-dev] Build #332: 20759 Unused temps in Metacello classes >> >> This fix has been submitted upstream, too. >> >>> On 27 Nov 2017, at 09:09, ci-pharo-ci-jenkins2(a)inria.fr wrote: >>> >>> There is a new Pharo build available! >>> >>> The status of the build #332 was: SUCCESS. >>> >>> The Pull Request #546 was integrated: "20759 Unused temps in Metacello classes" >>> Pull request url: https://github.com/pharo-project/pharo/pull/546 >>> >>> Issue Url: https://pharo.fogbugz.com/f/cases/20759 >>> Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… >> >>

Dec. 11, 2017

Re: [Pharo-dev] loading from github changes lgit classes?

by Nicolai Hess

But these aren't method changes. The class definition is changed. (see screenshot) It looks like it adds new class variables, even though they were alreday in the original fresh image. 2017-12-11 13:49 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > Without taking a closer look, those are probably auto generated methods. > > Max > > > > On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaihess(a)gmail.com) > wrote: > > How come, loading a github project writes strange code change entries for > classes > like > LGitFetchOptions > LGitRemoteCallbacks > ... > > For example, in a Pharo 6.1 image I load bloc like this: > > Metacello new > baseline: 'Bloc'; > repository: 'github://pharo-graphics/Bloc:pharo6.1/src'; > load: #core > > In my Epicea code change window I see this entries (see screenshot). > And the final "new" version of this classes, (class definitions) just look > like the > original class definition in a fresh image. > > >

Dec. 11, 2017

[Pharo 7.0-dev] Build #375: 20857-Confirm-dialog-return-nil-when-closed-by-cmd-w

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

There is a new Pharo build available! The status of the build #375 was: SUCCESS. The Pull Request #596 was integrated: "20857-Confirm-dialog-return-nil-when-closed-by-cmd-w" Pull request url: https://github.com/pharo-project/pharo/pull/596 Issue Url: https://pharo.fogbugz.com/f/cases/20857 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 11, 2017

[Pharo 7.0-dev] Build #374: 20857-Confirm-dialog-return-nil-when-closed-by-cmd-w

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

There is a new Pharo build available! The status of the build #374 was: FAILURE. The Pull Request #596 was integrated: "20857-Confirm-dialog-return-nil-when-closed-by-cmd-w" Pull request url: https://github.com/pharo-project/pharo/pull/596 Issue Url: https://pharo.fogbugz.com/f/cases/20857 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 11, 2017

Re: [Pharo-dev] loading from github changes lgit classes?

by Max Leske

Without taking a closer look, those are probably auto generated methods. Max On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaihess(a)gmail.com) wrote: How come, loading a github project writes strange code change entries for classes like LGitFetchOptions LGitRemoteCallbacks ... For example, in a Pharo 6.1 image I load bloc like this: Metacello new baseline: 'Bloc'; repository: 'github://pharo-graphics/Bloc:pharo6.1/src'; load: #core In my Epicea code change window I see this entries (see screenshot). And the final "new" version of this classes, (class definitions) just look like the original class definition in a fresh image.

Dec. 11, 2017

Re: [Pharo-dev] create snapshots out of github based packages

by Dimitris Chloupis

nice to hear that my very old complaint about filetrees habit of breaking down everything to small files has caught and there is even a project I am not aware of that deal with this. Though my motivation was mostly readability and not speed of loading. Great work! :) On Mon, Dec 11, 2017 at 11:35 AM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > On 10 Dec 2017, at 21:37, Stephan Eggermont <stephan(a)stack.nl> wrote: > > > > Op 10-12-2017 om 15:44 schreef Cyril Ferlicot: > >> On dim. 10 dÃ©c. 2017 at 15:07, Nicolai Hess <nicolaihess(a)gmail.com > wrote: > >>> And I don't mean 1 or 2 thousand files. > >>> Loading bloc for example creates over 20.000 files. > >>> This is damn slow on windows. > >> This is one of the reasons Esteban created Tonel I think. With Tonel > there is 1 file par class instead of 1 file per method. Once it will be > really stable, moving projects to Tonel should speed up things on Windows. > > > > Indeed. An even larger problem is the write amplification: Minimium disk > file size of 4KB means a slow down of a factor 20. 1 (primary) file per > class and sorting the methods helps a lot. Doing that in a cross-platform > compatible way so we can easier share source code needs some further > refinement > > and btw since we moved pharo to tonel windows is a viable platform: > commits became seconds instead minutes (lots of minutes). > still work to do there, but we are getting closerâ¦ ;) > > Esteban > > > > > Stephan > > > > > > >

Dec. 11, 2017

Re: [Pharo-dev] create snapshots out of github based packages

by Esteban Lorenzano

> On 10 Dec 2017, at 21:37, Stephan Eggermont <stephan(a)stack.nl> wrote: > > Op 10-12-2017 om 15:44 schreef Cyril Ferlicot: >> On dim. 10 dÃ©c. 2017 at 15:07, Nicolai Hess <nicolaihess(a)gmail.com wrote: >>> And I don't mean 1 or 2 thousand files. >>> Loading bloc for example creates over 20.000 files. >>> This is damn slow on windows. >> This is one of the reasons Esteban created Tonel I think. With Tonel there is 1 file par class instead of 1 file per method. Once it will be really stable, moving projects to Tonel should speed up things on Windows. > > Indeed. An even larger problem is the write amplification: Minimium disk file size of 4KB means a slow down of a factor 20. 1 (primary) file per class and sorting the methods helps a lot. Doing that in a cross-platform compatible way so we can easier share source code needs some further refinement and btw since we moved pharo to tonel windows is a viable platform: commits became seconds instead minutes (lots of minutes). still work to do there, but we are getting closerâ¦ ;) Esteban > > Stephan > >

Dec. 11, 2017

Re: [Pharo-dev] gtInspector+FastTable enhancement requests

by Esteban Lorenzano

I thin there were some FT improvements we should integrate ? Esteban > On 10 Dec 2017, at 09:51, Ben Coman <btc(a)openinworld.com> wrote: > > Feedback for GT'ers... > > I'm probably ab-using FastTable support in gtInspector, > but as a quick hack during initial prototyping it was *very* nice > to be able review retrieved data as a table of instances > with a column per instance variable. > > Some enhancements that would make this even better... > 1. Horizontal scroll bar - There are columns past the right margin that I can't get to for lack of one. > 2. Column resizing to shift subsequent columns, which could provide another path to seeing the hidden columns. > 3. Individual column width auto-fit - like in Excel where you double-click the edge > https://www.youtube.com/watch?v=Yeb8emsjtf4 <https://www.youtube.com/watch?v=Yeb8emsjtf4> > 4. All columns auto-fit > 5. Auto-fit columns prior to first opening. > 6. Being able to split column labels over two lines - to allow for thinner columns > > For a demonstration, > could you please load the attached ST fileout (its small), > and also... > Gofer it > smalltalkhubUser: 'SvenVanCaekenberghe' project: 'Neo'; > configurationOf: 'NeoJSON'; > loadStable. > > Then inspect.... > BittrexMarket getAll. > > cheers -ben > <Demo.zip>

Dec. 11, 2017

Re: [Pharo-dev] Text Indentation in Pharo editor

by Esteban Lorenzano

> On 8 Dec 2017, at 15:40, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > I would love to have Ctrl E and Ctrl A. > And yes we should not be different for the sake of it. > For the moment the reason is simple: we are full of work and even more. > > FYI: I'm starting at regular crash of the VM and regular superbad > behavior of the debugger (like hundred of debuggers, like spawing many > process) > there is a really bad problem there. > > Setf > > On Fri, Dec 8, 2017 at 10:52 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> On 8 December 2017 at 11:37, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> >>> Torsten Bergmann wrote >>>> so we do it with different shortcuts than regular editors >>> >>> I wonder if it makes sense to allow the standard shortcut. The current one >>> is a bit like playing twister ;) >> >> >> We should be different if there is a good reason, >> but where possible (especially on UI interface) we should align with the >> majority. +1000 this is my work motto, and what Iâm trying to do with my work on Pharo every day :) and of course, lot of work is still needed. >> I feel this case is the latter. agreed. Esteban >> >> cheers -ben >> >> >

Dec. 11, 2017

Re: [Pharo-dev] create snapshots out of github based packages

by Stephan Eggermont

Op 10-12-2017 om 15:44 schreef Cyril Ferlicot: > On dim. 10 dÃ©c. 2017 at 15:07, Nicolai Hess <nicolaihess(a)gmail.com wrote: >> And I don't mean 1 or 2 thousand files. >> Loading bloc for example creates over 20.000 files. >> >> This is damn slow on windows. > > This is one of the reasons Esteban created Tonel I think. With Tonel > there is 1 file par class instead of 1 file per method. Once it will be > really stable, moving projects to Tonel should speed up things on Windows. Indeed. An even larger problem is the write amplification: Minimium disk file size of 4KB means a slow down of a factor 20. 1 (primary) file per class and sorting the methods helps a lot. Doing that in a cross-platform compatible way so we can easier share source code needs some further refinement Stephan

Dec. 10, 2017

Re: [Pharo-dev] Weird ZnClient benchmarking result

by Norbert Hartl

I like that kind of noise because these numbers are very informative. And they show that pharo can be used in heavy scenarios, too > Am 10.12.2017 um 19:14 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > @ Henrik > > Arg, arg, arg, yes of course. > I actually did think about that, but still did not look carefully enough !! > Really stupid of me. > > It is even worse because I wrote that code ... > > Now, the #printOn: of BenchmarkResult is much clearer, less confusing: > > ZnClient new in: [ :client | > [ client get: 'http://localhost:8080' ] benchFor: 5 seconds ]. > > a BenchmarkResult(14,732 iterations in 5 seconds. 2,946 per second) > > vs > > ZnClient new in: [ :client | > client loggingOff. > [ client get: 'http://localhost:8080' ] benchFor: 5 seconds ]. > > a BenchmarkResult(42 iterations in 5 seconds 88 milliseconds. 8.255 per second) > > Still the same issue with $, and $. in frequency, but the iteration count is crystal clear. > > The reason #bench works like that is backwards compatibility at the time we introduced that. > > @ Ben > > Yes, I should have looked at the other side as well, to confirm things actually happened as I imagined them (the did not). > > Thx and sorry for the noise. > > Sven > >> On 10 Dec 2017, at 18:00, Henrik-Nergaard <draagren(a)outlook.com> wrote: >> >> Hi Sven, >> >> What you are seeing is most likely a $, vs $. issue. >> See BenchmarkResult >>#printFrequenceOn: it uses both decimal and thousand >> separators. >> >> If i run this code: >> ----------------------------------------- >> | counter | >> counter := >> ZnClient new in: [ :client | >> client loggingOff. >> [ client get: 'http://localhost:8080'. counter ] bench >> ]. >> counter. >> ----------------------------------------- >> >> Then i get 9035 ('1,773 per second') when no inspector is open, and only 22 >> ('5.995 per second') when inspecting the logs. >> >> Best regards, >> Henrik >> >> >> >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>

Dec. 10, 2017

Re: [Pharo-dev] How to get rid of empty XML nodes?

by Norbert Hartl

Sure it can get quite annoying. It would be good to have a switch to prevent the creation of whitespace-only nodes at parse time. Norbert > Am 10.12.2017 um 08:42 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > Norbert > > Should I say to the tool generating the XML that it is an idiot? Even > that I cannot. It is a tool I do not control. > I have no control about what I get. > Now why we cannot control that if people add a line return or not does > not matter? > Why I cannot be in charge of deciding? I take the risk of the > interpretation but now > the "standard" does not help me at all. It just tells me that is good for me. > > I implemented in the past "standards" like XMI to found that there > were bugs in the spec. > > At then end, each time I visit a node I have to check > > visitNodeWithElements: aNodeWithElements > | currentNode | > currentNode := OkStubNode new. > self cleanNode: aNodeWithElements. > aNodeWithElements hasChildren > ifTrue: [ | tokenNode | > self cleanNode: aNodeWithElements nodes first. > tokenNode := self visitElement: aNodeWithElements > nodes first. > self assert: tokenNode isToken. > currentNode addChild: tokenNode. > aNodeWithElements nodes allButFirst > do: [ :each | currentNode addChild: (self > visitNodeWithElements: each) ] ]. > ^ currentNode > > And I do not like to modify a structure while I'm visiting it. > > > cleanNode: aNodeWithElements > aNodeWithElements removeNodes: (aNodeWithElements nodes select: > [ :e | e isStringNode and: [ e isEmpty or: [ e isWhitespace ] ] ]) > > So I understand why people are going away from XML. > > Stef > >> On Fri, Dec 8, 2017 at 4:02 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >>> Am 08.12.2017 um 14:21 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: >>> >>> Hi monty >>> >>> >>>> On Fri, Dec 8, 2017 at 9:03 AM, monty <monty2(a)programmer.net> wrote: >>>> By "empty XML nodes," do you mean whitespace-only string nodes? >>> >>> Yes >>> >>>> Those are included because all in-element whitespace is assumed significant by the spec: https://www.w3.org/TR/xml/#sec-white-space >>> >>> I know. There was a discussion a while ago. I just lost a couple of >>> hours understanding that :( >>> >>> But this is a super super super annoying practices. >>> We had to test each nodes to see if it is a empty nodes so it makes >>> everything a lot more complex without real justification >>> beside the fact that these standardizers probably never implemented >>> some real cases. >>> This standard is a really out of reality from that perspective. >> >> Are you sure you do not oversimplify things? XML would be even more complex if these cases would be in the standard. It is not easy to decide if a whitespace is important or not. >> Where do this whitespaces in your case come from? Most probably because the XML is pretty printed. That is inserting whitespaces into the serialized text. So why not just stopping to pretty print and your problem is gone. >> >> Norbert >>> >>>> The exception is if the element is declared in the DTD as only having element children ("element content"): https://www.w3.org/TR/xml/#dt-elemcontent >>> >>> Well the XML files that I had (I did not choose XML because I would >>> have prefer JSON :) ), had no DTD :( >>> >>> So at the end of the day, this wonderful standard puts all the stress >>> and burden to people. >>> >>>> >>>> For example, if you declare an element like this: >>>> >>>> <!ELEMENT one (two,three*,four?)> >>>> >>>> Any whitespace around a "two," "three," or "four" element child of a "one" element is insignificant and ignored (unless #preservesIgnorableWhitespace: is true). Other parsers, like LibXML2 and Xerces, behave the same way. >>>> >>>> I'll see if I can come up with some easier way to deal with this, like an optional parser setting, new enumeration methods, or maybe a tree transformation. >>> >>> It would be A HUGE PLUS!!!!!!!!!!!!!!!!!! >>> >>> >>> Because reality is that people have XML files with just nodes and no >>> empty nodes and they are forced to >>> Let me know because I could try. >>> >>> I was showing how to use Pharo to import code to pharo learners and >>> this was a big drag. >>> >>> Stef >>> >>> >>> I tried to set some values in the parser but it did not work. >>> BTW I saw that the configuration logic forces to write the following >>> >>> | parser doc visitor | >>> parser := XMLDOMParser new >>> on: self xmlContents; >>> preservesIgnorableWhitespace: true. >>> >>> and not >>> >>> | parser doc visitor | >>> parser := XMLDOMParser new >>> preservesIgnorableWhitespace: true. >>> on: self xmlContents; >>> >>> >>>> >>>>> Sent: Tuesday, December 05, 2017 at 8:29 AM >>>>> From: "Stephane Ducasse" <stepharo.self(a)gmail.com> >>>>> To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>>>> Subject: [Pharo-dev] How to get rid of empty XML nodes? >>>>> >>>>> )Hi >>>>> >>>>> we are manipulating an XML document and I would like to get rid of the >>>>> spurious empty string. >>>>> We saw that the gt panes are doing it. >>>>> >>>>> (aNodeWithElements isStringNode >>>>> and: [aNodeWithElements isEmpty >>>>> or: [aNodeWithElements isWhitespace]] >>>>> >>>>> Is there a way not to produce empty nodes? >>>>> Is there a simple way not to have to handle them >>>>> >>>>> Now each time we are dealing with a node with have to check. >>>>> >>>>> Stef >>>>> >>>>> >>>> >> > <Original-java.xml>

Dec. 10, 2017

About margin and rectangle

by Stephane Ducasse

Hi While harvesting the old change of Henrik on margins and the idea that Rectangle should not be used to express margins. I looked at expandBy: comment In fact I would like to make sure that that no rectangle is passed as argument and that we can deprecate asMargin from the Rectangle class (we can keep it but I would like to identify the callers). expandBy: delta "Answer a Rectangle that is outset from the receiver by delta. delta is a Rectangle, Point, or scalar." ^ delta asMargin expandRectangle: self So looked at all the senders of expandBy: and they look ok. I imagine that I should do the same for extendBy: Stef

Dec. 10, 2017

Re: [Pharo-dev] Weird ZnClient benchmarking result

by Sven Van Caekenberghe

@ Henrik Arg, arg, arg, yes of course. I actually did think about that, but still did not look carefully enough !! Really stupid of me. It is even worse because I wrote that code ... Now, the #printOn: of BenchmarkResult is much clearer, less confusing: ZnClient new in: [ :client | [ client get: 'http://localhost:8080' ] benchFor: 5 seconds ]. a BenchmarkResult(14,732 iterations in 5 seconds. 2,946 per second) vs ZnClient new in: [ :client | client loggingOff. [ client get: 'http://localhost:8080' ] benchFor: 5 seconds ]. a BenchmarkResult(42 iterations in 5 seconds 88 milliseconds. 8.255 per second) Still the same issue with $, and $. in frequency, but the iteration count is crystal clear. The reason #bench works like that is backwards compatibility at the time we introduced that. @ Ben Yes, I should have looked at the other side as well, to confirm things actually happened as I imagined them (the did not). Thx and sorry for the noise. Sven > On 10 Dec 2017, at 18:00, Henrik-Nergaard <draagren(a)outlook.com> wrote: > > Hi Sven, > > What you are seeing is most likely a $, vs $. issue. > See BenchmarkResult >>#printFrequenceOn: it uses both decimal and thousand > separators. > > If i run this code: > ----------------------------------------- > | counter | > counter := > ZnClient new in: [ :client | > client loggingOff. > [ client get: 'http://localhost:8080'. counter ] bench > ]. > counter. > ----------------------------------------- > > Then i get 9035 ('1,773 per second') when no inspector is open, and only 22 > ('5.995 per second') when inspecting the logs. > > Best regards, > Henrik > > > > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Dec. 10, 2017

Re: [Pharo-dev] Weird ZnClient benchmarking result

by Henrik Sperre Johansen

Sven Van Caekenberghe-2 wrote > Hi, > > While benchmarking ZnClient I encountered something weird and counter > intuitive that I cannot explain. > > This was on macOS running Pharo 7 and 6. > > First you need to setup a fast local HTTP server, can be anything, for > example: > > $ brew install nginx > $ brew services start nginx > $ curl http://localhost:8080 > > In Pharo, the benchmark code looks as follows: > > ZnClient new in: [ :client | > [ client get: 'http://localhost:8080' ] bench ]. > > On my machine this gives about 2500 req/s. > > ZnClient uses object logging: it emits special event objects that contain > information regarding what happens (full details and timing information) > using an Announcer. Subscribers can then decide what to do with this > detailed information. This mechanism is always active, but there is an > option to turn it totally off for maximum performance: > > ZnClient new in: [ :client | > client loggingOff. > [ client get: 'http://localhost:8080' ] bench ]. > > This gives about 3000 req/s, a non-trivial + 500 req/s improvement. > > Now comes the weird thing. GT contains a custom view for Announcers, > inspect: > > ZnLogEvent announcer. > > And select the Announcements tab. Leave this window open. > > Now, the first expression (with full logging enabled and an active > subscriber with a UI) is way FASTER than first, it yields about 7000 to > 8000 req/s. Since the benchmark runs in the main UI thread, no actual > drawing happens until the expression finishes. > > Running both expression inside a Time profiler show how in the first case > significant time (actually *most* time ;-) is spent in the logging: > > > > In the second case, with logging disabled, that changes to: > > > > One has to take into account that the request has to be processed by the > server, so from the client's perspective, most time will always be spent > waiting for a reply, #readResponse. With the logging enabled, probably > less time is spent waiting, since the client does a bit more work. Still > what should be slower is more than 2 times as fast ! > > I have a feeling that this has to do with scheduling (probably interacting > with network IO), as going deep into the last #readResponse above, I see: > > > > But I still cannot understand why doing apparently more work results in > faster throughput. > > Can anyone explain this behaviour ? > > Thx, > > Sven > > > > Screen Shot 2017-12-10 at 16.59.36.png (68K) > <http://forum.world.st/attachment/5060328/0/Screen%20Shot%202017-12-10%20at%2016.59.36.png> > Screen Shot 2017-12-10 at 17.00.28.png (60K) > <http://forum.world.st/attachment/5060328/1/Screen%20Shot%202017-12-10%20at%2017.00.28.png> > Screen Shot 2017-12-10 at 17.07.39.png (140K) > <http://forum.world.st/attachment/5060328/2/Screen%20Shot%202017-12-10%20at%2017.07.39.png> Just a theory, but iirc, if the vm heartbeat thread isn't running properly, newly arrived external events only gets checked every N executed bytecodes. Could explain an increase in delay times before the socket semaphore is signalled. Should be easily testable, any low-priority thread with an infinite loop would probably do enough work. Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 10, 2017

Re: [Pharo-dev] Weird ZnClient benchmarking result

by Henrik-Nergaard

Hi Sven, What you are seeing is most likely a $, vs $. issue. See BenchmarkResult >>#printFrequenceOn: it uses both decimal and thousand separators. If i run this code: ----------------------------------------- | counter | counter := ZnClient new in: [ :client | client loggingOff. [ client get: 'http://localhost:8080'. counter ] bench ]. counter. ----------------------------------------- Then i get 9035 ('1,773 per second') when no inspector is open, and only 22 ('5.995 per second') when inspecting the logs. Best regards, Henrik -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 10, 2017

Re: [Pharo-dev] Weird ZnClient benchmarking result

by Ben Coman

On 11 December 2017 at 00:14, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > While benchmarking ZnClient I encountered something weird and counter > intuitive that I cannot explain. > > This was on macOS running Pharo 7 and 6. > > First you need to setup a fast local HTTP server, can be anything, for > example: > > $ brew install nginx > $ brew services start nginx > $ curl http://localhost:8080 > > In Pharo, the benchmark code looks as follows: > > ZnClient new in: [ :client | > [ client get: 'http://localhost:8080' ] bench ]. > > On my machine this gives about 2500 req/s. > > ZnClient uses object logging: it emits special event objects that contain > information regarding what happens (full details and timing information) > using an Announcer. Subscribers can then decide what to do with this > detailed information. This mechanism is always active, but there is an > option to turn it totally off for maximum performance: > > ZnClient new in: [ :client | > client loggingOff. > [ client get: 'http://localhost:8080' ] bench ]. > > This gives about 3000 req/s, a non-trivial + 500 req/s improvement. > > Now comes the weird thing. GT contains a custom view for Announcers, > inspect: > > ZnLogEvent announcer. > > And select the Announcements tab. Leave this window open. > > Now, the first expression (with full logging enabled and an active > subscriber with a UI) is way FASTER than first, it yields about 7000 to > 8000 req/s. Since the benchmark runs in the main UI thread, no actual > drawing happens until the expression finishes. > Can you compare logging from Nginx to confirm the additional requests. Perhaps in the second case each Annoucement is being re-Announced. cheers -ben > > Running both expression inside a Time profiler show how in the first case > significant time (actually *most* time ;-) is spent in the logging: > > > In the second case, with logging disabled, that changes to: > > > One has to take into account that the request has to be processed by the > server, so from the client's perspective, most time will always be spent > waiting for a reply, #readResponse. With the logging enabled, probably less > time is spent waiting, since the client does a bit more work. Still what > should be slower is more than 2 times as fast ! > > I have a feeling that this has to do with scheduling (probably interacting > with network IO), as going deep into the last #readResponse above, I see: > > > But I still cannot understand why doing apparently more work results in > faster throughput. > > Can anyone explain this behaviour ? > > Thx, > > Sven > >

Dec. 10, 2017

Weird ZnClient benchmarking result

by Sven Van Caekenberghe

Hi, While benchmarking ZnClient I encountered something weird and counter intuitive that I cannot explain. This was on macOS running Pharo 7 and 6. First you need to setup a fast local HTTP server, can be anything, for example: $ brew install nginx $ brew services start nginx $ curl http://localhost:8080 In Pharo, the benchmark code looks as follows: ZnClient new in: [ :client | [ client get: 'http://localhost:8080' ] bench ]. On my machine this gives about 2500 req/s. ZnClient uses object logging: it emits special event objects that contain information regarding what happens (full details and timing information) using an Announcer. Subscribers can then decide what to do with this detailed information. This mechanism is always active, but there is an option to turn it totally off for maximum performance: ZnClient new in: [ :client | client loggingOff. [ client get: 'http://localhost:8080' ] bench ]. This gives about 3000 req/s, a non-trivial + 500 req/s improvement. Now comes the weird thing. GT contains a custom view for Announcers, inspect: ZnLogEvent announcer. And select the Announcements tab. Leave this window open. Now, the first expression (with full logging enabled and an active subscriber with a UI) is way FASTER than first, it yields about 7000 to 8000 req/s. Since the benchmark runs in the main UI thread, no actual drawing happens until the expression finishes. Running both expression inside a Time profiler show how in the first case significant time (actually *most* time ;-) is spent in the logging: In the second case, with logging disabled, that changes to: One has to take into account that the request has to be processed by the server, so from the client's perspective, most time will always be spent waiting for a reply, #readResponse. With the logging enabled, probably less time is spent waiting, since the client does a bit more work. Still what should be slower is more than 2 times as fast ! I have a feeling that this has to do with scheduling (probably interacting with network IO), as going deep into the last #readResponse above, I see: But I still cannot understand why doing apparently more work results in faster throughput. Can anyone explain this behaviour ? Thx, Sven

Dec. 10, 2017

Re: [Pharo-dev] create snapshots out of github based packages

by Cyril Ferlicot

On dim. 10 dÃ©c. 2017 at 15:07, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > Is there any way to create a "snapshot" of a project from a git based > repository. > Something that creates a "condensed" old style mcz package ? > Maybe there is already something and I missed it ? > > Because now I am just a little shocked how much files are created during > loading > a project. > > I did some tests with gtoolkit bloc and calypso. > Sure, bloc or gtoollkit may be huge projects, but they produce thousands > of files. > And I don't mean 1 or 2 thousand files. > Loading bloc for example creates over 20.000 files. > > This is damn slow on windows. > Hi, This is one of the reasons Esteban created Tonel I think. With Tonel there is 1 file par class instead of 1 file per method. Once it will be really stable, moving projects to Tonel should speed up things on Windows. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Dec. 10, 2017

create snapshots out of github based packages

by Nicolai Hess

Is there any way to create a "snapshot" of a project from a git based repository. Something that creates a "condensed" old style mcz package ? Maybe there is already something and I missed it ? Because now I am just a little shocked how much files are created during loading a project. I did some tests with gtoolkit bloc and calypso. Sure, bloc or gtoollkit may be huge projects, but they produce thousands of files. And I don't mean 1 or 2 thousand files. Loading bloc for example creates over 20.000 files. This is damn slow on windows.

Dec. 10, 2017

loading from github changes lgit classes?

by Nicolai Hess

How come, loading a github project writes strange code change entries for classes like LGitFetchOptions LGitRemoteCallbacks ... For example, in a Pharo 6.1 image I load bloc like this: Metacello new baseline: 'Bloc'; repository: 'github://pharo-graphics/Bloc:pharo6.1/src'; load: #core In my Epicea code change window I see this entries (see screenshot). And the final "new" version of this classes, (class definitions) just look like the original class definition in a fresh image.

Dec. 10, 2017

gtInspector+FastTable enhancement requests

by Ben Coman

Feedback for GT'ers... I'm probably ab-using FastTable support in gtInspector, but as a quick hack during initial prototyping it was *very* nice to be able review retrieved data as a table of instances with a column per instance variable. Some enhancements that would make this even better... 1. Horizontal scroll bar - There are columns past the right margin that I can't get to for lack of one. 2. Column resizing to shift subsequent columns, which could provide another path to seeing the hidden columns. 3. Individual column width auto-fit - like in Excel where you double-click the edge https://www.youtube.com/watch?v=Yeb8emsjtf4 4. All columns auto-fit 5. Auto-fit columns prior to first opening. 6. Being able to split column labels over two lines - to allow for thinner columns For a demonstration, could you please load the attached ST fileout (its small), and also... Gofer it smalltalkhubUser: 'SvenVanCaekenberghe' project: 'Neo'; configurationOf: 'NeoJSON'; loadStable. Then inspect.... BittrexMarket getAll. cheers -ben

Dec. 10, 2017

Re: [Pharo-dev] How to get rid of empty XML nodes?

by Stephane Ducasse

Norbert Should I say to the tool generating the XML that it is an idiot? Even that I cannot. It is a tool I do not control. I have no control about what I get. Now why we cannot control that if people add a line return or not does not matter? Why I cannot be in charge of deciding? I take the risk of the interpretation but now the "standard" does not help me at all. It just tells me that is good for me. I implemented in the past "standards" like XMI to found that there were bugs in the spec. At then end, each time I visit a node I have to check visitNodeWithElements: aNodeWithElements | currentNode | currentNode := OkStubNode new. self cleanNode: aNodeWithElements. aNodeWithElements hasChildren ifTrue: [ | tokenNode | self cleanNode: aNodeWithElements nodes first. tokenNode := self visitElement: aNodeWithElements nodes first. self assert: tokenNode isToken. currentNode addChild: tokenNode. aNodeWithElements nodes allButFirst do: [ :each | currentNode addChild: (self visitNodeWithElements: each) ] ]. ^ currentNode And I do not like to modify a structure while I'm visiting it. cleanNode: aNodeWithElements aNodeWithElements removeNodes: (aNodeWithElements nodes select: [ :e | e isStringNode and: [ e isEmpty or: [ e isWhitespace ] ] ]) So I understand why people are going away from XML. Stef On Fri, Dec 8, 2017 at 4:02 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > >> Am 08.12.2017 um 14:21 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> Hi monty >> >> >>> On Fri, Dec 8, 2017 at 9:03 AM, monty <monty2(a)programmer.net> wrote: >>> By "empty XML nodes," do you mean whitespace-only string nodes? >> >> Yes >> >>> Those are included because all in-element whitespace is assumed significant by the spec: https://www.w3.org/TR/xml/#sec-white-space >> >> I know. There was a discussion a while ago. I just lost a couple of >> hours understanding that :( >> >> But this is a super super super annoying practices. >> We had to test each nodes to see if it is a empty nodes so it makes >> everything a lot more complex without real justification >> beside the fact that these standardizers probably never implemented >> some real cases. >> This standard is a really out of reality from that perspective. > > Are you sure you do not oversimplify things? XML would be even more complex if these cases would be in the standard. It is not easy to decide if a whitespace is important or not. > Where do this whitespaces in your case come from? Most probably because the XML is pretty printed. That is inserting whitespaces into the serialized text. So why not just stopping to pretty print and your problem is gone. > > Norbert >> >>> The exception is if the element is declared in the DTD as only having element children ("element content"): https://www.w3.org/TR/xml/#dt-elemcontent >> >> Well the XML files that I had (I did not choose XML because I would >> have prefer JSON :) ), had no DTD :( >> >> So at the end of the day, this wonderful standard puts all the stress >> and burden to people. >> >>> >>> For example, if you declare an element like this: >>> >>> <!ELEMENT one (two,three*,four?)> >>> >>> Any whitespace around a "two," "three," or "four" element child of a "one" element is insignificant and ignored (unless #preservesIgnorableWhitespace: is true). Other parsers, like LibXML2 and Xerces, behave the same way. >>> >>> I'll see if I can come up with some easier way to deal with this, like an optional parser setting, new enumeration methods, or maybe a tree transformation. >> >> It would be A HUGE PLUS!!!!!!!!!!!!!!!!!! >> >> >> Because reality is that people have XML files with just nodes and no >> empty nodes and they are forced to >> Let me know because I could try. >> >> I was showing how to use Pharo to import code to pharo learners and >> this was a big drag. >> >> Stef >> >> >> I tried to set some values in the parser but it did not work. >> BTW I saw that the configuration logic forces to write the following >> >> | parser doc visitor | >> parser := XMLDOMParser new >> on: self xmlContents; >> preservesIgnorableWhitespace: true. >> >> and not >> >> | parser doc visitor | >> parser := XMLDOMParser new >> preservesIgnorableWhitespace: true. >> on: self xmlContents; >> >> >>> >>>> Sent: Tuesday, December 05, 2017 at 8:29 AM >>>> From: "Stephane Ducasse" <stepharo.self(a)gmail.com> >>>> To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>>> Subject: [Pharo-dev] How to get rid of empty XML nodes? >>>> >>>> )Hi >>>> >>>> we are manipulating an XML document and I would like to get rid of the >>>> spurious empty string. >>>> We saw that the gt panes are doing it. >>>> >>>> (aNodeWithElements isStringNode >>>> and: [aNodeWithElements isEmpty >>>> or: [aNodeWithElements isWhitespace]] >>>> >>>> Is there a way not to produce empty nodes? >>>> Is there a simple way not to have to handle them >>>> >>>> Now each time we are dealing with a node with have to check. >>>> >>>> Stef >>>> >>>> >>> >

Dec. 10, 2017

Re: [Pharo-dev] Text Indentation in Pharo editor

by Stephane Ducasse

I think so too. Yesterday we got a crazy stuff spawning UI processes like hell. In fact I have the impression that a crazy progress is running from time to time. I wonder if it is not linked to tests. Stef On Sat, Dec 9, 2017 at 7:48 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > >> Am 08.12.2017 um 21:24 schrieb Tudor Girba <tudor(a)tudorgirba.com>: >> >> Hi Stef, >> >> Do you get the debugger issue even in a plain Pharo image? >> > I do > > Norbert >> Doru >> >> >>> On Dec 8, 2017, at 3:40 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> I would love to have Ctrl E and Ctrl A. >>> And yes we should not be different for the sake of it. >>> For the moment the reason is simple: we are full of work and even more. >>> >>> FYI: I'm starting at regular crash of the VM and regular superbad >>> behavior of the debugger (like hundred of debuggers, like spawing many >>> process) >>> there is a really bad problem there. >>> >>> Setf >>> >>>> On Fri, Dec 8, 2017 at 10:52 AM, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>> >>>>> On 8 December 2017 at 11:37, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>>>> >>>>> Torsten Bergmann wrote >>>>>> so we do it with different shortcuts than regular editors >>>>> >>>>> I wonder if it makes sense to allow the standard shortcut. The current one >>>>> is a bit like playing twister ;) >>>> >>>> >>>> We should be different if there is a good reason, >>>> but where possible (especially on UI interface) we should align with the >>>> majority. >>>> I feel this case is the latter. >>>> >>>> cheers -ben >>>> >>>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Don't give to get. Just give." >

Dec. 10, 2017

Re: [Pharo-dev] [Moose-dev] [ann] gtmondrian

by Stephane Ducasse

tx doru I will have to digest this. I will reread it multiple times. But I'm happy that the edges are not poluting BlElement :). Stef On Sat, Dec 9, 2017 at 9:25 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Here is an example that shows the distinction between edge and line: > > elementToVisualize := BlChicken chicken. > elementToVisualize forceLayout. > root := BlElement new constraintsDo: [:c | > c horizontal matchParent. c vertical matchParent]. > elementToVisualize allChildrenBreadthFirstDo: [ :each | > | label | > *label* := BlTextElement new > text: each gtDisplayString asRopedText; > background: Color white; > effect: (BlDropShadowEffect color: (Color gray alpha: 0.5) width: 10 > offset: 0@0). > label userData at: #model put: each. > root children > detect: [ :child | > (child userData at: #model ifAbsent: [ nil ]) = each parent ] > ifFound: [ :*parentLabel* | > | edge | > *edge := GtGraphEdge new from: parentLabel to: label.* > * parentLabel constraints graph addConnectedEdge: edge.* > * label constraints graph addConnectedEdge: edge* ]. > root addChild: label]. > root layout: (GtGraphHorizontalTreeLayout new layered; verticalGap: 20). > root > > With this we visualize the elements that make the chicken element demo: > - we create a label for each element > - we find the parentLabel corresponding to the parent element > - we create an edge between the parentLabel and the current label > > The example gives us this: > > > The edge is a constraint. It has no visual impact. And the graph layouts > take the edge constraints into account. The cool thing is the GtGraphEdge > is defined next to the graph layout classes, not in the core of Bloc. > > To add a visual impact, we have to create a separate line: > > > > > Thanks for the question. This email is now a comment in the graph layout > examples and can be viewed like this: > > > Cheers, > Doru > > > > On Dec 9, 2017, at 8:43 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > Super super cool. > > > On 9 Dec 2017, at 08:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > We are happy to announce GT Mondrian, a graph visualization engine built > on top of Bloc. > > It is similar to the original Mondrian and the Mondrian from Roassal, but > it is different in that it is built directly out of Bloc elements. This is > interesting because it allows us to combine typical widgets with > visualizations. The other interesting thing about it is that it validates > the design of Bloc: right now, the implementation has 509 lines of code > (excluding graph-specific layouts). The goal is to make visualization a > first class citizen and an integral part of the IDE. > > The key ingredient that made this happen is that Bloc can now treat graph > layouts, such as tree or force based, behave under the same rules as > typical widget layouts, such as grid or flow. The challenge comes from the > fact that a graph layout depends on the notion of edges between elements, > and we did not want to have elements know about edges in the core of Bloc. > > The solution was to split the typical edge implementation in graph > visualization libraries into two distinct concepts: > â¢ Line is an element that draws the connections. > â¢ Edge defines constraints imposed by connections between elements. > > > Can you give an example? > > BTW doru did you think about having a bloc layer on top of telescope model? > Because from that perspective telescope offers a visualisation model while > roassal/mondrian like design are > more a pen-oriented metaphor. > > I wanted to do it to learn Bloc but Iâm running against time and trying to > flush pilling duties (I want to also release > the book that we wrote with luc and olivier and convert the seaside book > and and andâ¦.. :( > > > > > Thus, edges form constraints, and constraints are what layouts deal with. > That is one reason why elements in bloc have the ability of defining > layout-specific constraints. Using this, we can nicely define edges between > elements as a plugin to Bloc, but still be able to connect arbitrary > elements. What's more, it turns out that we need constraints for other > layouts as well. For example, an element in a grid layout might specify the > span. > > The API of GT Mondrian is similar to the one from Roassal, but there are a > few differences as well. These are described in the Pillar documentation > available in the GitHub repo. > > The best way to experience GT Mondrian and its documentation is to load > the GToolkit as described here: > https://github.com/feenkcom/gtoolkit > > If you download the GT code through Iceberg, the documentation can be > experienced live by inspecting: > './pharo-local/iceberg/feenkcom/gtoolkit-visualizer/doc/mondrian/index.pillar' > asFileReference > > > <mondrian-doc.png> > > > > > > Cheers, > The feenk team > > > -- > www.tudorgirba.com > www.feenk.com > > "Quality cannot be an afterthought." > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr > http://www.synectique.eu / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > <https://maps.google.com/?q=40,+avenue+Halley,%C2%A0+Parc+Scientifique+de+la…> > > Parc Scientifique de la Haute Borne > <https://maps.google.com/?q=40,+avenue+Halley,%C2%A0+Parc+Scientifique+de+la…>, > BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > -- > www.tudorgirba.com > www.feenk.com > > "Every successful trip needs a suitable vehicle." > > > > > >

Dec. 10, 2017

Re: [Pharo-dev] [Moose-dev] [ann] gtmondrian

by Tudor Girba

Hi, Here is an example that shows the distinction between edge and line: elementToVisualize := BlChicken chicken. elementToVisualize forceLayout. root := BlElement new constraintsDo: [:c | c horizontal matchParent. c vertical matchParent]. elementToVisualize allChildrenBreadthFirstDo: [ :each | | label | label := BlTextElement new text: each gtDisplayString asRopedText; background: Color white; effect: (BlDropShadowEffect color: (Color gray alpha: 0.5) width: 10 offset: 0@0). label userData at: #model put: each. root children detect: [ :child | (child userData at: #model ifAbsent: [ nil ]) = each parent ] ifFound: [ :parentLabel | | edge | edge := GtGraphEdge new from: parentLabel to: label. parentLabel constraints graph addConnectedEdge: edge. label constraints graph addConnectedEdge: edge ]. root addChild: label]. root layout: (GtGraphHorizontalTreeLayout new layered; verticalGap: 20). root With this we visualize the elements that make the chicken element demo: - we create a label for each element - we find the parentLabel corresponding to the parent element - we create an edge between the parentLabel and the current label The example gives us this: The edge is a constraint. It has no visual impact. And the graph layouts take the edge constraints into account. The cool thing is the GtGraphEdge is defined next to the graph layout classes, not in the core of Bloc. To add a visual impact, we have to create a separate line: Thanks for the question. This email is now a comment in the graph layout examples and can be viewed like this: Cheers, Doru > On Dec 9, 2017, at 8:43 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Super super cool. > > >> On 9 Dec 2017, at 08:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> We are happy to announce GT Mondrian, a graph visualization engine built on top of Bloc. >> >> It is similar to the original Mondrian and the Mondrian from Roassal, but it is different in that it is built directly out of Bloc elements. This is interesting because it allows us to combine typical widgets with visualizations. The other interesting thing about it is that it validates the design of Bloc: right now, the implementation has 509 lines of code (excluding graph-specific layouts). The goal is to make visualization a first class citizen and an integral part of the IDE. >> >> The key ingredient that made this happen is that Bloc can now treat graph layouts, such as tree or force based, behave under the same rules as typical widget layouts, such as grid or flow. The challenge comes from the fact that a graph layout depends on the notion of edges between elements, and we did not want to have elements know about edges in the core of Bloc. >> >> The solution was to split the typical edge implementation in graph visualization libraries into two distinct concepts: >> â¢ Line is an element that draws the connections. >> â¢ Edge defines constraints imposed by connections between elements. > > Can you give an example? > > BTW doru did you think about having a bloc layer on top of telescope model? > Because from that perspective telescope offers a visualisation model while roassal/mondrian like design are > more a pen-oriented metaphor. > > I wanted to do it to learn Bloc but Iâm running against time and trying to flush pilling duties (I want to also release > the book that we wrote with luc and olivier and convert the seaside book and and andâ¦.. :( > > > >> >> Thus, edges form constraints, and constraints are what layouts deal with. That is one reason why elements in bloc have the ability of defining layout-specific constraints. Using this, we can nicely define edges between elements as a plugin to Bloc, but still be able to connect arbitrary elements. What's more, it turns out that we need constraints for other layouts as well. For example, an element in a grid layout might specify the span. >> >> The API of GT Mondrian is similar to the one from Roassal, but there are a few differences as well. These are described in the Pillar documentation available in the GitHub repo. >> >> The best way to experience GT Mondrian and its documentation is to load the GToolkit as described here: >> https://github.com/feenkcom/gtoolkit >> >> If you download the GT code through Iceberg, the documentation can be experienced live by inspecting: >> './pharo-local/iceberg/feenkcom/gtoolkit-visualizer/doc/mondrian/index.pillar' asFileReference >> >> >> <mondrian-doc.png> >> >> >> >> >> >> Cheers, >> The feenk team >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Quality cannot be an afterthought." >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr > http://www.synectique.eu / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com "Every successful trip needs a suitable vehicle."

Dec. 9, 2017

Re: [Pharo-dev] Implementors of margins in GLMRubScrolledTextBrick

by Henrik-Nergaard

>>GLMRubScrolledTextBrick>>withoutMargins uses self margins: but I cannot find the method. This is because it is implemented in RubScrollTextMorph. GLMRubScrolledTextBrick implements #doesNotUnderstand: to send it to the rubric object. see: https://pharo.fogbugz.com/f/cases/17888/GLMRubScrolledTextBrick-relies-on-d… Best regards, Henrik -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 9, 2017

Implementors of margins in GLMRubScrolledTextBrick

by Stephane Ducasse

Hi I'm working on 16969 https://pharo.fogbugz.com/f/cases/16969/ which is basically cleaning the use of rectangle instead of using Margin. Now I'm surprised because GLMRubScrolledTextBrick>>withoutMargins uses self margins: but I cannot find the method. Did I misses something? I rewrote it as withoutMargins self margins: (0@0) asMargin but I'm still curious. Stef

Dec. 9, 2017