- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo70 alpha] Store settings raise a DNU primFlush

by Stephane Ducasse

Thanks guy. I was dead tired. Did not have the energy to look went to sleep. On Fri, Apr 13, 2018 at 10:44 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 13 Apr 2018, at 22:26, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> Hi Stef & Sven, >> >> On 13 April 2018 at 20:38, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> Hi >>> >>> I do not know if this is related to the OldStreamCleaningEffort but >>> when I press store settings in the Settings browser I get a primitive >>> failed. >>> >>> https://pharo.fogbugz.com/f/cases/21699/Store-settings-raise-a-DNU-primFlush >> >> >> This is because the stream created in >> SystemSettingsPersistence>>storeExactStoredSettings: is closed twice, >> first in SettingsStonWriter>>store and then in >> SystemSettingsPersistence>>storeExactStoredSettings:. >> >> Previous versions of file streams have allowed the stream #close to be >> called multiple times, however ZnBufferedReadWriteStream doesn't allow >> this. >> >> I think that since an already open stream is handed to >> SettingsStonWriter, it shouldn't be closing the stream. That will >> resolve this particular problem. >> >> It can also be argued that ZnBufferedReadWriteStream and co. should >> allow streams to be closed multiple times for backward compatibility. >> Sven? > > Yes, OK, making #close idempotent is good. If we add #closed to ZnBufferedReadStream we can add a > > self closed ifFalse: [ .. ] > > guard in #close. > >> Cheers, >> Alistair >> > >

April 14, 2018

Re: [Pharo-dev] [Pharo-users] [TechTalk] April 12: GIT with Iceberg

by Ben Coman

On 14 April 2018 at 01:55, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > On Fri, Apr 13, 2018 at 7:34 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> >> >> On 14 April 2018 at 01:10, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> >>> >>> >>> On Fri, Apr 13, 2018 at 5:57 PM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>>> >>>> >>>> On 13 April 2018 at 23:15, Alistair Grant <akgrant0710(a)gmail.com> >>>> wrote: >>>> >>>>> On 13 April 2018 at 17:07, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> >>>>> wrote: >>>>> > >>>>> > >>>>> > On ven. 13 avr. 2018 at 17:03, Guillermo Polito < >>>>> guillermopolito(a)gmail.com> wrote: >>>>> >> >>>>> >> >>>>> >> The thing is that the best way to do it is to clone your own >>>>> fork... And each one has her/his one. >>>>> >>>> >>>> I know, but momentarily forgot while trying to work on my first Issue >>>> with the new UI. >>>> However I discovered something cool... >>>> >>>> I had directly cloned "git@github.com:pharo-project/pharo.git" >>>> successfully brought that "Up to date" >>>> then in the "Working copy of pharo" window, clicked <New Issue> and >>>> filled in details, >>>> made my code change, >>>> then clicked <Commit> >>>> then clicked <Push> bringing me to a window titled "Push >>>> pharo/21686-.../21686..." >>>> where the only option to "Push to remote: " was "origin >>>> (git@github.com:pharo-project/pharo.git)" >>>> and clicking <Push> of course produced an error "LGit_GIT_EEOF: ERROR: >>>> Permission to pharo-project/pharo.git denied to bencoman." >>>> Fair enough! >>>> >>> >>> Have to gracefully manage that error. Could you open an issue? >>> >>> >>>> >>>> But then...!!! >>>> Back in the "Repositories" window, >>>> "pharo" > right-click > Repository > Add Remote >>>> Remote name = bencoman >>>> Remote URL = git@github.com:pharo-project/pharo.git >>>> And back in the "Working copy of pharo" window >>>> clicked <Push> bringing again me to a window titled "Push >>>> pharo/21686-.../21686..." >>>> but now I had an extra option "bencoman <git@github.com:bencoman/pharo >>>> .git>" >>>> and selecting that and clicking <Push> worked!!!! >>>> >>>> https://github.com/bencoman/pharo/tree/21686-Setting-backgro >>>> und-images-doesnt-work-on-Pharo-70 >>>> >>> >>> Esteban is working on adding the add remote to the pull/push windows >>> >>> https://github.com/pharo-vcs/iceberg/issues/624 >>> >>> so you will have less clicks to do there ;) >>> >>> >>>> >>>> >>>> Now the key thing here is that I **didn't** have to first >>>> synchronise github.com:bencoman/pharo.git with github.com: >>>> pharo-project/pharo.git >>>> and remember to clone github.com: bencoman/pharo.git . >>>> I just pushed to my repo **after-the-fact**. >>>> >>>> I haven't submitted many fixes lately to get familiar with Iceberg, >>>> and maybe I missed something in the old workflow, >>>> but previously it seemed that my pharo github repo needed to be up to >>>> date, >>>> and I must clone from there. >>>> >>> >>> Well, it depends. >>> >>> Scenario 1) If you're not planning to reuse your clone, you don't need >>> to care about synchronize. >>> - just reclone pharo from pharo >>> - add your fork as remote >>> - you're set >>> >>> Scenario 2) If you want to reuse your clone you may not synchronize them. >>> - pull from pharo from time to time >>> - start a new branch from the current commit >>> - you're set >>> >>> But then, there is people that may want/need to have some other >>> workflow. For example: >>> - I start from scenario 1 >>> - make a branch >>> - commit some work >>> - tomorrow I come back and I download a new image >>> * a couple of integrations may have happened in between!! >>> * but I want to continue working in my branch >>> >>> Then the scenario could be solved as: >>> - fetch from pharo >>> - if you're in detached mode, just use the merge image into branch >>> action and select your branch >>> - or if you want to do it manually: >>> - checkout your branch in your image without loading packages >>> - merge pharo/development into your branch >>> - continue working >>> >>> Now, what I would like is that we detect such "common rough scenarios" >>> and discuss how we could have a better UI support for them. >>> Maybe we need as a part of the Pharo plugin a wizard that takes you >>> through the "synchronize my image again please"? >>> Or could it be solved with some strategy that is general enough to be >>> reused in any repository? >>> >>> >>>> >>>> The new UI is intuitive and made it east to clone from pharo-project, >>>> make fix the push to bencoman. >>>> I worked this out from just a small bit of trial & error. >>>> >>>> >>>> One request... >>>> In attached snapshot where the remotes show "origin", >>>> please consider showing that as "pharo-project" >>>> The term "origin" is useful for generic documentation and for examples, >>>> but there is *nothing* special about that label from a git perspective. >>>> A remote is a remote is a remote. >>>> >>> >>> Well that's mostly a libgit thing. It does it by default I think when >>> you clone, and I'm pretty sure that a lot of people would be against >>> breaking such default because that's how git works also. >>> >> >> Its not "the" way git works. Its just the "default". >> Any name can be used to refer to the upstream repo. >> i.e... >> --origin <name> >> Instead of using the remote name origin to keep track of the >> upstream repository, use <name>. >> https://git-scm.com/docs/git-clone >> > > I know it's the default name git gives by default :). But changing that > may confuse people that are used to git also... > So I'm just thinking what would be the less surprising thing for most of > the people > > https://en.wikipedia.org/wiki/Principle_of_least_astonishment > I agree with the principle. btw its really nice how easy it is to choose which remote to push to. cheers -ben

April 14, 2018

Re: [Pharo-dev] Change Pharo window icon

by Eliot Miranda

On Fri, Apr 13, 2018 at 4:45 PM, <Vincent.Blondeau(a)lamresearch.com> wrote: > Hi, > > > > In the way to change dynamically the icon of the main window, I am adding > a primitive in the HostWindow VM Plugin. > > So, I implemented the primitive call on Pharo side: > https://github.com/pharo-project/pharo/pull/1198 > > Modified the C plugin file: https://github.com/ > OpenSmalltalk/opensmalltalk-vm/pull/248 (only the windows version for now) > > And implemented the binding in VMMaker, and I would commit this last one. > > However, I do not have the write access to http://source.squeak.org/ > VMMaker. Could someone grant me to it? > OK, you're now added to the committer list using your source.squeak.org credentials. > > > Thanks in advance, > > Vincent > > > > *From:* Blondeau, Vincent > *Sent:* Tuesday, February 6, 2018 18:36 > *To:* Pharo Development List <pharo-dev(a)lists.pharo.org> > *Subject:* RE: [Pharo-dev] Change Pharo window icon > > > > Hi, > > > > The fact that he mentioned an ability to change window's title from inside > of the running image suggested me that he actually wants to change an icon > at runtime too. > > > > Indeed, that is what I would like to do. > > > > Cheers, > > Vincent > > > > *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org > <pharo-dev-bounces(a)lists.pharo.org>] *On Behalf Of *Aliaksei Syrel > *Sent:* Saturday, February 3, 2018 8:09 > *To:* Pharo Development List <pharo-dev(a)lists.pharo.org> > *Subject:* Re: [Pharo-dev] Change Pharo window icon > > > > Hi Eliot, > > > > I thought Vincent wants to change Pharo main window icon (image). > > I would like to know how to change the main Pharo window icon. > > > > The fact that he mentioned an ability to change window's title from inside > of the running image suggested me that he actually wants to change an icon > at runtime too. > > DisplayScreen class >> primitiveWindowTitle:string: > > > > I may be wrong :) But in any case it would be nice to be able to change > window icon from the image. > > > Cheers, > > Alex > > > > On 3 February 2018 at 17:01, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > Hi Aliaksei, > > On Feb 3, 2018, at 4:30 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hi > > > > Since Pharo uses sdl2 (or should use) > > https://wiki.libsdl.org/SDL_SetWindowIcon > <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.libsdl.org_SDL-5F…> > > > > Hang on. Changing a window's icon is not at all the same as changing the > VM's icon. Which are we talking about here? I thought we were talking > about changing the VM icon. > > > > > > Alex > > > > > -- _,,,^..^,,,_ best, Eliot

April 14, 2018

Re: [Pharo-dev] Change Pharo window icon

by Vincent.Blondeau＠lamresearch.com

Hi, In the way to change dynamically the icon of the main window, I am adding a primitive in the HostWindow VM Plugin. So, I implemented the primitive call on Pharo side: https://github.com/pharo-project/pharo/pull/1198 Modified the C plugin file: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/248 (only the windows version for now) And implemented the binding in VMMaker, and I would commit this last one. However, I do not have the write access to http://source.squeak.org/VMMaker. Could someone grant me to it? Thanks in advance, Vincent From: Blondeau, Vincent Sent: Tuesday, February 6, 2018 18:36 To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: RE: [Pharo-dev] Change Pharo window icon Hi, The fact that he mentioned an ability to change window's title from inside of the running image suggested me that he actually wants to change an icon at runtime too. Indeed, that is what I would like to do. Cheers, Vincent From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Aliaksei Syrel Sent: Saturday, February 3, 2018 8:09 To: Pharo Development List <pharo-dev(a)lists.pharo.org<mailto:pharo-dev@lists.pharo.org>> Subject: Re: [Pharo-dev] Change Pharo window icon Hi Eliot, I thought Vincent wants to change Pharo main window icon (image). I would like to know how to change the main Pharo window icon. The fact that he mentioned an ability to change window's title from inside of the running image suggested me that he actually wants to change an icon at runtime too. DisplayScreen class >> primitiveWindowTitle:string: I may be wrong :) But in any case it would be nice to be able to change window icon from the image. Cheers, Alex On 3 February 2018 at 17:01, Eliot Miranda <eliot.miranda(a)gmail.com<mailto:eliot.miranda@gmail.com>> wrote: Hi Aliaksei, On Feb 3, 2018, at 4:30 AM, Aliaksei Syrel <alex.syrel(a)gmail.com<mailto:alex.syrel@gmail.com>> wrote: Hi Since Pharo uses sdl2 (or should use) https://wiki.libsdl.org/SDL_SetWindowIcon<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.libsdl.org_SDL-5F…> Hang on. Changing a window's icon is not at all the same as changing the VM's icon. Which are we talking about here? I thought we were talking about changing the VM icon. Alex

April 13, 2018

Re: [Pharo-dev] [Pharo70 alpha] Store settings raise a DNU primFlush

by Sven Van Caekenberghe

> On 13 Apr 2018, at 22:26, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Stef & Sven, > > On 13 April 2018 at 20:38, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> Hi >> >> I do not know if this is related to the OldStreamCleaningEffort but >> when I press store settings in the Settings browser I get a primitive >> failed. >> >> https://pharo.fogbugz.com/f/cases/21699/Store-settings-raise-a-DNU-primFlush > > > This is because the stream created in > SystemSettingsPersistence>>storeExactStoredSettings: is closed twice, > first in SettingsStonWriter>>store and then in > SystemSettingsPersistence>>storeExactStoredSettings:. > > Previous versions of file streams have allowed the stream #close to be > called multiple times, however ZnBufferedReadWriteStream doesn't allow > this. > > I think that since an already open stream is handed to > SettingsStonWriter, it shouldn't be closing the stream. That will > resolve this particular problem. > > It can also be argued that ZnBufferedReadWriteStream and co. should > allow streams to be closed multiple times for backward compatibility. > Sven? Yes, OK, making #close idempotent is good. If we add #closed to ZnBufferedReadStream we can add a self closed ifFalse: [ .. ] guard in #close. > Cheers, > Alistair >

April 13, 2018

Re: [Pharo-dev] [Pharo70 alpha] Store settings raise a DNU primFlush

by Alistair Grant

Hi Stef & Sven, On 13 April 2018 at 20:38, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi > > I do not know if this is related to the OldStreamCleaningEffort but > when I press store settings in the Settings browser I get a primitive > failed. > > https://pharo.fogbugz.com/f/cases/21699/Store-settings-raise-a-DNU-primFlush This is because the stream created in SystemSettingsPersistence>>storeExactStoredSettings: is closed twice, first in SettingsStonWriter>>store and then in SystemSettingsPersistence>>storeExactStoredSettings:. Previous versions of file streams have allowed the stream #close to be called multiple times, however ZnBufferedReadWriteStream doesn't allow this. I think that since an already open stream is handed to SettingsStonWriter, it shouldn't be closing the stream. That will resolve this particular problem. It can also be argued that ZnBufferedReadWriteStream and co. should allow streams to be closed multiple times for backward compatibility. Sven? Cheers, Alistair

April 13, 2018

Re: [Pharo-dev] Iceberg2.0 crash test passed :)

by Serge Stinckwich

On Fri, Apr 13, 2018 at 8:54 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 13 Apr 2018, at 21:43, Serge Stinckwich <serge.stinckwich(a)gmail.com> > wrote: > > Yes I was able to commit also. > Very slick interface :-) > > > But now, every time I want to commit, my image crash and I have: > > Assertion failed: (git_atomic_get(&git__n_inits) > 0), function > git__global_state, file /Users/travis/build/OpenSmalltalk/opensmalltalk- > vm/build.macos64x64/pharo.cog.spur/build/third-party/libgit2-0.25.1/src/global.c, > line 322. > > > there is a current bug on initialisation (no idea why, still > investigating). > > this is fixed by executing: > > LGitLibrary initialize. > > âThank you Esteban, you save my time :-) â âApparently this crash happens after I relaunch my image with Iceberg running.â -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

April 13, 2018

Re: [Pharo-dev] Iceberg2.0 crash test passed :)

by Esteban Lorenzano

> On 13 Apr 2018, at 21:43, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > Yes I was able to commit also. > Very slick interface :-) > > > But now, every time I want to commit, my image crash and I have: > > Assertion failed: (git_atomic_get(&git__n_inits) > 0), function git__global_state, file /Users/travis/build/OpenSmalltalk/opensmalltalk-vm/build.macos64x64/pharo.cog.spur/build/third-party/libgit2-0.25.1/src/global.c, line 322. there is a current bug on initialisation (no idea why, still investigating). this is fixed by executing: LGitLibrary initialize. cheers! Esteban > > > On Fri, Apr 13, 2018 at 8:02 PM, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: > I could commit my first commit with iceberg 2.0 > Well done > > It feels nicer :). > > Stef > > > > > -- > Serge Stinckwich > UMI UMMISCO 209 (SU/IRD/UY1) > "Programs must be written for people to read, and only incidentally for machines to execute." > http://www.doesnotunderstand.org/ <http://www.doesnotunderstand.org/>

April 13, 2018

Re: [Pharo-dev] Iceberg2.0 crash test passed :)

by Serge Stinckwich

Yes Pharo 7.0, latest VM 64 bits On Fri, Apr 13, 2018 at 8:46 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Is that Pharo 7? > > On Fri, Apr 13, 2018 at 9:43 PM, Serge Stinckwich < > serge.stinckwich(a)gmail.com> wrote: > >> Yes I was able to commit also. >> Very slick interface :-) >> >> >> But now, every time I want to commit, my image crash and I have: >> >> Assertion failed: (git_atomic_get(&git__n_inits) > 0), function >> git__global_state, file /Users/travis/build/OpenSmallt >> alk/opensmalltalk-vm/build.macos64x64/pharo.cog.spur/ >> build/third-party/libgit2-0.25.1/src/global.c, line 322. >> >> >> On Fri, Apr 13, 2018 at 8:02 PM, Stephane Ducasse < >> stepharo.self(a)gmail.com> wrote: >> >>> I could commit my first commit with iceberg 2.0 >>> Well done >>> >>> It feels nicer :). >>> >>> Stef >>> >>> >> >> >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (SU/IRD/UY1) >> "Programs must be written for people to read, and only incidentally for >> machines to execute."http://www.doesnotunderstand.org/ >> > > > > -- > > > > 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 > -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

April 13, 2018

Re: [Pharo-dev] Iceberg2.0 crash test passed :)

by Guillermo Polito

Is that Pharo 7? On Fri, Apr 13, 2018 at 9:43 PM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > Yes I was able to commit also. > Very slick interface :-) > > > But now, every time I want to commit, my image crash and I have: > > Assertion failed: (git_atomic_get(&git__n_inits) > 0), function > git__global_state, file /Users/travis/build/OpenSmalltalk/opensmalltalk- > vm/build.macos64x64/pharo.cog.spur/build/third-party/libgit2-0.25.1/src/global.c, > line 322. > > > On Fri, Apr 13, 2018 at 8:02 PM, Stephane Ducasse <stepharo.self(a)gmail.com > > wrote: > >> I could commit my first commit with iceberg 2.0 >> Well done >> >> It feels nicer :). >> >> Stef >> >> > > > -- > Serge Stinckwich > UMI UMMISCO 209 (SU/IRD/UY1) > "Programs must be written for people to read, and only incidentally for > machines to execute."http://www.doesnotunderstand.org/ > -- 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

April 13, 2018