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

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

by 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 <estebanlm(a)gmail.com> wrote: > > > On 12 Dec 2017, at 04:29, Martin Dias <tinchodias(a)gmail.com> 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 <nicolaihess(a)gmail.com> > 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 <estebanlm(a)gmail.com>: >> >>> 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 <nicolaihess(a)gmail.com> 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 <nicolaihess(a)gmail.com>: >>> >>>> 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 <maxleske(a)gmail.com>: >>>> >>>>> Without taking a closer look, those are probably auto generated >>>>> methods. >>>>> >>>>> Max >>>>> >>>>> >>>>> >>>>> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaihess(a)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. >>>>> >>>>> >>>>> >>>> >>> <PharoScreenshot.1.png> >>> >>> >>> >> > >

Dec. 12, 2017

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

by Esteban Lorenzano

> On 12 Dec 2017, at 04:29, Martin Dias <tinchodias(a)gmail.com> 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 <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> 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 <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > 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 <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> 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 <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>>: >> 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 <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: >> Without taking a closer look, those are probably auto generated methods. >> >> Max >> >> >> >> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaihess(a)gmail.com <mailto:nicolaihess@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. >>> >>> >> >> >> <PharoScreenshot.1.png> > > >

Dec. 12, 2017

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

by 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 <nicolaihess(a)gmail.com> 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 <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > 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 <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> 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 <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>>: >> 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 <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: >> Without taking a closer look, those are probably auto generated methods. >> >> Max >> >> >> >> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaihess(a)gmail.com <mailto:nicolaihess@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. >>> >>> >> >> >> <PharoScreenshot.1.png> > > > <PharoScreenshot.3.png>

Dec. 12, 2017

Re: [Pharo-dev] Weird ZnClient benchmarking result

by 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 <sven(a)stfx.eu> 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 <draagren(a)outlook.com> 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 >> > >

Dec. 12, 2017

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

by 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 <nicolaihess(a)gmail.com> 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 <estebanlm(a)gmail.com>: > >> 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 <nicolaihess(a)gmail.com> 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 <nicolaihess(a)gmail.com>: >> >>> 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 <maxleske(a)gmail.com>: >>> >>>> Without taking a closer look, those are probably auto generated methods. >>>> >>>> Max >>>> >>>> >>>> >>>> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaihess(a)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. >>>> >>>> >>>> >>> >> <PharoScreenshot.1.png> >> >> >> >

Dec. 12, 2017

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

by 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

Dec. 12, 2017

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

by 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 <estebanlm(a)gmail.com> wrote: > I thin there were some FT improvements we should integrate ? > > Esteban > > On 10 Dec 2017, at 09:51, Ben Coman <btc(a)openinworld.com> 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 > <Demo.zip> > >

Dec. 11, 2017

Do we have this iterator?

by 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

Dec. 11, 2017

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

by 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 <estebanlm(a)gmail.com>: > 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 <nicolaihess(a)gmail.com> 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 <nicolaihess(a)gmail.com>: > >> 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 <maxleske(a)gmail.com>: >> >>> Without taking a closer look, those are probably auto generated methods. >>> >>> Max >>> >>> >>> >>> On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaihess(a)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. >>> >>> >>> >> > <PharoScreenshot.1.png> > > >

Dec. 11, 2017

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

by 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 <nicolaihess(a)gmail.com> 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 <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>>: > 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 <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: > Without taking a closer look, those are probably auto generated methods. > > Max > > > > On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaihess(a)gmail.com <mailto:nicolaihess@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. >> >> > > > <PharoScreenshot.1.png>

Dec. 11, 2017