- Pharo-dev - lists.pharo.org

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=mac/… 1 regressions found. Tests.Release.ReleaseTest.testUnknownProcesses

July 11, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linu… 1 regressions found. Tests.CodeImport.ChunkImportTestCase.testImportAClassCategory

July 11, 2013

Re: [Pharo-dev] [Update 3.0] 30265

by Sebastian Tleye

Excellent!! 2013/7/11 Esteban Lorenzano <estebanlm(a)gmail.com> > 11151 More changes needed to trait/classes polymorphism > https://pharo.fogbugz.com/f/cases/11151/ > > (pass 2) > >

July 11, 2013

[Update 3.0] 30265

by Esteban Lorenzano

11151 More changes needed to trait/classes polymorphism https://pharo.fogbugz.com/f/cases/11151/ (pass 2)

July 11, 2013

Re: [Pharo-dev] Notification extends Exception...

by Sven Van Caekenberghe

On 11 Jul 2013, at 16:08, Vincent Blondeau <vincent.blondeau(a)polytech-lille.net> wrote: > Le 11/07/2013 15:42, Sven Van Caekenberghe a Ã©crit : >> Vincent, >> >> On 11 Jul 2013, at 15:06, Vincent Blondeau <vincent.blondeau(a)polytech-lille.net> wrote: >> >>> I use a Zinc Server. So when I do the request, Zinc catch the Exception and send an error as response. >> ZnSingleThreadedServer>>#handleRequestProtected: request >> "Handle request and return a response. >> If a Smalltalk Error is thrown, return a HTTP Server Error response." >> >> ^ [ self authenticateAndDelegateRequest: request ] >> on: Error >> do: [ :exception | >> self debugMode >> ifTrue: [ exception pass ] >> ifFalse: [ >> self logServerError: exception. >> ZnResponse serverError: exception printString ] ] >> >> AFAICT this code catches Error, not Exception, hence it would let Notification through. No ? >> >> Sven >> >> > Indeed but I use the Zinc-Rest-Server and all Exceptions are caught: > > ZnRestServerDelegate>>handleRequest: request > | call | > (call := self match: request) > ifNil: [ ^ self noHandlerFound: request ]. > (self authenticate: call) > ifFalse: [ ^ self callUnauthorized: request ]. > ^ [ self execute: call ] > on: Exception > do: [ :exception | > request server debugMode > ifTrue: [ exception pass ] > ifFalse: [ > request server logServerError: exception. > self serverError: request exception: exception ] ] > Indeed. I know why I wrote that (I often write assertions in code, and AssertionFailed is not an Error, hence the broader net) - I will think about it. In the mean time, you could subclass ZnRestServerDelegate and override #handleRequest: Maybe I can also improve the overriding options a bit, like with an introduction of an #exceptionsToCatch accessor. HTH, Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

July 11, 2013

Re: [Pharo-dev] Some Spec questions

by Clara Allende

Great! Thank you guys :) On 11 July 2013 05:17, Andrei Vasile Chis <chisvasileandrei(a)gmail.com>wrote: > > Actually Erwan Douaille is doing WidgetAbstractWrapper to solve this >> problem (I've just learnt that a few minutes ago). You may discuss with him >> about that. >> > > Super. Thanks for all the help and the info > > Andrei >

July 11, 2013

Re: [Pharo-dev] Notification extends Exception...

by Vincent Blondeau

Le 11/07/2013 15:42, Sven Van Caekenberghe a Ã©crit : > Vincent, > > On 11 Jul 2013, at 15:06, Vincent Blondeau <vincent.blondeau(a)polytech-lille.net> wrote: > >> I use a Zinc Server. So when I do the request, Zinc catch the Exception and send an error as response. > ZnSingleThreadedServer>>#handleRequestProtected: request > "Handle request and return a response. > If a Smalltalk Error is thrown, return a HTTP Server Error response." > > ^ [ self authenticateAndDelegateRequest: request ] > on: Error > do: [ :exception | > self debugMode > ifTrue: [ exception pass ] > ifFalse: [ > self logServerError: exception. > ZnResponse serverError: exception printString ] ] > > AFAICT this code catches Error, not Exception, hence it would let Notification through. No ? > > Sven > > Indeed but I use the Zinc-Rest-Server and all Exceptions are caught: ZnRestServerDelegate>>handleRequest: request | call | (call := self match: request) ifNil: [ ^ self noHandlerFound: request ]. (self authenticate: call) ifFalse: [ ^ self callUnauthorized: request ]. ^ [ self execute: call ] on: Exception do: [ :exception | request server debugMode ifTrue: [ exception pass ] ifFalse: [ request server logServerError: exception. self serverError: request exception: exception ] ] Vicnent

July 11, 2013

Re: [Pharo-dev] Some updates to GLorp

by Mariano Martinez Peck

I do agree. But notice that it took me like 2 days to adapt the pool to the native driver, find the problems, fix the bugs, commit fixed, update the confs, etc. So that was already something :) On Thu, Jul 11, 2013 at 4:14 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Jul 10, 2013, at 10:04 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > Hi guys > > I did a couple of things related to Glorp. I commited 2 fixes related to > the connection pool. > Also, for the native postgres driver, I adapted the pool we have for > OpenDBXDriver. It's quite ugly because we are duplicating quite a lot of > code, but the hierarchy make things complicated here and I don't have more > time to improve it (at least not right now). If someone wants to give it a > shoot :) You can give it as an exercise to a student hahaha. > > So...to sum up, some fixes in GlorpOpenDBXDriver and the new connection > pool to > GlorpDriverPostgreSQL. > > > Hi mariano > > I think that this is important that you allocate a certain percentage of > your dev time to improve the tools > you use else there is no possibility of progress. I would not wait for a > student to fix code that > nobody in our team (except esteban probably) ever used. > > Stef > > Cheers, > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

July 11, 2013

Re: [Pharo-dev] Notification extends Exception...

by Sven Van Caekenberghe

Vincent, On 11 Jul 2013, at 15:06, Vincent Blondeau <vincent.blondeau(a)polytech-lille.net> wrote: > I use a Zinc Server. So when I do the request, Zinc catch the Exception and send an error as response. ZnSingleThreadedServer>>#handleRequestProtected: request "Handle request and return a response. If a Smalltalk Error is thrown, return a HTTP Server Error response." ^ [ self authenticateAndDelegateRequest: request ] on: Error do: [ :exception | self debugMode ifTrue: [ exception pass ] ifFalse: [ self logServerError: exception. ZnResponse serverError: exception printString ] ] AFAICT this code catches Error, not Exception, hence it would let Notification through. No ? Sven

July 11, 2013

Re: [Pharo-dev] Notification extends Exception...

by Frank Shearar

On 11 July 2013 14:26, Guillaume Larcheveque <guillaume.larcheveque(a)gmail.com> wrote: > An exception sounds to me like something that is not expected. In my > opinion, a notification is not an exception but just an information. It's a terminology problem. The Smalltalk class Exception does not represent the same thing as the Ruby or Java Exception classes. Smalltalk's Error class is what everyone else calls an exception. A Smalltak Exception is just a thing that can communicate with some other bit of code - a handler - somewhere down the call stack. If you have any familiarity with Common Lisp, you can think of Smalltalk's Exception as a condition [1]. [1] http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-re… frank > Esteban told me that this discussion has already occurs but I was not able > to find it. > > > 2013/7/11 Igor Stasenko <siguctua(a)gmail.com> >> >> On 11 July 2013 15:06, Vincent Blondeau >> <vincent.blondeau(a)polytech-lille.net> wrote: >> > Hi, >> > >> > For Moose on web, I have to implement the loading of a Moose Model by a >> > HTML >> > post request. >> > This request send a file which have to been parsed to create a model. >> > >> > The parsing launch a Job (by an UIManager) and the Job throws a >> > JobStartNotification at his beginning. >> > JobStartNotification is a subclass of Exception. >> > I use a Zinc Server. So when I do the request, Zinc catch the Exception >> > and >> > send an error as response. >> > >> > Has a Notification to be considered like an Exception and not like a >> > catchable object, because it's just some information... ? >> > >> It is not a question that Notification should be an Exception, >> but question, if zinc should treat all exceptions as errors. >> >> > Cheers, >> > Vincent >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Guillaume Larcheveque >

July 11, 2013