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

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

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

> 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

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

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

Re: [Pharo-dev] Weird ZnClient benchmarking result

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

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

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

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

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

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

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

[Pharo-dev] Do we have this iterator?

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?

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

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

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

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

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

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

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

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

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

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

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:

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

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:

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

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

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

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

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

> 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

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

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 >

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

> 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