Re: [Pharo-users] "News" section of the website down

[orsayman via Pharo-users]

--- Begin Message ---
Yes, it's back. Thanks !



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

--- End Message ---

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

[Tim Mackinnon]

Phew - I can confirm that (unsurprisingly I guess) - just committing in Iceberg 
(without ticking - push changes to origin/master) does then let you easily 
overlay the same checked out project (typically ./iceberg/ProjectName) in a 
tool like VSCode or IntelliJ where you can then also commit further changes to 
files that Iceberg is ignoring (essentially everything not in the src directory 
- typically candidates would be your Readme.md file and possibly a ./scripts or 
./assets directory).

In that other tool you can then issue a push which will then atomically push 
all commits to a pipeline. It can be a little more tricky to understand what 
the pipeline is building - in Gitlab it will show you the comment of the most 
recent commit in the pipeline, however if you then click on the branch the 
pipeline is running on, you will get a list of commits and can see all the 
commits that are between the running pipeline and the previously run pipeline.

For many of you - this might be pleadingly obvious - but when you have a 
different workflow mindset in your head, it might be trickier to spot this 
subtlety.

Tim

p.s. Thanks for all the useful debate in this thread. I should add that when I 
wrote “I’ll shut up” - a meant more that I felt the conversation was going in a 
cycle and repeating itself, not that I was offended or frustrated. I can 
probably live with the above nuance for my desire for atomic commits.

p.p.s It hadn’t occurred to me that the most common use case where people will 
hit a similar problem to me - is that Readme.md file. Definitely that is one 
where it should possibly automatically added to the index, or catered for - as 
it is really just a text file right?

> On 15 Jun 2018, at 18:26, Todd Blanchard  wrote:
> 
> 
> 
>> On Jun 15, 2018, at 2:05 AM, Esteban Lorenzano > > wrote:
>> 
>> 
>> 
>>> On 15 Jun 2018, at 10:29, Tim Mackinnon >> > wrote:
>>> 
>>> 
>>> In many parts of the dev world - every commit should be shippable, meaning 
>>> atomic - particularly with the use of CI systems (Travis, Gitlab etc) that 
>>> build on every commit. 
>> 
>> but then, you mean every *push* should be shippable :)
>> that’s something I agree :)
> 
> The way we run projects - pushing to master is forbidden.  You push your work 
> to a feature specific branch, a CI server runs all the tests in the branch 
> every push.  We create pull requests from the github project page, people 
> review them and when the tests are green and reviewers approve, we perform 
> the merge on github.
> 
> Never touch master (or whatever branch you pick for main trunk) outside of 
> github.  Always perform new work in new branch.
> 

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

[Tim Mackinnon]

Tod/Norbert - I won’t shy away from answering your comments on this - but if 
its ok - lets move that conversation to a new thread. I don’t want to distract 
away from how one actually does some form of atomic checkin (and I’m talking a 
small one - one Smalltalk class, one associated text file).

I earlier tried doing a change on a class - committing, but not pushing and 
then switching to IntelliJ to then commit and push my config file change - and 
it didn’t seem to work - which surprised me, so I’m gong to redo my test again 
with the the latest Iceberg 1.1 in a new image (and also make sure my IntelliJ 
is attached to the same local repo). This seems like the closest root to how I 
would like to work (albeit a slightly bit more complicated than I would like, 
but certainly doable).

Tim

> On 15 Jun 2018, at 18:26, Todd Blanchard  wrote:
> 
> 
> 
>> On Jun 15, 2018, at 2:05 AM, Esteban Lorenzano > > wrote:
>> 
>> 
>> 
>>> On 15 Jun 2018, at 10:29, Tim Mackinnon >> > wrote:
>>> 
>>> 
>>> In many parts of the dev world - every commit should be shippable, meaning 
>>> atomic - particularly with the use of CI systems (Travis, Gitlab etc) that 
>>> build on every commit. 
>> 
>> but then, you mean every *push* should be shippable :)
>> that’s something I agree :)
> 
> The way we run projects - pushing to master is forbidden.  You push your work 
> to a feature specific branch, a CI server runs all the tests in the branch 
> every push.  We create pull requests from the github project page, people 
> review them and when the tests are green and reviewers approve, we perform 
> the merge on github.
> 
> Never touch master (or whatever branch you pick for main trunk) outside of 
> github.  Always perform new work in new branch.
> 

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

[Tim Mackinnon]

Hi Christophe - you are right, I did contribute many years ago (I found the Mcz 
field on my disk when I just checked now) - but I’ll be darned If I can 
remember how it works (I have to confess, I never really got on with Metacello 
and slices).

Do I simply take my latest .mcz file in my local directory and somehow apply it 
to the sthub repo (sorry if this is obvious to you - but I’ve plain forgotten 
how its done).

It would be good to get it into GitHub - it certainly seems to work pretty well 
now for most things, and it makes contributing so much easier.

Tim

> On 15 Jun 2018, at 08:14, Christophe Demarey  
> wrote:
> 
> Hi Tim,
> 
>> Le 14 juin 2018 à 18:48, Tim Mackinnon  a écrit :
>> 
>> Is PharoLauncher using git - there is a note saying the StHub repo is about 
>> to be moved?
>> 
>> I ask as I wanted to contribute a simple change that shows the modified date 
>> of the images and lets you sort by that (I sometimes forget which was the 
>> latest image I was using and have a few old ones kicking around).
> 
> 
> Until now, I preferred to stay on StHub mainly because Iceberg was not ready 
> to work smoothly with. I did not wanted to get extra-difficulties to work on 
> Pharo Launcher (merge problems, etc).
> That said, Iceberg has now moved a lot in the right direction and I think we 
> could start to use git for Pharo Launcher development.
> I will release a ne version of PharoLauncher soon and then, I think I will 
> move PharoLauncher on github and use Cargo to manage it.
> 
> For your contribution, it is welcomed (in fact, it was planned to be added 
> but you were faster). Feel free to commit it directly to the SH repository, I 
> will then take a look at it. It looks like you already can commit: 
> http://smalltalkhub.com/#!/~Pharo/PharoLauncher/contributors.
> 
> Thanks Tim.
> 
> Regards,
> Christophe

Re: [Pharo-users] Lost in stream

[Hilaire]

Le 15/06/2018 à 20:40, Sven Van Caekenberghe a écrit :

I don't see anything wrong with Toto-Wrong.png.

When loading like this I have space low detection:
PNGReadWriter formFromStream: 'Toto-Wrong.png' asFileReference 
binaryReadStream




As for the XML part, the following seemed to work:

xmldoc := (FileLocator desktop / 'Toto-ok.fgeo') readStreamDo: [ :in | 
XMLDOMParser parse: in ].

(FileLocator desktop / 'drgeo.xml') writeStreamDo: [ :out | xmldoc writeXMLOn: 
(XMLWriter on: out) ].

I know this is the DOM parser, not the SAX parser, but as far as streams are 
concerned, XML* seems to work OK.


I am using the DOM parser, but apparently it uses SAX
I don't have writeXMLOn: method. I am using an old version of the XML 
package, is it? Its newer version breaks the API.



--
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] Lost in stream

[Sven Van Caekenberghe]

I don't see anything wrong with Toto-Wrong.png.

As for the XML part, the following seemed to work:

xmldoc := (FileLocator desktop / 'Toto-ok.fgeo') readStreamDo: [ :in | 
XMLDOMParser parse: in ].

(FileLocator desktop / 'drgeo.xml') writeStreamDo: [ :out | xmldoc writeXMLOn: 
(XMLWriter on: out) ].

I know this is the DOM parser, not the SAX parser, but as far as streams are 
concerned, XML* seems to work OK.

> On 15 Jun 2018, at 19:17, Hilaire  wrote:
> 
> I investigated a bit more the other issue, and it looks like XML entities are 
> not correctly decoded when read from the newer File API. Somehow it is 
> related to stream I guess.
> 
> For example, drgeo document starting like:
> 
> 
> 
> 
> are correctly decoded with DrGeo 17.07, but not with the newer one.
> 
> When debugging, it looks like there is a jump at the end of the entity, the 
> $; character is not returned by the (self next) in the SAX Driver.
> 
> May be I used the wrong stream when opening the doc, but I don't know, the 
> stream was open as:
> 
> 'triangle-scale.fgeo' asFileReference readStream
> 
> Hilaire
> 
> 
> Le 15/06/2018 à 18:31, Hilaire a écrit :
>> I already met fragilities with some file when loading older drgeo document, 
>> but I have not fully tracked the issue.
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

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

[Todd Blanchard]

> On Jun 15, 2018, at 2:05 AM, Esteban Lorenzano  wrote:
> 
> 
> 
>> On 15 Jun 2018, at 10:29, Tim Mackinnon > > wrote:
>> 
>> 
>> In many parts of the dev world - every commit should be shippable, meaning 
>> atomic - particularly with the use of CI systems (Travis, Gitlab etc) that 
>> build on every commit. 
> 
> but then, you mean every *push* should be shippable :)
> that’s something I agree :)

The way we run projects - pushing to master is forbidden.  You push your work 
to a feature specific branch, a CI server runs all the tests in the branch 
every push.  We create pull requests from the github project page, people 
review them and when the tests are green and reviewers approve, we perform the 
merge on github.

Never touch master (or whatever branch you pick for main trunk) outside of 
github.  Always perform new work in new branch.

Re: [Pharo-users] Lost in stream

[Hilaire]

I investigated a bit more the other issue, and it looks like XML 
entities are not correctly decoded when read from the newer File API. 
Somehow it is related to stream I guess.


For example, drgeo document starting like:




are correctly decoded with DrGeo 17.07, but not with the newer one.

When debugging, it looks like there is a jump at the end of the entity, 
the $; character is not returned by the (self next) in the SAX Driver.


May be I used the wrong stream when opening the doc, but I don't know, 
the stream was open as:


'triangle-scale.fgeo' asFileReference readStream

Hilaire


Le 15/06/2018 à 18:31, Hilaire a écrit :
I already met fragilities with some file when loading older drgeo 
document, but I have not fully tracked the issue.


--
Dr. Geo
http://drgeo.eu

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

[Norbert Hartl]

> Am 15.06.2018 um 10:29 schrieb Tim Mackinnon :
> 
> 
> In many parts of the dev world - every commit should be shippable, meaning 
> atomic - particularly with the use of CI systems (Travis, Gitlab etc) that 
> build on every commit. 
> 
To be honest I don’t like such comments. Do you have a proof for „many parts of 
the world“? I do not get why every commit should be shippable. To me it sounds 
like a misplaced constraint. And for every project that is not pretty simple I 
doubt it can work at all. Commits are commits and a shippable product is 
shippable product not much in common. 

> Of course you can choose to work a different way - but our tools shouldn’t 
> force a very common practice to be awkward, should they?
> 
Again. Where is this common practice? You cannot just state such things without 
proof in order to back your argument. I can see that in some scenarios it comes 
in handy that such commits ease some things. But I do not agree to see that 
this is or should be the common case. 

> I don’t understand why many of you guys are so anti such a common thing. In 
> fact our community pioneered this way of working - a build machine where you 
> loaded all your code and ran all your tests before committing.  Also, a large 
> number of agile teams will council to work on master (and avoid branches - a 
> technique we also pioneered).
> In today’s world where we live in a wider polyglot stack this is one of the 
> reasons why git is so attractive as it should easily embraces that.
> 
I don’t think I am anti. I don’t get your point making this a common thing. I 
think that wanting commits spawning multiple repos is much more common. 

> I get that it’s not quite possible yet - but there are some decent ways to 
> accommodate this (a staging operation, or perhaps a better way to make use of 
> the #addToIndex: which I will experiment with).
> 
> Anyway, I’ll shut up - and possibly will learn how to implement it myself. 
> Thinking more, I may also be able run with commit and no push , which I will 
> try - as it’s probably the easiest mechanism if the CI will recognise that (I 
> think it will).
> 
No, do no shut up. Just proof your point. We cannot support every possible use 
case. 

Norbert

> Thanks for the enlightening conversation, and as always the hard work on 
> iceberg that made this conversation even possible.
> 
> Tim
> 
> Sent from my iPhone
> 
> On 15 Jun 2018, at 07:11, Norbert Hartl  > wrote:
> 
>> 
>> 
>> Am 14.06.2018 um 13:12 schrieb Thierry Goubier > >:
>> 
>>> Hi Norbert, Tim,
>>> 
>>> 2018-06-14 11:33 GMT+02:00 Norbert Hartl >> >:
>>> 
>>> 
 Am 14.06.2018 um 10:30 schrieb Tim Mackinnon >>> >:
 
 Hi - yes I’m pleased you check out the entire tree, although currently 
 it’s a bit confusing that you do (fortunately this does give the 
 possibility that we can checkout images and other resources that an Pharo 
 application might rely on - without having to resort to the Seaside 
 FileLibrary trick).
 
 However my concrete case was that I have a gitlab ci pipeline and next to 
 my src directory in my project I have a config directory that has some 
 Nginx config for my teapot app. If I add a teapot route, I also need to 
 adjust that config and check both changes in together. I can’t easily do 
 that now?
 
 I can modify /config/app.nginx either in another app (intellij) or even in 
 the simple Pharo text editor, and the I can add my new route in my 
 DemoApp>>createRoutes method but how do I check them in together so my 
 pipeline will build atomically?
 
 Iceberg hasn’t written out the changes yet, so IntelliJ can’t see them to 
 do a commit, and iceberg ignores the parallel /config directory (that it 
 checked out). So it’s a catch 22.
 
 This is why I suggested maybe we could specify safer (textual) directories 
 that iceberg might also checkin? OR we have a Stage command in iceberg 
 that does everything that commit does up to the point of actually writing 
 to the repo - then I could jump to IntelliJ and do the final commit there 
 and use its tools to manage non Pharo stuff (until we can build more)?
 
 Does this make sense?
 
>>> I don’t understand why you are so eager to have everything into one commit. 
>>> Usually the tension is rather have small commits. What is the problem of 
>>> having two commits for this?
>>> 
>>> A single commit allow one to make sure that both the smalltalk code and the 
>>> external resource are well in sync, and that you may not ending up in a 
>>> situation were at commit j has data format v1 and smalltalk code for format 
>>> v2, because it is in commit j+1 that you rewrote the data in format v2.
>>> 
>> Yes, sure but that is only a problem if you lost control over which commit 
>> goes into action. I think th

Re: [Pharo-users] "News" section of the website down

[Marcus Denker]

Hi,

It should now work: 
http://pharo.org/news 

(thanks to esteban)

Marcus

> On 11 Apr 2018, at 08:30, orsayman via Pharo-users 
>  wrote:
> 
> 
> From: orsayman 
> Subject: Re: "News" section of the website down
> Date: 11 April 2018 at 08:30:17 CEST
> To: pharo-users@lists.pharo.org
> 
> 
> Hum, I'm sorry but it still doesn't work this morning (from home).
> 
> 
> 
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
> 
> 
> 

Re: [Pharo-users] Insecure issue tracker registration

[Marcus Denker]

Hi,

I have found a simple workaround (not yet the final solution):

Please check:

https://tracker.pharo.org/issues-register-service

> On 15 Jun 2018, at 13:56, Tim Mackinnon  wrote:
> 
> I think Let’s Encrypt can be your friend (that seems to be the instructions 
> all of the providers give - e.g. 
> https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04
>  
> ).
> 
> Alternatively - and this applies more to Pharo.org  - why 
> not stick it on Netlify (https://www.netlify.com/docs/welcome/ 
> ) which does https for you. I was 
> amazed how much it does by checking your site off git and even offers some 
> dynamic hooks too.
> 
> I am still sizing up porting my metalsmith generated site to something pillar 
> based - but the concept is the same and depending on how you do things, it 
> might be quite trivial.
> 
> Tim
> 
>> On 15 Jun 2018, at 10:15, Marcus Denker > > wrote:
>> 
>> Hello,
>> 
>> yes, we really need to setup SSL for that server. I will have a look next 
>> week.
>> 
>>> On 13 Jun 2018, at 10:25, Manuel Leuenberger >> > wrote:
>>> 
>>> Hi,
>>> 
>>> I announced my concerns on Discord already, but got no reaction, so I post 
>>> it here as well to have it properly archived.
>>> 
>>> "A colleague just noticed that the registration for the issue tracker is 
>>> HTTP-only. This is not an appropriate choice for sensitive data like a 
>>> password. Any possibilities to make this HTTPS-only?
>>> Link: http://tracker.pharo.org/issues-register-service 
>>> , setting https:// 
>>> manually does not work"
>>> 
>>> From my perspective this is a serious problem that should be quickly 
>>> addressed, it's not just a nice to have feature. Not treating sensitive 
>>> data with proper care leaves an image of not caring about user security and 
>>> looks unprofessional. I don't think that is what Pharo needs.
>>> 
>>> Cheers,
>>> Manuel
>> 
>> 
> 

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

[Offray Vladimir Luna Cárdenas]

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

Re: [Pharo-users] Insecure issue tracker registration

[Tim Mackinnon]

I think Let’s Encrypt can be your friend (that seems to be the instructions all 
of the providers give - e.g. 
https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04
 
).

Alternatively - and this applies more to Pharo.org - why not stick it on 
Netlify (https://www.netlify.com/docs/welcome/ 
) which does https for you. I was amazed 
how much it does by checking your site off git and even offers some dynamic 
hooks too.

I am still sizing up porting my metalsmith generated site to something pillar 
based - but the concept is the same and depending on how you do things, it 
might be quite trivial.

Tim

> On 15 Jun 2018, at 10:15, Marcus Denker  wrote:
> 
> Hello,
> 
> yes, we really need to setup SSL for that server. I will have a look next 
> week.
> 
>> On 13 Jun 2018, at 10:25, Manuel Leuenberger  
>> wrote:
>> 
>> Hi,
>> 
>> I announced my concerns on Discord already, but got no reaction, so I post 
>> it here as well to have it properly archived.
>> 
>> "A colleague just noticed that the registration for the issue tracker is 
>> HTTP-only. This is not an appropriate choice for sensitive data like a 
>> password. Any possibilities to make this HTTPS-only?
>> Link: http://tracker.pharo.org/issues-register-service, setting https:// 
>> manually does not work"
>> 
>> From my perspective this is a serious problem that should be quickly 
>> addressed, it's not just a nice to have feature. Not treating sensitive data 
>> with proper care leaves an image of not caring about user security and looks 
>> unprofessional. I don't think that is what Pharo needs.
>> 
>> Cheers,
>> Manuel
> 
> 

[Pharo-users] Call for TechTalks

[Marcus Denker]

Hi,

As you might now, we organised “tech talks” in the past:

https://pharo.org/TechTalk 

We would like to continue the next half of 2018 with this series.

The form itself is quite open: it can be a lecture, a demo, or just some 
“guided” discussion on Discord.

If you have ideas —> send me a mail. 

Marcus

Re: [Pharo-users] Insecure issue tracker registration

[Marcus Denker]

Hello,

yes, we really need to setup SSL for that server. I will have a look next week.

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

[Pharo-users] @pharoproject: > 2000 followers

[Marcus Denker]

@pharoproject on twitter now has >2000 followers: 
https://twitter.com/pharoproject

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

[Esteban Lorenzano]

> On 15 Jun 2018, at 10:29, Tim Mackinnon  wrote:
> 
> 
> In many parts of the dev world - every commit should be shippable, meaning 
> atomic - particularly with the use of CI systems (Travis, Gitlab etc) that 
> build on every commit. 

but then, you mean every *push* should be shippable :)
that’s something I agree :)

> 
> Of course you can choose to work a different way - but our tools shouldn’t 
> force a very common practice to be awkward, should they?
> 
> I don’t understand why many of you guys are so anti such a common thing.

I’m not anti. Being “anti” requires a lot of effort I prefer to spend on 
something else :)
But  in general, I prefer many small commits of tasks. And yes, I prefer those 
commits to be atomic, but when is not possible I just make sure I do not push 
until something is finished.

> In fact our community pioneered this way of working - a build machine where 
> you loaded all your code and ran all your tests before committing.  Also, a 
> large number of agile teams will council to work on master (and avoid 
> branches - a technique we also pioneered).

hah… we pioneered it as a technique basically because our tools were not 
capable of branching properly, but well, It can be a way to minimise 
integration problems, yes (depends on the team, of course).

> In today’s world where we live in a wider polyglot stack this is one of the 
> reasons why git is so attractive as it should easily embraces that.
> 
> I get that it’s not quite possible yet - but there are some decent ways to 
> accommodate this (a staging operation, or perhaps a better way to make use of 
> the #addToIndex: which I will experiment with).

I think the easiest/fastest way to handle this is to add a “special commit” 
plugin which could export sources and then delegate commit to an external tool. 
And it could be a plugin because then people wanting to work with it can load 
it independently.

> Anyway, I’ll shut up - and possibly will learn how to implement it myself. 
> Thinking more, I may also be able run with commit and no push , which I will 
> try - as it’s probably the easiest mechanism if the CI will recognise that (I 
> think it will).

do not shut up :)
your opinions and considerations are good and a good way to see a different pov 
that may be better than ours.

> 
> Thanks for the enlightening conversation, and as always the hard work on 
> iceberg that made this conversation even possible.

thank you

Esteban

> 
> Tim
> 
> Sent from my iPhone
> 
> On 15 Jun 2018, at 07:11, Norbert Hartl  > wrote:
> 
>> 
>> 
>> Am 14.06.2018 um 13:12 schrieb Thierry Goubier > >:
>> 
>>> Hi Norbert, Tim,
>>> 
>>> 2018-06-14 11:33 GMT+02:00 Norbert Hartl >> >:
>>> 
>>> 
 Am 14.06.2018 um 10:30 schrieb Tim Mackinnon >>> >:
 
 Hi - yes I’m pleased you check out the entire tree, although currently 
 it’s a bit confusing that you do (fortunately this does give the 
 possibility that we can checkout images and other resources that an Pharo 
 application might rely on - without having to resort to the Seaside 
 FileLibrary trick).
 
 However my concrete case was that I have a gitlab ci pipeline and next to 
 my src directory in my project I have a config directory that has some 
 Nginx config for my teapot app. If I add a teapot route, I also need to 
 adjust that config and check both changes in together. I can’t easily do 
 that now?
 
 I can modify /config/app.nginx either in another app (intellij) or even in 
 the simple Pharo text editor, and the I can add my new route in my 
 DemoApp>>createRoutes method but how do I check them in together so my 
 pipeline will build atomically?
 
 Iceberg hasn’t written out the changes yet, so IntelliJ can’t see them to 
 do a commit, and iceberg ignores the parallel /config directory (that it 
 checked out). So it’s a catch 22.
 
 This is why I suggested maybe we could specify safer (textual) directories 
 that iceberg might also checkin? OR we have a Stage command in iceberg 
 that does everything that commit does up to the point of actually writing 
 to the repo - then I could jump to IntelliJ and do the final commit there 
 and use its tools to manage non Pharo stuff (until we can build more)?
 
 Does this make sense?
 
>>> I don’t understand why you are so eager to have everything into one commit. 
>>> Usually the tension is rather have small commits. What is the problem of 
>>> having two commits for this?
>>> 
>>> A single commit allow one to make sure that both the smalltalk code and the 
>>> external resource are well in sync, and that you may not ending up in a 
>>> situation were at commit j has data format v1 and smalltalk code for format 
>>> v2, because it is in commit j+1 that you rewrote the data in format v2.
>>> 
>> Yes, sure bu

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

[Guillermo Polito]

Hi Tim,

On Fri, Jun 15, 2018 at 10:31 AM Tim Mackinnon  wrote:

>
> In many parts of the dev world - every commit should be shippable, meaning
> atomic - particularly with the use of CI systems (Travis, Gitlab etc) that
> build on every commit.
>
> Of course you can choose to work a different way - but our tools shouldn’t
> force a very common practice to be awkward, should they?
>
> I don’t understand why many of you guys are so anti such a common thing.
> In fact our community pioneered this way of working - a build machine where
> you loaded all your code and ran all your tests before committing.  Also,
> a large number of agile teams will council to work on master (and avoid
> branches - a technique we also pioneered).
> In today’s world where we live in a wider polyglot stack this is one of
> the reasons why git is so attractive as it should easily embraces that.
>
> I get that it’s not quite possible yet - but there are some decent ways to
> accommodate this (a staging operation, or perhaps a better way to make use
> of the #addToIndex: which I will experiment with).
>
> Anyway, I’ll shut up - and possibly will learn how to implement it myself.
> Thinking more, I may also be able run with commit and no push , which I
> will try - as it’s probably the easiest mechanism if the CI will recognise
> that (I think it will).
>

Please don't shut up ^^. I really value the feedback.
I see myself the value of both small and atomic/self-contained/complete
commits.

In general what happens is that we are few modifying iceberg.
But on the other side we really had given a thought to many of these
topics, and many decisions had a reason (even if it is that it is not
implemented because it would be too much work :)).
I try to explain them as better as I can, I can probably do better :)

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

[Tim Mackinnon]

In many parts of the dev world - every commit should be shippable, meaning 
atomic - particularly with the use of CI systems (Travis, Gitlab etc) that 
build on every commit. 

Of course you can choose to work a different way - but our tools shouldn’t 
force a very common practice to be awkward, should they?

I don’t understand why many of you guys are so anti such a common thing. In 
fact our community pioneered this way of working - a build machine where you 
loaded all your code and ran all your tests before committing.  Also, a large 
number of agile teams will council to work on master (and avoid branches - a 
technique we also pioneered).
In today’s world where we live in a wider polyglot stack this is one of the 
reasons why git is so attractive as it should easily embraces that.

I get that it’s not quite possible yet - but there are some decent ways to 
accommodate this (a staging operation, or perhaps a better way to make use of 
the #addToIndex: which I will experiment with).

Anyway, I’ll shut up - and possibly will learn how to implement it myself. 
Thinking more, I may also be able run with commit and no push , which I will 
try - as it’s probably the easiest mechanism if the CI will recognise that (I 
think it will).

Thanks for the enlightening conversation, and as always the hard work on 
iceberg that made this conversation even possible.

Tim

Sent from my iPhone

> On 15 Jun 2018, at 07:11, Norbert Hartl  wrote:
> 
> 
> 
>> Am 14.06.2018 um 13:12 schrieb Thierry Goubier :
>> 
>> Hi Norbert, Tim,
>> 
>> 2018-06-14 11:33 GMT+02:00 Norbert Hartl :
>>> 
>>> 
 Am 14.06.2018 um 10:30 schrieb Tim Mackinnon :
 
 Hi - yes I’m pleased you check out the entire tree, although currently 
 it’s a bit confusing that you do (fortunately this does give the 
 possibility that we can checkout images and other resources that an Pharo 
 application might rely on - without having to resort to the Seaside 
 FileLibrary trick).
 
 However my concrete case was that I have a gitlab ci pipeline and next to 
 my src directory in my project I have a config directory that has some 
 Nginx config for my teapot app. If I add a teapot route, I also need to 
 adjust that config and check both changes in together. I can’t easily do 
 that now?
 
 I can modify /config/app.nginx either in another app (intellij) or even in 
 the simple Pharo text editor, and the I can add my new route in my 
 DemoApp>>createRoutes method but how do I check them in together so my 
 pipeline will build atomically?
 
 Iceberg hasn’t written out the changes yet, so IntelliJ can’t see them to 
 do a commit, and iceberg ignores the parallel /config directory (that it 
 checked out). So it’s a catch 22.
 
 This is why I suggested maybe we could specify safer (textual) directories 
 that iceberg might also checkin? OR we have a Stage command in iceberg 
 that does everything that commit does up to the point of actually writing 
 to the repo - then I could jump to IntelliJ and do the final commit there 
 and use its tools to manage non Pharo stuff (until we can build more)?
 
 Does this make sense?
 
>>> I don’t understand why you are so eager to have everything into one commit. 
>>> Usually the tension is rather have small commits. What is the problem of 
>>> having two commits for this?
>> 
>> A single commit allow one to make sure that both the smalltalk code and the 
>> external resource are well in sync, and that you may not ending up in a 
>> situation were at commit j has data format v1 and smalltalk code for format 
>> v2, because it is in commit j+1 that you rewrote the data in format v2.
>> 
> Yes, sure but that is only a problem if you lost control over which commit 
> goes into action. I think the problem is in the deployment then. Putting 
> integrity constraints on commits is IMHO the wrong level deployment 
> granularity
> 
> Norbert
> 
>> I had that issue recently with a Pharo / FPGA project with a Pharo package 
>> generating state machines to be integrated in a Verilog FPGA design with C 
>> code for the drivers, the softcore in the FPGA, and test programs, and both 
>> Pharo and the C/FPGA working out of the same test data... And that whole 
>> thing getting regularly out of sync.
>> 
>> IMHO: I'd model a concept of "multi-lingual projet" for that sort of things, 
>> where one can list, in Pharo, Monticello packages and external files or 
>> directories. Whatever the technology you use (OSProcess, libgit, 
>> whatever...) it is easy then to commit all this in a single pass. On a 
>> per-package basis, I'd see the package manifest as a suitable place for 
>> listing external resources. On a per-project basis, a possible place could 
>> be the manifest for the BaselineOf the project.
>> 
>> Thierry
>>  
>>> 
>>> Norbert
>>> 
 As an aside - I’d really like to checkin in the play-xxx directories (the 
 .p

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

[Thierry Goubier]

2018-06-15 8:19 GMT+02:00 Esteban Lorenzano :

>
>
> On 15 Jun 2018, at 08:11, Norbert Hartl  wrote:
>
>
>
> Am 14.06.2018 um 13:12 schrieb Thierry Goubier  >:
>
> Hi Norbert, Tim,
>
> 2018-06-14 11:33 GMT+02:00 Norbert Hartl :
>
>>
>>
>> Am 14.06.2018 um 10:30 schrieb Tim Mackinnon :
>>
>> Hi - yes I’m pleased you check out the entire tree, although currently
>> it’s a bit confusing that you do (fortunately this does give the
>> possibility that we can checkout images and other resources that an Pharo
>> application might rely on - without having to resort to the Seaside
>> FileLibrary trick).
>>
>> However my concrete case was that I have a gitlab ci pipeline and next to
>> my src directory in my project I have a config directory that has some
>> Nginx config for my teapot app. If I add a teapot route, I also need to
>> adjust that config and check both changes in together. I can’t easily do
>> that now?
>>
>> I can modify /config/app.nginx either in another app (intellij) or even
>> in the simple Pharo text editor, and the I can add my new route in my
>> DemoApp>>createRoutes method but how do I check them in together so my
>> pipeline will build atomically?
>>
>> Iceberg hasn’t written out the changes yet, so IntelliJ can’t see them to
>> do a commit, and iceberg ignores the parallel /config directory (that it
>> checked out). So it’s a catch 22.
>>
>> This is why I suggested maybe we could specify safer (textual)
>> directories that iceberg might also checkin? OR we have a Stage command in
>> iceberg that does everything that commit does up to the point of actually
>> writing to the repo - then I could jump to IntelliJ and do the final commit
>> there and use its tools to manage non Pharo stuff (until we can build more)?
>>
>> Does this make sense?
>>
>> I don’t understand why you are so eager to have everything into one
>> commit. Usually the tension is rather have small commits. What is the
>> problem of having two commits for this?
>>
>
> A single commit allow one to make sure that both the smalltalk code and
> the external resource are well in sync, and that you may not ending up in a
> situation were at commit j has data format v1 and smalltalk code for format
> v2, because it is in commit j+1 that you rewrote the data in format v2.
>
> Yes, sure but that is only a problem if you lost control over which commit
> goes into action. I think the problem is in the deployment then. Putting
> integrity constraints on commits is IMHO the wrong level deployment
> granularity
>
>
> +1
> git favours many small commits.
>

.. and suggests you use rebase, squash and etc... to make sense of those
many small commits.

Thierry


>
> Esteban
>
>
> Norbert
>
> I had that issue recently with a Pharo / FPGA project with a Pharo package
> generating state machines to be integrated in a Verilog FPGA design with C
> code for the drivers, the softcore in the FPGA, and test programs, and both
> Pharo and the C/FPGA working out of the same test data... And that whole
> thing getting regularly out of sync.
>
> IMHO: I'd model a concept of "multi-lingual projet" for that sort of
> things, where one can list, in Pharo, Monticello packages and external
> files or directories. Whatever the technology you use (OSProcess, libgit,
> whatever...) it is easy then to commit all this in a single pass. On a
> per-package basis, I'd see the package manifest as a suitable place for
> listing external resources. On a per-project basis, a possible place could
> be the manifest for the BaselineOf the project.
>
> Thierry
>
>
>>
>> Norbert
>>
>> As an aside - I’d really like to checkin in the play-xxx directories (the
>> .ph files) as there is often useful playground stuff I’d like to access on
>> my home computer. We can’t do that easily at the moment either.
>>
>> Tim
>>
>> Sent from my iPhone
>>
>> On 14 Jun 2018, at 09:12, Guillermo Polito 
>> wrote:
>>
>> Just to complement Esteban's answer:
>>
>> - Iceberg checks out in disk more than the src directory because you
>> **may** want to edit files from the command line, and after long
>> discussions we did not want to forbid that.
>> Actually, just to put everybody in perspective, at first the idea was to
>> not have a working copy in disk at all, but just hit to the blob.
>> Imagine is nowadays we are a bit alien, that would have been worst :)
>>
>> - About checking in files. I'd like to understand what you mean exactly.
>>   - Do you want to load them into memory?
>> This would be the "more consistent" way to do it, following the "the
>> image it its own working copy" metaphore.
>> This would allow us to, for example, share an image and transparently
>> share resources with it (without requiring to clone).
>> But this would have some impact in memory consumption and add stress
>> to the GC, right?
>>
>>   - Or do you mean to ask like any other Git client and show you the file
>> differences between the working copy and the git index?
>> The problem with this approach is 

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

[Thierry Goubier]

2018-06-15 8:11 GMT+02:00 Norbert Hartl :

>
>
> Am 14.06.2018 um 13:12 schrieb Thierry Goubier  >:
>
> Hi Norbert, Tim,
>
> 2018-06-14 11:33 GMT+02:00 Norbert Hartl :
>
>>
>>
>> Am 14.06.2018 um 10:30 schrieb Tim Mackinnon :
>>
>> Hi - yes I’m pleased you check out the entire tree, although currently
>> it’s a bit confusing that you do (fortunately this does give the
>> possibility that we can checkout images and other resources that an Pharo
>> application might rely on - without having to resort to the Seaside
>> FileLibrary trick).
>>
>> However my concrete case was that I have a gitlab ci pipeline and next to
>> my src directory in my project I have a config directory that has some
>> Nginx config for my teapot app. If I add a teapot route, I also need to
>> adjust that config and check both changes in together. I can’t easily do
>> that now?
>>
>> I can modify /config/app.nginx either in another app (intellij) or even
>> in the simple Pharo text editor, and the I can add my new route in my
>> DemoApp>>createRoutes method but how do I check them in together so my
>> pipeline will build atomically?
>>
>> Iceberg hasn’t written out the changes yet, so IntelliJ can’t see them to
>> do a commit, and iceberg ignores the parallel /config directory (that it
>> checked out). So it’s a catch 22.
>>
>> This is why I suggested maybe we could specify safer (textual)
>> directories that iceberg might also checkin? OR we have a Stage command in
>> iceberg that does everything that commit does up to the point of actually
>> writing to the repo - then I could jump to IntelliJ and do the final commit
>> there and use its tools to manage non Pharo stuff (until we can build more)?
>>
>> Does this make sense?
>>
>> I don’t understand why you are so eager to have everything into one
>> commit. Usually the tension is rather have small commits. What is the
>> problem of having two commits for this?
>>
>
> A single commit allow one to make sure that both the smalltalk code and
> the external resource are well in sync, and that you may not ending up in a
> situation were at commit j has data format v1 and smalltalk code for format
> v2, because it is in commit j+1 that you rewrote the data in format v2.
>
> Yes, sure but that is only a problem if you lost control over which commit
> goes into action. I think the problem is in the deployment then. Putting
> integrity constraints on commits is IMHO the wrong level deployment
> granularity
>

That may be.

But I'm not used to consider co-working on the same branch with my HW
engineer as "deployment"...

Thierry


>
> Norbert
>
> I had that issue recently with a Pharo / FPGA project with a Pharo package
> generating state machines to be integrated in a Verilog FPGA design with C
> code for the drivers, the softcore in the FPGA, and test programs, and both
> Pharo and the C/FPGA working out of the same test data... And that whole
> thing getting regularly out of sync.
>
> IMHO: I'd model a concept of "multi-lingual projet" for that sort of
> things, where one can list, in Pharo, Monticello packages and external
> files or directories. Whatever the technology you use (OSProcess, libgit,
> whatever...) it is easy then to commit all this in a single pass. On a
> per-package basis, I'd see the package manifest as a suitable place for
> listing external resources. On a per-project basis, a possible place could
> be the manifest for the BaselineOf the project.
>
> Thierry
>
>
>>
>> Norbert
>>
>> As an aside - I’d really like to checkin in the play-xxx directories (the
>> .ph files) as there is often useful playground stuff I’d like to access on
>> my home computer. We can’t do that easily at the moment either.
>>
>> Tim
>>
>> Sent from my iPhone
>>
>> On 14 Jun 2018, at 09:12, Guillermo Polito 
>> wrote:
>>
>> Just to complement Esteban's answer:
>>
>> - Iceberg checks out in disk more than the src directory because you
>> **may** want to edit files from the command line, and after long
>> discussions we did not want to forbid that.
>> Actually, just to put everybody in perspective, at first the idea was to
>> not have a working copy in disk at all, but just hit to the blob.
>> Imagine is nowadays we are a bit alien, that would have been worst :)
>>
>> - About checking in files. I'd like to understand what you mean exactly.
>>   - Do you want to load them into memory?
>> This would be the "more consistent" way to do it, following the "the
>> image it its own working copy" metaphore.
>> This would allow us to, for example, share an image and transparently
>> share resources with it (without requiring to clone).
>> But this would have some impact in memory consumption and add stress
>> to the GC, right?
>>
>>   - Or do you mean to ask like any other Git client and show you the file
>> differences between the working copy and the git index?
>> The problem with this approach is that we will have some treatment
>> for pharo code and some different treatment for non-code...
>>

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

[Christophe Demarey]

Hi Tim,

> Le 14 juin 2018 à 18:48, Tim Mackinnon  a écrit :
> 
> Is PharoLauncher using git - there is a note saying the StHub repo is about 
> to be moved?
> 
> I ask as I wanted to contribute a simple change that shows the modified date 
> of the images and lets you sort by that (I sometimes forget which was the 
> latest image I was using and have a few old ones kicking around).


Until now, I preferred to stay on StHub mainly because Iceberg was not ready to 
work smoothly with. I did not wanted to get extra-difficulties to work on Pharo 
Launcher (merge problems, etc).
That said, Iceberg has now moved a lot in the right direction and I think we 
could start to use git for Pharo Launcher development.
I will release a ne version of PharoLauncher soon and then, I think I will move 
PharoLauncher on github and use Cargo to manage it.

For your contribution, it is welcomed (in fact, it was planned to be added but 
you were faster). Feel free to commit it directly to the SH repository, I will 
then take a look at it. It looks like you already can commit: 
http://smalltalkhub.com/#!/~Pharo/PharoLauncher/contributors.

Thanks Tim.

Regards,
Christophe