- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] iceberg / libgit behind proxy

by Stephane Ducasse

I did not try behind a proxy. On Thu, Jul 27, 2017 at 10:28 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > Anyone got it working to use iceberg /libgit behind a proxy? > > I can access monticello repositories with the right proxy settings. > But using iceberg shows an error about > can not access github.org > >

July 28, 2017

Re: [Pharo-dev] WorkingSession log

by Stephane Ducasse

Remove does not mean that we cannot reload. The font logic is a bit messy. So one of these days we will have to do a pass there. On Fri, Jul 28, 2017 at 7:39 AM, Ben Coman <btc(a)openinworld.com> wrote: > I vaguely remember StrikeFonts being considered for removal once(??) > but this seems a good reason to not do that, and eliminate the FreeType > stuff for server-side deployment. > > cheers -ben > > On Fri, Jul 28, 2017 at 3:14 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> This is really interesting. >> I would be interested to see why ClassSessionHandler(FreeTypeSettings) >> takes 2/3 of the computation. >> Without it we would be 100 ms. >> >> Stef >> >> On Thu, Jul 27, 2017 at 2:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> > Hi, >> > >> > I instrumented WorkingSession with a log collection that holds timing >> > info for each #startUp: executed. In a clean Pharo 6 image, 62 were run. >> > Most of them resulted in a 0ms execution time (#millisecondsToRun: i.e. they >> > were faster than 1ms). Here is the list of the non zero ones: >> > >> > 1ms startup:true a ClassSessionHandler(ProcessorScheduler) >> > 1ms startup:true a ClassSessionHandler(OSPlatform) >> > 6ms startup:true a ClassSessionHandler(ExternalObject) >> > 1ms startup:true a ClassSessionHandler(DiskStore) >> > 5ms startup:true a ClassSessionHandler(SmalltalkImage) >> > 9ms startup:true a ClassSessionHandler(DisplayScreen) >> > 1ms startup:true a ClassSessionHandler(Cursor) >> > 41ms startup:true a ClassSessionHandler(FT2Handle) >> > 238ms startup:true a ClassSessionHandler(FreeTypeSettings) >> > 1ms startup:true a ClassSessionHandler(WorldMorph) >> > 14ms startup:true a ClassSessionHandler(OmSessionStore) >> > >> > For a total of 318ms >> > >> > I think being able to inspect the WorkingSession and see this list >> > (ordered, with timing info) would be generally useful (and low cost). Even >> > headless, we could access the list using eval. >> > >> > Sven >> > >> > PS: The code of SessionManager/WorkingSession was very readable, well >> > done Christophe ! >> > >> > >> > >> > >> >

July 28, 2017

Re: [Pharo-dev] WorkingSession log

by Ben Coman

I vaguely remember StrikeFonts being considered for removal once(??) but this seems a good reason to not do that, and eliminate the FreeType stuff for server-side deployment. cheers -ben On Fri, Jul 28, 2017 at 3:14 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > This is really interesting. > I would be interested to see why ClassSessionHandler(FreeTypeSettings) > takes 2/3 of the computation. > Without it we would be 100 ms. > > Stef > > On Thu, Jul 27, 2017 at 2:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > Hi, > > > > I instrumented WorkingSession with a log collection that holds timing > info for each #startUp: executed. In a clean Pharo 6 image, 62 were run. > Most of them resulted in a 0ms execution time (#millisecondsToRun: i.e. > they were faster than 1ms). Here is the list of the non zero ones: > > > > 1ms startup:true a ClassSessionHandler(ProcessorScheduler) > > 1ms startup:true a ClassSessionHandler(OSPlatform) > > 6ms startup:true a ClassSessionHandler(ExternalObject) > > 1ms startup:true a ClassSessionHandler(DiskStore) > > 5ms startup:true a ClassSessionHandler(SmalltalkImage) > > 9ms startup:true a ClassSessionHandler(DisplayScreen) > > 1ms startup:true a ClassSessionHandler(Cursor) > > 41ms startup:true a ClassSessionHandler(FT2Handle) > > 238ms startup:true a ClassSessionHandler(FreeTypeSettings) > > 1ms startup:true a ClassSessionHandler(WorldMorph) > > 14ms startup:true a ClassSessionHandler(OmSessionStore) > > > > For a total of 318ms > > > > I think being able to inspect the WorkingSession and see this list > (ordered, with timing info) would be generally useful (and low cost). Even > headless, we could access the list using eval. > > > > Sven > > > > PS: The code of SessionManager/WorkingSession was very readable, well > done Christophe ! > > > > > > > > > >

July 28, 2017

iceberg / libgit behind proxy

by Nicolai Hess

Anyone got it working to use iceberg /libgit behind a proxy? I can access monticello repositories with the right proxy settings. But using iceberg shows an error about can not access github.org

July 27, 2017

Re: [Pharo-dev] Improving formatting [was: Big claps for Epicea (small request!)]

by Stephane Ducasse

> Hi Denis, > you're right, for literal numbers it's been solved in Pharo at least since > 3.0, or maybe even 2.0 (by usage of RB AST I guess). > That's a major improvment over Squeak which is is certainly where I last > encountered the problem. > > Still, formatting does mess line breaking/indenting/commenting in literal > arrays. Yes I would love to have a better heuristics. Now we refactored the prettyprinter so it should be easier to play and enhance it.

July 27, 2017

Re: [Pharo-dev] WorkingSession log

by phil＠highoctane.be

In my case it once took eons because I had lots of fonts on a machine. It depends if you have the font check enabled or not I guess. But yeah, loading truetype fonts and all glyphs etc take a while I assume. Having this "boot time sequence log" is nice. Clement told me once to do this in a 5.0 WorkingSession>>#runStartup: isImageStarting | c | Smalltalk at: #LOG11 put: OrderedCollection new. c := Smalltalk at: #LOG11. self runList: manager startupList do: [ :each | c add: each -> DateAndTime now. each startup: isImageStarting ]. self executeDeferredStartupActions: isImageStarting then save and start again, and then inspect the LOG11 global. the thing that took time was the FT2 loading. Phil On Thu, Jul 27, 2017 at 9:14 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > This is really interesting. > I would be interested to see why ClassSessionHandler(FreeTypeSettings) > takes 2/3 of the computation. > Without it we would be 100 ms. > > Stef > > On Thu, Jul 27, 2017 at 2:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > > > I instrumented WorkingSession with a log collection that holds timing info for each #startUp: executed. In a clean Pharo 6 image, 62 were run. Most of them resulted in a 0ms execution time (#millisecondsToRun: i.e. they were faster than 1ms). Here is the list of the non zero ones: > > > > 1ms startup:true a ClassSessionHandler(ProcessorScheduler) > > 1ms startup:true a ClassSessionHandler(OSPlatform) > > 6ms startup:true a ClassSessionHandler(ExternalObject) > > 1ms startup:true a ClassSessionHandler(DiskStore) > > 5ms startup:true a ClassSessionHandler(SmalltalkImage) > > 9ms startup:true a ClassSessionHandler(DisplayScreen) > > 1ms startup:true a ClassSessionHandler(Cursor) > > 41ms startup:true a ClassSessionHandler(FT2Handle) > > 238ms startup:true a ClassSessionHandler(FreeTypeSettings) > > 1ms startup:true a ClassSessionHandler(WorldMorph) > > 14ms startup:true a ClassSessionHandler(OmSessionStore) > > > > For a total of 318ms > > > > I think being able to inspect the WorkingSession and see this list (ordered, with timing info) would be generally useful (and low cost). Even headless, we could access the list using eval. > > > > Sven > > > > PS: The code of SessionManager/WorkingSession was very readable, well done Christophe ! > > > > > > > > >

July 27, 2017

Re: [Pharo-dev] WorkingSession log

by Stephane Ducasse

This is really interesting. I would be interested to see why ClassSessionHandler(FreeTypeSettings) takes 2/3 of the computation. Without it we would be 100 ms. Stef On Thu, Jul 27, 2017 at 2:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I instrumented WorkingSession with a log collection that holds timing info for each #startUp: executed. In a clean Pharo 6 image, 62 were run. Most of them resulted in a 0ms execution time (#millisecondsToRun: i.e. they were faster than 1ms). Here is the list of the non zero ones: > > 1ms startup:true a ClassSessionHandler(ProcessorScheduler) > 1ms startup:true a ClassSessionHandler(OSPlatform) > 6ms startup:true a ClassSessionHandler(ExternalObject) > 1ms startup:true a ClassSessionHandler(DiskStore) > 5ms startup:true a ClassSessionHandler(SmalltalkImage) > 9ms startup:true a ClassSessionHandler(DisplayScreen) > 1ms startup:true a ClassSessionHandler(Cursor) > 41ms startup:true a ClassSessionHandler(FT2Handle) > 238ms startup:true a ClassSessionHandler(FreeTypeSettings) > 1ms startup:true a ClassSessionHandler(WorldMorph) > 14ms startup:true a ClassSessionHandler(OmSessionStore) > > For a total of 318ms > > I think being able to inspect the WorkingSession and see this list (ordered, with timing info) would be generally useful (and low cost). Even headless, we could access the list using eval. > > Sven > > PS: The code of SessionManager/WorkingSession was very readable, well done Christophe ! > > > >

July 27, 2017

Re: [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

by Hilaire

Thanks Nicolai Hilaire Le 26/07/2017 Ã 17:07, Nicolai Hess a Ã©crit : > whatever, put a slice for this case into the inbox > SLICE-Issue-20166-wrong-cliprect-on-transformed-athens-canvas-NicolaiHess.1 -- Dr. Geo http://drgeo.eu

July 27, 2017

Re: [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

by Hilaire

Le 26/07/2017 Ã 16:42, Nicolai Hess a Ã©crit : > It is ok if we tell hilaire to not just put bugreports on the ml but > create a bug report on fogbugz instead. So people can fix/provide a > slice and run the validation. And this is what I do > But this happend in this case. It is just that we do not get it right > to handle this case because it depens on athens. Indeed -- Dr. Geo http://drgeo.eu

July 27, 2017

Re: [Pharo-dev] Lots of "UTF8InvalidText: Invalid utf8 input detected" from OMBU

by Mariano Martinez Peck

On Wed, Jul 26, 2017 at 6:36 AM, Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no> wrote: > There's https://pharo.fogbugz.com/f/cases/20112/, your error could be the > same. > (a multibyte character crossing the initial-guess block boundary) > > As outlined there, the (temp) fix is to put an error handler around the > nextEntryPositionIfFound:ifNone: call in refreshNewBlocksFrom: > > Hi Henry, Thanks for the pointer. I patched my images with your workaround. I will use it for a couple of days and I will later tell if you it seems to fix it or not. Cheers, > Cheers, > Henry > > > > -- > View this message in context: http://forum.world.st/Lots-of- > UTF8InvalidText-Invalid-utf8-input-detected-from-OMBU- > tp4956734p4956805.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

July 27, 2017