Re: [Pharo-dev] FileSystem fix integration

[Alistair Grant]

Hi Stef,

On Wed, Aug 09, 2017 at 08:23:50PM +0200, Stephane Ducasse wrote:
> Tx!
> So that I do not make mistake:
> The fix is the second solution. Now do we have somewhere the first one?

Not yet.  My patch also fixes some inconsistencies in path
canonicalisation.

I'll separate the code out in to two separate patches and post.

Cheers,
Alistair



> On Wed, Aug 9, 2017 at 10:08 AM, Denis Kudriashov  
> wrote:
> > Hi
> >
> > 2017-08-09 8:47 GMT+02:00 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-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
> >>
> >
> 

Re: [Pharo-dev] Pharo 7 provisional HOWTO

[Nicolai Hess]

2017-08-09 9:33 GMT+02:00 Esteban Lorenzano :

>
> On 8 Aug 2017, at 23:47, Cyril Ferlicot D. 
> 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.ferli...@gmail.com"
>
> [1] 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
>

Now I have the same problem. I can not get the pharo repo because it can
not operate on files with long path names.
even with longpaths true, this does not work ...


>
>
> --
> Cyril Ferlicot
> https://ferlicot.fr
>
> http://www.synectique.eu
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
> 
>
>
>

Re: [Pharo-dev] Pharo 7 provisional HOWTO

[Nicolai Hess]

2017-08-09 23:18 GMT+02:00 Nicolai Hess :

>
>
> 2017-08-08 23:41 GMT+02:00 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.
>>
>>
> yes, just tested, this seems to work. I can use the key for a ssh remote
> commit from the command line.
> but somehow I can not use it with pharo /iceberg..
>
>

Ah, I think I got it to work now.
I created a new ssh key, but this time I did not set a passphrase.
So maybe, ssh remotes with iceberg are only working if you don't use
passphrases for you secret key!


> --
>> Cyril Ferlicot
>> https://ferlicot.fr
>>
>> http://www.synectique.eu
>> 2 rue Jacques Prévert 01,
>> 59650 Villeneuve d'ascq France
>>
>>
>

Re: [Pharo-dev] Pharo 7 provisional HOWTO

[Nicolai Hess]

2017-08-08 23:41 GMT+02:00 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.
>
>
yes, just tested, this seems to work. I can use the key for a ssh remote
commit from the command line.
but somehow I can not use it with pharo /iceberg..


> --
> Cyril Ferlicot
> https://ferlicot.fr
>
> http://www.synectique.eu
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
>
>

Re: [Pharo-dev] Shouldn't new:0 fail for non-indexable classes

[Nicolai Hess]

2017-08-09 22:14 GMT+02:00 Eliot Miranda :

> Hi Nicolai,
>
> On Tue, Aug 8, 2017 at 12:10 PM, Nicolai Hess 
> wrote:
>
>> see fogbugz 20246 (https://pharo.fogbugz.com/f/c
>> ases/20246/Segfault-calling-new-0)
>>
>> Create a class with a single instance variable.
>>
>> call
>>
>> AClass new:0
>>
>> -> segfaults (on windows latest vm).
>> I can reproduce this on squeak (Squeak5.1-16549-32bit). It does not crash
>> right away, but
>> I was able to crash it by debugging into the new: call.
>>
>> from the comment of Behavior>>#new: , I would expect the error:
>>
>> self error: self printString, ' cannot have variable sized instances'
>>
>
> Quite right.  Squeak and Pharo used to have a funky class DirectoryEntry
> that was expected to be able to be instantiated with DirectoryEntry new:
> 0.  The (Spur) VM bug is that the object was being filled with 0's instead
> of nil.  I've fixed the Spur VM to now fail for any non-indexable class
> since, AFAICT, DirectoryEntry is no longer used in this way.
>

Thank you!


>
> _,,,^..^,,,_
> best, Eliot
>

Re: [Pharo-dev] [Pharo 70] build 19 / PR-168

[Guillermo Polito]

Probably you already saw it, but builds are green again. As I told you this
afternoon, there are some hiccups that cause failures from time to time. We
should chase them one by one :)

Le mer. 9 août 2017 à 21:47, Stephane Ducasse  a
écrit :

>
> https://pharo.fogbugz.com/f/cases/20238/Run-out-of-memory-the-image-hangs-without-out-of-memory-warning
>
> https://github.com/pharo-project/pharo/pull/168
>
> Now I get message that I do not understand test failure error from jenkins
> :(
>
>
> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/19/
>
>
> I can tell you that leaving the confort zone of a working but weak
> process for the
> promise of a better one is still painful.
>
> Stef
>
> --



Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*




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

*Phone: *+33 06 52 70 66 13

[Pharo-dev] [Pharo 70] build 21 / PR 187

[Stephane Ducasse]

 in PR 21
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/21/

https://pharo.fogbugz.com/f/cases/20295/

Stef

Re: [Pharo-dev] Shouldn't new:0 fail for non-indexable classes

[Eliot Miranda]

Hi Nicolai,

On Tue, Aug 8, 2017 at 12:10 PM, Nicolai Hess  wrote:

> see fogbugz 20246 (https://pharo.fogbugz.com/f/
> cases/20246/Segfault-calling-new-0)
>
> Create a class with a single instance variable.
>
> call
>
> AClass new:0
>
> -> segfaults (on windows latest vm).
> I can reproduce this on squeak (Squeak5.1-16549-32bit). It does not crash
> right away, but
> I was able to crash it by debugging into the new: call.
>
> from the comment of Behavior>>#new: , I would expect the error:
>
> self error: self printString, ' cannot have variable sized instances'
>

Quite right.  Squeak and Pharo used to have a funky class DirectoryEntry
that was expected to be able to be instantiated with DirectoryEntry new:
0.  The (Spur) VM bug is that the object was being filled with 0's instead
of nil.  I've fixed the Spur VM to now fail for any non-indexable class
since, AFAICT, DirectoryEntry is no longer used in this way.

_,,,^..^,,,_
best, Eliot

Re: [Pharo-dev] FileSystem fix integration

[Stephane Ducasse]

Hi alistair

I went on fogbugz to find the fix to be included and I'm not sure not
that find them.
I looked for FileSystem.

I found
 - https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing

 - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile
   https://github.com/pharo-project/pharo/pull/133

 - 
https://pharo.fogbugz.com/f/cases/19609/FileReference-base-should-be-before-last-separator
   https://github.com/pharo-project/pharo/pull/137

Did I miss some others?

Stef


On Tue, Aug 8, 2017 at 10:27 AM, Stephane Ducasse
 wrote:
> Hi alistair
>
> I will go over all the FS changes and push them in Pharo 70.
> I'm learning the process to integrate fixes and I attract bugs :)
>
> Stef

Re: [Pharo-dev] Spec menu extensibility (epicea)

[Stephane Ducasse]

Hi Peter

Yes I was thinking about it.
Now from your experience what kind of pragma should we provide?



Not sure that we need the argument to the group.





Stef




On Sun, Aug 6, 2017 at 12:09 AM, Peter Uhnak  wrote:
> Hi Stef,
>
> I faced similar issue and then I've found out that PragmaMenuBuilder is 
> compatible with Spec.
>
> Something like...
>
> builder := PragmaMenuBuilder pragmaKeyword: 'myPragma' model: self.
> menu := MenuModel new.
> menu fromSpec: builder menuSpec.
>
> Peter
>
>
> On Sat, Aug 05, 2017 at 06:26:45PM +0200, Stephane Ducasse wrote:
>> Hi guys
>>
>> I would like to know if there is a pattern to build extensible menu in Spec.
>> For example, I extending Epicea to support pillar fileout so that I
>> can turn a coding section into a pillar steps of action.
>>
>> I wanted to extend the epicea browser to get my menu in:
>> But the code is like that:
>>
>> EPLogBrowserModel >> addMenuItemsForSelectedItemsIn: aMenu
>>
>>   aMenu addGroup: [ :aGroup |
>> self menuActionsForSelectedItems do: [ :oldStyleMenuItemArray |
>>  aGroup addItem: [ :anItem |
>> anItem
>>name: oldStyleMenuItemArray first;
>>description: oldStyleMenuItemArray third;
>>icon: (self iconNamed: oldStyleMenuItemArray fourth);
>>action: [ self perform: oldStyleMenuItemArray second ] ] ] ].
>>
>>   aMenu addGroup: [ :aGroup |
>>  aGroup addItem: [ :anItem |
>> anItem
>>   name: 'Filters';
>>   icon: (self iconNamed: #smallFindIcon);
>>   subMenu: self filtersSubMenu ] ].
>>
>>   aMenu addGroup: [ :aGroup |
>> aGroup addItem: [ :anItem |
>> anItem
>>  name: 'File Out';
>>  description: 'Write selected entries to an Ombu file';
>>  icon: (self iconNamed: #smallSaveAsIcon);
>>  action: [ self fileOutSelection ] ] ].
>>
>>
>> EPLogBrowserModel >> menuMorphForSelectedItems
>>
>>  | aMenu |
>>  aMenu := MenuModel new.
>>  showEntryItemMenu ifTrue: [ self
>> addMenuItemsForSelectedItemsIn: aMenu ].
>>  ^ aMenu buildWithSpecAsPopup
>>
>>
>> So I would like to improve Epicea but I face the problem of the limits
>> of Spec (presumably).
>> I'm thinking to add a  pragma to handle this case.
>> Any thought.
>>
>> Stef
>>
>

[Pharo-dev] [Pharo 70] build 19 / PR-168

[Stephane Ducasse]

https://pharo.fogbugz.com/f/cases/20238/Run-out-of-memory-the-image-hangs-without-out-of-memory-warning

https://github.com/pharo-project/pharo/pull/168

Now I get message that I do not understand test failure error from jenkins :(

https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/19/


I can tell you that leaving the confort zone of a working but weak
process for the
promise of a better one is still painful.

Stef

[Pharo-dev] [Pharo 70] build 18 / PR 66

[Stephane Ducasse]

20063-isDeprecated-should-consider-protocol-names

Stef

Re: [Pharo-dev] FileSystem fix integration

[Stephane Ducasse]

Tx!
So that I do not make mistake:
The fix is the second solution. Now do we have somewhere the first one?

On Wed, Aug 9, 2017 at 10:08 AM, Denis Kudriashov  wrote:
> Hi
>
> 2017-08-09 8:47 GMT+02:00 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-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
>>
>

Re: [Pharo-dev] FileSystem fix integration

[Stephane Ducasse]

Tx guille.
So I will update the bug entry.

On Tue, Aug 8, 2017 at 7:29 PM, Guillermo Polito 
wrote:

> Hi Stef,
>
> On Tue, Aug 8, 2017 at 7:00 PM, Stephane Ducasse 
> 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.
>
>
>>
>> - Then also https://pharo.fogbugz.com/f/cases/18042/FileSystem-a-file-do
>> esn-t-exist-but-still-exists
>> I read it but do you suggest to drop it and close it?
>>
>> TX
>>
>> On Tue, Aug 8, 2017 at 6:44 PM, Stephane Ducasse
>>  wrote:
>> > For the moment I'm trying to understand the process and this is not
>> that simple
>> > because in flux.
>> >
>> > stef
>> >
>> > On Tue, Aug 8, 2017 at 3:24 PM, Alistair Grant 
>> wrote:
>> >> Hi Stef,
>> >>
>> >> Great, thanks!
>> >>
>> >> If you've got any questions or concerns, please let me know, I'm more
>> >> than happy to discuss them.
>> >>
>> >> I've also got one more change that I haven't submitted yet.  I
>> >> originally developed a patch that modified FileReference>>/ to accept
>> >> paths.  However this directly conflicts with the change proposed in
>> >> https://pharo.fogbugz.com/f/cases/18042/FileSystem-a-file-do
>> esn-t-exist-but-still-exists.
>> >> Opinion seems to be split on which way we should go, so I'll defer to
>> >> higher authority on this particular issue.  My patch also separated
>> >> path canonicalisation, as discussed in
>> >> http://forum.world.st/FileReference-gt-gt-and-path-canonical
>> isation-td4952575.html,
>> >> so I might separate that out and make it a separate patch.
>> >>
>> >>
>> >> Cheers,
>> >> Alistair
>> >>
>> >> On 8 August 2017 at 10:27, Stephane Ducasse 
>> wrote:
>> >>> Hi alistair
>> >>>
>> >>> I will go over all the FS changes and push them in Pharo 70.
>> >>> I'm learning the process to integrate fixes and I attract bugs :)
>> >>>
>> >>> Stef
>> >>>
>> >>
>>
>>
>
>
> --
>
>
>
> Guille Polito
>
>
> Research Engineer
>
> French National Center for Scientific Research - *http://www.cnrs.fr*
> 
>
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>

[Pharo-dev] [Pharo 70] PR 185 / Build 17

[Stephane Ducasse]

Hi

We do not have yet an automated mail after each integration. So I will
do it by hand.
I'm going over the green issues

https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/view/change-requests/

And integrating the ones I understand. Then I will look at the other ones.

Stef

[Pharo 70] PR 185 / Build 17

SLICE-Issue-18818-Add-labelled-simple-widget

https://github.com/pharo-project/pharo/commit/73ffa96a4993ca482410437c91f3953813c438f9

Re: [Pharo-dev] GTInspector auto refresh hooks?

[Andrei Chis]

On Wed, Aug 9, 2017 at 3:32 PM, Denis Kudriashov 
wrote:

> Actually I found trick:
>
> composite fastTable
>
> title: 'Devices';
> display: [ devices ];
> wantsAutomaticRefresh: true;
>
>  *when: GLMPresentationRefreshRequest do: [myModel update].*
>
>
> Event handler can be executed after actual view update because announcer
> do not ensure delivering order. But in that case new value will be shown at
> next refresh which should be fine.
> What you thing?
>

Interesting trick :). But I think it should work. Like you said in the
worst case the user will see the new data at the next refresh.

Cheers,
Andrei


>
> 2017-08-09 13:47 GMT+02:00 Andrei Chis :
>
>> Hi Denis,
>>
>> The current update mechanism in the inspector is very light, in the sense
>> that it only updates the visual representation of elements and does not
>> recompute them, nor offers any hooks into the update process.
>> Indeed having a way to also recompute the display elements could be
>> useful. We could change the update mechanism to add different kind of
>> update strategies.
>>
>> Cheers,
>> Andrei
>>
>> On Wed, Aug 9, 2017 at 10:58 AM, Denis Kudriashov 
>> wrote:
>>
>>> 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
>>>
>>
>>
>

Re: [Pharo-dev] GTInspector auto refresh hooks?

[Denis Kudriashov]

Actually I found trick:

composite fastTable

title: 'Devices';
display: [ devices ];
wantsAutomaticRefresh: true;

 *when: GLMPresentationRefreshRequest do: [myModel update].*


Event handler can be executed after actual view update because announcer do
not ensure delivering order. But in that case new value will be shown at
next refresh which should be fine.
What you thing?

2017-08-09 13:47 GMT+02:00 Andrei Chis :

> Hi Denis,
>
> The current update mechanism in the inspector is very light, in the sense
> that it only updates the visual representation of elements and does not
> recompute them, nor offers any hooks into the update process.
> Indeed having a way to also recompute the display elements could be
> useful. We could change the update mechanism to add different kind of
> update strategies.
>
> Cheers,
> Andrei
>
> On Wed, Aug 9, 2017 at 10:58 AM, Denis Kudriashov 
> wrote:
>
>> 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
>>
>
>

Re: [Pharo-dev] GTInspector auto refresh hooks?

[Andrei Chis]

Hi Denis,

The current update mechanism in the inspector is very light, in the sense
that it only updates the visual representation of elements and does not
recompute them, nor offers any hooks into the update process.
Indeed having a way to also recompute the display elements could be useful.
We could change the update mechanism to add different kind of update
strategies.

Cheers,
Andrei

On Wed, Aug 9, 2017 at 10:58 AM, Denis Kudriashov 
wrote:

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

Re: [Pharo-dev] Pull requests ready to be reviewed

[Alistair Grant]

On Wed, Aug 09, 2017 at 12:20:17PM +0200, Guillermo Polito wrote:
> On Wed, Aug 9, 2017 at 11:09 AM, Pavel Krivanek 
> wrote:
> 
> We have several pull requests validated successfully by the 
> infrastructure.
> They need to be reviewed by humans:
> 
> https://github.com/pharo-project/pharo/pull/75
> 
> 
> This one has a merge coflict.

This is also the subject of a current discussion, see subject
"FileSystem fix integration"

Cheers,
Alistair


> https://github.com/pharo-project/pharo/pull/66
> 
> 
> I made a little review there :)
>  
> 
> 
> 
> https://github.com/pharo-project/pharo/pull/175
> 
> https://github.com/pharo-project/pharo/pull/172
> 
> https://github.com/pharo-project/pharo/pull/169
> 
> https://github.com/pharo-project/pharo/pull/168
> 
> https://github.com/pharo-project/pharo/pull/134

Re: [Pharo-dev] Pull requests ready to be reviewed

[Guillermo Polito]

On Wed, Aug 9, 2017 at 11:09 AM, Pavel Krivanek 
wrote:

> We have several pull requests validated successfully by the
> infrastructure. They need to be reviewed by humans:
>
> https://github.com/pharo-project/pharo/pull/75
>

This one has a merge coflict.


>
>
> https://github.com/pharo-project/pharo/pull/66
>

I made a little review there :)


>
>
> https://github.com/pharo-project/pharo/pull/175
>
> https://github.com/pharo-project/pharo/pull/172
>
> https://github.com/pharo-project/pharo/pull/169
>
> https://github.com/pharo-project/pharo/pull/168
>
> https://github.com/pharo-project/pharo/pull/134
>
> Cheers,
> -- Pavel
>
>
>


-- 



Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*




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

*Phone: *+33 06 52 70 66 13

[Pharo-dev] Pull requests ready to be reviewed

[Pavel Krivanek]

We have several pull requests validated successfully by the infrastructure.
They need to be reviewed by humans:

https://github.com/pharo-project/pharo/pull/75

https://github.com/pharo-project/pharo/pull/66

https://github.com/pharo-project/pharo/pull/175

https://github.com/pharo-project/pharo/pull/172

https://github.com/pharo-project/pharo/pull/169

https://github.com/pharo-project/pharo/pull/168

https://github.com/pharo-project/pharo/pull/134

Cheers,
-- Pavel

[Pharo-dev] GTInspector auto refresh hooks?

[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

Re: [Pharo-dev] FileSystem fix integration

[Denis Kudriashov]

Hi

2017-08-09 8:47 GMT+02:00 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-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
>
>

Re: [Pharo-dev] Pharo 7 provisional HOWTO

[Cyril Ferlicot]

On Wed, Aug 9, 2017 at 9:33 AM, Esteban Lorenzano  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

Re: [Pharo-dev] Pharo 7 provisional HOWTO

[Esteban Lorenzano]

> On 8 Aug 2017, at 23:47, Cyril Ferlicot D.  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.ferli...@gmail.com"
> 
> [1] 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
> 

Re: [Pharo-dev] FileSystem fix integration

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

Re: [Pharo-dev] FileSystem fix integration

[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 
> 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-tt4952918.html

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