- Pharo-dev - lists.pharo.org

[Pharo-project] Basic rules of life in this team!
by StÃ©phane Ducasse Jan. 8, 2011

Jan. 8, 2011

May be this is time to resend this email... sadly. > Hi guys > > apparently gwenael is reading this mailing-list and you too, so could you tell > him that I would appreciate that he replies (not only by email but this is a first step but) by actions > to my mails, if they are of any values of course. Sorry but I'm mad that I have to write this kind of mail. > > Just a point for everybody: > My door is **always** open and you can drop by and say hello I'm here and I'm doing that > when you are back from holidays or when you want. > Saying hello is the first level of communication. > > Second I'm *really* busy BUT YOU are always *more* important that my business so > you can always interrupt me. > > Third, since you do not really know what is to work on several (too many) things at the same > time, focus on your PhD AND push information to me since I'm constantly rescheduling my > tasks list. Pulling information KILLS me and I do not like that. > > Fourth, realize that you are payed more than people at EMD for example mariano. > > Again again again no communication hurts me and I do not like that. > I hate that you do not communicate with me since it makes me losing more time!!!!! > Now again don't get me really mad because I'm a butcher in such case. If this is you or me, this will be you. > > Sad but it seems that I already said that, so may be this is the occasion to learn. > Now I'm sure that if you do not learn life will make it and it will be a pain one day or another. > > Stef

1 1

[Pharo-project] Announcements in core images?
by Janko MivÅ¡ek Jan. 8, 2011

Jan. 8, 2011

Hi both Squeakers and Pharoers, What is a status of Announcements package as part of core images? Are they already there and, are they compatible, and if not, what are the differences? Announcements are namely very important and elegant way of event notifications based on publish/subscribe pattern. And they are portable, which is very important for us, doing cross platform frameworks like Aida, Seaside, etc. Therefore I'd really like to see Announcements included in all Smalltalks by default and at least on API level as same as possible. Best regards Janko -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

3 3

Re: [Pharo-project] [Seaside-dev] Seaside and exception behaviour
by Julian Fitzell Jan. 8, 2011

Jan. 8, 2011

On Wed, Jan 5, 2011 at 8:15 AM, Paolo Bonzini <bonzini(a)gnu.org> wrote: > On 01/05/2011 04:58 PM, mkobetic(a)cincom.com wrote: >> >> > > Â Here's maybe a bit more concise example. If you run the thing below >> > > in a workspace, >> > > Â it returns 'Squeak' in Squeak and 'VW' in VW >> > > >> > > Â [ Â [ Â Â Â [ Â Â Â self error: 'trigger error' >> > > Â Â Â Â Â Â ] on: ZeroDivide do: [ :ex | 'Squeak' ] >> > > Â Â ] on: Error do: [ :ex | 3 / 0 ] >> > > Â ] on: ZeroDivide do: [ :ex | 'VW' ] >> > >> > Â It returns 'Squeak' on GNU Smalltalk. Â This is consistent with my >> > Â analysis of Alan's snippet. Â Unfortunately I don't have at hand my copy >> > Â of the standard. >> >> FWIW, Smalltalk/X returns 'VW' > > That's the correct behavior. Â The standard says the search should proceed > from the last exception handler that was created up to the oldest. Agreed. The ANSI standard seems quite clear about that: 5.4.3.3: "If signaling of an exception results in evaluation of action the evaluation will occur in the context of the handler environment." 5.5.2.1: "If a matching handler is found, the exception action of the handler is evaluated in the exception environment that was current when the handler was created and the state of the current exception environment is preserved as the signaling environment." > (That said, Squeak/gst's behavior is quite easy to justify, as stack > unwinding hasn't happened yet. Â I'll wait for this thread to settle before > changing it in gst). But stack unwinding shouldn't need to happen until one of the #on:do: calls is actually ready to return. Until then, its all just searching. I think Squeak/Pharo's problem is that it doesn't maintain a first class "exception environment" as described by the glossary in the ANSI standard: "An abstract entity that is a LIFO list of exception handlers. An exception environment may be logically searched starting from the most recently "pushed" exception handler." Squeak/Pharo simply (ab)uses the context chain, walking it looking for the next handler (see the implementation of #signal, which always starts searching from thisContext). This works fine most of the time but not when you need to temporarily restore a previous exception environment. #handleSignal: does go to the effort of setting a handlerContext on the signaled exception before calling the action block. This is necessary to implement #pass, #isNested, and so on but would also need to be put somewhere that #signal could get at it to use as a starting point for the search. This seems like a squeak/pharo bug to me. I don't much feel like fixing it in Grease given that Grease is supposed to assume correct ANSI implementation as a pre-requisite. Perhaps we can broker a deal where Squeak/Pharo will fix this and VW (finally) fixes its signaling behaviour so we can drop GRError, etc. entirely. In the meantime, though, how would we fix the Seaside code assuming we had ANSI-correct exception handling implementations? Julian

1 0

[Pharo-project] announcements and weak references
by Tudor Girba Jan. 8, 2011

Jan. 8, 2011

Hi, Are there any plans to get Announcements use weak references? I saw that in the repository of Lukas, there is a WeakAnnouncer. However, here the subscriptions are still held in a regular Dictionary. Actually, I am not sure what is the status of weak references. I tried the following, but it does not seem to work: | x array | x := GLMPane new. array := WeakArray with: x. x := nil. Smalltalk garbageCollect. array size ==> 1 Cheers, Doru -- www.tudorgirba.com "We cannot reach the flow of things unless we let go."

3 6

[Pharo-project] About preloaded packages
by Torsten Bergmann Jan. 8, 2011

Jan. 8, 2011

>I would favor push metacello so that in one click people can load what they >want. You already can. Push the config to the Metacello Repository for 1.2 on squeaksource.com and use the configuration browser. You can then load the config or the lates version with a few clicks. There are questions left/to discuss ... but at least that works already. Bye T. BTW: Squeaksource is down today -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone

3 2

[Pharo-project] About using pragma for help like in setting
by Torsten Bergmann Jan. 8, 2011

Jan. 8, 2011

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

2 1

[Pharo-project] Adding hudson links from pharo webpage?
by Mariano Martinez Peck Jan. 8, 2011

Jan. 8, 2011

Now that hudson seems to be working fine, I think it is a good moment to link hudson links from the pharo website. cheers mariano

3 3

[Pharo-project] What feature you want to see in Mondrian
by Alexandre Bergel Jan. 8, 2011

Jan. 8, 2011

Hi! I am willing to spend some time on Mondrian the coming weeks. I would like to know what are the feature/issue what are the most pressing for you? http://code.google.com/p/moose-technology/issues/list?can=2&q=Mondrian&cols… Lazy edges? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 2

[Pharo-project] Issue 3519 in pharo: EventHandlerPlus
by pharo＠googlecode.com Jan. 7, 2011

Jan. 7, 2011

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

1 1

[Pharo-project] Issue 3518 in pharo: #warningAllowed does not handle UndeclaredVariableWarning
by pharo＠googlecode.com Jan. 7, 2011

Jan. 7, 2011

Status: Accepted Owner: hernan.m...@gmail.com Labels: Type-RequestForEnhancement Difficulty-Easy New issue 3518 by hernan.m...@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

1 0