- Pharo-dev - lists.pharo.org

Re: [Pharo-project] who is maintaining shout?

by Lukas Renggli

I do. 2010/10/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Oct. 12, 2010

[Pharo-project] FreeType and finalization

by Gary Chambers

Hi all, I've encountered a problem with FreeType with respect to the new finalization scheme. http://code.google.com/p/pharo/issues/detail?id=3096 Regards, Gary

Oct. 12, 2010

[Pharo-project] who is maintaining shout?

by StÃ©phane Ducasse

Stef

Oct. 12, 2010

[Pharo-project] [update 1.2] #12192

by StÃ©phane Ducasse

12192 ----- - Issue 2883: UITheme Pro. - Issue 3072: System error handling fail on changing Integer>>+. Thanks johan fabry. Stef

Oct. 12, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Henrik Johansen

On Oct 11, 2010, at 10:17 18PM, Igor Stasenko wrote: > On 11 October 2010 22:49, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> Sig, >> >> The most important words in there are "critical section." Carry on :) >> > > Oh, please. This is not too hard to code. > > My mind rolling around following choice(s) (there may be others i don't see). > What would be a proper way to handle error during #finalize. > > [ executor finalize ] on: Error do: [:ex | > self handleFinalizationError: ex "where self is registry" > ]. > > or: > > [ executor finalize ] on: Error do: [:ex | > executor handleFinalizationError: ex > ]. > > > of course, i should catch this error in test, so i can verify that: > > a) test is get notified upon synthetically made error > b) no matter what i do inside error handler (up to 'Processor > activeProcess terminate'), a finalization process continues working > (or restarts without losing remainder of executors). > I agree it should be the executor doing handling. However, if you get to this point, the executor already had the chance to do so in the finalize method itself, so I don't really see the point of sending it back.. Personally, I feel the only promises FinalizationRegistry should make wrt. to errors during finalization, is it should never lead to: - termination of the (or a) finalization process, - discarding another finalization action. IE I am perfectly fine with an error here being thrown in your face (hopefully in a somewhat debuggable way, unlike what happened in your first example when removing the error-swallowing), as you've already passed the point a correction should be made, and there's nothing more intelligible to do than making sure everything keeps working, and inform of the error. (Pretty sure the error swallowing was a quick hack for keeping everything working in the first place ;) ) Cheers, Henry

Oct. 12, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Henrik Johansen

Den 11. okt. 2010 kl. 22:17 skrev Igor Stasenko <siguctua(a)gmail.com>: > > Also, i used #ensure: and #ifCurtailed: but i tend to forget where > they are applicable and how. > So, little help in this regard will be wellcome. Ensure: block always execute. IfCurtailed blocks only run if an error is encountered, or the thread is terminated. Cheers, Henry

Oct. 12, 2010

Re: [Pharo-project] Collaboractive book chapter 10

by StÃ©phane Ducasse

Thanks ALOT!!!! On Oct 12, 2010, at 11:27 AM, Simon Denier wrote: > > I did a large pass to reorganize stuff around so that it gets more consistent, starting with basic stuff and advancing towards the more technical stuff. > > Chapters "How to contribute" and "3D Graphics and OpenGL" are nearly empty > > > On 12 oct. 2010, at 10:20, Simon Denier wrote: > >> I'm fixing ordering in book chapters >> >> For some reasons, two chapters (Customizing Pharo and Pharo Tools) were created as children of Table-Of-Contents, and they pushed everything down. >> >> Also I notice that a figure was created as a child of Table-Of-Figures, I have no idea where it should go >> http://book.pharo-project.org/book/table-of-figures/RepositoryEnvironment >> >> >> On 12 oct. 2010, at 09:07, Norbert Hartl wrote: >> >>> I just had a look at the book and wondered why the chapter introduction is chapter 10. Looks like it is supposed to be 1 or 2 >>> >>> Norbert >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> Simon >> >> >> > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 12, 2010

[Pharo-project] Fwd: License question

by StÃ©phane Ducasse

Begin forwarded message: > From: Paolo Bonzini <bonzini(a)gnu.org> > Date: October 12, 2010 10:43:25 AM GMT+02:00 > To: "Fitzell, Julian" <jfitzell(a)cincom.com> > Cc: stephane.ducasse(a)inria.fr, BSchwab(a)anest.ufl.edu, paolo.bonzini(a)usi.ch > Subject: Re: [Pharo-project] License question > > On 10/12/2010 10:37 AM, Paolo Bonzini wrote: >> >> It's tricky terrain, but the FSF itself did it multiple times with its >> "provide a free replacement for a non-free package" policy. It's one of >> the few areas in which you'll hear me saying their evaluation criteria >> is biased ("if you use this to make a free derivative it's fine, if you >> use this to make a non-copyleft derivative it's not"). >> >> However, in this case it doesn't apply. What I suggested is to copy the >> API of an existing non-copyleft package (Didier Besset's numerical >> methods) and use it in the GPL'd bindings that BSchwab (I think) wrote >> for GSL. > > Hmm, an old post suggests that the code from numerical methods is under the LGPL. So, this is not a feasible way to get it under MIT. > > Paolo

Oct. 12, 2010

[Pharo-project] Fwd: License question

by StÃ©phane Ducasse

Begin forwarded message: > From: Paolo Bonzini <bonzini(a)gnu.org> > Date: October 12, 2010 10:37:35 AM GMT+02:00 > To: "Fitzell, Julian" <jfitzell(a)cincom.com> > Cc: stephane.ducasse(a)inria.fr, BSchwab(a)anest.ufl.edu, paolo.bonzini(a)usi.ch > Subject: Re: [Pharo-project] License question > > On 10/12/2010 10:00 AM, Fitzell, Julian wrote: >> Are you sure? I've heard opinions expressed that looking at a library >> and copying the API might constitute a derivative work. > > It's tricky terrain, but the FSF itself did it multiple times with its "provide a free replacement for a non-free package" policy. It's one of the few areas in which you'll hear me saying their evaluation criteria is biased ("if you use this to make a free derivative it's fine, if you use this to make a non-copyleft derivative it's not"). > > However, in this case it doesn't apply. What I suggested is to copy the API of an existing non-copyleft package (Didier Besset's numerical methods) and use it in the GPL'd bindings that BSchwab (I think) wrote for GSL. > > Paolo

Oct. 12, 2010

[Pharo-project] Fwd: License question

by StÃ©phane Ducasse

Begin forwarded message: > From: "Fitzell, Julian" <jfitzell(a)cincom.com> > Date: October 12, 2010 10:00:56 AM GMT+02:00 > To: <bonzini(a)gnu.org>, <stephane.ducasse(a)inria.fr> > Cc: <BSchwab(a)anest.ufl.edu>, <paolo.bonzini(a)usi.ch> > Subject: Re: [Pharo-project] License question > > Are you sure? I've heard opinions expressed that looking at a library and copying the API might constitute a derivative work. > > I'm not certain if that's correct or not but if you're purposely trying to skirt the terms of the GPL, you might want to make certain. > > Julian > > ----- Original Message ----- > From: Paolo Bonzini <paolo.bonzini(a)gmail.com> > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Cc: Fitzell, Julian; Wilhelm K Schwab <BSchwab(a)anest.ufl.edu>; Bonzini Paolo <paolo.bonzini(a)usi.ch> > Sent: Tue Oct 12 08:47:56 2010 > Subject: Re: [Pharo-project] License question > > On 10/12/2010 09:35 AM, Paolo Bonzini wrote: > > On 10/11/2010 11:29 PM, StÃ©phane Ducasse wrote: > >>>> Let's go forward in time. NativeBoost, Alien or FFI provide > >>>> callbacks, I do some adaptation on my end, and out comes a pretty > >>>> capable wrapper for the GNU Scientific Library. That sentence > >>>> trivializes a LOT of work :( Details aside, is the wrapper code > >>>> itself affected by GPL > > > > Yes. > > That said, there is a way out. You could have a simple-minded library > which has the same interface as the bindings but is written in pure > Smalltalk. Then, the same thing can run fast under the GPL, or slow > under MIT license. > > I meant to do this exactly for GSL for a long time, making it compatible > with the code from "Object-Oriented Implementation of Numerical Methods" > so that it could act as a fallback. However, I never even started it. > > http://www.amazon.com/Object-Oriented-Implementation-Numerical-Methods-Intr… > > Paolo >

Oct. 12, 2010