- Pharo-dev - lists.pharo.org

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

by Lukas Renggli

> People won't buy an 'approved' C++ crap, if they will have a choice to > use something which is way better. > And they are really don't care, what language is used to implement software. You'll have to admit that open source software with a truly excellent user experience still hasn't happened yet. Lukas -- Lukas Renggli www.lukas-renggli.ch

April 11, 2010

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

by Igor Stasenko

On 11 April 2010 17:42, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 11 April 2010 17:29, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Interesting theory. Â The question is are they trying to force developers to buy Macs, or are they simply trying to avoid the hassles of targeting Windows? Â 10+ years to present day is an interesting time frame. Â OLE was pretty much out of the way (supported but not pressed and certainly not dominating the work flow of the masses), COM was still the answer to everything, at least until the OCX/ActiveX silliness got into full swing, and then they started threatening to do away with native code (.Net, presentation framework, end of the portable executable format, etc.). >> >> If I could avoid all of that *and* sell some of my high-priced hardware at the same time, I might do the same thing that Apple is doing. >> > > But what makes you think, that your approach to software development > is any better than any other one? > Or, that having C, C++, Object-C and JavaScript is all what today's > developper needs? > You could have a brilliant hardware with tons of cool functionality. But without good software this is just a piece of useless metal and plastic. And we know, that all good things is brought to life in open and free, creative environments, not in sealed and secured , paranoic places. People won't buy an 'approved' C++ crap, if they will have a choice to use something which is way better. And they are really don't care, what language is used to implement software. P.S. i miss the S letter in 'Apple's name, so , i will put a $ instead :) > >> Bill >> >> >> -- Best regards, Igor Stasenko AKA sig.

April 11, 2010

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

by Igor Stasenko

On 11 April 2010 17:29, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Interesting theory. Â The question is are they trying to force developers to buy Macs, or are they simply trying to avoid the hassles of targeting Windows? Â 10+ years to present day is an interesting time frame. Â OLE was pretty much out of the way (supported but not pressed and certainly not dominating the work flow of the masses), COM was still the answer to everything, at least until the OCX/ActiveX silliness got into full swing, and then they started threatening to do away with native code (.Net, presentation framework, end of the portable executable format, etc.). > > If I could avoid all of that *and* sell some of my high-priced hardware at the same time, I might do the same thing that Apple is doing. > But what makes you think, that your approach to software development is any better than any other one? Or, that having C, C++, Object-C and JavaScript is all what today's developper needs? > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lawson English > Sent: Saturday, April 10, 2010 5:36 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Bye bye pharo on the iPhone > > Igor Stasenko wrote: >> 2010/4/10 John M McIntosh <johnmci(a)smalltalkconsulting.com>: >> >>> On 2010-04-10, at 9:08 AM, Stefan Marr wrote: >>> >>> >>>> 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-to-iphone-export-continues/ >>>>>> >>>> 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. >>>> << >>>> >>> Nonsense. >>> >>> An hour with some unix internals book and reading a bit about suspend/resume, and reflect on what happens when you sleep your unix based laptop shows there is no magic involved, just a bit of change to how Processes are managed. >>> >> >> +1.. this is a bullshit. >> Instead of solving the problem, they locking-down their platform. >> >> Its like saying "we're going to build an aircrafts with 4 wings, and >> from this moment, all two-winged planes should stop being used >> worldwide". >> >> > Its just a way of making sure that all iPhone/iPad/Mac development is still done on Macs, IMHO. > > 10+ years ago, Apple promised developers a way to program Mac OS X apps > for Windows. > > With the advent of QuickTime X, based on Cocoa libs, I've been > speculating that Apple was planning on leveraging those libraries as a > distribution of Mac OS X frameworks to Windows that 3rd party developers > could use. > > It doesn't seem a total stretch that if Apple does this, they want to > make sure that iPhone/iPad apps can only be developed on Mac and by > extension, Mac OS X applications, even for Windows, will only be > developed on the Mac as well. One IDE to rule them all: Mac OS X, > iphone/ipad/iTouch, and now (MAYBE) Windows... > > > Lawson > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 11, 2010

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

by Schwab,Wilhelm K

Interesting theory. The question is are they trying to force developers to buy Macs, or are they simply trying to avoid the hassles of targeting Windows? 10+ years to present day is an interesting time frame. OLE was pretty much out of the way (supported but not pressed and certainly not dominating the work flow of the masses), COM was still the answer to everything, at least until the OCX/ActiveX silliness got into full swing, and then they started threatening to do away with native code (.Net, presentation framework, end of the portable executable format, etc.). If I could avoid all of that *and* sell some of my high-priced hardware at the same time, I might do the same thing that Apple is doing. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lawson English Sent: Saturday, April 10, 2010 5:36 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Bye bye pharo on the iPhone Igor Stasenko wrote: > 2010/4/10 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > >> On 2010-04-10, at 9:08 AM, Stefan Marr wrote: >> >> >>> 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-to-iphone-export-continues/ >>>>> >>> 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. >>> << >>> >> Nonsense. >> >> An hour with some unix internals book and reading a bit about suspend/resume, and reflect on what happens when you sleep your unix based laptop shows there is no magic involved, just a bit of change to how Processes are managed. >> > > +1.. this is a bullshit. > Instead of solving the problem, they locking-down their platform. > > Its like saying "we're going to build an aircrafts with 4 wings, and > from this moment, all two-winged planes should stop being used > worldwide". > > Its just a way of making sure that all iPhone/iPad/Mac development is still done on Macs, IMHO. 10+ years ago, Apple promised developers a way to program Mac OS X apps for Windows. With the advent of QuickTime X, based on Cocoa libs, I've been speculating that Apple was planning on leveraging those libraries as a distribution of Mac OS X frameworks to Windows that 3rd party developers could use. It doesn't seem a total stretch that if Apple does this, they want to make sure that iPhone/iPad apps can only be developed on Mac and by extension, Mac OS X applications, even for Windows, will only be developed on the Mac as well. One IDE to rule them all: Mac OS X, iphone/ipad/iTouch, and now (MAYBE) Windows... Lawson _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 11, 2010

Re: [Pharo-project] Graphics-MichaelRueger.168....backported normalized transform

by Michael Rueger

On 4/11/2010 11:19 AM, stephane ducasse wrote: > Hi > > apparently mike posted a while ago transform changes. > There were unnoticed because buried over a lot of other changes. > > So mike should I integrate these changes. Even when I use the bug entry > I tend to forget my own changes so without bug entry item. the chances are even higher. hmm, long time ago ;-) Someone actually using transforms should verify these changes don't break anything in the current Pharo version. Michael

April 11, 2010

Re: [Pharo-project] [squeak-dev] Context reflection regression?

by Igor Stasenko

On 11 April 2010 12:41, Lukas Renggli <renggli(a)gmail.com> wrote: > AFAIK, the values are copied on send to the arguments/temps of > thisContext (1...4), they are not kept in the sending stack frame. > hmm... then i wonder , how ContextPart>>jump and ContextPart>>restart still working, because in #jump it using a #pop method, which decrements the sp value. Obviously, if sp == 0, it fails. > Lukas > > On 11 April 2010 11:32, Igor Stasenko <siguctua(a)gmail.com> wrote: >> I just found that >> >> a: a b: b c: c >> Â ^ thisContext sender stackPtr >> >> answers 0 Â :( >> >> while, in order to call the above method , a caller, obviously needs >> to push 4 values on stack: >> Â - push receiver >> Â - push a >> Â - push b >> Â - push c >> Â - send #a:b:c: >> >> so, a method's caller context stack _should_ contain at least 4 elements. >> >> So, either i wrong, or VM doesn't tracking the context's sp value >> correctly anymore. >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > > > -- > 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 > -- Best regards, Igor Stasenko AKA sig.

April 11, 2010

Re: [Pharo-project] [squeak-dev] Context reflection regression?

by Lukas Renggli

AFAIK, the values are copied on send to the arguments/temps of thisContext (1...4), they are not kept in the sending stack frame. Lukas On 11 April 2010 11:32, Igor Stasenko <siguctua(a)gmail.com> wrote: > I just found that > > a: a b: b c: c > Â ^ thisContext sender stackPtr > > answers 0 Â :( > > while, in order to call the above method , a caller, obviously needs > to push 4 values on stack: > Â - push receiver > Â - push a > Â - push b > Â - push c > Â - send #a:b:c: > > so, a method's caller context stack _should_ contain at least 4 elements. > > So, either i wrong, or VM doesn't tracking the context's sp value > correctly anymore. > > -- > Best regards, > Igor Stasenko AKA sig. > > -- Lukas Renggli www.lukas-renggli.ch

April 11, 2010

[Pharo-project] Context reflection regression?

by Igor Stasenko

I just found that a: a b: b c: c ^ thisContext sender stackPtr answers 0 :( while, in order to call the above method , a caller, obviously needs to push 4 values on stack: - push receiver - push a - push b - push c - send #a:b:c: so, a method's caller context stack _should_ contain at least 4 elements. So, either i wrong, or VM doesn't tracking the context's sp value correctly anymore. -- Best regards, Igor Stasenko AKA sig.

April 11, 2010

[Pharo-project] Graphics-MichaelRueger.168....backported normalized transform

by stephane ducasse

Hi apparently mike posted a while ago transform changes. There were unnoticed because buried over a lot of other changes. So mike should I integrate these changes. Even when I use the bug entry I tend to forget my own changes so without bug entry item. the chances are even higher. Name: Graphics-MichaelRueger.168 Author: MichaelRueger Time: 17 December 2009, 12:02:55 pm UUID: 9a3cca4d-1a2d-5d4b-84c6-b6d3286b98e0 Ancestors: Graphics-MichaelRueger.167 backported normalized transform

April 11, 2010

[Pharo-project] [update 1.1] #11311

by StÃ©phane Ducasse

11311 ----- - Issue 1842: Make the System -> Software update a preference for 1.1. Thanks alain. - Issue 991: Polymorph text entry dialog is ugly . Thanks alain - Issue 2287: Menu Selection Color. Thanks gary.

April 11, 2010