- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken (pharo@googlecode.com)

by Stephan Eggermont

Nicolas wrote: >Then group the selectors (first, first: etc..), explain that they are >extensions, and don't need a copy prefix, because anyway most messages >will do a copy. You are aware first doesn't copy, do you? The explanation should be that you always have to take a look at the implementation to see if it copies or not (or sometimes), and explain when it doesn't matter (small integers, characters). Stephan

Jan. 8, 2011

Re: [Pharo-project] TODO 1.2

by Mariano Martinez Peck

Thanks Marcus for the summary. We need people to help on this! mariano On Fri, Jan 7, 2011 at 3:04 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > 1) Core: > > - Failing Tests: 8 > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.2/lastCompleted… > - Open Bug Tracker entries: 15 > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2 > > > 2) Full: > - Failing tests: 8 + 11 > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/lastCompletedBuild/t… > - Open Bug Tracker entries: 13 > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2-DevImage > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

Jan. 8, 2011

Re: [Pharo-project] Including Zinc HTTP Components in Pharo 1.2 Dev ?

by Igor Stasenko

On 7 January 2011 20:07, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > I was in meeting all day, hence the late reply. > > On 07 Jan 2011, at 14:08, StÃ©phane Ducasse wrote: > >> Sven >> >> two questions: >> Â Â Â - if we want to use zn for pharo to replace HTTPSocket, don't you think that Zinc-HTTP-Client-Server should be split into pieces. > > I don't think that would make a lot of sense: HTTP is a client-server protocol, the client and server sides have a lot in common; a split in three pieces would be possible but each piece would be rather small. Having the necessary pieces for a simple HTTP server present will lower the bar for others, so that makes sense too. (For example, the Seaside adaptor is really very little code, no more need for Kom unless you really want it). > >> Â Â Â - do you think that some parts of zinc could be reused to implement other protocols such as POP, SMTP, IMAP? > > Maybe, finding shared code can only be done by doing both implementations I'm afraid ;-) > > Another, related point is the following: maybe you noticed browsing the code that I have a number of classes in Zn that redo some standard functionality (ZnMimeType, ZnUrl, ZnCharacterEncoder, and some of the code in the utils classes), a bit like Seaside does. The reason is that the existing classes were broken beyond repair (IMHO), or that I was not confortable extending them. Now, if the existing classes could be improved/replaced, it would make sense to replace the Zn variant with a good system wide one. This is a search for the best solution. > well it would be good to have these classes fixed, and make zinc using them. because these ones are needed thoughout entire system, and certainty, for things like mime-type , there could be code which can handle certain type(s), but know nothing about Zinc. > Sven > -- Best regards, Igor Stasenko AKA sig.

Jan. 8, 2011

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

by StÃ©phane Ducasse

sorry this mail was for our team at lille. Stef On Jan 8, 2011, at 5:13 PM, StÃ©phane Ducasse wrote: > 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] [squeak-dev] Announcements in core images?

by StÃ©phane Ducasse

On Jan 8, 2011, at 5:16 PM, Mariano Martinez Peck wrote: > > > 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. They start and we will migrate to 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

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