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

Re: [Pharo-project] A port of Pharo: Redline Smalltalk ...

by StÃ©phane Ducasse

Hi richard thanks. The idea is to start small and learn. This is what I'm doing. Something where we need some hands are for example the running the tests in 1.1 and reporting the problems. Looking at the bug entries and checking if there are still valid is also an important task. After pick something you think will be interesting for you and ask for feedback. An interesting one is the one related to the pointerfinder you may learn a lot of fun stuff. Stef On Apr 11, 2010, at 6:16 PM, Richard Durr wrote: > I'd like to contribute, but I am not good enough for the difficult > ones to come to pleasing solutions, and I somehow don't feel the other > ones accessable for me :/ > > On Sat, Apr 10, 2010 at 9:21 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Hi richard >> >> some changes are changes coming from squeak and in such a case there is the squeak change >> It does not mean that we can integrate the change as it is. >> Thanks for looking at fixes and bug entries >> >> Stef >> >> On Apr 10, 2010, at 7:52 PM, Richard Durr wrote: >> >>> I am still trying to grok how this issue-fixing works. For example, in >>> "Difficulty:Easy" there are some issues which consist mostly of >>> ChangeSets of something. O_o >> >> O_o >> >> Nice :) >> >> >>> >>> On Tue, Apr 6, 2010 at 10:50 AM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> Yes this is the vision we have. >>>> Now if people would help for simple things in pharo we would have more time for such issues. >>>> We got several people doing PhD on modules and related. We studied namespace and other kind of >>>> points so we have an idea of what could be a solution but it should be implemented >>>> tested..... >>>> >>>> Stef >>>> >>>> >>>> On Apr 6, 2010, at 1:14 AM, Richard Durr wrote: >>>> >>>>> No, it's not. I would be far more valuable to have modularized images >>>>> though: Just like Next/Apples Nibs or Bundle-mechanism. These >>>>> image-modules would be edited from a development-image-bundle. They >>>>> could be used to form stand-alone applications already clean of the >>>>> development code or libraries that contain only a diff to the base >>>>> classes, these library-images could then be combined to form more >>>>> complex images. They could also contain their own namespaceâ¦ and they >>>>> would replace the non-modelling packaging mechanism, but I digressâ¦ ^^ >>>>> >>>>> | packageWorkedOn | >>>>> packageWorkedOn := Browser newPackageNamed: 'Calculator'. >>>>> packageWorkedOn importPackage: 'Seaside'. >>>>> "Create code in the Browserâ¦" >>>>> packageWorkedOn saveAsMonticello. >>>>> packageWordedOn saveAsPackage. >>>>> packageWorkedOn saveAsApplication. >>>>> >>>>> or something like that â¦ ^^ >>>>> >>>>> On Mon, Apr 5, 2010 at 9:08 PM, nullPointer <epicfan(a)gmail.com> wrote: >>>>>> >>>>>> jarober says: >>>>>> >>>>>>> The reason these "Smalltalk for .NET" and "Smalltalk for the JVM" >>>>>>> projects never seem to come off is simple - Smalltalk isn't just flat >>>>>>> text in an editor. Smalltalk is the entire interactive environment. >>>>>>> It would be fairly simple to get a syntax parser, but it wouldn't be >>>>>>> Smalltalk. It would be Ruby or Python with Smalltalk syntax. >>>>>>> Somewhat useful perhaps, but not really Smalltalk. >>>>>> >>>>>> :( >>>>>> >>>>>> Hopefully it would have sufficient knowledge to be able to do something >>>>>> thus. >>>>>> >>>>>> Sorry, but I believe that it is the way that had to take commercial >>>>>> Smalltalk. It surprises to me that Cincom and company do not see it. >>>>>> >>>>>> Regards. >>>>>> -- >>>>>> View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1751884p1751963.ht… >>>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> >> _______________________________________________ >> 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

April 11, 2010

Re: [Pharo-project] A port of Pharo: Redline Smalltalk ...

by Richard Durr

I'd like to contribute, but I am not good enough for the difficult ones to come to pleasing solutions, and I somehow don't feel the other ones accessable for me :/ On Sat, Apr 10, 2010 at 9:21 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi richard > > some changes are changes coming from squeak and in such a case there is the squeak change > It does not mean that we can integrate the change as it is. > Thanks for looking at fixes and bug entries > > Stef > > On Apr 10, 2010, at 7:52 PM, Richard Durr wrote: > >> I am still trying to grok how this issue-fixing works. For example, in >> "Difficulty:Easy" there are some issues which consist mostly of >> ChangeSets of something. O_o > > O_o > > Nice :) > > >> >> On Tue, Apr 6, 2010 at 10:50 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Yes this is the vision we have. >>> Now if people would help for simple things in pharo we would have more time for such issues. >>> We got several people doing PhD on modules and related. We studied namespace and other kind of >>> points so we have an idea of what could be a solution but it should be implemented >>> tested..... >>> >>> Stef >>> >>> >>> On Apr 6, 2010, at 1:14 AM, Richard Durr wrote: >>> >>>> No, it's not. I would be far more valuable to have modularized images >>>> though: Just like Next/Apples Nibs or Bundle-mechanism. These >>>> image-modules would be edited from a development-image-bundle. They >>>> could be used to form stand-alone applications already clean of the >>>> development code or libraries that contain only a diff to the base >>>> classes, these library-images could then be combined to form more >>>> complex images. They could also contain their own namespaceâ¦ and they >>>> would replace the non-modelling packaging mechanism, but I digressâ¦ ^^ >>>> >>>> | packageWorkedOn | >>>> packageWorkedOn := Browser newPackageNamed: 'Calculator'. >>>> packageWorkedOn importPackage: 'Seaside'. >>>> "Create code in the Browserâ¦" >>>> packageWorkedOn saveAsMonticello. >>>> packageWordedOn saveAsPackage. >>>> packageWorkedOn saveAsApplication. >>>> >>>> or something like that â¦ ^^ >>>> >>>> On Mon, Apr 5, 2010 at 9:08 PM, nullPointer <epicfan(a)gmail.com> wrote: >>>>> >>>>> jarober says: >>>>> >>>>>> The reason these "Smalltalk for .NET" and "Smalltalk for the JVM" >>>>>> projects never seem to come off is simple - Smalltalk isn't just flat >>>>>> text in an editor. Â Smalltalk is the entire interactive environment. >>>>>> It would be fairly simple to get a syntax parser, but it wouldn't be >>>>>> Smalltalk. Â It would be Ruby or Python with Smalltalk syntax. >>>>>> Somewhat useful perhaps, but not really Smalltalk. >>>>> >>>>> :( >>>>> >>>>> Hopefully it would have sufficient knowledge to be able to do something >>>>> thus. >>>>> >>>>> Sorry, but I believe that it is the way that had to take commercial >>>>> Smalltalk. It surprises to me that Cincom and company do not see it. >>>>> >>>>> Regards. >>>>> -- >>>>> View this message in context: http://n4.nabble.com/A-port-of-Pharo-Redline-Smalltalk-tp1751884p1751963.ht… >>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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

[Pharo-project] WeakSet but no WeakIdentitySet?

by Igor Stasenko

Hello, i need to keep a bunch of CompiledMethods in WeakSet, but i am a bit afraid, that it wont work as i want to, because of CompiledMethod>>= implementation, because a code, which i currently writing doesn't changing a method's bytecode, but changing its trailer instead, and so, this could lead to undesirable effects.. If i could have a WeakIdentitySet... Meanwhile, i think i have nothing else, but just use a degenerate WeakIdentityKeyDictionary , with methods in keys and nils in values. :( -- 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:59, Lukas Renggli <renggli(a)gmail.com> wrote: >> 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. > Really? What about FireFox? If that's not excellent.. then i really can't guess , what is your criteria of being excellent. Or. take macs.. what engine used in Safari? Or .. on what is based a Darwin OS? > Lukas > > -- > 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] 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