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

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

by Todd Blanchard

I think the asymmetry would drive me bananas. I prefer the original set. > On Sep 18, 2017, at 7:28 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > In this case, it would sound better to have: > - pinInMemory > - unpinFromMemory > - isPinnedInMemory > - setPinnedInMemory: > > Cheers, > Doru > > >> On Sep 14, 2017, at 10:17 AM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> Hello. >> >> I guess we are agree to rename. I will prepare pull request for Pharo. And Squeak is up to you. >> >> Here is the new messages: >> - pinInMemory >> - unpinInMemory >> - isPinnedInMemory >> - setPinnedInMemory: >> >> What was decision about #pinInMemoryDuring: ? Do we need it? >> >> 2017-09-14 9:28 GMT+02:00 H. Hirzel <hannes.hirzel(a)gmail.com <mailto:hannes.hirzel@gmail.com>>: >> +1 for pinInMemory >> >> It explains what it does. >> >> On 9/14/17, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > Hi Norbert, >> > >> >> On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >> >> >> >>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>> >> >>> Hi Denis, >> >>> >> >>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> >>> wrote: >> >>>> Hi Eliot. >> >>>> >> >>>> I know and I only talk about new messages. I am not trying to rethink >> >>>> full meta model of Smalltalk. >> >>>> By the way #class is very common message and it is handy to use short >> >>>> name. But pinning messages will be used rarely in very specific >> >>>> applications. So no much sense to preserve them in short version. >> >>> >> >>> Agreed. So we have to decide whether to go with pinInMemory or >> >>> pinObject, pinObject being suggested by Norbert because it matched >> >>> isReadOnlyObject. Personally I like pinInMemory. Norbert, do you feel >> >>> strongly about pinObject et al? >> >>> >> >> No I don't. It feels only good to me if there is a requirement not to >> >> implement selectors that are likely to be used in user code. I'm ok with >> >> pinInMemory although I asked myself where can it be pinned elsewhere if >> >> not in memory. So the suffix in memory doesn't add anything but also moves >> >> the selector out of user space. >> > >> > Well I think Denis' point is that pinInMemory removes ambiguity with pin for >> > other uses and I agree. So I for one am happy to change it to pinInMemory >> > et al. >> > >> >> >> >> Norbert >> >> >> >>>> >> >>>> 2017-09-12 18:05 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>>>> Hi Denis, >> >>>>> >> >>>>> >> >>>>>> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> >>>>>> wrote: >> >>>>>> >> >>>>>> I am really wonder guys. I thought you are not big funs of Object >> >>>>>> protocol. >> >>>>>> Current pinning messages are a new set of very generic messages in the >> >>>>>> Object. >> >>>>> >> >>>>> Yes, and that's because this is a fundamental property of all >> >>>>> non-immediate objects. Do you object to the #class message? Should it >> >>>>> be #classObject because it might conflict with #class used in an >> >>>>> educational or socioeconomic model? All objects other than immediates >> >>>>> can move. Pinning stops that movement. It applies generally. So the >> >>>>> protocol belongs in Object. >> >>>>> >> >>>>> >> >>>>>> >> >>>>>> About Norbert idea. >> >>>>>> - bePinnedObject is not bad convention. But I would prefer the memory >> >>>>>> suffix because it reflects the low level behaviour. >> >>>>>> >> >>>>>> 2017-09-11 14:16 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>>>>>> yes, me :) >> >>>>>>> >> >>>>>>> I do not see a reason to change them, tbh. >> >>>>>>> for me they are comprensible as they are now and it does not adds >> >>>>>>> more information pinInMemory or pinMemory. >> >>>>>>> >> >>>>>>> Esteban >> >>>>>>> >> >>>>>>> >> >>>>>>>> On 11 Sep 2017, at 11:56, Denis Kudriashov <dionisiydk(a)gmail.com> >> >>>>>>>> wrote: >> >>>>>>>> >> >>>>>>>> Anybody else? >> >>>>>>>> >> >>>>>>>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek >> >>>>>>>> <pavel.krivanek(a)gmail.com>: >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov >> >>>>>>>>> <dionisiydk(a)gmail.com>: >> >>>>>>>>>> Hi. >> >>>>>>>>>> >> >>>>>>>>>> We now have very generic message names: >> >>>>>>>>>> - pin >> >>>>>>>>>> - unpin >> >>>>>>>>>> - setPinned: >> >>>>>>>>>> - isPinned >> >>>>>>>>>> >> >>>>>>>>>> Problem that they collide with possible domain related names. >> >>>>>>>>>> For example I implemented pinning of tabs in Calypso and I found >> >>>>>>>>>> that I overrides #pin and #isPinned messages. Then I fix it with >> >>>>>>>>>> different names. >> >>>>>>>>>> Probably menus also uses pin word but without overrides >> >>>>>>>>>> >> >>>>>>>>>> What you think about renaming pinning messages? Something like: >> >>>>>>>>>> - pinMemory >> >>>>>>>>> >> >>>>>>>>> I would use pinInMemory >> >>>>>>>>> >> >>>>>>>>> -- Pavel >> >>>>>>>>> >> >>>>>>>>>> - unpinMemory >> >>>>>>>>>> - isMemoryPinned >> >>>>>>>>>> - setPinnedMemory: >> >>>>>>>>>> - pinMemoryDuring: (if we will introduce it) >> >>>>>>>>>> >> >>>>>>>>>> I think it is easy to do now because not much code uses pinning >> >>>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> _,,,^..^,,,_ >> >>> best, Eliot >> >> >> > >> >> > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > www.feenk.com > > "Every thing has its own flow." > > > > >

Sept. 18, 2017

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

by Tudor Girba

Hi, In this case, it would sound better to have: - pinInMemory - unpinFromMemory - isPinnedInMemory - setPinnedInMemory: Cheers, Doru > On Sep 14, 2017, at 10:17 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hello. > > I guess we are agree to rename. I will prepare pull request for Pharo. And Squeak is up to you. > > Here is the new messages: > - pinInMemory > - unpinInMemory > - isPinnedInMemory > - setPinnedInMemory: > > What was decision about #pinInMemoryDuring: ? Do we need it? > > 2017-09-14 9:28 GMT+02:00 H. Hirzel <hannes.hirzel(a)gmail.com>: > +1 for pinInMemory > > It explains what it does. > > On 9/14/17, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Norbert, > > > >> On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> > >> > >>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > >>> > >>> Hi Denis, > >>> > >>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > >>> wrote: > >>>> Hi Eliot. > >>>> > >>>> I know and I only talk about new messages. I am not trying to rethink > >>>> full meta model of Smalltalk. > >>>> By the way #class is very common message and it is handy to use short > >>>> name. But pinning messages will be used rarely in very specific > >>>> applications. So no much sense to preserve them in short version. > >>> > >>> Agreed. So we have to decide whether to go with pinInMemory or > >>> pinObject, pinObject being suggested by Norbert because it matched > >>> isReadOnlyObject. Personally I like pinInMemory. Norbert, do you feel > >>> strongly about pinObject et al? > >>> > >> No I don't. It feels only good to me if there is a requirement not to > >> implement selectors that are likely to be used in user code. I'm ok with > >> pinInMemory although I asked myself where can it be pinned elsewhere if > >> not in memory. So the suffix in memory doesn't add anything but also moves > >> the selector out of user space. > > > > Well I think Denis' point is that pinInMemory removes ambiguity with pin for > > other uses and I agree. So I for one am happy to change it to pinInMemory > > et al. > > > >> > >> Norbert > >> > >>>> > >>>> 2017-09-12 18:05 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >>>>> Hi Denis, > >>>>> > >>>>> > >>>>>> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > >>>>>> wrote: > >>>>>> > >>>>>> I am really wonder guys. I thought you are not big funs of Object > >>>>>> protocol. > >>>>>> Current pinning messages are a new set of very generic messages in the > >>>>>> Object. > >>>>> > >>>>> Yes, and that's because this is a fundamental property of all > >>>>> non-immediate objects. Do you object to the #class message? Should it > >>>>> be #classObject because it might conflict with #class used in an > >>>>> educational or socioeconomic model? All objects other than immediates > >>>>> can move. Pinning stops that movement. It applies generally. So the > >>>>> protocol belongs in Object. > >>>>> > >>>>> > >>>>>> > >>>>>> About Norbert idea. > >>>>>> - bePinnedObject is not bad convention. But I would prefer the memory > >>>>>> suffix because it reflects the low level behaviour. > >>>>>> > >>>>>> 2017-09-11 14:16 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >>>>>>> yes, me :) > >>>>>>> > >>>>>>> I do not see a reason to change them, tbh. > >>>>>>> for me they are comprensible as they are now and it does not adds > >>>>>>> more information pinInMemory or pinMemory. > >>>>>>> > >>>>>>> Esteban > >>>>>>> > >>>>>>> > >>>>>>>> On 11 Sep 2017, at 11:56, Denis Kudriashov <dionisiydk(a)gmail.com> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>> Anybody else? > >>>>>>>> > >>>>>>>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek > >>>>>>>> <pavel.krivanek(a)gmail.com>: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov > >>>>>>>>> <dionisiydk(a)gmail.com>: > >>>>>>>>>> Hi. > >>>>>>>>>> > >>>>>>>>>> We now have very generic message names: > >>>>>>>>>> - pin > >>>>>>>>>> - unpin > >>>>>>>>>> - setPinned: > >>>>>>>>>> - isPinned > >>>>>>>>>> > >>>>>>>>>> Problem that they collide with possible domain related names. > >>>>>>>>>> For example I implemented pinning of tabs in Calypso and I found > >>>>>>>>>> that I overrides #pin and #isPinned messages. Then I fix it with > >>>>>>>>>> different names. > >>>>>>>>>> Probably menus also uses pin word but without overrides > >>>>>>>>>> > >>>>>>>>>> What you think about renaming pinning messages? Something like: > >>>>>>>>>> - pinMemory > >>>>>>>>> > >>>>>>>>> I would use pinInMemory > >>>>>>>>> > >>>>>>>>> -- Pavel > >>>>>>>>> > >>>>>>>>>> - unpinMemory > >>>>>>>>>> - isMemoryPinned > >>>>>>>>>> - setPinnedMemory: > >>>>>>>>>> - pinMemoryDuring: (if we will introduce it) > >>>>>>>>>> > >>>>>>>>>> I think it is easy to do now because not much code uses pinning > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> _,,,^..^,,,_ > >>> best, Eliot > >> > > > > -- www.tudorgirba.com www.feenk.com "Every thing has its own flow."

Sept. 18, 2017

[Pharo 7.0-dev] Build #128: SUCCESS

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

There is a new Pharo build available! The status of the build #128 was: SUCCESS. Could not extract further issue information from commit message: Merge pull request #287 from pavel-krivanek/20428-ClassTest-Kernel-Tests-is-dependent-on-System-Changes 20428-ClassTest-Kernel-Tests-is-dependent-on-System-Changes Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 18, 2017

About a discord channel for the mooc?

by Stephane Ducasse

Hi guys The students of the lectures at Prague and the forthcoming mooc will be strongly suggested to use discord. So now how can we organise it? How do we create a channel? Stef

Sept. 18, 2017

Re: [Pharo-dev] [Calypso] Toolbar and Statusbar Look - voting time

by Mariano Martinez Peck

On Thu, Sep 14, 2017 at 4:29 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > "Denis Kudriashov" wrote > >Thank's guys for comments. And thank's Torsten for this initiative. I > will merge your changes soon. > > No - we have to thank you. For Calypso, for accepting the community > decision and (in advance) for > merging the first Calypso pull request. > > +1. I am already enjoying it since a couple of months and Denis was also quick to incorporate my suggestions :) BTW, RIGHT, of course. > I'm pretty sure the next Pharo versions will rock even more ... > > Bye > T. > > -- Mariano http://marianopeck.wordpress.com

Sept. 18, 2017

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

by Denis Kudriashov

I did pull request for issue 20426 <https://pharo.fogbugz.com/f/cases/20426/Better-pin-messages>. Interesting that Iceberg uses pinning in couple of places. I not touch it because it would not be single commit. And I have no idea how contribute in that case. I thing we are still in process to decide it. Anyway old messages are deprecated and users will continue work with auto transformation. 2017-09-14 17:27 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > On Sep 14, 2017, at 7:07 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > Am 14.09.2017 um 10:17 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > > Hello. > > I guess we are agree to rename. I will prepare pull request for Pharo. And > Squeak is up to you. > > Here is the new messages: > - pinInMemory > - unpinInMemory > - isPinnedInMemory > - setPinnedInMemory: > > What was decision about #pinInMemoryDuring: ? Do we need it? > > I understand Eliot in a way that there is no real point in unpinning > objects. Hence pinDuring: is basically never useful and therefor adding a > selectir has rather a negative impact > > > +1 > > > Norbert > > 2017-09-14 9:28 GMT+02:00 H. Hirzel <hannes.hirzel(a)gmail.com>: > >> +1 for pinInMemory >> >> It explains what it does. >> >> On 9/14/17, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > Hi Norbert, >> > >> >> On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >> >> >> >>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda(a)gmail.com >> >: >> >>> >> >>> Hi Denis, >> >>> >> >>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov < >> dionisiydk(a)gmail.com> >> >>> wrote: >> >>>> Hi Eliot. >> >>>> >> >>>> I know and I only talk about new messages. I am not trying to rethink >> >>>> full meta model of Smalltalk. >> >>>> By the way #class is very common message and it is handy to use short >> >>>> name. But pinning messages will be used rarely in very specific >> >>>> applications. So no much sense to preserve them in short version. >> >>> >> >>> Agreed. So we have to decide whether to go with pinInMemory or >> >>> pinObject, pinObject being suggested by Norbert because it matched >> >>> isReadOnlyObject. Personally I like pinInMemory. Norbert, do you >> feel >> >>> strongly about pinObject et al? >> >>> >> >> No I don't. It feels only good to me if there is a requirement not to >> >> implement selectors that are likely to be used in user code. I'm ok >> with >> >> pinInMemory although I asked myself where can it be pinned elsewhere if >> >> not in memory. So the suffix in memory doesn't add anything but also >> moves >> >> the selector out of user space. >> > >> > Well I think Denis' point is that pinInMemory removes ambiguity with >> pin for >> > other uses and I agree. So I for one am happy to change it to >> pinInMemory >> > et al. >> > >> >> >> >> Norbert >> >> >> >>>> >> >>>> 2017-09-12 18:05 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>>>> Hi Denis, >> >>>>> >> >>>>> >> >>>>>> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov < >> dionisiydk(a)gmail.com> >> >>>>>> wrote: >> >>>>>> >> >>>>>> I am really wonder guys. I thought you are not big funs of Object >> >>>>>> protocol. >> >>>>>> Current pinning messages are a new set of very generic messages in >> the >> >>>>>> Object. >> >>>>> >> >>>>> Yes, and that's because this is a fundamental property of all >> >>>>> non-immediate objects. Do you object to the #class message? >> Should it >> >>>>> be #classObject because it might conflict with #class used in an >> >>>>> educational or socioeconomic model? All objects other than >> immediates >> >>>>> can move. Pinning stops that movement. It applies generally. So >> the >> >>>>> protocol belongs in Object. >> >>>>> >> >>>>> >> >>>>>> >> >>>>>> About Norbert idea. >> >>>>>> - bePinnedObject is not bad convention. But I would prefer the >> memory >> >>>>>> suffix because it reflects the low level behaviour. >> >>>>>> >> >>>>>> 2017-09-11 14:16 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com >> >: >> >>>>>>> yes, me :) >> >>>>>>> >> >>>>>>> I do not see a reason to change them, tbh. >> >>>>>>> for me they are comprensible as they are now and it does not adds >> >>>>>>> more information pinInMemory or pinMemory. >> >>>>>>> >> >>>>>>> Esteban >> >>>>>>> >> >>>>>>> >> >>>>>>>> On 11 Sep 2017, at 11:56, Denis Kudriashov <dionisiydk(a)gmail.com >> > >> >>>>>>>> wrote: >> >>>>>>>> >> >>>>>>>> Anybody else? >> >>>>>>>> >> >>>>>>>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek >> >>>>>>>> <pavel.krivanek(a)gmail.com>: >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov >> >>>>>>>>> <dionisiydk(a)gmail.com>: >> >>>>>>>>>> Hi. >> >>>>>>>>>> >> >>>>>>>>>> We now have very generic message names: >> >>>>>>>>>> - pin >> >>>>>>>>>> - unpin >> >>>>>>>>>> - setPinned: >> >>>>>>>>>> - isPinned >> >>>>>>>>>> >> >>>>>>>>>> Problem that they collide with possible domain related names. >> >>>>>>>>>> For example I implemented pinning of tabs in Calypso and I >> found >> >>>>>>>>>> that I overrides #pin and #isPinned messages. Then I fix it >> with >> >>>>>>>>>> different names. >> >>>>>>>>>> Probably menus also uses pin word but without overrides >> >>>>>>>>>> >> >>>>>>>>>> What you think about renaming pinning messages? Something like: >> >>>>>>>>>> - pinMemory >> >>>>>>>>> >> >>>>>>>>> I would use pinInMemory >> >>>>>>>>> >> >>>>>>>>> -- Pavel >> >>>>>>>>> >> >>>>>>>>>> - unpinMemory >> >>>>>>>>>> - isMemoryPinned >> >>>>>>>>>> - setPinnedMemory: >> >>>>>>>>>> - pinMemoryDuring: (if we will introduce it) >> >>>>>>>>>> >> >>>>>>>>>> I think it is easy to do now because not much code uses pinning >> >>>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> _,,,^..^,,,_ >> >>> best, Eliot >> >> >> > >> >> >

Sept. 18, 2017

Re: [Pharo-dev] Esteban's ChangeLog week of 11 September 2017

by Denis Kudriashov

> > But well... I'm happy to say that we have a Pharo 7.0 running 100% on > headless mode with an SDL2 window > serving the world, on macOS 32bits. This is super cool. Interesting what the size of VM in that case? 2017-09-18 8:00 GMT+02:00 <estebanlm(a)gmail.com>: > Hello! > > This is my weekly ChangeLog, from 11 September 2017 to 17 September 2017. > You can see it in a better format by going here: > http://log.smallworks.eu/web/search?from=11/9/2017&to=17/9/2017 > > ChangeLog > ========= > > 14 September 2017: > ------------------ > > * Since Ronie came to spend two weeks with us, I made a "stop the > world" call to work with him in a couple > of projects I want to integrate in Pharo. > > So, I've been working on that last two days: Ronie has a working > implementation of a "real headless" > VM that can chose to start a world using SDL2. > > Why we want this? Because of many reasons... one of them is because is > lame to open a hidden window when > we want to use just a command line, but also because the desition of > opening a window (the World or > whatever) should be responsibility of the image (the user), not the VM. > > Anyway, the problem is that Ronie made his VM using CMake and we use > plain Makefiles (a very complex > structure of makefiles), so we needed to convert that. > > Also, since this is experimental, a lot ot small details are missing > and we are running to supply them. > > But well... I'm happy to say that we have a Pharo 7.0 running 100% on > headless mode with an SDL2 window > serving the world, on macOS 32bits. > > Tomorrow we will look to fix some remaining details and to expand the > source to linux and windows (32bits), > then we will jump to 64bits. > > > 11 September 2017: > ------------------ > > * I just released [iceberg v0.5.8](https://github.com/ > pharo-vcs/iceberg/releases/tag/v0.5.8). > > This version is a maintenance version, and contains this fixes: > > * speed up of commits by not traversing the full tree to detect staged > files (just compare later) > * fix refresh option in PR tool > * do not use hardcoded colours in diffs > * add guessing of source dirs to easy adding of local repositories > * recategorise methods > > It will be integrated on Pharo 7.0 in on [case: 20406]( > https://pharo.fogbugz.com/f/cases/20406) > > * Last week I was at ESUG :) > > Anyway, I'm working on [tonel](http://github.com/pharo-vcs/tonel), > the new fileformat made to replace > [filetree](http://github.com/pharo-vcs/filetree) (because of many > reasons, being the non-scalable nature of > file-per-method strategy the most important). > > > cheers! > Esteban > >

Sept. 18, 2017

Re: [Pharo-dev] slow Pharo downloading and Travis

by Marcus Denker

> On 16 Sep 2017, at 09:40, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi marcus > > I do not see why they could not find it. > Can you tell me how you ask because we should reask? > > I spend a ticket and they wanted to close it last week. I have told them to not close it I will forward the mails to you. Marcus

Sept. 18, 2017

Esteban's ChangeLog week of 11 September 2017

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 11 September 2017 to 17 September 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=11/9/2017&to=17/9/2017 ChangeLog ========= 14 September 2017: ------------------ * Since Ronie came to spend two weeks with us, I made a "stop the world" call to work with him in a couple of projects I want to integrate in Pharo. So, I've been working on that last two days: Ronie has a working implementation of a "real headless" VM that can chose to start a world using SDL2. Why we want this? Because of many reasons... one of them is because is lame to open a hidden window when we want to use just a command line, but also because the desition of opening a window (the World or whatever) should be responsibility of the image (the user), not the VM. Anyway, the problem is that Ronie made his VM using CMake and we use plain Makefiles (a very complex structure of makefiles), so we needed to convert that. Also, since this is experimental, a lot ot small details are missing and we are running to supply them. But well... I'm happy to say that we have a Pharo 7.0 running 100% on headless mode with an SDL2 window serving the world, on macOS 32bits. Tomorrow we will look to fix some remaining details and to expand the source to linux and windows (32bits), then we will jump to 64bits. 11 September 2017: ------------------ * I just released [iceberg v0.5.8](https://github.com/pharo-vcs/iceberg/releases/tag/v0.5.8). This version is a maintenance version, and contains this fixes: * speed up of commits by not traversing the full tree to detect staged files (just compare later) * fix refresh option in PR tool * do not use hardcoded colours in diffs * add guessing of source dirs to easy adding of local repositories * recategorise methods It will be integrated on Pharo 7.0 in on [case: 20406](https://pharo.fogbugz.com/f/cases/20406). * Last week I was at ESUG :) Anyway, I'm working on [tonel](http://github.com/pharo-vcs/tonel), the new fileformat made to replace [filetree](http://github.com/pharo-vcs/filetree) (because of many reasons, being the non-scalable nature of file-per-method strategy the most important). cheers! Esteban

Sept. 18, 2017

Re: [Pharo-dev] [Pharo 70] Log of integration

by Tudor Girba

Pharo 7.0 is shaping up to be very exciting, indeed! Doru > On Sep 8, 2017, at 6:36 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Because I do not know how to do it :) > But it will come. > Pharo70 is exciting. > > > > On Fri, Sep 8, 2017 at 6:33 PM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: >> >> On ven. 8 sept. 2017 at 18:30, Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >>> >>> Waiting for an automated way :) >>> >>> Remove SmalllintManifestCheckerTest(class)>>DoIt >>> >>> https://pharo.fogbugz.com/f/cases/20398 >>> >>> >>> Uncategorized methods in SystemVersionTest, SystemProgressMorph, >>> SugsWatchpointSuggestion, SugsSuggestionSwapMethodTest, SugsNau >>> >>> https://pharo.fogbugz.com/f/cases/20385 >>> >>> >>> add Gt and Github support to minimal image >>> >>> https://pharo.fogbugz.com/f/cases/20389 >>> >>> >>> Uncategorized methods in TextKern, TextSelectionColor, TextURL >>> >>> https://pharo.fogbugz.com/f/cases/20386 >>> >>> >>> Enforce Proper method categorization - Part 1 - SUnit >>> >>> https://pharo.fogbugz.com/f/cases/20390 >>> >>> >>> Use Pharo.org instead of disney >>> >>> https://pharo.fogbugz.com/f/cases/20392 >>> >>> >>> Uncategorized methods in WorldMenuHelp,WeakValueAssociation, >>> WeakOrderedCollectionTest, WeakOrderedCollection, WeakMessageSendTe >>> >>> https://pharo.fogbugz.com/f/cases/20380 >>> >>> >>> Pharo 7 Help should already use Pharo 7 instead of 6 and show some >>> first highlights >>> >>> https://pharo.fogbugz.com/f/cases/20364 >>> >>> >>> Categorize methods in UserOfFooSharedPool, UnusedVariable, >>> UnlimitedInstanceVariableSlotTest, UnknownSelector, UndefinedVariable >>> >>> https://pharo.fogbugz.com/f/cases/20382 >>> >>> >>> Categorize methods in TabLabelMorph, TaskbarTask, TermInfoCharacter, >>> TestAutoFractionComputation, TextClassLink, TextComposer, T >>> >>> https://pharo.fogbugz.com/f/cases/20383 >>> >>> >>> Uncategorized methods in VSUnloadUnit and VMWindowDriver >>> >>> https://pharo.fogbugz.com/f/cases/20381 >>> >>> >>> Uncategorized methods in ZipStringMember, ZipStore, ZipFileMember, >>> ZipDirectoryMember >>> >>> https://pharo.fogbugz.com/f/cases/20379 >>> >>> >>> MailMessage API Improvement >>> >>> https://pharo.fogbugz.com/f/cases/19697 >>> >>> >>> Add Retry of tests in CI >>> >>> https://pharo.fogbugz.com/f/cases/20371 >>> >>> >>> Categorize methods in RubNotificationStrategy >>> >>> https://pharo.fogbugz.com/f/cases/20378/ >>> >>> >>> free and beNull missing methods in referenced structures >>> >>> https://pharo.fogbugz.com/f/cases/20361 >>> >>> >>> New warning text color is not readable on white theme >>> >>> https://pharo.fogbugz.com/f/cases/20357 >>> >>> >>> deprecated call in QANautilusPluginMorph>>#displayCritique: >>> >>> https://pharo.fogbugz.com/f/cases/20359 >>> >>> >>> RecursionStopper methods not categorized >>> >>> https://pharo.fogbugz.com/f/cases/20376 >>> >>> >>> Categorize method in PharoShortcuts >>> >>> https://pharo.fogbugz.com/f/cases/20377 >>> >>> >>> Uncategorized methods in CP1253TextConverter, CairoPNGPaint, >>> CairoScaledFont, CheckboxButtonMorph, CheckboxMorph, CheckboxMorph, >>> >>> https://pharo.fogbugz.com/f/cases/20394 >>> >>> >>> Uncategorized methods in DummyUIManager, DropListMorph class, >>> DropListMorph, DoesNotUnderstandDebugAction, DockingBarMenuMorph >>> >>> https://pharo.fogbugz.com/f/cases/20395 >>> >>> >>> Move SymbolicBytecode>># and hash from package "GT-BytecodeDebugger" >>> into "Kernel" >>> >>> https://pharo.fogbugz.com/f/cases/20393 >>> >>> >>> [ Pharo 70] Senders-of-String---isLegalInstVarName-isLegalClassName- >>> >>> https://github.com/pharo-project/pharo/pull/226 >>> >>> [ Pharo 70] Categorize methods in AnnouncementLogger #240 >>> >>> https://github.com/pharo-project/pharo/pull/240 >>> >>> >>> [ Pharo 70 ] Build 83 PR 236 introduce-at-at-in-dictionary >>> >>> https://github.com/pharo-project/pharo/pull/236 >>> >>> https://pharo.fogbugz.com/f/cases/20203/ >>> >>> >>> [ Pharo 70 ] Build XX PR 236 >>> free-and-beNull-missing-methods-in-referenced-structures >>> >>> https://github.com/pharo-project/pharo/pull/236 >>> >>> https://pharo.fogbugz.com/f/cases/20361 >>> >>> >>> [ Pharo 70 ] Build XX PR 233 cleanup #isMorphicModel >>> >>> https://pharo.fogbugz.com/f/cases/resolve/20175 >>> >>> https://github.com/pharo-project/pharo/pull/233 >>> >>> >>> â¦ lots not recorded, build is at 79. >>> >>> >>> [ Pharo 70 ] Build 69 PR 225 20350-include 32-bit sources in the >>> 64-bit Pharo archive >>> >>> https://github.com/pharo-project/pharo/pull/225 >>> >>> https://pharo.fogbugz.com/f/cases/20350 >>> >>> >>> [ Pharo 70 ] Build 66 PR 223 >>> 20348-testWideStringClassName-needs-to-be-unmarked-as-expected-failure >>> >>> https://github.com/pharo-project/pharo/pull/223 >>> >>> https://pharo.fogbugz.com/f/cases/20348 >> >> >> Why not use the newly produced image to send a mail via Zodiac with the >> infos? :) >>> >>> >> -- >> Cyril Ferlicot >> https://ferlicot.fr >> >> http://www.synectique.eu >> 2 rue Jacques PrÃ©vert 01, >> 59650 Villeneuve d'ascq France > -- www.tudorgirba.com www.feenk.com "There are no old things, there are only old ways of looking at them."

Sept. 18, 2017