- Pharo-dev - lists.pharo.org

[Pharo-project] Adding a new font in System like DejaVu fonts
by nullPointer Oct. 12, 2010

Oct. 12, 2010

Now I know is possible add a new font, for use cross platform like DejaVu. I know Juan Vuletich did that but I donÂ´t know found the place of that is explained. Is heard do that? takes very space of image when the font is added? Many thanks for answers. -- View this message in context: http://forum.world.st/Adding-a-new-font-in-System-like-DejaVu-fonts-tp29701… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

3 2

Re: [Pharo-project] Collaboractive book chapter 10
by Simon Denier Oct. 12, 2010

Oct. 12, 2010

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

2 1

[Pharo-project] Another finalization concern: error handling
by Igor Stasenko Oct. 12, 2010

Oct. 12, 2010

Hello, here a situation, with which we can deal in more safer manner: Suppose you have a weak registry, populated by different objects and their executors. Now, when some of them died, a weak registry performs finalization. The potential danger is , that if there's an error triggered by some executor(s), then rest of executors will have no chance to run and will be forgotten, causing memory leakage. What you think, should we handle this more graciously? (Consider a following meta-code) WeakRegistry>>finalizeValues | executors | executors := self gatherExecutorsToRun. executors do: [:ex | [ ex finalize ] fork. ]. in this way, if any executor's #finalize causing error, it won't interfere with other executors, and they will accomplish their task normally. Of course, i'm not saying that we should use #fork for this, because it is costly. Similar could be done w/o forking. I just wanted to show a simplest code with which we could achieve a more gracious error handling. P.S. of course, in a first place it would be good to make sure that we writing executors, which can't cause an error during finalization. But bad things happen, and we should make sure that rest of system won't be put on its knees because of some stupid bug in a single #finalize. -- Best regards, Igor Stasenko AKA sig.

4 37

Re: [Pharo-project] who is maintaining shout?
by StÃ©phane Ducasse Oct. 12, 2010

Oct. 12, 2010

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

2 2

[Pharo-project] [update 1.2] #12192
by StÃ©phane Ducasse Oct. 12, 2010

Oct. 12, 2010

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

1 0

Re: [Pharo-project] Collaboractive book chapter 10
by StÃ©phane Ducasse Oct. 12, 2010

Oct. 12, 2010

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

1 0

[Pharo-project] Fwd: License question
by StÃ©phane Ducasse Oct. 12, 2010

Oct. 12, 2010

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

1 0

Oct. 12, 2010

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

1 0

Oct. 12, 2010

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 >

1 0

Re: [Pharo-project] Collaboractive book chapter 10
by Simon Denier Oct. 12, 2010

Oct. 12, 2010

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

1 0