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

beacon documentation

by Tudor Girba

Hi, To support the recent conversation about Beacon, we put together an updated documentation using Documenter. To play with it: 1. Load GToolkit (this will also load Beacon) https://github.com/feenkcom/gtoolkit 2. Inspect IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit' / 'doc' / 'beacon' / 'index.pillarâ. Enjoy, The feenk team -- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."

June 13, 2018

Re: [Pharo-users] Why doesn't Iceberg checkin other assets (scripts) but does check them out?

by Tim Mackinnon

> yeahâ¦ but is a lot of work and no time just right now. > long term, it would be cool to manage everything from iceberg. > but reality check, is a huge amount of work so it has to come step by step. Fair enough - its pretty cool weâve got this far, and I guess the onus is on the rest of us to learn more about how its done and see if we can contribute more somehow. I really appreciate the love youâve already put into this - it works far better than I think we even realised it could. Tim > On 13 Jun 2018, at 21:55, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> On 13 Jun 2018, at 22:44, Tim Mackinnon <tim(a)testit.works> wrote: >> >> Esteban - so I don't then understand why iceberg (usefully in my view) checks out more than the src directory, if itâs only focusing on the Pharo blob? >> >> Iâm guessing that by knowing where the src is, you are just committing that part of the tree with libgit? >> >> Perhaps from a pragmatic first step you might consider letting us add a second safe resources directory that you could check in atomically as well (on the understanding all bets are off if it goes wrong?) >> >> OR could we have a check in mode does all the add/remove operations and writes to disk but then letâs you drop to the command line/other tool to add any other files and do the final commit? >> >> I just feel like you/we are so close to something that works a bit more broadly and embrace the wider world.? > > yeahâ¦ but is a lot of work and no time just right now. > long term, it would be cool to manage everything from iceberg. > but reality check, is a huge amount of work so it has to come step by step. > >> >> Tim >> >> Sent from my iPhone >> >>> On 13 Jun 2018, at 21:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> hi, >>> >>> >>>> On 13 Jun 2018, at 16:50, Tim Mackinnon <tim(a)testit.works> wrote: >>>> >>>> Hi - my second attempt at using Pharo with Git has proven very satisfying (I saw the potential in phase 1, but it was often difficult to understand what was happening and the workflow to use). >>>> >>>> One thing that has come up a few times for me however - and its something that using git nicely highlights, there are many non-smalltalk assets in my project that donât need to live in the image (like Seaside FileLibraries were trying to do) but do need to be versioned and be part of my project. Common examples are server config files, images and even the playground history files that are useful to pull up when on another computer. >>>> >>>> It seems that while Iceberg does check out a full project, if I change any of the files outside of the src directory (like edit a .txt file using the crude Pharo file editor), those changes donât get committed when I do a checkin? Is this on purpose? It makes the workflow a bit trickier to do an atomic commit of a piece of work - and Iâm not clear whether this is a conscious thing, or an MVP thing (and it will come later). >>> >>> workflow is tricker because you are expecting iceberg to talk with the local working copy and to handle that WC. >>> what happens in fact is different: iceberg treats the image as a working copy itself (it has its own âstageâ area) and what you have in disk is like a separated WC. >>> >>> at least, this is the metaphor we are using now, because we cannot realistically handle/control what is in disk since it can be anything. >>> So, instead having this picture in mind: >>> >>> Image -> Disk -> Git blob (database) >>> >>> you need to have this other: >>> >>> Image \ >>> Git blob (database) >>> Disk / >>> >>> >>> you will see as soon as you change the mental image, your problems are gone ;) >>> >>> cheers! >>> Esteban >>> >>> ps: diagram before is not exactly as it is since the image actually writes into disk first, but this is an implementation detail we would like to remove in the future, even. >>> >>>> >>>> As mentioned above, I was also thinking it would be nice if I could checkin some of the play-xxxx/*.sh files to essentially keep some of that history synced between environments (or team members?). >>>> >>>> It strikes me that this is the kind of thing that git integration should bring to us? >>>> >>>> I can overlay my copy of IntelliJ on top of my local iceberg directory and then use it for checkins - but then I still have the atomic problem, as its only when I commit that tonel files are written out onto the file system for me to checkin along with any other assets Iâve changed. Does anyone else have a good workflow for this? What do you guys do? >>>> >>>> Tim >>> >>> >> >> > >

June 13, 2018

[ann] gt documenter

by Tudor Girba

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: 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."

June 13, 2018

Re: [Pharo-users] Why doesn't Iceberg checkin other assets (scripts) but does check them out?

by Esteban Lorenzano

> On 13 Jun 2018, at 22:44, Tim Mackinnon <tim(a)testit.works> wrote: > > Esteban - so I don't then understand why iceberg (usefully in my view) checks out more than the src directory, if itâs only focusing on the Pharo blob? > > Iâm guessing that by knowing where the src is, you are just committing that part of the tree with libgit? > > Perhaps from a pragmatic first step you might consider letting us add a second safe resources directory that you could check in atomically as well (on the understanding all bets are off if it goes wrong?) > > OR could we have a check in mode does all the add/remove operations and writes to disk but then letâs you drop to the command line/other tool to add any other files and do the final commit? > > I just feel like you/we are so close to something that works a bit more broadly and embrace the wider world.? yeahâ¦ but is a lot of work and no time just right now. long term, it would be cool to manage everything from iceberg. but reality check, is a huge amount of work so it has to come step by step. > > Tim > > Sent from my iPhone > >> On 13 Jun 2018, at 21:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> hi, >> >> >>> On 13 Jun 2018, at 16:50, Tim Mackinnon <tim(a)testit.works> wrote: >>> >>> Hi - my second attempt at using Pharo with Git has proven very satisfying (I saw the potential in phase 1, but it was often difficult to understand what was happening and the workflow to use). >>> >>> One thing that has come up a few times for me however - and its something that using git nicely highlights, there are many non-smalltalk assets in my project that donât need to live in the image (like Seaside FileLibraries were trying to do) but do need to be versioned and be part of my project. Common examples are server config files, images and even the playground history files that are useful to pull up when on another computer. >>> >>> It seems that while Iceberg does check out a full project, if I change any of the files outside of the src directory (like edit a .txt file using the crude Pharo file editor), those changes donât get committed when I do a checkin? Is this on purpose? It makes the workflow a bit trickier to do an atomic commit of a piece of work - and Iâm not clear whether this is a conscious thing, or an MVP thing (and it will come later). >> >> workflow is tricker because you are expecting iceberg to talk with the local working copy and to handle that WC. >> what happens in fact is different: iceberg treats the image as a working copy itself (it has its own âstageâ area) and what you have in disk is like a separated WC. >> >> at least, this is the metaphor we are using now, because we cannot realistically handle/control what is in disk since it can be anything. >> So, instead having this picture in mind: >> >> Image -> Disk -> Git blob (database) >> >> you need to have this other: >> >> Image \ >> Git blob (database) >> Disk / >> >> >> you will see as soon as you change the mental image, your problems are gone ;) >> >> cheers! >> Esteban >> >> ps: diagram before is not exactly as it is since the image actually writes into disk first, but this is an implementation detail we would like to remove in the future, even. >> >>> >>> As mentioned above, I was also thinking it would be nice if I could checkin some of the play-xxxx/*.sh files to essentially keep some of that history synced between environments (or team members?). >>> >>> It strikes me that this is the kind of thing that git integration should bring to us? >>> >>> I can overlay my copy of IntelliJ on top of my local iceberg directory and then use it for checkins - but then I still have the atomic problem, as its only when I commit that tonel files are written out onto the file system for me to checkin along with any other assets Iâve changed. Does anyone else have a good workflow for this? What do you guys do? >>> >>> Tim >> >> > >

June 13, 2018

Re: [Pharo-users] Iceberg - finding deleted classes, reverting versions?

by Sean P. DeNigris

Tim Mackinnon wrote > I didnât quite get your fu to work Interesting. When I searched for commits affecting the deleted class SuDebianKey: $ git log --full-history -- */SuDebianKey.class/properties.json I got back a list of commits (obviously with the last chronologically being the deletion): commit a38fbced4abec59ff9879d4c607da80dc89b6637 Author: Sean DeNigris <sean(a)Seans-MBP.home> Date: Mon Jan 30 17:13:58 2017 -0500 Extract Lots to ComputerWorld, Absorb Rest of Old ScriptingBase Project commit 61175745d57c60a1707d5e2f9a2fc92e6c19a6ea Author: Sean DeNigris <sean(a)clipperadams.com> Date: Sat Aug 20 17:14:12 2016 -0400 Basket O' Enhancements ... ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 13, 2018

Re: [Pharo-users] Why doesn't Iceberg checkin other assets (scripts) but does check them out?

by Tim Mackinnon

Esteban - so I don't then understand why iceberg (usefully in my view) checks out more than the src directory, if itâs only focusing on the Pharo blob? Iâm guessing that by knowing where the src is, you are just committing that part of the tree with libgit? Perhaps from a pragmatic first step you might consider letting us add a second safe resources directory that you could check in atomically as well (on the understanding all bets are off if it goes wrong?) OR could we have a check in mode does all the add/remove operations and writes to disk but then letâs you drop to the command line/other tool to add any other files and do the final commit? I just feel like you/we are so close to something that works a bit more broadly and embrace the wider world.? Tim Sent from my iPhone > On 13 Jun 2018, at 21:28, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > hi, > > >> On 13 Jun 2018, at 16:50, Tim Mackinnon <tim(a)testit.works> wrote: >> >> Hi - my second attempt at using Pharo with Git has proven very satisfying (I saw the potential in phase 1, but it was often difficult to understand what was happening and the workflow to use). >> >> One thing that has come up a few times for me however - and its something that using git nicely highlights, there are many non-smalltalk assets in my project that donât need to live in the image (like Seaside FileLibraries were trying to do) but do need to be versioned and be part of my project. Common examples are server config files, images and even the playground history files that are useful to pull up when on another computer. >> >> It seems that while Iceberg does check out a full project, if I change any of the files outside of the src directory (like edit a .txt file using the crude Pharo file editor), those changes donât get committed when I do a checkin? Is this on purpose? It makes the workflow a bit trickier to do an atomic commit of a piece of work - and Iâm not clear whether this is a conscious thing, or an MVP thing (and it will come later). > > workflow is tricker because you are expecting iceberg to talk with the local working copy and to handle that WC. > what happens in fact is different: iceberg treats the image as a working copy itself (it has its own âstageâ area) and what you have in disk is like a separated WC. > > at least, this is the metaphor we are using now, because we cannot realistically handle/control what is in disk since it can be anything. > So, instead having this picture in mind: > > Image -> Disk -> Git blob (database) > > you need to have this other: > > Image \ > Git blob (database) > Disk / > > > you will see as soon as you change the mental image, your problems are gone ;) > > cheers! > Esteban > > ps: diagram before is not exactly as it is since the image actually writes into disk first, but this is an implementation detail we would like to remove in the future, even. > >> >> As mentioned above, I was also thinking it would be nice if I could checkin some of the play-xxxx/*.sh files to essentially keep some of that history synced between environments (or team members?). >> >> It strikes me that this is the kind of thing that git integration should bring to us? >> >> I can overlay my copy of IntelliJ on top of my local iceberg directory and then use it for checkins - but then I still have the atomic problem, as its only when I commit that tonel files are written out onto the file system for me to checkin along with any other assets Iâve changed. Does anyone else have a good workflow for this? What do you guys do? >> >> Tim > >

June 13, 2018

[ANN] ba-st Web Stack new versions available

by Gabriel Cotelli

Check the announcement at https://medium.com/ba-st/web-stack-june-release-bbfb2674b11. Anyone interested in joining our ba-st projects <https://github.com/ba-st/> is welcomed. Regards, Gabriel Cotelli, Maxi Tabacman and all the contributors.

June 13, 2018

Re: [Pharo-users] Why doesn't Iceberg checkin other assets (scripts) but does check them out?

by Esteban Lorenzano

hi, > On 13 Jun 2018, at 16:50, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi - my second attempt at using Pharo with Git has proven very satisfying (I saw the potential in phase 1, but it was often difficult to understand what was happening and the workflow to use). > > One thing that has come up a few times for me however - and its something that using git nicely highlights, there are many non-smalltalk assets in my project that donât need to live in the image (like Seaside FileLibraries were trying to do) but do need to be versioned and be part of my project. Common examples are server config files, images and even the playground history files that are useful to pull up when on another computer. > > It seems that while Iceberg does check out a full project, if I change any of the files outside of the src directory (like edit a .txt file using the crude Pharo file editor), those changes donât get committed when I do a checkin? Is this on purpose? It makes the workflow a bit trickier to do an atomic commit of a piece of work - and Iâm not clear whether this is a conscious thing, or an MVP thing (and it will come later). workflow is tricker because you are expecting iceberg to talk with the local working copy and to handle that WC. what happens in fact is different: iceberg treats the image as a working copy itself (it has its own âstageâ area) and what you have in disk is like a separated WC. at least, this is the metaphor we are using now, because we cannot realistically handle/control what is in disk since it can be anything. So, instead having this picture in mind: Image -> Disk -> Git blob (database) you need to have this other: Image \ Git blob (database) Disk / you will see as soon as you change the mental image, your problems are gone ;) cheers! Esteban ps: diagram before is not exactly as it is since the image actually writes into disk first, but this is an implementation detail we would like to remove in the future, even. > > As mentioned above, I was also thinking it would be nice if I could checkin some of the play-xxxx/*.sh files to essentially keep some of that history synced between environments (or team members?). > > It strikes me that this is the kind of thing that git integration should bring to us? > > I can overlay my copy of IntelliJ on top of my local iceberg directory and then use it for checkins - but then I still have the atomic problem, as its only when I commit that tonel files are written out onto the file system for me to checkin along with any other assets Iâve changed. Does anyone else have a good workflow for this? What do you guys do? > > Tim

June 13, 2018

Re: [Pharo-users] Iceberg - finding deleted classes, reverting versions?

by Tim Mackinnon

Hi Sean - that is an excellent reply, I didnât quite get your fu to work - but if you look up how to find deleted classes in git they give the following: git log --diff-filter=D --summary This gives you a git list of checkins and shows you the checkin comment, along with the list of files that were deleted (this is using tonel format, so its quite clear). A bit more man help gives a better: git log --diff-filter=D --summary --pretty='format:%cd|%h|%cn%n%s%nâ Which will output something a bit more like what I think you have to use to then understand how to find your change (the %h is the short hash with the Repository explorer in the new Iceberg shows). So you then get something like this: Mon Jun 11 01:33:59 2018 +0100|65363ad|Tim Mackinnon Refactor to a more consistent design with support for a basic link resolver delete mode 100644 src/PrismicDemo/PrismicBlock.class.st delete mode 100644 src/PrismicDemo/PrismicSpan.class.st delete mode 100644 src/PrismicDemo/PrismicSpannedText.class.st delete mode 100644 src/PrismicDemo/PrismicTextSpan.class.st Wed Jun 6 19:05:07 2018 +0100|4bea74d|macta Better handling of more data types for improved demo delete mode 100644 src/PrismicDemo/Text.extension.st This does highlight a few more thing though (and possibly future things to implement) - there is no search in the Repository list, so you have to scroll down yourself. Having found the class of interest - if I want to restore it, you are a bit on your own here too, as I think the âRevert Changeâ menu option (regardless of where you click) is going to try and recover the whole checkin and not let you cherry pick the class you want. You can of course at least see the source in the middle pane, and copy paste each method (but it could be a bit tedious). Possibly you might then be able to do this: git checkout 65363ad src/PrismicDemo/PrismicBlock.class.st Iâm not sure how Pharo will then react to this command line jiggery - as I keep getting an error : error: pathspec 'PrismicDemo/PrismicBlock.class.st' did not match any file(s) known to git. But I suspect its something like that? Tim > On 13 Jun 2018, at 17:23, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tim Mackinnon wrote >> Hi - I am interested in what the future holds with Iceberg for things like >> finding deleted classes or reverting to older versions of things. > > Great question! It used to be in the Change Sorter that delections were > logged and reversible. At some point that stopped working and then I moved > to git so I don't know if it was ever fixed. Obviously, that only looks back > w/in the current image which doesn't fully solve your issue. The cool thing > about git is that we inherit all its functionality - the good and bad. So > iot got me wondering whether we could drop down to the command line for the > time being. After some googling and experimentation, I came up with the > following: > > git log --full-history -- */{{className}}.class/properties.json > > NB. I had to add the properties.json because directories don't work, but > that may not be needed with Tonel > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

June 13, 2018

Re: [Pharo-users] Why doesn't Iceberg checkin other assets (scripts) but does check them out?

by Esteban A. Maringolo

On 13/06/2018 11:50, Tim Mackinnon wrote: > Hi - my second attempt at using Pharo with Git has proven very satisfying (I saw the potential in phase 1, but it was often difficult to understand what was happening and the workflow to use). > > One thing that has come up a few times for me however - and its something that using git nicely highlights, there are many non-smalltalk assets in my project that donât need to live in the image (like Seaside FileLibraries were trying to do) but do need to be versioned and be part of my project. Common examples are server config files, images and even the playground history files that are useful to pull up when on another computer. > [SNIP] > It strikes me that this is the kind of thing that git integration should bring to us? Of the mentioned benefits of using Git (or any other file based SCM) was exactly that of versioning "external" assets. You could do that with filetree/gitfiletree. But I guess that given then tight integration of Iceberg with git and the Pharo workflow, to "sync" ("commit") external files, these should be visible to Iceberg as well, and should be added for staging on each commit, which means that Iceberg should have a "file explorer" of some sort integrated into its GUI. Regards, -- Esteban A. Maringolo

June 13, 2018