January 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3519 in pharo: EventHandlerPlus

by pharo＠googlecode.com

Status: Accepted Owner: stephane.ducasse Labels: Milestone-1.3 New issue 3519 by stephane.ducasse: EventHandlerPlus http://code.google.com/p/pharo/issues/detail?id=3519 We should check EventHandlerPlus. Probably this was in polymorph to extend Squeak

Jan. 7, 2011

Re: [Pharo-project] Origins [poll]

by Esteban Lorenzano

Jan. 7, 2011

[Pharo-project] About using pragma for help like in setting

by Torsten Bergmann

Dont confuse this, marking with <systemHelp> does not mean you mark a method that returns a string and it magically appears in the system help. This pragma is used to mark "help types" that should be included in the SystemHelp. Classes marked with this pragma are converted to to a help topic (#asHelpTopic) and using subtopics for SystemHelp. This allows to easily "register" own help types like the WikiStyleHelp. So this pragma is for people WHO WISH TO EXTEND the help system itself (for new syntaxes, new help contents sources, ... without patching it). This pragma is NOT FOR END USERS who want to write help contents. There is no difference since issue #3511 is integrated since CustomHelp is the only provider of <systemHelp> so for. Anything thats changed is the way SystemHelp (which is used as default in HelpBrowser) queries for its roots. If you load the WikiStyleHelp you have another provider of system help. Your scenario is different: =========================== - you want to write help contents that should load in 1.1. and 1.2 and display at least in 1.2 If it is OK for you to have a special help package with the dependency on the help framework: => use a CustomHelp subclass since this is supported in 1.1. and 1.2 (loads and displays in both) If this (dependency) is a "no-go" then describe it using the <wikiStyle> pragma => it is loadable in both, but not displayed in both => it will only appear in 1.2 if we either integrate "WikiStyleHelp" into core or dev image or you load the wiki style help extension it with your soup config Thats why I would like to see Alains idea pushed into 1.2. (either as part of Help system in 1.2-core or as an help extension package in 1.2-dev). Bye T. -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

Jan. 7, 2011

Re: [Pharo-project] About preloaded packages

by Miguel CobÃ¡

I concur with Mariano and wonder why StÃ©phane wants a smaller dev image? Right now there are two images, the core and the dev. As the core is promoted for deploying, the size of the dev isn't an issue. At least in terms of deploying. Now the dev image is currently targeted to new users, so I think that it should have everything that is know to work in Pharo loaded, so that the users doesn't have to cope with the installation issue of new packages. This also means that tutorials and documentation can be straightforward. Just showing what they want to teach, and not explaining what to do to install some random package. So this will help document and promote Pharo. Now maybe the name dev is misleading. It says development although the image is for everyone that is not deploying some application. On the other side, there isn't officially a dev image, only PharoCore and Pharo. So maybe we need to create a official PharoDev image targeted to the developers but this is also very subjective as what packages made a development environment, it is upon the developer. So maybe this make no sense at all. So the options are: 1. Refer to Pharo dev as Pharo, the official name and officially make it targeted to new users and so include everything under the sun (like the fun images of Edgar, that can show off the capabilities of Pharo) 2. Create a PharoDev, with a list of common dev packages, also officially supported TL;DR; Pharo is for new users and should include everything preloaded. PharoCore is for deploying and the developer install just what he wants. Maybe a PharoDev is needed targeted directly to developers. Cheers -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Jan. 7, 2011

[Pharo-project] Issue 3518 in pharo: #warningAllowed does not handle UndeclaredVariableWarning

by pharo＠googlecode.com

Status: Accepted Owner: hernan.m...(a)gmail.com Labels: Type-RequestForEnhancement Difficulty-Easy New issue 3518 by hernan.m...(a)gmail.com: #warningAllowed does not handle UndeclaredVariableWarning http://code.google.com/p/pharo/issues/detail?id=3518 Pharo image: Pharo-1.1.1-- Pharo core version: Latest update: #11414 Virtual machine used: Squeak 3.11.4 (beta) from Aug 27 2009 Steps to reproduce: " Set the environment to warn the user about parsing exceptions " Parser warnUser. Parser warningAllowed = true or: [self error]. Transcript open. " Let's signal the exception " Compiler evaluate: 'a'. " Now set the silent behavior " Parser silent. Parser warningAllowed = false or: [self error]. " But the exception still notifies the user " Compiler evaluate: 'b'. [Compiler evaluate: 'b'] on: UndeclaredVariableWarning do: [:ex | self error] because of this if you want to compile programatically without user intervention you must handle every compilation warning like: [ Compiler new compile: aString classified: aCategoryClassification ] on: UndeclaredVariableWarning do: [: ex | self log: 'Warning UndeclaredVariableWarning in ' , self targetClass asString , '>>' , aString asString ] Proposed fix is attached. However you should 1) Take care because #undeclared is trying to do 2 things: a) Handling the interactive and non-interactive user notification. b) Handling the Undeclared global behavior. 2) Review what default behavior do you want. Should the warningAllowed cover the requestor interactive too? 3) Consider implementing two preferences : logging preferences and notifying preferences (they are not the same). I guess it's for the long term when a good logging framework is going to be integrated in the system. Attachments: Encoder-undeclared.st 1.0 KB

Jan. 7, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

by pharo＠googlecode.com

Comment #17 on issue 3436 by step...(a)stack.nl: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 Nicolas wrote: > Because you have two ways to copy a string : > - a copy of the full string > - a partial copy from start index to stop index > does this POV makes it clearer ? This does not help, as we also have a.o. - allButFirst: - allButLast: - first: - last: -reverse: - sortBy: and compare to: - after: - before: - appendTo: - sort: and then to: - copyEmpty or even to: - truncateWithElipsisTo: How am I supposed to know if I change the original vs get a copy?

Jan. 7, 2011

[Pharo-project] Issue 3517 in pharo: Failing test AutomaticMethodCategorizerOB

by pharo＠googlecode.com

Status: Accepted Owner: marcus.denker Labels: Milestone-1.2-DevImage New issue 3517 by marcus.denker: Failing test AutomaticMethodCategorizerOB http://code.google.com/p/pharo/issues/detail?id=3517 >>> AutomaticMethodCategorizerOB.Tests.OBCmdAutoCategorizeWithAMCTest.testOBAutocategorizeCommandOverride >>> >>> 0.014 15

Jan. 7, 2011

Re: [Pharo-project] About using pragma for help like in setting

by StÃ©phane Ducasse

Hi Torsten I have a simple question: I'm adding help to soup (which works in 1.1) and I would like to add the help in 1.2 but that I can load the same configuration in 1.1 and 1.2 so I could use <systemHelp> and if the help is not in 1.1 is not there then no help, no problem and if the help is in 1.2 then we get the help Now how <systemHelp> tagged methods work. With settings I can see the api but with Help I do not get it. Of course I could use CustomHelp but I would have to change my config for 1.1 and .... boring Stef

Jan. 7, 2011

[Pharo-project] Issue 3516 in pharo: Failing tests in MetaCello

by pharo＠googlecode.com

Status: Accepted Owner: marcus.denker Labels: Milestone-1.2-DevImage New issue 3516 by marcus.denker: Failing tests in MetaCello http://code.google.com/p/pharo/issues/detail?id=3516 >>> Metacello.TestsReference.MetacelloReferenceTestCase.testReferenceConfig >>> 0.0020 9 >>> Metacello.TestsReference.MetacelloReferenceTestCase.testReferenceConfigPrintString >>> >>> 0.0060 9

Jan. 7, 2011

[Pharo-project] Issue 3515 in pharo: Failing Test: RBInlineMethodFromComponentTest.testInlineEmptyComponentMethod

by pharo＠googlecode.com

Status: Accepted Owner: marcus.denker Labels: Milestone-1.2-DevImage New issue 3515 by marcus.denker: Failing Test: RBInlineMethodFromComponentTest.testInlineEmptyComponentMethod http://code.google.com/p/pharo/issues/detail?id=3515 RBInlineMethodFromComponentTest.testInlineEmptyComponentMethod

Jan. 7, 2011