[Pharo-users] Insecure issue tracker registration

[Manuel Leuenberger]

Hi,

I announced my concerns on Discord already, but got no reaction, so I post it 
here as well to have it properly archived.

"A colleague just noticed that the registration for the issue tracker is 
HTTP-only. This is not an appropriate choice for sensitive data like a 
password. Any possibilities to make this HTTPS-only?
Link: http://tracker.pharo.org/issues-register-service, setting https:// 
manually does not work"

From my perspective this is a serious problem that should be quickly addressed, 
it's not just a nice to have feature. Not treating sensitive data with proper 
care leaves an image of not caring about user security and looks 
unprofessional. I don't think that is what Pharo needs.

Cheers,
Manuel

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

[Tim Mackinnon]

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).

As mentioned above, I was also thinking it would be nice if I could checkin 
some of the play-/*.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

Re: [Pharo-users] Insecure issue tracker registration

[Ben Coman]

On 13 June 2018 at 16:25, Manuel Leuenberger 
wrote:

> Hi,
>
> I announced my concerns on Discord already, but got no reaction, so I post
> it here as well to have it properly archived.
>
> "A colleague just noticed that the registration for the issue tracker is
> HTTP-only. This is not an appropriate choice for sensitive data like a
> password. Any possibilities to make this HTTPS-only?
> Link: http://tracker.pharo.org/issues-register-service, setting https://
> manually does not work"
>
> From my perspective this is a serious problem that should be quickly
> addressed, it's not just a nice to have feature. Not treating sensitive
> data with proper care leaves an image of not caring about user security and
> looks unprofessional. I don't think that is what Pharo needs.


Thanks for raising this.  You're concerns are valid, but in the meantime
until someone can change it to https,
just use a temporary password and immediately change it the first time you
log onto Fogbugz - which is a https service.

@all,  If its difficult to add https to it, then perhaps at least a not can
be added to advise using a temporary password.

cheers -ben

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

[Sean P. DeNigris]

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

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

[Tim Mackinnon]

Hi - I am interested in what the future holds with Iceberg for things like 
finding deleted classes or reverting to older versions of things.

As we tend to use lots of classes in Smalltalk (and view them as cheap) - I 
often create them, then move behaviour around and delete things I don’t need 
anymore. However, if you want to recover one of those classes - with Envy there 
was a useful concept of “show me deleted classes in a package” and you would 
get a list that you could then browse and recover from.  Even older squeaks had 
some nice tools to pull this information from the .changes file (and while not 
quite the same as envy, it did let a solo developer work efficiently).

So I was a bit surprised yesterday in Pharo 6.1 - to struggle to find a class I 
knew that I had deleted. There seemed to be no easy way to do this - and I 
thought there was somewhere that had that “Available/Deleted classes” menu. 
Eventually I went to iceberg and browsed older versions of my package and with 
some riffing - managed to find what a I wanted - but it definitely seemed 
harder than it should be - for a concept that feels natural to us.

I’ve heard it mentioned that we might get “versions” behaviour back via git on 
a method or existing class - but what about Deleted classes - is this something 
we will be able to do more easily?

Tim

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

[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

[Pharo-users] Fwd: ApplicationSecurity Questions

[Hernán Morales Durand]

FYI

-- Forwarded message --
From: Hernán Morales Durand 
Date: 2018-06-13 13:44 GMT-03:00
Subject: Re: ApplicationSecurity Questions
To: Sean DeNigris 


Hi Sean,

Sorry for the delayed reply, almost no time for anything here

2018-06-08 10:20 GMT-03:00 Sean DeNigris :
> You can check a project making use of ApplicationSecurity here:
> http://www.smalltalkhub.com/#!/~hernan/IGEVET
>
>

Ok, I load it using:

Gofer it
   smalltalkhubUser: 'hernan' project: 'IGEVET';
   configurationOf: 'IGEVETWebSite';
   loadDevelopment.

> Pharo 6.1:
> - No #development version for Iliad, had to add to ConfigurationOfIliad
> - ConfigurationOfNacl - had to comment out #preload, which failed to
> download libsodium (apparently the dropbox link no longer works). I was able
> to procure the library elsewhere

I checked and ApplicationSecurity baseline was broken, missing some
dependencies.
Now I've fixed the BaselineOfApplicationSecurity to include the
ConfigurationOfNacl (https://github.com/hernanmd/ApplicationSecurity)
and PBKDF2 from Configuration, so includes the Fortuna and
SecureRandom classes. All Nacl tests passes at least on Windows.

If you're loading ConfigurationOfNacl-HernanMoralesDurand.36 then
#platformLibraryUrl contains the URLs which points to:
https://github.com/hernanmd/NacL/tree/master/res


> - ERROR: DNU #selector from RBParser >>#externalFunctionDeclaration when
> trying to parse:
>
> apiDeleteDC: aHDC
> 
> ^self externalCallFailed
>

IIRC that happens when you load a package with primitive syntax/format
for a different version of Pharo.

>
> Pharo 5:
> - ConfigurationOfNacl - had to comment out #preload, which failed to
> download libsodium (apparently the dropbox link no longer works). I was able
> to procure the library elsewhere
> - BioFormatters-HernanMoralesDurand.118 complained about missing PMVector,
> clicked proceed and no more problems
>

I don't have time to try it or support it in Pharo 5 now :(

> Since I’m not familiar with Iliad, I wasn’t sure how to run the app.

I wrote a Control Panel for Iliad some time ago. It should be
accessible from the World Menu. It works pretty much like the Seaside
one, plus some minor features, including a Session Browser.

> manually executed IGEVETApplication>>#startUp to get the server going, but
> wasn’t sure what URL to type into the browser. I tried a few things that all
> returned 404 like:
> - http://localhost:/IC
> - http://localhost:/chromopainter-jobs
> - http://localhost:/IC/chromopainter-jobs
>

Add an adaptor using the Control Panel then go to:

http://localhost:/main

> Also from my previous reply (not sure if you saw it):
>
> Out of curiosity, why Iliad instead of Seaside? Would Iliad be your
> default/recommendation for new web apps?
> Is it well-supported/maintained? It doesn’t seem to have much recent
> activity unless I’m looking at the wrong repo.
>
>
> Thanks!
>
> - s

Thank you for the feedback.
Please let me know how it is going,

Cheers,

Hernán

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

[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  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
> 

[Pharo-users] [ANN] ba-st Web Stack new versions available

[Gabriel Cotelli]

Check the announcement at
https://medium.com/ba-st/web-stack-june-release-bbfb2674b11.

Anyone interested in joining our ba-st projects 
is welcomed.

Regards,
Gabriel Cotelli, Maxi Tabacman and all the contributors.

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

[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  wrote:
> 
> hi,
> 
> 
>> On 13 Jun 2018, at 16: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.
>> 
>> 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-/*.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
> 
> 

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

[Tim Mackinnon]

Hi Sean - I tried it again, and it worked:

git log --full-history -- */PrismicBlock.class*

(I got my wildcard slightly wrong for tonel format) - although the beauty of 
the one I gave was that it shows you all deleted classes (in case you don’t 
know the name)

I’m still confused why I can’t checkout the deleted class though - damn you 
git, for the cryptic error: : error: pathspec 
'PrismicDemo/PrismicBlock.class.st ' did not 
match any file(s) known to git.

I was hoping a quick hack to iceberg might be to OSProcess a few choice git 
commands to help us along while we work out better ways to do things.

Tim

> On 13 Jun 2018, at 21:53, Sean P. DeNigris  wrote:
> 
> 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 
> Date:   Mon Jan 30 17:13:58 2017 -0500
> 
>Extract Lots to ComputerWorld, Absorb Rest of Old ScriptingBase Project
> 
> commit 61175745d57c60a1707d5e2f9a2fc92e6c19a6ea
> Author: Sean DeNigris 
> 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
> 

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

[Esteban Lorenzano]

> On 13 Jun 2018, at 22:44, Tim Mackinnon  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  wrote:
>> 
>> hi,
>> 
>> 
>>> On 13 Jun 2018, at 16: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.
>>> 
>>> 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-/*.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
>> 
>> 
> 
> 

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

[Esteban Lorenzano]

hi,


> On 13 Jun 2018, at 16: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.
> 
> 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-/*.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

[Pharo-users] [ann] gt documenter

[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/75333972541440

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

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

[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 
Date:   Mon Jan 30 17:13:58 2017 -0500

Extract Lots to ComputerWorld, Absorb Rest of Old ScriptingBase Project

commit 61175745d57c60a1707d5e2f9a2fc92e6c19a6ea
Author: Sean DeNigris 
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

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

[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  wrote:
> 
> 
> 
>> On 13 Jun 2018, at 22:44, Tim Mackinnon  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  wrote:
>>> 
>>> hi,
>>> 
>>> 
 On 13 Jun 2018, at 16: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.
 
 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-/*.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
>>> 
>>> 
>> 
>> 
> 
>