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

[Pharo-project] Autotest / TDD + screencast

by laurent laffont

Hi, Here's a first usable version of Autotest (automatic test runner, inspired by Ruby's ZentTest autotest). The goal is to have instant feedback on the code you The screencast to see it in action: http://lolgzs.free.fr/pharo/autotest_1.mpeg To load it: Gofer new squeaksource: 'Autotest'; package: 'Autotest'; load Comments are welcome as I have to rewrite it better :) Repository is read / write for those who wants to contribute. Cheers, Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/

June 4, 2010

Re: [Pharo-project] Something I don't see in ImageSegment

by Mariano Martinez Peck

2010/6/4 Eliot Miranda <eliot.miranda(a)gmail.com> > > > 2010/6/4 Mariano Martinez Peck <marianopeck(a)gmail.com> > > >> >> 2010/6/3 Eliot Miranda <eliot.miranda(a)gmail.com> >> >> Hi Mariano, Hi All, >>> >>> response below. But does anyone have any tests for the image segment >>> primitives? I'm refactoring them and would like some tests. >>> >> >> Hi Eliot. First, congratulations!! I though several times to refactor >> the primitives what I was not brave enough. I was not confidence of myself >> hahaha >> >> Originally, ImageSegment didn't have a single test. Only some class side >> examples that in Pharo at least were not even working. Adrian Lienhard wrote >> the first 2 or 3 tests for them. Then I needed to understand ImageSegment >> for my PhD, and the best way to understand them were writing unit tests ;) >> >> So, now if you take a Pharo 1.1 image you will see there are 26 tests. The >> classes are ImageSegmentTest, ImageSegmentTestExport and >> ImageSegmentTestSwap. The tests are quite simple and cover not too much. >> They can be improved and there are more to write. They may be even not >> completly correct as I wrote them to understand ImageSegment, not because I >> already understood them ;) >> >> In addition, there is one failing that I yet don't understand why: >> #testOutPointers3 >> I asked in mailing list but not really an answer in my opinion: >> >> http://forum.world.st/Something-I-don-t-understand-with-ImageSegments-tp129… >> If you know why it is failing, tell me :) >> >> > I wrote a test yesterday anyway. Perhaps we can combine at some stage. I > can certainly use the tests you've written though. Thanks! > > Great. If you want feel free to attach your test and I commit it. Or you create an issue and you do it by yourself. > > >> >>> >> >> Ok...but where is the roots of the system? it is the instVar rootTable of >> ObjectMemory? so all the root table is also marked? >> > > The roots of the system are > - the specialObjectsArray > - the current context > - the extraRoots table (addGCRoot/removeGCRoot's underlying table) > - suspended callbacks (processes using the FFI's callback facility) > > While the specialObjectsArray contains references to known classes (which > indirectly refer to Smalltalk and the entire class hierarchy) and to the > process scheduler (Smalltalk associationAt: #Processor) it also contains the > external semaphore table, the Character table (byte character instances) and > the specialSelectors table (for special selector sends). > > OK, I didn't know all this :) > >> At the beginning I though it was this that you are saying. But then I >> check in the senders of markAndTraceInterpreterOops and you can see in >> ObjectMemory >> markPhase that it does: >> >> "trace the interpreter's objects, including the active stack >> and special objects array" >> self markAndTraceInterpreterOops. >> statSpecialMarkCount := statMarkCount. >> "trace the roots" >> 1 to: rootTableCount do: [:i | >> oop := rootTable at: i. >> self markAndTrace: oop]. >> 1 to: extraRootCount do:[:i| >> oop := (extraRoots at: i) at: 0. >> (self isIntegerObject: oop) ifFalse:[self markAndTrace: oop]]. >> >> So...it is manually iterating the table. Why? shouldn't be done as you >> told me? >> > > The rootTable (better known as a remembered set) is part of the garbage > collector and contains any and all old objects that may reference a young > object. These objects are roots for an incremental GC, and they get voided > at the start of a full GC and after an incrementalGC. See clearRootsTable. > > > In summary, my question is: is these code doing this (iterating the table) >> even if it is not necessary or ImageSegment should also do it? >> > > It's an essential part of the generational GC implementation. It is > nothing to do with tracing for image segments. > > > Ok...so, my problem was I though that rootTable were indeed the roots of the system, not a particular GC table. Then, I confused because as in GC it needed to iterate it, I though I had to do that also in ImageSegment. > This would mark all objects in the system were it not for the fact that the >>> primitive marks the rootArray and so markInterpreterOops does not marl >>> objects /only/ reachable from the rootArray. So once the rootArray objects >>> have been unmarked, only those objects that should go in the image segment >>> are unmarked. >>> >>> So the primitive works by >>> - marking the objects in rootArray, preventing marking of objects >>> reachable from them in the next step >>> - recursively marking all objects reachable from the roots (except those >>> already marked) >>> - unmarking root objects, leaving the transitive closure of objects >>> accessible from the roots and no where else unmarked >>> - writing the unmarked objects to an image segment >>> >>> >> yes, this is clear :) >> >> Thanks for the help. >> >> Mariano >> > > cheers > Eliot > > >> >> >>> >>> HTH >>> Eliot >>> >>> >>>> You can see the comment: "Then do a mark pass over all objects" and even >>>> without the comment it makes sense to mark all objects in order to detect >>>> outPointers. >>>> >>>> Does anyone has a hint? >>>> >>>> Thanks >>>> >>>> Mariano >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> _______________________________________________ >> 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 >

June 4, 2010

Re: [Pharo-project] SUnit Time out

by Nicolas Cellier

2010/6/4 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: > I dont think it is a necessary... I mean, if you are doing TDD, you write > the test and you run it inmediatly, if it takes too much time to run (that > is, more than 2 seconds :-)) then you press ctrl+ . and problem solved... Pretend you are Stephane or Andreas and trying to integrate a bunch of tests that you did not write. How do you know whether the test programmer cared about shortness ? How do you know whether the test is expected to be long or there is a regression somewhere causing an infinite loop ? >From integrator point of view, best strategy is to reject any long test. If you are a producer and want to produce a long test, then you MUST declare it as such. Of course, that breaks a few legacy tests... > I'm saying this because the should:notTakeMoreThan: has some interesting > implementation details, like running the test in another process and > synchronizing them, etc... so running all the test would create a process > for each test, etc. tacking more timeÂ unnecessarilyÂ in most of the cases... > unless the implementation takes care of only doing this special "feature" > when needed (for example, when you have that pragma) but the, if you have to > write the pragma why not just send the message #should:notTakeMoreThan: and > problem solved? > Your problem, probably, Andreas and Steph problem, I don't think so. Implementation details should be discussed. also the threshold is arbitrary and hardware dependent. Maybe we could use the Dorado as unit of time ;) but IMO, this feature is worth. Nicolas > On Sat, May 29, 2010 at 3:42 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> For me the point is that I have the impression that this is an interesting >> feature to have >> when we have a test server. Like that you make sure that you do not have >> tests with infinite recursion >> now this is also true that on a test server you do not really care if your >> tests take 30s or 2 min. >> >> Stef >> >> > We already have #should:notTakeMoreThan: and friends in TestCase. The >> > complete TestCase can be protected by overriding #runCase, the >> > individual test by wrapping the code of the test method. >> > >> > Lukas >> > >> > On 29 May 2010 16:43, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >> >> Stef, >> >> >> >> Time to expose some of my ignorance (don't worry, I have plenty more >> >> waiting where I found this): what is the tag concept? Â That sounds very >> >> Tweak-ish, and I am a real believer in doing things "with the language, not >> >> TO the language" whenever possible. Â That is not to say that frameworks are >> >> bad; in fact, it means that frameworks are good, language extensions are >> >> anywhere from suspect to evil. >> >> >> >> I have some code that I am still porting, but the basic idea is to be >> >> able to write >> >> >> >> [ >> >> Â "code that might not complete" >> >> >> >> ] tryForSeconds:10 onTimeOut:[ >> >> >> >> ]. >> >> >> >> With a robust capability to do such things, it is probably not >> >> necessary (or even appropriate) for TestCase to enforce timeouts. Â The >> >> timeout block can simply raise an exception or assert false, and there is no >> >> need to disable timeouts where they do not belong. >> >> >> >> Bill >> >> >> >> ________________________________________ >> >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> >> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Michael Roberts >> >> [mike(a)mjr104.co.uk] >> >> Sent: Saturday, May 29, 2010 6:17 AM >> >> To: Pharo-project(a)lists.gforge.inria.fr >> >> Subject: Re: [Pharo-project] SUnit Time out >> >> >> >> yes think it's a good idea. I'm not sure the granularity that's >> >> required though. >> >> >> >> mike >> >> >> >> On Saturday, May 29, 2010, stephane ducasse <stephane.ducasse(a)free.fr> >> >> wrote: >> >>> Hi guys >> >>> >> >>> in Squeak andreas introduced the idea of test time out >> >>> Do you think that this is interesting? >> >>> >> >>> Stef >> >>> >> >>> SUnit >> >>> ----- >> >>> All test cases now have an associated timeout after which the test is >> >>> considered failed. The purpose of the timeout is to catch issues like >> >>> infinite loops, unexpected user input etc. in automated test environments. >> >>> Timeouts can be set on an individual test basis using the <timeout: seconds> >> >>> tag or for an entire test case by implementing the #defaultTimeout method. >> >>> _______________________________________________ >> >>> 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 >> >> >> >> _______________________________________________ >> >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 4, 2010

Re: [Pharo-project] Something I don't see in ImageSegment

by Eliot Miranda

2010/6/4 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > 2010/6/3 Eliot Miranda <eliot.miranda(a)gmail.com> > > Hi Mariano, Hi All, >> >> response below. But does anyone have any tests for the image segment >> primitives? I'm refactoring them and would like some tests. >> > > Hi Eliot. First, congratulations!! I though several times to refactor the > primitives what I was not brave enough. I was not confidence of myself > hahaha > > Originally, ImageSegment didn't have a single test. Only some class side > examples that in Pharo at least were not even working. Adrian Lienhard wrote > the first 2 or 3 tests for them. Then I needed to understand ImageSegment > for my PhD, and the best way to understand them were writing unit tests ;) > > So, now if you take a Pharo 1.1 image you will see there are 26 tests. The > classes are ImageSegmentTest, ImageSegmentTestExport and > ImageSegmentTestSwap. The tests are quite simple and cover not too much. > They can be improved and there are more to write. They may be even not > completly correct as I wrote them to understand ImageSegment, not because I > already understood them ;) > > In addition, there is one failing that I yet don't understand why: > #testOutPointers3 > I asked in mailing list but not really an answer in my opinion: > > http://forum.world.st/Something-I-don-t-understand-with-ImageSegments-tp129… > If you know why it is failing, tell me :) > Its to do with compact classes. 'mariano' class indexIfCompact 11 Object new indexIfCompact 0 The store segment primitive does not consider class references from objects with compact class as external pointers. Arguably this is a bug because it means an image segment is only safely loadable into an image with the same compact classes, but that's a restriction we're willing to live with. HTH Eliot > continue answering above... > > >> >> 2010/6/3 Mariano Martinez Peck <marianopeck(a)gmail.com> >> >> .... >>> >>> But here I see it is only marking Interpreter oops, not all objects. And >>> I don't see where all objects are marked even in the code that follows this >>> little piece. >>> >> >> markInterpreterOops marks all objects accessible from the interpreter >> oops, including the specialObjectsArray, recursively marking any unmarked >> objects and their referents. i.e. it marks all objects reachable from the >> roots of the system. >> > > Ok...but where is the roots of the system? it is the instVar rootTable of > ObjectMemory? so all the root table is also marked? > > At the beginning I though it was this that you are saying. But then I check > in the senders of markAndTraceInterpreterOops and you can see in > ObjectMemory >> markPhase that it does: > > "trace the interpreter's objects, including the active stack > and special objects array" > self markAndTraceInterpreterOops. > statSpecialMarkCount := statMarkCount. > "trace the roots" > 1 to: rootTableCount do: [:i | > oop := rootTable at: i. > self markAndTrace: oop]. > 1 to: extraRootCount do:[:i| > oop := (extraRoots at: i) at: 0. > (self isIntegerObject: oop) ifFalse:[self markAndTrace: oop]]. > > So...it is manually iterating the table. Why? shouldn't be done as you told > me? > > In summary, my question is: is these code doing this (iterating the table) > even if it is not necessary or ImageSegment should also do it? > > > >> This would mark all objects in the system were it not for the fact that >> the primitive marks the rootArray and so markInterpreterOops does not marl >> objects /only/ reachable from the rootArray. So once the rootArray objects >> have been unmarked, only those objects that should go in the image segment >> are unmarked. >> >> So the primitive works by >> - marking the objects in rootArray, preventing marking of objects >> reachable from them in the next step >> - recursively marking all objects reachable from the roots (except those >> already marked) >> - unmarking root objects, leaving the transitive closure of objects >> accessible from the roots and no where else unmarked >> - writing the unmarked objects to an image segment >> >> > yes, this is clear :) > > Thanks for the help. > > Mariano > > >> >> HTH >> Eliot >> >> >>> You can see the comment: "Then do a mark pass over all objects" and even >>> without the comment it makes sense to mark all objects in order to detect >>> outPointers. >>> >>> Does anyone has a hint? >>> >>> Thanks >>> >>> Mariano >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 4, 2010

Re: [Pharo-project] Something I don't see in ImageSegment

by Eliot Miranda

2010/6/4 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > 2010/6/3 Eliot Miranda <eliot.miranda(a)gmail.com> > > Hi Mariano, Hi All, >> >> response below. But does anyone have any tests for the image segment >> primitives? I'm refactoring them and would like some tests. >> > > Hi Eliot. First, congratulations!! I though several times to refactor the > primitives what I was not brave enough. I was not confidence of myself > hahaha > > Originally, ImageSegment didn't have a single test. Only some class side > examples that in Pharo at least were not even working. Adrian Lienhard wrote > the first 2 or 3 tests for them. Then I needed to understand ImageSegment > for my PhD, and the best way to understand them were writing unit tests ;) > > So, now if you take a Pharo 1.1 image you will see there are 26 tests. The > classes are ImageSegmentTest, ImageSegmentTestExport and > ImageSegmentTestSwap. The tests are quite simple and cover not too much. > They can be improved and there are more to write. They may be even not > completly correct as I wrote them to understand ImageSegment, not because I > already understood them ;) > > In addition, there is one failing that I yet don't understand why: > #testOutPointers3 > I asked in mailing list but not really an answer in my opinion: > > http://forum.world.st/Something-I-don-t-understand-with-ImageSegments-tp129… > If you know why it is failing, tell me :) > > I wrote a test yesterday anyway. Perhaps we can combine at some stage. I can certainly use the tests you've written though. Thanks! > continue answering above... > > >> >> 2010/6/3 Mariano Martinez Peck <marianopeck(a)gmail.com> >> >> .... >>> >>> But here I see it is only marking Interpreter oops, not all objects. And >>> I don't see where all objects are marked even in the code that follows this >>> little piece. >>> >> >> markInterpreterOops marks all objects accessible from the interpreter >> oops, including the specialObjectsArray, recursively marking any unmarked >> objects and their referents. i.e. it marks all objects reachable from the >> roots of the system. >> > > Ok...but where is the roots of the system? it is the instVar rootTable of > ObjectMemory? so all the root table is also marked? > The roots of the system are - the specialObjectsArray - the current context - the extraRoots table (addGCRoot/removeGCRoot's underlying table) - suspended callbacks (processes using the FFI's callback facility) While the specialObjectsArray contains references to known classes (which indirectly refer to Smalltalk and the entire class hierarchy) and to the process scheduler (Smalltalk associationAt: #Processor) it also contains the external semaphore table, the Character table (byte character instances) and the specialSelectors table (for special selector sends). > At the beginning I though it was this that you are saying. But then I check > in the senders of markAndTraceInterpreterOops and you can see in > ObjectMemory >> markPhase that it does: > > "trace the interpreter's objects, including the active stack > and special objects array" > self markAndTraceInterpreterOops. > statSpecialMarkCount := statMarkCount. > "trace the roots" > 1 to: rootTableCount do: [:i | > oop := rootTable at: i. > self markAndTrace: oop]. > 1 to: extraRootCount do:[:i| > oop := (extraRoots at: i) at: 0. > (self isIntegerObject: oop) ifFalse:[self markAndTrace: oop]]. > > So...it is manually iterating the table. Why? shouldn't be done as you told > me? > The rootTable (better known as a remembered set) is part of the garbage collector and contains any and all old objects that may reference a young object. These objects are roots for an incremental GC, and they get voided at the start of a full GC and after an incrementalGC. See clearRootsTable. In summary, my question is: is these code doing this (iterating the table) > even if it is not necessary or ImageSegment should also do it? > It's an essential part of the generational GC implementation. It is nothing to do with tracing for image segments. This would mark all objects in the system were it not for the fact that the >> primitive marks the rootArray and so markInterpreterOops does not marl >> objects /only/ reachable from the rootArray. So once the rootArray objects >> have been unmarked, only those objects that should go in the image segment >> are unmarked. >> >> So the primitive works by >> - marking the objects in rootArray, preventing marking of objects >> reachable from them in the next step >> - recursively marking all objects reachable from the roots (except those >> already marked) >> - unmarking root objects, leaving the transitive closure of objects >> accessible from the roots and no where else unmarked >> - writing the unmarked objects to an image segment >> >> > yes, this is clear :) > > Thanks for the help. > > Mariano > cheers Eliot > > >> >> HTH >> Eliot >> >> >>> You can see the comment: "Then do a mark pass over all objects" and even >>> without the comment it makes sense to mark all objects in order to detect >>> outPointers. >>> >>> Does anyone has a hint? >>> >>> Thanks >>> >>> Mariano >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 4, 2010

Re: [Pharo-project] Multiple Worlds (was Re: Can I use Projects in Pharo?)

by Jochen Riekhof

> I tried in 1.1 and I got a beWorldForProject: is not understood. Hmm, I thought so, as you promised, all the old support for Squeak Projects goes away :-). > > But continue this sounds interesting. > and may be this is what people needs. Yep, I will. Ciao ...Jochen Am 04.06.2010 um 13:53 schrieb StÃ©phane Ducasse: > I really like the idea that your tried. > > I tried in 1.1 and I got a beWorldForProject: is not understood. > > But continue this sounds interesting. > and may be this is what people needs. > > > On Jun 3, 2010, at 9:11 PM, Jochen Riekhof wrote: > >> JRWorldManager instance createOrSwitchToWorldNamed: 'JustAnotherWorld'. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 4, 2010

Re: [Pharo-project] Changes aren't saved in the default (unnamed) changeset on a new image

by Guillermo Polito

They are not saved :D, that's what motivated me to send this email :P. I'll open one :) On Fri, Jun 4, 2010 at 1:18 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > where is it saved? > it may be a bug > create a bug entry with a nice description :) > > Stef > On Jun 4, 2010, at 5:23 PM, Guillermo Polito wrote: > > > Hi! > > > > I'm using the develop Pharo-1.1-11367-Beta on windows. > > > > When I make a change with a fresh image, that change isn't saved in the > default changeset :(. In the Core image it's just ok. > > > > Is it a bug or a 'feature'? > > > > Cheers, > > Guille > > _______________________________________________ > > 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 >

June 4, 2010

Re: [Pharo-project] Little "bug" when browsing classes from TestRunner

by StÃ©phane Ducasse

open a ticket :) On Jun 4, 2010, at 3:14 PM, Mariano Martinez Peck wrote: > Hi folks. If this is a bug, is very very little, but just in case. > When you open a TestRunner, you can select a particular class -> right button -> browse and it opens a browser with it. > > However, it does not happen the same if you do the following: > > - You open a Test Runner > - Select a particular package, for example, Gofer-Tests which has 4 classes. > - Press left click and holding it select the four tests. > - Now, press left click again and holding it, deselect all test but the first one. > - Now, only the first test should be gray. But if you do right button -> browse, nothing happens. > > It seems the test is not like selected, although it is gray. In addition, if you click again to that class, it will be unselected. Click again, it will be selected. There, you can browse it. > > Tested in PharoDev and Core. > > Cheers > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 4, 2010

Re: [Pharo-project] Changes aren't saved in the default (unnamed) changeset on a new image

by StÃ©phane Ducasse

where is it saved? it may be a bug create a bug entry with a nice description :) Stef On Jun 4, 2010, at 5:23 PM, Guillermo Polito wrote: > Hi! > > I'm using the develop Pharo-1.1-11367-Beta on windows. > > When I make a change with a fresh image, that change isn't saved in the default changeset :(. In the Core image it's just ok. > > Is it a bug or a 'feature'? > > Cheers, > Guille > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 4, 2010

Re: [Pharo-project] The Morphic 3 project

by Igor Stasenko

On 4 June 2010 16:26, Juan Vuletich <juan(a)jvuletich.org> wrote: > Igor Stasenko wrote: >> >> On 2 June 2010 15:16, Juan Vuletich <juan(a)jvuletich.org> wrote: >> >>> >>> Lukas Renggli wrote: >>> >>>> >>>> Hi Juan, >>>> >>>> This looks really exiting! >>>> >>>> How do you get the actual pixels drawn? Is this implemented in >>>> Smalltalk? Did you write primitives to do that? Are you using external >>>> libraries? How does it compare performance wise with the current >>>> rendering? >>>> >>>> Lukas >>>> >>>> >>>> >>> >>> Hi Lukas, >>> >>> I'm glad you like it. It is all done in Smalltalk. There are no external >>> libraries. In fact, I developed new drawing algorithms that are better >>> than >>> those in Cairo, AGG, etc. So there are no libraries in existence I could >>> call! >>> >>> The sampling theorem is about 80 years old. It is the base (together with >>> Fourier analysis) of most of the DSP (Digital Signal Processing) field. >>> It >>> is therefore the basis of digital audio and photography. But it seems I >>> am >>> the first one to apply it to 2d rendering! I have been working on this >>> for >>> the last 3 years, after finishing my Ms.Sc. in CS on Image and Signal >>> Processing. I had to establish the theoretical foundations, and come up >>> with >>> new algorithms to draw basic elements using this theory. What you see are >>> the first practical result of all this work. >>> >>> It is still pure Smalltalk, and therefore, a bit slow. The lion takes 1.8 >>> secs to draw on my 1.6GHz Mac mini. I am still changing the code a lot, >>> but >>> when it stabilizes I'll do a VM plugin. I guess it would be about 100 >>> times >>> faster. The other option is to use Igor's NativeBoost. That could perhaps >>> be >>> 10 times faster than the plugin, at the cost of portability and hand >>> written >>> asm (I'd done lots of asm in a previous life). >>> >>> >> >> Last year i built an SVG API bindings. And i were able to render the Tiger >> at screen refresh rate (65Hz). The rendering throughput is even higher >> than that, >> but it looks like SVG implementation limits the frame rate to screen >> refresh rate as maximum :) >> >> Sure thing, the quality is not that high as yours, >> but still, it shows how much speed-up we could achieve, if we put all >> processing on >> GPU side. >> >> It would be cool if we could cooperate and implement this stuff using >> OpenGL as backend > > Indeed. Although I wonder if OpenGL is general enough to implement it... I > mean, the only standard operation I do is to blend pixels... Everything else > is done with new algorithms. Without being an OpenGL expert, I believe that > CUDA / OpenCL would be better suited. > I don't know. But i don't think it is too different from many other techniques, which implemented using shaders. The rendering algorithms is highly parallelisable, that's why GPU is best place where they should run. And i guess, your algorithms is not an exception. I see there are two separate stages for rendering: 1. rasterize the path to mask (including pixel coverage) 2. fill the mask with paint Both can be implemented quite efficiently on GPU. > Cheers, > Juan Vuletich > > _______________________________________________ > 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.

June 4, 2010