April 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Bye bye pharo on the iPhone

by Stefan Marr

There are rumors, that this change is motived by technical reasons related to multitasking. I could imagine some nice tricks related to the efforts Apple is putting into LLVM, to actually have a 'smart' C/C++ runtime system which allows to assess what kind of activity profile an app is going to exhibit. This is already hard enough with C, prohibiting any VM technology seems to be a reasonable step, if they are actually going to employ any analysis techniques to get their multitasking stuff 'right'. But this is pure speculation. In the light of Steve Job's remark: "We just shipped it on Saturday, and we rested on Sunday." everything is possible, even that he is just going... >> http://www.macrumors.com/2010/04/09/fallout-from-apples-exclusion-of-flash-… The primary reason for the change, say sources familiar with Apple's plans, is to support sophisticated new multitasking APIs in iPhone 4.0. The system will now be evaluating apps as they run in order to implement smart multitasking. It can't do this if apps are running within a runtime or are cross compiled with a foreign structure that doesn't behave identically to a native C/C++/Obj-C app. "[The operating system] can't swap out resources, it can't pause some threads while allowing others to run, it can't selectively notify, etc. Apple needs full access to a properly-compiled app to do the pull off the tricks they are with this new OS," wrote one reader under the name Ktappe. << Regards Stefan On 10 Apr 2010, at 17:46, Lukas Renggli wrote: > There is no reasonable way for Apple to tell if an application is > implemented in Objective-C or in some other language on top of > Objective-C. After all, "any sufficiently complicated C or Fortran > program contains an ad hoc informally-specified bug-ridden slow > implementation of half of Common Lisp" [Phil Greenspun]. Why can't > this Lisp be Pharo Smalltalk? How would they know the difference? > > Lukas > > 2010/4/10 Ramiro Diaz Trepat <ramiro(a)diaztrepat.name>: >> arstechnica.com/apple/news/2010/04/apple-takes-aim-at-adobe-or-android.ars >> >> Sent from my Android mobile >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

April 10, 2010

Re: [Pharo-project] Bye bye pharo on the iPhone

by StÃ©phane Ducasse

why? the vm is a c application and the image such data of the application. Tell me if this is otherwise. On Apr 10, 2010, at 5:13 PM, Ramiro Diaz Trepat wrote: > arstechnica.com/apple/news/2010/04/apple-takes-aim-at-adobe-or-android.ars > > Sent from my Android mobile > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 10, 2010

Re: [Pharo-project] Bye bye pharo on the iPhone

by Lukas Renggli

There is no reasonable way for Apple to tell if an application is implemented in Objective-C or in some other language on top of Objective-C. After all, "any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp" [Phil Greenspun]. Why can't this Lisp be Pharo Smalltalk? How would they know the difference? Lukas 2010/4/10 Ramiro Diaz Trepat <ramiro(a)diaztrepat.name>: > arstechnica.com/apple/news/2010/04/apple-takes-aim-at-adobe-or-android.ars > > Sent from my Android mobile > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

April 10, 2010

[Pharo-project] Bye bye pharo on the iPhone

by Ramiro Diaz Trepat

arstechnica.com/apple/news/2010/04/apple-takes-aim-at-adobe-or-android.ars Sent from my Android mobile

April 10, 2010

Re: [Pharo-project] Canvas transform bug when rendering text?

by Michael Rueger

On Sat, Apr 10, 2010 at 11:33 AM, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Michael Rueger a Ã©crit : >> >> On 4/10/2010 11:04 AM, Hilaire Fernandes wrote: > >> In combination with CSS it allowed us to change the UI without changing >> the code (at least to some extend). Basically skinning through external >> files, as you would do with a properly done web site. > > And how do you fell about it now? Â Will you do the same choice if starting > from now? Basically yes, although some of the internal aspects could be improved. Largely has to do with the way we sort of had to retrofit it onto Tweak. Michael

April 10, 2010

Re: [Pharo-project] Initial experience coming from Squeak

by Lukas Renggli

>> * what is with the workflow of the default browser? Â When you click on a >> protocol, the method template appears in the bottom pane, all highlighted >> and ready to be replaced. Â But because hovering over the pane doesn't give >> it the keyboard focus (like Squeak), you have to click in it, which >> unselects the template, which you then have to reselect manuallyâ¦ >> Certainly not a big deal, but weird. Â I though of a few possible fixes: >> Â - automatically give the bottom pane the keyboard focus when working in >> the protocol column (which doesn't seem to need it (I like this one - >> fewest steps for the user) >> Â - don't have the template pre-selected, so that clicking in the pane >> below the template selects it (easiest fix, requires one more user click) > > Issue 2289: http://code.google.com/p/pharo/issues/detail?id=2289 : 1. Automatically selecting the text pane violates basic UI principles. In many cases this is not what you want, e.g. when you just browse existing code. 2. I don't see why not pre-selecting the template helps? I've quickly changed that, but clicking on it doesn't select it. However, whatever focus settings you've enabled in your Pharo image, double clicking onto the text pane selects everything. Lukas -- Lukas Renggli www.lukas-renggli.ch

April 10, 2010

Re: [Pharo-project] Canvas transform bug when rendering text?

by Hilaire Fernandes

Michael Rueger a Ã©crit : > On 4/10/2010 11:04 AM, Hilaire Fernandes wrote: > In combination with CSS it allowed us to change the UI without changing > the code (at least to some extend). Basically skinning through external > files, as you would do with a properly done web site. And how do you fell about it now? Will you do the same choice if starting from now? Hilaire

April 10, 2010

Re: [Pharo-project] SqueakSource is unusable

by Lukas Renggli

> or if not that, then nearly so. Thank you for the friendly subject, I almost marked it as spam. I've integrated you changes, but I had to change many things because your styles broke the layout of the two columns and the position of the separation bar between them. Lukas -- Lukas Renggli www.lukas-renggli.ch

April 10, 2010

Re: [Pharo-project] Canvas transform bug when rendering text?

by Michael Rueger

On 4/10/2010 11:04 AM, Hilaire Fernandes wrote: > I remember you were using XUL for UI definition in Sophie, why this choice? In combination with CSS it allowed us to change the UI without changing the code (at least to some extend). Basically skinning through external files, as you would do with a properly done web site. Michael

April 10, 2010

Re: [Pharo-project] Canvas transform bug when rendering text?

by Hilaire Fernandes

Michael Rueger a Ã©crit : > Tweak does (or did back then) some caching. You have to be careful > though with caching, as you might end up copying a lot of bits around > even if caching doesn't really make sense for your particular application. I was meaning caching for UI widget rendering. Of course, in DrGeo it does not make sense, but I was not thinking at all to it. I remember you were using XUL for UI definition in Sophie, why this choice? Hilaire

April 10, 2010