Re: [Pharo-project] Pharo-project Digest, Vol 29, Issue 57
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Compiling the VM for MacOSX
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. McIntoshTwitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === smime.p7s Description: S/MIME cryptographic signature ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Feature Request: Strict Compiler / Monticello Mode
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@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] Compiling the VM for MacOSX
> 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. McIntoshTwitter: squeaker68882 >>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>> === >>> >>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> ___ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Feature Request: Strict Compiler / Monticello Mode
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@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." ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [ANN] OPAL Digest
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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Compiling the VM for MacOSX
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Compiling the VM for MacOSX
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. McIntoshTwitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > === > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ 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.2] #12131
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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Feature Request: Strict Compiler / Monticello Mode
>> 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] TimespanTest >> testEnd failing
Thanks! This is nice to get some help from the tests. Integrated in the next batch. Stef On Sep 9, 2010, at 8:43 PM, Pavel Krivanek wrote: > http://code.google.com/p/pharo/issues/detail?id=2937 > > ___ > 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] Feature Request: Strict Compiler / Monticello Mode
El jue, 09-09-2010 a las 21:02 +0200, Levente Uzonyi escribió: > 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. > > > Now if you want status quo why do you even commit in squeak? > > I'm not against changes. > > > Now I'm not sure that this is the kind of > > I think the end of the sentence got lost somewhere. > > > > Isn't Grease dialect dependent by essence ? > If Pharo and Squeak diverge, then there will naturally be two versions > of Grease... > However, for these two messages, I think Pharo core should integrate > them and align with Squeak. The question is more whether you need to > distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ... > >>> > >>> Probably else this means that Pharo and any system is bound to die because > >>> it does not change. > >> > >> The rapid changes and no-backwards-compatibility you prefer and advocate > >> are not essential for a Smalltalk system to "stay alive". Just look at > >> VSE, it didn't change in the last 10 years, and people are still using it. > >> In constrast Pharo 1.0 was considered abandonware four months after it's > >> release, which caused trouble for some users who didn't think that they'll > >> have to patch their code and rebuild their images to "get" updates/fixes. > > > > 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? You change the source for downloading updates from. Then in a workspace you fire up the updateFromServer code and voilá. This will apply the same patches that were applied to 1.0 since the freeze to reach the point where 1.1 is. Just the same as squeak. But given the multiple ways in that 1.1 is different that 1.0, if you do this in a production image of yours very likely your image will blow, because there won't be code that was in 1.0 and isn't in 1.1. That is the main reason that isn't a supported option. If enabled somehow (menu, code snippet, some wiki page instruction) a lot of users will blindly update a working image leaving them with a unfunctional one. As we don't have the time or the people to support incountable questions about why this happend, the best it to advise the users to put the code in monticello (a good thing, no matter the arguments about the monolithic, time-evolved image) and load their code in a new downloaded 1.1 image. If every works correctly then they can be sure that their package works on the new version. If not, well, they have still a running stable working image and can spend time making its package work in the new image. But this is effort for the user. No matter how good the developers of Pharo are, there is no possible way to guarantee that the update process will be flawless for every user and for each but the simplest cases. Cheers > > > 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 -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Feature Request: Strict Compiler / Monticello Mode
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. Now if you want status quo why do you even commit in squeak? I'm not against changes. Now I'm not sure that this is the kind of I think the end of the sentence got lost somewhere. Isn't Grease dialect dependent by essence ? If Pharo and Squeak diverge, then there will naturally be two versions of Grease... However, for these two messages, I think Pharo core should integrate them and align with Squeak. The question is more whether you need to distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ... Probably else this means that Pharo and any system is bound to die because it does not change. The rapid changes and no-backwards-compatibility you prefer and advocate are not essential for a Smalltalk system to "stay alive". Just look at VSE, it didn't change in the last 10 years, and people are still using it. In constrast Pharo 1.0 was considered abandonware four months after it's release, which caused trouble for some users who didn't think that they'll have to patch their code and rebuild their images to "get" updates/fixes. 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? 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
Re: [Pharo-project] DateAndTimeTest failures
On Sep 9, 2010, at 8:28 PM, Pavel Krivanek wrote: > On Thu, Sep 9, 2010 at 7:25 PM, Stéphane Ducasse > wrote: >> Thanks Pavel >> >> I have been thinking a lot about you recently. >> I started to create a lot of bug entries remodularisation (and I got trapped >> by time >> - today an obligatory meeting starting a 12h on account certification :) and >> ended up at 17h :) >> >> I will continue and I saw to nicolas and gabriel how they can help going >> over your issues and the new ones >> I'm creating. > > Don't worry, I'm still discovering new ones :-) Me too :) I'm confident that it will keep us busy. > > -- Pavel > >> >> On Sep 9, 2010, at 6:30 PM, Pavel Krivanek wrote: >> >>> Hi, >>> >>> I tried to fix DateAndTimeTest failures, see >>> http://code.google.com/p/pharo/issues/detail?id=2936 >>> >>> The patch adds methods clearOffset and withoutOffset to DateAndTime. >>> >>> Cheers, >>> -- Pavel >>> >>> ___ >>> 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] TimespanTest >> testEnd failing
http://code.google.com/p/pharo/issues/detail?id=2937 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] DateAndTimeTest failures
On Thu, Sep 9, 2010 at 7:25 PM, Stéphane Ducasse wrote: > Thanks Pavel > > I have been thinking a lot about you recently. > I started to create a lot of bug entries remodularisation (and I got trapped > by time > - today an obligatory meeting starting a 12h on account certification :) and > ended up at 17h :) > > I will continue and I saw to nicolas and gabriel how they can help going over > your issues and the new ones > I'm creating. Don't worry, I'm still discovering new ones :-) -- Pavel > > On Sep 9, 2010, at 6:30 PM, Pavel Krivanek wrote: > >> Hi, >> >> I tried to fix DateAndTimeTest failures, see >> http://code.google.com/p/pharo/issues/detail?id=2936 >> >> The patch adds methods clearOffset and withoutOffset to DateAndTime. >> >> Cheers, >> -- Pavel >> >> ___ >> 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] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b10
Thanks John Stef > I've stuck a version (5.8b10) of the cocoa based os-x squeak cog JIT based VM > in my experimental folder. > > http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b10.app.zip > > Changes are: > > (a) Fix issue with timezone calculation on file creation and modification > timestamps. > (b) Fix a crash with sqInt ioSetCursor() which calls ioSetCursorWithMask() > with a NULL mask value which it did not handle correctly. > > Based on feedback I wil produce a non-cog VM 5.7x and push that as the > approved for regular use os-x/iOS VM on the weekend. > > -- > === > John M. McIntoshTwitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.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] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b10
I've stuck a version (5.8b10) of the cocoa based os-x squeak cog JIT based VM in my experimental folder. http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b10.app.zip Changes are: (a) Fix issue with timezone calculation on file creation and modification timestamps. (b) Fix a crash with sqInt ioSetCursor() which calls ioSetCursorWithMask() with a NULL mask value which it did not handle correctly. Based on feedback I wil produce a non-cog VM 5.7x and push that as the approved for regular use os-x/iOS VM on the weekend. -- === John M. McIntoshTwitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === smime.p7s Description: S/MIME cryptographic signature ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Cog Segmentation Fault with Pharo 1.1
why should add some guards in the tests for that even if ObjectAsMethods is a cool feature to have for experimentation. There are some changes from squeak pending in the bug tracker. Now you should also pay that the coverage button is using wrapper and I guess also use test coverage. Stef > Hi: > > I was playing a bit with a stock Pharo 1.1 image, with the only adding > of the cs NecessaryImageChangesForCogToWork.Pharo1.1. > > Then I tried to run TestRunner new runAll (for comparing times against > the common vm) and get the attached segfault. > > I tried with my own compiled cog and also with the downloaded from > here http://www.mirandabanda.org/files/Cog/VM/VM.r2219/. > > My OS is Ubuntu 10.04 64 bits. > > Any hint will be appreciated. > > Cheers. > > -- > = > Germán S. Arduino Twitter: garduino > Arduino Software & Web Hosting http://www.arduinosoftware.com > PasswordsPro http://www.passwordspro.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
Re: [Pharo-project] Building Cocoa 5.x series plugins, and testing help needed.
On 2010-09-09, at 8:21 AM, Philippe Marschall wrote: >> There is also issues withe currency symbol, the logic assumes it's one byte, >> but it could be a unicode value >> if you decide between the international symbol versus localized regional >> symbol. I think the plugin is flawed >> in that respect. > > Answers 'SFr.' where quite nicely. > > Cheers > Philippe Ok I've placed a LocalePlugin 2.1b1.bundle.zip on the server. It has a minor fix where I did the length calculation in UTF8 then asked for the data in MacRoman. Must not write email when tired. It's the currency decimal and grouping separators that are fixed as 1 byte. Also currency uses the international symbol(s) in UTF8 versus the regional value which might be different and at some different point in the unicode chart. -- === John M. McIntoshTwitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === smime.p7s Description: S/MIME cryptographic signature ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] CompiledMethod
Hi Benjamin. Yes, this is a known "problem". Check http://forum.world.st/problem-with-CompiledMethod-equality-tt2221276.html#a2221276 2010/9/9 Eliot Miranda > > > 2010/9/9 Benjamin Van Ryseghem > > Hi everybody, >> >> >> I wonder if it's normal than two different methods can have the same >> CompiledMethod ? >> >> By example : >> >> Class >> foo >> 'foo' >> >> and >> >> Class >> foo2 >> 'foo' >> >> If I evaluate (Class methodDict at: #foo) = (Class methodDict at: #foo2), >> it answers true. >> >> Maybe the CompiledMethod >> = should test the source ? >> > > There are many definitions of method equality. If you ant to test the > source you can test the source, (C >> #foo) getSourceFromFile asString = (C > >> #foo2) getSourceFromFile asString. You can test the decompilation of a > method (C>>#foo) decompileString = (C>>#foo2) decompileString. > > The current definition tests whether the bytecodes and literals are the > same, not the selector or the source code. That's a useful definition, but > not the only one. It is close to the decompile version but faster, and is > useful in e.g. testing whether the compiler has changed, since if on > recompiling a method is still = the compiler is producing the same bytecode > for a compilation. That's what I use it for and it's an important use. > > cheers > Eliot > > >> >> >> Ben >> >> ___ >> 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] DateAndTimeTest failures
Thanks Pavel I have been thinking a lot about you recently. I started to create a lot of bug entries remodularisation (and I got trapped by time - today an obligatory meeting starting a 12h on account certification :) and ended up at 17h :) I will continue and I saw to nicolas and gabriel how they can help going over your issues and the new ones I'm creating. Stef On Sep 9, 2010, at 6:30 PM, Pavel Krivanek wrote: > Hi, > > I tried to fix DateAndTimeTest failures, see > http://code.google.com/p/pharo/issues/detail?id=2936 > > The patch adds methods clearOffset and withoutOffset to DateAndTime. > > Cheers, > -- Pavel > > ___ > 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] simpleLog in pharo?
Göran, Re "left running," while it is not my intention to throw up the knee-jerk "NO" that has been so common in other projects, I do think we should demand a torture test of any logging system that we adopt. If it can't be started and safely forgotten, it isn't ready. Is the code base small because it is simple and elegant (good) or because it is missing a lot of functionality to let it pass the set and forget test? I don't know the answer, but the question must be asked, and my vote is to adopt only after the answer is favorable. Your observation about new tools is well taken. Your experience on an old laptop is very interesting. If you really want to watch a struggle, compare Pharo to Dolphin running across a remote desktop connection. I am no Morphic expert, but it makes me wonder just how much of the screen is being redrawn and whether a lot of that could be avoided. Good performance on modest hardware is of value. You mention "shiny new stuff," but that is largely in the IDE or parallel systems (e.g. Nile, Ocean). The alternative is to continue to languish with Squeak's streams, sockets, file system, etc. Parts of Squeak are the way they are because they predate structured exception handling. Pharo is catching up on 15 years of refactoring to take advantage of 25 years of advancing technology. There will be some instability along the way, but the released versions have been pretty good so far. No doubt we can and should do better as Pharo evolves. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Göran Krampe [go...@krampe.se] Sent: Wednesday, September 08, 2010 7:34 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] simpleLog in pharo? Hi! On 09/09/2010 01:18 AM, Schwab,Wilhelm K wrote: > Göran, > > I think before we adopt anything, it should have the "left running" scenario > addressed in some way. Pharo is supposed to be robust. > That mean losing the silent failures, and doing so in a way that the new information does not bring the system to its knees. First - I did not bring this up, so feel free to fix any flaws you see/find :). The code base is very small. Secondly - my impression of Pharo so far is not really "robust", and don't get me wrong here - it is not criticism, but my feeling every time I have used Pharo is that it is smack full of new stuff (completion, OB browsers etc etc) which quite often seems to break and also makes it painful to develop on my old trusty kinda slow Dell laptop. It seems to me that "progress" (new shiny stuff!) has been put in favor of robustness, which probably is why Pharo is attractive to a lot of people. Perhaps Pharo changed focus for next release? Sorry for that little rant, don't really "mean" anything with it, just curious to see if I am the only one with this feeling. > On Windows, OutputDebugString() is probably good enough. Since I am doing > everything I can to ditch said platform, I might not be the best person to > ask. Certainly, it is where I would go for a live view, and a file-based log > would then cover everything else - I think. > > On Linux, you mention lots of tools: any recommendations? No :). But there are lots of syslog related tools, just google it. :) regards, Göran ___ 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] CompiledMethod
2010/9/9 Benjamin Van Ryseghem > Hi everybody, > > > I wonder if it's normal than two different methods can have the same > CompiledMethod ? > > By example : > > Class >> foo > 'foo' > > and > > Class >> foo2 > 'foo' > > If I evaluate (Class methodDict at: #foo) = (Class methodDict at: #foo2), > it answers true. > > Maybe the CompiledMethod >> = should test the source ? > There are many definitions of method equality. If you ant to test the source you can test the source, (C >> #foo) getSourceFromFile asString = (C >> #foo2) getSourceFromFile asString. You can test the decompilation of a method (C>>#foo) decompileString = (C>>#foo2) decompileString. The current definition tests whether the bytecodes and literals are the same, not the selector or the source code. That's a useful definition, but not the only one. It is close to the decompile version but faster, and is useful in e.g. testing whether the compiler has changed, since if on recompiling a method is still = the compiler is producing the same bytecode for a compilation. That's what I use it for and it's an important use. cheers Eliot > > > Ben > > ___ > 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] CompiledMethod
Hi everybody, I wonder if it's normal than two different methods can have the same CompiledMethod ? By example : Class >> foo 'foo' and Class >> foo2 'foo' If I evaluate (Class methodDict at: #foo) = (Class methodDict at: #foo2), it answers true. Maybe the CompiledMethod >> = should test the source ? Ben ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] DateAndTimeTest failures
Hi, I tried to fix DateAndTimeTest failures, see http://code.google.com/p/pharo/issues/detail?id=2936 The patch adds methods clearOffset and withoutOffset to DateAndTime. Cheers, -- Pavel ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Feature Request: Strict Compiler / Monticello Mode
El jue, 09-09-2010 a las 18:01 +0200, Levente Uzonyi escribió: > > When should one complain? Never, they should ask for help, maybe file a bug, or better help to fix it and improve the system, but not complain. The contributors and people around Pharo are doing it in their free time for different reasons, but that doesn't means that they are somehow obliged or forced to make the system compatible for everyone and every situation and posible combination of factors, including, time, backward compatibility, API stability, technical support. The code as MIT says, is take it as it is: THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. So if works for you fine. If breaks your code, sorry. If works in this version and the next don't, I feel sorry for you. Of course this isn't what happens regularly in an FOSS project, as the developers are proud to have a system that works correctly in most reasonable situations and they are by their nature very helpful people. But that is just because the good faith of the developers, not their obligation. So, yes, Pharo 1.0 was released and inmediatly Pharo 1.1 was worked out, changing the focus to the new version. If that means that people will have a couple hitches when migrating in order to use the newest changes, then that is a little price to pay (not monetary, but a price nonetheless). The backwards compatibility could be a good thing, but in this little community, we don't have the energy and people to try to do it always. And even if we had them, we don't want to. Neither the big bucks companies. Else, we'll still have 5in drives in our gorgeous Macbook Pro. Cheers -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient License Update
BTW andreas I was reading your changes in squeak about fileList -> FileServices and I noticed that there is a bug there is one method missing suffixOf: in FileServices and I sent a notification in squeak-dev so may be you see it. I did not have the time to produce a fix but this is an easy one. Stef On Sep 9, 2010, at 4:27 AM, Andreas Raab wrote: > Phillipe wrote: > > Did you change your position towards #squeakToUtf8 and string > > concatenation (I didn't follow the entire previous thread)? > > Implicitly yes, but let's discuss this. You're saying you want WebClient > "without overrides" but is this really what you mean? The only reason these > methods are marked overrides is so that they don't kill your system if the > methods themselves get added to the system at some point. For example, Grease > currently adds extension methods for Collection>>sorted but these methods are > already in Squeak and while nothing harmful happens if you load Grease, > unloading it will destroy several methods. As a consequence it is vastly > advantageous to mark methods as overrides if they have even the slightest > possibility to conflict (but of course if you'd rather have them > straightforward extensions, I have no problems with that). > > As for integrating the changes itself, I think that we're talking two very > different issues here. I suspect that the only objection to #squeakToUtf8 and > #utf8ToSqueak is that they have "Squeak" in their name. I don't think you'd > have any objection if they would've been called #utf8Encoded and > #utf8Decoded. Which, honestly, is a childish attitude from my point of view. > > For string concatenation on the other hand, we're basically talking about > dispersing a whole load of FUD about all the things that "may" go wrong. Fact > is, nothing actually *does* go wrong with the change, but the change does fix > situations that are *very* difficult to handle otherwise. One of the > unfortunate realities of string concatenation is that it's very often used > around error messages and logging, often in corner cases that aren't well > tested, like: > > ifTrue:[ > self log: 'Found impossible condition: ', foo. > ]. > > The problem with these uses is that it's quite easy to forget some asString, > or #printString (for example, if you generally had expected foo to be a > string but in the impossible condition it's actually nil) and when you hit > the condition your logging screws up and instead of getting informed about > the impossible condition the program quits due to the error. In fact, I'm > willing to bet that there's at least one bug in Pharo and/or Seaside which is > the result of erroneous string concatenation of this kind. It's just very > easy to get wrong. > > The other relevant bit about this change is that it's entirely type-safe. > I.e., the return type does not depend on the argument, the return type is > always a string. That means that the change does *not* introduce failures > down the road due to type violations. It *does* mean that if you have a bug > in your code you might print "a SomethingOrOther" when you didn't mean to, > but unless you're the kind of person who believes that a program that doesn't > raise an error must be obviously correct, this makes little difference. The > only difference it makes is that your program will not abort when the > *intention* is so utterly obvious. > > Put differently, the change adds nothing but robustness to the system. There > is really no data to back up the FUD about all the changes that "may" go > wrong, but from my experience there is ample evidence to show that logging > and error handling involving string concatenation is highly susceptible to > this kind of problem and generally not very well tested and difficult to QA. > And the major use of string concatenation is right in these areas. > > Last but not least, programming is about efficiency. Why would you waste your > time in typing 'The result is: ', x printString" when you could just type > "'The result is: ', x" and spare the time to write all the extra characters? > Do you realize how much time you've wasted sprinkling all those #printString > and #asString around WebClient? > > Cheers, > - Andreas > > ___ > 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] Feature Request: Strict Compiler / Monticello Mode
> > > I'm sure they didn't pay for this. > > "Now Squeak/Pharo comes with no warranties, as the license states. So > don't complain because when migrating to a new version *you* must adapt > your code to the new environment. That is expected and nothing to whine > of. If you want that a system runs unchanged for decades, the use a > environment that doesn't change for decades. And remain there, as the > world lets you behind." > > When should one complain? Of course people can complain. Now do you use pharo? And squeak is changing too so where is the difference. 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] Feature Request: Strict Compiler / Monticello Mode
Why are you so aggressive against us? Now if you want status quo why do you even commit in squeak? Now I'm not sure that this is the kind of >>> Isn't Grease dialect dependent by essence ? >>> If Pharo and Squeak diverge, then there will naturally be two versions >>> of Grease... >>> However, for these two messages, I think Pharo core should integrate >>> them and align with Squeak. The question is more whether you need to >>> distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ... >> >> Probably else this means that Pharo and any system is bound to die because >> it does not change. > > The rapid changes and no-backwards-compatibility you prefer and advocate are > not essential for a Smalltalk system to "stay alive". Just look at VSE, it > didn't change in the last 10 years, and people are still using it. > In constrast Pharo 1.0 was considered abandonware four months after it's > release, which caused trouble for some users who didn't think that they'll > have to patch their code and rebuild their images to "get" updates/fixes. 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 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] Cog Segmentation Fault with Pharo 1.1
ahh, Thanks Levente, sorry was my fault, I forgot this detail. 2010/9/9 Levente Uzonyi : > On Thu, 9 Sep 2010, Germán Arduino wrote: > >> Hi: >> >> I was playing a bit with a stock Pharo 1.1 image, with the only adding >> of the cs NecessaryImageChangesForCogToWork.Pharo1.1. >> >> Then I tried to run TestRunner new runAll (for comparing times against >> the common vm) and get the attached segfault. >> >> I tried with my own compiled cog and also with the downloaded from >> here http://www.mirandabanda.org/files/Cog/VM/VM.r2219/. >> >> My OS is Ubuntu 10.04 64 bits. >> >> Any hint will be appreciated. > > ObjectsAsMethods is not supported, so TestObjectsAsMethods will crash the > VM. > > > Levente > >> >> Cheers. >> >> -- >> = >> Germán S. Arduino Twitter: garduino >> Arduino Software & Web Hosting http://www.arduinosoftware.com >> PasswordsPro http://www.passwordspro.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
Re: [Pharo-project] Feature Request: Strict Compiler / Monticello Mode
On Thu, 9 Sep 2010, Miguel Enrique Cobá Martínez wrote: El jue, 09-09-2010 a las 16:01 +0200, Levente Uzonyi escribió: On Thu, 9 Sep 2010, Stéphane Ducasse wrote: > >> Isn't Grease dialect dependent by essence ? >> If Pharo and Squeak diverge, then there will naturally be two versions >> of Grease... >> However, for these two messages, I think Pharo core should integrate >> them and align with Squeak. The question is more whether you need to >> distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ... > > Probably else this means that Pharo and any system is bound to die because > it does not change. The rapid changes and no-backwards-compatibility you prefer and advocate are not essential for a Smalltalk system to "stay alive". Just look at VSE, it didn't change in the last 10 years, and people are still using it. In constrast Pharo 1.0 was considered abandonware four months after it's release, which caused trouble for some users who didn't think that they'll have to patch their code and rebuild their images to "get" updates/fixes. "Yes but they paid support to remain backwards compatible. If I paid support and not get my system running in new versions then I really would be a fool for paying." I'm sure they didn't pay for this. "Now Squeak/Pharo comes with no warranties, as the license states. So don't complain because when migrating to a new version *you* must adapt your code to the new environment. That is expected and nothing to whine of. If you want that a system runs unchanged for decades, the use a environment that doesn't change for decades. And remain there, as the world lets you behind." When should one complain? Levente Levente > > This is why configurations are important. > > 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 -- Miguel Cobá http://miguel.leugim.com.mx ___ 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] Cog Segmentation Fault with Pharo 1.1
On Thu, 9 Sep 2010, Germán Arduino wrote: Hi: I was playing a bit with a stock Pharo 1.1 image, with the only adding of the cs NecessaryImageChangesForCogToWork.Pharo1.1. Then I tried to run TestRunner new runAll (for comparing times against the common vm) and get the attached segfault. I tried with my own compiled cog and also with the downloaded from here http://www.mirandabanda.org/files/Cog/VM/VM.r2219/. My OS is Ubuntu 10.04 64 bits. Any hint will be appreciated. ObjectsAsMethods is not supported, so TestObjectsAsMethods will crash the VM. Levente Cheers. -- = Germán S. Arduino Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com = ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Cog Segmentation Fault with Pharo 1.1
Hi: I was playing a bit with a stock Pharo 1.1 image, with the only adding of the cs NecessaryImageChangesForCogToWork.Pharo1.1. Then I tried to run TestRunner new runAll (for comparing times against the common vm) and get the attached segfault. I tried with my own compiled cog and also with the downloaded from here http://www.mirandabanda.org/files/Cog/VM/VM.r2219/. My OS is Ubuntu 10.04 64 bits. Any hint will be appreciated. Cheers. -- = Germán S. Arduino Twitter: garduino Arduino Software & Web Hosting http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com = gardu...@ubuntu:~/Development/Pharo-1.1Cog$ /home/garduino/Development/coglinux/squeak Pharo-1.1-SandBox.image Segmentation fault Smalltalk stack dump: 0xff9fe4f4 I UUID>initialize -1186627592: a(n) UUID 0xff9fe50c M UUID class(Behavior)>new: -1220271004: a(n) UUID class 0xff9fe530 I UUID class>new -1220271004: a(n) UUID class 0xff9fe564 I [] in GoferResource>setUpMonticelloRepository -1186638508: a(n) GoferResource 0xff9fe584 M OrderedCollection>do: -1186638484: a(n) OrderedCollection 0xff9fe5a8 I GoferResource>setUpMonticelloRepository -1186638508: a(n) GoferResource 0xff9fe5c8 I GoferResource>setUp -1186638508: a(n) GoferResource 0xff9fe5e8 I GoferResource(TestResource)>initialize -1186638508: a(n) GoferResource 0xff9fe600 M GoferResource class(Behavior)>new -1219438712: a(n) GoferResource class 0xff9fe620 I GoferResource class(TestResource class)>current -1219438712: a(n) GoferResource class 0xff9fe640 I GoferResource class(TestResource class)>isAvailable -1219438712: a(n) GoferResource class 0xff9fe660 I [] in TestRunner>basicSetUpSuite: -1189329880: a(n) TestRunner 0xff9fe680 M [] in Set>do: -1188768800: a(n) Set 0xff9fe6a4 M Array(SequenceableCollection)>do: -1188768320: a(n) Array 0xff9fe6c0 M Set>do: -1188768800: a(n) Set 0xff9fe6e4 I TestRunner>basicSetUpSuite: -1189329880: a(n) TestRunner 0xff9fe708 I TestRunner>basicRunSuite:do: -1189329880: a(n) TestRunner 0xff998140 I TestRunner>runSuite: -1189329880: a(n) TestRunner 0xff998164 I TestRunner>runAll -1189329880: a(n) TestRunner 0xff99817c M UndefinedObject>? -1221214204: a(n) UndefinedObject 0xff9981b4 I Compiler>evaluate:in:to:notifying:ifFail:logged: -1189332936: a(n) Compiler 0xff9981f4 I [] in TextMorphForShoutEditor(ParagraphEditor)>evaluateSelection -1201578868: a(n) TextMorphForShoutEditor 0xff998210 M BlockClosure>on:do: -1189332980: a(n) BlockClosure 0xff998244 I TextMorphForShoutEditor(ParagraphEditor)>evaluateSelection -1201578868: a(n) TextMorphForShoutEditor 0xff998268 I TextMorphForShoutEditor(ParagraphEditor)>printIt -1201578868: a(n) TextMorphForShoutEditor 0xff998280 M [] in TextMorphForShoutEditor(ParagraphEditor)>printIt: -1201578868: a(n) TextMorphForShoutEditor 0xff9982a0 I TextMorphForShoutEditor(ParagraphEditor)>terminateAndInitializeAround: -1201578868: a(n) TextMorphForShoutEditor 0xff9982bc M TextMorphForShoutEditor(ParagraphEditor)>printIt: -1201578868: a(n) TextMorphForShoutEditor 0xff9982ec M TextMorphForShoutEditor(ParagraphEditor)>dispatchOnKeyEvent:with: -1201578868: a(n) TextMorphForShoutEditor 0xff99830c M TextMorphForShoutEditor(TextMorphEditor)>dispatchOnKeyEvent:with: -1201578868: a(n) TextMorphForShoutEditor 0xff998330 M TextMorphForShoutEditor(ParagraphEditor)>keystroke: -1201578868: a(n) TextMorphForShoutEditor 0xff99834c M TextMorphForShoutEditor(TextMorphEditor)>keystroke: -1201578868: a(n) TextMorphForShoutEditor 0xff99836c M [] in TextMorphForShout(TextMorph)>keyStroke: -1201583104: a(n) TextMorphForShout 0xff998390 M TextMorphForShout(TextMorph)>handleInteraction: -1201583104: a(n) TextMorphForShout 0xff9983ac M TextMorphForShout(TextMorphForEditView)>handleInteraction: -1201583104: a(n) TextMorphForShout 0xff9983d0 M [] in TextMorphForShout(TextMorph)>keyStroke: -1201583104: a(n) TextMorphForShout 0xff9983f4 M ECToolSet class>codeCompletionAround:textMorph:keyStroke: -1212144152: a(n) ECToolSet class 0xff99841c M DEVToolSet class>codeCompletionAround:textMorph:keyStroke: -1210724356: a(n) DEVToolSet class 0xff998440 M ToolSet class>codeCompletionAround:textMorph:keyStroke: -1220252476: a(n) ToolSet class 0xff998464 M TextMorphForShout(TextMorph)>keyStroke: -1201583104: a(n) TextMorphForShout 0xff998484 M TextMorphForShout(TextMorphForEditView)>keyStroke: -1201583104: a(n) TextMorphForShout 0xff9984a4 M TextMorphForShout(TextMorph)>handleKeystroke: -1201583104: a(n) TextMorphForShout 0xff9984c0 M KeyboardEvent>sentTo: -1189334052: a(n) KeyboardEvent 0xff9984dc M TextMorphForShout(Morph)>handleEvent: -1201583104: a(n) TextMorphForShout 0xff9984f8 M TextMorphForShout(Morph)>handleFocusEvent: -1201583104: a(n) TextMorphForShout 0xff998520 M [] in HandMorph>sendFocusEvent:to:clear: -1219767840: a(n) HandMorph 0xff99853c M [] in PasteUpMorph>becomeActiveDuring: -1219479724: a(n) PasteU
Re: [Pharo-project] Changing the world menu
thanks! Stef On Sep 9, 2010, at 3:35 PM, Hilaire Fernandes wrote: > I have proposed a patch ready for integration to easily change the world > menu > > http://code.google.com/p/pharo/issues/detail?id=2930 > > Hilaire > > Le 09/09/2010 14:36, Alain Plantec a écrit : >> Yes, what is missing is a way to reset the menuBuilder in the WorldState so that it creates a new one. >>> Is it what you are looking for ? >> argh, no, you need to re-create the menuBuilder with the new pragma >> keyword. >> and yes it is missing :( >> >> maybe something like: >> >> setMenuPragmaKeywordTo: aSymbol >>menuBuilder := PragmaMenuBuilder pragmaKeyword: aSymbol model: self >> >> Alain >> >> >>> >>> PasteUpMorph>>resetWorldMenu >>>menuBuilder >>>ifNotNil: [menuBuilder reset] >>> >>> >>> to be used as follow: >>> -- >>> World resetWorldMenu >>> -- >>> >>> Alain Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> > > > -- > Dr. Geo, to discover geometry on Linux, Windows, MAC and XO > http://community.ofset.org/index.php/DrGeo > > > ___ > 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] Building Cocoa 5.x series plugins, and testing help needed.
On 08.09.2010 20:42, John M McIntosh wrote: > > On 2010-09-08, at 3:34 AM, Philippe Marschall wrote: >> - #primCountry and #primLanguage seem to answer a three element String >> with the last element being a zero character (I assume a C string), this >> is not so nice. I'm not sure whether this should be fixed in the >> primitive or in the Pharo code. > > The primitive is answering a ISO 639-1 value (2 character) versus the ISO > 639-2 value (3 character) > I have to figure out how to get the ISO 639-2 data, but it seems in looking > it appears you'll get the 2 character > code versus the 3 character code on other platforms so I'll bet you need to > deal with the case of 2 character codes. > The plugin assumes a 3 character value which is why you get the trailing null > char. You'll need to deal with it. OK >> - All the primitives seem to totally ignore the locale id and only work >> on the system locale. This makes it a whole lot less useful. > > ? explain ? > > In the primitive I ask for "autoupdatingCurrentLocale" The current logical > locale for the current user. The locale is formed from the settings for the > current user’s chosen system locale overlaid with any custom settings the > user has specified in System Preferences. The object always reflects the > current state of the current user's locale settings. (Locale localeID: (LocaleID isoString: 'de-CH')) primCountry I mean, really? It totally ignores the locale id and answers the locale of the user. If that's the intended behavior why not move it to the class side of Locale? That would remove a lot of potential for confusion. The current behavior might make sense for a single classroom EToys image. It's not very helpful in a multiuser application where you want to format numbers and currencies according to the users locale. >> - I'm totally confused by the Current and CurrentPlatform class >> variables. What's the difference? Do we really need both? >> - I'm confused by #isoCountry vs #primCountry and #isoLangauge vs >> #primLanguage. Do we need both? What's the point? Is this what you meant >> which cleanup? > > Yes that would be cleanup.. OK, but see the problem above, #isoCountry comes from the locale id, #primCountry comes from the user locale. > There is also issues withe currency symbol, the logic assumes it's one byte, > but it could be a unicode value > if you decide between the international symbol versus localized regional > symbol. I think the plugin is flawed > in that respect. Answers 'SFr.' where quite nicely. 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] [ANN] Aida/Web 6.1 released
Dear Smalltalkers, I'm proud to announce the new version of Aida/Web Application server and Web framework (http://www.aidaweb.si), currently prepared for Squeak/Pharo and VisualWorks. What's new in 6.1? * Inline translation to multiple languages,to translate your web applications to other languages inline, by just clicking the text on the page. Translation is immediately stored in class methods on your web app classes. * See three screenshots in an attached picture. First we click the Security title. Second we translate it inline to French and click Ok. Text is from now on in French for a French speaking visitors and in English for all others. Other most important new features: * Standalone web apps, no link to the domain model needed, * Ajaxified input validation, * Action blocks (aka callbacks). And more: * Routing of web requests, * Static serving moved to a special StaticServer class, * IE8 support in IE7 emulation mode to avoid manual checking of IE8 Compatibility view * AdvancedSearch widget introduced, for easier implementation of advanced search in web apps * Email messenger introduced for easier sending emails with notifications and similar from your web apps * RegistrationApp, a standalone web app to guide the user registration process * Pluggable authentication, with default authenticator from local security settings included, LDAP authenticator as add-on. See Release notes for detailed list of all new features and bugs resolved, with most important ones emphasized http://www.aidaweb.si/release-notes-6.1 For Squeak/Pharo there is now a Metacello configuration available. To install for instance Pharo just evaluate this script: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfAida'; load. ((Smalltalk at: #ConfigurationOfAida) project version: '6.1') load. SwazooAida demoStart. More on Download page on our website http://www.aidaweb.si/download.html Best regards Janko -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si <>___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Feature Request: Strict Compiler / Monticello Mode
El jue, 09-09-2010 a las 16:01 +0200, Levente Uzonyi escribió: > On Thu, 9 Sep 2010, Stéphane Ducasse wrote: > > > > >> Isn't Grease dialect dependent by essence ? > >> If Pharo and Squeak diverge, then there will naturally be two versions > >> of Grease... > >> However, for these two messages, I think Pharo core should integrate > >> them and align with Squeak. The question is more whether you need to > >> distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ... > > > > Probably else this means that Pharo and any system is bound to die because > > it does not change. > > The rapid changes and no-backwards-compatibility you prefer and advocate > are not essential for a Smalltalk system to "stay alive". Just look at > VSE, it didn't change in the last 10 years, and people are still using it. > In constrast Pharo 1.0 was considered abandonware four months after it's > release, which caused trouble for some users who didn't think that they'll > have to patch their code and rebuild their images to "get" updates/fixes. Yes but they paid support to remain backwards compatible. If I paid support and not get my system running in new versions then I really would be a fool for paying. Now Squeak/Pharo comes with no warranties, as the license states. So don't complain because when migrating to a new version *you* must adapt your code to the new environment. That is expected and nothing to whine of. If you want that a system runs unchanged for decades, the use a environment that doesn't change for decades. And remain there, as the world lets you behind. > > > Levente > > > > > This is why configurations are important. > > > > 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 -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Feature Request: Strict Compiler / Monticello Mode
> Isn't Grease dialect dependent by essence ? Sure, not only dialect dependent but even version dependent. That's why I changed Grease to align with Pharo 1.1 (this is the stable Pharo supported by Grease). What Philippe only wanted to point out is that updating Grease might blow up your system (because of the methods that are missing afterwards). 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] Feature Request: Strict Compiler / Monticello Mode
On Thu, 9 Sep 2010, Stéphane Ducasse wrote: Isn't Grease dialect dependent by essence ? If Pharo and Squeak diverge, then there will naturally be two versions of Grease... However, for these two messages, I think Pharo core should integrate them and align with Squeak. The question is more whether you need to distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ... Probably else this means that Pharo and any system is bound to die because it does not change. The rapid changes and no-backwards-compatibility you prefer and advocate are not essential for a Smalltalk system to "stay alive". Just look at VSE, it didn't change in the last 10 years, and people are still using it. In constrast Pharo 1.0 was considered abandonware four months after it's release, which caused trouble for some users who didn't think that they'll have to patch their code and rebuild their images to "get" updates/fixes. Levente This is why configurations are important. 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
Re: [Pharo-project] We'll have a sunny ESUG 2010 :-)
Lucky you :) Hilaire Le 09/09/2010 14:19, Noury Bouraqadi a écrit : > > > Begin forwarded message: > >> From: Jordi Delgado >> Date: 9 septembre 2010 13:22:27 HAEC >> To: bo...@esug.org >> Subject: weather forecast >> >> Hi, >> >> Good news, it looks like we are going to enjoy >> a sunny ESUG! >> >> http://www.meteocat.com/mediamb_xemec/servmet/english/index.html >> >> At least until next thursday... >> >> Bests, >> >> Jordi > > Noury -- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Changing the world menu
I have proposed a patch ready for integration to easily change the world menu http://code.google.com/p/pharo/issues/detail?id=2930 Hilaire Le 09/09/2010 14:36, Alain Plantec a écrit : > >>> Yes, what is missing is a way to reset the menuBuilder in the >>> WorldState so that >>> it creates a new one. >> Is it what you are looking for ? > argh, no, you need to re-create the menuBuilder with the new pragma > keyword. > and yes it is missing :( > > maybe something like: > > setMenuPragmaKeywordTo: aSymbol > menuBuilder := PragmaMenuBuilder pragmaKeyword: aSymbol model: self > > Alain > > >> >> PasteUpMorph>>resetWorldMenu >> menuBuilder >> ifNotNil: [menuBuilder reset] >> >> >> to be used as follow: >> -- >> World resetWorldMenu >> -- >> >> Alain >>> Marcus >>> >>> >>> -- >>> Marcus Denker -- http://www.marcusdenker.de >>> INRIA Lille -- Nord Europe. Team RMoD. >>> >>> >>> ___ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo ___ 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.2] #12130
12130 - Issue 2915: remove tinyDisplay check and code Issue 2916: Clean MorphExtension more Issue 2917: CatchAll entry for small cleanups Issue 2913: Remove empty WebClient class categories -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Feature Request: Strict Compiler / Monticello Mode
> Isn't Grease dialect dependent by essence ? > If Pharo and Squeak diverge, then there will naturally be two versions > of Grease... > However, for these two messages, I think Pharo core should integrate > them and align with Squeak. The question is more whether you need to > distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ... Probably else this means that Pharo and any system is bound to die because it does not change. This is why configurations are important. Stef ___ 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.2] #12129
12129 - - Fix suffixOf: - Issue 2107: Using test to encode package dependency structure. 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] Feature Request: Strict Compiler / Monticello Mode
Isn't Grease dialect dependent by essence ? If Pharo and Squeak diverge, then there will naturally be two versions of Grease... However, for these two messages, I think Pharo core should integrate them and align with Squeak. The question is more whether you need to distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ... Nicolas 2010/9/9 Stéphane Ducasse : > ok let us know how we can help. > There are methods from grease that I would love to have in Pharo to get > better libraries. > > Stef > > >> I suggest that we just remove the two methods (Collection>>#sorted and >> Colection>>#sorted:) from Grease. It doesn't look like the system >> itself is calling them on Collection, and most subclasses override >> them anyway. >> >> Lukas >> >> On 9 September 2010 11:10, Philippe Marschall wrote: >>> Hi >>> >>> It seems like we unintentionally introduced an override for Collection > #sorted in Grease. That puts in a hard place because we can't simply >>> remove it from Grease. Because if you do that everybody who updates >>> looses the method and potentially breaks his image. Yeah, I see that the >>> real fix you be for Monticello to restore the old method but that hasn't >>> happened in years. >>> >>> Monticello / the compiler already warns about a lot of less important >>> things. Now I know adding an additional preference for that is ugly and >>> I'd welcome and better/nicer solution. >>> >>> 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] Changing the world menu
Yes, what is missing is a way to reset the menuBuilder in the WorldState so that it creates a new one. Is it what you are looking for ? argh, no, you need to re-create the menuBuilder with the new pragma keyword. and yes it is missing :( maybe something like: setMenuPragmaKeywordTo: aSymbol menuBuilder := PragmaMenuBuilder pragmaKeyword: aSymbol model: self Alain PasteUpMorph>>resetWorldMenu menuBuilder ifNotNil: [menuBuilder reset] to be used as follow: -- World resetWorldMenu -- Alain Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ 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] We'll have a sunny ESUG 2010 :-)
Begin forwarded message: > From: Jordi Delgado > Date: 9 septembre 2010 13:22:27 HAEC > To: bo...@esug.org > Subject: weather forecast > > Hi, > > Good news, it looks like we are going to enjoy > a sunny ESUG! > > http://www.meteocat.com/mediamb_xemec/servmet/english/index.html > > At least until next thursday... > > Bests, > > Jordi Noury ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient License Update
> > Implicitly yes, but let's discuss this. You're saying you want WebClient > "without overrides" but is this really what you mean? The only reason these > methods are marked overrides is so that they don't kill your system if the > methods themselves get added to the system at some point. For example, Grease > currently adds extension methods for Collection>>sorted but these methods are > already in Squeak and while nothing harmful happens if you load Grease, > unloading it will destroy several methods. As a consequence it is vastly > advantageous to mark methods as overrides if they have even the slightest > possibility to conflict (but of course if you'd rather have them > straightforward extensions, I have no problems with that). may be we should change the semantics of unload with overriding (without *overrides*): restore the hidden method that a new load can be do. 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] Changing the world menu
Le 09/09/2010 14:17, Marcus Denker a écrit : On Sep 9, 2010, at 2:13 PM, Hilaire Fernandes wrote: Okay I see. I will propose a little refactoring of WorldState so one can change the world menu programmatically. Yes, what is missing is a way to reset the menuBuilder in the WorldState so that it creates a new one. Is it what you are looking for ? PasteUpMorph>>resetWorldMenu menuBuilder ifNotNil: [menuBuilder reset] to be used as follow: -- World resetWorldMenu -- Alain Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ 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] Changing the world menu
On Sep 9, 2010, at 2:13 PM, Hilaire Fernandes wrote: > Okay I see. > I will propose a little refactoring of WorldState so one can change the > world menu programmatically. Yes, what is missing is a way to reset the menuBuilder in the WorldState so that it creates a new one. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Changing the world menu
Okay I see. I will propose a little refactoring of WorldState so one can change the world menu programmatically. Hilaire > When I change > > WordState>>worldMenuPragmaKeyword > ^ 'DrGeo' > "^worldMenu' " > > I still get the default world menu > > Hilaire > > Le 09/09/2010 13:27, Marcus Denker a écrit : >> >> On Sep 9, 2010, at 12:29 PM, Stéphane Ducasse wrote: >> >>> >>> On Sep 9, 2010, at 11:49 AM, Hilaire Fernandes wrote: >>> How can I change programmatically the world menu? Which class to look at? >>> >>> PasteUpMorph? >>> Setting? >>> >> >> Check the senders of worldMenu, e.g. >> >> >> SettingsBrowser>>#menuCommandOn: aBuilder >> >> (aBuilder item: #'Settings') >> parent: #System; >> order: 1; >> icon: MenuIcons smallConfigurationIcon; >> action: [SettingBrowser open]; >> help: 'Opens a SystemSettingBrowser which allows you to alter >> many system settings' >> >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. > > -- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Changing the world menu
When I change WordState>>worldMenuPragmaKeyword ^ 'DrGeo' "^worldMenu' " I still get the default world menu Hilaire Le 09/09/2010 13:27, Marcus Denker a écrit : > > On Sep 9, 2010, at 12:29 PM, Stéphane Ducasse wrote: > >> >> On Sep 9, 2010, at 11:49 AM, Hilaire Fernandes wrote: >> >>> How can I change programmatically the world menu? >>> Which class to look at? >> >> PasteUpMorph? >> Setting? >> > > Check the senders of worldMenu, e.g. > > > SettingsBrowser>>#menuCommandOn: aBuilder > > (aBuilder item: #'Settings') > parent: #System; > order: 1; > icon: MenuIcons smallConfigurationIcon; > action: [SettingBrowser open]; > help: 'Opens a SystemSettingBrowser which allows you to alter > many system settings' > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. -- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Changing the world menu
On Sep 9, 2010, at 12:29 PM, Stéphane Ducasse wrote: > > On Sep 9, 2010, at 11:49 AM, Hilaire Fernandes wrote: > >> How can I change programmatically the world menu? >> Which class to look at? > > PasteUpMorph? > Setting? > Check the senders of worldMenu, e.g. SettingsBrowser>>#menuCommandOn: aBuilder (aBuilder item: #'Settings') parent: #System; order: 1; icon: MenuIcons smallConfigurationIcon; action: [SettingBrowser open]; help: 'Opens a SystemSettingBrowser which allows you to alter many system settings' -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.2] #12127
We were doing horizontal teaching :) Stef On Sep 9, 2010, at 11:11 AM, Mariano Martinez Peck wrote: > > > On Thu, Sep 9, 2010 at 11:07 AM, stephane ducasse > wrote: > 12127 > - > > - 2920 and 2921: Some little recategorizations with Gabriela Arevalo, Gabriel > Barbuto, Nicolas Paez and Martin Dias. > > what happened to pharo ? all argentinians now? :) > > > 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
Re: [Pharo-project] simpleLog in pharo?
We should think about that and identify a good solution. Thanks for the information and discussion. Stef > The inspector is currently used to view the object log in the development > vm...for large object logs it makes sense to filter the log before viewing. > > For external viewing I have a Seaside Component that allows one to filter and > sort the object log entries as well as delete entries from the ObjectLog ... > > Since GemStone runs with multiple vms, you can use a separate vm to look at > the shared object log ... .. > > The RCQueue (and OrderedCollections for that matter) in GemStone don't incur > performance hits as the collection grows over time (unlike growing > OrderedCollections in a normal client Smalltalk), but then GemStone was > designed with very large collections in mind:)... > > GemStone was designed to handle collections and object graphs that can be > larger than available memory, so you can forget about the object log until > start running out of repository space (basically disk space) ... > > For the Pharo, I would think that the fact that an Object log could > accumulate a whole lot of stuff is real limiting factor...there'd need to be > a process that continuously pruned objects from the object log over time > so a thread safe linked list might be a better choice for the Object log > collection ... > > Dale ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] simpleLog in pharo?
>> Göran, >> >> I think before we adopt anything, it should have the "left running" scenario >> addressed in some way. Pharo is supposed to be robust. > > That mean losing the silent failures, and doing so in a way that the new > > information does not bring the system to its knees. > > First - I did not bring this up, so feel free to fix any flaws you see/find > :). The code base is very small. > > Secondly - my impression of Pharo so far is not really "robust", and don't > get me wrong here - it is not criticism, but my feeling every time I have > used Pharo is that it is smack full of new stuff (completion, OB browsers etc > etc) which quite often seems to break and also makes it painful to develop on > my old trusty kinda slow Dell laptop. Where are your feedback? When did you mention that? And yes the system should change because I can list a lot of skeletons and paper tape that make the system believe it is working but is brittle. > It seems to me that "progress" (new shiny stuff!) has been put in favor of > robustness, Apparently all the bugs we close do not count? Come on goran... > which probably is why Pharo is attractive to a lot of people. Perhaps Pharo > changed focus for next release? > > Sorry for that little rant, don't really "mean" anything with it, just > curious to see if I am the only one with this feeling. >> On Windows, OutputDebugString() is probably good enough. Since I am doing >> everything I can to ditch said platform, I might not be the best person to >> ask. Certainly, it is where I would go for a live view, and a file-based >> log would then cover everything else - I think. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient License Update
> For string concatenation on the other hand, we're basically talking about > dispersing a whole load of FUD about all the things that "may" go wrong. Fact > is, nothing actually *does* go wrong with the change, but the change does fix > situations that are *very* difficult to handle otherwise. One of the > unfortunate realities of string concatenation is that it's very often used > around error messages and logging, often in corner cases that aren't well > tested, like: > > ifTrue:[ > self log: 'Found impossible condition: ', foo. > ]. I do not buy this argument. We should fix the code and not break the libraries. Your argument is bogus. We do not want such kind of extensions that opens the door to really sloppy code. Then we should avoid overrides as much as possible. 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] Changing the world menu
On Sep 9, 2010, at 11:49 AM, Hilaire Fernandes wrote: > How can I change programmatically the world menu? > Which class to look at? PasteUpMorph? Setting? > > Hilaire > > -- > Dr. Geo, to discover geometry on Linux, Windows, MAC and XO > http://community.ofset.org/index.php/DrGeo > > > ___ > 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] Feature Request: Strict Compiler / Monticello Mode
ok let us know how we can help. There are methods from grease that I would love to have in Pharo to get better libraries. Stef > I suggest that we just remove the two methods (Collection>>#sorted and > Colection>>#sorted:) from Grease. It doesn't look like the system > itself is calling them on Collection, and most subclasses override > them anyway. > > Lukas > > On 9 September 2010 11:10, Philippe Marschall wrote: >> Hi >> >> It seems like we unintentionally introduced an override for Collection #sorted in Grease. That puts in a hard place because we can't simply >> remove it from Grease. Because if you do that everybody who updates >> looses the method and potentially breaks his image. Yeah, I see that the >> real fix you be for Monticello to restore the old method but that hasn't >> happened in years. >> >> Monticello / the compiler already warns about a lot of less important >> things. Now I know adding an additional preference for that is ugly and >> I'd welcome and better/nicer solution. >> >> 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] Feature Request: Strict Compiler / Monticello Mode
Btw, same problem with WriteStream>>crlf. Lukas On 9 September 2010 12:10, Lukas Renggli wrote: > I suggest that we just remove the two methods (Collection>>#sorted and > Colection>>#sorted:) from Grease. It doesn't look like the system > itself is calling them on Collection, and most subclasses override > them anyway. > > Lukas > > On 9 September 2010 11:10, Philippe Marschall wrote: >> Hi >> >> It seems like we unintentionally introduced an override for Collection #sorted in Grease. That puts in a hard place because we can't simply >> remove it from Grease. Because if you do that everybody who updates >> looses the method and potentially breaks his image. Yeah, I see that the >> real fix you be for Monticello to restore the old method but that hasn't >> happened in years. >> >> Monticello / the compiler already warns about a lot of less important >> things. Now I know adding an additional preference for that is ugly and >> I'd welcome and better/nicer solution. >> >> Cheers >> Philippe >> >> >> ___ >> 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 > -- 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] Feature Request: Strict Compiler / Monticello Mode
I suggest that we just remove the two methods (Collection>>#sorted and Colection>>#sorted:) from Grease. It doesn't look like the system itself is calling them on Collection, and most subclasses override them anyway. Lukas On 9 September 2010 11:10, Philippe Marschall wrote: > Hi > > It seems like we unintentionally introduced an override for Collection >>> #sorted in Grease. That puts in a hard place because we can't simply > remove it from Grease. Because if you do that everybody who updates > looses the method and potentially breaks his image. Yeah, I see that the > real fix you be for Monticello to restore the old method but that hasn't > happened in years. > > Monticello / the compiler already warns about a lot of less important > things. Now I know adding an additional preference for that is ugly and > I'd welcome and better/nicer solution. > > Cheers > Philippe > > > ___ > 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
[Pharo-project] Pharo taskbar
I added a button to the taskbar, but this one is regularly pooled and udpated with the active window. So my button is deleted. As far as I can see from the taskbar code there is no mechanism to add alternate widget to the taskbar, right? Hilaire -- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo ___ 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.2] #12128
12128 - - Issue 2888: floating point printing is wrong. Thanks Paolo Bonzini and Nicolas Cellier. Now 0.3-0.2 prints 0.09998 - Issue 2919: SystemNavigation package support. Thanks Eliot Miranda. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Changing the world menu
How can I change programmatically the world menu? Which class to look at? Hilaire -- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.2] #12127
On Thu, Sep 9, 2010 at 11:07 AM, stephane ducasse wrote: > 12127 > - > > - 2920 and 2921: Some little recategorizations with Gabriela Arevalo, > Gabriel Barbuto, Nicolas Paez and Martin Dias. > what happened to pharo ? all argentinians now? :) > > 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] Feature Request: Strict Compiler / Monticello Mode
Hi It seems like we unintentionally introduced an override for Collection >> #sorted in Grease. That puts in a hard place because we can't simply remove it from Grease. Because if you do that everybody who updates looses the method and potentially breaks his image. Yeah, I see that the real fix you be for Monticello to restore the old method but that hasn't happened in years. Monticello / the compiler already warns about a lot of less important things. Now I know adding an additional preference for that is ugly and I'd welcome and better/nicer solution. 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] [update 1.2] #12127
12127 - - 2920 and 2921: Some little recategorizations with Gabriela Arevalo, Gabriel Barbuto, Nicolas Paez and Martin Dias. 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] WebClient License Update
On 09.09.2010 04:27, Andreas Raab wrote: > Phillipe wrote: >> Did you change your position towards #squeakToUtf8 and string >> concatenation (I didn't follow the entire previous thread)? > > Implicitly yes, That's fine. > but let's discuss this. Personal coding styles are a matter of taste, no way we ever reach a consensus (the discussion that will go nowhere has already started). > You're saying you want WebClient > "without overrides" but is this really what you mean? The only reason > these methods are marked overrides is so that they don't kill your > system if the methods themselves get added to the system at some point. > For example, Grease currently adds extension methods for > Collection>>sorted but these methods are already in Squeak and while > nothing harmful happens if you load Grease, unloading it will destroy > several methods. As a consequence it is vastly advantageous to mark > methods as overrides if they have even the slightest possibility to > conflict (but of course if you'd rather have them straightforward > extensions, I have no problems with that). We need to fix that, thanks for pointing that out. > As for integrating the changes itself, I think that we're talking two > very different issues here. I suspect that the only objection to > #squeakToUtf8 and #utf8ToSqueak is that they have "Squeak" in their > name. I don't think you'd have any objection if they would've been > called #utf8Encoded and #utf8Decoded. Which, honestly, is a childish > attitude from my point of view. > > For string concatenation on the other hand, we're basically talking > about dispersing a whole load of FUD about all the things that "may" go > wrong. Fact is, nothing actually *does* go wrong with the change, but > the change does fix situations that are *very* difficult to handle > otherwise. One of the unfortunate realities of string concatenation is > that it's very often used around error messages and logging, often in > corner cases that aren't well tested, like: > > ifTrue:[ > self log: 'Found impossible condition: ', foo. > ]. > > The problem with these uses is that it's quite easy to forget some > asString, or #printString (for example, if you generally had expected > foo to be a string but in the impossible condition it's actually nil) > and when you hit the condition your logging screws up and instead of > getting informed about the impossible condition the program quits due to > the error. In fact, I'm willing to bet that there's at least one bug in > Pharo and/or Seaside which is the result of erroneous string > concatenation of this kind. It's just very easy to get wrong. > > The other relevant bit about this change is that it's entirely > type-safe. I.e., the return type does not depend on the argument, the > return type is always a string. That means that the change does *not* > introduce failures down the road due to type violations. It *does* mean > that if you have a bug in your code you might print "a SomethingOrOther" > when you didn't mean to, but unless you're the kind of person who > believes that a program that doesn't raise an error must be obviously > correct, this makes little difference. The only difference it makes is > that your program will not abort when the *intention* is so utterly > obvious. > > Put differently, the change adds nothing but robustness to the system. > There is really no data to back up the FUD about all the changes that > "may" go wrong, but from my experience there is ample evidence to show > that logging and error handling involving string concatenation is highly > susceptible to this kind of problem and generally not very well tested > and difficult to QA. And the major use of string concatenation is right > in these areas. > > Last but not least, programming is about efficiency. Why would you waste > your time in typing 'The result is: ', x printString" when you could > just type "'The result is: ', x" and spare the time to write all the > extra characters? Do you realize how much time you've wasted sprinkling > all those #printString and #asString around WebClient? 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] [update 1.1] #11413
11413 - Issue 1068: Mac: Quit from host menu not working anymore Issue 2844: String>>#numArgs is broken Issue 2711: SmartRefStream (and hence also ImageSegment) are broken due to missing #convertToCurrentVersion:refStream: -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient License Update
On 09/09/2010 03:27, Andreas Raab wrote: For string concatenation on the other hand, we're basically talking about dispersing a whole load of FUD about all the things that "may" go wrong. Fact is, nothing actually *does* go wrong with the change, but the change does fix situations that are *very* difficult to handle otherwise. One of the unfortunate realities of string concatenation is that it's very often used around error messages and logging, often in corner cases that aren't well tested, like: ifTrue:[ self log: 'Found impossible condition: ', foo. ]. I'm not sure how important this is considered in Squeak/Pharo, especially in this context, but isn't this sort of output string manipulation a definite no-no from an i18n viewpoint? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient License Update
On Sep 9, 2010, at 4:27 50AM, Andreas Raab wrote: > Phillipe wrote: > > Did you change your position towards #squeakToUtf8 and string > > concatenation (I didn't follow the entire previous thread)? > > Implicitly yes, but let's discuss this. You're saying you want WebClient > "without overrides" but is this really what you mean? The only reason these > methods are marked overrides is so that they don't kill your system if the > methods themselves get added to the system at some point. For example, Grease > currently adds extension methods for Collection>>sorted but these methods are > already in Squeak and while nothing harmful happens if you load Grease, > unloading it will destroy several methods. As a consequence it is vastly > advantageous to mark methods as overrides if they have even the slightest > possibility to conflict (but of course if you'd rather have them > straightforward extensions, I have no problems with that). > > As for integrating the changes itself, I think that we're talking two very > different issues here. I suspect that the only objection to #squeakToUtf8 and > #utf8ToSqueak is that they have "Squeak" in their name. I don't think you'd > have any objection if they would've been called #utf8Encoded and > #utf8Decoded. Which, honestly, is a childish attitude from my point of view. Yeesh. I can only speak for myself, but my objection to the methods is more that I don't think knowing how to change its contents to a specific encoding should be the responsibility of the String class. Yes, there are plenty of other comparable delegations of responsibility, but in this case it is easily avoided. Sure though, it's a bit faster in some cases than the alternatives using convertToWithConverter:, or convertToEncoding: (at least with a symbol -> converter cache added), but with the general improvements to UTF8TextConverter the speedup is no longer measured in the orders of magnitudes, where it might feel worth it (to me). > > For string concatenation on the other hand, we're basically talking about > dispersing a whole load of FUD about all the things that "may" go wrong. Fact > is, nothing actually *does* go wrong with the change, but the change does fix > situations that are *very* difficult to handle otherwise. One of the > unfortunate realities of string concatenation is that it's very often used > around error messages and logging, often in corner cases that aren't well > tested, like: > > ifTrue:[ > self log: 'Found impossible condition: ', foo. > ]. > > The problem with these uses is that it's quite easy to forget some asString, > or #printString (for example, if you generally had expected foo to be a > string but in the impossible condition it's actually nil) and when you hit > the condition your logging screws up and instead of getting informed about > the impossible condition the program quits due to the error. In fact, I'm > willing to bet that there's at least one bug in Pharo and/or Seaside which is > the result of erroneous string concatenation of this kind. It's just very > easy to get wrong. > > The other relevant bit about this change is that it's entirely type-safe. > I.e., the return type does not depend on the argument, the return type is > always a string. That means that the change does *not* introduce failures > down the road due to type violations. It *does* mean that if you have a bug > in your code you might print "a SomethingOrOther" when you didn't mean to, > but unless you're the kind of person who believes that a program that doesn't > raise an error must be obviously correct, this makes little difference. The > only difference it makes is that your program will not abort when the > *intention* is so utterly obvious. > > Put differently, the change adds nothing but robustness to the system. There > is really no data to back up the FUD about all the changes that "may" go > wrong, but from my experience there is ample evidence to show that logging > and error handling involving string concatenation is highly susceptible to > this kind of problem and generally not very well tested and difficult to QA. > And the major use of string concatenation is right in these areas. While I see some value in your arguments, in addition to Pharo, at least the VW, GST and ST-X dialects, plus the ANSI standard, do not allow it. IE, if you want to write your code the least bit portable, you include the ugly as/printString sends. Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
