October 2010 - Pharo-dev - lists.pharo.org

[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

Re: [Pharo-project] Collaboractive book chapter 10

by Simon Denier

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

Oct. 12, 2010

Re: [Pharo-project] Collaboractive book chapter 10

by Simon Denier

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

Oct. 12, 2010

Re: [Pharo-project] Issue 3090: Context not included in ImageSegment when saving morph to file

by Mariano Martinez Peck

Hi Sheridan. I tried to fix it last night, but didn't succeed. Few notes: - I could reproduce it - The problem seems in writing a MethodContext since ContextPart >> storeDataOn: throws the error - ImageSegment is NOT BEING USED AT ALL. I just implement #new in ImageSegment to put a halt there, and nothing. No IS instance in created And...if you see the method ContextPart >> storeDataOn: it does: self error: 'This Context was not included in the ImageSegment'. "or perhaps ImageSegments were not used at all" notice the comment - In Squeak 4.1 save morph to file seems to be working. You can try to see why and compare. What I think is that in Squeak 4.1 maybe you don't have MethodContext (I put a halt in COntextOart >> storeDataOn: and never passes) to serialize and then this is what it works. I say this because in my case the MethodContext was something related to Polymorph (that it is not included in Squeak). Maybe that's the difference or maybe we broke something why cleaning Pharo. - I don't think it is related to Closures Cheers Mariano On Mon, Oct 11, 2010 at 11:04 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > For convenience, this is the link to the issue: > > http://code.google.com/p/pharo/issues/detail?id=3090 > > I suspect that this bug is related to the new block closures. > > Adrian > > On Oct 11, 2010, at 07:15 , Sheridan Mahoney wrote: > > > I've just re-entered the Pharo world after a long(ish) absence, and > wanted to report a > > new bug submission; here's the breakdown: > > > > Pharo image: dev > > Pharo core version: Pharo-1.1.1-- Latest update: #11414 > > Virtual machine used: 4.0.3.2202 Unix VM > > OS: Ubuntu Lucid Lynx 10.04 > > Class browser used if applicable: SystemBrowser default > > > > > > Steps to reproduce: > > > > 1. start pharo > > 2. open a Shout workspace > > 3. select the just-opened workspace > > 4. Ctrl-right button to get the meta-click window > > 5. select 'save morph in file' > > 6. hit 'ok' to proffered name for file > > 7. a message box comes up that reads 'please wait while objects are > > counted'. > > 8. shortly after that an error is generated: > > 'Error: this context was not included in the ImageSegment' > > > > > > > > I'm planning on doing more research, but wanted to get the issue > reported. > > > > Cheers, > > Sheridan > > > > PS - so far I really like 1.1.1 !!! Good work, gang! > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > 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