Re: [Pharo-project] [squeak-dev] Re: SqueakSource is unusable
On 11 April 2010 00:18, stephane ducasse stephane.duca...@gmail.com wrote: thanks. My thanks too. It is just GREAT improvement! Keep moving guys! :) -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11311
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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Graphics-MichaelRueger.168....backported normalized transform
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Context reflection regression?
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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Context reflection regression?
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 siguc...@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Context reflection regression?
On 11 April 2010 12:41, Lukas Renggli reng...@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 ContextPartjump and ContextPartrestart 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 siguc...@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Graphics-MichaelRueger.168....backported normalized transform
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Bye bye pharo on the iPhone
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-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Lawson English Sent: Saturday, April 10, 2010 5:36 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Bye bye pharo on the iPhone Igor Stasenko wrote: 2010/4/10 John M McIntosh john...@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Bye bye pharo on the iPhone
On 11 April 2010 17:29, Schwab,Wilhelm K bsch...@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-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Lawson English Sent: Saturday, April 10, 2010 5:36 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Bye bye pharo on the iPhone Igor Stasenko wrote: 2010/4/10 John M McIntosh john...@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Bye bye pharo on the iPhone
On 11 April 2010 17:42, Igor Stasenko siguc...@gmail.com wrote: On 11 April 2010 17:29, Schwab,Wilhelm K bsch...@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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Bye bye pharo on the iPhone
On 11 April 2010 17:59, Lukas Renggli reng...@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] WeakSet but no WeakIdentitySet?
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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] A port of Pharo: Redline Smalltalk ...
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.duca...@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.duca...@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 epic...@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.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] A port of Pharo: Redline Smalltalk ...
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.duca...@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.duca...@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 epic...@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.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Bye bye pharo on the iPhone
http://www.engadget.com/2010/04/10/steve-jobs-responds-to-complaint-about-new-development-tool-rest/ 2010/4/10 Ramiro Diaz Trepat ram...@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- -JT ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Bye bye pharo on the iPhone
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-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Sunday, April 11, 2010 9:43 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Bye bye pharo on the iPhone On 11 April 2010 17:29, Schwab,Wilhelm K bsch...@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-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Lawson English Sent: Saturday, April 10, 2010 5:36 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Bye bye pharo on the iPhone Igor Stasenko wrote: 2010/4/10 John M McIntosh john...@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Bye bye pharo on the iPhone
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-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Sunday, April 11, 2010 9:59 AM To: Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] add #next:putAll:startingAt: to SocketStream
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] add #next:putAll:startingAt: to SocketStream
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Bye bye pharo on the iPhone
On 11 April 2010 19:53, Schwab,Wilhelm K bsch...@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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Open Pharo debugger from a Seaside wallback
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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] add #next:putAll:startingAt: to SocketStream
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] add #next:putAll:startingAt: to SocketStream
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] A port of Pharo: Redline Smalltalk ...
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.duca...@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.duca...@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 epic...@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.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11312
11312 - - Issue 2292: add #next:putAll:startingAt: to SocketStream. Thanks pmm - http://code.google.com/p/pharo/issues/detail?id=2292 - Issue 1011: Monticello snapshot browser does not display class side definitions. Thanks lukas. - Fix Code recovery menu: thanks alain - Issue 1908: beginsWithAnyOf: / endsWithAnyOf: stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Open Pharo debugger from a Seaside wallback
This seems to be a known problem: http://permalink.gmane.org/gmane.comp.lang.smalltalk.squeak.seaside/20959 Lukas 2010/4/11 Facundo Vozzi facundo...@gmail.com: 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. ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Open Pharo debugger from a Seaside wallback
Yes, it's seems to be that issue but its solution didn't repair my problem. I think that the problem is relationated with a network configuration issue so i will continue trying in that way. Thank you Lukas. Facundo On Sun, Apr 11, 2010 at 5:24 PM, Lukas Renggli reng...@gmail.com wrote: This seems to be a known problem: http://permalink.gmane.org/gmane.comp.lang.smalltalk.squeak.seaside/20959 Lukas 2010/4/11 Facundo Vozzi facundo...@gmail.com: 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. ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Facundo Vozzi InfOil S.A. Project Leader (+54-11) 4542- x108 fvo...@infoil.com.ar ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] news about 1.0
Hi guys mariano, marcus and adrian got some push to get 1.0 out. I was just on cc: I think that we made a mistake not to roll that publicly via the mailing-list (we will do that for 1.1). Now this is holidays time here, mariano is going to get married and adrian just moved so no internet connection. Tomorrow I will sync with marcus to know if I can help to get this 1.0 version out. If I remember the mails I saw, marcus was looking for the BitBltPluging binaries for the one click image on other platforms than mac os. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
Hi levente/igor this hashedCollection is still on my radar. Now I was wondering if I should work first on Set with nil or HashedCollection. Any idea/suggestion? Stef On Mar 14, 2010, at 7:02 PM, Levente Uzonyi wrote: On Sun, 14 Mar 2010, stephane ducasse wrote: Hi levente and others I always wanted to have Dictionary not be a subclass of Set and you did it. Now when you introduced that in Squeak, we were busy. But now I'm so found of this change (like other Smalltalk - SmalltalkImage current --- which we stopped in the middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. Do you have any specific recommandations (like not shooting in our own foot)? IIRC this is what I did: - created a copy of Set named HashedCollection - changed it's category to Collections-Abstract - changed Set's superclass to HashedCollection while removed it's instance variables - removed Set specific methods from HashedCollection - copied Dictionary specific methods from Set to Dictionary - changed Dictionary's superclass to HashedCollection - removed Dictionary specific methods from Set - cleaup (code that assumes that Dictionary is a Set may be everywhere in the image, for example: Set rehashAllSets won't rehash Dictionaries now, etc) But if you change these classes now, you'll have to update Andrés' changes. That's why I told you earlier to add those changes before touching anything else in the Set hierarchy. The weak dictionary related parts have to be updated already. Levente Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] VM team update
Folks, We are in the midst of a flurry of activity to update the virtual machines for Mac, Windows and Unix in support of upcoming Squeak and Pharo releases. These VMs all will include Eliot Miranda's block closure support, as well as a large number of updates, bug fixes, and enhancements. There have been many significant updates to all of the major platforms, and I will not attempt to do justice to all of these. That said, the revision logs for the VMMaker package provide an overview of many of the changes, so I am attaching an update log below. It is worth noting here that John McIntosh has announced a new code base for Mac VMs (in addition to his iPhone VM work) with expanded 64-bit support. This will be the basis for future Mac VM releases following the current round of updates. Following is a change log of the VMMaker package updates, starting with current version, and going back to the introduction of block closure support in early 2009. - Dave --- Name: VMMaker-dtl.169 Author: dtl Time: 10 April 2010, 3:43:27.612 pm Ancestors: VMMaker-ar.168 VMMaker 4.0.3 Add version identification primitives - primitiveInterpreterSourceVersion answers the version of VMMaker that was used to generate the VM source code. This is a string like '4.0.3'. - primitivePlatformSourceVersion answers the Subversion version level if $PLATFORM_SOURCE_VERSION has been defined, or fails otherwise. This should be a string like '2172'. - primitiveVMVersion answers an identifier for the VM version (VMMaker plus Subversion) if $VM_VERSION is defined, or fails otherwise. For the Unix VMs, this is a string like '4.0.3-2172'. - primitiveImageFormatVersion answers an integer identifier for the image format. This is the number that is stored in the image file header to identify image fomat (32/64 bit word size, block closure support). Rename some code generation methods from #writeXXX to #emitXXX for consistency with other method naming. Fix VMMaker file list processing to ignore Subversion administrative files (previously only CVS files were ignored). --- Name: VMMaker-ar.168 Author: ar Time: 31 March 2010, 9:46:52 am Ancestors: VMMaker-ar.167 Bump VMMaker version to 4.0.2. --- Name: VMMaker-ar.167 Author: ar Time: 31 March 2010, 9:44:42 am Ancestors: VMMaker-JMM.166 Fix SoundPluginprimSoundRecordSamplesInto again. Performs subtraction in the primitive, calls external code with the offset ALWAYS set to zero. Should be rationalized by removing the arg from the support code call. --- Name: VMMaker-JMM.166 Author: JMM Time: 28 March 2010, 4:57:23 pm Ancestors: VMMaker-dtl.119, VMMaker-dtl.122, VMMaker-dtl.135, VMMaker-dtl.139, VMMaker-dtl.153, VMMaker-dtl.156, VMMaker-ar.160, VMMaker-ar.165, VMMaker-dtl.165 Merge some 64bit fixes primitiveAsyncFileOpen: filename is not an (int) address on 64bit systems MIDIPlugin portName is not an int RePluginrecvrExtraPtr 64bits NULL is not int JPEGReadWriter2Plugin not 64bit clean primJPEGReadImage: primJPEGWriteImage: primitiveShowHostWindow: dispBits is unsigned char* Interpreter Ensure microsecond clock is 64bit statGCTime,statFullGCMSecs,statIGCDeltaTime,statIncrGCMSecs are all sqLong startTime,statGCTime as sqLong primitiveVMParameter has microsecond clock times 64bit readImageFromFile: 32 clean desiredHeapSize is unsigned --- Name: VMMaker-dtl.165 Author: dtl Time: 28 March 2010, 6:54:54 pm Ancestors: VMMaker-dtl.164 Fix declaration of readImageFromFile:HeapSize:StartingAt: as per John's note at http://lists.squeakfoundation.org/pipermail/vm-dev/2010-January/003614.html --- Name: VMMaker-dtl.164 Author: dtl Time: 28 March 2010, 1:44:25 pm Ancestors: VMMaker-eem.163 VMMaker 4.0.1 Reference Mantis 7458: [Vm-dev] microsecond timing for GC work Add primitiveMicrosecondClock and microsecond GC instrumentation by John McIntosh. Add primitiveUtcWithOffset. Fix signature of InterpreterdumpImage: (pointer declared as int). The new primitives require support in the platform code. Default implementations are provided to allow compilation without these platforms updates, see CCodeGeneratorwriteDefaultMacrosOn:. Without platform updates, the GC instrumentation falls back to millisecond precision, the primitiveMicrosecondClock primitive answers (incorrectly) a millisecond value, and primitiveUtcWithOffset fails the primitive. --- Name: VMMaker-eem.163 Author: eem Time: 22 March 2010, 5:15:57 pm Ancestors: VMMaker-ar.162 SoundPlugin: fix bounds bug in primitiveSoundRecordSamples. The call to snd_RecordSamplesIntoAtLength neglected to subtract the start index from the size of the buffer to be written into. --- Name: VMMaker-ar.162 Author: ar Time: 15 March 2010, 4:02:31 am Ancestors: VMMaker-dtl.161 Fix loading of image segments that are from older, but compatible image versions. --- Name: VMMaker-dtl.161 Author: dtl Time: 14 March 2010, 9:19:53 am Ancestors: VMMaker-ar.160 VMMaker 4.0.0 Change #versionString from 3.x.x to
Re: [Pharo-project] Open Pharo debugger from a Seaside wallback
I don't have windows, so I cannot help. It would be cool if some Windows/Firefox user could figure out a permanent solution for our side, as this problem keeps on reappearing. Luas 2010/4/11 Facundo Vozzi facundo...@gmail.com: Yes, it's seems to be that issue but its solution didn't repair my problem. I think that the problem is relationated with a network configuration issue so i will continue trying in that way. Thank you Lukas. Facundo On Sun, Apr 11, 2010 at 5:24 PM, Lukas Renggli reng...@gmail.com wrote: This seems to be a known problem: http://permalink.gmane.org/gmane.comp.lang.smalltalk.squeak.seaside/20959 Lukas 2010/4/11 Facundo Vozzi facundo...@gmail.com: 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. ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Facundo Vozzi InfOil S.A. Project Leader (+54-11) 4542- x108 fvo...@infoil.com.ar ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
On 12 April 2010 00:29, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi levente/igor this hashedCollection is still on my radar. Now I was wondering if I should work first on Set with nil or HashedCollection. Any idea/suggestion? HashedCollection is more important/basic refactoring than nils in sets. So, adopt them first. Stef On Mar 14, 2010, at 7:02 PM, Levente Uzonyi wrote: On Sun, 14 Mar 2010, stephane ducasse wrote: Hi levente and others I always wanted to have Dictionary not be a subclass of Set and you did it. Now when you introduced that in Squeak, we were busy. But now I'm so found of this change (like other Smalltalk - SmalltalkImage current --- which we stopped in the middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. Do you have any specific recommandations (like not shooting in our own foot)? IIRC this is what I did: - created a copy of Set named HashedCollection - changed it's category to Collections-Abstract - changed Set's superclass to HashedCollection while removed it's instance variables - removed Set specific methods from HashedCollection - copied Dictionary specific methods from Set to Dictionary - changed Dictionary's superclass to HashedCollection - removed Dictionary specific methods from Set - cleaup (code that assumes that Dictionary is a Set may be everywhere in the image, for example: Set rehashAllSets won't rehash Dictionaries now, etc) But if you change these classes now, you'll have to update Andrés' changes. That's why I told you earlier to add those changes before touching anything else in the Set hierarchy. The weak dictionary related parts have to be updated already. Levente Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
On Sun, 11 Apr 2010, Stéphane Ducasse wrote: Hi levente/igor this hashedCollection is still on my radar. Now I was wondering if I should work first on Set with nil or HashedCollection. Any idea/suggestion? I think it's easier to add HashedCollection first, then the nil support for Set, because this way you can be sure that the changes added to Set (for the nil support) won't affect Dictionary. Levente Stef On Mar 14, 2010, at 7:02 PM, Levente Uzonyi wrote: On Sun, 14 Mar 2010, stephane ducasse wrote: Hi levente and others I always wanted to have Dictionary not be a subclass of Set and you did it. Now when you introduced that in Squeak, we were busy. But now I'm so found of this change (like other Smalltalk - SmalltalkImage current --- which we stopped in the middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. Do you have any specific recommandations (like not shooting in our own foot)? IIRC this is what I did: - created a copy of Set named HashedCollection - changed it's category to Collections-Abstract - changed Set's superclass to HashedCollection while removed it's instance variables - removed Set specific methods from HashedCollection - copied Dictionary specific methods from Set to Dictionary - changed Dictionary's superclass to HashedCollection - removed Dictionary specific methods from Set - cleaup (code that assumes that Dictionary is a Set may be everywhere in the image, for example: Set rehashAllSets won't rehash Dictionaries now, etc) But if you change these classes now, you'll have to update Andrés' changes. That's why I told you earlier to add those changes before touching anything else in the Set hierarchy. The weak dictionary related parts have to be updated already. Levente Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
Ok I will do that. Stef On Apr 11, 2010, at 11:39 PM, Igor Stasenko wrote: On 12 April 2010 00:29, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi levente/igor this hashedCollection is still on my radar. Now I was wondering if I should work first on Set with nil or HashedCollection. Any idea/suggestion? HashedCollection is more important/basic refactoring than nils in sets. So, adopt them first. Stef On Mar 14, 2010, at 7:02 PM, Levente Uzonyi wrote: On Sun, 14 Mar 2010, stephane ducasse wrote: Hi levente and others I always wanted to have Dictionary not be a subclass of Set and you did it. Now when you introduced that in Squeak, we were busy. But now I'm so found of this change (like other Smalltalk - SmalltalkImage current --- which we stopped in the middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. Do you have any specific recommandations (like not shooting in our own foot)? IIRC this is what I did: - created a copy of Set named HashedCollection - changed it's category to Collections-Abstract - changed Set's superclass to HashedCollection while removed it's instance variables - removed Set specific methods from HashedCollection - copied Dictionary specific methods from Set to Dictionary - changed Dictionary's superclass to HashedCollection - removed Dictionary specific methods from Set - cleaup (code that assumes that Dictionary is a Set may be everywhere in the image, for example: Set rehashAllSets won't rehash Dictionaries now, etc) But if you change these classes now, you'll have to update Andrés' changes. That's why I told you earlier to add those changes before touching anything else in the Set hierarchy. The weak dictionary related parts have to be updated already. Levente Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
Yes! So I will follow your steps as soon as I have a bit of time. Stef On Apr 11, 2010, at 11:48 PM, Levente Uzonyi wrote: On Sun, 11 Apr 2010, Stéphane Ducasse wrote: Hi levente/igor this hashedCollection is still on my radar. Now I was wondering if I should work first on Set with nil or HashedCollection. Any idea/suggestion? I think it's easier to add HashedCollection first, then the nil support for Set, because this way you can be sure that the changes added to Set (for the nil support) won't affect Dictionary. Levente Stef On Mar 14, 2010, at 7:02 PM, Levente Uzonyi wrote: On Sun, 14 Mar 2010, stephane ducasse wrote: Hi levente and others I always wanted to have Dictionary not be a subclass of Set and you did it. Now when you introduced that in Squeak, we were busy. But now I'm so found of this change (like other Smalltalk - SmalltalkImage current --- which we stopped in the middle because lack of momentum and mindsharing) that I would like to integrate it into Pharo. Do you have any specific recommandations (like not shooting in our own foot)? IIRC this is what I did: - created a copy of Set named HashedCollection - changed it's category to Collections-Abstract - changed Set's superclass to HashedCollection while removed it's instance variables - removed Set specific methods from HashedCollection - copied Dictionary specific methods from Set to Dictionary - changed Dictionary's superclass to HashedCollection - removed Dictionary specific methods from Set - cleaup (code that assumes that Dictionary is a Set may be everywhere in the image, for example: Set rehashAllSets won't rehash Dictionaries now, etc) But if you change these classes now, you'll have to update Andrés' changes. That's why I told you earlier to add those changes before touching anything else in the Set hierarchy. The weak dictionary related parts have to be updated already. Levente Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] fixing underscores in a trivial manner thanks to SmalllintChecker and Lukas!
Hi all, i just wanted to re post the fix underscore code Lukas posted a while
ago.
I've just imported Connectors package into pharo, (i'm trying to get a minimal
version working ), and stumbled upon the problem of the underscores..
but now thanks to SmallInt rules it was easy and fast to overcome this problem!
Thanks
Fernando
pd: From previous mail from lukas.
1. Load the code:
Gofer new
squeaksource: 'rb';
package: 'AST-Core';
package: 'Refactoring-Core';
load.
2. Select the code (packages) you want to fix:
environment := BrowserEnvironment new
forPackageNames: #('Connectors-Base' 'Connectors-Lines and Curves').
3. Create the transformation rule:
rule := RBUnderscoreAssignmentRule new.
4. Perform the search:
SmalllintChecker runRule: rule onEnvironment: environment.
5. Perform the transformation:
change := CompositeRefactoryChange new.
change changes: rule changes.
change execute
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] WeakSet but no WeakIdentitySet?
On Sun, 11 Apr 2010, Igor Stasenko wrote: 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... We can add it to 4.2. Levente 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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
Hi levente/igor this hashedCollection is still on my radar. Now I was wondering if I should work first on Set with nil or HashedCollection. Any idea/suggestion? Stef I think moving Dictionary out from under Set is a great idea. However I am not convinced having a class HashedCollection to share common code between Set and Dictionary is worth it. I would just tolerate the code duplication because these classes are so important. Given that Squeak is going to support HashedCollection though, I would hate to see yet another difference between Pharo and Squeak. I expect that the difference is unlikely to break code shared between Pharo and Squeak though. I was always against allowing the addition of nil to sets. This change means that every time I accidentally add nil to a set the error will go undetected and will be difficult to track down once the problem is discovered. My solution to escape this change in my code will be to subclass Set and any of its subclasses that I use and add code in the subclasses to test for addition of nil and report an error when it happens. This will allow bugs to show up sooner. An alternative is just to modify Set itself by adding a test for adding nil to a set and then reporting an error. This change will break down of course once there are instances of actually adding nil to a set in Squeak/Pharo. Are there any such occurrences is Squeak 4.1? Now that this feature will be in Squeak 4.1, however, we again have the problem of divergence of code between Pharo and Squeak. The problem won't be there immediately but eventually this feature will actually be used in Squeak. Of course the issue here is how often it is useful to allow addition of nil to a Set. For the approximately 100,000 lines of code I have written in Smalltalk the answer is 0 explaining my opposition to this change. For some others though the answer must be different. For me this change will delay my moving my code from Squeak 3.10 to 4.1+ (and might even tempt me to move to Pharo :-)). Note that I use Sets and Dictionaries a lot. When my Squeak project runs 80% of the time is spent on Set/Dictionary operations. Regards, Ralph Boland ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About getting HashedCollection (another dream happening)
On Sun, 11 Apr 2010, Ralph Boland wrote: Hi levente/igor this hashedCollection is still on my radar. Now I was wondering if I should work first on Set with nil or HashedCollection. Any idea/suggestion? Stef I think moving Dictionary out from under Set is a great idea. However I am not convinced having a class HashedCollection to share common code between Set and Dictionary is worth it. I would just tolerate the code duplication because these classes are so important. Given that Squeak is going to support I don't see your point here. In Squeak that would mean duplicating 17 + 9 methods (instance/class side) + the two instance variables for no reason. HashedCollection though, I would hate to see yet another difference between Pharo and Squeak. I expect that the difference is unlikely to break code shared between Pharo and Squeak though. I was always against allowing the addition of nil to sets. This change means that every time I accidentally add nil to a set the error will go undetected and will be difficult to track down once the problem is discovered. Collections are still not ment to be bug detectors... Btw, do you notice if you add nil as a key to a Dictionary? (or add nil to an OrderedCollection?) My solution to escape this change in my code will be to subclass Set and any of its subclasses that I use and add code in the subclasses to test for addition of nil and report an error when it happens. This will allow bugs to show up sooner. You can (ab)use PluggableSet if you really need this by adding the nil check to the hashBlock. An alternative is just to modify Set itself by adding a test for adding nil to a set and then reporting an error. This change will break down of course once there are instances of actually adding nil to a set in Squeak/Pharo. Are there any such occurrences is Squeak 4.1? Who knows, nil can be everywhere: #(1 2 nil) asSet. Now that this feature will be in Squeak 4.1, however, we again have the problem of divergence of code between Pharo and Squeak. The problem won't be there immediately but eventually this feature will actually be used in Squeak. Of course the issue here is how often it is useful to allow addition of nil to a Set. For the approximately 100,000 lines of code I have written in Smalltalk the answer is 0 explaining my opposition to this change. For some others though the answer must be different. For me this change will delay my moving my code from Squeak 3.10 to 4.1+ (and might even tempt me to move to Pharo :-)). Note that I use Sets and Dictionaries a lot. When my Squeak project runs 80% of the time is spent on Set/Dictionary operations. You could have added nil as a key to a Dictionary and that went undetected... Levente Regards, Ralph Boland ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
