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

[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

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

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

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

[Pharo-project] Issue 3090: Context not included in ImageSegment when saving morph to file
by Sheridan Mahoney Oct. 12, 2010

Oct. 12, 2010

3 2

[Pharo-project] Collaboractive book chapter 10
by Norbert Hartl Oct. 12, 2010

Oct. 12, 2010

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

3 2

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

Oct. 12, 2010

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

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

Oct. 12, 2010

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

1 0

[Pharo-project] Problem with inspector
by morod Oct. 12, 2010

Oct. 12, 2010

Hi i'm new to smalltalk and Pharo and my inspector show instead of Why? Thanks

3 10

Re: [Pharo-project] Xtreams port to Squeak - second wave
by mkobetic＠gmail.com Oct. 12, 2010

Oct. 12, 2010

Hi Nicolas, "Nicolas Cellier"<nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hi again, > I now have ported two more packages > - Xtreams-Transforms > - Xtreams-Substreams > and their tests This is great! I loaded your code into Pharo 1.1 and things seem to be working quite well. There was a complaint about missing SharedQueue2, I just created a dummy subclass of SharedQueue with that name and things seemed to load fine. XTRecyclingCenter seems to be subclass of XTWriteStream, it should be Object subclass, maybe a typo ? > I did not have any portability problem with those... > But that's because I did not handle the Character encoder/decoder. > Consequently, I have 8 tests failing (the Base64 related tests) I was thinking, we could implement just 'encoding: #ascii' quite easily, to make this reasonably usable at least for applications that are fine with that. We're actually contemplating about implementing our own encoders for Xtreams too. The VW ones are tied to the classic streams more than we like. You might have noticed some rather hairy parts in the encoding streams yourself, where we're trying to work around some of the issues it creates. The advantage of reusing the existing encoders was that there are quite a few of those available, so reimplementing all that would be a drag. But we can come up with a scheme where we can reimplement at least the common ones and in VW we can still preserve hooking into the old ones for the rest. I can give that a try on VW side in the meantime so you could get those for free. > Plus 4 other tests failing because of my poor implementation of > #after:do: (forking processes in a SUnit TestCase can't be that > obvious). I looked at this, and I think this is how #after:do: should look like: after: aDelay do: aBlock "Evaluate the argument block delayed after the specified duration." | watchdog | watchdog := [ aDelay wait. aBlock value. ] newProcess. watchdog priority: Processor userInterruptPriority. watchdog resume. This would assume that the 2 tests calling #timeout:server:client: would use a Delay instance instead of a Duration, which I'd be fine with. However making that change doesn't quite get the tests running. It's blowing up with a DNU on the 'output close' bit in #terminate:server:client: with output being nil, which I'm having trouble figuring out. I can't find who could possibly be nilling it out. I'm somewhat struggling finding my way around the Pharo tools. The test seems to otherwise pass but the DNUs from the background process isn't nice. Also when I just click on the test in the TestRunner, I actually get four DNUs, not just one as I would expect. So I'm kinda stuck, not sure how to move forward without help from someone who knows his way around Pharo. I also get odd failure from #testWriteCollectingMultipleBufferSize, which seems to run fine (against collection) when I run the equivalent in a workspace, but strangely fails when running via the #timeout:server:client: construct, i.e. when client and server run in separate processes. Hm, now that I think of it, they sure could fail if something preempts the client, server processes at the right moment. I'll have to rethink that again. > Now, the easy part of the port (copy/paste) is almost ended. > Once we manage a compatible way to handle pragmas, PEG Parser should > port quite easily too. I wouldn't worry about the Parser stuff at this point. > Then, the harder work begins: > - File/Socket/Pipe > - Pointers (in External Heap) I wouldn't worry, about the external heap stuff either. It's neat, but probably not something many people will miss. > - Character encoding/decoding I'll see if I can help with this from the VW side. > - Compression/Decompression Is Zlib linked into the VM in Squeak too ? The compression streams are written directly against the ZLib API, so there aren't any VW specific dependencies other than how those calls are made. Similarly the crypto streams go directly against the EVP API in LibCrypto in OpenSSL, so as long as we can abstract over how those are called, the stream implementation should work as is. > If you think you can help in any of these, please tell. If you could compile a list of changes that you'd like us to adopt on the VW side, I'd certainly look at that. I did read your posts but it's not entirely clear what you'd like to handle on Squeak side and what on VW side. A fileout would be best to avoid any confusion, but a description is fine too. I'm also unclear about the become: discussion. Don't write streams in Squeak become: the underlying collection when they grow it ? Cheers, Martin

4 8

Oct. 11, 2010

I would really like to have the same behavior than the squeak system ie having the source modification send to the list. I could not see how to set it up on squeaksource. May be this is not the same version running. Stef

6 6

Re: [Pharo-project] Exception handling and cull: [ Xtreams port to Squeak - second wave ]
by Nicolas Cellier Oct. 11, 2010

Oct. 11, 2010

2010/10/11 <mkobetic(a)gmail.com>: > "Sven Van Caekenberghe"<sven(a)beta9.be> wrote: >> I tried to follow your different releases in Pharo 1.1.1, right now I have 433 tests, 3 failures (#testReadWriteLargeAmount), 11 errors (#..base64 and #..multipleBufferSize). If will send you the report. >> >> I have been trying some of the examples from the doc pages (google code project), this simple one still fails: >> >> ((1 to: 10) reading collecting: [:x | x * x]) rest > > Ah, that's because of the use of #cull: like semantics with exception handlers in some places, mostly > > Â Â Â Â ... on: Incomplete do: #count. > > We can certainly replace all those with regular block style. > I see, #handleSignal: just calls valueWithPossibleArgument: instead of #cull... I don't well see the interest of adding arguments to #on:do: handler, since they would all be filled with nils... IMO, this is because we didn't have #cull: previously, so we used an existsing more powerfull version. To me, it should be self to just send #cull: Nicolas

2 1

[Pharo-project] [CfPart] BoF: Non-deterministic Programming for Manycore Systems at SPLASH'10
by Stefan Marr Oct. 11, 2010

Oct. 11, 2010

============================================================================ Call for Participation Non-deterministic Programming for Manycore Systems Birds of a Feather Tuesday, October 19, starting 5:30pm Reno/Tahoe, Nevada, 2010. Co-located with SPLASH 2010 http://soft.vub.ac.be/~smarr/bof_non-determenistic_programming.html ============================================================================ Non-deterministic Programming: A Solution for the Manycore Challenge? Informal Workshop on the Opportunities of Embracing Non-determinism in a Highly Parallel World Goal ---- This BoF is meant to bring together people who are interested in solving the challenges that the fine-grained parallelism of manycore and exascale systems present. Today, non-determinism is usually considered a problem researchers have to solve when they confronted with parallel programming. However, non-deterministic programming and its potential has been the subject of research for decades past. With the increasing and unavoidable degree of parallelism, it may be the time to discuss it from a new perspective. Thus, the main question of the workshop is, what if the downsides of non-determinism are outweighed by its benefits? We like to discuss the question of how a programming model for non-deterministic parallel programming could be designed. Thus, we want to think about what challenges need to be overcome and what research questions need to be formulated. Of interest are also which classic problems, for instance sorting, could be solved in a non-deterministic manner, and what kind of computational problems could benefit from speedups provided by additional parallelism even when trading off precision for speed. Attendance ---------- This Birds of a Feather is supposed to propose and discus new ideas, without any restriction of the creativity of its attendees. Every attendee is welcome to give a brief presentation, show a demo, or just engage into a discussion with the audience. Renaissance Project ------------------- This BoF will also be used as a venue to present the Renaissance Virtual Machine (RVM) of IBM Research[3]. On this occasion, the RVM will be opensourced and attendees will have the opportunity to get introduced to the technical details of it. The RVM is meant to provide a common foundation for research regarding non-deterministic parallel programming for manycore systems. It is a Squeak/Pharo compatible Smalltalk VM supporting a classic shared-memory programming model. Thus, the programmer has the illusion of a single object heap on which Smalltalk Processes can work in parallel. On top of the RVM, Ly was developed to embrace non-determinism and to harness emergence. The first results will be reported in an Onward! presentation on Thursday afternoon [1]: Harnessing Emergence for Manycore Programming: Early Experience Integrating Ensembles, Adverbs, and Object-based Inheritance by David Ungar, Sam S. Adams Confirmed Participants ---------------------- David Ungar, Doug Kimelman, IBM Research Brief introduction into the Renaissance project and demo of the current status of their Ly/Sly language and manycore virtual machine. Max OrHai, Andrew Black, Portland State University Giving an overview of an example application to test the Renaissance ensemble code as well as an outlook to a scalable non-deterministic parallel sorting algorithm. Theo D'Hondt, Vrije Universiteit Brussel Lessons from the past: Recapitulating the relations of non-deterministic programming, AI, and highly parallel systems like Connection Machine. Organizers ---------- Theo D'Hondt, Software Languages Lab, Vrije Universiteit Brussel Stefan Marr, Software Languages Lab, Vrije Universiteit Brussel [1] http://splashcon.org/program/onward-short-papers/154-onward-short-papers-b [2] http://splashcon.org/schedule/tuesday-oct-19-/235 [3] https://researcher.ibm.com/researcher/view_project.php?id=245 -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

1 0

[Pharo-project] Xtreams hook to the holly Squeak TextEncoder
by Nicolas Cellier Oct. 11, 2010

Oct. 11, 2010

So, I updated Xtreams-Transforms to fit Cincom public store version 52. Then I added Xtreams-SqueakTextConverter to provide a DialectConverter. I didn't name it Xtreams-SqueakEncoder because I'd like to let room for cleaner classes. I didn't make any effort to support backup/restore State My version can now execute: (((ByteArray new writing encoding: 'utf8') nextPutAll: 'Ã Ã©'; conclusion) reading encoding: 'utf8') rest Cheers Nicolas

1 0

Re: [Pharo-project] Xtreams port to Squeak - second wave
by mkobetic＠gmail.com Oct. 11, 2010

Oct. 11, 2010

"Sven Van Caekenberghe"<sven(a)beta9.be> wrote: > I tried to follow your different releases in Pharo 1.1.1, right now I have 433 tests, 3 failures (#testReadWriteLargeAmount), 11 errors (#..base64 and #..multipleBufferSize). If will send you the report. > > I have been trying some of the examples from the doc pages (google code project), this simple one still fails: > > ((1 to: 10) reading collecting: [:x | x * x]) rest Ah, that's because of the use of #cull: like semantics with exception handlers in some places, mostly ... on: Incomplete do: #count. We can certainly replace all those with regular block style. > The readline example is using the non-existing #slicer: method, this simpler version seems to work: > > |text| > text := 'line1\line2\line3\line4' withCRs reading. > text := text ender: [ :char | char = Character cr ]. > text collect: [ :line | line rest ]. > > That is a documentation bug though. Hm, odd, this is fixed in the package comments, but looks like I failed to regenerate the project pages properly. I'll review the comments again and update the site. Thanks!

3 2

[Pharo-project] Xtreams was Re: Unit Tests on Pharo 1.1.1
by Sven Van Caekenberghe Oct. 11, 2010

Oct. 11, 2010

Nicolas, On 11 Oct 2010, at 22:35, Nicolas Cellier wrote: > Yes, that was expected. > > With latest versions, the Base64 encoding/decoding now pass. > Beware, I moved everything to http://www.squeaksource.com/Xtreams.html > > Cheers > > Nicolas > > 2010/10/11 Sven Van Caekenberghe <sven(a)beta9.be>: >> Nicolas, >> >> Here is the unit test report I promised: OK, thanks, I moved to the new SS project. I commited some changes: replacing on: XTIncomplete do: #count with on: XTIncomplete do: [:exception | exception count] as suggested by Martin Kobetic Now, this works: ((1 to: 10) reading collecting: [:x | x * x]) rest and I think more tests succeed, but I am not sure since I forgot how many failed before. Sven

1 0