September 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] pharo on ipad3 -- tiny image shown only

by phil＠highoctane.be

Well, get the CFG test out of the way of course. The CFG_... is a #define in my other app 2012/9/16 Johan Brichau <johan(a)inceptive.be>: > Thanks for the response, but unfortunately it does not seem to help. > > I'm a bit amazed because the Dr Geo app works perfectly fine. So where is the trick? > > On 16 Sep 2012, at 19:24, phil(a)highoctane.be wrote: > >> In another application, I do have this thing that helps in rescaling >> (the class is a XXXView) >> >> // Enable retina display >> if( CFG_IOS_RETINA_ENABLED ){ >> if( [self respondsToSelector:@selector(contentScaleFactor)] ){ >> float scaleFactor=[[UIScreen mainScreen] scale]; >> [self setContentScaleFactor:scaleFactor]; >> } >> } >> >> This is a quickfix that will look ugly but... worth trying. >> >> Add that into the SqueakUIView.m file inside this: >> >> - (id)initWithFrame:(CGRect) aFrame { >> self = [super initWithFrame: aFrame]; >> self.autoresizingMask = >> UIViewAutoresizingFlexibleRightMargin|UIViewAutoresizingFlexibleBottomMargin|UIViewAutoresizingFlexibleHeight|UIViewAutoresizingFlexibleWidth; >> colorspace = CGColorSpaceCreateDeviceRGB(); >> return self; >> } >> >> I suspect that self.autoresizingMask is the culprit... >> >> Hope it helps. >> >> Phil >> >> 2012/9/16 Igor Stasenko <siguctua(a)gmail.com>: >>> On 16 September 2012 18:14, Johan Brichau <johan(a)inceptive.be> wrote: >>>> Hi everyone, >>>> >>>> After some very friendly help of Nick and Igor at ESUG, I managed to get the iStackVM running on my iPad again, thanks a lot guys! >>>> >>>> However, the image now shows up on only a very small portion of the screen. >>>> Is that a known issue? >>> >>> yes. this is a "retina display" issue. :) >>> I am not sure what is the status, however i can assure you that we >>> (especially Esteban) is well aware of it. >>> >>>> >>>> btw: the problem I experienced to compile the vm correctly was eventually a package-loading problem (i.e. I did not get the correct packages). This is because there is a bug in the version-method generation of Metacello. Together with Dale, we discussed that issue and Dale just solved it last friday. >>>> >>>> Johan >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> > >

Sept. 16, 2012

Re: [Pharo-project] Zinc Progress

by StÃ©phane Ducasse

I think that I integrated some of the changes of camillo yesterday. Stef On Sep 16, 2012, at 9:50 PM, Camillo Bruni wrote: >> I wrote some code to try to have something executable to work with, but I can't find anything. >> >> (The examples use the extended version of HTTPProgress, http://code.google.com/p/pharo/issues/detail?id=6674 ) >> >> I created 1Mb and 10Mb files somewhere public. Full progress is currently only available in Zn when doing stream, as in #downloadTo: >> >> '/tmp/10Mb.bin' asFileReference ensureDeleted. >> >> [ ZnClient new >> systemPolicy; >> beOneShot; >> url: 'http://s3-eu-west-1.amazonaws.com/public-stfx-eu/10Mb.bin'; >> downloadTo: '/tmp/' ] timeToRun. >> >> [ UIManager default informUserDuring: [ :bar | >> bar label: 'Downloading...'. >> [ ZnClient new >> signalProgress: true; >> systemPolicy; >> beOneShot; >> url: 'http://s3-eu-west-1.amazonaws.com/public-stfx-eu/10Mb.bin'; >> downloadTo: '/tmp/' ] >> on: HTTPProgress >> do: [ :progress | >> bar label: progress printString. >> progress isEmpty ifFalse: [ bar current: progress percentage ]. >> self crLog: progress printString. >> progress resume ] ] ] timeToRun. >> >> As fas as I can tell, both run at the same speed (more or less). >> >> Is is possible to show the code where you noticed the slowdown ? > > I assume that the overhead only occurs for small files... > > > ZnClient new > signalProgress: true; > systemPolicy; > beOneShot; > url: 'http://smalltalkhub.com/mc/estebanlm/Voyage/main?format=raw'; > get. > > with progress 2.5secs without, 57ms.. :/ well might be that the server > responds with an incomplete header or so... > > > > >

Sept. 16, 2012

Re: [Pharo-project] Zinc Progress

by Camillo Bruni

>> I assume that the overhead only occurs for small files... >> >> >> ZnClient new >> signalProgress: true; >> systemPolicy; >> beOneShot; >> url: 'http://smalltalkhub.com/mc/estebanlm/Voyage/main?format=raw'; >> get. >> >> with progress 2.5secs without, 57ms.. :/ well might be that the server >> responds with an incomplete header or so... > > another remark with signalProgress the time to run highly varies, 250ms - 2500ms. > whereas without progress notification it stays <140ms the culprit IMO is ZnClient>>#executeWithRetriesRemaining: which does a on: Exception do:[ ... retry ]. so that means on an HTTPProgress you initiate a retry? (and wait for retryDelay), AUCH! :D

Sept. 16, 2012

Re: [Pharo-project] Smalltalkhub news

by Camillo Bruni

On 2012-09-16, at 21:29, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Good work ! > > Where can the code be found/seen ? all in the latest pharo SmalltalkHubRepository browse. > I am especially interested in the last point. Has it something to do with (using) Zn ? yes, we basically did a HEAD request and returned false on 404, however Zn does 3 or so retries, and thus makes everything slow :). I don't know what the side-effects are, but we reduce the retryCount to 0, to get low response times. I thought that upon a valid 404 response there is no retry needed? (but I guess I miss something here :P)

Sept. 16, 2012

Re: [Pharo-project] Zinc Progress

by Camillo Bruni

On 2012-09-16, at 21:50, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> I wrote some code to try to have something executable to work with, but I can't find anything. >> >> (The examples use the extended version of HTTPProgress, http://code.google.com/p/pharo/issues/detail?id=6674 ) >> >> I created 1Mb and 10Mb files somewhere public. Full progress is currently only available in Zn when doing stream, as in #downloadTo: >> >> '/tmp/10Mb.bin' asFileReference ensureDeleted. >> >> [ ZnClient new >> systemPolicy; >> beOneShot; >> url: 'http://s3-eu-west-1.amazonaws.com/public-stfx-eu/10Mb.bin'; >> downloadTo: '/tmp/' ] timeToRun. >> >> [ UIManager default informUserDuring: [ :bar | >> bar label: 'Downloading...'. >> [ ZnClient new >> signalProgress: true; >> systemPolicy; >> beOneShot; >> url: 'http://s3-eu-west-1.amazonaws.com/public-stfx-eu/10Mb.bin'; >> downloadTo: '/tmp/' ] >> on: HTTPProgress >> do: [ :progress | >> bar label: progress printString. >> progress isEmpty ifFalse: [ bar current: progress percentage ]. >> self crLog: progress printString. >> progress resume ] ] ] timeToRun. >> >> As fas as I can tell, both run at the same speed (more or less). >> >> Is is possible to show the code where you noticed the slowdown ? > > I assume that the overhead only occurs for small files... > > > ZnClient new > signalProgress: true; > systemPolicy; > beOneShot; > url: 'http://smalltalkhub.com/mc/estebanlm/Voyage/main?format=raw'; > get. > > with progress 2.5secs without, 57ms.. :/ well might be that the server > responds with an incomplete header or so... another remark with signalProgress the time to run highly varies, 250ms - 2500ms. whereas without progress notification it stays <140ms

Sept. 16, 2012

Re: [Pharo-project] Zinc Progress

by Camillo Bruni

> I wrote some code to try to have something executable to work with, but I can't find anything. > > (The examples use the extended version of HTTPProgress, http://code.google.com/p/pharo/issues/detail?id=6674 ) > > I created 1Mb and 10Mb files somewhere public. Full progress is currently only available in Zn when doing stream, as in #downloadTo: > > '/tmp/10Mb.bin' asFileReference ensureDeleted. > > [ ZnClient new > systemPolicy; > beOneShot; > url: 'http://s3-eu-west-1.amazonaws.com/public-stfx-eu/10Mb.bin'; > downloadTo: '/tmp/' ] timeToRun. > > [ UIManager default informUserDuring: [ :bar | > bar label: 'Downloading...'. > [ ZnClient new > signalProgress: true; > systemPolicy; > beOneShot; > url: 'http://s3-eu-west-1.amazonaws.com/public-stfx-eu/10Mb.bin'; > downloadTo: '/tmp/' ] > on: HTTPProgress > do: [ :progress | > bar label: progress printString. > progress isEmpty ifFalse: [ bar current: progress percentage ]. > self crLog: progress printString. > progress resume ] ] ] timeToRun. > > As fas as I can tell, both run at the same speed (more or less). > > Is is possible to show the code where you noticed the slowdown ? I assume that the overhead only occurs for small files... ZnClient new signalProgress: true; systemPolicy; beOneShot; url: 'http://smalltalkhub.com/mc/estebanlm/Voyage/main?format=raw'; get. with progress 2.5secs without, 57ms.. :/ well might be that the server responds with an incomplete header or so...

Sept. 16, 2012

Re: [Pharo-project] pharo on ipad3 -- tiny image shown only

by Johan Brichau

Thanks for the response, but unfortunately it does not seem to help. I'm a bit amazed because the Dr Geo app works perfectly fine. So where is the trick? On 16 Sep 2012, at 19:24, phil(a)highoctane.be wrote: > In another application, I do have this thing that helps in rescaling > (the class is a XXXView) > > // Enable retina display > if( CFG_IOS_RETINA_ENABLED ){ > if( [self respondsToSelector:@selector(contentScaleFactor)] ){ > float scaleFactor=[[UIScreen mainScreen] scale]; > [self setContentScaleFactor:scaleFactor]; > } > } > > This is a quickfix that will look ugly but... worth trying. > > Add that into the SqueakUIView.m file inside this: > > - (id)initWithFrame:(CGRect) aFrame { > self = [super initWithFrame: aFrame]; > self.autoresizingMask = > UIViewAutoresizingFlexibleRightMargin|UIViewAutoresizingFlexibleBottomMargin|UIViewAutoresizingFlexibleHeight|UIViewAutoresizingFlexibleWidth; > colorspace = CGColorSpaceCreateDeviceRGB(); > return self; > } > > I suspect that self.autoresizingMask is the culprit... > > Hope it helps. > > Phil > > 2012/9/16 Igor Stasenko <siguctua(a)gmail.com>: >> On 16 September 2012 18:14, Johan Brichau <johan(a)inceptive.be> wrote: >>> Hi everyone, >>> >>> After some very friendly help of Nick and Igor at ESUG, I managed to get the iStackVM running on my iPad again, thanks a lot guys! >>> >>> However, the image now shows up on only a very small portion of the screen. >>> Is that a known issue? >> >> yes. this is a "retina display" issue. :) >> I am not sure what is the status, however i can assure you that we >> (especially Esteban) is well aware of it. >> >>> >>> btw: the problem I experienced to compile the vm correctly was eventually a package-loading problem (i.e. I did not get the correct packages). This is because there is a bug in the version-method generation of Metacello. Together with Dale, we discussed that issue and Dale just solved it last friday. >>> >>> Johan >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >

Sept. 16, 2012

Re: [Pharo-project] Smalltalkhub news

by Sven Van Caekenberghe

Good work ! Where can the code be found/seen ? I am especially interested in the last point. Has it something to do with (using) Zn ? -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill On 16 Sep 2012, at 13:18, Camillo Bruni <camillobruni(a)gmail.com> wrote: > Nicolas and I improved on last Friday the interaction with Smalltalkhub > - new repository type for Pharo2.0 > - cached allFileNames on server side > - response time reduction: 500ms => 12ms > - added new raw filenames format: > - see: http://smalltalkhub.com/mc/estebanlm/Voyage/main?format=raw > - cuts the transferred data size in half > - reduces parsing overhead on image-side > - fixed a bug in the HTTPRepository where the download would take took long > - testing if a mcz file exists is now a 10ms action instead of >1s > > with the last three fixes applied we have cropped down the response time > from the server to ~15ms. All in all this will make Smalltalkhub a super-fast > Monticello experience! > > enjoy! > camillo

Sept. 16, 2012

Re: [Pharo-project] Zinc Progress

by Sven Van Caekenberghe

On 15 Sep 2012, at 01:02, Camillo Bruni <camillobruni(a)gmail.com> wrote: > On 2012-09-14, at 23:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> On 14 Sep 2012, at 20:57, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> >>> Is it possible to notify every time interval? Say, every second or so. >>> That way the cost would also not vary with download/upload speed. >> >> Good idea, it will take some tweaking to get this to work well, I guess. >> I remember that some changes like this were done for the unit tests progress as well, I'll try find that code. > > I still think it's not the amount of notifications that causes the pauses > there must be more to it... given that the download took around 1000ms longer > we would have spend more than 30ms per notification! no-way :) > > running the download in the profiler showed the 1s lost is spent in the idle > process ;) IMO that's rather funny :) I wrote some code to try to have something executable to work with, but I can't find anything. (The examples use the extended version of HTTPProgress, http://code.google.com/p/pharo/issues/detail?id=6674 ) I created 1Mb and 10Mb files somewhere public. Full progress is currently only available in Zn when doing stream, as in #downloadTo: '/tmp/10Mb.bin' asFileReference ensureDeleted. [ ZnClient new systemPolicy; beOneShot; url: 'http://s3-eu-west-1.amazonaws.com/public-stfx-eu/10Mb.bin'; downloadTo: '/tmp/' ] timeToRun. [ UIManager default informUserDuring: [ :bar | bar label: 'Downloading...'. [ ZnClient new signalProgress: true; systemPolicy; beOneShot; url: 'http://s3-eu-west-1.amazonaws.com/public-stfx-eu/10Mb.bin'; downloadTo: '/tmp/' ] on: HTTPProgress do: [ :progress | bar label: progress printString. progress isEmpty ifFalse: [ bar current: progress percentage ]. self crLog: progress printString. progress resume ] ] ] timeToRun. As fas as I can tell, both run at the same speed (more or less). Is is possible to show the code where you noticed the slowdown ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Sept. 16, 2012

Re: [Pharo-project] [ANN] iPad Dr. Geo 12.10

by Peter Hugosson-Miller

Hehe, AFAIK, "frustration time" isn't a proper phrase, it's just something I made up to try and describe the time it takes from starting up a new program I've never seen before, until it makes me frustrated. In the best of cases that never happens, and I must say that it's highly personal, and depends largely on my expectations at the time. In this case, I had already decided to buy the app, not knowing if I would have a use for it, just because I like to do things to help the Smalltalk community in any way that I can. In the back of my mind I also hoped it might be something I could use with my kids, to show them a bit about geometry, maths in general, and maybe even Smalltalk. I was not expecting a beautiful, polished finish, nor much in the way of documentation, but I'd hoped that, given a few minutes of time, there would be enough clues to be found by clicking and prodding around, to be able to make it do something cool. Sadly, during the time I had available during that first look, I didn't manage to make anything happen at all, and I felt frustrated. I fear that someone with higher expectations might have become cross at that point, and that's why I wanted to suggest a tutorial button. Now I know that I just need to go and watch those demo videos before I try next time :-) Good luck! -- Cheers, Peter On Sun, Sep 16, 2012 at 5:01 PM, Hilaire Fernandes < hilaire.fernandes(a)edu.ge.ch> wrote: > Peter, > > It will be terribly useful if you describe me where you get your > frustration time. > > Thanks > > Hilaire > > Le 16/09/2012 11:53, Peter Hugosson-Miller a Ã©crit : > > Never having seen the app before, I was unable to find a help or > tutorial button within my personal "frustration time". May I suggest that > first-time users be started up in some kind of "newbie mode"? >

Sept. 16, 2012