June 2018 - Pharo-users - lists.pharo.org

[ANN] Pharo Launcher v1.2 release

by Christophe Demarey

Hi all, I just released PharoLauncher 1.2. It includes a new windows installer that you can use without administrator privileges as well as binary signing for OS X and Windows. Also, Pharo Launcher is not anymore identified as âPharoâ application and comes with its own icon. Here is the changelog (details on https://github.com/pharo-project/pharo-launcher/issues <https://github.com/pharo-project/pharo-launcher/issues>): New features: #21 Bless the DMG #46 sign pharo launcher app for windows #103 No way to rename a local template #107 Unable to add a description for the image using the Launcher UI #121 You can't see/sort images by last modified date Improvements: #69 Import command should also import pharo-local directory #70 Import command should delete origin folder if empty #73 Managers of Download of VMs and images should be in their own packages #76 Use https instead of http to requests the pharo file server #82 Official Distributions loads 32bit versions on 64bit System (i.e. provide better information on templates architecture) #86 Sort Existing Images Case-Insensitive #98 Copy and subfolders problem (contents no copied) #101 Templates from a local image are listed in "downloaded". "local" would be a better name #102 Template Cleared at Startup setting is enabled, making it weird when trying to use the template feature #106 Import could work if we select the parent folder of an image #109 Use latest pre-Spur VM to determine the image version #122 The Run without settings icon looks like a funny grey/which blob (missing alpha correction) Bux fixes: #41 #selectedMorphList was sent to nil #67 bash is not a command usable under windows #68 Does not launch images on Windows #85 Double click on an existing image open a file selector #88 Pharo Launcher on Windows > Failing #104 GUI bug makes Launcher unusable #110 Image launch not reliable on Windows #119 MessageNotUnderstood exception on launch #123 The status bar of the Launcher is broken, so can't easily show image descriptions Big thanks to all contributors: code, issues report, comments, advices. You can get platform bundles from pharo download page or files.pharo.org <http://files.pharo.org/>: http://files.pharo.org/pharo-launcher/1.2/ <http://files.pharo.org/pharo-launcher/1.2/> Regards, Christophe.

June 19, 2018

Re: [Pharo-users] Help contributing a fix to pharo - docs seem out of date again?

by Guillermo Polito

Strange... I'm with Esteban there, I'd need more information to reproduce it. I've just done $ wget -O - get.pharo.org/70+vm | bash $ ./pharo-ui Pharo.image - Open iceberg - Repair Pharo by cloning my (really out of date) fork (guillep/pharo) - Fetch - Repair -> Create branch And I have the "New branch" option. On Tue, Jun 19, 2018 at 3:28 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On 19 Jun 2018, at 15:18, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi Guillermo - it sounds like Iâm on the right track - the only thing that > caught me out was in the latest V7 there is no ânew branchâ - I have to > have an issue number? The picture in your doc shows both possibilities? > > > how did you arrive there? > seems to me that there should always be the opportunity of just branch. If > not, may be there is an error. > > Esteban > > > For now, I found a bug and created an issue, and so can experiment with > that - but I think it is handy to create a generic branch so that you can > experiment (while easily tracking your changes)? > > Tim > > On 19 Jun 2018, at 14:01, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Hi, > > On Tue, Jun 19, 2018 at 2:26 PM Tim Mackinnon <tim(a)testit.works> wrote: > >> Hi - a few weeks ago, I contributed a tiny fix to Pharo 7 -and the >> instructions seemed to work really well. >> >> Iâve since come back to try and do some more over lunch (I was thinking >> Iâd like to dig out the changes I worked out for using the AST and cursor >> to make senders/implements work properly and not just use the selected >> text). >> >> My first problem was that my fork of Pharo from many months ago was out >> of date - I think the instructions on >> https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo should >> probably mention this subtlety. >> > >> It took me ages to figure out what to do - this was the clue ( >> https://help.github.com/articles/syncing-a-fork/) - and of particular >> note the the tiny bit at the bottom to ensure you Push your changes back to >> your GitHub fork (I slightly complicated myself by using IntelliJ to do >> this - doable but you need to be aware of whats going on). I did this in a >> separate non-pharo directory (I think thats what you would recommend right? >> Then you can keep updating it from time to time?) >> > > Usually, you don't care. You don't need to update your fork :) > You only need to: > - clone/locate your repository in disk > - fetch (this will find your commit in the pharo repository) > - create a new branch X > - push branch X to your fork > - make a pull request > > The contribution process never goes through master nor development, so it > does not really matter if they are updated. > And that's what I was showing in my videos because there is nothing else > to it :) > > >> >> Having got my GitHub fork caught up with pharo/development - I then have >> the Local Repo Missing error (expected) - and now when I go to repair it I >> can either clone again (which is the instructions online) - or âLocate this >> repository in your file systemâ. As Iâve had to already check everything >> out to catch up to pharo/dev I chose to locate. >> >> I then get a Fetch require msg (expected) >> >> I then choose to use Fetch (Iâm not sure what the Repair repository >> picture is now about?) - the text does mention I will become detached, so >> Iâve stuck to that >> >> Iâm not sure why the âsolving a detached working copyâ is further down >> the page - but Iâve jumped to that >> >> It says I need to synchronise both (image and repo) - but then says its >> easier to do a branch - and then says a nice alternative is to create a >> temp branch like temp/synch - however I canât see how to do that as there >> is only Crete new Branch from Issue now (the picture shows that plus New >> Branch). >> > > I don't see what's the problem, maybe the UI can be enhanced to be more > explicit. > But you can just select "New branch" and create a branch with any name. > > I'll go a bit deeper here: > - you just downloaded a new image that was built from commit 100 > - In the meantime, while you downloaded your image, a new PR would have > been integrated in pharo, so now the development branch may not be anymore > on commit 100 but on commit 101. > - Even worse! There is no branch at all pointing to 100, your image's > commit > - So the safest way to work (because updating the image may be dangerous > not because of Iceberg :)) is to create a new branch on your commit. > > However, while this is the recommended way to work on Pharo, on other > projects you can do a more normal workflow: checkout, pull. > > Does this answer it? Maybe I've missed something? > > > >> >> Am I on the right track here? If I want try something out - do I just >> create myself a new issue (or is there a temp issue anyway?) >> >> Tim >> > > > -- > > 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 > > > > -- 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

June 19, 2018

Re: [Pharo-users] [ann] gt documenter

by Tudor Girba

Hi, Moz2D is one of the backends of Sparta, the canvas behind Bloc. The repository is here: https://github.com/syrel/Moz2D It comes as a VM plugin. When you load Bloc and Sparta, the loading process automatically also downloads the plugin and installs it in the VM. On Linux, this only works for Pharo 64bit installations. So, all you would need to do is to take a fresh Pharo 64 image + vm and then load: Metacello new baseline: 'GToolkit'; repository: 'github://feenkcom/gtoolkit/src'; load. If it does not work, it would be useful for us to debug that situation. Good luck with your thesis. Cheers, Doru > On Jun 19, 2018, at 3:26 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Hi, > > I will (once I have deliver my PhD thesis on upcoming June 25th). There > is any place where Moz2D installation is documented? Being a such > integral part of the font rendering capabilities of Documenter I > couldn't find any place in its documentation dealing with Moz2D as > prerequisite and addressing its installation. > > Cheers, > > Offray > > > On 19/06/18 03:04, Tudor Girba wrote: >> Hi Offray, >> >> Would you be able to retry the installation as mentioned below, and let us know if you still encounter issues? >> >> Cheers, >> Doru >> >> >>> On Jun 16, 2018, at 8:24 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Hi, >>> >>> If Moz2D is installed, the fonts should work fine. >>> >>> Can you please try the installation again? And if it does not work, please let me know if in >>> Settings Browser / Appearance / Bloc / Preferable Sparta renderering backend >>> you see Moz2D or not. >>> >>> >>> Cheers, >>> Doru >>> >>> >>>> On Jun 15, 2018, at 2:31 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >>>> >>>> Hi Doru, >>>> >>>> Thanks for the update in Markdown. I will try to bring better Markdown >>>> support in Pharo by developing my ideas on a Playground for Markdown >>>> with syntax highlighting, image preview and so on and maybe I can help >>>> in incorporating them in GT Documenter on Pharo 7. >>>> >>>> I can confirm that fonts didn't work on Manjaro on 64 bits installation >>>> running Pharo 64b previously, but maybe in Pharo 7 installation will be >>>> smoother, including font installation via Moz2D integration (nix package >>>> manager has been a real asset in our workshops in multiple Unix >>>> environments, including Mac and several Gnu/Linux flavors, so maybe it >>>> can help with Moz2D engine and fonts integration). >>>> >>>> Cheers, >>>> >>>> Offray >>>> >>>> >>>> On 15/06/18 00:56, Tudor Girba wrote: >>>>> Hi, >>>>> >>>>> I am happy you like it. >>>>> >>>>> Fonts should work with a Pharo 64b installation on Linux, including Manjaro. Can you confirm that you use a Pharo 64bit and that it does not work? If yes, can you describe how you are installing Pharo and GToolkit? >>>>> >>>>> Markdown is certainly interesting, but it is not our focus at this point. We are building on top of Pillar. There are several reasons for it, two of them being: >>>>> 1. To build the experience we want to, we need deep control over the markup language and Pillar provides that in Pharo. >>>>> 2. Pillar is the de facto documentation markup used in Pharo, and our primary focus is to support new kinds of development workflows in this environment, including handling documentation. >>>>> >>>>> GT 2nd generation will indeed not be part of Pharo 7, but will be loadable in it. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> >>>>>> On Jun 15, 2018, at 3:47 AM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >>>>>> >>>>>> Cool! I hope to see how this could be integrated in Grafoscopio once Documenter is better integrated with Pharo, for example addressing the font issues already reported in the mailing list on Manjaro Linux (64 bits) and in the thread at [1] and also the Markdown integration possibilities (which are never answered). >>>>>> [1] https://twitter.com/feenkcom/status/996310432225820672 >>>>>> >>>>>> I think it will not part of Pharo 7 but, may be in Pharo 8 we can start to use it in a more confident day to day fashion. >>>>>> >>>>>> Keep the interesting work. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Offray >>>>>> >>>>>> On 13/06/18 15:57, Tudor Girba wrote: >>>>>>> Hi, >>>>>>> >>>>>>> We are happy to announce a new leap of GToolkit Documenter, the tool for manipulating live documents directly in the development environment: >>>>>>> https://github.com/feenkcom/gtoolkit-documenter >>>>>>> >>>>>>> Documenter is part of the second generation GToolkit project, it is based on Bloc and works with the latest Pillar. It is mainly developed by Juraj Kubelka. >>>>>>> >>>>>>> Attached you can see a preview of how documents look like: >>>>>>> >>>>>>> <gt-documenter.png> >>>>>>> >>>>>>> At its core it offers a live editor for manipulating Pillar documents. The interaction happens seamlessly directly in the text editor, and it can be combined with different types of previews to serve several classes of use cases: >>>>>>> â¢ code documentation >>>>>>> â¢ tutorials >>>>>>> â¢ interactive data notebook >>>>>>> >>>>>>> >>>>>>> Code documentation >>>>>>> ---- >>>>>>> Documenter complements the GToolkit Examples engine to redefine code documentation. When practicing example-driven development, examples get written as part of the typical development. Once examples exist, they can be quickly put together in a document to form documentation. For example, the linked picture shows the comment of a class containing a visual explanation: >>>>>>> https://twitter.com/feenkcom/status/973899862482866176 >>>>>>> >>>>>>> You can see a live example of documentation by inspecting the following snippet: >>>>>>> GtDocumenter editorForText: BrToggleExamples comment. >>>>>>> >>>>>>> >>>>>>> Tutorials: >>>>>>> ---- >>>>>>> Documenter offers a new experience of writing tutorials for Pharo by enabling the creation and embedding of Epicea change sessions directly in the document. For example, take a look at the following animation: >>>>>>> https://twitter.com/feenkcom/status/999975333972541440 >>>>>>> >>>>>>> The document shows a method on top, and a change preview at the bottom showing both the code and the associated diff to the state from the image. Applying the change updates both the change view (no more diff), and method preview. This speeds up significantly the process of going through a tutorial. Furthermore, given that now the document shows the diff to the current image, the reader can safely explore alternative scenario and come back to the tutorial at any time without losing the overview. >>>>>>> >>>>>>> The size of the preview can also be adjusted live: >>>>>>> https://twitter.com/feenkcom/status/1001152789874167808 >>>>>>> https://twitter.com/feenkcom/status/1001407762285375490 >>>>>>> >>>>>>> You can see a live tutorial by inspecting: >>>>>>> IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillarâ. >>>>>>> >>>>>>> >>>>>>> Interactive data notebook: >>>>>>> ---- >>>>>>> A Documenter document can also be used as an interactive notebook. Internally it essentially acts as a playground: >>>>>>> â¢ it supports defining variables in code snippets, and >>>>>>> â¢ the execution of code shows an embedded inspector. >>>>>>> >>>>>>> For example: >>>>>>> https://twitter.com/feenkcom/status/996310432225820672 >>>>>>> https://twitter.com/feenkcom/status/1002851190475026432 >>>>>>> >>>>>>> An example, can be seen by inspecting: >>>>>>> IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit' / 'doc' / 'gtoolkit' / 'gtoolkit.pillar'. >>>>>>> >>>>>>> >>>>>>> As always, please do let us know what you think. >>>>>>> >>>>>>> Enjoy, >>>>>>> The feenk team >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> www.feenk.com >>>>>>> >>>>>>> "If you can't say why something is relevant, >>>>>>> it probably isn't." >>>>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> www.feenk.com >>>>> >>>>> "Being happy is a matter of choice." >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Every now and then stop and ask yourself if the war you're fighting is the right one." >>> >>> >>> >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Yesterday is a fact. >> Tomorrow is a possibility. >> Today is a challenge." >> >> >> >> >> >> > > -- www.tudorgirba.com www.feenk.com "No matter how many recipes we know, we still value a chef."

June 19, 2018

Re: [Pharo-users] Help contributing a fix to pharo - docs seem out of date again?

by Esteban Lorenzano

> On 19 Jun 2018, at 15:18, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi Guillermo - it sounds like Iâm on the right track - the only thing that caught me out was in the latest V7 there is no ânew branchâ - I have to have an issue number? The picture in your doc shows both possibilities? how did you arrive there? seems to me that there should always be the opportunity of just branch. If not, may be there is an error. Esteban > > For now, I found a bug and created an issue, and so can experiment with that - but I think it is handy to create a generic branch so that you can experiment (while easily tracking your changes)? > > Tim > >> On 19 Jun 2018, at 14:01, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >> >> Hi, >> >> On Tue, Jun 19, 2018 at 2:26 PM Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >> Hi - a few weeks ago, I contributed a tiny fix to Pharo 7 -and the instructions seemed to work really well. >> >> Iâve since come back to try and do some more over lunch (I was thinking Iâd like to dig out the changes I worked out for using the AST and cursor to make senders/implements work properly and not just use the selected text). >> >> My first problem was that my fork of Pharo from many months ago was out of date - I think the instructions on https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo <https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo> should probably mention this subtlety. >> >> It took me ages to figure out what to do - this was the clue (https://help.github.com/articles/syncing-a-fork/ <https://help.github.com/articles/syncing-a-fork/>) - and of particular note the the tiny bit at the bottom to ensure you Push your changes back to your GitHub fork (I slightly complicated myself by using IntelliJ to do this - doable but you need to be aware of whats going on). I did this in a separate non-pharo directory (I think thats what you would recommend right? Then you can keep updating it from time to time?) >> >> Usually, you don't care. You don't need to update your fork :) >> You only need to: >> - clone/locate your repository in disk >> - fetch (this will find your commit in the pharo repository) >> - create a new branch X >> - push branch X to your fork >> - make a pull request >> >> The contribution process never goes through master nor development, so it does not really matter if they are updated. >> And that's what I was showing in my videos because there is nothing else to it :) >> >> >> Having got my GitHub fork caught up with pharo/development - I then have the Local Repo Missing error (expected) - and now when I go to repair it I can either clone again (which is the instructions online) - or âLocate this repository in your file systemâ. As Iâve had to already check everything out to catch up to pharo/dev I chose to locate. >> >> I then get a Fetch require msg (expected) >> >> I then choose to use Fetch (Iâm not sure what the Repair repository picture is now about?) - the text does mention I will become detached, so Iâve stuck to that >> >> Iâm not sure why the âsolving a detached working copyâ is further down the page - but Iâve jumped to that >> >> It says I need to synchronise both (image and repo) - but then says its easier to do a branch - and then says a nice alternative is to create a temp branch like temp/synch - however I canât see how to do that as there is only Crete new Branch from Issue now (the picture shows that plus New Branch). >> >> I don't see what's the problem, maybe the UI can be enhanced to be more explicit. >> But you can just select "New branch" and create a branch with any name. >> >> I'll go a bit deeper here: >> - you just downloaded a new image that was built from commit 100 >> - In the meantime, while you downloaded your image, a new PR would have been integrated in pharo, so now the development branch may not be anymore on commit 100 but on commit 101. >> - Even worse! There is no branch at all pointing to 100, your image's commit >> - So the safest way to work (because updating the image may be dangerous not because of Iceberg :)) is to create a new branch on your commit. >> >> However, while this is the recommended way to work on Pharo, on other projects you can do a more normal workflow: checkout, pull. >> >> Does this answer it? Maybe I've missed something? >> >> >> >> Am I on the right track here? If I want try something out - do I just create myself a new issue (or is there a temp issue anyway?) >> >> Tim >> >> >> -- >> >> 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 >

June 19, 2018

Re: [Pharo-users] [ann] gt documenter

by Offray Vladimir Luna CÃ¡rdenas

Hi, I will (once I have deliver my PhD thesis on upcoming June 25th). There is any place where Moz2D installation is documented? Being a such integral part of the font rendering capabilities of Documenter I couldn't find any place in its documentation dealing with Moz2D as prerequisite and addressing its installation. Cheers, Offray On 19/06/18 03:04, Tudor Girba wrote: > Hi Offray, > > Would you be able to retry the installation as mentioned below, and let us know if you still encounter issues? > > Cheers, > Doru > > >> On Jun 16, 2018, at 8:24 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> If Moz2D is installed, the fonts should work fine. >> >> Can you please try the installation again? And if it does not work, please let me know if in >> Settings Browser / Appearance / Bloc / Preferable Sparta renderering backend >> you see Moz2D or not. >> >> >> Cheers, >> Doru >> >> >>> On Jun 15, 2018, at 2:31 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >>> >>> Hi Doru, >>> >>> Thanks for the update in Markdown. I will try to bring better Markdown >>> support in Pharo by developing my ideas on a Playground for Markdown >>> with syntax highlighting, image preview and so on and maybe I can help >>> in incorporating them in GT Documenter on Pharo 7. >>> >>> I can confirm that fonts didn't work on Manjaro on 64 bits installation >>> running Pharo 64b previously, but maybe in Pharo 7 installation will be >>> smoother, including font installation via Moz2D integration (nix package >>> manager has been a real asset in our workshops in multiple Unix >>> environments, including Mac and several Gnu/Linux flavors, so maybe it >>> can help with Moz2D engine and fonts integration). >>> >>> Cheers, >>> >>> Offray >>> >>> >>> On 15/06/18 00:56, Tudor Girba wrote: >>>> Hi, >>>> >>>> I am happy you like it. >>>> >>>> Fonts should work with a Pharo 64b installation on Linux, including Manjaro. Can you confirm that you use a Pharo 64bit and that it does not work? If yes, can you describe how you are installing Pharo and GToolkit? >>>> >>>> Markdown is certainly interesting, but it is not our focus at this point. We are building on top of Pillar. There are several reasons for it, two of them being: >>>> 1. To build the experience we want to, we need deep control over the markup language and Pillar provides that in Pharo. >>>> 2. Pillar is the de facto documentation markup used in Pharo, and our primary focus is to support new kinds of development workflows in this environment, including handling documentation. >>>> >>>> GT 2nd generation will indeed not be part of Pharo 7, but will be loadable in it. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>>> On Jun 15, 2018, at 3:47 AM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >>>>> >>>>> Cool! I hope to see how this could be integrated in Grafoscopio once Documenter is better integrated with Pharo, for example addressing the font issues already reported in the mailing list on Manjaro Linux (64 bits) and in the thread at [1] and also the Markdown integration possibilities (which are never answered). >>>>> [1] https://twitter.com/feenkcom/status/996310432225820672 >>>>> >>>>> I think it will not part of Pharo 7 but, may be in Pharo 8 we can start to use it in a more confident day to day fashion. >>>>> >>>>> Keep the interesting work. >>>>> >>>>> Cheers, >>>>> >>>>> Offray >>>>> >>>>> On 13/06/18 15:57, Tudor Girba wrote: >>>>>> Hi, >>>>>> >>>>>> We are happy to announce a new leap of GToolkit Documenter, the tool for manipulating live documents directly in the development environment: >>>>>> https://github.com/feenkcom/gtoolkit-documenter >>>>>> >>>>>> Documenter is part of the second generation GToolkit project, it is based on Bloc and works with the latest Pillar. It is mainly developed by Juraj Kubelka. >>>>>> >>>>>> Attached you can see a preview of how documents look like: >>>>>> >>>>>> <gt-documenter.png> >>>>>> >>>>>> At its core it offers a live editor for manipulating Pillar documents. The interaction happens seamlessly directly in the text editor, and it can be combined with different types of previews to serve several classes of use cases: >>>>>> â¢ code documentation >>>>>> â¢ tutorials >>>>>> â¢ interactive data notebook >>>>>> >>>>>> >>>>>> Code documentation >>>>>> ---- >>>>>> Documenter complements the GToolkit Examples engine to redefine code documentation. When practicing example-driven development, examples get written as part of the typical development. Once examples exist, they can be quickly put together in a document to form documentation. For example, the linked picture shows the comment of a class containing a visual explanation: >>>>>> https://twitter.com/feenkcom/status/973899862482866176 >>>>>> >>>>>> You can see a live example of documentation by inspecting the following snippet: >>>>>> GtDocumenter editorForText: BrToggleExamples comment. >>>>>> >>>>>> >>>>>> Tutorials: >>>>>> ---- >>>>>> Documenter offers a new experience of writing tutorials for Pharo by enabling the creation and embedding of Epicea change sessions directly in the document. For example, take a look at the following animation: >>>>>> https://twitter.com/feenkcom/status/999975333972541440 >>>>>> >>>>>> The document shows a method on top, and a change preview at the bottom showing both the code and the associated diff to the state from the image. Applying the change updates both the change view (no more diff), and method preview. This speeds up significantly the process of going through a tutorial. Furthermore, given that now the document shows the diff to the current image, the reader can safely explore alternative scenario and come back to the tutorial at any time without losing the overview. >>>>>> >>>>>> The size of the preview can also be adjusted live: >>>>>> https://twitter.com/feenkcom/status/1001152789874167808 >>>>>> https://twitter.com/feenkcom/status/1001407762285375490 >>>>>> >>>>>> You can see a live tutorial by inspecting: >>>>>> IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillarâ. >>>>>> >>>>>> >>>>>> Interactive data notebook: >>>>>> ---- >>>>>> A Documenter document can also be used as an interactive notebook. Internally it essentially acts as a playground: >>>>>> â¢ it supports defining variables in code snippets, and >>>>>> â¢ the execution of code shows an embedded inspector. >>>>>> >>>>>> For example: >>>>>> https://twitter.com/feenkcom/status/996310432225820672 >>>>>> https://twitter.com/feenkcom/status/1002851190475026432 >>>>>> >>>>>> An example, can be seen by inspecting: >>>>>> IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit' / 'doc' / 'gtoolkit' / 'gtoolkit.pillar'. >>>>>> >>>>>> >>>>>> As always, please do let us know what you think. >>>>>> >>>>>> Enjoy, >>>>>> The feenk team >>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> www.feenk.com >>>>>> >>>>>> "If you can't say why something is relevant, >>>>>> it probably isn't." >>>>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "Being happy is a matter of choice." >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Every now and then stop and ask yourself if the war you're fighting is the right one." >> >> >> >> > -- > www.tudorgirba.com > www.feenk.com > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > > > > >

June 19, 2018

Re: [Pharo-users] [Pharo-dev] [Ann] Iceberg v1.1.1

by Guillermo Polito

On Tue, Jun 19, 2018 at 2:07 PM Norbert Hartl <norbert(a)hartl.name> wrote: > Hi, > > let me wear the project manager hat for a moment. > let me too, because the fact that I'm younger does not mean I don't know, right? :) > > Am 19.06.2018 um 10:59 schrieb Guillermo Polito <guillermopolito(a)gmail.com > >: > > Hi, > > About why 1.1.1 and not 1.2.0. Itâs not about cheap or not, but about > semantics :) > > > for me âcaring about semanticsâ is just one of the top ten justifications > developers use for the changes they did. > Maybe, and putting the hat of project manager is usually a justification for somebody that is not good at technical stuff. But I know that's not like it, so please let's not enter into this, I've felt a little insulted by this comment... > > We can agree that there is no hard rule on versionning, do we? But I try > to follow the following guidelines (delta my own interpretation that adds > some subjectivity :P) > - Major Version will change when we break backwards compatibility > - Minor Version will change when new features are added > - Otherwise, patch version will change. > > There is only one hard rule for me and that is knowing about the risk to > take. > That's a matter of conventions. We agree that version 1.1.x is compatible with 1.1.y. > So if we take the patch version it should only include important bug fixes > and nothing else. I would argue that only #864, #862, #858 and #854 qualify > for such a patch if at all. > So they are to my view. They should not introduce any compatibility issue. And if they do, that's an error, but we are too few helping here, doing our best... > Not sure about #860 because the title is not specific enough. > Please, I'll let you judge it for yourself https://github.com/pharo-vcs/iceberg/pull/860/files But to me that change applies to patch. It actually fixes a compatibility issue that was introduced in 1.1.0. > The point for me is that I want my project to rely on something like 1.1.x > because I donât want anything to change that breaks my software. And I can > tell you that most developers underestimate the side-effects of changes. > I'm well aware of this. But do you have a concrete issue? > > So I donât assign a new version number regarding the number of changes but > about what they mean... > > > To mean they mean it is a risk to use that version and you define how big > that is. > We are trying to do weekly releases, we could do better but again. I can count with my hand fingers people contributing with actual commits and issues in the issue tracker. > > Now, I considered myself this release as a patch because mostly little > bugs here and there were fixed. > Moreover, one of the changes done in the credentials manager was to > *recover* some backwards compatibility for people setting up credentials in > settings files. > Of course, to this we add to this that my own interpretation saying that > the changes do not break compatibility nor add features :) > > You see you said âmostly bugsâ and that is the error already. > I'm sorry for not being perfect... > I mean we come from an amateurish behaviour that we change released > artefacts. > I assure you I do my best on it, and I'm one of the first that cries aloud when there are versionning and dependencies problems. What I do not understand if this mail was meant as a lesson for the community or should I take it personally... > That is not discussable just a no-go. > I know and I'm against it. So we agree, right? > The reason was it would have wasted a huge amount of time to do a new > version. So ok it was a loose-loose situation. Now we can do it better and > I want something far less amateurish. So you can discuss your semantics > about what major and minor versions in pharo mean but patch needs to be the > definition of the combination: least risk - highest value. > Would you help us measuring the risk? > > Now, this is the kind of subjective topic that starts a flamewar, but Iâd > prefer to use my time on somewhat else ^^. > > > You may not like to talk about these things but I do. And you should > listen. > I mostly do [enjoy such discussions] but what I learn from this discussion is: - you think I'm stupid, or young, or both, so I don't know - we are all amateurs > I have no use for an environment where people only care about coding new > cool stuff. > I'm fu*** trying to make Iceberg as stable as possible, If I was just wanting to do new cool stuff I would not be doing this.

June 19, 2018

Re: [Pharo-users] Help contributing a fix to pharo - docs seem out of date again?

by Tim Mackinnon

Hi Guillermo - it sounds like Iâm on the right track - the only thing that caught me out was in the latest V7 there is no ânew branchâ - I have to have an issue number? The picture in your doc shows both possibilities? For now, I found a bug and created an issue, and so can experiment with that - but I think it is handy to create a generic branch so that you can experiment (while easily tracking your changes)? Tim > On 19 Jun 2018, at 14:01, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi, > > On Tue, Jun 19, 2018 at 2:26 PM Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: > Hi - a few weeks ago, I contributed a tiny fix to Pharo 7 -and the instructions seemed to work really well. > > Iâve since come back to try and do some more over lunch (I was thinking Iâd like to dig out the changes I worked out for using the AST and cursor to make senders/implements work properly and not just use the selected text). > > My first problem was that my fork of Pharo from many months ago was out of date - I think the instructions on https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo <https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo> should probably mention this subtlety. > > It took me ages to figure out what to do - this was the clue (https://help.github.com/articles/syncing-a-fork/ <https://help.github.com/articles/syncing-a-fork/>) - and of particular note the the tiny bit at the bottom to ensure you Push your changes back to your GitHub fork (I slightly complicated myself by using IntelliJ to do this - doable but you need to be aware of whats going on). I did this in a separate non-pharo directory (I think thats what you would recommend right? Then you can keep updating it from time to time?) > > Usually, you don't care. You don't need to update your fork :) > You only need to: > - clone/locate your repository in disk > - fetch (this will find your commit in the pharo repository) > - create a new branch X > - push branch X to your fork > - make a pull request > > The contribution process never goes through master nor development, so it does not really matter if they are updated. > And that's what I was showing in my videos because there is nothing else to it :) > > > Having got my GitHub fork caught up with pharo/development - I then have the Local Repo Missing error (expected) - and now when I go to repair it I can either clone again (which is the instructions online) - or âLocate this repository in your file systemâ. As Iâve had to already check everything out to catch up to pharo/dev I chose to locate. > > I then get a Fetch require msg (expected) > > I then choose to use Fetch (Iâm not sure what the Repair repository picture is now about?) - the text does mention I will become detached, so Iâve stuck to that > > Iâm not sure why the âsolving a detached working copyâ is further down the page - but Iâve jumped to that > > It says I need to synchronise both (image and repo) - but then says its easier to do a branch - and then says a nice alternative is to create a temp branch like temp/synch - however I canât see how to do that as there is only Crete new Branch from Issue now (the picture shows that plus New Branch). > > I don't see what's the problem, maybe the UI can be enhanced to be more explicit. > But you can just select "New branch" and create a branch with any name. > > I'll go a bit deeper here: > - you just downloaded a new image that was built from commit 100 > - In the meantime, while you downloaded your image, a new PR would have been integrated in pharo, so now the development branch may not be anymore on commit 100 but on commit 101. > - Even worse! There is no branch at all pointing to 100, your image's commit > - So the safest way to work (because updating the image may be dangerous not because of Iceberg :)) is to create a new branch on your commit. > > However, while this is the recommended way to work on Pharo, on other projects you can do a more normal workflow: checkout, pull. > > Does this answer it? Maybe I've missed something? > > > > Am I on the right track here? If I want try something out - do I just create myself a new issue (or is there a temp issue anyway?) > > Tim > > > -- > > 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

June 19, 2018

Project dependency management with Iceberg

by Vitor Medina Cruz

Hello, How do I do project dependency management with Iceberg? I tried sometime ago but I was unable to understand how it work together with Metacello, is there some tutorial available? Regards, Vitor

June 19, 2018

Pharo Sprints second half 2018

by Marcus Denker

Pharo Sprints second half 2018 ==================== We organise one Pharo âSprintâ per month were we meet to work on boring issue tracker entries together. Goals of the next sprints: - Fix issues for Pharo7 - Backport important fixes to Pharo6 - Clean issue tracker to prepare for release Pharo7 Remotely, you can join us on Discord. During the sprint, we will try to synchronize local and remote Pharo sprinters. In the past people organised local sprints at the same time (e.g. Santiago/Chile). See here for more infos: http://pharo.org/contribute-events There will be an event on the association website for each sprint. The next dates are: Friday June 29 https://association.pharo.org/event-2789583 Friday 31 August https://association.pharo.org/event-2973616 Friday 28 September https://association.pharo.org/event-2973620 Friday 26 October https://association.pharo.org/event-2973622 Friday 30 November https://association.pharo.org/event-2973626 Friday 21 December (Christmas Sprint) https://association.pharo.org/event-2973628 https://association.pharo.org/news/6320747

June 19, 2018

Re: [Pharo-users] Help contributing a fix to pharo - docs seem out of date again?

by Guillermo Polito

Hi, On Tue, Jun 19, 2018 at 2:26 PM Tim Mackinnon <tim(a)testit.works> wrote: > Hi - a few weeks ago, I contributed a tiny fix to Pharo 7 -and the > instructions seemed to work really well. > > Iâve since come back to try and do some more over lunch (I was thinking > Iâd like to dig out the changes I worked out for using the AST and cursor > to make senders/implements work properly and not just use the selected > text). > > My first problem was that my fork of Pharo from many months ago was out of > date - I think the instructions on > https://github.com/pharo-project/pharo/wiki/Contribute-a-fix-to-Pharo should > probably mention this subtlety. > > It took me ages to figure out what to do - this was the clue ( > https://help.github.com/articles/syncing-a-fork/) - and of particular > note the the tiny bit at the bottom to ensure you Push your changes back to > your GitHub fork (I slightly complicated myself by using IntelliJ to do > this - doable but you need to be aware of whats going on). I did this in a > separate non-pharo directory (I think thats what you would recommend right? > Then you can keep updating it from time to time?) > Usually, you don't care. You don't need to update your fork :) You only need to: - clone/locate your repository in disk - fetch (this will find your commit in the pharo repository) - create a new branch X - push branch X to your fork - make a pull request The contribution process never goes through master nor development, so it does not really matter if they are updated. And that's what I was showing in my videos because there is nothing else to it :) > > Having got my GitHub fork caught up with pharo/development - I then have > the Local Repo Missing error (expected) - and now when I go to repair it I > can either clone again (which is the instructions online) - or âLocate this > repository in your file systemâ. As Iâve had to already check everything > out to catch up to pharo/dev I chose to locate. > > I then get a Fetch require msg (expected) > > I then choose to use Fetch (Iâm not sure what the Repair repository > picture is now about?) - the text does mention I will become detached, so > Iâve stuck to that > > Iâm not sure why the âsolving a detached working copyâ is further down the > page - but Iâve jumped to that > > It says I need to synchronise both (image and repo) - but then says its > easier to do a branch - and then says a nice alternative is to create a > temp branch like temp/synch - however I canât see how to do that as there > is only Crete new Branch from Issue now (the picture shows that plus New > Branch). > I don't see what's the problem, maybe the UI can be enhanced to be more explicit. But you can just select "New branch" and create a branch with any name. I'll go a bit deeper here: - you just downloaded a new image that was built from commit 100 - In the meantime, while you downloaded your image, a new PR would have been integrated in pharo, so now the development branch may not be anymore on commit 100 but on commit 101. - Even worse! There is no branch at all pointing to 100, your image's commit - So the safest way to work (because updating the image may be dangerous not because of Iceberg :)) is to create a new branch on your commit. However, while this is the recommended way to work on Pharo, on other projects you can do a more normal workflow: checkout, pull. Does this answer it? Maybe I've missed something? > > Am I on the right track here? If I want try something out - do I just > create myself a new issue (or is there a temp issue anyway?) > > Tim > -- 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

June 19, 2018