[Pharo-project] [ANN] iPad Dr. Geo 12.10
Dr. Geo (aka Dr. Geometry) 12.10 for iPad is available on AppStore. It comes in two versions: gratis and paid. http://itunes.apple.com/us/app/dr.-geometry/id559858173?l=fr&ls=1&mt=8 Compare to the desktop versions, it is almost feature complete: only the script and programmed figure can not be created or edited with this version. However, sketches including scripts are interpreted and rendered correctly on the tablet. *Feedbacks* and *rating* are welcome and greatly appreciated! Thanks! http://drgeo.eu
Re: [Pharo-project] [ANN] iPad Dr. Geo 12.10
Hej Hilaire! I've bought the paid version, and it does look pretty nice. As you ask for feedback, I thought it would be OK to post it here, apologies to all if it's not appropriate! 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"? I wanted to show this to my kids to demonstrate what amazing things are possible with Smalltalk, but for that to work I'd need to at least seem to understand it myself ;-) -- Cheers, Peter. On 16 sep 2012, at 10:30, Hilaire Fernandes wrote: > Dr. Geo (aka Dr. Geometry) 12.10 for iPad is available on AppStore. It > comes in two versions: gratis and paid. > http://itunes.apple.com/us/app/dr.-geometry/id559858173?l=fr&ls=1&mt=8 > > Compare to the desktop versions, it is almost feature complete: only the > script and programmed figure can not be created or edited with this > version. However, sketches including scripts are interpreted and > rendered correctly on the tablet. > > *Feedbacks* and *rating* are welcome and greatly appreciated! > > Thanks! > > http://drgeo.eu > > >
Re: [Pharo-project] [ANN] iPad Dr. Geo 12.10
Great achievement, congratulations ! On 16 Sep 2012, at 10:30, Hilaire Fernandes wrote: > Dr. Geo (aka Dr. Geometry) 12.10 for iPad is available on AppStore. It > comes in two versions: gratis and paid. > http://itunes.apple.com/us/app/dr.-geometry/id559858173?l=fr&ls=1&mt=8 > > Compare to the desktop versions, it is almost feature complete: only the > script and programmed figure can not be created or edited with this > version. However, sketches including scripts are interpreted and > rendered correctly on the tablet. > > *Feedbacks* and *rating* are welcome and greatly appreciated! -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Re: [Pharo-project] [ANN] iPad Dr. Geo 12.10
Hi Peter, Interactive geometry software are very specilised software, so you need to understand how it works. Tutorial are indeed important. My main problem is speaking language. I have written documentation in French at http://www.drgeo.eu/screenshot-video I can't produce an english documentation with a good quality level. We have some video tutorial at http://www.drgeo.eu/screenshot-video Some of the video are in French other in English But I should set up a Video channel for begginer to get started, it will be a great idea. What do you think? Next about tutorial button within DrGeo, yes it will be a nice addition. It is someting I need to thing about. Thanks for your feedback Hilaire Le 16/09/2012 11:53, Peter Hugosson-Miller a écrit : > Hej Hilaire! > > I've bought the paid version, and it does look pretty nice. As you ask for > feedback, I thought it would be OK to post it here, apologies to all if it's > not appropriate! > > 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"? > > I wanted to show this to my kids to demonstrate what amazing things are > possible with Smalltalk, but for that to work I'd need to at least seem to > understand it myself ;-) > > -- > Cheers, > Peter. > > On 16 sep 2012, at 10:30, Hilaire Fernandes > wrote: > >> Dr. Geo (aka Dr. Geometry) 12.10 for iPad is available on AppStore. It >> comes in two versions: gratis and paid. >> http://itunes.apple.com/us/app/dr.-geometry/id559858173?l=fr&ls=1&mt=8 >> >> Compare to the desktop versions, it is almost feature complete: only the >> script and programmed figure can not be created or edited with this >> version. However, sketches including scripts are interpreted and >> rendered correctly on the tablet. >> >> *Feedbacks* and *rating* are welcome and greatly appreciated! >> >> Thanks! >> >> http://drgeo.eu >> >> >> > >
[Pharo-project] Smalltalkhub news
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
Re: [Pharo-project] Smalltalkhub news
Cool cool cool :) Now the website need a "Import from" part to mmigrate from ss3/squeaksource to SmalltalkHub :) Ben On Sep 16, 2012, at 1:18 PM, Camillo Bruni 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 >
Re: [Pharo-project] [ANN] iPad Dr. Geo 12.10
Yes, I think that a beginners video channel would be a great idea! When I get to the stage of understanding things enough, maybe I'll be able to help. I have English as my mother tongue, and my sister is French, and speaks excellent English. I'm not promising anything, but it does feel important to me at the moment ;-) -- Cheers, Peter. On 16 sep 2012, at 12:14, Hilaire Fernandes wrote: > Hi Peter, > > > Interactive geometry software are very specilised software, so you need > to understand how it works. Tutorial are indeed important. > > My main problem is speaking language. > > I have written documentation in French at > http://www.drgeo.eu/screenshot-video > I can't produce an english documentation with a good quality level. > > We have some video tutorial at > http://www.drgeo.eu/screenshot-video > > Some of the video are in French other in English > > But I should set up a Video channel for begginer to get started, it will > be a great idea. What do you think? > > Next about tutorial button within DrGeo, yes it will be a nice addition. > It is someting I need to thing about. > > Thanks for your feedback > > Hilaire > > > Le 16/09/2012 11:53, Peter Hugosson-Miller a écrit : >> Hej Hilaire! >> >> I've bought the paid version, and it does look pretty nice. As you ask for >> feedback, I thought it would be OK to post it here, apologies to all if it's >> not appropriate! >> >> 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"? >> >> I wanted to show this to my kids to demonstrate what amazing things are >> possible with Smalltalk, but for that to work I'd need to at least seem to >> understand it myself ;-) >> >> -- >> Cheers, >> Peter. >> >> On 16 sep 2012, at 10:30, Hilaire Fernandes >> wrote: >> >>> Dr. Geo (aka Dr. Geometry) 12.10 for iPad is available on AppStore. It >>> comes in two versions: gratis and paid. >>> http://itunes.apple.com/us/app/dr.-geometry/id559858173?l=fr&ls=1&mt=8 >>> >>> Compare to the desktop versions, it is almost feature complete: only the >>> script and programmed figure can not be created or edited with this >>> version. However, sketches including scripts are interpreted and >>> rendered correctly on the tablet. >>> >>> *Feedbacks* and *rating* are welcome and greatly appreciated! >>> >>> Thanks! >>> >>> http://drgeo.eu >>> >>> >>> >> >> > > >
Re: [Pharo-project] Smalltalkhub news
Nice work guys. Just, one question, I read that Smalltalkhub is using MongoDB. Is that right? How do you do that? There is a Smalltalk port or something for MongoDB. Cheers. On Sep 16, 2012, at 8:18 , Camillo Bruni 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
Re: [Pharo-project] Smalltalkhub news
driver: http://squeaksource.com/MongoTalk/ mapper: http://smalltalkhub.com/#!/~estebanlm/Voyage cheers, Esteban On Sep 16, 2012, at 3:15 PM, Oscar E A Callaú wrote: > Nice work guys. > > Just, one question, I read that Smalltalkhub is using MongoDB. Is that right? > How do you do that? There is a Smalltalk port or something for MongoDB. > > Cheers. > > > On Sep 16, 2012, at 8:18 , Camillo Bruni 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 > >
Re: [Pharo-project] Smalltalkhub news
Very cool. I'll give it a shot. 2012/9/16 Benjamin : > Cool cool cool :) > > Now the website need a "Import from" part to mmigrate from ss3/squeaksource > to SmalltalkHub :) > > Ben > > On Sep 16, 2012, at 1:18 PM, Camillo Bruni 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 >> > >
Re: [Pharo-project] [ANN] iPad Dr. Geo 12.10
You can take a look at this selection of video http://www.dailymotion.com/group/drgeo-beginner Need to be recorded again Hilaire
Re: [Pharo-project] Smalltalkhub news
Excellent! Stef On Sep 16, 2012, at 1:18 PM, Camillo Bruni 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 >
Re: [Pharo-project] [ANN] iPad Dr. Geo 12.10
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"?
[Pharo-project] R: [ANN] iPad Dr. Geo 12.10
Hi Hilaire, I am going to download a simplex algorithm for linear programming from a VSE version I developed some years ago; are you (or some other people) interested to it, as I have found that the porting is more complex than I have imagined. Grazie Lorenzo -Messaggio originale- Da: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] Per conto di Hilaire Fernandes Inviato: domenica 16 settembre 2012 10.30 A: pharo-project@lists.gforge.inria.fr Oggetto: [Pharo-project] [ANN] iPad Dr. Geo 12.10 Dr. Geo (aka Dr. Geometry) 12.10 for iPad is available on AppStore. It comes in two versions: gratis and paid. http://itunes.apple.com/us/app/dr.-geometry/id559858173?l=fr&ls=1&mt=8 Compare to the desktop versions, it is almost feature complete: only the script and programmed figure can not be created or edited with this version. However, sketches including scripts are interpreted and rendered correctly on the tablet. *Feedbacks* and *rating* are welcome and greatly appreciated! Thanks! http://drgeo.eu
Re: [Pharo-project] R: [ANN] iPad Dr. Geo 12.10
Ho Lorenzo, Philip wrote about simplex algorithm for DrGeo, but he did not gave examples of use case. Right now I can not tell if I will use it for Dr. Geo. But it is nice you asked. Something I will use for sure in Dr. Geo is a Computer Algebra System (even a simple one) written in Smalltalk. Btw, does any of you know Boris Gaertner, he worked in a CAS system in Smalltalk ? http://www.bgaertner.gmxhome.de/liouville.htm Thanks Hilaire Le 16/09/2012 17:04, Lorenzo Schiavina a écrit : > Hi Hilaire, > > I am going to download a simplex algorithm for linear programming from a VSE > version I developed some years ago; are you (or some other people) > interested to it, as I have found that the porting is more complex than I > have imagined. > > Grazie > > Lorenzo >
Re: [Pharo-project] [ANN] iPad Dr. Geo 12.10
yes I meet boris once and this is a nice person. Ask him if he want to release his code under MIT. On Sep 16, 2012, at 5:22 PM, Hilaire Fernandes wrote: > Ho Lorenzo, > > Philip wrote about simplex algorithm for DrGeo, but he did not gave > examples of use case. Right now I can not tell if I will use it for Dr. Geo. > But it is nice you asked. > > Something I will use for sure in Dr. Geo is a Computer Algebra System > (even a simple one) written in Smalltalk. > Btw, does any of you know Boris Gaertner, he worked in a CAS system in > Smalltalk ? > http://www.bgaertner.gmxhome.de/liouville.htm > > Thanks > > Hilaire > > Le 16/09/2012 17:04, Lorenzo Schiavina a écrit : >> Hi Hilaire, >> >> I am going to download a simplex algorithm for linear programming from a VSE >> version I developed some years ago; are you (or some other people) >> interested to it, as I have found that the porting is more complex than I >> have imagined. >> >> Grazie >> >> Lorenzo >> > >
[Pharo-project] pharo on ipad3 -- tiny image shown only
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
Re: [Pharo-project] pharo on ipad3 -- tiny image shown only
On 16 September 2012 18:14, Johan Brichau 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.
[Pharo-project] [NB] Speaking about callbacks
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 ^ 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.
Re: [Pharo-project] pharo on ipad3 -- tiny image shown only
It works fine on my iPad2. Dunno about the 3. What happens when you rotate the screen? Phil 2012/9/16 Johan Brichau : > 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
Re: [Pharo-project] pharo on ipad3 -- tiny image shown only
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 :
> On 16 September 2012 18:14, Johan Brichau 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.
>
Re: [Pharo-project] [NB] Speaking about callbacks
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 > > ^ 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.
Re: [Pharo-project] [NB] Speaking about callbacks
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. <>
Re: [Pharo-project] [ANN] iPad Dr. Geo 12.10
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.fernan...@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"? >
Re: [Pharo-project] Zinc Progress
On 15 Sep 2012, at 01:02, Camillo Bruni wrote: > On 2012-09-14, at 23:11, Sven Van Caekenberghe wrote: >> On 14 Sep 2012, at 20:57, Frank Shearar 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
Re: [Pharo-project] Smalltalkhub news
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 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
Re: [Pharo-project] pharo on ipad3 -- tiny image shown only
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, p...@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 :
>> On 16 September 2012 18:14, Johan Brichau 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.
>>
>
Re: [Pharo-project] Zinc Progress
> 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...
Re: [Pharo-project] Zinc Progress
On 2012-09-16, at 21:50, 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... another remark with signalProgress the time to run highly varies, 250ms - 2500ms. whereas without progress notification it stays <140ms
Re: [Pharo-project] Smalltalkhub news
On 2012-09-16, at 21:29, Sven Van Caekenberghe 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)
Re: [Pharo-project] Zinc Progress
>> 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
Re: [Pharo-project] Zinc Progress
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... > > > > >
Re: [Pharo-project] pharo on ipad3 -- tiny image shown only
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 :
> 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, p...@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 :
>>> On 16 September 2012 18:14, Johan Brichau 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.
>>>
>>
>
>
[Pharo-project] [update 2.0] #20289
20289 - - Issue 6626: [Nautilus] removing groups is not working properly. Thanks Benjamin Van Ryseghem. http://code.google.com/p/pharo/issues/detail?id=6626 - Issue 5103: Better Gofer error messages. Thanks Sean De Nigris and Camillo Bruni. http://code.google.com/p/pharo/issues/detail?id=5103 - Issue 6673: Remove squeakmap from MC repositories. http://code.google.com/p/pharo/issues/detail?id=6673
Re: [Pharo-project] Smalltalkhub news
On 16 Sep 2012, at 21:56, Camillo Bruni wrote: >> 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) The reason ZnClient keeps on retrying on 404 is because you probably had #enforceHttpSuccess true as part of #systemPolicy and only 2xx response are considered a success. But this is an interesting use case: basically 404 is a valid response here. I'll have to think about that so more. Thanks for pushing this and letting me know. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
[Pharo-project] pharo-2.0-tests » win - Build # 352 - Still Failing!
BUILD FAILUREBuild URLhttps://ci.lille.inria.fr/pharo/job/pharo-2.0-tests/./label_exp=win/352/Project:label_exp=winDate of build:Sun, 16 Sep 2012 22:57:58 +0200Build duration:0.26 secCHANGESNo ChangesCONSOLE OUTPUTStarted by upstream project "pharo-2.0-tests" build number 352Building remotely on pharo-win7-64 in workspace C:\jenkins\workspace\pharo-2.0-tests\label_exp\winNo emails were triggered.[win] $ sh -xe C:\Windows\TEMP\hudson7218104088491836508.shThe system cannot find the file specifiedFATAL: command execution failedjava.io.IOException: Cannot run program "sh" (in directory "C:\jenkins\workspace\pharo-2.0-tests\label_exp\win"): CreateProcess error=2, The system cannot find the file specified at java.lang.ProcessBuilder.start(Unknown Source) at hudson.Proc$LocalProc.(Proc.java:244) at hudson.Proc$LocalProc.(Proc.java:216) at hudson.Launcher$LocalLauncher.launch(Launcher.java:709) at hudson.Launcher$ProcStarter.start(Launcher.java:338) at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:934) at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:901) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at hudson.remoting.Engine$1$1.run(Engine.java:60) at java.lang.Thread.run(Unknown Source)Caused by: java.io.IOException: CreateProcess error=2, The system cannot find the file specified at java.lang.ProcessImpl.create(Native Method) at java.lang.ProcessImpl.(Unknown Source) at java.lang.ProcessImpl.start(Unknown Source) ... 17 moreBuild step 'Execute shell' marked build as failureArchiving artifactsRecording test resultsDescription set: Email was triggered for: FailureSending email for trigger: Failure
Re: [Pharo-project] Zinc Progress
On 16 Sep 2012, at 21:59, Camillo Bruni wrote: >>> 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 Yeah, that is probably it, and that is horrible, terrible. .. ;-) In #executeWithTimeout a special #exceptionSetForIfFail is used to avoid that, if I remember correctly. Tomorrow, I'll have another look, with a fresh head. Thx again! -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Re: [Pharo-project] Smalltalkhub news
On 2012-09-16, at 22:50, Sven Van Caekenberghe wrote: > > On 16 Sep 2012, at 21:56, Camillo Bruni wrote: > >>> 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) > > The reason ZnClient keeps on retrying on 404 is because you probably had > #enforceHttpSuccess true as part of #systemPolicy and only 2xx response are > considered a success. ah right, that will do it! > But this is an interesting use case: basically 404 is a valid response here. > I'll have to think about that so more. well now I know, so I'm fine by manually changing it :P
Re: [Pharo-project] Zinc Progress
>> 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 > > Yeah, that is probably it, and that is horrible, terrible. .. ;-) > In #executeWithTimeout a special #exceptionSetForIfFail is used to avoid > that, if I remember correctly. > Tomorrow, I'll have another look, with a fresh head. cool ;) I assume a simple Exception => Error will do :P
Re: [Pharo-project] [ANN] iPad Dr. Geo 12.10
Hilaire, I completely admire your dedication. Making great software is a long road. Congratulations. On Sun, Sep 16, 2012 at 3:30 AM, Hilaire Fernandes wrote: > Dr. Geo (aka Dr. Geometry) 12.10 for iPad is available on AppStore. It > comes in two versions: gratis and paid. > http://itunes.apple.com/us/app/dr.-geometry/id559858173?l=fr&ls=1&mt=8 > > Compare to the desktop versions, it is almost feature complete: only the > script and programmed figure can not be created or edited with this > version. However, sketches including scripts are interpreted and > rendered correctly on the tablet. > > *Feedbacks* and *rating* are welcome and greatly appreciated! > > Thanks! > > http://drgeo.eu > > >
