[Pharo-users] Cargo

[Norbert Hartl]

Here comes my every-no-and-then-inquiry of the status of cargo. Is it in 
pharo7? Is it usable?

Norbert

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

[Tim Mackinnon]

Actually I realised it ended up on the be moose forum - here’s what Doru 
replied (for any lurkers)



Sent from my iPhone
> On Jun 18, 2018, at 1:21 PM, Tim Mackinnon  wrote:
> 
> Guys this is really impressive!

Thanks.


> 2 things I noticed when going through the example in a new Pharo 6.1 image 
> (with the latest Iceberg) -
> 
> 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
> 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ has 
> changed to “IceLibgitRepository …” in the newer iceberg - so it might be 
> worth a note in the readme (I’ll submit a PR)

Show Quoted Content
> 2 things I noticed when going through the example in a new Pharo 6.1 image 
> (with the latest Iceberg) -
> 
> 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
> 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ has 
> changed to “IceLibgitRepository …” in the newer iceberg - so it might be 
> worth a note in the readme (I’ll submit a PR)

Ok.


> 2) In a clean 6.1 image I get a walkback (GtPhlowExplicitView>>mondrian DNU) 
> when you try any of the graphical bits , making me think either the 
> dependencies are incorrect  on the Baseline (or the instruction for the 
> example also need to mention you need to load something else - presumably 
> Roassal?

Indeed, this is due to the fact that loading GToolkitDocumenter does not load 
GToolkitVisualizer which includes GtMondrian. We are still working on finding 
the right dependencies balance.

Until then, please load the whole GToolkit to get the full support.


> 3) You can’t scroll the Diff tabs of results, only the Code tabs

Good catch!


Cheers,
Doru

Sent from my iPhone

> On 20 Jun 2018, at 02:47, Tim Mackinnon  wrote:
> 
> Bump (not sure this got through , and keen to know how to load the 
> diagramming bit)
> 
> Guys this is really impressive!
> 
> 2 things I noticed when going through the example in a new Pharo 6.1 image 
> (with the latest Iceberg) -
> 
> 1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
> 'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ has 
> changed to “IceLibgitRepository …” in the newer iceberg - so it might be 
> worth a note in the readme (I’ll submit a PR)
> 
> 2) In a clean 6.1 image I get a walkback (GtPhlowExplicitView>>mondrian DNU) 
> when you try any of the graphical bits , making me think either the 
> dependencies are incorrect  on the Baseline (or the instruction for the 
> example also need to mention you need to load something else - presumably 
> Roassal?
> 3) You can’t scroll the Diff tabs of results, only the Code tabs
> 
> Tim
> 
>> On 13 Jun 2018, at 21: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:
>> 
>> 
>> 
>> 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.
>>

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

[Tim Mackinnon]

Bump (not sure this got through , and keen to know how to load the diagramming 
bit)

Guys this is really impressive!

2 things I noticed when going through the example in a new Pharo 6.1 image 
(with the latest Iceberg) -

1) The example "IceRepository repositoriesLocation / 'feenkcom'/ 
'gtoolkit-examples' / 'doc' / 'tutorial' / 'examples-tutorial.pillar'. “ has 
changed to “IceLibgitRepository …” in the newer iceberg - so it might be worth 
a note in the readme (I’ll submit a PR)

2) In a clean 6.1 image I get a walkback (GtPhlowExplicitView>>mondrian DNU) 
when you try any of the graphical bits , making me think either the 
dependencies are incorrect  on the Baseline (or the instruction for the example 
also need to mention you need to load something else - presumably Roassal?
3) You can’t scroll the Diff tabs of results, only the Code tabs

Tim

> On 13 Jun 2018, at 21: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:
> 
> 
> 
> 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."
> 
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

Re: [Pharo-users] How to contribute to Calypso when it relies on pharo-core editors?

[Tim Mackinnon]

Thinking about this more - why doesn’t Calypso appear in iceberg as a separate 
project alongside iceberg and Pharo?

That’s what’s confusing? And how did it get loaded from it’s git project 
without it appearing?

Which all makes me think there might need to be an iceberg setting - show/hide 
system projects so they don’t get in the way of your own projects. 

But then if you accidentally save a method in a system class - how are we going 
to spit it and know?

I hate getting burned when you thought you were on a roll 

Tim

Sent from my iPhone

> On 20 Jun 2018, at 02:26, Tim Mackinnon  wrote:
> 
> Hi - so in trying to improve the sendersof/implementors of - I thought I had 
> nailed it (and got working what I had done in Pharo 6 for Pharo 7) - but when 
> I loaded my commit into a fresh image I realised that none of the (minor) 
> changes I had made to Calypso had been committed.
> 
> This is actually quite confusing - and its take me a while to realise that 
> Calypso is a separate project and so when I picked commit on Pharo - this 
> won’t pick up any of the changes in Calypso…. Arrr
> 
> So now I’m guessing that I have to follow the same steps that I followed for 
> loading a pharo repo - for Calypso?
> 
> But then if I do this - and I propose some fixes to Calypso - how can it 
> work, as it relies on some changes to older pharo core editors that its 
> inserting from?
> 
> My changes without Calypso will work (they did in V6) - but then how can 
> someone test those in V7 as Calypso is then the default variable.
> 
> I’m in a bit of a twist - how can I proceed?
> 
> I’d really like to help improve the situation - as its bugged me for years 
> that its a pain looking stuff up quickly (requiring you to highlight just the 
> right stuff for very obvious things)
> 
> Tim

[Pharo-users] How to contribute to Calypso when it relies on pharo-core editors?

[Tim Mackinnon]

Hi - so in trying to improve the sendersof/implementors of - I thought I had 
nailed it (and got working what I had done in Pharo 6 for Pharo 7) - but when I 
loaded my commit into a fresh image I realised that none of the (minor) changes 
I had made to Calypso had been committed.

This is actually quite confusing - and its take me a while to realise that 
Calypso is a separate project and so when I picked commit on Pharo - this won’t 
pick up any of the changes in Calypso…. Arrr

So now I’m guessing that I have to follow the same steps that I followed for 
loading a pharo repo - for Calypso?

But then if I do this - and I propose some fixes to Calypso - how can it work, 
as it relies on some changes to older pharo core editors that its inserting 
from?

My changes without Calypso will work (they did in V6) - but then how can 
someone test those in V7 as Calypso is then the default variable.

I’m in a bit of a twist - how can I proceed?

I’d really like to help improve the situation - as its bugged me for years that 
its a pain looking stuff up quickly (requiring you to highlight just the right 
stuff for very obvious things)

Tim

Re: [Pharo-users] Nice catchy video for covering Pharo capability

[Offray Vladimir Luna Cárdenas]

Hi,


On 19/06/18 17:13, Andrei Stebakov wrote:
> Could you suggest a nice video for a presentation to showcase Pharo as
> a nice language for data visualization?
>
> Thanks,
> Andrei
>

I like the video Software as a Graph[1], which inspired me to do
Grafoscopio[2]. Some blog post (not in video format) show the
capabilities of Pharo as a data storytelling and visualization platform
for reproducible publishing and research and can be found in [3] and [4].


[1] https://vimeo.com/94724841
[2] http://mutabit.com/grafoscopio/index.en.html
[3] http://mutabit.com/offray/blog/en/entry/sdv-infomed
[4] http://mutabit.com/offray/blog/en/entry/ds-twitter-mockup

Hope this helps,

Offray

[Pharo-users] Nice catchy video for covering Pharo capability

[Andrei Stebakov]

Could you suggest a nice video for a presentation to showcase Pharo as a
nice language for data visualization?

Thanks,
Andrei

Re: [Pharo-users] Pharo 7 proxy problem

[Vincent.Blondeau]

Thank you!

Vincent

From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
Vitor Medina Cruz
Sent: Tuesday, June 19, 2018 12:10
To: Any question about pharo is welcome 
Subject: Re: [Pharo-users] Pharo 7 proxy problem

Done!

https://pharo.fogbugz.com/f/cases/22177/Pharo-7-proxy-problem

On Tue, Jun 19, 2018 at 3:55 PM, 
mailto:vincent.blond...@lamresearch.com>> 
wrote:
Great!

Could you create a bug report with the stack trace here: 
https://pharo.fogbugz.com/f/cases/new
 ?
It should be an issue with the socket library under x64.

Drag and drop the file into the image ;)
However the classes should be the same, otherwise you’ll get an error. That’s 
why I asked the version

Cheers,
Vincent

From: Pharo-users 
[mailto:pharo-users-boun...@lists.pharo.org]
 On Behalf Of Vitor Medina Cruz
Sent: Tuesday, June 19, 2018 11:46

To: Any question about pharo is welcome 
mailto:pharo-users@lists.pharo.org>>
Subject: Re: [Pharo-users] Pharo 7 proxy problem

Oh! on 32 bits version worked \o/, just tested it now.

On Tue, Jun 19, 2018 at 3:43 PM, Vitor Medina Cruz 
mailto:vitormc...@gmail.com>> wrote:
I just download it using Pharo Launcher
[cid:image001.png@01D407CB.F6D840B0]

Out of curiosity, how do I deserialize it into an image? :)

On Tue, Jun 19, 2018 at 3:36 PM, 
mailto:vincent.blond...@lamresearch.com>> 
wrote:
Hi,

Could you send the serialized stack of your primitive failure?
[cid:image002.png@01D407CB.F6D840B0]
And the version of Pharo you are using?

Thanks,

Vincent Blondeau

From: Pharo-users 
[mailto:pharo-users-boun...@lists.pharo.org]
 On Behalf Of Vitor Medina Cruz
Sent: Tuesday, June 19, 2018 11:30
To: Any question about pharo is welcome 
mailto:pharo-users@lists.pharo.org>>
Subject: Re: [Pharo-users] Pharo 7 proxy problem

Yes, it can resolve.

On Tue, Jun 19, 2018 at 1:30 PM, Esteban Lorenzano 
mailto:esteba...@gmail.com>> wrote:
have you tested your windows can resolve localhost?
I’m not a regular windows user, but I remember time ago this was not evident on 
windows systems.

Esteban

> On 19 Jun 2018, at 18:23, Vitor Medina Cruz 
> mailto:vitormc...@gmail.com>> wrote:
>
> Hello,
>
> I decided to give a try on Pharo 7 and see how iceberg is doing on 
> windows :)
>
> Pharo launcher is working fine by the way — I had some problems with it in 
> the past, but it seems more stable now.
>
> Well, if using windows isn't bad enought I am behind a proxy, so I use cntlm 
> and my configuration in Pharo 6.1 for cntlm proxy on localhost works fine, 
> but in 7 don't. First it seems to not recognize localhost as 127.0.0.1, it 
> prompts the message: NameLookupFailure: cannot resolve 'localhost'
>
> Using 127.0.0.1 I got a PrimitiveFailure (Ick!):
>
> PrimitiveFailed: primitive 
> #primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex:
>  in Socket failed'
>
> Since it is a primitive problem, I figure there is no workaround possible 
> here... right?
>
>
> 
>
>
> Socket(ProtoObject)>>primitiveFailed:
> Socket(ProtoObject)>>primitiveFailed
> Socket>>primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex:
> Socket>>initialize:
> [ super new initialize: TCPSocketType ] in Socket class>>newTCP in Block: [ 
> super new initialize: TCPSocketType ]
> BlockClosure>>repeatWithGCIf:
> Socket class>>newTCP
> ZdcSocketStream class(ZdcSimpleSocketStream 
> class)>>openConnectionToHost:port:timeout:
> ZnNetworkingUtils>>socketStreamToUrlDirectly:
> ZnNetworkingUtils>>socketStreamToProxy
> ZnNetworkingUtils>>socketStreamToUrl:
> ZnNetworkingUtils class>>socketStreamToUrl:
> ZnClient>>newConnectionTo:
> ZnClient>>getConnectionAndExecute
> ZnClient>>executeWithRedirectsRemaining:
> [ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in 
> ZnClient>>executeWithRetriesRemaining: in Block: [ self 
> executeWithRedirectsRemaining: self maxNumb...etc...
> BlockClosure>>on:do:
> ZnClient>>executeWithRetriesRemaining:
> [ self executeWithRetriesRemaining: self numberOfRetries ] in [ [ self 
> executeWithRetriesRemaining: self numberOfRetries ]
> on: Error
> do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ self 
> executeWithRetriesRemaining: self numberOfR...etc...
> B

Re: [Pharo-users] Pharo 7 proxy problem

[Vitor Medina Cruz]

Done!

https://pharo.fogbugz.com/f/cases/22177/Pharo-7-proxy-problem

On Tue, Jun 19, 2018 at 3:55 PM,  wrote:

> Great!
>
>
>
> Could you create a bug report with the stack trace here:
> https://pharo.fogbugz.com/f/cases/new ?
>
> It should be an issue with the socket library under x64.
>
>
>
> Drag and drop the file into the image ;)
>
> However the classes should be the same, otherwise you’ll get an error.
> That’s why I asked the version
>
>
>
> Cheers,
>
> Vincent
>
>
>
> *From:* Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] *On
> Behalf Of *Vitor Medina Cruz
> *Sent:* Tuesday, June 19, 2018 11:46
>
> *To:* Any question about pharo is welcome 
> *Subject:* Re: [Pharo-users] Pharo 7 proxy problem
>
>
>
> Oh! on 32 bits version worked \o/, just tested it now.
>
>
>
> On Tue, Jun 19, 2018 at 3:43 PM, Vitor Medina Cruz 
> wrote:
>
> I just download it using Pharo Launcher
>
>
>
> Out of curiosity, how do I deserialize it into an image? :)
>
>
>
> On Tue, Jun 19, 2018 at 3:36 PM,  wrote:
>
> Hi,
>
>
>
> Could you send the serialized stack of your primitive failure?
>
> And the version of Pharo you are using?
>
>
>
> Thanks,
>
>
>
> Vincent Blondeau
>
>
>
> *From:* Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] *On
> Behalf Of *Vitor Medina Cruz
> *Sent:* Tuesday, June 19, 2018 11:30
> *To:* Any question about pharo is welcome 
> *Subject:* Re: [Pharo-users] Pharo 7 proxy problem
>
>
>
> Yes, it can resolve.
>
>
>
> On Tue, Jun 19, 2018 at 1:30 PM, Esteban Lorenzano 
> wrote:
>
> have you tested your windows can resolve localhost?
> I’m not a regular windows user, but I remember time ago this was not
> evident on windows systems.
>
> Esteban
>
>
> > On 19 Jun 2018, at 18:23, Vitor Medina Cruz 
> wrote:
> >
> > Hello,
> >
> > I decided to give a try on Pharo 7 and see how iceberg is doing on
> windows :)
> >
> > Pharo launcher is working fine by the way — I had some problems with it
> in the past, but it seems more stable now.
> >
> > Well, if using windows isn't bad enought I am behind a proxy, so I use
> cntlm and my configuration in Pharo 6.1 for cntlm proxy on localhost works
> fine, but in 7 don't. First it seems to not recognize localhost as
> 127.0.0.1, it prompts the message: NameLookupFailure: cannot resolve
> 'localhost'
> >
> > Using 127.0.0.1 I got a PrimitiveFailure (Ick!):
> >
> > PrimitiveFailed: primitive #primSocketCreateNetwork:type:
> receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex: in
> Socket failed'
> >
> > Since it is a primitive problem, I figure there is no workaround
> possible here... right?
> >
> >
> > 
> >
> >
> > Socket(ProtoObject)>>primitiveFailed:
> > Socket(ProtoObject)>>primitiveFailed
> > Socket>>primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:
> semaIndex:readSemaIndex:writeSemaIndex:
> > Socket>>initialize:
> > [ super new initialize: TCPSocketType ] in Socket class>>newTCP in
> Block: [ super new initialize: TCPSocketType ]
> > BlockClosure>>repeatWithGCIf:
> > Socket class>>newTCP
> > ZdcSocketStream class(ZdcSimpleSocketStream class)>>openConnectionToHost:
> port:timeout:
> > ZnNetworkingUtils>>socketStreamToUrlDirectly:
> > ZnNetworkingUtils>>socketStreamToProxy
> > ZnNetworkingUtils>>socketStreamToUrl:
> > ZnNetworkingUtils class>>socketStreamToUrl:
> > ZnClient>>newConnectionTo:
> > ZnClient>>getConnectionAndExecute
> > ZnClient>>executeWithRedirectsRemaining:
> > [ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in
> ZnClient>>executeWithRetriesRemaining: in Block: [ self
> executeWithRedirectsRemaining: self maxNumb...etc...
> > BlockClosure>>on:do:
> > ZnClient>>executeWithRetriesRemaining:
> > [ self executeWithRetriesRemaining: self numberOfRetries ] in [ [ self
> executeWithRetriesRemaining: self numberOfRetries ]
> > on: Error
> > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [
> self executeWithRetriesRemaining: self numberOfR...etc...
> > BlockClosure>>on:do:
> > [ [ self executeWithRetriesRemaining: self numberOfRetries ]
> > on: Error
> > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ [
> self executeWithRetriesRemaining: self numberO...etc...
> > [ ^ block value ] in ZnClient>>withTimeoutDo: in Block: [ ^ block value ]
> > [ activeProcess psValueAt: index put: anObject.
> > aBlock value ] in ZnConnectionTimeout(DynamicVariable)>>value:during:
> in Block: [ activeProcess psValueAt: index put: anObject
> > BlockClosure>>ensure:
> > ZnConnectionTimeout(DynamicVariable)>>value:during:
> > ZnConnectionTimeout class(DynamicVariable class)>>value:during:
> > ZnClient>>withTimeoutDo:
> > ZnClient>>executeWithTimeout
> > [ result := self executeWithTimeout ] in ZnClient>>execute in Block: [
> result := self executeWithTimeout ]
> > [ ^ block value ] in ZnClient>>withProgressDo: in Block: [ ^ block value
> ]
> >
> > Regards,
> > Vitor
>
>
>
>
>
>
>

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

[Tim Mackinnon]

Ah - I didn’t think to look in the repair menu, now I see what you guys are 
talking about - the nomenclature threw me (maybe that’s ok if its there).

Tim

> On 19 Jun 2018, at 17:40, Guillermo Polito  > wrote:
> 
> Ok, I confirm. Actually I think that never worked. The create branch option 
> is only available from the repair action.
> 
> I've opened an issue:
> 
> https://github.com/pharo-vcs/iceberg/issues/871 
> 
> 
> I think it would be nice to show all valid options (including the ones in the 
> repair button) in the context menu too, for experienced users that want to 
> avoid an extra click.
> 
> On Tue, Jun 19, 2018 at 5:57 PM Guillermo Polito  > wrote:
> Ah! Yes, in the Pharo plugin you have just that option.
> What we were saying with Esteban is that if you go to the *Repair* and then 
> *Create new Branch* you should have it.
> 
> But in the main menu you don't have a "Checkout branch" option?
> That's then maybe a bug, I'll check.
> 
> On Tue, Jun 19, 2018 at 5:45 PM Tim Mackinnon  > wrote:
> Hi guys - I got build 1072 using Pharo Launcher (I like to know what build 
> I’m using - but maybe I should pick stable and just date stamp my image?)
> 
> Anyway just tried the latest 1077 and followed the steps I described 
> (although using my caught up branch)  - when I right click on the detached 
> pharo  - there is the Pharo menu item and inside that there is only the 
> option to create a new branch for an issue?
> 
> Am I missing something (or is this something recently broken?)
> 
> Tim
> 
>> On 19 Jun 2018, at 14:35, Guillermo Polito > > wrote:
>> 
>> 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 > > wrote:
>> 
>> 
>>> On 19 Jun 2018, at 15:18, Tim Mackinnon >> > 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 >>> > wrote:
 
 Hi,
 
 On Tue, Jun 19, 2018 at 2:26 PM Tim Mackinnon >>> > 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 :)
  
 
>>

Re: [Pharo-users] Pharo 7 proxy problem

[Vincent.Blondeau]

Great!

Could you create a bug report with the stack trace here: 
https://pharo.fogbugz.com/f/cases/new ?
It should be an issue with the socket library under x64.

Drag and drop the file into the image ;)
However the classes should be the same, otherwise you’ll get an error. That’s 
why I asked the version

Cheers,
Vincent

From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
Vitor Medina Cruz
Sent: Tuesday, June 19, 2018 11:46
To: Any question about pharo is welcome 
Subject: Re: [Pharo-users] Pharo 7 proxy problem

Oh! on 32 bits version worked \o/, just tested it now.

On Tue, Jun 19, 2018 at 3:43 PM, Vitor Medina Cruz 
mailto:vitormc...@gmail.com>> wrote:
I just download it using Pharo Launcher
[cid:image002.png@01D407C4.69242D30]

Out of curiosity, how do I deserialize it into an image? :)

On Tue, Jun 19, 2018 at 3:36 PM, 
mailto:vincent.blond...@lamresearch.com>> 
wrote:
Hi,

Could you send the serialized stack of your primitive failure?
[cid:image003.png@01D407C4.69242D30]
And the version of Pharo you are using?

Thanks,

Vincent Blondeau

From: Pharo-users 
[mailto:pharo-users-boun...@lists.pharo.org]
 On Behalf Of Vitor Medina Cruz
Sent: Tuesday, June 19, 2018 11:30
To: Any question about pharo is welcome 
mailto:pharo-users@lists.pharo.org>>
Subject: Re: [Pharo-users] Pharo 7 proxy problem

Yes, it can resolve.

On Tue, Jun 19, 2018 at 1:30 PM, Esteban Lorenzano 
mailto:esteba...@gmail.com>> wrote:
have you tested your windows can resolve localhost?
I’m not a regular windows user, but I remember time ago this was not evident on 
windows systems.

Esteban

> On 19 Jun 2018, at 18:23, Vitor Medina Cruz 
> mailto:vitormc...@gmail.com>> wrote:
>
> Hello,
>
> I decided to give a try on Pharo 7 and see how iceberg is doing on 
> windows :)
>
> Pharo launcher is working fine by the way — I had some problems with it in 
> the past, but it seems more stable now.
>
> Well, if using windows isn't bad enought I am behind a proxy, so I use cntlm 
> and my configuration in Pharo 6.1 for cntlm proxy on localhost works fine, 
> but in 7 don't. First it seems to not recognize localhost as 127.0.0.1, it 
> prompts the message: NameLookupFailure: cannot resolve 'localhost'
>
> Using 127.0.0.1 I got a PrimitiveFailure (Ick!):
>
> PrimitiveFailed: primitive 
> #primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex:
>  in Socket failed'
>
> Since it is a primitive problem, I figure there is no workaround possible 
> here... right?
>
>
> 
>
>
> Socket(ProtoObject)>>primitiveFailed:
> Socket(ProtoObject)>>primitiveFailed
> Socket>>primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex:
> Socket>>initialize:
> [ super new initialize: TCPSocketType ] in Socket class>>newTCP in Block: [ 
> super new initialize: TCPSocketType ]
> BlockClosure>>repeatWithGCIf:
> Socket class>>newTCP
> ZdcSocketStream class(ZdcSimpleSocketStream 
> class)>>openConnectionToHost:port:timeout:
> ZnNetworkingUtils>>socketStreamToUrlDirectly:
> ZnNetworkingUtils>>socketStreamToProxy
> ZnNetworkingUtils>>socketStreamToUrl:
> ZnNetworkingUtils class>>socketStreamToUrl:
> ZnClient>>newConnectionTo:
> ZnClient>>getConnectionAndExecute
> ZnClient>>executeWithRedirectsRemaining:
> [ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in 
> ZnClient>>executeWithRetriesRemaining: in Block: [ self 
> executeWithRedirectsRemaining: self maxNumb...etc...
> BlockClosure>>on:do:
> ZnClient>>executeWithRetriesRemaining:
> [ self executeWithRetriesRemaining: self numberOfRetries ] in [ [ self 
> executeWithRetriesRemaining: self numberOfRetries ]
> on: Error
> do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ self 
> executeWithRetriesRemaining: self numberOfR...etc...
> BlockClosure>>on:do:
> [ [ self executeWithRetriesRemaining: self numberOfRetries ]
> on: Error
> do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ [ self 
> executeWithRetriesRemaining: self numberO...etc...
> [ ^ block value ] in ZnClient>>withTimeoutDo: in Block: [ ^ block value ]
> [ activeProcess psValueAt: index put: anObject.
> aBlock value ] in ZnConnectionTimeout(DynamicVariable)>>value:during: in 
> Block: [ activeProcess psValueAt: index put: anObject
> BlockClosure>>ensure:
> ZnConnectionTimeout(DynamicVariable)>>value:during:
> ZnConnectionTimeout class(DynamicVariable class)>>value:during:
> ZnClient>>withTimeoutDo:
> ZnClient>>executeWithTimeout
> [ result := self executeWithTimeout ] in ZnClient>>execute in Block: [ result 
> := self executeWithTimeout ]
> [ ^ block value ] in ZnClient>>withProgressDo: in Block: [ ^ block value ]
>
> Regards,
> Vitor

Re: [Pharo-users] Pharo 7 proxy problem

[Vitor Medina Cruz]

Oh! on 32 bits version worked \o/, just tested it now.

On Tue, Jun 19, 2018 at 3:43 PM, Vitor Medina Cruz 
wrote:

> I just download it using Pharo Launcher
>
>
>
>
> Out of curiosity, how do I deserialize it into an image? :)
>
>
> On Tue, Jun 19, 2018 at 3:36 PM,  wrote:
>
>> Hi,
>>
>>
>>
>> Could you send the serialized stack of your primitive failure?
>>
>> And the version of Pharo you are using?
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Vincent Blondeau
>>
>>
>>
>> *From:* Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] *On
>> Behalf Of *Vitor Medina Cruz
>> *Sent:* Tuesday, June 19, 2018 11:30
>> *To:* Any question about pharo is welcome 
>> *Subject:* Re: [Pharo-users] Pharo 7 proxy problem
>>
>>
>>
>> Yes, it can resolve.
>>
>>
>>
>> On Tue, Jun 19, 2018 at 1:30 PM, Esteban Lorenzano 
>> wrote:
>>
>> have you tested your windows can resolve localhost?
>> I’m not a regular windows user, but I remember time ago this was not
>> evident on windows systems.
>>
>> Esteban
>>
>>
>> > On 19 Jun 2018, at 18:23, Vitor Medina Cruz 
>> wrote:
>> >
>> > Hello,
>> >
>> > I decided to give a try on Pharo 7 and see how iceberg is doing on
>> windows :)
>> >
>> > Pharo launcher is working fine by the way — I had some problems with it
>> in the past, but it seems more stable now.
>> >
>> > Well, if using windows isn't bad enought I am behind a proxy, so I use
>> cntlm and my configuration in Pharo 6.1 for cntlm proxy on localhost works
>> fine, but in 7 don't. First it seems to not recognize localhost as
>> 127.0.0.1, it prompts the message: NameLookupFailure: cannot resolve
>> 'localhost'
>> >
>> > Using 127.0.0.1 I got a PrimitiveFailure (Ick!):
>> >
>> > PrimitiveFailed: primitive #primSocketCreateNetwork:type:
>> receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex: in
>> Socket failed'
>> >
>> > Since it is a primitive problem, I figure there is no workaround
>> possible here... right?
>> >
>> >
>> > 
>> >
>> >
>> > Socket(ProtoObject)>>primitiveFailed:
>> > Socket(ProtoObject)>>primitiveFailed
>> > Socket>>primSocketCreateNetwork:type:receiveBufferSize:
>> sendBufSize:semaIndex:readSemaIndex:writeSemaIndex:
>> > Socket>>initialize:
>> > [ super new initialize: TCPSocketType ] in Socket class>>newTCP in
>> Block: [ super new initialize: TCPSocketType ]
>> > BlockClosure>>repeatWithGCIf:
>> > Socket class>>newTCP
>> > ZdcSocketStream class(ZdcSimpleSocketStream
>> class)>>openConnectionToHost:port:timeout:
>> > ZnNetworkingUtils>>socketStreamToUrlDirectly:
>> > ZnNetworkingUtils>>socketStreamToProxy
>> > ZnNetworkingUtils>>socketStreamToUrl:
>> > ZnNetworkingUtils class>>socketStreamToUrl:
>> > ZnClient>>newConnectionTo:
>> > ZnClient>>getConnectionAndExecute
>> > ZnClient>>executeWithRedirectsRemaining:
>> > [ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in
>> ZnClient>>executeWithRetriesRemaining: in Block: [ self
>> executeWithRedirectsRemaining: self maxNumb...etc...
>> > BlockClosure>>on:do:
>> > ZnClient>>executeWithRetriesRemaining:
>> > [ self executeWithRetriesRemaining: self numberOfRetries ] in [ [ self
>> executeWithRetriesRemaining: self numberOfRetries ]
>> > on: Error
>> > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [
>> self executeWithRetriesRemaining: self numberOfR...etc...
>> > BlockClosure>>on:do:
>> > [ [ self executeWithRetriesRemaining: self numberOfRetries ]
>> > on: Error
>> > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [
>> [ self executeWithRetriesRemaining: self numberO...etc...
>> > [ ^ block value ] in ZnClient>>withTimeoutDo: in Block: [ ^ block value
>> ]
>> > [ activeProcess psValueAt: index put: anObject.
>> > aBlock value ] in ZnConnectionTimeout(DynamicVariable)>>value:during:
>> in Block: [ activeProcess psValueAt: index put: anObject
>> > BlockClosure>>ensure:
>> > ZnConnectionTimeout(DynamicVariable)>>value:during:
>> > ZnConnectionTimeout class(DynamicVariable class)>>value:during:
>> > ZnClient>>withTimeoutDo:
>> > ZnClient>>executeWithTimeout
>> > [ result := self executeWithTimeout ] in ZnClient>>execute in Block: [
>> result := self executeWithTimeout ]
>> > [ ^ block value ] in ZnClient>>withProgressDo: in Block: [ ^ block
>> value ]
>> >
>> > Regards,
>> > Vitor
>>
>>
>>
>
>

Re: [Pharo-users] Pharo 7 proxy problem

[Vincent.Blondeau]

Hi,

Could you send the serialized stack of your primitive failure?
[cid:image001.png@01D407C1.C9C68460]
And the version of Pharo you are using?

Thanks,

Vincent Blondeau

From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of 
Vitor Medina Cruz
Sent: Tuesday, June 19, 2018 11:30
To: Any question about pharo is welcome 
Subject: Re: [Pharo-users] Pharo 7 proxy problem

Yes, it can resolve.

On Tue, Jun 19, 2018 at 1:30 PM, Esteban Lorenzano 
mailto:esteba...@gmail.com>> wrote:
have you tested your windows can resolve localhost?
I’m not a regular windows user, but I remember time ago this was not evident on 
windows systems.

Esteban

> On 19 Jun 2018, at 18:23, Vitor Medina Cruz 
> mailto:vitormc...@gmail.com>> wrote:
>
> Hello,
>
> I decided to give a try on Pharo 7 and see how iceberg is doing on 
> windows :)
>
> Pharo launcher is working fine by the way — I had some problems with it in 
> the past, but it seems more stable now.
>
> Well, if using windows isn't bad enought I am behind a proxy, so I use cntlm 
> and my configuration in Pharo 6.1 for cntlm proxy on localhost works fine, 
> but in 7 don't. First it seems to not recognize localhost as 127.0.0.1, it 
> prompts the message: NameLookupFailure: cannot resolve 'localhost'
>
> Using 127.0.0.1 I got a PrimitiveFailure (Ick!):
>
> PrimitiveFailed: primitive 
> #primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex:
>  in Socket failed'
>
> Since it is a primitive problem, I figure there is no workaround possible 
> here... right?
>
>
> 
>
>
> Socket(ProtoObject)>>primitiveFailed:
> Socket(ProtoObject)>>primitiveFailed
> Socket>>primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex:
> Socket>>initialize:
> [ super new initialize: TCPSocketType ] in Socket class>>newTCP in Block: [ 
> super new initialize: TCPSocketType ]
> BlockClosure>>repeatWithGCIf:
> Socket class>>newTCP
> ZdcSocketStream class(ZdcSimpleSocketStream 
> class)>>openConnectionToHost:port:timeout:
> ZnNetworkingUtils>>socketStreamToUrlDirectly:
> ZnNetworkingUtils>>socketStreamToProxy
> ZnNetworkingUtils>>socketStreamToUrl:
> ZnNetworkingUtils class>>socketStreamToUrl:
> ZnClient>>newConnectionTo:
> ZnClient>>getConnectionAndExecute
> ZnClient>>executeWithRedirectsRemaining:
> [ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in 
> ZnClient>>executeWithRetriesRemaining: in Block: [ self 
> executeWithRedirectsRemaining: self maxNumb...etc...
> BlockClosure>>on:do:
> ZnClient>>executeWithRetriesRemaining:
> [ self executeWithRetriesRemaining: self numberOfRetries ] in [ [ self 
> executeWithRetriesRemaining: self numberOfRetries ]
> on: Error
> do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ self 
> executeWithRetriesRemaining: self numberOfR...etc...
> BlockClosure>>on:do:
> [ [ self executeWithRetriesRemaining: self numberOfRetries ]
> on: Error
> do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ [ self 
> executeWithRetriesRemaining: self numberO...etc...
> [ ^ block value ] in ZnClient>>withTimeoutDo: in Block: [ ^ block value ]
> [ activeProcess psValueAt: index put: anObject.
> aBlock value ] in ZnConnectionTimeout(DynamicVariable)>>value:during: in 
> Block: [ activeProcess psValueAt: index put: anObject
> BlockClosure>>ensure:
> ZnConnectionTimeout(DynamicVariable)>>value:during:
> ZnConnectionTimeout class(DynamicVariable class)>>value:during:
> ZnClient>>withTimeoutDo:
> ZnClient>>executeWithTimeout
> [ result := self executeWithTimeout ] in ZnClient>>execute in Block: [ result 
> := self executeWithTimeout ]
> [ ^ block value ] in ZnClient>>withProgressDo: in Block: [ ^ block value ]
>
> Regards,
> Vitor

Re: [Pharo-users] Pharo 7 proxy problem

[Vitor Medina Cruz]

Yes, it can resolve.

On Tue, Jun 19, 2018 at 1:30 PM, Esteban Lorenzano 
wrote:

> have you tested your windows can resolve localhost?
> I’m not a regular windows user, but I remember time ago this was not
> evident on windows systems.
>
> Esteban
>
> > On 19 Jun 2018, at 18:23, Vitor Medina Cruz 
> wrote:
> >
> > Hello,
> >
> > I decided to give a try on Pharo 7 and see how iceberg is doing on
> windows :)
> >
> > Pharo launcher is working fine by the way — I had some problems with it
> in the past, but it seems more stable now.
> >
> > Well, if using windows isn't bad enought I am behind a proxy, so I use
> cntlm and my configuration in Pharo 6.1 for cntlm proxy on localhost works
> fine, but in 7 don't. First it seems to not recognize localhost as
> 127.0.0.1, it prompts the message: NameLookupFailure: cannot resolve
> 'localhost'
> >
> > Using 127.0.0.1 I got a PrimitiveFailure (Ick!):
> >
> > PrimitiveFailed: primitive #primSocketCreateNetwork:type:
> receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex: in
> Socket failed'
> >
> > Since it is a primitive problem, I figure there is no workaround
> possible here... right?
> >
> >
> > 
> >
> >
> > Socket(ProtoObject)>>primitiveFailed:
> > Socket(ProtoObject)>>primitiveFailed
> > Socket>>primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:
> semaIndex:readSemaIndex:writeSemaIndex:
> > Socket>>initialize:
> > [ super new initialize: TCPSocketType ] in Socket class>>newTCP in
> Block: [ super new initialize: TCPSocketType ]
> > BlockClosure>>repeatWithGCIf:
> > Socket class>>newTCP
> > ZdcSocketStream class(ZdcSimpleSocketStream class)>>openConnectionToHost:
> port:timeout:
> > ZnNetworkingUtils>>socketStreamToUrlDirectly:
> > ZnNetworkingUtils>>socketStreamToProxy
> > ZnNetworkingUtils>>socketStreamToUrl:
> > ZnNetworkingUtils class>>socketStreamToUrl:
> > ZnClient>>newConnectionTo:
> > ZnClient>>getConnectionAndExecute
> > ZnClient>>executeWithRedirectsRemaining:
> > [ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in
> ZnClient>>executeWithRetriesRemaining: in Block: [ self
> executeWithRedirectsRemaining: self maxNumb...etc...
> > BlockClosure>>on:do:
> > ZnClient>>executeWithRetriesRemaining:
> > [ self executeWithRetriesRemaining: self numberOfRetries ] in [ [ self
> executeWithRetriesRemaining: self numberOfRetries ]
> > on: Error
> > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [
> self executeWithRetriesRemaining: self numberOfR...etc...
> > BlockClosure>>on:do:
> > [ [ self executeWithRetriesRemaining: self numberOfRetries ]
> > on: Error
> > do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ [
> self executeWithRetriesRemaining: self numberO...etc...
> > [ ^ block value ] in ZnClient>>withTimeoutDo: in Block: [ ^ block value ]
> > [ activeProcess psValueAt: index put: anObject.
> > aBlock value ] in ZnConnectionTimeout(DynamicVariable)>>value:during:
> in Block: [ activeProcess psValueAt: index put: anObject
> > BlockClosure>>ensure:
> > ZnConnectionTimeout(DynamicVariable)>>value:during:
> > ZnConnectionTimeout class(DynamicVariable class)>>value:during:
> > ZnClient>>withTimeoutDo:
> > ZnClient>>executeWithTimeout
> > [ result := self executeWithTimeout ] in ZnClient>>execute in Block: [
> result := self executeWithTimeout ]
> > [ ^ block value ] in ZnClient>>withProgressDo: in Block: [ ^ block value
> ]
> >
> > Regards,
> > Vitor
>
>
>

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

[Guillermo Polito]

Ok, I confirm. Actually I think that never worked. The create branch option
is only available from the repair action.

I've opened an issue:

https://github.com/pharo-vcs/iceberg/issues/871

I think it would be nice to show all valid options (including the ones in
the repair button) in the context menu too, for experienced users that want
to avoid an extra click.

On Tue, Jun 19, 2018 at 5:57 PM Guillermo Polito 
wrote:

> Ah! Yes, in the Pharo plugin you have just that option.
> What we were saying with Esteban is that if you go to the *Repair* and
> then *Create new Branch* you should have it.
>
> But in the main menu you don't have a "Checkout branch" option?
> That's then maybe a bug, I'll check.
>
> On Tue, Jun 19, 2018 at 5:45 PM Tim Mackinnon  wrote:
>
>> Hi guys - I got build 1072 using Pharo Launcher (I like to know what
>> build I’m using - but maybe I should pick stable and just date stamp my
>> image?)
>>
>> Anyway just tried the latest 1077 and followed the steps I described
>> (although using my caught up branch)  - when I right click on the detached
>> pharo  - there is the Pharo menu item and inside that there is only the
>> option to create a new branch for an issue?
>>
>> Am I missing something (or is this something recently broken?)
>>
>> Tim
>>
>> On 19 Jun 2018, at 14:35, Guillermo Polito 
>> wrote:
>>
>> 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 
>> wrote:
>>
>>>
>>>
>>> On 19 Jun 2018, at 15:18, Tim Mackinnon  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 
>>> wrote:
>>>
>>> Hi,
>>>
>>> On Tue, Jun 19, 2018 at 2:26 PM Tim Mackinnon  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
>>>

Re: [Pharo-users] Pharo 7 proxy problem

[Esteban Lorenzano]

have you tested your windows can resolve localhost?
I’m not a regular windows user, but I remember time ago this was not evident on 
windows systems.

Esteban

> On 19 Jun 2018, at 18:23, Vitor Medina Cruz  wrote:
> 
> Hello,
> 
> I decided to give a try on Pharo 7 and see how iceberg is doing on 
> windows :)
> 
> Pharo launcher is working fine by the way — I had some problems with it in 
> the past, but it seems more stable now.
> 
> Well, if using windows isn't bad enought I am behind a proxy, so I use cntlm 
> and my configuration in Pharo 6.1 for cntlm proxy on localhost works fine, 
> but in 7 don't. First it seems to not recognize localhost as 127.0.0.1, it 
> prompts the message: NameLookupFailure: cannot resolve 'localhost'
> 
> Using 127.0.0.1 I got a PrimitiveFailure (Ick!):
> 
> PrimitiveFailed: primitive 
> #primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex:
>  in Socket failed'
> 
> Since it is a primitive problem, I figure there is no workaround possible 
> here... right?
> 
> 
> 
> 
> 
> Socket(ProtoObject)>>primitiveFailed:
> Socket(ProtoObject)>>primitiveFailed
> Socket>>primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex:
> Socket>>initialize:
> [ super new initialize: TCPSocketType ] in Socket class>>newTCP in Block: [ 
> super new initialize: TCPSocketType ]
> BlockClosure>>repeatWithGCIf:
> Socket class>>newTCP
> ZdcSocketStream class(ZdcSimpleSocketStream 
> class)>>openConnectionToHost:port:timeout:
> ZnNetworkingUtils>>socketStreamToUrlDirectly:
> ZnNetworkingUtils>>socketStreamToProxy
> ZnNetworkingUtils>>socketStreamToUrl:
> ZnNetworkingUtils class>>socketStreamToUrl:
> ZnClient>>newConnectionTo:
> ZnClient>>getConnectionAndExecute
> ZnClient>>executeWithRedirectsRemaining:
> [ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in 
> ZnClient>>executeWithRetriesRemaining: in Block: [ self 
> executeWithRedirectsRemaining: self maxNumb...etc...
> BlockClosure>>on:do:
> ZnClient>>executeWithRetriesRemaining:
> [ self executeWithRetriesRemaining: self numberOfRetries ] in [ [ self 
> executeWithRetriesRemaining: self numberOfRetries ]
> on: Error
> do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ self 
> executeWithRetriesRemaining: self numberOfR...etc...
> BlockClosure>>on:do:
> [ [ self executeWithRetriesRemaining: self numberOfRetries ]
> on: Error
> do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ [ self 
> executeWithRetriesRemaining: self numberO...etc...
> [ ^ block value ] in ZnClient>>withTimeoutDo: in Block: [ ^ block value ]
> [ activeProcess psValueAt: index put: anObject.
> aBlock value ] in ZnConnectionTimeout(DynamicVariable)>>value:during: in 
> Block: [ activeProcess psValueAt: index put: anObject
> BlockClosure>>ensure:
> ZnConnectionTimeout(DynamicVariable)>>value:during:
> ZnConnectionTimeout class(DynamicVariable class)>>value:during:
> ZnClient>>withTimeoutDo:
> ZnClient>>executeWithTimeout
> [ result := self executeWithTimeout ] in ZnClient>>execute in Block: [ result 
> := self executeWithTimeout ]
> [ ^ block value ] in ZnClient>>withProgressDo: in Block: [ ^ block value ]
> 
> Regards,
> Vitor

[Pharo-users] Pharo 7 proxy problem

[Vitor Medina Cruz]

Hello,

I decided to give a try on Pharo 7 and see how iceberg is doing on
windows :)

Pharo launcher is working fine by the way — I had some problems with it in
the past, but it seems more stable now.

Well, if using windows isn't bad enought I am behind a proxy, so I use
cntlm and my configuration in Pharo 6.1 for cntlm proxy on localhost works
fine, but in 7 don't. First it seems to not recognize localhost as
127.0.0.1, it prompts the message: NameLookupFailure: cannot resolve
'localhost'

Using 127.0.0.1 I got a PrimitiveFailure (Ick!):

PrimitiveFailed: primitive
#primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex:
in Socket failed'

Since it is a primitive problem, I figure there is no workaround possible
here... right?





Socket(ProtoObject)>>primitiveFailed:
Socket(ProtoObject)>>primitiveFailed
Socket>>primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex:
Socket>>initialize:
[ super new initialize: TCPSocketType ] in Socket class>>newTCP in Block: [
super new initialize: TCPSocketType ]
BlockClosure>>repeatWithGCIf:
Socket class>>newTCP
ZdcSocketStream class(ZdcSimpleSocketStream
class)>>openConnectionToHost:port:timeout:
ZnNetworkingUtils>>socketStreamToUrlDirectly:
ZnNetworkingUtils>>socketStreamToProxy
ZnNetworkingUtils>>socketStreamToUrl:
ZnNetworkingUtils class>>socketStreamToUrl:
ZnClient>>newConnectionTo:
ZnClient>>getConnectionAndExecute
ZnClient>>executeWithRedirectsRemaining:
[ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in
ZnClient>>executeWithRetriesRemaining: in Block: [ self
executeWithRedirectsRemaining: self maxNumb...etc...
BlockClosure>>on:do:
ZnClient>>executeWithRetriesRemaining:
[ self executeWithRetriesRemaining: self numberOfRetries ] in [ [ self
executeWithRetriesRemaining: self numberOfRetries ]
on: Error
do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ self
executeWithRetriesRemaining: self numberOfR...etc...
BlockClosure>>on:do:
[ [ self executeWithRetriesRemaining: self numberOfRetries ]
on: Error
do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ [
self executeWithRetriesRemaining: self numberO...etc...
[ ^ block value ] in ZnClient>>withTimeoutDo: in Block: [ ^ block value ]
[ activeProcess psValueAt: index put: anObject.
aBlock value ] in ZnConnectionTimeout(DynamicVariable)>>value:during: in
Block: [ activeProcess psValueAt: index put: anObject
BlockClosure>>ensure:
ZnConnectionTimeout(DynamicVariable)>>value:during:
ZnConnectionTimeout class(DynamicVariable class)>>value:during:
ZnClient>>withTimeoutDo:
ZnClient>>executeWithTimeout
[ result := self executeWithTimeout ] in ZnClient>>execute in Block: [
result := self executeWithTimeout ]
[ ^ block value ] in ZnClient>>withProgressDo: in Block: [ ^ block value ]

Regards,
Vitor

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

[Guillermo Polito]

Ah! Yes, in the Pharo plugin you have just that option.
What we were saying with Esteban is that if you go to the *Repair* and then
*Create new Branch* you should have it.

But in the main menu you don't have a "Checkout branch" option?
That's then maybe a bug, I'll check.

On Tue, Jun 19, 2018 at 5:45 PM Tim Mackinnon  wrote:

> Hi guys - I got build 1072 using Pharo Launcher (I like to know what build
> I’m using - but maybe I should pick stable and just date stamp my image?)
>
> Anyway just tried the latest 1077 and followed the steps I described
> (although using my caught up branch)  - when I right click on the detached
> pharo  - there is the Pharo menu item and inside that there is only the
> option to create a new branch for an issue?
>
> Am I missing something (or is this something recently broken?)
>
> Tim
>
> On 19 Jun 2018, at 14:35, Guillermo Polito 
> wrote:
>
> 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 
> wrote:
>
>>
>>
>> On 19 Jun 2018, at 15:18, Tim Mackinnon  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 
>> wrote:
>>
>> Hi,
>>
>> On Tue, Jun 19, 2018 at 2:26 PM Tim Mackinnon  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 

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

[Tim Mackinnon]

Hi guys - I got build 1072 using Pharo Launcher (I like to know what build I’m 
using - but maybe I should pick stable and just date stamp my image?)

Anyway just tried the latest 1077 and followed the steps I described (although 
using my caught up branch)  - when I right click on the detached pharo  - there 
is the Pharo menu item and inside that there is only the option to create a new 
branch for an issue?

Am I missing something (or is this something recently broken?)

Tim

> On 19 Jun 2018, at 14:35, Guillermo Polito  wrote:
> 
> 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  > wrote:
> 
> 
>> On 19 Jun 2018, at 15:18, Tim Mackinnon > > 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 >> > wrote:
>>> 
>>> Hi,
>>> 
>>> On Tue, Jun 19, 2018 at 2:26 PM Tim Mackinnon >> > 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 fr

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo Launcher v1.2 release

[Sven Van Caekenberghe]

> On 19 Jun 2018, at 16:01, Tudor Girba  wrote:
> 
> Great work!

Indeed. Thank you.

> Doru
> 
> 
>> On Jun 19, 2018, at 3:55 PM, Christophe Demarey 
>>  wrote:
>> 
>> 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):
>> 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/pharo-launcher/1.2/
>> 
>> Regards,
>> Christophe.
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "The coherence of a trip is given by the clearness of the goal."
> 
> 
> 
> 
> 
> 

Re: [Pharo-users] [ANN] Pharo Launcher v1.2 release

[Serge Stinckwich]

Thank you Christophe for your work !
I really appreciate it.

I dl the 64 bits VM for macOS. Everytime I run a 32 bits image, I have a
warning that using a 32 bits images, require a 32 bits VM.
And then when I select yes, everything works. Why having this warning
everytime ?

A+

On Tue, Jun 19, 2018 at 2:57 PM Christophe Demarey <
christophe.dema...@inria.fr> wrote:

> 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):
> 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/pharo-launcher/1.2/
>
> Regards,
> Christophe.
>


-- 
Serge Stinckwich
UMI UMMISCO 209 (SU/IRD/UY1)
"Programs must be written for people to read, and only incidentally for
machines to execute."http://www.doesnotunderstand.org/

[Pharo-users] [ANN] TechTalk Dates second half 2018

[Marcus Denker]

Here are the next dates for the Pharo Techtalks.

12 Jul 2018: Pharo TechTalk:  Machine Learning with TensorFlow and Pharo  
https://association.pharo.org/event-2973748

For the others we have no topic yet, but dates are pre-fixed to:

23 Aug 2018: Pharo TechTalk https://association.pharo.org/event-2973753
11 Oct 2018: Pharo TechTalk https://association.pharo.org/event-2973754
15 Nov 2018: Pharo TechTalk https://association.pharo.org/event-2973755
13 Dec 2018: Pharo TechTalk https://association.pharo.org/event-2973756


We are looking for topics!

• If you have ideas for topics, please tell us! 
• With no topic, we will use this slot for a general free discussion.
• If you want to do a TechTalk about a topic but no date is good, we 
can change the date!


For recording of the past ones, see: http://pharo.org/TechTalk

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

[Norbert Hartl]

> Am 19.06.2018 um 15:22 schrieb Guillermo Polito :
> 
> 
> On Tue, Jun 19, 2018 at 2:07 PM Norbert Hartl  > 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? :)
>  
It has more to do with experience then with age. Well, the one thing enables 
sometimes the other but there is no strict causality, right.

> 
>> Am 19.06.2018 um 10:59 schrieb Guillermo Polito > >:
>> 
>> 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...
>  
That is pretty clear by what you wrote. It wasn’t meant to be personal so 
please don’t take it like that. So do I. 
> 
>> 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...
>  
My mail was meant to be a plea for exactly this. If you don’t think the hot-fix 
(I like that much more than patch) solves a show stopper for a lot of users of 
this version you don’t put it in a patch version. If it is in the slightest 
sense an improvement don’t put into a patch version but a minor on. Because I 
don’t want to have my stuff broken but I choose to update in order to get the 
improvement hence a deliberate action. If all of these commits are hot-fixes 
then take my big excuse for bringing this up.

> 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?
>  
For what?

> 
>> 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.
>  
This time it is not about having more but less in a version.
> 
>> 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...
>  
I know you do your best. And I know that you are a really good developer that 
does great stuff all the time. It is neither meant as a lesson nor something 
you should take personally. I do not often raise my wishes because I always 
need to assurance it is something really important and not something I want out 
of my current mood. But this is something I have no doubt about so I bring it 
up. And I do all of this for quite some time and that does count, too.

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

[Tudor Girba]

Hi,

Indeed. Something went amiss in this email exchange. But, I really do not think 
that you are in disagreement.

Cheers,
Doru



> On Jun 19, 2018, at 4:09 PM, Christophe Demarey  
> wrote:
> 
> Hi Norbert,
> 
>> Le 19 juin 2018 à 14:06, Norbert Hartl  a écrit :
>> 
>> I have no use for an environment where people only care about coding new 
>> cool stuff. If it would be like this I would quit all my pharo businesses, 
>> move to mainstream and would use pharo only for hobbyist projects because 
>> that would be the level that can be met.
> 
> I do not think Guille has this state of mind. He spends time to write lot of 
> tests for code other people wrote (not the funniest part), to clean code in 
> the image (old code, bad dependencies, better API), to improve existing 
> stuff, answering questions on the ML, and so on.
> He is one of the few people that really tries to push semantic versioning. He 
> could have made some errors (like everyone) but I find your sentence not fair 
> for him.
> 
> Regards,
> Christophe

--
www.tudorgirba.com
www.feenk.com

"We are all great at making mistakes."

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

[Christophe Demarey]

Hi Norbert,

> Le 19 juin 2018 à 14:06, Norbert Hartl  a écrit :
> 
> I have no use for an environment where people only care about coding new cool 
> stuff. If it would be like this I would quit all my pharo businesses, move to 
> mainstream and would use pharo only for hobbyist projects because that would 
> be the level that can be met.

I do not think Guille has this state of mind. He spends time to write lot of 
tests for code other people wrote (not the funniest part), to clean code in the 
image (old code, bad dependencies, better API), to improve existing stuff, 
answering questions on the ML, and so on.
He is one of the few people that really tries to push semantic versioning. He 
could have made some errors (like everyone) but I find your sentence not fair 
for him.

Regards,
Christophe

Re: [Pharo-users] [ANN] Pharo Launcher v1.2 release

[Tudor Girba]

Great work!

Doru


> On Jun 19, 2018, at 3:55 PM, Christophe Demarey  
> wrote:
> 
> 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):
> 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/pharo-launcher/1.2/
> 
> Regards,
> Christophe.

--
www.tudorgirba.com
www.feenk.com

"The coherence of a trip is given by the clearness of the goal."

Re: [Pharo-users] Project dependency management with Iceberg

[Guillermo Polito]

Hi,

On Tue, Jun 19, 2018 at 3:16 PM Vitor Medina Cruz 
wrote:

> Hello,
>
> How do I do project dependency management with Iceberg?
>

This is still Metacello.


> I tried sometime ago but I was unable to understand how it work together
> with Metacello, is there some tutorial available?
>

Well, there is a chapter in the Deep Into Pharo book

http://files.pharo.org/books-pdfs/deep-into-pharo/2013-DeepIntoPharo-EN.pdf

But that covers ConfigurationOf only. The technical part on how you define
a dependency does not change too much between Configurations and Baselines.
The main difference is that
- a ConfigurationOf will store inside it several baselines (in baseline
methods) and several versions (in version methods)
- a BaselineOf defines a single baseline in a baseline method. And versions
are declared in the VCS using whatever you like the most, most commonly
being tags.

Then, inside a BaselineOf, if you want to define a dependency to a project
in github for example, you can specify it like this:

spec
baseline: 'Tonel'
with: [ spec repository: 'github://pharo-vcs/tonel:v1.0.9/src' ]

Where Tonel is the name of the project and the strangish url is then used
to construct a github url. So it's something like

[provider]://[owner-name]/[project-name][:version][/subdirectory]

- provider can be (so far) any of github, bitbucket, gitorious
- If version is ommited then it will just download the main branch (usually
master)
- Otherwise you can specify any commitish (commit hash, tag name, branch
name)
- If your source code is stored in a subdirectory of the repository, you
can specify it after the version.

Then, to load project you can either
- use the Metacello plugin from Iceberg (right click -> Metacello ->
Install baseline)
- evaluate a Metacello expression in the playground

Metacello new
baseline: 'Tonel';
repository: 'github://pharo-vcs/tonel:v1.0.9/src' ;
load

Of course you can then just look for senders of #baseline:with: to see
other examples in the image.

Cheers,
Guille

[Pharo-users] [ANN] Pharo Launcher v1.2 release

[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 
):
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/pharo-launcher/1.2/ 

Regards,
Christophe.

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

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

>
>
> On 19 Jun 2018, at 15:18, Tim Mackinnon  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 
> wrote:
>
> Hi,
>
> On Tue, Jun 19, 2018 at 2:26 PM Tim Mackinnon  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
> 

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

[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 
>  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  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 
  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 
>>  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:
>>> 
>>> 
>>> 
>>> At its core it offers a live editor for manipulating Pillar documents. 
>>> The interaction happens s

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

[Esteban Lorenzano]

> On 19 Jun 2018, at 15:18, Tim Mackinnon  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 > > wrote:
>> 
>> Hi,
>> 
>> On Tue, Jun 19, 2018 at 2:26 PM Tim Mackinnon > > 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 
>> 
>> 
>> Web: http://guillep.github.io 
>> Phone: +33 06 5

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

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

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

[Guillermo Polito]

On Tue, Jun 19, 2018 at 2:07 PM Norbert Hartl  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  >:
>
> 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.

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

[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  wrote:
> 
> Hi,
> 
> On Tue, Jun 19, 2018 at 2:26 PM Tim Mackinnon  > 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 
> 
> 
> Web: http://guillep.github.io 
> Phone: +33 06 52 70 66 13

[Pharo-users] Project dependency management with Iceberg

[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

[Pharo-users] Pharo Sprints second half 2018

[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

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

[Guillermo Polito]

Hi,

On Tue, Jun 19, 2018 at 2:26 PM Tim Mackinnon  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
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

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

[Tim Mackinnon]

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

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

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

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

[Norbert Hartl]

Hi,

let me wear the project manager hat for a moment.

> Am 19.06.2018 um 10:59 schrieb Guillermo Polito :
> 
> 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.

> 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. 
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. Not sure about #860 because the title is not specific 
enough. 
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. 

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

> 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 mean we come 
from an amateurish behaviour that we change released artefacts. That is not 
discussable just a no-go. 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.

> 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 
have no use for an environment where people only care about coding new cool 
stuff. If it would be like this I would quit all my pharo businesses, move to 
mainstream and would use pharo only for hobbyist projects because that would be 
the level that can be met.

Norbert

> In any case, I think it is more important to discuss about the numbering as 
> soon as we have a clear documentation on Iceberg's API...
> 
> Regarding the bad links, I copy-pasted the text from the PR instead from the 
> release page in Iceberg, which messes up links.
> 
> Patch version containing the following cleanups and enhancements
> 
> #864  Repairing Missing 
> repositories lead to wrong source directory
> #861  update tonel to v1.0.9
> #836  DefaultBackendType 
> class variable is unused
> #862  Iceberg tests are not 
> running in Pharo 7
> #852  Make error dialogs 
> copy-pastable
> #858  
> IceTipReadOnlyTextMorph does not allow select and copy anymore
> #850  Change Detached head 
> status from error to warning if we are on a tag
> #853  Clone dialog 
> "username" is confusing
> #860  CredentialStore API
> #854  Error in History window
> 
> Guille
> 
> On Mon, Jun 18, 2018 at 9:12 PM Torsten Bergmann  > wrote:
> Great - thank you! Might be a small patch release - but nonetheless important.
> 
> BTW: the links in your mail are pointing to PR's of Pharo and not Iceberg. If 
> you used
>  a template you might want to consider changing it.
>  
>  
> Gesendet: Montag, 18. Juni 2018 um 17:47 Uhr
> Von: "Guillermo Polito"  >
> An: "Any question about pharo is welcome"  >, "Discusses Development of Pharo" 
> mailto:pharo-...@lists.pharo.org>>
> Betreff: [Pharo-dev] [Ann] Iceberg v1.1.1
> Hi everybody,
>  
> This week we have a small patch release of Iceberg, version v1.1.1.
> This version will be available in the next Pharo build.
> 

Re: [Pharo-users] How to contribute to Pharo Launcher?

[Christophe Demarey]

Thanks a lot Tim. All contributions are welcomed!
Indeed, for a tool like Pharo Launcher,  most complexity comes from multiple OS 
environments.

> Le 19 juin 2018 à 12:05, Tim Mackinnon  a écrit :
> 
> Done - sorry, I wasn’t clear on how best to tie it all together. I think its 
> more obvious when we get it all onto GitHub - but for now this can work too.
> 
> Thanks for resurrecting the project a while back - I know its had a bit of 
> flack lately, but that more the complexity of multiple OS environments, and 
> trying to get some more contributors to help.
> 
> Ironically its quite nicely structured code - although it could do with a few 
> more tests - so maybe thats one to double up on.
> 
> Tim
> 
>> On 19 Jun 2018, at 09:51, Christophe Demarey  
>> wrote:
>> 
>> Hi Tim,
>> 
>> Thanks a lot for your contributions. Looks good to me. It is a nice addition.
>> Could you open an issue 
>> https://github.com/pharo-project/pharo-launcher/issues/new so that we can 
>> keep a trace of your contribution (we open issues for features / 
>> improvements also)? 
>> 
>> Thanks also to Cyril who helped you to commit to ST.
>> 
>> Cheers,
>> Christophe.
>> 
>>> Le 18 juin 2018 à 19:20, Tim Mackinnon  a écrit :
>>> 
>>> While I’m at it - improve the icon for Launch without Settings (it needed 
>>> Alpha)
>>> 
>>> Name: PharoLauncher-Core-TimM.174
>>> Author: TimM
>>> Time: 18 June 2018, 6:11:54.416337 pm
>>> UUID: d9433566-4f2b-0d00-85be-afca09965ccd
>>> Ancestors: PharoLauncher-Core-TimM.173
>>> 
>>> Sorry - can’t help with the windows launch problems as I don’t have a 
>>> windows machine any more.
>>> 
 On 18 Jun 2018, at 17:35, Tim Mackinnon  wrote:
 
 Ok - I’ve done a save for both packages - hopefully they are useful:
 
 Name: PharoLauncher-Spec-TimM.70
 Author: TimM
 Time: 18 June 2018, 5:32:00.928101 pm
 UUID: 5e888bd7-4e2b-0d00-85bb-537409965ccd
 Ancestors: PharoLauncher-Spec-TimM.69
 
 
 Name: PharoLauncher-Core-TimM.172
 Author: TimM
 Time: 18 June 2018, 5:34:46.055084 pm
 UUID: 6a2b63e1-4e2b-0d00-85bc-0fed09965ccd
 Ancestors: PharoLauncher-Core-TimM.171
 
 
 
> On 18 Jun 2018, at 16:30, Cyril Ferlicot D.  
> wrote:
> 
> On 18/06/2018 17:27, Tim Mackinnon wrote:
>> Hi Cyril - I have to confess that I don’t recall what the steps are to 
>> safely commit in Monticello. I have smallish changes to 2 packages Core 
>> and Spec, and I can see that smalltalkhub repo in the MC browser and can 
>> browse my changes against it - but how do I commit both packages in 
>> there? I vaguely recall something about slices - but wasn’t that a Pharo 
>> core thing?
>> 
>> I get the impression that I don’t just press save on each package 
>> against sthub do I?
>> 
>> Sorry to be so dumb - I’ve just swapped out Monticello usage for Git 
>> usage these days.  Just need a few hints to get back on track
>> 
> 
> You need to save the two packages individually.
> 
> While git is project oriented, StHub is package oriented.
> 
> Slices are only for Pharo development. (One could adapt them to make
> Monticello more project oriented but it is currently not the case).
> 
> So in conclusion, yes you need to press save on each package. :)
> 
>> Tim
>> 
>> 
>> 
> 
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr
> 
 
 
>>> 
>>> 
>> 
>> 
> 
> 

Re: [Pharo-users] How to contribute to Pharo Launcher?

[Tim Mackinnon]

Done - sorry, I wasn’t clear on how best to tie it all together. I think its 
more obvious when we get it all onto GitHub - but for now this can work too.

Thanks for resurrecting the project a while back - I know its had a bit of 
flack lately, but that more the complexity of multiple OS environments, and 
trying to get some more contributors to help.

Ironically its quite nicely structured code - although it could do with a few 
more tests - so maybe thats one to double up on.

Tim

> On 19 Jun 2018, at 09:51, Christophe Demarey  
> wrote:
> 
> Hi Tim,
> 
> Thanks a lot for your contributions. Looks good to me. It is a nice addition.
> Could you open an issue 
> https://github.com/pharo-project/pharo-launcher/issues/new so that we can 
> keep a trace of your contribution (we open issues for features / improvements 
> also)? 
> 
> Thanks also to Cyril who helped you to commit to ST.
> 
> Cheers,
> Christophe.
> 
>> Le 18 juin 2018 à 19:20, Tim Mackinnon  a écrit :
>> 
>> While I’m at it - improve the icon for Launch without Settings (it needed 
>> Alpha)
>> 
>> Name: PharoLauncher-Core-TimM.174
>> Author: TimM
>> Time: 18 June 2018, 6:11:54.416337 pm
>> UUID: d9433566-4f2b-0d00-85be-afca09965ccd
>> Ancestors: PharoLauncher-Core-TimM.173
>> 
>> Sorry - can’t help with the windows launch problems as I don’t have a 
>> windows machine any more.
>> 
>>> On 18 Jun 2018, at 17:35, Tim Mackinnon  wrote:
>>> 
>>> Ok - I’ve done a save for both packages - hopefully they are useful:
>>> 
>>> Name: PharoLauncher-Spec-TimM.70
>>> Author: TimM
>>> Time: 18 June 2018, 5:32:00.928101 pm
>>> UUID: 5e888bd7-4e2b-0d00-85bb-537409965ccd
>>> Ancestors: PharoLauncher-Spec-TimM.69
>>> 
>>> 
>>> Name: PharoLauncher-Core-TimM.172
>>> Author: TimM
>>> Time: 18 June 2018, 5:34:46.055084 pm
>>> UUID: 6a2b63e1-4e2b-0d00-85bc-0fed09965ccd
>>> Ancestors: PharoLauncher-Core-TimM.171
>>> 
>>> 
>>> 
 On 18 Jun 2018, at 16:30, Cyril Ferlicot D.  
 wrote:
 
 On 18/06/2018 17:27, Tim Mackinnon wrote:
> Hi Cyril - I have to confess that I don’t recall what the steps are to 
> safely commit in Monticello. I have smallish changes to 2 packages Core 
> and Spec, and I can see that smalltalkhub repo in the MC browser and can 
> browse my changes against it - but how do I commit both packages in 
> there? I vaguely recall something about slices - but wasn’t that a Pharo 
> core thing?
> 
> I get the impression that I don’t just press save on each package against 
> sthub do I?
> 
> Sorry to be so dumb - I’ve just swapped out Monticello usage for Git 
> usage these days.  Just need a few hints to get back on track
> 
 
 You need to save the two packages individually.
 
 While git is project oriented, StHub is package oriented.
 
 Slices are only for Pharo development. (One could adapt them to make
 Monticello more project oriented but it is currently not the case).
 
 So in conclusion, yes you need to press save on each package. :)
 
> Tim
> 
> 
> 
 
 
 -- 
 Cyril Ferlicot
 https://ferlicot.fr
 
>>> 
>>> 
>> 
>> 
> 
> 

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

[Guillermo Polito]

Hi,

About why 1.1.1 and not 1.2.0. It's not about cheap or not, but about
semantics :)
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.

So I don't assign a new version number regarding the number of changes but
about what they mean...
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 :)

Now, this is the kind of subjective topic that starts a flamewar, but I'd
prefer to use my time on somewhat else ^^.
In any case, I think it is more important to discuss about the numbering as
soon as we have a clear documentation on Iceberg's API...

Regarding the bad links, I copy-pasted the text from the PR instead from
the release page in Iceberg, which messes up links.

Patch version containing the following cleanups and enhancements

#864  Repairing Missing
repositories lead to wrong source directory
#861  update tonel to v1.0.9
#836  DefaultBackendType
class variable is unused
#862  Iceberg tests are
not running in Pharo 7
#852  Make error dialogs
copy-pastable
#858  IceTipReadOnlyTextMorph
does not allow select and copy anymore
#850  Change Detached head
status from error to warning if we are on a tag
#853  Clone dialog
"username" is confusing
#860  CredentialStore API
#854  Error in History
window

Guille

On Mon, Jun 18, 2018 at 9:12 PM Torsten Bergmann  wrote:

> Great - thank you! Might be a small patch release - but nonetheless
> important.
>
> BTW: the links in your mail are pointing to PR's of Pharo and not Iceberg.
> If you used
>  a template you might want to consider changing it.
>
>
> *Gesendet:* Montag, 18. Juni 2018 um 17:47 Uhr
> *Von:* "Guillermo Polito" 
> *An:* "Any question about pharo is welcome" ,
> "Discusses Development of Pharo" 
> *Betreff:* [Pharo-dev] [Ann] Iceberg v1.1.1
> Hi everybody,
>
> This week we have a small patch release of Iceberg, version v1.1.1.
> This version will be available in the next Pharo build.
>
> In summary, this release fixes two issues with the new credentials
> manager, and introduces a couple of other enhancements/bugfixes.
>
> Below you will find the detailed changes log.
> Enjoy,
> Guille
>
>
> Integrate Iceberg 1.1.1
> https://pharo.fogbugz.com/f/cases/22168/Integrate-Iceberg-1-1-1
>
> https://github.com/pharo-vcs/iceberg/releases/tag/v1.1.1
>
> #864  Repairing Missing
> repositories lead to wrong source directory
> #861  update tonel to
> v1.0.9
> #836  DefaultBackendType
> class variable is unused
> #862  Iceberg tests are
> not running in Pharo 7
> #852  Make error dialogs
> copy-pastable
> #858  IceTipReadOnlyTextMorph
> does not allow select and copy anymore
> #850  Change Detached
> head status from error to warning if we are on a tag
> #853  Clone dialog
> "username" is confusing
> #860  CredentialStore API
> #854  Error in History
> window
>
>
> --
>
>
>
> 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
> *
>
>
>
> *Web:* *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
*


*Web:* *http://guillep.github.io* 

*Phone:

Re: [Pharo-users] How to contribute to Pharo Launcher?

[Christophe Demarey]

Hi Tim,

Thanks a lot for your contributions. Looks good to me. It is a nice addition.
Could you open an issue 
https://github.com/pharo-project/pharo-launcher/issues/new so that we can keep 
a trace of your contribution (we open issues for features / improvements also)? 

Thanks also to Cyril who helped you to commit to ST.

Cheers,
Christophe.

> Le 18 juin 2018 à 19:20, Tim Mackinnon  a écrit :
> 
> While I’m at it - improve the icon for Launch without Settings (it needed 
> Alpha)
> 
> Name: PharoLauncher-Core-TimM.174
> Author: TimM
> Time: 18 June 2018, 6:11:54.416337 pm
> UUID: d9433566-4f2b-0d00-85be-afca09965ccd
> Ancestors: PharoLauncher-Core-TimM.173
> 
> Sorry - can’t help with the windows launch problems as I don’t have a windows 
> machine any more.
> 
>> On 18 Jun 2018, at 17:35, Tim Mackinnon  wrote:
>> 
>> Ok - I’ve done a save for both packages - hopefully they are useful:
>> 
>> Name: PharoLauncher-Spec-TimM.70
>> Author: TimM
>> Time: 18 June 2018, 5:32:00.928101 pm
>> UUID: 5e888bd7-4e2b-0d00-85bb-537409965ccd
>> Ancestors: PharoLauncher-Spec-TimM.69
>> 
>> 
>> Name: PharoLauncher-Core-TimM.172
>> Author: TimM
>> Time: 18 June 2018, 5:34:46.055084 pm
>> UUID: 6a2b63e1-4e2b-0d00-85bc-0fed09965ccd
>> Ancestors: PharoLauncher-Core-TimM.171
>> 
>> 
>> 
>>> On 18 Jun 2018, at 16:30, Cyril Ferlicot D.  
>>> wrote:
>>> 
>>> On 18/06/2018 17:27, Tim Mackinnon wrote:
 Hi Cyril - I have to confess that I don’t recall what the steps are to 
 safely commit in Monticello. I have smallish changes to 2 packages Core 
 and Spec, and I can see that smalltalkhub repo in the MC browser and can 
 browse my changes against it - but how do I commit both packages in there? 
 I vaguely recall something about slices - but wasn’t that a Pharo core 
 thing?
 
 I get the impression that I don’t just press save on each package against 
 sthub do I?
 
 Sorry to be so dumb - I’ve just swapped out Monticello usage for Git usage 
 these days.  Just need a few hints to get back on track
 
>>> 
>>> You need to save the two packages individually.
>>> 
>>> While git is project oriented, StHub is package oriented.
>>> 
>>> Slices are only for Pharo development. (One could adapt them to make
>>> Monticello more project oriented but it is currently not the case).
>>> 
>>> So in conclusion, yes you need to press save on each package. :)
>>> 
 Tim
 
 
 
>>> 
>>> 
>>> -- 
>>> Cyril Ferlicot
>>> https://ferlicot.fr
>>> 
>> 
>> 
> 
> 

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

[Tudor Girba]

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