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

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

by StÃ©phane Ducasse

Richard Nicolas checked systematically that add: method returns their argument. - Issue 2171: add consistency in MC, Exception and other for the tests: this a list of possible tests that would be worth to migrate to pharo. - Issue 2238: tests for FileStream behavior - Issue 1920: Better PureBehaviorTests - Issue 1934: some tests for WeakRegistry Let me know if you need advices. 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] add #next:putAll:startingAt: to SocketStream

by StÃ©phane Ducasse

thanks for the reminder Philippe I just integrated your fixes. Could you have a look at the entry pointed by levente? Stef On Apr 11, 2010, at 9:46 PM, Levente Uzonyi wrote: > On Sun, 11 Apr 2010, Philippe Marschall wrote: > >> Hi >> >> While I was optimizing some Seaside code I found out that SocketStream >> does not understand #next:putAll:startingAt: [1]. It's quite a helpful >> method that allows one to write a subcollection of a collection to a >> stream without making a copy. In our case it would allow the codec to >> directly write to the socket stream. >> >> Anyway what I wanted to say is this is fixed in Network-Kernel-pmm.29 ;-) >> >> [1] http://code.google.com/p/pharo/issues/detail?id=2292 > > FYI: http://code.google.com/p/pharo/issues/detail?id=2244 > > > Levente > >> >> Cheers >> Philippe >> >> >> _______________________________________________ >> 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] add #next:putAll:startingAt: to SocketStream

by Levente Uzonyi

On Sun, 11 Apr 2010, Philippe Marschall wrote: > Hi > > While I was optimizing some Seaside code I found out that SocketStream > does not understand #next:putAll:startingAt: [1]. It's quite a helpful > method that allows one to write a subcollection of a collection to a > stream without making a copy. In our case it would allow the codec to > directly write to the socket stream. > > Anyway what I wanted to say is this is fixed in Network-Kernel-pmm.29 ;-) > > [1] http://code.google.com/p/pharo/issues/detail?id=2292 FYI: http://code.google.com/p/pharo/issues/detail?id=2244 Levente > > Cheers > Philippe > > > _______________________________________________ > 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] Open Pharo debugger from a Seaside wallback

by Facundo Vozzi

Hi people, I'm using Pharo RC2 with Seaside 2.8.4 version and it's very slow when I trying to debugging a seaside application. In other words, I press the debug link on the seaside application walback and it take to Pharo over 40 seconds to open de imagen debugger. I tried with Seaside 3 developer image and it was the same situation. I'm using pharo on 32 bits Windows 7 in a Core 2 Duo and 2 GB ram memory. Has anybody experimented the same problem or behavior? Tranks, Facundo ps: Please, excuse my poor english.

April 11, 2010

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

by Igor Stasenko

On 11 April 2010 19:53, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > I *never* said anything like that. Sure you didn't. Apple did :) >I do think that Microsoft is in decline, and it would not surprise me at all if Apple didn't want to play along with their whims, trying hit a moving target that will cause them to do extra work at the potential expense of their own market share. > They (Apple and M$) are dinosaurs. Google will kill them all. We'll see that :) This is because they don't realizing where a software evolution goes: open standards, open architecture, open software. > Bill > > -- Best regards, Igor Stasenko AKA sig.

April 11, 2010

Re: [Pharo-project] add #next:putAll:startingAt: to SocketStream

by StÃ©phane Ducasse

Cool! Soon in the best shop close to you :) Stef On Apr 11, 2010, at 7:03 PM, Philippe Marschall wrote: > Hi > > While I was optimizing some Seaside code I found out that SocketStream > does not understand #next:putAll:startingAt: [1]. It's quite a helpful > method that allows one to write a subcollection of a collection to a > stream without making a copy. In our case it would allow the codec to > directly write to the socket stream. > > Anyway what I wanted to say is this is fixed in Network-Kernel-pmm.29 ;-) > > [1] http://code.google.com/p/pharo/issues/detail?id=2292 > > Cheers > Philippe > > > _______________________________________________ > 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] add #next:putAll:startingAt: to SocketStream

by Philippe Marschall

Hi While I was optimizing some Seaside code I found out that SocketStream does not understand #next:putAll:startingAt: [1]. It's quite a helpful method that allows one to write a subcollection of a collection to a stream without making a copy. In our case it would allow the codec to directly write to the socket stream. Anyway what I wanted to say is this is fixed in Network-Kernel-pmm.29 ;-) [1] http://code.google.com/p/pharo/issues/detail?id=2292 Cheers Philippe

April 11, 2010

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

by Schwab,Wilhelm K

Lukas, I'll give you that, but I also think that Windows is going the wrong way. Something simple like browsing a directory full of graphs of data from various experimental runs has become easier (and faster) on Linux than it is on Windows. If Apple could/would run their OS on things like PC/104 hardware, I might have jumped to them years ago. As it is, Linux has been getting better, Windows (IMHO) has been getting steadily more bloated, annoying and buggy, and my long-standing policy of never increasing my dependence on MS has gradually made it feasible for me to move to Linux in a big way. Pharo is no small part of it. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Sunday, April 11, 2010 9:59 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Bye bye pharo on the iPhone > 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 _______________________________________________ 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] Bye bye pharo on the iPhone

by Schwab,Wilhelm K

Sig, I *never* said anything like that. I do think that Microsoft is in decline, and it would not surprise me at all if Apple didn't want to play along with their whims, trying hit a moving target that will cause them to do extra work at the potential expense of their own market share. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Sunday, April 11, 2010 9:43 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Bye bye pharo on the iPhone 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 > 10+ 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. _______________________________________________ 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] Bye bye pharo on the iPhone

by John Toohey

http://www.engadget.com/2010/04/10/steve-jobs-responds-to-complaint-about-n… 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 > -- -JT

April 11, 2010