February 2019 - Pharo-users

Re: [Pharo-users] Looking for a STON in/out "factory"

by Sven Van Caekenberghe

That is already provided, you should implement SQOne class>>#stonName ^ #OneChoice Apart from that I would also use STON class>>#toStringPretty: or #prettyPrint: true on a writer, if the target audience are humans. > On 20 Feb 2019, at 11:00, ducasse <stepharo(a)netcourrier.com> wrote: > > Hi > > I would like to use STON to save objects that non programmer will edit. > From that perspective I would like to be able to have a different class name > than the one in the implementation. > > For example > instead of > > 'SQOne{#question:''Where do developers typically write the Pharo syntax?'',#choices:[''a stamp'',''an envelop'',''a postcard''],#solution:3,#explanation:''It is common to say that the Pharo syntax fits on a postcard.â'} > > having > > âOneChoice{#question:''Where do developers typically write the Pharo syntax?'',#choices:[''a stamp'',''an envelop'',''a postcard''],#solution:3,#explanation:''It is common to say that the Pharo syntax fits on a postcard.â'} > > Iâm wondering if > - there are hooks for that in STON so that I can inject a map. I look super fast at the doc > and browsing the code and I could not find them. > - if someone build such kind of layers on top of STON > > Stef >

Feb. 20, 2019

Looking for a STON in/out "factory"

by ducasse

Hi I would like to use STON to save objects that non programmer will edit. >From that perspective I would like to be able to have a different class name than the one in the implementation. For example instead of 'SQOne{#question:''Where do developers typically write the Pharo syntax?'',#choices:[''a stamp'',''an envelop'',''a postcard''],#solution:3,#explanation:''It is common to say that the Pharo syntax fits on a postcard.â'} having âOneChoice{#question:''Where do developers typically write the Pharo syntax?'',#choices:[''a stamp'',''an envelop'',''a postcard''],#solution:3,#explanation:''It is common to say that the Pharo syntax fits on a postcard.â'} Iâm wondering if - there are hooks for that in STON so that I can inject a map. I look super fast at the doc and browsing the code and I could not find them. - if someone build such kind of layers on top of STON Stef

Feb. 20, 2019

Re: [Pharo-users] OSProcess / OSSubprocess / LibC uniqueInstance

by Albrecht Baur

Nice! This helps -> thanks for the explanation. Albrecht On 19.02.19 21:10, Mariano Martinez Peck wrote: > Yeah, readme is out of date. 64 bits is working: > https://github.com/pharo-contributions/OSSubprocess/issues/22 > > On Tue, Feb 19, 2019 at 4:48 PM Alistair Grant <akgrant0710(a)gmail.com > <mailto:akgrant0710@gmail.com>> wrote: > > On Tue, 19 Feb 2019 at 13:45, Albrecht Baur via Pharo-users > <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> > wrote: > > > > Thank you. > > > > The Metacello snippet helps. It loads a newer version than that > from the catalog browser. > > > > > > But 2 more questions: > > > > 1.: Is there a reason not to use just ... > > > > LibC uniqueInstance system: 'zip -r 123.zip zipme/' > > You don't have the same level of control over the process, can't pipe > stdio, it introduces issues with interrupts (SIGINT, SIGQUIT), etc. > > > > And 2.: Is it ok to use OSSubprocess on in 64 bit images even > though the documentation says it doesn't work ? (but it does) > > > > -> https://github.com/pharo-contributions/OSSubprocess#installation > > That's a surprise.Â Yes, OSSubprocess is officially supported on 64 > bits, the readme is out of date. > > HTH, > Alistair > > > > -- > Mariano > https://twitter.com/MartinezPeck > http://marianopeck.wordpress.com

Feb. 20, 2019

Re: [Pharo-users] [ANN] SETT (Store Export to Tonel Tools) for Pharo6.1

by Dale Henrichs

Esteban, I'm glad that you are taking SETT for a spin. I am not familiar with the details of SETT, but if you could submit an issue[1] with the SETT project, then someone should be able to start looking into it:) I will ping them that you ran into issues ... Dale [1] https://github.com/GemTalk/SETT/issues On 2/19/19 4:36 PM, Esteban Maringolo wrote: > Dale, > > I tried to test SETT to migrate a Package from Store to our repo. > > But it fails while initializing the git repository. I set the > destination config to `isNewRepository := false`, then it works as > expected. > > I'm testing it against the Cincom Public Repository, which being > remote and full of code (and garbage), limiting by date isn't useful > if I can't filter by a particular package name/pattern (I couldn't > find such option). > > In any case, it's a helpful tool to ease the migration of code. > > Regards, > > Esteban A. Maringolo > > > El miÃ©., 16 ene. 2019 a las 18:18, Dale Henrichs via Pharo-users > (<pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>>) > escribiÃ³: > > > On 1/16/19 11:56 AM, Esteban Maringolo wrote: >> This is great! >> >> One less fence to move code from one dialect to another. :) >> >> I will follow the examples and try to export code from Store and >> load id in Pharo. >> >> Is it mandatory to use Linux? > > We've only tested with Linux and it looks like the current code > base is wired to use Unix[1] .... > > Dale > > [1] > https://github.com/GemTalk/SETT/blob/master/StoreImporter.package/SettGitRe… > >> >> Esteban A. Maringolo >> >> >> El miÃ©., 16 ene. 2019 a las 16:38, Dale Henrichs >> (<dale.henrichs(a)gemtalksystems.com >> <mailto:dale.henrichs@gemtalksystems.com>>) escribiÃ³: >> >> GemTalkSystems is pleased to announce SETT (Store Export to >> Tonel Tools)[1]. SETT is open source project with an MIT license. >> >> SETT (Store Export to Tonel Tools) is a set of tools to >> export Smalltalk code from Store and >> write into the Tonel file format managed using Git. >> >> SETT is: >> >> * a Pharo 6.1 application, that >> * connects to a Postgres Database >> * containing source code history in VisualWorks Store >> format; and >> * writes to a Git repository >> * in Tonel format >> * maintaining all version history, source code and SCM >> metadata. >> >> SETT was developed last year to support one of our commercial >> customers in their conversion From Store to Rowan[2]. Rowan >> artifacts are produced as part of the output of SETT, but the >> Rowan artifacts can be ignored. The important bit is that >> SETT converts from Store to Tonel and maintains version >> history in git. >> >> Please see the project ReadMe[3] and Wiki[4] for additional >> details. >> >> Dale >> >> [1] https://github.com/GemTalk/SETT >> [2] https://github.com/GemTalk/Rowan >> [3] https://github.com/GemTalk/SETT#overview >> [4] https://github.com/GemTalk/SETT/wiki >> >>

Feb. 20, 2019

Pharo general questions for a commercial application

by BrunoBB

Hi, My name is Bruno i'been using Smalltalk since 1999 for commercial applications, mostly Dolphin, GemStone/S and Visual Works. Now we have a commercial project and we are going to use Pharo :) So we have some general questions. 1) Which version of Pharo to use in a production deployment 6.1 or 7.0 ? 2) We need a local database to Pharo app, which open source database is better to use with Pharo: mysql, postgree or .... In term of packages for Pharo. There is https://guillep.github.io/DBXTalk/ but i do not know if is up to date. 3) There is any documentation about deployment and maintenance for a Pharo + Seaside app ? I have found "2016-10-06-EnterprisePharo.pdf" but may there are other sources... regards, bruno -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 20, 2019

Re: [Pharo-users] [ANN] SETT (Store Export to Tonel Tools) for Pharo6.1

by Esteban Maringolo

Dale, I tried to test SETT to migrate a Package from Store to our repo. But it fails while initializing the git repository. I set the destination config to `isNewRepository := false`, then it works as expected. I'm testing it against the Cincom Public Repository, which being remote and full of code (and garbage), limiting by date isn't useful if I can't filter by a particular package name/pattern (I couldn't find such option). In any case, it's a helpful tool to ease the migration of code. Regards, Esteban A. Maringolo El miÃ©., 16 ene. 2019 a las 18:18, Dale Henrichs via Pharo-users (< pharo-users(a)lists.pharo.org>) escribiÃ³: > > On 1/16/19 11:56 AM, Esteban Maringolo wrote: > > This is great! > > One less fence to move code from one dialect to another. :) > > I will follow the examples and try to export code from Store and load id > in Pharo. > > Is it mandatory to use Linux? > > We've only tested with Linux and it looks like the current code base is > wired to use Unix[1] .... > > Dale > > [1] > https://github.com/GemTalk/SETT/blob/master/StoreImporter.package/SettGitRe… > > > Esteban A. Maringolo > > > El miÃ©., 16 ene. 2019 a las 16:38, Dale Henrichs (< > dale.henrichs(a)gemtalksystems.com>) escribiÃ³: > >> GemTalkSystems is pleased to announce SETT (Store Export to Tonel >> Tools)[1]. SETT is open source project with an MIT license. >> >> SETT (Store Export to Tonel Tools) is a set of tools to export Smalltalk >> code from Store and >> write into the Tonel file format managed using Git. >> >> SETT is: >> >> - a Pharo 6.1 application, that >> - connects to a Postgres Database >> - containing source code history in VisualWorks Store format; and >> - writes to a Git repository >> - in Tonel format >> - maintaining all version history, source code and SCM metadata. >> >> SETT was developed last year to support one of our commercial customers >> in their conversion From Store to Rowan[2]. Rowan artifacts are produced as >> part of the output of SETT, but the Rowan artifacts can be ignored. The >> important bit is that SETT converts from Store to Tonel and maintains >> version history in git. >> >> Please see the project ReadMe[3] and Wiki[4] for additional details. >> >> Dale >> [1] https://github.com/GemTalk/SETT >> [2] https://github.com/GemTalk/Rowan >> [3] https://github.com/GemTalk/SETT#overview >> [4] https://github.com/GemTalk/SETT/wiki >> >> >>

Feb. 20, 2019

Re: [Pharo-users] About Iceberg

by ducasse

> On 19 Feb 2019, at 17:45, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Hi, > > I just want to add my grateful voices in this thread. > > Even as a vocal critic of the (gratuitous?) complexity of Git and the > dangers in the centralization via GitHub, Iceberg makes easy to use > modern VCS and get this feeling of momentum. Yes When MS bought github we thought that there is no risk because we can move in no time to other services. I did not gitea but this is a nice idea. > I'm starting to port my > repositoies to a community hosted version of Gitea[1] and I hope to > contribute into extending Iceberg to support Fossil. > > [1] https://gitea.io/ > > Thanks again, > > Offray > > On 19/2/19 7:32, Tim Mackinnon wrote: >> Yes I agree - when there is so much discussion and debate going on, its easy to lose sight of the hard work and determination that went into getting us to this brave new world. I too want to shout a big thank you for the tooling and also the support that goes along with that. >> >> I love been able to think a bit more polyglot, and use tools/languages more easily side by side - although of course I want to hold on to what makes Smalltalk special (which is tons of stuff). >> >> I particularly love being able to feel like its easier to contribute - updating readmeâs and docs is trivial in a web browser now - just correct them and submit a PR. And on the receiving side - GitHub makes it easy to discuss the fix, alter it, or simply approve it. Equally - modern build tools easily detect the change, pull the code and rebuild and package it (and cheap scalable infrastructure). >> >> Its also getting easier and easier to submit code fixes too - and the VCS skills you learn doing this are transferable beyond Smalltalk - so its a big win win. >> >> So yes guys - thanks for hanging in for us! >> >> Tim >> >>> On 19 Feb 2019, at 08:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> Hi, >>> >>> This is a thank you note about Iceberg. >>> >>> I have been moving all my external and internal Pharo code to git/tonel/7 and on multiple occasions I have been pleasantly surprised about the functionality and performance of Iceberg. Basically, it just works. >>> >>> Finally, Pharo code lives in standard open source and commercial repositories (git, GitHub, Bitbucket, ...), without losing anything. >>> >>> I know that it took years to get here and that lots of code and community battles had to be fought. So thank you, to the whole team, you did a great job ! >>> >>> Sven >>> >>> -- >>> Sven Van Caekenberghe >>> Proudly supporting Pharo >>> http://pharo.org >>> http://association.pharo.org >>> http://consortium.pharo.org >>> >>> >>> >>> >>> >> >> >

Feb. 19, 2019

Re: [Pharo-users] OSProcess / OSSubprocess / LibC uniqueInstance

by Mariano Martinez Peck

Yeah, readme is out of date. 64 bits is working: https://github.com/pharo-contributions/OSSubprocess/issues/22 On Tue, Feb 19, 2019 at 4:48 PM Alistair Grant <akgrant0710(a)gmail.com> wrote: > On Tue, 19 Feb 2019 at 13:45, Albrecht Baur via Pharo-users > <pharo-users(a)lists.pharo.org> wrote: > > > > Thank you. > > > > The Metacello snippet helps. It loads a newer version than that from the > catalog browser. > > > > > > But 2 more questions: > > > > 1.: Is there a reason not to use just ... > > > > LibC uniqueInstance system: 'zip -r 123.zip zipme/' > > You don't have the same level of control over the process, can't pipe > stdio, it introduces issues with interrupts (SIGINT, SIGQUIT), etc. > > > > And 2.: Is it ok to use OSSubprocess on in 64 bit images even though the > documentation says it doesn't work ? (but it does) > > > > -> https://github.com/pharo-contributions/OSSubprocess#installation > > That's a surprise. Yes, OSSubprocess is officially supported on 64 > bits, the readme is out of date. > > HTH, > Alistair > > -- Mariano https://twitter.com/MartinezPeck http://marianopeck.wordpress.com

Feb. 19, 2019

Re: [Pharo-users] OSProcess / OSSubprocess / LibC uniqueInstance

by Alistair Grant

On Tue, 19 Feb 2019 at 13:45, Albrecht Baur via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > Thank you. > > The Metacello snippet helps. It loads a newer version than that from the catalog browser. > > > But 2 more questions: > > 1.: Is there a reason not to use just ... > > LibC uniqueInstance system: 'zip -r 123.zip zipme/' You don't have the same level of control over the process, can't pipe stdio, it introduces issues with interrupts (SIGINT, SIGQUIT), etc. > And 2.: Is it ok to use OSSubprocess on in 64 bit images even though the documentation says it doesn't work ? (but it does) > > -> https://github.com/pharo-contributions/OSSubprocess#installation That's a surprise. Yes, OSSubprocess is officially supported on 64 bits, the readme is out of date. HTH, Alistair

Feb. 19, 2019

Re: [Pharo-users] Partition/Sync ready databases for Pharo?

by Offray Vladimir Luna CÃ¡rdenas

Maybe something like the SQLite based Core Object [1], from the Etoile folks, can your for you... at least as inspiration, because the project looks pretty unmaintained. [1] http://coreobject.org/ Cheers, Offray On 19/2/19 12:45, Esteban Maringolo wrote: > El mar., 19 feb. 2019 a las 13:40, Offray Vladimir Luna CÃ¡rdenas > (<offray.luna(a)mutabit.com>) escribiÃ³: > >> For alternatives to Firebase I have been starting to look at [3] and >> [4]. I would really love to see a Pharo client to any of such >> alternatives as I would like to have real time collaboration on >> Grafoscopio based notebooks. >> >> [1] http://demo.codimd.org/ >> [2] https://mutabit.com/repos.fossil/datafem/ >> [3] >> https://www.quora.com/Whats-the-closest-open-source-alternative-to-Firebase… >> [4] https://alternativeto.net/software/firebase/?license=opensource > These takes the "old" Firebase approach of a pure JS client (or > Android/iOS with SDK). > In general I don't like the "Firebase" approach of a huge JSON tree as > your database, nor how it merges changes (PATCH/PUT). > Firestore [1] seems to orient everything to a Collection based NoSQL > approach (ala MongoDB). > > I want something I can access from Pharo, at least via a REST API. > Although I'm biased to choose RDBMS (and SQL). > > Regards! > > Esteban A. Maringolo > >

Feb. 19, 2019

Re: [Pharo-users] Partition/Sync ready databases for Pharo?

by Esteban Maringolo

El mar., 19 feb. 2019 a las 13:40, Offray Vladimir Luna CÃ¡rdenas (<offray.luna(a)mutabit.com>) escribiÃ³: > For alternatives to Firebase I have been starting to look at [3] and > [4]. I would really love to see a Pharo client to any of such > alternatives as I would like to have real time collaboration on > Grafoscopio based notebooks. > > [1] http://demo.codimd.org/ > [2] https://mutabit.com/repos.fossil/datafem/ > [3] > https://www.quora.com/Whats-the-closest-open-source-alternative-to-Firebase… > [4] https://alternativeto.net/software/firebase/?license=opensource These takes the "old" Firebase approach of a pure JS client (or Android/iOS with SDK). In general I don't like the "Firebase" approach of a huge JSON tree as your database, nor how it merges changes (PATCH/PUT). Firestore [1] seems to orient everything to a Collection based NoSQL approach (ala MongoDB). I want something I can access from Pharo, at least via a REST API. Although I'm biased to choose RDBMS (and SQL). Regards! Esteban A. Maringolo

Feb. 19, 2019

Re: [Pharo-users] About Iceberg

by Offray Vladimir Luna CÃ¡rdenas

Hi, I just want to add my grateful voices in this thread. Even as a vocal critic of the (gratuitous?) complexity of Git and the dangers in the centralization via GitHub, Iceberg makes easy to use modern VCS and get this feeling of momentum. I'm starting to port my repositoies to a community hosted version of Gitea[1] and I hope to contribute into extending Iceberg to support Fossil. [1] https://gitea.io/ Thanks again, Offray On 19/2/19 7:32, Tim Mackinnon wrote: > Yes I agree - when there is so much discussion and debate going on, its easy to lose sight of the hard work and determination that went into getting us to this brave new world. I too want to shout a big thank you for the tooling and also the support that goes along with that. > > I love been able to think a bit more polyglot, and use tools/languages more easily side by side - although of course I want to hold on to what makes Smalltalk special (which is tons of stuff). > > I particularly love being able to feel like its easier to contribute - updating readmeâs and docs is trivial in a web browser now - just correct them and submit a PR. And on the receiving side - GitHub makes it easy to discuss the fix, alter it, or simply approve it. Equally - modern build tools easily detect the change, pull the code and rebuild and package it (and cheap scalable infrastructure). > > Its also getting easier and easier to submit code fixes too - and the VCS skills you learn doing this are transferable beyond Smalltalk - so its a big win win. > > So yes guys - thanks for hanging in for us! > > Tim > >> On 19 Feb 2019, at 08:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi, >> >> This is a thank you note about Iceberg. >> >> I have been moving all my external and internal Pharo code to git/tonel/7 and on multiple occasions I have been pleasantly surprised about the functionality and performance of Iceberg. Basically, it just works. >> >> Finally, Pharo code lives in standard open source and commercial repositories (git, GitHub, Bitbucket, ...), without losing anything. >> >> I know that it took years to get here and that lots of code and community battles had to be fought. So thank you, to the whole team, you did a great job ! >> >> Sven >> >> -- >> Sven Van Caekenberghe >> Proudly supporting Pharo >> http://pharo.org >> http://association.pharo.org >> http://consortium.pharo.org >> >> >> >> >> > >

Feb. 19, 2019

Re: [Pharo-users] Partition/Sync ready databases for Pharo?

by Offray Vladimir Luna CÃ¡rdenas

Hi, I think that using Fossil depends on what things are you synchronizing and how fast. In the Grafoscopio community we use Fossil to sync documentation (Grafoscopio notebooks and Wiki pages) and issues, which means documents that move slow, and we use CodiMD [1] (Firebase based) when we do synchronization on documents we write together in real time (like hackathon/documentathon notes). Usually we publish them in a single Fossil repository (see [2] for an example of this combination of slow + quick sync combining Fossil and CodiMD). For alternatives to Firebase I have been starting to look at [3] and [4]. I would really love to see a Pharo client to any of such alternatives as I would like to have real time collaboration on Grafoscopio based notebooks. [1] http://demo.codimd.org/ [2] https://mutabit.com/repos.fossil/datafem/ [3] https://www.quora.com/Whats-the-closest-open-source-alternative-to-Firebase… [4] https://alternativeto.net/software/firebase/?license=opensource Hope it helps, Offray On 19/2/19 8:36, Esteban Maringolo wrote: > Hi Tim, Pierce, > > No problem, I was going to ask about Fossil as well, I know it is a > self contained SCM, with issue tracker, and whatnot. People that uses > it don't want to use git except if forced to. > So I also ask how this would work. :) > > I saw SQLite-sync before, but it is a commercial product, and its > platform support/setup seems convoluted. > > dqlite might be a viable alternative, from more than reliable > provider, it's is not clear whether I have to use a different library > to access SQLite (it seems so) or a special wire protocol/api calls. > The only drawback I see is that, according to the the FAQ [1], from > the CAP theorem the consensus algorithm puts Consistency and Partition > and leaves out Availability. > > I'm looking into CouchDB and reading its "Definitive Guide"[2] book. > It seems straightforward to install, distribute and uses a MVCC > approach that puts availability as its top priority, and since my > domain data has a low probability of conflicts, the eventual > consistency will be more than enough. OTOH I'm not used to document > based DBMS, which will require me to rethink a lot of my domain and > application models. > > Also, it has a simple HTTP API (JSON/REST) and there is an existing > Smalltalk client that might be ported and adapted to Pharo > https://cwiki.apache.org/confluence/display/COUCHDB/Smalltalk > > > Background: I have the prospect to develop an application to replace > an existing one that is a desktop app that "syncs" from/to a central > server every 15', most of the data entry happens locally and the > central server is read only for the most part, it is old, ugly, but it > works "reliably", so I must come with an alternative that is as > reliable as that, and then provide a better UI/UX, new features, etc. > > Regards! > > > Esteban A. Maringolo > > > [1] From https://github.com/CanonicalLtd/go-dqlite/ > Q: When not enough nodes are available, are writes hung until consensus? > A: Yes, however there's a (configurable) timeout. This is a > consequence of Raft sitting in the CP spectrum of the CAP theorem: in > case of a network partition it chooses consistency and sacrifices > availability. > > [2] http://guide.couchdb.org/draft/index.html > > El mar., 19 feb. 2019 a las 10:03, Tim Mackinnon (<tim(a)testit.works>) escribiÃ³: >> When you say Fossil - are you referring to "https://fossil-scm.org/index.html/doc/trunk/www/index.wikiâ ? >> >> Iâve seen it come up a few times - is it good? But rather than subvert Estebanâs thread - if it is the above, can you hook into it to save application runtime artefacts such that a distributed application can read them back (Iâd just sort of assumed it was for saving code and docs) - but it sounds like it can go a bit deeper than that (which seems quite interesting and perhaps what Esteban is after?) >> >> Tim >> >> >>> On 19 Feb 2019, at 01:46, Pierce Ng <pierce(a)samadhiweb.com> wrote: >>> >>> On Mon, Feb 18, 2019 at 02:56:10PM -0300, Esteban Maringolo wrote: >>>> I have the requirement that an app that I'm prospecting must be able >>>> to work offline and synchronize changes once the connection is >>>> restored. >>>> >>>> I want to avoid having to write "sync" logic manually. >>> I've not done this for real before, but here are some possibilities: >>> >>> - https://github.com/sqlite-sync/SQLite-sync.com >>> - http://www.symmetricds.org/ >>> - https://github.com/CanonicalLtd/dqlite >>> - Use Fossil as your database >>> >>> >>> >> >

Feb. 19, 2019

Re: [Pharo-users] Iceberg working with forks - can it be easier?

by Tim Mackinnon

Ah - I think I know whats happened - I didnât do a proper reset of my fork - the real command is: Tims-MacBook-Pro:pharo-exercism macta$ git fetch exercism Tims-MacBook-Pro:pharo-exercism macta$ git reset --hard exercism/master HEAD is now at 28a7a95 Update readme for pharo smalltalk repo name #2 (#134) Tims-MacBook-Pro:pharo-exercism macta$ git push origin master --force Total 0 (delta 0), reused 0 (delta 0) To github.com:macta/pharo-exercism.git + 16293c4...28a7a95 master -> master (forced update) And then you need to make sure you fetch in Pharo again (obvious, but easy to forget) Now I think Iâm in good shape. Tim > On 19 Feb 2019, at 15:45, Tim Mackinnon <tim(a)testit.works> wrote: > > Once again - super helpful - Iâll definitely bookmark this one. Half the problem is that every time I think I understand what is going on and confidently do a bunch of stuff I then discover that its not what I thought. I then jump over to IntelliJ to visualise what the current state is and then try understand how I got to that place - which hasnât been from doing anything knowingly funky (that comes afterwards when Iâve tried to rationalise/rectify what I think Iâm seeing). > > If you donât mind, I will try and repeat what youâve said and keep a journal of what Iâm doing so we can hopefully make sense of what has happened 3 times now. > > So back to original setup - in GitHub you fork the main repo (pharo for you, but for me it was exercism/pharo due to the name issue - but actually this has proved a useful learning exercise). > > So having forked from exercism/pharo to macta/pharo-exercism , in Pharo I go to clone my repo. (Iâve actually just removed my previous project and said to delete from file system as well) > > So hereâs the first thing - if I clone my fork - Pharo helpfully creates 2 remotes for me (exercism & origin) if I clone just the origin I then have to add the remote myself - and the prompt for that that is user and url (so a bit less friendly than having the extra GitHub option of user and project). > > So for now - Iâll stick with what Iâve done before (but do you think doing it the more awkward way is better? And can we make it less awkward if it is). > > Now just to be sure - Iâll make sure my fork and origin are in sync (and this is where now I notice why it might have been going wrong, because my current local master is based on that of my fork - which I notice currently on GitHub says its â10 commits ahead of exercism:masterâ) - and this might be why Iâm seeing all those extra commits in my PR (?). Scratching my head on this Iâve realised that when I first started out - I accidentally committed to master on my fork before realising that I had forgotten to create a branch - which I then did (but I guess I left my fork master in a bad state). > > So I have now done: > git reset --hard exercism/master > > Now my GitHub fork page looks like its correct. > > So Iâve done some categorisation changes in a branch and done a commit and pushed those changes to my fork - but when I go to generate a PR on GitHub in my upstream - its showing 10 commitsâ¦ grrrr > > So it looks like this (and yes its a mess because Iâve been struggling with this for day and getting the same sort of problem) > > <PastedGraphic-1.png> > > The only thing I can think is that after doing that reset - I canât recall if I did a pull in pharo - so possibly my image was still synced to the repo prior to me making it equal to upstream? > > But Iâve now just switched to master in my image - created a new branch, and made a simple comment change and pushed that branch back to my fork and its still showing 11 commits (when there should be just 1). > > So I donât understand whats going on? > > My upstream is exercism/pharo-smalltalk and my fork is macta/pharo-exercism - the comment change I just made was id: 84e581c38d351baddf98a172a01b5bf475ec2e25. > > Is it possible my image is just in a funny state and that simply removing the project at the beginning wasnât enough? > > Tim > > >> On 19 Feb 2019, at 13:08, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >> >> >> >> On Tue, Feb 19, 2019 at 2:08 AM Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >> Hi Guille - thanks for taking the time to write this upâ¦ in the middle there I finally spotted the crucial bit âclone the original, push to your forkâ. I think thats what Iâve been doing wrong - and it leads to all kinds of confusion (at least Iâm hoping this is what it is). >> >> >> You've been doing nothing wrong :). >> Both are valid things in Git, and to talk about rights and wrongs are fuzzy at the least there. >> >> As I have cloned from my Fork (and in my defence - its because we were given a repository that collides with the pharo one - exercism/pharo - and P7 doesnât let us clone from that) - so Iâve had to clone from my fork. >> >> Yeh, that's a bug. It should not be difficult to fix. >> The thing is, iceberg distinguishes repositories/projects by name. >> And names are obtained from the repository/project directory name. >> Then, the plugin made to simplify contributions to pharo, detects the repositories called "pharo" as pharo themselves and do some extra configuration. What happens in your case is that your repository suffers from that extra configuration, which is not the right thing to do in your case... >> >> One Idea that was poking around in my head is to be able to "rename" a project independently of its location in disk. >> We already have a metadata file at the root of the repository. We could add in that metadata file properties like: >> - the project's name (for example you could call it "pharo-exercism" in there, while keeping the tree structure) >> - an extra special property "isPharoRepository : true" that may be defined only for pharo >> - a canonical-repository url which could be used to compare against pharo's canonical url >> >> Implementing the detection of pharo's repository using any of those strategies could solve your problem... >> What do you think? >> >> It all seemed to work until I started submitting my PRâs and then they seem to include commits going much further back than I think they should need Even wen I thought I was being careful and syncing to master - it still seems to go back to some of my earliest work. >> >> This looks like a mis-manipulation of branches, and It smells to me that it is not related to the issue above... >> Next time it happens, I'd like, if you can, that you share with me the exact: >> - branch >> - commitish >> >> that you're trying to make a PR from, to see if we can see the real cause, and at least build some docs on it ^^. >> >> >> Now that we have managed to get the repo renamed - I will try working like you have suggested and make sure that it is working like you describe - as it shouldnât be as complicated as this to make clean isolated changes and then submit them as a PR. (otherwise Pharo would fall apart). >> >> One question I do have however - is what is the best procedure if you realised when making changes that >> A) you forgot to make changes in a branch (so are working on master) >> >> It depends if your changes have been pushed or not. >> 1) First thing is to fix your local branch with the expression I told in a previous email >> >> repo branch commit: repo branch commit parent. >> >> 2) If you have already pushed, that means that you have to rewrite the history on the remote side, and that would require a push force (from the command line so far, unless you would like to implement that in iceberg :P). >> >> B) you are working in a branch but decide some of your changes should go in another branch itself based on master (how to stash?) >> >> There is no stash mechanism in iceberg (so far). >> What I do is: >> - I checkout the base branch (master in this case) in expert mode => do not touch my image code, then the image itself will work as a stash >> - I now checkout a new branch (that will "fork" from the last commit in my master branch) >> - I commit only the things I want to commit. >> >> (see that this is not much different from what you would have done from the terminal except that the checkout strategy will make the stashing unnecessary: >> - git stash >> - git checkout master >> - git checkout -b myBranch >> - git stash pop >> - git commit >> ) >> >> Then you can either >> - discard all your extra changes (I'd suggest to have committed them earlier :)) to be in a clean master+yournewchanges >> - or you can go back to your first branch >> >> >> These are 2 common scenarios Iâve found when trying to be a good citizen for my little project. Do I have to go to the terminal to do this stuff - or can I cleanly do these kinds of operations in Pharo (which I think you should be able to do, as its so easy to get into either of those states). >> >> >> I think you can do everything so far except the push force. >> >> Still I'm not happy with what we have (and I'd like to have 48h days) :) >> >> To help in your first scenario: >> - It should not be difficult to get the reset on the UI (https://github.com/pharo-vcs/iceberg/issues/1174 <https://github.com/pharo-vcs/iceberg/issues/1174>) ;) >> - The same with the push force >> >> For the second scenario, what bothers me the most is the special checkout that may confuse people. >> Also, while you're doing it, you may have not committed your code anywhere => and that's dangerous, because you may lose it. >> >> So, imagine this: you are in branch A and you have these changes that you wan to put in branch B. >> Instead of doing strange stashing/checkout blah, you create a new branch temp/AtoB and commit there. >> And then you move to B and apply a smart cherry pick operation of your changes. >> Martin was visiting the team last week and he had a super nice prototype: you select what you want to cherry pick from a branch and it automatically selects all (static) dependencies in the same branch, and proposes you doing a commit/merge of that. >> I don't know how far are we from this, but it would be super nice to do easy backporting between branches (think pharo8 -> pharo7). >> >> Guille >> >> Thanks in advance. >> >> Tim >> >>> On 18 Feb 2019, at 08:56, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >>> >>> Hi! >>> >>> On Fri, Feb 15, 2019 at 7:06 PM Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >>> Hi guys - Iâve spent a few hours scratching my head trying to understand why some of my Pull Requests to a project I had forked kept showing my previous commits when I thought I was all caught up. >>> >>> It suddenly dawned on me, that when I had forked, and then done some work and then submitted a PR, and then applied it upstream that my fork is now no longer in sync with its upstream counterpart. >>> >>> Having not done this in ages, it took me a while to then realise I have to do some git stuff to get it back in sync e.g. (and I think Iâve got this right) >>> >>> git fetch upstream (or whatever name you gave it) >>> Git checkout master >>> Git merge upstream/master >>> >>> When you did your clone, did you clone the original repository or your fork's? >>> One way to simplify this workflow is: >>> - you clone always the original repository >>> - you create a branch and work there >>> - then you'll push your branch to your fork + fork >>> >>> That way your branch will be always up to date with the original repository, and no need to sync (actually the sync is done automatically when you push to your fork). >>> >>> Of course this assumes you're doing a new clone every time you work :). >>> >>> >>> So I guess my question is - wouldnât it be helpful if this was a command in Iceberg? >>> >>> It would, there are several places where we could simplify the workflow for common cases, I agree. >>> >>> It seems quite common to fork a project (I think this is still recommended for pharo itself isnât it?) >>> >>> I'd say its mandatory :). Otherwise you will not be able to push directly to it because of permission problems (actually all main dev branches are now blocked so **nobody**, not even admins, push to them directly). >>> >>> - and then at some point you need to catchup with that origin again? Or am I missing something? >>> >>> Well, it really depends on the workflow you use. Above I've explained a workflow that works when you clone every time. >>> Git is so complex and so low level that you can do lots of different things with it. >>> >>> First thing is to understand what "catch up with origin" means. In my head it only means: >>> - checkout your "to-catchup" branch >>> - merge the remote "to-catchup" branch and merge it >>> >>> All the rest is workflow dependent. Even (!!) I would argue that merging is not, strictly speaking, a correct way to catch up: If you have made changes into "to-catchup", then merging will not make both branches the same, but your "to-catchup" branch may have extra commits that you did not want to introduce... >>> >>> And here I'm not saying you should not merge, actually I do it most of the times because I know that 90% of the times it will be ok, and I do rollback when I realize I was in the other 10%... >>> >>> I guess lots of stuff can go wrong - but if it does - youâd still get the same problems on the command line. >>> >>> Yes, and no. The "lots of stuff can go wrong" can be translated in most of the cases to "I had a merge conflict". But this is not git, this is git+pharo. >>> >>> The thing is that with Git, your code is dead in files. With Iceberg, your code is in the files but it also may be alive in your image too. So updating code for what you have existing instances, or announcement subscriptions or other could (and probably will) mess up with the running code... >>> So to the typical merge conflict, you may add breaking your running system. >>> >>> It just seems that for normal situations - it would be handy to run this straight in Pharo. >>> >>> Thoughts from the git experts? >>> >>> For these cases, you can do exactly as the command line from Iceberg's UI >>> >>> - change your branch to your "to-catchup" master >>> - fetch >>> - now you can go to the merge option, and choose to merge your remote branch into your checked-out branch. >>> - and push >>> >>> Of course, this simple workflow works most of the times, but you may find edge cases. >>> For those edge cases (typically updating iceberg itself, or trying to update pharo itself), in the checkout preview you will have the combo with the checkout strategy: choose the expert mode "do not load the code". This option will change the branch on git's world, but it will not load the code in your image. >>> >>> That is useful if you have living instances for example. >>> This option will though make a diff between the checked out version and your image code and show you differences. (think this as a git reset --soft) >>> >>> To me the fact that we are manipulating live code loaded in the image and not dead files makes a huge difference, and this makes that extrapolating git commands to iceberg is not so straight forward :). Also, understanding that git is stateful/context dependant, and applying an operation means changing your current state (modify your current branch, change your current branch) is useful to see the consequences. >>> >>> In any case, any more concrete suggestions for enhancing this workflow are welcome. I think that neither Esteban, Pablo, me nor other contributors are skilled UI designers, and thinking about the best way to present a usecase to a user is super super hard :). >>> >>> Guille, from his vacations >>> >> >> >> >> -- >> >> 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 >

Feb. 19, 2019

Re: [Pharo-users] Iceberg working with forks - can it be easier?

by Tim Mackinnon

Once again - super helpful - Iâll definitely bookmark this one. Half the problem is that every time I think I understand what is going on and confidently do a bunch of stuff I then discover that its not what I thought. I then jump over to IntelliJ to visualise what the current state is and then try understand how I got to that place - which hasnât been from doing anything knowingly funky (that comes afterwards when Iâve tried to rationalise/rectify what I think Iâm seeing). If you donât mind, I will try and repeat what youâve said and keep a journal of what Iâm doing so we can hopefully make sense of what has happened 3 times now. So back to original setup - in GitHub you fork the main repo (pharo for you, but for me it was exercism/pharo due to the name issue - but actually this has proved a useful learning exercise). So having forked from exercism/pharo to macta/pharo-exercism , in Pharo I go to clone my repo. (Iâve actually just removed my previous project and said to delete from file system as well) So hereâs the first thing - if I clone my fork - Pharo helpfully creates 2 remotes for me (exercism & origin) if I clone just the origin I then have to add the remote myself - and the prompt for that that is user and url (so a bit less friendly than having the extra GitHub option of user and project). So for now - Iâll stick with what Iâve done before (but do you think doing it the more awkward way is better? And can we make it less awkward if it is). Now just to be sure - Iâll make sure my fork and origin are in sync (and this is where now I notice why it might have been going wrong, because my current local master is based on that of my fork - which I notice currently on GitHub says its â10 commits ahead of exercism:masterâ) - and this might be why Iâm seeing all those extra commits in my PR (?). Scratching my head on this Iâve realised that when I first started out - I accidentally committed to master on my fork before realising that I had forgotten to create a branch - which I then did (but I guess I left my fork master in a bad state). So I have now done: git reset --hard exercism/master Now my GitHub fork page looks like its correct. So Iâve done some categorisation changes in a branch and done a commit and pushed those changes to my fork - but when I go to generate a PR on GitHub in my upstream - its showing 10 commitsâ¦ grrrr So it looks like this (and yes its a mess because Iâve been struggling with this for day and getting the same sort of problem) The only thing I can think is that after doing that reset - I canât recall if I did a pull in pharo - so possibly my image was still synced to the repo prior to me making it equal to upstream? But Iâve now just switched to master in my image - created a new branch, and made a simple comment change and pushed that branch back to my fork and its still showing 11 commits (when there should be just 1). So I donât understand whats going on? My upstream is exercism/pharo-smalltalk and my fork is macta/pharo-exercism - the comment change I just made was id: 84e581c38d351baddf98a172a01b5bf475ec2e25. Is it possible my image is just in a funny state and that simply removing the project at the beginning wasnât enough? Tim > On 19 Feb 2019, at 13:08, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > > > > On Tue, Feb 19, 2019 at 2:08 AM Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: > Hi Guille - thanks for taking the time to write this upâ¦ in the middle there I finally spotted the crucial bit âclone the original, push to your forkâ. I think thats what Iâve been doing wrong - and it leads to all kinds of confusion (at least Iâm hoping this is what it is). > > > You've been doing nothing wrong :). > Both are valid things in Git, and to talk about rights and wrongs are fuzzy at the least there. > > As I have cloned from my Fork (and in my defence - its because we were given a repository that collides with the pharo one - exercism/pharo - and P7 doesnât let us clone from that) - so Iâve had to clone from my fork. > > Yeh, that's a bug. It should not be difficult to fix. > The thing is, iceberg distinguishes repositories/projects by name. > And names are obtained from the repository/project directory name. > Then, the plugin made to simplify contributions to pharo, detects the repositories called "pharo" as pharo themselves and do some extra configuration. What happens in your case is that your repository suffers from that extra configuration, which is not the right thing to do in your case... > > One Idea that was poking around in my head is to be able to "rename" a project independently of its location in disk. > We already have a metadata file at the root of the repository. We could add in that metadata file properties like: > - the project's name (for example you could call it "pharo-exercism" in there, while keeping the tree structure) > - an extra special property "isPharoRepository : true" that may be defined only for pharo > - a canonical-repository url which could be used to compare against pharo's canonical url > > Implementing the detection of pharo's repository using any of those strategies could solve your problem... > What do you think? > > It all seemed to work until I started submitting my PRâs and then they seem to include commits going much further back than I think they should need Even wen I thought I was being careful and syncing to master - it still seems to go back to some of my earliest work. > > This looks like a mis-manipulation of branches, and It smells to me that it is not related to the issue above... > Next time it happens, I'd like, if you can, that you share with me the exact: > - branch > - commitish > > that you're trying to make a PR from, to see if we can see the real cause, and at least build some docs on it ^^. > > > Now that we have managed to get the repo renamed - I will try working like you have suggested and make sure that it is working like you describe - as it shouldnât be as complicated as this to make clean isolated changes and then submit them as a PR. (otherwise Pharo would fall apart). > > One question I do have however - is what is the best procedure if you realised when making changes that > A) you forgot to make changes in a branch (so are working on master) > > It depends if your changes have been pushed or not. > 1) First thing is to fix your local branch with the expression I told in a previous email > > repo branch commit: repo branch commit parent. > > 2) If you have already pushed, that means that you have to rewrite the history on the remote side, and that would require a push force (from the command line so far, unless you would like to implement that in iceberg :P). > > B) you are working in a branch but decide some of your changes should go in another branch itself based on master (how to stash?) > > There is no stash mechanism in iceberg (so far). > What I do is: > - I checkout the base branch (master in this case) in expert mode => do not touch my image code, then the image itself will work as a stash > - I now checkout a new branch (that will "fork" from the last commit in my master branch) > - I commit only the things I want to commit. > > (see that this is not much different from what you would have done from the terminal except that the checkout strategy will make the stashing unnecessary: > - git stash > - git checkout master > - git checkout -b myBranch > - git stash pop > - git commit > ) > > Then you can either > - discard all your extra changes (I'd suggest to have committed them earlier :)) to be in a clean master+yournewchanges > - or you can go back to your first branch > > > These are 2 common scenarios Iâve found when trying to be a good citizen for my little project. Do I have to go to the terminal to do this stuff - or can I cleanly do these kinds of operations in Pharo (which I think you should be able to do, as its so easy to get into either of those states). > > > I think you can do everything so far except the push force. > > Still I'm not happy with what we have (and I'd like to have 48h days) :) > > To help in your first scenario: > - It should not be difficult to get the reset on the UI (https://github.com/pharo-vcs/iceberg/issues/1174 <https://github.com/pharo-vcs/iceberg/issues/1174>) ;) > - The same with the push force > > For the second scenario, what bothers me the most is the special checkout that may confuse people. > Also, while you're doing it, you may have not committed your code anywhere => and that's dangerous, because you may lose it. > > So, imagine this: you are in branch A and you have these changes that you wan to put in branch B. > Instead of doing strange stashing/checkout blah, you create a new branch temp/AtoB and commit there. > And then you move to B and apply a smart cherry pick operation of your changes. > Martin was visiting the team last week and he had a super nice prototype: you select what you want to cherry pick from a branch and it automatically selects all (static) dependencies in the same branch, and proposes you doing a commit/merge of that. > I don't know how far are we from this, but it would be super nice to do easy backporting between branches (think pharo8 -> pharo7). > > Guille > > Thanks in advance. > > Tim > >> On 18 Feb 2019, at 08:56, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >> >> Hi! >> >> On Fri, Feb 15, 2019 at 7:06 PM Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >> Hi guys - Iâve spent a few hours scratching my head trying to understand why some of my Pull Requests to a project I had forked kept showing my previous commits when I thought I was all caught up. >> >> It suddenly dawned on me, that when I had forked, and then done some work and then submitted a PR, and then applied it upstream that my fork is now no longer in sync with its upstream counterpart. >> >> Having not done this in ages, it took me a while to then realise I have to do some git stuff to get it back in sync e.g. (and I think Iâve got this right) >> >> git fetch upstream (or whatever name you gave it) >> Git checkout master >> Git merge upstream/master >> >> When you did your clone, did you clone the original repository or your fork's? >> One way to simplify this workflow is: >> - you clone always the original repository >> - you create a branch and work there >> - then you'll push your branch to your fork + fork >> >> That way your branch will be always up to date with the original repository, and no need to sync (actually the sync is done automatically when you push to your fork). >> >> Of course this assumes you're doing a new clone every time you work :). >> >> >> So I guess my question is - wouldnât it be helpful if this was a command in Iceberg? >> >> It would, there are several places where we could simplify the workflow for common cases, I agree. >> >> It seems quite common to fork a project (I think this is still recommended for pharo itself isnât it?) >> >> I'd say its mandatory :). Otherwise you will not be able to push directly to it because of permission problems (actually all main dev branches are now blocked so **nobody**, not even admins, push to them directly). >> >> - and then at some point you need to catchup with that origin again? Or am I missing something? >> >> Well, it really depends on the workflow you use. Above I've explained a workflow that works when you clone every time. >> Git is so complex and so low level that you can do lots of different things with it. >> >> First thing is to understand what "catch up with origin" means. In my head it only means: >> - checkout your "to-catchup" branch >> - merge the remote "to-catchup" branch and merge it >> >> All the rest is workflow dependent. Even (!!) I would argue that merging is not, strictly speaking, a correct way to catch up: If you have made changes into "to-catchup", then merging will not make both branches the same, but your "to-catchup" branch may have extra commits that you did not want to introduce... >> >> And here I'm not saying you should not merge, actually I do it most of the times because I know that 90% of the times it will be ok, and I do rollback when I realize I was in the other 10%... >> >> I guess lots of stuff can go wrong - but if it does - youâd still get the same problems on the command line. >> >> Yes, and no. The "lots of stuff can go wrong" can be translated in most of the cases to "I had a merge conflict". But this is not git, this is git+pharo. >> >> The thing is that with Git, your code is dead in files. With Iceberg, your code is in the files but it also may be alive in your image too. So updating code for what you have existing instances, or announcement subscriptions or other could (and probably will) mess up with the running code... >> So to the typical merge conflict, you may add breaking your running system. >> >> It just seems that for normal situations - it would be handy to run this straight in Pharo. >> >> Thoughts from the git experts? >> >> For these cases, you can do exactly as the command line from Iceberg's UI >> >> - change your branch to your "to-catchup" master >> - fetch >> - now you can go to the merge option, and choose to merge your remote branch into your checked-out branch. >> - and push >> >> Of course, this simple workflow works most of the times, but you may find edge cases. >> For those edge cases (typically updating iceberg itself, or trying to update pharo itself), in the checkout preview you will have the combo with the checkout strategy: choose the expert mode "do not load the code". This option will change the branch on git's world, but it will not load the code in your image. >> >> That is useful if you have living instances for example. >> This option will though make a diff between the checked out version and your image code and show you differences. (think this as a git reset --soft) >> >> To me the fact that we are manipulating live code loaded in the image and not dead files makes a huge difference, and this makes that extrapolating git commands to iceberg is not so straight forward :). Also, understanding that git is stateful/context dependant, and applying an operation means changing your current state (modify your current branch, change your current branch) is useful to see the consequences. >> >> In any case, any more concrete suggestions for enhancing this workflow are welcome. I think that neither Esteban, Pablo, me nor other contributors are skilled UI designers, and thinking about the best way to present a usecase to a user is super super hard :). >> >> Guille, from his vacations >> > > > > -- > > 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

Feb. 19, 2019

How do you easily re-categorise methods in Calypso?

by Tim Mackinnon

Hi - Iâm scratching my head over how to easily re-caegorise methods in calypso? Iâve overridden some methods in subclasses and picked up the wrong category (which the critic is slapping me for). But when I click on the method - I canât drag it to the new category, so if I click on the pencil in the status line (or the current category name - not sure why they are independently clickable?) - it shows me a rather unhelpful list of protocols. Iâm not sure where this list comes from as it doesnât seem to include any of the protocols that are already in the class? (and those which I want to use?). So I have to start typing âaccesâ and can click on accessingâ¦ Am I missing a simple trick - or is this an area that needs some work?

Feb. 19, 2019

How to uncache Commander menu items

by Tim Mackinnon

I was going to write this question - but Denis pinged me on Discord - however I thought I would lob this into the list in case someone else hits the problem and is searching for it. (Maybe I should stick this in Calypso or Commander faq). My problem was that I had built a sub menu in Calypso and specified the order of the menu items as described in the docs. packageContextMenuActivation <classAnnotation> ^ CmdContextMenuActivation byItemOf: ClyExercismMenuGroup order: self contextMenuOrder for: ClyTaggedClassGroup asCalypsoItemContext However when I went to add some icons and change the ordering I was finding that my menu wasnât updating. There are 2 solutions (one better than the other). The brute force way is: CmdContextMenuActivation resetCache. The elegant way was to add an annotation to my menu ordering method contextMenuOrder <classAnnotationDependency> ^1 Tim By the way - to see what icons you can use in your menus, inspect: ThemeIcons current

Feb. 19, 2019

Re: [Pharo-users] Partition/Sync ready databases for Pharo?

by Esteban Maringolo

Hi Tim, Pierce, No problem, I was going to ask about Fossil as well, I know it is a self contained SCM, with issue tracker, and whatnot. People that uses it don't want to use git except if forced to. So I also ask how this would work. :) I saw SQLite-sync before, but it is a commercial product, and its platform support/setup seems convoluted. dqlite might be a viable alternative, from more than reliable provider, it's is not clear whether I have to use a different library to access SQLite (it seems so) or a special wire protocol/api calls. The only drawback I see is that, according to the the FAQ [1], from the CAP theorem the consensus algorithm puts Consistency and Partition and leaves out Availability. I'm looking into CouchDB and reading its "Definitive Guide"[2] book. It seems straightforward to install, distribute and uses a MVCC approach that puts availability as its top priority, and since my domain data has a low probability of conflicts, the eventual consistency will be more than enough. OTOH I'm not used to document based DBMS, which will require me to rethink a lot of my domain and application models. Also, it has a simple HTTP API (JSON/REST) and there is an existing Smalltalk client that might be ported and adapted to Pharo https://cwiki.apache.org/confluence/display/COUCHDB/Smalltalk Background: I have the prospect to develop an application to replace an existing one that is a desktop app that "syncs" from/to a central server every 15', most of the data entry happens locally and the central server is read only for the most part, it is old, ugly, but it works "reliably", so I must come with an alternative that is as reliable as that, and then provide a better UI/UX, new features, etc. Regards! Esteban A. Maringolo [1] From https://github.com/CanonicalLtd/go-dqlite/ Q: When not enough nodes are available, are writes hung until consensus? A: Yes, however there's a (configurable) timeout. This is a consequence of Raft sitting in the CP spectrum of the CAP theorem: in case of a network partition it chooses consistency and sacrifices availability. [2] http://guide.couchdb.org/draft/index.html El mar., 19 feb. 2019 a las 10:03, Tim Mackinnon (<tim(a)testit.works>) escribiÃ³: > > When you say Fossil - are you referring to "https://fossil-scm.org/index.html/doc/trunk/www/index.wikiâ ? > > Iâve seen it come up a few times - is it good? But rather than subvert Estebanâs thread - if it is the above, can you hook into it to save application runtime artefacts such that a distributed application can read them back (Iâd just sort of assumed it was for saving code and docs) - but it sounds like it can go a bit deeper than that (which seems quite interesting and perhaps what Esteban is after?) > > Tim > > > > On 19 Feb 2019, at 01:46, Pierce Ng <pierce(a)samadhiweb.com> wrote: > > > > On Mon, Feb 18, 2019 at 02:56:10PM -0300, Esteban Maringolo wrote: > >> I have the requirement that an app that I'm prospecting must be able > >> to work offline and synchronize changes once the connection is > >> restored. > >> > >> I want to avoid having to write "sync" logic manually. > > > > I've not done this for real before, but here are some possibilities: > > > > - https://github.com/sqlite-sync/SQLite-sync.com > > - http://www.symmetricds.org/ > > - https://github.com/CanonicalLtd/dqlite > > - Use Fossil as your database > > > > > > > >

Feb. 19, 2019

Re: [Pharo-users] Running pharo in daemon mode

by sergio ruiz

My daemontools run file looks like: #!/bin/bash # settings USER="bandtracker" VM="/home/bandtracker/pharoImages/pharo" VM_PARAMS="-mmap 256m -vm-sound-null -vm-display-null" IMAGE="/home/bandtracker/pharoImages/Pharo.image" # start the vm exec \ setuidgid "$USER" \ "$VM" $VM_PARAMS "$IMAGE" --no-quit but for some reason, it just sits and grinds and restarts.. never remaining started for more than a second.. On February 18, 2019 at 8:19:24 PM, Pierce Ng (pierce(a)samadhiweb.com) wrote: My daemontools run file: #!/bin/sh /usr/bin/setuidgid app1 \ /pkg/vm/pharo -vm-display-null -vm-sound-null app1.image --no-quit ---- peace, sergio photographer, journalist, visionary Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.codeandmusic.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

Feb. 19, 2019

Re: [Pharo-users] How do you avoid loading master code which is indirectly referenced by a version in the baseline?

by Guillermo Polito

Hi Sabine, maybe you want to have a look at metacello lock. https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloScr… On Tue, Feb 19, 2019 at 1:06 PM Tim Mackinnon <tim(a)testit.works> wrote: > Hi Sabine - you raise an important point, and I am interested in us > getting better answers to this too. Hopefully Dale seeâs this and is > thinking about this in Rowen. Repeatable loading is an important enterprise > feature. > > Tim > > > On 18 Feb 2019, at 15:46, Sabine Manaa <manaa.sabine(a)gmail.com> wrote: > > > > For test and deployment, I have to be sure that I know exactly which > versions > > I load and I have to be sure to be able to load exactly the same code > again. > > I do not speak from my projects but from the projects I use. > > > > I found myself asking people again and again to set tags in their > projects > > and being surprised again and again by changed code even though I am > trying > > to load versions (with versions I mean NOT #stable or #master but like > > v2.2.2). > > > > The reason for this problem I then have, is that often in baselines with > > version numbers (e.g. v2.2.2) other projects are referenced but as > master. > > So in consequence, I load version but get master from another project > which > > is referenced indirectly. > > > > For me, that this is not good at all. I was wondering that this seems > not to > > be a problem for others. > > > > I found out that I can put a lock in my baselines preLoadDoIt for those > > indirectly referenced projects. > > > > Examlpe Artefact v1.0.1 > > > > > https://github.com/pharo-contributions/Artefact/blob/v1.0.1/src/BaselineOfA… > > > > loads github://zweidenker/Units/src (which is master). > > > > I found a solution for this: > > > > In the preLoadDoIt of my baseline I lock Units to a certain commit. > > > > preLoadDoIt > > Metacello new > > baseline: 'Units'; > > repository: 'github://zweidenker/Units:98d5a3d/src'; > > lock. > > > > This solves my problem in this example. > > > > Disadvantage is that I have to analyze everything which is loaded from > the > > projects I use and create a lock for it. > > > > Questions: > > 1.) Wouldn't it make sense to have some mechanism, perhaps in Rowan then, > > where I can say that a project which has a number can only reference > other > > projects with numbers? This would avoid the whole problem > > 2.) How do others solve this problem? > > > > addendum: I do not speak about project versions which are in development, > > here #stable or master are great features. But sometime when a project > has a > > certain state, and it gets a version, then it should not change..imho > > > > > > > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > > > > -- 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

Feb. 19, 2019

Re: [Pharo-users] Iceberg working with forks - can it be easier?

by Guillermo Polito

On Tue, Feb 19, 2019 at 2:08 AM Tim Mackinnon <tim(a)testit.works> wrote: > Hi Guille - thanks for taking the time to write this upâ¦ in the middle > there I finally spotted the crucial bit âclone the original, push to your > forkâ. I think thats what Iâve been doing wrong - and it leads to all kinds > of confusion (at least Iâm hoping this is what it is). > > You've been doing nothing wrong :). Both are valid things in Git, and to talk about rights and wrongs are fuzzy at the least there. > As I have cloned from my Fork (and in my defence - its because we were > given a repository that collides with the pharo one - exercism/pharo - and > P7 doesnât let us clone from that) - so Iâve had to clone from my fork. > Yeh, that's a bug. It should not be difficult to fix. The thing is, iceberg distinguishes repositories/projects by name. And names are obtained from the repository/project directory name. Then, the plugin made to simplify contributions to pharo, detects the repositories called "pharo" as pharo themselves and do some extra configuration. What happens in your case is that your repository suffers from that extra configuration, which is not the right thing to do in your case... One Idea that was poking around in my head is to be able to "rename" a project independently of its location in disk. We already have a metadata file at the root of the repository. We could add in that metadata file properties like: - the project's name (for example you could call it "pharo-exercism" in there, while keeping the tree structure) - an extra special property "isPharoRepository : true" that may be defined only for pharo - a canonical-repository url which could be used to compare against pharo's canonical url Implementing the detection of pharo's repository using any of those strategies could solve your problem... What do you think? > It all seemed to work until I started submitting my PRâs and then they > seem to include commits going much further back than I think they should > need Even wen I thought I was being careful and syncing to master - it > still seems to go back to some of my earliest work. > This looks like a mis-manipulation of branches, and It smells to me that it is not related to the issue above... Next time it happens, I'd like, if you can, that you share with me the exact: - branch - commitish that you're trying to make a PR from, to see if we can see the real cause, and at least build some docs on it ^^. > Now that we have managed to get the repo renamed - I will try working like > you have suggested and make sure that it is working like you describe - as > it shouldnât be as complicated as this to make clean isolated changes and > then submit them as a PR. (otherwise Pharo would fall apart). > > One question I do have however - is what is the best procedure if you > realised when making changes that > A) you forgot to make changes in a branch (so are working on master) > It depends if your changes have been pushed or not. 1) First thing is to fix your local branch with the expression I told in a previous email repo branch commit: repo branch commit parent. 2) If you have already pushed, that means that you have to rewrite the history on the remote side, and that would require a push force (from the command line so far, unless you would like to implement that in iceberg :P). > B) you are working in a branch but decide some of your changes should go > in another branch itself based on master (how to stash?) > There is no stash mechanism in iceberg (so far). What I do is: - I checkout the base branch (master in this case) in expert mode => do not touch my image code, then the image itself will work as a stash - I now checkout a new branch (that will "fork" from the last commit in my master branch) - I commit only the things I want to commit. (see that this is not much different from what you would have done from the terminal except that the checkout strategy will make the stashing unnecessary: - git stash - git checkout master - git checkout -b myBranch - git stash pop - git commit ) Then you can either - discard all your extra changes (I'd suggest to have committed them earlier :)) to be in a clean master+yournewchanges - or you can go back to your first branch > > These are 2 common scenarios Iâve found when trying to be a good citizen > for my little project. Do I have to go to the terminal to do this stuff - > or can I cleanly do these kinds of operations in Pharo (which I think you > should be able to do, as its so easy to get into either of those states). > > I think you can do everything so far except the push force. Still I'm not happy with what we have (and I'd like to have 48h days) :) To help in your first scenario: - It should not be difficult to get the reset on the UI ( https://github.com/pharo-vcs/iceberg/issues/1174) ;) - The same with the push force For the second scenario, what bothers me the most is the special checkout that may confuse people. Also, while you're doing it, you may have not committed your code anywhere => and that's dangerous, because you may lose it. So, imagine this: you are in branch A and you have these changes that you wan to put in branch B. Instead of doing strange stashing/checkout blah, you create a new branch temp/AtoB and commit there. And then you move to B and apply a smart cherry pick operation of your changes. Martin was visiting the team last week and he had a super nice prototype: you select what you want to cherry pick from a branch and it automatically selects all (static) dependencies in the same branch, and proposes you doing a commit/merge of that. I don't know how far are we from this, but it would be super nice to do easy backporting between branches (think pharo8 -> pharo7). Guille Thanks in advance. > > Tim > > On 18 Feb 2019, at 08:56, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Hi! > > On Fri, Feb 15, 2019 at 7:06 PM Tim Mackinnon <tim(a)testit.works> wrote: > >> Hi guys - Iâve spent a few hours scratching my head trying to understand >> why some of my Pull Requests to a project I had forked kept showing my >> previous commits when I thought I was all caught up. >> >> It suddenly dawned on me, that when I had forked, and then done some work >> and then submitted a PR, and then applied it upstream that my fork is now >> no longer in sync with its upstream counterpart. >> >> Having not done this in ages, it took me a while to then realise I have >> to do some git stuff to get it back in sync e.g. (and I think Iâve got this >> right) >> >> git fetch upstream (or whatever name you gave it) >> Git checkout master >> Git merge upstream/master >> > > When you did your clone, did you clone the original repository or your > fork's? > One way to simplify this workflow is: > - you clone always the original repository > - you create a branch and work there > - then you'll push your branch to your fork + fork > > That way your branch will be always up to date with the original > repository, and no need to sync (actually the sync is done automatically > when you push to your fork). > > Of course this assumes you're doing a new clone every time you work :). > > >> >> So I guess my question is - wouldnât it be helpful if this was a command >> in Iceberg? > > > It would, there are several places where we could simplify the workflow > for common cases, I agree. > > >> It seems quite common to fork a project (I think this is still >> recommended for pharo itself isnât it?) > > > I'd say its mandatory :). Otherwise you will not be able to push directly > to it because of permission problems (actually all main dev branches are > now blocked so **nobody**, not even admins, push to them directly). > > >> - and then at some point you need to catchup with that origin again? Or >> am I missing something? > > > Well, it really depends on the workflow you use. Above I've explained a > workflow that works when you clone every time. > Git is so complex and so low level that you can do lots of different > things with it. > > First thing is to understand what "catch up with origin" means. In my head > it only means: > - checkout your "to-catchup" branch > - merge the remote "to-catchup" branch and merge it > > All the rest is workflow dependent. Even (!!) I would argue that merging > is not, strictly speaking, a correct way to catch up: If you have made > changes into "to-catchup", then merging will not make both branches the > same, but your "to-catchup" branch may have extra commits that you did not > want to introduce... > > And here I'm not saying you should not merge, actually I do it most of the > times because I know that 90% of the times it will be ok, and I do rollback > when I realize I was in the other 10%... > > >> I guess lots of stuff can go wrong - but if it does - youâd still get the >> same problems on the command line. > > > Yes, and no. The "lots of stuff can go wrong" can be translated in most of > the cases to "I had a merge conflict". But this is not git, this is > git+pharo. > > The thing is that with Git, your code is dead in files. With Iceberg, your > code is in the files but it also may be alive in your image too. So > updating code for what you have existing instances, or announcement > subscriptions or other could (and probably will) mess up with the running > code... > So to the typical merge conflict, you may add breaking your running system. > > It just seems that for normal situations - it would be handy to run this >> straight in Pharo. >> >> Thoughts from the git experts? >> > > For these cases, you can do exactly as the command line from Iceberg's UI > > - change your branch to your "to-catchup" master > - fetch > - now you can go to the merge option, and choose to merge your remote > branch into your checked-out branch. > - and push > > Of course, this simple workflow works most of the times, but you may find > edge cases. > For those edge cases (typically updating iceberg itself, or trying to > update pharo itself), in the checkout preview you will have the combo with > the checkout strategy: choose the expert mode "do not load the code". This > option will change the branch on git's world, but it will not load the code > in your image. > > That is useful if you have living instances for example. > This option will though make a diff between the checked out version and > your image code and show you differences. (think this as a git reset --soft) > > To me the fact that we are manipulating live code loaded in the image and > not dead files makes a huge difference, and this makes that extrapolating > git commands to iceberg is not so straight forward :). Also, understanding > that git is stateful/context dependant, and applying an operation means > changing your current state (modify your current branch, change your > current branch) is useful to see the consequences. > > In any case, any more concrete suggestions for enhancing this workflow are > welcome. I think that neither Esteban, Pablo, me nor other contributors are > skilled UI designers, and thinking about the best way to present a usecase > to a user is super super hard :). > > Guille, from his vacations > > > -- 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

Feb. 19, 2019

Re: [Pharo-users] RBPattern syntax

by Henrik Sperre Johansen

Manuel Leuenberger wrote > Hi, > > I am looking into the RB pattern language for refactoring and I am having > trouble matching and replacing non-trivial pattern. Given the following > excerpt, I want to match "b shape > <rest> > ." and replace it with "b shape: [ :x | x > <rest> > ]" > > b shape circle > size: 15; > color: (Color veryLightGray alpha: 0.4); > if: [ :value | toBeRed includes: value ] fillColor: Color red. > > How can I do this? I tried using "b shape ``@messages", but this only > matches "b shape circle". Using "b shape `message `;middle; `;last" for > some reason then also matches the following, which I think it should not: > > b edges > moveBehind; > connectToAll: [ :v | > v \\ 20 ~~ 0 > ifTrue: [ Array with: v + 1 with: v + 20 ] > ifFalse: [ Array with: v + 20 ] ]. > > There seems not be too much documentation about the pattern language, only > found tests, some short help description from RB and Yuriy's MatchTool. > How can I match the node correctly? > > Cheers, > Manuel The best documentation is at https://refactory.com/rewrite-tool/ What isn't covered, is cascade nodes (`@;messages1), but my first naive attempt did not work as I expected on your example; '(b shape `@method: `@keywords) @;messages1: `@args' -> 'b shape: [ :x | (x `@method: `@keywords) @;messages1: `@args ]' b shape circle size: 15; color: (Color veryLightGray alpha: 0.4); if: [ :value | toBeRed includes: value ] fillColor: Color red -> b shape: [ :x | x circle size: 15 ]; shape: [ :x | x circle color: (Color veryLightGray alpha: 0.4) ]; shape: [ :x | x circle if: [ :value | toBeRed includes: value ] fillColor: Color red ] -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 19, 2019

Re: [Pharo-users] Partition/Sync ready databases for Pharo?

by Tim Mackinnon

When you say Fossil - are you referring to "https://fossil-scm.org/index.html/doc/trunk/www/index.wikiâ ? Iâve seen it come up a few times - is it good? But rather than subvert Estebanâs thread - if it is the above, can you hook into it to save application runtime artefacts such that a distributed application can read them back (Iâd just sort of assumed it was for saving code and docs) - but it sounds like it can go a bit deeper than that (which seems quite interesting and perhaps what Esteban is after?) Tim > On 19 Feb 2019, at 01:46, Pierce Ng <pierce(a)samadhiweb.com> wrote: > > On Mon, Feb 18, 2019 at 02:56:10PM -0300, Esteban Maringolo wrote: >> I have the requirement that an app that I'm prospecting must be able >> to work offline and synchronize changes once the connection is >> restored. >> >> I want to avoid having to write "sync" logic manually. > > I've not done this for real before, but here are some possibilities: > > - https://github.com/sqlite-sync/SQLite-sync.com > - http://www.symmetricds.org/ > - https://github.com/CanonicalLtd/dqlite > - Use Fossil as your database > > >

Feb. 19, 2019

Phorms repository?

by Manuel Leuenberger

Hi, I am looking into AST transformations and played with the RBPattern language, which isn't quite powerful enough to do what I want to do (my matching patterns are more complex). I found papers about Phorms, which seems like a nice language to investigate. But I could not find any repository to load the code from. Where can I find the Phorms code? Cheers, Manuel

Feb. 19, 2019

Re: [Pharo-users] OSProcess / OSSubprocess / LibC uniqueInstance

by Albrecht Baur

Thank you. The Metacello snippet helps. It loads a newer version than that from the catalog browser. But 2 more questions: 1.: Is there a reason not to use just ... LibC uniqueInstance system: 'zip -r 123.zip zipme/' ... ? And 2.: Is it ok to use OSSubprocess on in 64 bit images even though the documentation says it doesn't work ? (but it does) -> https://github.com/pharo-contributions/OSSubprocess#installation On 19.02.19 13:05, Serge Stinckwich wrote: > Thank you Thierry. > > On Tue, Feb 19, 2019 at 12:48 PM Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > Hi Serge, Albrecht, > > loading OSProcess directly with the following expression works: > > Metacello new > Â Â configuration: 'OSProcess'; > Â Â repository: 'http://www.squeaksource.com/MetacelloRepository'; > Â Â load > > There is still some work to be done on OSProcess adaptation to Pharo > 7, but they are in rarely used parts. > > Regards, > > Thierry > > Le mar. 19 fÃ©vr. 2019 Ã 12:19, Albrecht Baur via Pharo-users > <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> > a Ã©crit : > > > > I need to execute OS commands from within a x64 pharo 7.01 image > on centos7 (for example: 'zip -r 123.zip zipme/'). > > > > I found these 3 tools: OSProcess, OSSubprocess, LibC uniqueInstance > > > > But I did not find any docu on which one to use for which use case. > > > > OSProcess is in the catalog browser but fails loading because of > ByteArray>>ifNotNilDo: > > -> So OSProcess is not to be used with p7 ? > > > > OSSubprocess loads via catalog browser and the following snippet > works (even though 64 bit): > > > > OSSUnixSubprocess new > >Â Â Â command: 'zip'; > >Â Â Â arguments: #('-r' '123.zip' 'zipme'); > >Â Â Â redirectStdout; > >Â Â Â runAndWaitOnExitDo: [ :process :outStringÂ | > >Â Â Â Â Â outString inspect > >Â Â Â ] > > > > So is it ok to use OSSubprocess with 64 bit even though > documented as 32 bit only ? (here: > https://github.com/pharo-contributions/OSSubprocess#installation) > > > > LibC uniqueInstance system: 'zip -r 123.zip zipme/' > > ... works, but I don't know if its the right tool for this. > > > > Is there somewhere more info on which tool to use for which use > case ? > > > > Thanks in advance! > > > > Albrecht > > > > PS.: I need to use zip as os process only because of this issue: > https://github.com/pharo-project/pharo/issues/2584 > > > > -- > Serge Stinckwic > âhâ > > Int. Research Unit > Â on Modelling/Simulation of Complex Systems (UMMISCO) > âSorbonne University > Â (SU) > French National Research Institute for Sustainable Development (IRD)â > U > âniversity of YaoundÃ© Iâ, Cameroun > "Programs must be written for people to read, and only incidentally > for machines to execute." > https://twitter.com/SergeStinckwich > > â

Feb. 19, 2019