August 2017 - Pharo-dev - lists.pharo.org

GTInspector auto refresh hooks?

by Denis Kudriashov

Hi. Is there a way in GTInspector presentation to call some special updating block before each of auto refresh operation? I want something like: composite fastTable title: 'Devices'; display: [ devices ]; wantsAutomaticRefresh: true; * beforeUpdateDo: ["rows updating code"]* Imaging my presentation shows database table and I want query updated rows. (I activate updating by GTInspector setEnabledStepRefreshStatus: true). Best regards, Denis

Aug. 9, 2017

Re: [Pharo-dev] FileSystem fix integration

by Denis Kudriashov

Hi 2017-08-09 8:47 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > Hi Stef, > > On Tue, Aug 08, 2017 at 07:00:04PM +0200, Stephane Ducasse wrote: > > Hi Alistair > > > > I'm going over the green build first. > > > > - Then also https://pharo.fogbugz.com/f/cases/18042/FileSystem-a-file- > doesn-t-exist-but-still-exists > > I read it but do you suggest to drop it and close it? > > I don't think this issue should be dropped, there is a regular stream of > questions to the mailing list from newcomers getting confused by the > current behaviour. > > There are basically two opposing proposals: > > 1. Modify FileReference>>/ to accept a path and parse it correctly > (which is what I proposed). > 2. Modify FileReference>>/ to explicitly reject an argument which > includes the path delimiter (and it should suggest using #resolve:). > > The first proposal is more "practical", and the second is more "pure", > keeping the to original design goals and abstractions. > > Both have had multiple people support them, and both are better than the > current situation, however it is subjective as to which of the two > proposals is better. > I would vote for first solution > > I'm not sure what the normal tie-breaking process is, but I'm happy to > defer to the Pharo Association (Esteban? / Marcus? / yourself?). > > Cheers, > Alistair > >

Aug. 9, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Cyril Ferlicot

On Wed, Aug 9, 2017 at 9:33 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > yes, the keys may be an issue, but the standard rsa generated key should > work. We need to do a pass in security/credentials system (and probably a > revamp of some parts), but I still didnât find the time. > about the 255 limitation, if you execute this in command line: > > git config --system core.longpaths true > I already did it but I still get the problem :( > it should also fix the problem with pharo repo. > > Esteban > > > -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Aug. 9, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Esteban Lorenzano

> On 8 Aug 2017, at 23:47, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > > Le 08/08/2017 Ã 23:40, Nicolai Hess a Ã©crit : >> Thanks for the info, cyril. >> >> What do you use for the ssh username in pharo setting and what username >> did you use for creating the ssh-key ? >> I tried both, my github-email and my github-username, I didn't get it to >> work. >> > > I did not use anything special. While creating the ssh key I used all > the default options and in the setting I do not change the username (see > joined screenshot). > > This is the command I probably used since I followed github tutorial[1]: > > ssh-keygen -t rsa -b 4096 -C "cyril.ferlicot(a)gmail.com" > > [1] https://help.github.com/articles/connecting-to-github-with-ssh/ <https://help.github.com/articles/connecting-to-github-with-ssh/> yes, the keys may be an issue, but the standard rsa generated key should work. We need to do a pass in security/credentials system (and probably a revamp of some parts), but I still didnât find the time. about the 255 limitation, if you execute this in command line: git config --system core.longpaths true it should also fix the problem with pharo repo. Esteban > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > <PharoScreenshot.png>

Aug. 9, 2017

Re: [Pharo-dev] FileSystem fix integration

by Alistair Grant

Hi Stef, On Tue, Aug 08, 2017 at 07:00:04PM +0200, Stephane Ducasse wrote: > Hi Alistair > > I'm going over the green build first. > > - Then also https://pharo.fogbugz.com/f/cases/18042/FileSystem-a-file-doesn-t-exist-but… > I read it but do you suggest to drop it and close it? I don't think this issue should be dropped, there is a regular stream of questions to the mailing list from newcomers getting confused by the current behaviour. There are basically two opposing proposals: 1. Modify FileReference>>/ to accept a path and parse it correctly (which is what I proposed). 2. Modify FileReference>>/ to explicitly reject an argument which includes the path delimiter (and it should suggest using #resolve:). The first proposal is more "practical", and the second is more "pure", keeping the to original design goals and abstractions. Both have had multiple people support them, and both are better than the current situation, however it is subjective as to which of the two proposals is better. I'm not sure what the normal tie-breaking process is, but I'm happy to defer to the Pharo Association (Esteban? / Marcus? / yourself?). Cheers, Alistair

Aug. 9, 2017

Re: [Pharo-dev] FileSystem fix integration

by Alistair Grant

Hi Stef, On Tue, Aug 08, 2017 at 07:29:02PM +0200, Guillermo Polito wrote: > Hi Stef, > > On Tue, Aug 8, 2017 at 7:00 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > Hi Alistair > > I'm going over the green build first. > > - Can you tell me what you think about the PR 92 05723 Default Working > Directory > https://pharo.fogbugz.com/f/cases/5723/ > > > This cannot be integrated yet. We have to review dependencies in the bootstrap, > because it introduces a (correct) definition of a working directory but using > FFI. And FFI is not in the kernel. I'm looking forward to this PR, as with most people, I think this will make scripting with Pharo much easier (I've also used the workaround of forking a shell to get the output of pwd :-(). Rajula went out of his way to discuss the implications of this on the mailing list, see: http://forum.world.st/The-new-implementation-of-current-working-directory-t… For full transparency, I haven't tested the code, but might try and load it over the next week or so. Obviously the issue Guillermo raises needs to be addressed before it can be integrated. Cheers, Alistair

Aug. 9, 2017

Re: [Pharo-dev] Having green builds

by Martin Dias

On Sun, Aug 6, 2017 at 6:00 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi all, > > As you all know, we are now building from github. Integrations are made > through pull requests. And pull requests are validated using jenkins (that > is back again, Yay!). > > In this scenario, pull requests validations in github differentiate only > between three states: Pased (green) and not passed (red). This of course > conflicts with the three-state jobs of jenkins. By default jenkins > transforms failing tests (yellow) to a red state. This means that we lose > the extra information provided by the intermediate state. > > Now, because of this, in order to really differentiate good builds from > bad builds, we need to have green builds :). Always. > > Yesterday we worked with Pablo on that and now we have a PR that fixes all > tests and is green :) > > https://github.com/pharo-project/pharo/pull/184 > > You can follow up all the things we did in the issue also: > > https://pharo.fogbugz.com/f/cases/20288/Fix-failing-tests-in-pharo-70 > > As a summary, we could fix most tests by just touching some code here and > there. Some of them were portability issues, some other encoding in the > build slaves and so on. The only one we could not fix was a problem cause > by a side effect of QualityAssistant-Tests, so we skipped it. Those two > tests should be rewritten to not have side effects on other tests (In this > case, Epicea). > Updates? anything has to be rewriten in the Epicea tests? > > Enjoy, > Guille and Pablo > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 >

Aug. 9, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Cyril Ferlicot D.

Le 08/08/2017 Ã 23:40, Nicolai Hess a Ã©crit : > Thanks for the info, cyril. > > What do you use for the ssh username in pharo setting and what username > did you use for creating the ssh-key ? > I tried both, my github-email and my github-username, I didn't get it to > work. > I did not use anything special. While creating the ssh key I used all the default options and in the setting I do not change the username (see joined screenshot). This is the command I probably used since I followed github tutorial[1]: ssh-keygen -t rsa -b 4096 -C "cyril.ferlicot(a)gmail.com" [1] https://help.github.com/articles/connecting-to-github-with-ssh/ -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Aug. 8, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Cyril Ferlicot D.

Le 08/08/2017 Ã 23:37, Nicolai Hess a Ã©crit : > > > Like I described above. > > I followed this howto ( the first mail from pavel). > > But I get this error: > > 'LGit_GIT_ERROR: Failed to authenticate SSH session: Callback returned > error' > > > Now I enabled the setting for "Use custom SSH keys", followed the > github-doc for adding a ssh-key on windows and add this key to my > github-account. > But I still get the same error. > > To be sure this is not a ssh key problem you can try to install git bash and to commit on a repository with a ssh remote. If it works you'll be sure the ssh key is good. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Aug. 8, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Nicolai Hess

2017-08-08 23:05 GMT+02:00 Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>: > Le 08/08/2017 Ã 20:40, Nicolai Hess a Ã©crit : > > > > Any news on howto use iceberg / libgit on windows. > > Does no one else use windows ? > > > > Hi, > > I can use Iceberg on Windows 7 but not to participate to Pharo (or any > project with file name longer than 255chars). > > So I can work on my projects or on projects like Iceberg. I have a ssh > key on my Windows that is associated to my github account and I have a > startup script executing this: > > IceCredentialsProvider useCustomSsh: true. > > Since my ssh key has the default name for a rsa key it select it by > default and I can use Iceberg. > Thanks for the info, cyril. What do you use for the ssh username in pharo setting and what username did you use for creating the ssh-key ? I tried both, my github-email and my github-username, I didn't get it to work. > > -- > Cyril Ferlicot > https://ferlicot.fr > > http://www.synectique.eu > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

Aug. 8, 2017