Re: [Pharo-dev] loading from github changes lgit classes?

[Andrei Chis]

I think this was added because on windows if we did not rebuild accessors,
some offsets were nil in external structures. Can that still be an issue?

Cheers,
Andrei

On Tue, Dec 12, 2017 at 7:39 AM, Esteban Lorenzano 
wrote:

>
>
> On 12 Dec 2017, at 04:29, Martin Dias  wrote:
>
> Should the rebuild changes be logged?
> Maybe we can have EpMonitor suspendDuring: […]
>
>
> no they not.
> what should be suspended is field regeneration on bloc config ;)
>
> Esteban
>
>
> Martín
>
> On Mon, Dec 11, 2017 at 6:42 PM, Nicolai Hess 
> wrote:
>
>> :) This looks interesting:
>>
>> So, postload of bloc and some classes (MozEnum, SpartaCairoEnum) doing a
>> rebuild with this author.
>>
>> 2017-12-11 22:27 GMT+01:00 Esteban Lorenzano :
>>
>>> honestly, this should not be happening.
>>> Now, I have no idea why it is happening at all ;)
>>>
>>> I mean, there is no automatic process that would have a UFFI name there
>>> (the only place where this can happen is on #rebuildFieldAccessors and that
>>> will use an UFFIGenerator author, not just UFFI.
>>> And also that method needs to be executed by hand…
>>>
>>> weird… can you search for UFFI in system?
>>>
>>> Esteban
>>>
>>> On 11 Dec 2017, at 22:00, Nicolai Hess  wrote:
>>>
>>> It happens not only from lgit-classes but from other FFI-Subclasses too,
>>> for example AthensCairoMatrix.
>>>
>>> And some methods have a strange version history (see screenshot).
>>> The timestamp of all of the UFFI changes are during loading gtoolkit.
>>> Maybe during loading we have multiple reinitializations that will
>>> recreate autogenerated methods, again and again ?
>>>
>>> 2017-12-11 21:49 GMT+01:00 Nicolai Hess :
>>>
 But these aren't method changes.
 The class definition is changed. (see screenshot)
 It looks like it adds new class variables, even though they were
 alreday in the original fresh image.


 2017-12-11 13:49 GMT+01:00 Max Leske :

> Without taking a closer look, those are probably auto generated
> methods.
>
> Max
>
>
>
> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaih...@gmail.com)
> wrote:
>
> How come, loading a github project writes strange code change entries
> for classes
> like
> LGitFetchOptions
> LGitRemoteCallbacks
> ...
>
> For example, in a Pharo 6.1 image I load bloc like this:
>
> Metacello new
> baseline: 'Bloc';
> repository: 'github://pharo-graphics/Bloc:pharo6.1/src';
> load: #core
>
> In my Epicea code change window I see this entries (see screenshot).
> And the final "new" version of this classes, (class definitions) just
> look like the
> original class definition in a fresh image.
>
>
>

>>> 
>>>
>>>
>>>
>>
>
>

Re: [Pharo-dev] loading from github changes lgit classes?

[Esteban Lorenzano]

> On 12 Dec 2017, at 04:29, Martin Dias  wrote:
> 
> Should the rebuild changes be logged?
> Maybe we can have EpMonitor suspendDuring: […]

no they not. 
what should be suspended is field regeneration on bloc config ;)

Esteban

> 
> Martín
> 
> On Mon, Dec 11, 2017 at 6:42 PM, Nicolai Hess  > wrote:
> :) This looks interesting:
> 
> So, postload of bloc and some classes (MozEnum, SpartaCairoEnum) doing a 
> rebuild with this author.
> 
> 2017-12-11 22:27 GMT+01:00 Esteban Lorenzano  >:
> honestly, this should not be happening. 
> Now, I have no idea why it is happening at all ;)
> 
> I mean, there is no automatic process that would have a UFFI name there (the 
> only place where this can happen is on #rebuildFieldAccessors and that will 
> use an UFFIGenerator author, not just UFFI. 
> And also that method needs to be executed by hand… 
> 
> weird… can you search for UFFI in system?
> 
> Esteban
> 
>> On 11 Dec 2017, at 22:00, Nicolai Hess > > wrote:
>> 
>> It happens not only from lgit-classes but from other FFI-Subclasses too, for 
>> example AthensCairoMatrix.
>> 
>> And some methods have a strange version history (see screenshot).
>> The timestamp of all of the UFFI changes are during loading gtoolkit.
>> Maybe during loading we have multiple reinitializations that will recreate 
>> autogenerated methods, again and again ?
>> 
>> 2017-12-11 21:49 GMT+01:00 Nicolai Hess > >:
>> But these aren't method changes.
>> The class definition is changed. (see screenshot)
>> It looks like it adds new class variables, even though they were alreday in 
>> the original fresh image.
>> 
>> 
>> 2017-12-11 13:49 GMT+01:00 Max Leske > >:
>> Without taking a closer look, those are probably auto generated methods.
>> 
>> Max
>> 
>>  
>> 
>> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaih...@gmail.com 
>> ) wrote:
>> 
>>> How come, loading a github project writes strange code change entries for 
>>> classes
>>> like
>>> LGitFetchOptions
>>> LGitRemoteCallbacks
>>> ...
>>> 
>>> For example, in a Pharo 6.1 image I load bloc like this:
>>> 
>>> Metacello new
>>> baseline: 'Bloc';
>>> repository: 'github://pharo-graphics/Bloc: <>pharo6.1/src';
>>> load: #core
>>> 
>>> In my Epicea code change window I see this entries (see screenshot).
>>> And the final "new" version of this classes, (class definitions) just look 
>>> like the
>>> original class definition in a fresh image.
>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 

Re: [Pharo-dev] loading from github changes lgit classes?

[Esteban Lorenzano]

this is a problem on Bloc configuration: unlike NativeBoost, UFFI fields 
accessors do NOT need to be regenerated each time, so that chunk of code is 
incorrect.

Esteban

> On 11 Dec 2017, at 22:42, Nicolai Hess  wrote:
> 
> :) This looks interesting:
> 
> So, postload of bloc and some classes (MozEnum, SpartaCairoEnum) doing a 
> rebuild with this author.
> 
> 2017-12-11 22:27 GMT+01:00 Esteban Lorenzano  >:
> honestly, this should not be happening. 
> Now, I have no idea why it is happening at all ;)
> 
> I mean, there is no automatic process that would have a UFFI name there (the 
> only place where this can happen is on #rebuildFieldAccessors and that will 
> use an UFFIGenerator author, not just UFFI. 
> And also that method needs to be executed by hand… 
> 
> weird… can you search for UFFI in system?
> 
> Esteban
> 
>> On 11 Dec 2017, at 22:00, Nicolai Hess > > wrote:
>> 
>> It happens not only from lgit-classes but from other FFI-Subclasses too, for 
>> example AthensCairoMatrix.
>> 
>> And some methods have a strange version history (see screenshot).
>> The timestamp of all of the UFFI changes are during loading gtoolkit.
>> Maybe during loading we have multiple reinitializations that will recreate 
>> autogenerated methods, again and again ?
>> 
>> 2017-12-11 21:49 GMT+01:00 Nicolai Hess > >:
>> But these aren't method changes.
>> The class definition is changed. (see screenshot)
>> It looks like it adds new class variables, even though they were alreday in 
>> the original fresh image.
>> 
>> 
>> 2017-12-11 13:49 GMT+01:00 Max Leske > >:
>> Without taking a closer look, those are probably auto generated methods.
>> 
>> Max
>> 
>>  
>> 
>> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaih...@gmail.com 
>> ) wrote:
>> 
>>> How come, loading a github project writes strange code change entries for 
>>> classes
>>> like
>>> LGitFetchOptions
>>> LGitRemoteCallbacks
>>> ...
>>> 
>>> For example, in a Pharo 6.1 image I load bloc like this:
>>> 
>>> Metacello new
>>> baseline: 'Bloc';
>>> repository: 'github://pharo-graphics/Bloc: <>pharo6.1/src';
>>> load: #core
>>> 
>>> In my Epicea code change window I see this entries (see screenshot).
>>> And the final "new" version of this classes, (class definitions) just look 
>>> like the
>>> original class definition in a fresh image.
>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 

Re: [Pharo-dev] Weird ZnClient benchmarking result

[Stephane Ducasse]

sven did you submit a fix to get a clearer printout?

Stef


On Sun, Dec 10, 2017 at 7:14 PM, Sven Van Caekenberghe  wrote:
> @ Henrik
>
> Arg, arg, arg, yes of course.
> I actually did think about that, but still did not look carefully enough !!
> Really stupid of me.
>
> It is even worse because I wrote that code ...
>
> Now, the #printOn: of BenchmarkResult is much clearer, less confusing:
>
> ZnClient new in: [ :client |
> [ client get: 'http://localhost:8080' ] benchFor: 5 seconds ].
>
> a BenchmarkResult(14,732 iterations in 5 seconds. 2,946 per second)
>
> vs
>
> ZnClient new in: [ :client |
> client loggingOff.
> [ client get: 'http://localhost:8080' ] benchFor: 5 seconds ].
>
> a BenchmarkResult(42 iterations in 5 seconds 88 milliseconds. 8.255 per 
> second)
>
> Still the same issue with $, and $. in frequency, but the iteration count is 
> crystal clear.
>
> The reason #bench works like that is backwards compatibility at the time we 
> introduced that.
>
> @ Ben
>
> Yes, I should have looked at the other side as well, to confirm things 
> actually happened as I imagined them (the did not).
>
> Thx and sorry for the noise.
>
> Sven
>
>> On 10 Dec 2017, at 18:00, Henrik-Nergaard  wrote:
>>
>> Hi Sven,
>>
>> What you are seeing is most likely a $, vs $. issue.
>> See BenchmarkResult >>#printFrequenceOn: it uses both decimal and thousand
>> separators.
>>
>> If i run this code:
>> -
>> | counter |
>> counter :=
>> ZnClient new in: [ :client |
>>  client loggingOff.
>>  [ client get: 'http://localhost:8080'. counter ] bench
>> ].
>> counter.
>> -
>>
>> Then i get 9035 ('1,773 per second') when no inspector is open, and only 22
>> ('5.995 per second') when inspecting the logs.
>>
>> Best regards,
>> Henrik
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>
>
>

Re: [Pharo-dev] loading from github changes lgit classes?

[Martin Dias]

Should the rebuild changes be logged?
Maybe we can have EpMonitor suspendDuring: [...]

Martín

On Mon, Dec 11, 2017 at 6:42 PM, Nicolai Hess  wrote:

> :) This looks interesting:
>
> So, postload of bloc and some classes (MozEnum, SpartaCairoEnum) doing a
> rebuild with this author.
>
> 2017-12-11 22:27 GMT+01:00 Esteban Lorenzano :
>
>> honestly, this should not be happening.
>> Now, I have no idea why it is happening at all ;)
>>
>> I mean, there is no automatic process that would have a UFFI name there
>> (the only place where this can happen is on #rebuildFieldAccessors and that
>> will use an UFFIGenerator author, not just UFFI.
>> And also that method needs to be executed by hand…
>>
>> weird… can you search for UFFI in system?
>>
>> Esteban
>>
>> On 11 Dec 2017, at 22:00, Nicolai Hess  wrote:
>>
>> It happens not only from lgit-classes but from other FFI-Subclasses too,
>> for example AthensCairoMatrix.
>>
>> And some methods have a strange version history (see screenshot).
>> The timestamp of all of the UFFI changes are during loading gtoolkit.
>> Maybe during loading we have multiple reinitializations that will
>> recreate autogenerated methods, again and again ?
>>
>> 2017-12-11 21:49 GMT+01:00 Nicolai Hess :
>>
>>> But these aren't method changes.
>>> The class definition is changed. (see screenshot)
>>> It looks like it adds new class variables, even though they were alreday
>>> in the original fresh image.
>>>
>>>
>>> 2017-12-11 13:49 GMT+01:00 Max Leske :
>>>
 Without taking a closer look, those are probably auto generated methods.

 Max



 On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaih...@gmail.com)
 wrote:

 How come, loading a github project writes strange code change entries
 for classes
 like
 LGitFetchOptions
 LGitRemoteCallbacks
 ...

 For example, in a Pharo 6.1 image I load bloc like this:

 Metacello new
 baseline: 'Bloc';
 repository: 'github://pharo-graphics/Bloc:pharo6.1/src';
 load: #core

 In my Epicea code change window I see this entries (see screenshot).
 And the final "new" version of this classes, (class definitions) just
 look like the
 original class definition in a fresh image.



>>>
>> 
>>
>>
>>
>

Re: [Pharo-dev] Do we have this iterator?

[Sean P. DeNigris]

Stephane Ducasse-3 wrote
> #(1 2 3 4 1 2 3 5 6 ) consumeUntil: [:each | each = 4)
 {#(1 2 3 4) . #( 1 2 3 5 6 )}

The shortest kernel thing I could come up with took two steps: `{ #(1 2 3 4
1 2 3 5 6 ) copyUpThrough: 4.
#(1 2 3 4 1 2 3 5 6 ) copyAfter: 4 }`. The splitting messages seem to all
eat the separator.



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] gtInspector+FastTable enhancement requests

[Stephane Ducasse]

Esteban

At Brest, I will meet the guy that did the google summer of code. He
was sick the last two months but he wants to release his enhancements.
So this is good.

Stef

On Mon, Dec 11, 2017 at 10:29 AM, Esteban Lorenzano  wrote:
> I thin there were some FT improvements we should integrate ?
>
> Esteban
>
> On 10 Dec 2017, at 09:51, Ben Coman  wrote:
>
> Feedback for GT'ers...
>
> I'm probably ab-using FastTable support in gtInspector,
> but as a quick hack during initial prototyping it was *very* nice
> to be able review retrieved data as a table of instances
> with a column per instance variable.
>
> Some enhancements that would make this even better...
> 1. Horizontal scroll bar - There are columns past the right margin that I
> can't get to for lack of one.
> 2. Column resizing to shift subsequent columns, which could provide another
> path to seeing the hidden columns.
> 3. Individual column width auto-fit - like in Excel where you double-click
> the edge
> https://www.youtube.com/watch?v=Yeb8emsjtf4
> 4. All columns auto-fit
> 5. Auto-fit columns prior to first opening.
> 6. Being able to split column labels over two lines - to allow for thinner
> columns
>
> For a demonstration,
> could you please load the attached ST fileout (its small),
> and also...
>   Gofer it
>   smalltalkhubUser: 'SvenVanCaekenberghe' project: 'Neo';
>   configurationOf: 'NeoJSON';
>   loadStable.
>
> Then inspect
>  BittrexMarket getAll.
>
> cheers -ben
> 
>
>

[Pharo-dev] Do we have this iterator?

[Stephane Ducasse]

Hi

Did a lot of manual parsing today and I wonder if consumeUntil: would
not have helped me.

#(1 2 3 4 1 2 3 5 6 ) consumeUntil: [:each | each = 4)
>>> {#(1 2 3 4) . #( 1 2 3 5 6 )}

Stef

Re: [Pharo-dev] loading from github changes lgit classes?

[Nicolai Hess]

:) This looks interesting:

So, postload of bloc and some classes (MozEnum, SpartaCairoEnum) doing a
rebuild with this author.

2017-12-11 22:27 GMT+01:00 Esteban Lorenzano :

> honestly, this should not be happening.
> Now, I have no idea why it is happening at all ;)
>
> I mean, there is no automatic process that would have a UFFI name there
> (the only place where this can happen is on #rebuildFieldAccessors and that
> will use an UFFIGenerator author, not just UFFI.
> And also that method needs to be executed by hand…
>
> weird… can you search for UFFI in system?
>
> Esteban
>
> On 11 Dec 2017, at 22:00, Nicolai Hess  wrote:
>
> It happens not only from lgit-classes but from other FFI-Subclasses too,
> for example AthensCairoMatrix.
>
> And some methods have a strange version history (see screenshot).
> The timestamp of all of the UFFI changes are during loading gtoolkit.
> Maybe during loading we have multiple reinitializations that will recreate
> autogenerated methods, again and again ?
>
> 2017-12-11 21:49 GMT+01:00 Nicolai Hess :
>
>> But these aren't method changes.
>> The class definition is changed. (see screenshot)
>> It looks like it adds new class variables, even though they were alreday
>> in the original fresh image.
>>
>>
>> 2017-12-11 13:49 GMT+01:00 Max Leske :
>>
>>> Without taking a closer look, those are probably auto generated methods.
>>>
>>> Max
>>>
>>>
>>>
>>> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaih...@gmail.com)
>>> wrote:
>>>
>>> How come, loading a github project writes strange code change entries
>>> for classes
>>> like
>>> LGitFetchOptions
>>> LGitRemoteCallbacks
>>> ...
>>>
>>> For example, in a Pharo 6.1 image I load bloc like this:
>>>
>>> Metacello new
>>> baseline: 'Bloc';
>>> repository: 'github://pharo-graphics/Bloc:pharo6.1/src';
>>> load: #core
>>>
>>> In my Epicea code change window I see this entries (see screenshot).
>>> And the final "new" version of this classes, (class definitions) just
>>> look like the
>>> original class definition in a fresh image.
>>>
>>>
>>>
>>
> 
>
>
>

Re: [Pharo-dev] loading from github changes lgit classes?

[Esteban Lorenzano]

honestly, this should not be happening. 
Now, I have no idea why it is happening at all ;)

I mean, there is no automatic process that would have a UFFI name there (the 
only place where this can happen is on #rebuildFieldAccessors and that will use 
an UFFIGenerator author, not just UFFI. 
And also that method needs to be executed by hand… 

weird… can you search for UFFI in system?

Esteban

> On 11 Dec 2017, at 22:00, Nicolai Hess  wrote:
> 
> It happens not only from lgit-classes but from other FFI-Subclasses too, for 
> example AthensCairoMatrix.
> 
> And some methods have a strange version history (see screenshot).
> The timestamp of all of the UFFI changes are during loading gtoolkit.
> Maybe during loading we have multiple reinitializations that will recreate 
> autogenerated methods, again and again ?
> 
> 2017-12-11 21:49 GMT+01:00 Nicolai Hess  >:
> But these aren't method changes.
> The class definition is changed. (see screenshot)
> It looks like it adds new class variables, even though they were alreday in 
> the original fresh image.
> 
> 
> 2017-12-11 13:49 GMT+01:00 Max Leske  >:
> Without taking a closer look, those are probably auto generated methods.
> 
> Max
> 
>  
> 
> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaih...@gmail.com 
> ) wrote:
> 
>> How come, loading a github project writes strange code change entries for 
>> classes
>> like
>> LGitFetchOptions
>> LGitRemoteCallbacks
>> ...
>> 
>> For example, in a Pharo 6.1 image I load bloc like this:
>> 
>> Metacello new
>> baseline: 'Bloc';
>> repository: 'github://pharo-graphics/Bloc:pharo6.1/src';
>> load: #core
>> 
>> In my Epicea code change window I see this entries (see screenshot).
>> And the final "new" version of this classes, (class definitions) just look 
>> like the
>> original class definition in a fresh image.
>> 
>> 
> 
> 
> 

Re: [Pharo-dev] loading from github changes lgit classes?

[Nicolai Hess]

It happens not only from lgit-classes but from other FFI-Subclasses too,
for example AthensCairoMatrix.

And some methods have a strange version history (see screenshot).
The timestamp of all of the UFFI changes are during loading gtoolkit.
Maybe during loading we have multiple reinitializations that will recreate
autogenerated methods, again and again ?

2017-12-11 21:49 GMT+01:00 Nicolai Hess :

> But these aren't method changes.
> The class definition is changed. (see screenshot)
> It looks like it adds new class variables, even though they were alreday
> in the original fresh image.
>
>
> 2017-12-11 13:49 GMT+01:00 Max Leske :
>
>> Without taking a closer look, those are probably auto generated methods.
>>
>> Max
>>
>>
>>
>> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaih...@gmail.com)
>> wrote:
>>
>> How come, loading a github project writes strange code change entries for
>> classes
>> like
>> LGitFetchOptions
>> LGitRemoteCallbacks
>> ...
>>
>> For example, in a Pharo 6.1 image I load bloc like this:
>>
>> Metacello new
>> baseline: 'Bloc';
>> repository: 'github://pharo-graphics/Bloc:pharo6.1/src';
>> load: #core
>>
>> In my Epicea code change window I see this entries (see screenshot).
>> And the final "new" version of this classes, (class definitions) just
>> look like the
>> original class definition in a fresh image.
>>
>>
>>
>

Re: [Pharo-dev] [Pharo-users] [TechTalk] Topics Wanted for 2018!

[Alexandre Bergel]

Yes!

Cheers,
Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



> On Dec 7, 2017, at 10:53 AM, Marcus Denker  wrote:
> 
> What about Tuesday 30th Jan?
> 
>> On 7 Dec 2017, at 02:06, Alexandre Bergel  wrote:
>> 
>> Hi Marcus!
>> 
>> Thanks for pushing the community!
>> If there is a free slot at the end of January, I can do another tech talk on 
>> AI technique. I am thinking about a lecture on Genetic Algorithm and Genetic 
>> Programming.
>> 
>> Let me know...
>> 
>> Alexandre
>> 
>> 
>>> On Dec 1, 2017, at 7:58 AM, Marcus Denker  wrote:
>>> 
>>> Hi,
>>> 
>>> As you know, we are trying to have one Pharo tech-talk per month. 
>>> 
>>> The idea is to use this for
>>> -> mini “Lectures”
>>> -> Demos of interesting Projects
>>> -> Just some interesting topic to discuss with audio chat on Discord
>>> 
>>> You can see the past topics here:
>>> 
>>> http://pharo.org/TechTalk
>>> 
>>> We will soon define the dates for the first half of 2018. If you want to do 
>>> a techtalk
>>> yourself (give a presentation / Demo or moderate a discussion), feel free 
>>> to contact
>>> me! You are able to pick a date that works best for you.
>>> 
>>> 
>>> Marcus
>> 
>> 
> 
> 

Re: [Pharo-dev] [Pharo 7.0-dev] Build #332: 20759 Unused temps in Metacello classes

[Dale Henrichs]

Sorry for the delay ... I am looking at merging this issue into 
Metacello ... a couple failed tests need to be rerun to see where we 
stand ...



On 11/27/17 12:54 PM, Torsten Bergmann wrote:

Yes - I submitted a PR to Metacello too:  
https://github.com/Metacello/metacello/pull/473

Who is able to merge it there?



Gesendet: Montag, 27. November 2017 um 09:16 Uhr
Von: "Marcus Denker" 
An: "Pharo Development List" 
Betreff: Re: [Pharo-dev] [Pharo 7.0-dev] Build #332: 20759 Unused temps in 
Metacello classes

This fix has been submitted upstream, too.


On 27 Nov 2017, at 09:09, ci-pharo-ci-jenki...@inria.fr wrote:

There is a new Pharo build available!

The status of the build #332 was: SUCCESS.

The Pull Request #546 was integrated: "20759 Unused temps in Metacello classes"
Pull request url: https://github.com/pharo-project/pharo/pull/546

Issue Url: https://pharo.fogbugz.com/f/cases/20759
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/332/

[Pharo-dev] [Pharo 7.0-dev] Build #375: 20857-Confirm-dialog-return-nil-when-closed-by-cmd-w

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #375 was: SUCCESS.

The Pull Request #596 was integrated: 
"20857-Confirm-dialog-return-nil-when-closed-by-cmd-w"
Pull request url: https://github.com/pharo-project/pharo/pull/596

Issue Url: https://pharo.fogbugz.com/f/cases/20857
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/375/

[Pharo-dev] [Pharo 7.0-dev] Build #374: 20857-Confirm-dialog-return-nil-when-closed-by-cmd-w

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #374 was: FAILURE.

The Pull Request #596 was integrated: 
"20857-Confirm-dialog-return-nil-when-closed-by-cmd-w"
Pull request url: https://github.com/pharo-project/pharo/pull/596

Issue Url: https://pharo.fogbugz.com/f/cases/20857
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/374/

Re: [Pharo-dev] loading from github changes lgit classes?

[Max Leske]

Without taking a closer look, those are probably auto generated methods.

Max



On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaih...@gmail.com) wrote:

How come, loading a github project writes strange code change entries for
classes
like
LGitFetchOptions
LGitRemoteCallbacks
...

For example, in a Pharo 6.1 image I load bloc like this:

Metacello new
baseline: 'Bloc';
repository: 'github://pharo-graphics/Bloc:pharo6.1/src';
load: #core

In my Epicea code change window I see this entries (see screenshot).
And the final "new" version of this classes, (class definitions) just look
like the
original class definition in a fresh image.

Re: [Pharo-dev] create snapshots out of github based packages

[Dimitris Chloupis]

nice to hear that my very old complaint about filetrees habit of breaking
down everything to small files has caught and there is even a project I am
not aware of that deal with this. Though my motivation was mostly
readability and not speed of loading. Great work! :)

On Mon, Dec 11, 2017 at 11:35 AM Esteban Lorenzano 
wrote:

>
>
> > On 10 Dec 2017, at 21:37, Stephan Eggermont  wrote:
> >
> > Op 10-12-2017 om 15:44 schreef Cyril Ferlicot:
> >> On dim. 10 déc. 2017 at 15:07, Nicolai Hess  wrote:
> >>>And I don't mean 1 or 2 thousand files.
> >>>Loading bloc for example creates over 20.000 files.
> >>>This is damn slow on windows.
> >> This is one of the reasons Esteban created Tonel I think. With Tonel
> there is 1 file par class instead of 1 file per method. Once it will be
> really stable, moving projects to Tonel should speed up things on Windows.
> >
> > Indeed. An even larger problem is the write amplification: Minimium disk
> file size of 4KB means a slow down of a factor 20. 1 (primary) file per
> class and sorting the methods helps a lot. Doing that in a cross-platform
> compatible way so we can easier share source code needs some further
> refinement
>
> and btw since we moved pharo to tonel windows is a viable platform:
> commits became seconds instead minutes (lots of minutes).
> still work to do there, but we are getting closer… ;)
>
> Esteban
>
> >
> > Stephan
> >
> >
>
>
>

Re: [Pharo-dev] create snapshots out of github based packages

[Esteban Lorenzano]

> On 10 Dec 2017, at 21:37, Stephan Eggermont  wrote:
> 
> Op 10-12-2017 om 15:44 schreef Cyril Ferlicot:
>> On dim. 10 déc. 2017 at 15:07, Nicolai Hess >>And I don't mean 1 or 2 thousand files.
>>>Loading bloc for example creates over 20.000 files.
>>>This is damn slow on windows.
>> This is one of the reasons Esteban created Tonel I think. With Tonel there 
>> is 1 file par class instead of 1 file per method. Once it will be really 
>> stable, moving projects to Tonel should speed up things on Windows.
> 
> Indeed. An even larger problem is the write amplification: Minimium disk file 
> size of 4KB means a slow down of a factor 20. 1 (primary) file per class and 
> sorting the methods helps a lot. Doing that in a cross-platform compatible 
> way so we can easier share source code needs some further refinement

and btw since we moved pharo to tonel windows is a viable platform: commits 
became seconds instead minutes (lots of minutes).
still work to do there, but we are getting closer… ;)

Esteban

> 
> Stephan
> 
> 

Re: [Pharo-dev] gtInspector+FastTable enhancement requests

[Esteban Lorenzano]

I thin there were some FT improvements we should integrate ?

Esteban

> On 10 Dec 2017, at 09:51, Ben Coman  wrote:
> 
> Feedback for GT'ers...
> 
> I'm probably ab-using FastTable support in gtInspector,
> but as a quick hack during initial prototyping it was *very* nice
> to be able review retrieved data as a table of instances 
> with a column per instance variable. 
> 
> Some enhancements that would make this even better...
> 1. Horizontal scroll bar - There are columns past the right margin that I 
> can't get to for lack of one.
> 2. Column resizing to shift subsequent columns, which could provide another 
> path to seeing the hidden columns.
> 3. Individual column width auto-fit - like in Excel where you double-click 
> the edge 
> https://www.youtube.com/watch?v=Yeb8emsjtf4 
> 
> 4. All columns auto-fit
> 5. Auto-fit columns prior to first opening.
> 6. Being able to split column labels over two lines - to allow for thinner 
> columns
> 
> For a demonstration, 
> could you please load the attached ST fileout (its small), 
> and also... 
>   Gofer it
>   smalltalkhubUser: 'SvenVanCaekenberghe' project: 'Neo';
>   configurationOf: 'NeoJSON';
>   loadStable.
> 
> Then inspect
>  BittrexMarket getAll.
> 
> cheers -ben
> 

Re: [Pharo-dev] Text Indentation in Pharo editor

[Esteban Lorenzano]

> On 8 Dec 2017, at 15:40, Stephane Ducasse  wrote:
> 
> I would love to have Ctrl E and Ctrl A.
> And yes we should not be different for the sake of it.
> For the moment the reason is simple: we are full of work and even more.
> 
> FYI: I'm starting at regular crash of the VM and regular superbad
> behavior of the debugger (like hundred of debuggers, like spawing many
> process)
> there is a really bad problem there.
> 
> Setf
> 
> On Fri, Dec 8, 2017 at 10:52 AM, Ben Coman  wrote:
>> 
>> 
>> On 8 December 2017 at 11:37, Sean P. DeNigris  wrote:
>>> 
>>> Torsten Bergmann wrote
 so we do it with different shortcuts than regular editors
>>> 
>>> I wonder if it makes sense to allow the standard shortcut. The current one
>>> is a bit like playing twister ;)
>> 
>> 
>> We should be different if there is a good reason,
>> but where possible (especially on UI interface) we should align with the
>> majority.

+1000
this is my work motto, and what I’m trying to do with my work on Pharo every 
day :)
and of course, lot of work is still needed.

>> I feel this case is the latter.

agreed.

Esteban

>> 
>> cheers -ben
>> 
>> 
>