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

[Pharo-project] [ANN] Opal Digest
by StÃ©phane Ducasse Oct. 12, 2010

Oct. 12, 2010

==================== Summary ==================== Name: OpalCompiler-Core-MarcusDenker.47 Author: MarcusDenker Time: 7 October 2010, 10:10:56 am UUID: eabd712c-a974-4416-9551-e210d85b6949 Ancestors: OpalCompiler-Core-JorgeRessia.46 -> Pass over ASTTranslator to make the effect (after) vs. value visiting more correct. More tests are green. -> Cleanups ==================== Summary ==================== Name: OpalCompiler-Tests-MarcusDenker.48 Author: MarcusDenker Time: 12 October 2010, 10:14 am UUID: 53fb460f-935c-4dd7-87df-92b9c77eb1f4 Ancestors: OpalCompiler-Tests-MarcusDenker.47 for now, remove OCCompilationEquivalencyTest ==================== Summary ==================== Name: OpalCompiler-Core-MarcusDenker.48 Author: MarcusDenker Time: 12 October 2010, 10:15:08 am UUID: f26101a1-d417-47c7-ab02-4974f0a15c93 Ancestors: OpalCompiler-Core-MarcusDenker.47 - some simplifications (eg remove compiledMethod...Using: methods from bc builder and iRBuilder) - cleanups - some fixes/hacks to make more tests green. ==================== Summary ==================== Name: OpalCompiler-Core-MarcusDenker.49 Author: MarcusDenker Time: 12 October 2010, 4:06:20 pm UUID: 21e13b3b-418a-404c-9405-9438b939a7a7 Ancestors: OpalCompiler-Core-MarcusDenker.48 - ASTTranslator: now #acceptBlockNode is responsible for pushing nil on empty bloks - ASTTranslator: simplify #acceptSequenceNode ==================== Summary ==================== Name: OpalCompiler-Tests-MarcusDenker.49 Author: MarcusDenker Time: 12 October 2010, 4:09:30 pm UUID: 9a662177-0e87-49fc-9cc3-475a6678f4f5 Ancestors: OpalCompiler-Tests-MarcusDenker.48 - started to merge OCSpecialVariableCases with OCOpalCompilerExamples - removed all #expectedTestfailures (e.g. FFI related tests are just skipped when FFI not installed) - add ASTTranslator test for exampleToDoInsideTemp and testExampleToDoInsideTempNotInlined - added testPushArray and testTodoValue (and example methods) - test initialize class side of BytecodeGenerator

1 0

[Pharo-project] FreeType and finalization
by Gary Chambers Oct. 12, 2010

Oct. 12, 2010

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

2 4

[Pharo-project] Learning by download all the mcz files from a repository
by HwaJong Oh Oct. 12, 2010

Oct. 12, 2010

I plan to study history of Metacello. For that I came up with an idea, what if i download all the mcz in the metacello repository on squeaksource. Then sort them by commit time stamp. installing very first version of Metacello to last version of Metacello-Help. Every moment of installation, see the difference by clicking "Changes" button of monticello browser. By doing it, i can grasp the idea, the indents of version and understand how the design has been changed and know the direction of change. What do you think of this idea? -HwaJong Oh- -- View this message in context: http://forum.world.st/Learning-by-download-all-the-mcz-files-from-a-reposit… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

4 7

[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

Oct. 12, 2010

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

1 0

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

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