- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo-project Digest, Vol 29, Issue 57

by Michael Roberts

Hi, i don't know why things are done the way they are... Is your question how the exception mechanism works, or why it is needed to be done with an exception? as opposed to say doing it some other way? The direct answer to your question is that given it is implemented in terms of exceptions, the signal is needed to trigger the defaultAction, or to allow someone higher up in the stack to trap it and redirect the notification. hth cheers, Mike On Fri, Sep 10, 2010 at 4:37 AM, Ralph Boland <rpboland(a)gmail.com> wrote: > I posted the following earlier to the Squeak list but didn't get a responce. > Hopefully someone on the Pharo list can help me. Â I need this information > so I can make some planned changes to the ProgressDisplay package I released > a while back. > > ----------------------------------------------------------------------------------------------------------------- > > A SystemProgressMorph is used to display progress while some computation > is being done. Â Furthermore the progress bars can be stacked to show progress > of component computations within a computation. > This I understand and understand most of the code. > But not All. > What I have trouble with is understanding why a ProgressInitiationException > is needed. Â In particular, String>>displayProgressAt:from:to:during: > does: > > ProgressInitiationException > Â Â Â Â Â Â Â display: self > Â Â Â Â Â Â Â at: aPoint > Â Â Â Â Â Â Â from: minVal > Â Â Â Â Â Â Â to: maxVal > Â Â Â Â Â Â Â during: workBlock. > > > This method sets a few variables and then does: > > Â Â Â ^self signal > > This signal is caught where upon a SystemProgressMorph is started or > extended with > an additional progress bar. > > But I don't understand why sending a signal to a ProgressInitiationException > is needed to get the ball rolling, > > Can someone please explain why things are done the way they are? > > > Regards, > > Ralph Boland > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 10, 2010

Re: [Pharo-project] Pharo-project Digest, Vol 29, Issue 57

by Ralph Boland

I posted the following earlier to the Squeak list but didn't get a responce. Hopefully someone on the Pharo list can help me. I need this information so I can make some planned changes to the ProgressDisplay package I released a while back. ----------------------------------------------------------------------------------------------------------------- A SystemProgressMorph is used to display progress while some computation is being done. Furthermore the progress bars can be stacked to show progress of component computations within a computation. This I understand and understand most of the code. But not All. What I have trouble with is understanding why a ProgressInitiationException is needed. In particular, String>>displayProgressAt:from:to:during: does: ProgressInitiationException display: self at: aPoint from: minVal to: maxVal during: workBlock. This method sets a few variables and then does: ^self signal This signal is caught where upon a SystemProgressMorph is started or extended with an additional progress bar. But I don't understand why sending a signal to a ProgressInitiationException is needed to get the ball rolling, Can someone please explain why things are done the way they are? Regards, Ralph Boland

Sept. 10, 2010

Re: [Pharo-project] Compiling the VM for MacOSX

by John M McIntosh

On 2010-09-09, at 1:01 PM, Alexandre Bergel wrote: > Thanks John for this explanation. > >> Ah, you'll need to explain which VM you built? Also when you build you get to pick between DEBUG and Deployment/Release in OS-X and I assure you the DEBUG version is 10x slower than the non-debug one. > > I downloaded the platforms folder with "svn co http://squeakvm.org/svn/squeak/trunk/platforms/" Ok go to platforms/iOS/vm/ double click on SqueakPureObjc.xcodeproj select the Distribution, SqueakPureObjc execute build *done* Your other choices are SqueakNoOGLIPhone to build the iphone vm SqueakPureObjc64*64 to build a 64 bit vm for use with a 64bit squeak image. The other xcode project SqueakPureObjcCogVM.xcodeproj builds a cog stack VM for the iphone, or a cog JIT VM for os-x in 32bit mode only. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Sept. 9, 2010

Re: [Pharo-project] Feature Request: Strict Compiler / Monticello Mode

by Levente Uzonyi

On Thu, 9 Sep 2010, StÃ©phane Ducasse wrote: >>> Why are you so aggressive against us? >> >> I didn't mean to be aggressive, I just don't think your idea will work well. > > we will see. > >>> Now if you want status quo why do you even commit in squeak? >> >> I'm not against changes. > > So I did not understand. Probably my english. I like to keep stuff backwards compatible as long as it doesn't "cost" too much do it. And I like when my old code works with none or minimal changes in newer systems. > >>> Pharo1.0 is not abandoned at all. Since 1.0 we got more than 1000 bugs closed. >>> The versions are just a way to have milestones. Now there is no problem you think otherwise >> >> So if I have a Pharo 1.0 image with my code and I don't want to rebuild the image, then how can I update it to 1.1? > > - first I cannot reload code for you. > - second you can simply look at Utilities and find the right invocation to get the next update > stream. > > Something like that > Utilities readServer: Utilities serverUrls updatesThrough: nil saveLocally: true updateImage: true. > But you should set the version to 1.1. > > I'm sure that you can easily find how to do it. I tried this in a PharoCore 1.0 image: ScriptLoader currentMajorVersionNumber: 1.1. SystemVersion current version: 'PharoCore1.1ALPHA'. Utilities readServerUpdatesThrough: nil saveLocally: false updateImage: true. But the image freezes (not interruptable by Alt+. (or Cmd+.)). > > Of course in 1.2 this is way nicer > UpdateStreamer new beVerbose; updateFromServer > > Then there are changes like closures that requires a brand new image so you cannot > bash us if you cannot reload you code in another image. Um no. We have several images which were updated from Squeak 3.10 to the current Squeak 4.2 trunk. Levente > Moose people have a lot of packages with a lot of dependencies and code and they moved from 1.0 to 1.1 > without any real problem. Probably a couple of deprecated messages. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 9, 2010

Re: [Pharo-project] Compiling the VM for MacOSX

by Alexandre Bergel

> contact jb.... > JB can you reply? Yep, help needed :-) Alexandre > > > On Sep 9, 2010, at 10:01 PM, Alexandre Bergel wrote: > >> Thanks John for this explanation. >> >>> Ah, you'll need to explain which VM you built? Also when you build you get to pick between DEBUG and Deployment/Release in OS-X and I assure you the DEBUG version is 10x slower than the non-debug one. >> >> I downloaded the platforms folder with "svn co http://squeakvm.org/svn/squeak/trunk/platforms/" >> >> Generating the last version of the VM Source raises some error: >> - findLastOccurranceOfString:startingAt: does not exist. I had to replace it by findLastOccurrenceOfString:startingAt: >> - fixTemps is sent many times. I had to remove the deprecation error message to proceed with the generation >> >> How long time does it take to generate the source? >> My macbook pro has turned itself into a furnace about 30 minutes ago. Pass 18 is indicated, 50% of the progress bar. >> >> John, will you be at esug? >> >> Cheers, >> Alexandre >> >> >>> >>> Now. >>> >>> VMMaker translates a subset of Smalltalk known as Slang to C code. This is the core of the Virtual Machine and processes Smalltalk byte codes it reads from the Squeak Image to perform some obscure task... As Block Closures and Cog JIT work , UTC time, etc, have been added in the last year that has resulted in new versions of VMMaker since we are changing the functionality of the VM. >>> >>> However the VM is decoupled from the issue of the supporting platform, which progresses at a different rate. >>> >>> In order to run the VM on a particular hardware device/software platform the person wanting to port the VM has to follow documentation such as found as http://isqueak.org/PlatformVMAPI to create the platform specific API to enable a user of the device to enter UI input and have the VM produce some form of output (may or may not be visual). >>> >>> The 'Mac OS' folder contains platform code to build a carbon based OS-X system which has it's roots in Apple's OS 7.5.x from 1991. This evolved over the years to support OS-X as an 'OS-X legacy carbon application' and is known as the 3.x series before MacIntel machines, and 4.x after MacIntel with 4.2.5 being the last shipped version. >>> >>> In June of 2008 the ESUG board provided funding to assist in the development of the platform files for the iPhone, further funding granted in October of 2009 enabled us to rebuild a new set of platform files for OS-X and iOS that >>> >>> (a) Bring the macintosh os-x platform support code up to the latest version of API support using Cocoa. >>> (b) Enable the ability of the VM & API to run in 32 bit or 64 bit mode on MacIntel or PowerPC. * >>> (c) Enable the ability to run the VM in 64 bit mode working with a 32 bit image >>> (d) Enable the ability to run the VM in 64 bit mode working with a 64 bit image. >>> (e) Rewrite the Squeak in the Browser api to work with Apple's 64 bit requirements. *Cough* pending... >>> >>> This resulted in the current 5.x series, which support 32bit/64bit VM on os-x against a 32bit or 64bit image, >>> or a 32bit VM with 32bit image on iOS devices. Work from teleplace also offers a 32bit vm in stack or JIT implementation against a 32bit image. >>> >>> *Apple did not supply 64bit versions of the GUI for the PowerPC which makes it impossible to offer a 64bit compiled VM on the PowerPC because one lacks a Graphical User Interface. >>> >>> -- >>> =========================================================================== >>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 >>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>> =========================================================================== >>> >>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 9, 2010

Re: [Pharo-project] Feature Request: Strict Compiler / Monticello Mode

by Tudor Girba

Indeed, we moved Moose from Pharo 1.0 to Pharo 1.1 in a couple of hours, and everything worked out perfectly. The coolest thing was that simply moving from one Pharo to the other basically improved the product performance with about 40% :). So, even from the point of view of a large project, change is not a problem. In fact, it is wanted. Addressing the question of how one should upgrade the code without changing the image ... I will say that at this point I do not want that. I want to be able to load my code in a new image at any time. So, from my point of view, I will upgrade my image by simply loading the code in the new image. Cheers, Doru On 9 Sep 2010, at 22:27, StÃ©phane Ducasse wrote: >>> Why are you so aggressive against us? >> >> I didn't mean to be aggressive, I just don't think your idea will work well. > > we will see. > >>> Now if you want status quo why do you even commit in squeak? >> >> I'm not against changes. > > So I did not understand. Probably my english. > >>> Pharo1.0 is not abandoned at all. Since 1.0 we got more than 1000 bugs closed. >>> The versions are just a way to have milestones. Now there is no problem you think otherwise >> >> So if I have a Pharo 1.0 image with my code and I don't want to rebuild the image, then how can I update it to 1.1? > > - first I cannot reload code for you. > - second you can simply look at Utilities and find the right invocation to get the next update > stream. > > Something like that > Utilities readServer: Utilities serverUrls updatesThrough: nil saveLocally: true updateImage: true. > But you should set the version to 1.1. > > I'm sure that you can easily find how to do it. > > Of course in 1.2 this is way nicer > UpdateStreamer new beVerbose; updateFromServer > > Then there are changes like closures that requires a brand new image so you cannot > bash us if you cannot reload you code in another image. > Moose people have a lot of packages with a lot of dependencies and code and they moved from 1.0 to 1.1 > without any real problem. Probably a couple of deprecated messages. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it."

Sept. 9, 2010

[Pharo-project] [ANN] OPAL Digest

by StÃ©phane Ducasse

hi guys Since Opalers are working hard in the shadow, I thought that I can do a little digest for them. Each time I will delete ten entries I will do a small digest. Thanks marcus, Jorge and JB for their time and energy. Stef PS: OPAL is the new compiler framework we will have in 1.3. Really cool. OPAL comes from the Opal coast near to lille with cool dunes and birds. ==================== Summary ==================== Name: OpalCompiler-Core-MarcusDenker.33 Author: MarcusDenker Time: 9 September 2010, 8:12:20 pm UUID: beb4fce5-38ef-4ff1-ba41-924245ff6456 Ancestors: OpalCompiler-Core-MarcusDenker.32 - cleanups (unsent methods) - make sure to hand over array of copiedTemos to IRBuilder, not Set. final one for today... things start to work. Failing tests down to 24 (from 40). TestCoverage 81% ==================== Summary ==================== Name: OpalCompiler-Tests-MarcusDenker.29 Author: MarcusDenker Time: 9 September 2010, 7:47:08 pm UUID: aa19bd88-0895-4ab8-b55c-3f62f1698e33 Ancestors: OpalCompiler-Tests-MarcusDenker.28 - ASTChecker tests does not use verifyin, but just the ASTChecker - misc changes ==================== Summary ==================== Name: OpalCompiler-Core-MarcusDenker.32 Author: MarcusDenker Time: 9 September 2010, 7:46:21 pm UUID: 845092d2-e58f-441a-9304-43106311e5a1 Ancestors: OpalCompiler-Core-MarcusDenker.31 -> ASTTraslator now requests a tempVector from IRBuilder if needed -> simplified ASTClosureAnalyzer --> moved code to block/method scope -> tempVector now is not a temp anymore, just a copying one if needed -> verifyIn: now calls both visitors. ==================== Summary ==================== Name: OpalCompiler-Core-MarcusDenker.31 Author: MarcusDenker Time: 9 September 2010, 5:49:20 pm UUID: ab2dc77f-71b4-4f82-9cb4-4a2c1261e3fe Ancestors: OpalCompiler-Core-MarcusDenker.30 - simplify a bit re-lookup of variables in OCASTClosureAnalyzer - scopes now have a unique name after ASTChecker pass (this is then used as the name of the vector) ==================== Summary ==================== Name: OpalCompiler-Tests-MarcusDenker.28 Author: MarcusDenker Time: 9 September 2010, 5:49:34 pm UUID: 4821aa22-5ca5-4973-9c18-df0b1bb0297f Ancestors: OpalCompiler-Tests-MarcusDenker.27 more tests... ==================== Summary ==================== Name: OpalCompiler-Tests-MarcusDenker.27 Author: MarcusDenker Time: 9 September 2010, 5:09:43 pm UUID: 49dfe8ab-d8af-4b61-9bcc-066fcf7e5aa0 Ancestors: OpalCompiler-Tests-JorgeRessia.26 fix tests... ==================== Summary ==================== Name: OpalCompiler-Core-MarcusDenker.30 Author: MarcusDenker Time: 9 September 2010, 5:09:27 pm UUID: 2485ef0c-25fe-4863-bd49-fad1aaa0f8bc Ancestors: OpalCompiler-Core-jb.29, OpalCompiler-Core-JorgeRessia.29 more work for scope analysis... -> after variables are re-looked up, add copying temps to outer scop -> Fixes ==================== Summary ==================== Name: OpalCompiler-Tests-JorgeRessia.26 Author: JorgeRessia Time: 7 September 2010, 9:29:08 pm UUID: 4def3fb1-2057-45fe-b7f7-62f057c999fb Ancestors: OpalCompiler-Tests-MarcusDenker.25 - Introduction of optimized block scopes. - the closure analysis is been moved out of the astchecker ==================== Summary ==================== Name: OpalCompiler-Core-JorgeRessia.29 Author: JorgeRessia Time: 7 September 2010, 9:28:46 pm UUID: 02e0a230-43fb-4c08-97f2-a767968faaf8 Ancestors: OpalCompiler-Core-MarcusDenker.28 - Introduction of optimized block scopes. - the closure analysis is been moved out of the astchecker ==================== Summary ==================== Name: OpalCompiler-Core-jb.29 Author: jb Time: 7 September 2010, 11:31:01 am UUID: 06331cc1-732f-4e49-8327-1d6eef92bf26 Ancestors: OpalCompiler-Core-MarcusDenker.28 Fix some bug about Jump in decompiler and clean a bit the code.

Sept. 9, 2010

Re: [Pharo-project] Compiling the VM for MacOSX

by Henrik Sperre Johansen

On 09.09.2010 22:01, Alexandre Bergel wrote: > Thanks John for this explanation. > >> Ah, you'll need to explain which VM you built? Also when you build you get to pick between DEBUG and Deployment/Release in OS-X and I assure you the DEBUG version is 10x slower than the non-debug one. > I downloaded the platforms folder with "svn co http://squeakvm.org/svn/squeak/trunk/platforms/" > > Generating the last version of the VM Source raises some error: > - findLastOccurranceOfString:startingAt: does not exist. I had to replace it by findLastOccurrenceOfString:startingAt: > - fixTemps is sent many times. I had to remove the deprecation error message to proceed with the generation > > How long time does it take to generate the source? > My macbook pro has turned itself into a furnace about 30 minutes ago. Pass 18 is indicated, 50% of the progress bar. > > John, will you be at esug? > > Cheers, > Alexandre Search the vm-dev list (or this one) to find solutions to these issues when using VMMaker in a Pharo image. Cheers, Henry

Sept. 9, 2010

Re: [Pharo-project] Compiling the VM for MacOSX

by Alexandre Bergel

Thanks John for this explanation. > Ah, you'll need to explain which VM you built? Also when you build you get to pick between DEBUG and Deployment/Release in OS-X and I assure you the DEBUG version is 10x slower than the non-debug one. I downloaded the platforms folder with "svn co http://squeakvm.org/svn/squeak/trunk/platforms/" Generating the last version of the VM Source raises some error: - findLastOccurranceOfString:startingAt: does not exist. I had to replace it by findLastOccurrenceOfString:startingAt: - fixTemps is sent many times. I had to remove the deprecation error message to proceed with the generation How long time does it take to generate the source? My macbook pro has turned itself into a furnace about 30 minutes ago. Pass 18 is indicated, 50% of the progress bar. John, will you be at esug? Cheers, Alexandre > > Now. > > VMMaker translates a subset of Smalltalk known as Slang to C code. This is the core of the Virtual Machine and processes Smalltalk byte codes it reads from the Squeak Image to perform some obscure task... As Block Closures and Cog JIT work , UTC time, etc, have been added in the last year that has resulted in new versions of VMMaker since we are changing the functionality of the VM. > > However the VM is decoupled from the issue of the supporting platform, which progresses at a different rate. > > In order to run the VM on a particular hardware device/software platform the person wanting to port the VM has to follow documentation such as found as http://isqueak.org/PlatformVMAPI to create the platform specific API to enable a user of the device to enter UI input and have the VM produce some form of output (may or may not be visual). > > The 'Mac OS' folder contains platform code to build a carbon based OS-X system which has it's roots in Apple's OS 7.5.x from 1991. This evolved over the years to support OS-X as an 'OS-X legacy carbon application' and is known as the 3.x series before MacIntel machines, and 4.x after MacIntel with 4.2.5 being the last shipped version. > > In June of 2008 the ESUG board provided funding to assist in the development of the platform files for the iPhone, further funding granted in October of 2009 enabled us to rebuild a new set of platform files for OS-X and iOS that > > (a) Bring the macintosh os-x platform support code up to the latest version of API support using Cocoa. > (b) Enable the ability of the VM & API to run in 32 bit or 64 bit mode on MacIntel or PowerPC. * > (c) Enable the ability to run the VM in 64 bit mode working with a 32 bit image > (d) Enable the ability to run the VM in 64 bit mode working with a 64 bit image. > (e) Rewrite the Squeak in the Browser api to work with Apple's 64 bit requirements. *Cough* pending... > > This resulted in the current 5.x series, which support 32bit/64bit VM on os-x against a 32bit or 64bit image, > or a 32bit VM with 32bit image on iOS devices. Work from teleplace also offers a 32bit vm in stack or JIT implementation against a 32bit image. > > *Apple did not supply 64bit versions of the GUI for the PowerPC which makes it impossible to offer a 64bit compiled VM on the PowerPC because one lacks a Graphical User Interface. > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 9, 2010

[Pharo-project] [update 1.2] #12131

by StÃ©phane Ducasse

12131 ----- - Issue 2936: DateAndTimeTest has failures. Thanks Pavel Krivanek. - Issue 2937: TimespanTest >> testEnd failing. Thanks Pavel Krivanek. - Issue 2929: remove #tiny, #tinyDisplay and the class var Tiny. - Issue 2499: MaskedTextMorph class for masked input fields. Thanks Dionisiygod. Stef

Sept. 9, 2010