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

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

by csrabak＠bol.com.br

+1 If you accept a two phase approach (as I understood Seaside may be heavily impacted): 1) Let's add add copyFrom: in Sequenceable as self copyFrom: a to: self size; 1.1) Test for issues with Seaside/Mondrian, etc., i.e., all production environments, if they come green from this mod, commit. 2) Do the deprecation protocol in Object>>copyFrom: (adding Object>>copyStateFrom:). 3) Remove Object>>copyFrom: Regards, -- Cesar Rabak Em 08/01/2011 12:22, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: What we will do is deprecate copyFrom: from Object -> copyStateFrom: add copyFrom: in Sequenceable as self copyFrom: a to: self size Stef

Jan. 8, 2011

Re: [Pharo-project] [Seaside-dev] Seaside and exception behaviour

by Julian Fitzell

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

Jan. 8, 2011

Re: [Pharo-project] [squeak-dev] Announcements in core images?

by Mariano Martinez Peck

2011/1/7 Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > 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? > Hi Janko. I don't know anything about announcments, but I can tell you they are integrated in pharo core, and its tests are green. I don't know if they are being used by the core itself but I think there are external packages that use them. > > 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 > >

Jan. 8, 2011

[Pharo-project] Basic rules of life in this team!

by StÃ©phane Ducasse

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

Jan. 8, 2011

Re: [Pharo-project] Issue 3262 in pharo: Debugger enhancement to open in a background process when the UI process is busy

by pharo＠googlecode.com

Updates: Labels: Milestone-1.3 Comment #4 on issue 3262 by stephane.ducasse: Debugger enhancement to open in a background process when the UI process is busy http://code.google.com/p/pharo/issues/detail?id=3262 (No comment was entered for this change.)

Jan. 8, 2011

Re: [Pharo-project] About preloaded packages

by StÃ©phane Ducasse

On Jan 8, 2011, at 4:42 PM, Schwab,Wilhelm K wrote: > Stef, > > I'm not sure I follow. I think we agree that loading all configurations and running tests is good. I meant that the configurations do not have to be loaded in the image. > I understand why the web image went away when it took somebody's time time build it, but the Hudson server can do that work now. It seems reasonable to leave a range of targets that might be of value to people. yes now somebody should maintain the configuration and fix conflict. > There could be a few likely useful targets (minimal, dev, web) and then one with absolutely everything that is mostly for testing. But if somebody wants to use that, why not leave it on the server so they can get it? because who maintains if there is a bug due to a conflict. Building the seaside image took lukas time and effort. I'm learned that things do not magically work. So if somebody stands up and say ok I'm responsible for the imageXZK why not and we can set up hudson to build it. Now we (the core minimal team) should spend time on getting the infrastructure right on tracks because this is an enabler of the future. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Saturday, January 08, 2011 10:30 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] About preloaded packages > >> It would also like a PharoBloat image built by Hudson with all ConfigurationOfXXX which are supposed to work on all operating systems. > > Not loaded :) > Just published in the right squeaksource repository and validated (run, tests run and results shown....) via an hudson server. >

Jan. 8, 2011

Re: [Pharo-project] About preloaded packages

by Schwab,Wilhelm K

Stef, I'm not sure I follow. I think we agree that loading all configurations and running tests is good. I understand why the web image went away when it took somebody's time time build it, but the Hudson server can do that work now. It seems reasonable to leave a range of targets that might be of value to people. There could be a few likely useful targets (minimal, dev, web) and then one with absolutely everything that is mostly for testing. But if somebody wants to use that, why not leave it on the server so they can get it? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Saturday, January 08, 2011 10:30 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] About preloaded packages > It would also like a PharoBloat image built by Hudson with all ConfigurationOfXXX which are supposed to work on all operating systems. Not loaded :) Just published in the right squeaksource repository and validated (run, tests run and results shown....) via an hudson server.

Jan. 8, 2011

Re: [Pharo-project] About preloaded packages

by Schwab,Wilhelm K

My concern about Metacello has always been that while it is terribly easy to use, it is very potentially difficult to know what to ask it to do. I *think* I have seen signs of improvement and increasing uniformity since I began playing with 1.2. The ConfigurationBrowser probably brought the confusion to light. The ConfiguationBrowser's load latest version command will either force a direct way to do that on all configurations (or at least stand as a reference on how to do it by reflecting on the configuration), but then there is another, bigger, and (I suspect) unsolvable problem: knowing which version to load of any given package. That is a good problem to have (lots of stuff being developed), but we have to acknowledge it. Laurent's Pharo-bloat idea is interesting. While it is not a build target that I would probably want to use, it makes a lot of sense for the Pharo brand to load the latest stable version of just about everything and report on test results. There will still be quirks: when did/does Seaside 3.0 replace 2.8? Of course, one can always start with the core and build anything, but the Pharo Hudson server probably should build things including: (1) recommended Pharo/Pharo-dev - whatever you want to call it, but it's a good starting point for general use; (2) Pharo web, above plus Seaside, Magritte; ... (n) Pharo-package-testing - everything, primarily to see if it builds and to get test results Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Saturday, January 08, 2011 9:00 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] About preloaded packages > I would also be rather conservative with regard to adding packages that are not developer tools. > > If we add XML we should probably also add XYZ. Wouldn't it make sense to add Seaside too? The problem here is not primarily the larger image file size, but the image becomes bloated in general (e.g., search results) and there's a risk of conflicts (e.g., we are using the pharo-dev image, but with our own Seaisde 2.9 version; if the image comes with a preinstalled Seaside 3, we couldn't use it anymore). > > It appears to me that preloading packages like XML is just points out that a good package manager is missing. Yes for example moose people get problem because when they load the latest version of XMLsupport on pharodev1.2 the system barks. While pharo-dev (with tools not frameworks) is an ok image to build systems like moose. Stef

Jan. 8, 2011

Re: [Pharo-project] Issue 3224 in pharo: Migrating MethodReference to MethodReferenceWithSource

by pharo＠googlecode.com

Comment #13 on issue 3224 by Benjamin.VanRyseghem.Pharo: Migrating MethodReference to MethodReferenceWithSource http://code.google.com/p/pharo/issues/detail?id=3224 Here are two new change set which fix a little bit the SourceReference API and fix some tests. The order matters. With that, only two error tests left, but I do not know why Attachments: FixingSourceReferenceChangingTimeStampIntoAString.1.cs 4.5 KB FixTestsForSourcedMethodReference.1.cs 2.4 KB

Jan. 8, 2011

Re: [Pharo-project] About preloaded packages

by StÃ©phane Ducasse

> Because we have to fix bug of packages that we do not know, control, want to fix... > Because been agile to load and having a good infrastructure for validating packages is way more > important than preloading XML. If we spend our time on the infrastructure (metacello publication, > configuration certification, hudson reporting) then the complete ecosystem will get better > and you should be able to automate several builds and pharo-dev whatever. > > I'm concerned that our resources are limited and they are a lot of ugly ugly things in the system > Now not everybody should work on them but then the insfrastructure is more important. > > > I agree that we should care about what packages are included in Pharo. But actually for newbies it's still complicated to discover and learn how to load a ConfigurationOfXXX. > > So one goal of Pharo 1.3 should be to have a GUI to load additional tools / libs / frameworks in one click (I've seen there's one included, that's a good step forward, but some work is needed). The tool is already there as torsten mentioned. Now what is missing are configurationOf published in the right squeaksource folders. > For Pharo 1.2 I'd rather leave XML in because today I expect that every programming environment used in enterprise supports XML out of the box. why ruby, python, .... java does it without an import statement? > It would also like a PharoBloat image built by Hudson with all ConfigurationOfXXX which are supposed to work on all operating systems. Not loaded :) Just published in the right squeaksource repository and validated (run, tests run and results shown....) via an hudson server.

Jan. 8, 2011