- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

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

Sept. 9, 2010

Re: [Pharo-project] Cog Segmentation Fault with Pharo 1.1

by GermÃ¡n Arduino

ahh, Thanks Levente, sorry was my fault, I forgot this detail. 2010/9/9 Levente Uzonyi <leves(a)elte.hu>: > 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Â <gsa @ arsol.net>Â Â Twitter: garduino >> Arduino Software & Web HostingÂ Â http://www.arduinosoftware.com >> PasswordsProÂ http://www.passwordspro.com >> ================================================= > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 9, 2010

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

by Levente Uzonyi

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(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 9, 2010

Re: [Pharo-project] Cog Segmentation Fault with Pharo 1.1

by 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Â <gsa @ arsol.net>Â Â Twitter: garduino > Arduino Software & Web HostingÂ Â http://www.arduinosoftware.com > PasswordsProÂ http://www.passwordspro.com > ================================================= >

Sept. 9, 2010

[Pharo-project] Cog Segmentation Fault with Pharo 1.1

by GermÃ¡n Arduino

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Â <gsa @ arsol.net>Â Â Twitter: garduino Arduino Software & Web HostingÂ Â http://www.arduinosoftware.com PasswordsProÂ http://www.passwordspro.com =================================================

Sept. 9, 2010

Re: [Pharo-project] Changing the world menu

by StÃ©phane Ducasse

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(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 9, 2010

Re: [Pharo-project] Building Cocoa 5.x series plugins, and testing help needed.

by Philippe Marschall

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

Sept. 9, 2010

[Pharo-project] [ANN] Aida/Web 6.1 released

by Janko MivÅ¡ek

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

Sept. 9, 2010

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

by Miguel Enrique CobÃ¡ MartÃnez

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(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Sept. 9, 2010

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

by Lukas Renggli

> 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

Sept. 9, 2010