- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] [NB] Speaking about callbacks

by Marten Feldtmann

Me too. Marten Am 16.09.2012 20:42, schrieb StÃ©phane Ducasse: > > for what it is worth I like the 3rd form. Now I'm not sure on: is the right selector. > > >

Sept. 16, 2012

Re: [Pharo-project] [NB] Speaking about callbacks

by StÃ©phane Ducasse

On Sep 16, 2012, at 7:17 PM, Igor Stasenko wrote: > Hello, there > > i am happy to say that during last week, i found a cure for my > callback code, and so finally callbacks are now working without > crashing the VM. :) > But before releasing it to public, first, i need to update VMs for > that, because of additional callback support code in VM. > > Right now, i'd like to discuss about different ways of > defining/creating callbacks. And i need more input from people, > because i think > the way how i implemented it is good for get started, but it looks > like there could be more convenient forms :) > > So, the existing implementation, for creating a callback, you must > make a subclass of NBFFICallback, overide #fnSpec method > and then instantiate it by using: > > callback := MyCallBack on: [:... some block ] > > and then you must pass it somewhere (to some external function), and > so, when callback get called, your block will handle it. > > In objective-C, however it would be much nicer to have a smalltalk > objects act as a Obj-C objects (so implementing a methods > for it will naturally map them as a callbacks ). > > For instance imagine that i wanna make own subclass of NSFoo obj-C class > and wanna override the #bar method. > And then i passing it as an obj-c instance around and each time ,Obj-C > #bar message is sent to it , i got a #bar message sent to my smalltalk > instance. > That would be really cool, isnt? Despite it is only applicable to > obj-c because of similar object model :) > > I imagine it could be done as following: > in #bar method you putting a special pragma: > > MyClass>>bar > <objCMethod: 'int ()'> > ^ 5 > > that's it, you telling the compiler that given method can be called > from Objective-C.. and you don't have to manually instantiate > callbacks etc.. > > In fact, same form can be used for non-objC callbacks , you must just > tell something like: > > callback := (MyClass>>#bar) asCallbackFor: myObject. > > here, you instantiating a callback, which when called, the object > 'myObject' will receive #bar message. But unlike from Obj-C this > callback > won't work for all instances of MyClass, but just for specific one. > > And third form is a variation of original one, instead of subclassing > the NBFFICallback, actually i can change implementation to use special > factory class(es) for it, so to create a callback you will do > something like: > > callbackFactory := NBFFICallback withSignature: #( int (int x, void * bar)). > > callback := callbackFactory on: [:x :bar | .... ]. > > So, i'd like to hear your input, which one you like, and which ones > you prefer to have > > 1. requires creating a subclass of NBFFICallback, overriding it's > fnSpec method. Takes a block closure as a callback. > 2. first you must create a factory object by specifying a callback > signature, then you can instantiate new callbacks by passing a block > closure to that factory > 3. to create a callback you must specify it's signature in one of the > compiled methods, and specify an object which will receive a message > when callback will be called. for what it is worth I like the 3rd form. Now I'm not sure on: is the right selector.

Sept. 16, 2012

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

by phil＠highoctane.be

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] pharo on ipad3 -- tiny image shown only

by phil＠highoctane.be

It works fine on my iPad2. Dunno about the 3. What happens when you rotate the screen? Phil 2012/9/16 Johan Brichau <johan(a)inceptive.be>: > 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? > > 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

Sept. 16, 2012

[Pharo-project] [NB] Speaking about callbacks

by Igor Stasenko

Hello, there i am happy to say that during last week, i found a cure for my callback code, and so finally callbacks are now working without crashing the VM. :) But before releasing it to public, first, i need to update VMs for that, because of additional callback support code in VM. Right now, i'd like to discuss about different ways of defining/creating callbacks. And i need more input from people, because i think the way how i implemented it is good for get started, but it looks like there could be more convenient forms :) So, the existing implementation, for creating a callback, you must make a subclass of NBFFICallback, overide #fnSpec method and then instantiate it by using: callback := MyCallBack on: [:... some block ] and then you must pass it somewhere (to some external function), and so, when callback get called, your block will handle it. In objective-C, however it would be much nicer to have a smalltalk objects act as a Obj-C objects (so implementing a methods for it will naturally map them as a callbacks ). For instance imagine that i wanna make own subclass of NSFoo obj-C class and wanna override the #bar method. And then i passing it as an obj-c instance around and each time ,Obj-C #bar message is sent to it , i got a #bar message sent to my smalltalk instance. That would be really cool, isnt? Despite it is only applicable to obj-c because of similar object model :) I imagine it could be done as following: in #bar method you putting a special pragma: MyClass>>bar <objCMethod: 'int ()'> ^ 5 that's it, you telling the compiler that given method can be called from Objective-C.. and you don't have to manually instantiate callbacks etc.. In fact, same form can be used for non-objC callbacks , you must just tell something like: callback := (MyClass>>#bar) asCallbackFor: myObject. here, you instantiating a callback, which when called, the object 'myObject' will receive #bar message. But unlike from Obj-C this callback won't work for all instances of MyClass, but just for specific one. And third form is a variation of original one, instead of subclassing the NBFFICallback, actually i can change implementation to use special factory class(es) for it, so to create a callback you will do something like: callbackFactory := NBFFICallback withSignature: #( int (int x, void * bar)). callback := callbackFactory on: [:x :bar | .... ]. So, i'd like to hear your input, which one you like, and which ones you prefer to have 1. requires creating a subclass of NBFFICallback, overriding it's fnSpec method. Takes a block closure as a callback. 2. first you must create a factory object by specifying a callback signature, then you can instantiate new callbacks by passing a block closure to that factory 3. to create a callback you must specify it's signature in one of the compiled methods, and specify an object which will receive a message when callback will be called. -- Best regards, Igor Stasenko.

Sept. 16, 2012

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

by Igor Stasenko

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