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

Re: [Pharo-project] FreeType and finalization

by Igor Stasenko

2010/10/12 Gary Chambers <gazzaguru2(a)btinternet.com>: > 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 > FT2HandleRegistry overrides following method: add: anObject "Add anObject to the receiver. Store the object as well as the associated executor." | executor dup | executor := anObject executor. dup := nil. self protected:[ dup := valueDictionary detect: [ :v | v handle = executor handle ] ifNone: [ ]. valueDictionary at: anObject put: executor. ]. dup ifNotNil: [ self error: 'Duplicate object added!'. self remove: anObject ]. ^anObject As i see, the intent is to prevent registering a same handle twice, so in own turn, when time will come, a #finalize won't attempt to destroy same handle twice. The proposed fix (as you wrote in issue tracker) registry ^Registry ifNil: [ Registry := WeakRegistry new] appears to fix the problem... But apparently its not the same as in original. Okay, but since we never seen the error: 'Duplicate object added!', then i think it may work without it :) Still, it would be good to know, how handles are created, and what the chances that they could be duplicated. -- Best regards, Igor Stasenko AKA sig.

Oct. 12, 2010

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

by Lukas Renggli

The code is in the official repository: http://www.squeaksource.com/shout.html On 12 October 2010 14:02, Tobias Pape <Das.Linux(a)gmx.de> wrote: > Am 2010-10-12 um 13:48 schrieb Lukas Renggli: >> I do. >> >> 2010/10/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> Stef > > Do y'all mean generally or for Pharo? > > So Long, > Â Â Â Â -Tobias > > > _______________________________________________ > 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

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

by Lukas Renggli

I closed the issue. On 12 October 2010 14:01, Lukas Renggli <renggli(a)gmail.com> wrote: > I integrated this during ESUG. > > Lukas > > On 12 October 2010 13:57, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> ok can you have a look at issue 1611 because now we can have an interface to define the color apparently. >> >> Stef >> >> On Oct 12, 2010, at 1:49 PM, Lukas Renggli wrote: >> >>> 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 >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch

Oct. 12, 2010

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

by Tobias Pape

Am 2010-10-12 um 13:48 schrieb Lukas Renggli: > I do. > > 2010/10/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> Stef Do y'all mean generally or for Pharo? So Long, -Tobias

Oct. 12, 2010

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

by Lukas Renggli

I integrated this during ESUG. Lukas On 12 October 2010 13:57, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > ok can you have a look at issue 1611 because now we can have an interface to define the color apparently. > > Stef > > On Oct 12, 2010, at 1:49 PM, Lukas Renggli wrote: > >> 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 >> >> _______________________________________________ >> 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 > -- Lukas Renggli www.lukas-renggli.ch

Oct. 12, 2010

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

by Igor Stasenko

On 12 October 2010 14:25, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > 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.. > well, its easier to add a default error handler in Object class, so any executor will have a default handler, and then some specific one may choose to override it, without putting a boilerplate of [ ] on: .. do: [] in every #finalize method. Besides, its natural , when you writing a code, you always expect that it will work w/o errors, and even if it fails, then in some concrete place, which means you usually not wrapping whole thing with exception handler. This leaves a chance to make another mistakes, like 'hey, despite i put error handler in my #finalize, something is still hangs finalization process'. > 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. > Yes this is the main intent. > 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 ;) ) > What i like in doing #finalize in forked process, that it doesn't matter where you screwed up: in finalization code or even in error handling code, you still don't have a chance to damage the system. And moreover, you can open debugger and debug it. Spice must flooow :) > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 12, 2010

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

by StÃ©phane Ducasse

ok can you have a look at issue 1611 because now we can have an interface to define the color apparently. Stef On Oct 12, 2010, at 1:49 PM, Lukas Renggli wrote: > 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 > > _______________________________________________ > 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

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

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

Re: [Pharo-project] Collaboractive book chapter 10

by Tudor Girba

To order the subpages, go to parent page, and then choose the Order command. For example, to order the chapters you should go to: http://book.pharo-project.org/book/ Doru On 12 Oct 2010, at 09:56, Mariano Martinez Peck wrote: > Yes, the order of the book is very very bad. The problem is that I have no idea how to sort it. > > > On Tue, Oct 12, 2010 at 9:06 AM, Norbert Hartl <norbert(a)hartl.name> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

Oct. 12, 2010

Re: [Pharo-project] Collaboractive book chapter 10

by Mariano Martinez Peck

Yes, the order of the book is very very bad. The problem is that I have no idea how to sort it. On Tue, Oct 12, 2010 at 9:06 AM, Norbert Hartl <norbert(a)hartl.name> 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 >

Oct. 12, 2010

[Pharo-project] Fwd: License question

by StÃ©phane Ducasse

> > 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

[Pharo-project] Fwd: License question

by StÃ©phane Ducasse

> > Yes. See this question in the GPL FAQ: > > "If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses?" > > Despite the phrasing of the question, it actually includes the relevant answer: > > ---- > However, when the interpreter is extended to provide âbindingsâ to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. > > Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together. > > If you choose to use GPL'd Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on. > ---- > > GSL is the "facilities" in this case. So the first paragraph means that the bindings themselves are under the GPL. > > So the bindings are a "GPL'd module" in the second/third paragraph, and the third paragraph means that any program using the GSL bindings is also under the GPL. > > Paolo

Oct. 12, 2010

[Pharo-project] Collaboractive book chapter 10

by Norbert Hartl

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

Oct. 12, 2010