Maybe cc'ing VM mailing list can help.
On Fri, Jul 1, 2011 at 9:32 AM, Lukas Renggli renggli@gmail.com wrote:
Hi Eliot,
I am using one of the latest VMs from your site (VM.r2434) and I continue to have subtle problems with objects as methods (#flushCache, #run:with:in:).
The issue is that the test coverage in Pharo is kind of broken on Cog for a long time already. It reports methods as not covered that are clearly covered, and tests seem to randomly fail.
I suspected that there is something wrong with the coverage code itself. So I started to experiment with TestCoverage>>flushCache and noticed that the current implementation
TestCoverage>>flushCache self reference methodSymbol flushCache
performs not that well: The set of not covered methods is wrong and many tests suddenly fail. If I replace it with
TestCoverage>>flushCache self reference actualClass flushCache
I actually get accurate coverage information, but there are still a few tests constantly failing. I tried to use all possible combinations of #flushCache (also calling it on the compiled method), but only flushing the cache on the class seems to work properly. So far so good, but I really wonder what the correct way is to flush the cache? :-)
For my experiments I was using the package 'AST-Tests-Semantics'. This is a small package with lots of test methods that cover each method but one (RBSemanticAnnotationMisssing>>#isResumable). Now the "real" problem is that when running these tests in coverage mode, the same 4 tests always fail:
RBSemanticTest>>testBlockScope RBSemanticTest>>testCascadeReceiver RBSemanticTest>>testClassVariableBinding RBSemanticTest>>testGlobalVariableBinding
Not sure of how to debug that? Do you have an idea why these otherwise passing tests suddenly fail? If you want to try to reproduce you can use any Pharo image with the tests loaded, or use those that I used:
http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifact...
http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifact...
Open the Test Runner, select 'AST-Tests-Semantics' and 'Run Coverage'.
Any help or clarification would be appreciated :-)
Lukas
-- Lukas Renggli www.lukas-renggli.ch
Hi All,
I'm in touch with Lukas on this but have no time to address it right now. worry not :)
On Mon, Jul 11, 2011 at 3:05 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Maybe cc'ing VM mailing list can help.
On Fri, Jul 1, 2011 at 9:32 AM, Lukas Renggli renggli@gmail.com wrote:
Hi Eliot,
I am using one of the latest VMs from your site (VM.r2434) and I continue to have subtle problems with objects as methods (#flushCache, #run:with:in:).
The issue is that the test coverage in Pharo is kind of broken on Cog for a long time already. It reports methods as not covered that are clearly covered, and tests seem to randomly fail.
I suspected that there is something wrong with the coverage code itself. So I started to experiment with TestCoverage>>flushCache and noticed that the current implementation
TestCoverage>>flushCache self reference methodSymbol flushCache
performs not that well: The set of not covered methods is wrong and many tests suddenly fail. If I replace it with
TestCoverage>>flushCache self reference actualClass flushCache
I actually get accurate coverage information, but there are still a few tests constantly failing. I tried to use all possible combinations of #flushCache (also calling it on the compiled method), but only flushing the cache on the class seems to work properly. So far so good, but I really wonder what the correct way is to flush the cache? :-)
For my experiments I was using the package 'AST-Tests-Semantics'. This is a small package with lots of test methods that cover each method but one (RBSemanticAnnotationMisssing>>#isResumable). Now the "real" problem is that when running these tests in coverage mode, the same 4 tests always fail:
RBSemanticTest>>testBlockScope RBSemanticTest>>testCascadeReceiver RBSemanticTest>>testClassVariableBinding RBSemanticTest>>testGlobalVariableBinding
Not sure of how to debug that? Do you have an idea why these otherwise passing tests suddenly fail? If you want to try to reproduce you can use any Pharo image with the tests loaded, or use those that I used:
http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifact...
http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifact...
Open the Test Runner, select 'AST-Tests-Semantics' and 'Run Coverage'.
Any help or clarification would be appreciated :-)
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Mariano http://marianopeck.wordpress.com
Hi Eliot,
I am experiencing the same problem as Lukas. I was having random DNU on replaced methods. I fixed the problem by flushing the cache on the compiled methods only, before I was flushing on the selector and on the class. It is not yet clear to me what is the right way of flushing the cache. Any explanation on that?
I think that this goes along with http://code.google.com/p/pharo/issues/detail?id=2255 http://forum.world.st/flushCache-with-MethoWrappers-in-CogVM-td3381310.html
Eliot, if you need help debugging or testing a potential solution let me know, I have a bunch of test working on top of this.
Cheers,
On Mon, Jul 11, 2011 at 6:31 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All, I'm in touch with Lukas on this but have no time to address it right now. worry not :)
On Mon, Jul 11, 2011 at 3:05 AM, Mariano Martinez Peck marianopeck@gmail.com wrote:
Maybe cc'ing VM mailing list can help.
On Fri, Jul 1, 2011 at 9:32 AM, Lukas Renggli renggli@gmail.com wrote:
Hi Eliot,
I am using one of the latest VMs from your site (VM.r2434) and I continue to have subtle problems with objects as methods (#flushCache, #run:with:in:).
The issue is that the test coverage in Pharo is kind of broken on Cog for a long time already. It reports methods as not covered that are clearly covered, and tests seem to randomly fail.
I suspected that there is something wrong with the coverage code itself. So I started to experiment with TestCoverage>>flushCache and noticed that the current implementation
TestCoverage>>flushCache self reference methodSymbol flushCache
performs not that well: The set of not covered methods is wrong and many tests suddenly fail. If I replace it with
TestCoverage>>flushCache self reference actualClass flushCache
I actually get accurate coverage information, but there are still a few tests constantly failing. I tried to use all possible combinations of #flushCache (also calling it on the compiled method), but only flushing the cache on the class seems to work properly. So far so good, but I really wonder what the correct way is to flush the cache? :-)
For my experiments I was using the package 'AST-Tests-Semantics'. This is a small package with lots of test methods that cover each method but one (RBSemanticAnnotationMisssing>>#isResumable). Now the "real" problem is that when running these tests in coverage mode, the same 4 tests always fail:
RBSemanticTest>>testBlockScope RBSemanticTest>>testCascadeReceiver RBSemanticTest>>testClassVariableBinding RBSemanticTest>>testGlobalVariableBinding
Not sure of how to debug that? Do you have an idea why these otherwise passing tests suddenly fail? If you want to try to reproduce you can use any Pharo image with the tests loaded, or use those that I used:
http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifact... http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifact...
Open the Test Runner, select 'AST-Tests-Semantics' and 'Run Coverage'.
Any help or clarification would be appreciated :-)
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Mariano http://marianopeck.wordpress.com
-- best, Eliot
Hi Jorge,
On Mon, Aug 8, 2011 at 12:20 PM, Jorge Ressia jorge.ressia@gmail.comwrote:
Hi Eliot,
I am experiencing the same problem as Lukas. I was having random DNU on replaced methods. I fixed the problem by flushing the cache on the compiled methods only, before I was flushing on the selector and on the class. It is not yet clear to me what is the right way of flushing the cache. Any explanation on that?
Hmmm, no. I would have thought that the right thing to do was to flush the selector. Do you have an image containing a reproducible case I can test?
I think that this goes along with http://code.google.com/p/pharo/issues/detail?id=2255 http://forum.world.st/flushCache-with-MethoWrappers-in-CogVM-td3381310.html
Eliot, if you need help debugging or testing a potential solution let me know, I have a bunch of test working on top of this.
Cheers,
On Mon, Jul 11, 2011 at 6:31 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All, I'm in touch with Lukas on this but have no time to address it right
now. worry not :)
On Mon, Jul 11, 2011 at 3:05 AM, Mariano Martinez Peck <
marianopeck@gmail.com> wrote:
Maybe cc'ing VM mailing list can help.
On Fri, Jul 1, 2011 at 9:32 AM, Lukas Renggli renggli@gmail.com
wrote:
Hi Eliot,
I am using one of the latest VMs from your site (VM.r2434) and I continue to have subtle problems with objects as methods (#flushCache, #run:with:in:).
The issue is that the test coverage in Pharo is kind of broken on Cog for a long time already. It reports methods as not covered that are clearly covered, and tests seem to randomly fail.
I suspected that there is something wrong with the coverage code itself. So I started to experiment with TestCoverage>>flushCache and noticed that the current implementation
TestCoverage>>flushCache self reference methodSymbol flushCache
performs not that well: The set of not covered methods is wrong and many tests suddenly fail. If I replace it with
TestCoverage>>flushCache self reference actualClass flushCache
I actually get accurate coverage information, but there are still a few tests constantly failing. I tried to use all possible combinations of #flushCache (also calling it on the compiled method), but only flushing the cache on the class seems to work properly. So far so good, but I really wonder what the correct way is to flush the cache? :-)
For my experiments I was using the package 'AST-Tests-Semantics'. This is a small package with lots of test methods that cover each method but one (RBSemanticAnnotationMisssing>>#isResumable). Now the "real" problem is that when running these tests in coverage mode, the same 4 tests always fail:
RBSemanticTest>>testBlockScope RBSemanticTest>>testCascadeReceiver RBSemanticTest>>testClassVariableBinding RBSemanticTest>>testGlobalVariableBinding
Not sure of how to debug that? Do you have an idea why these otherwise passing tests suddenly fail? If you want to try to reproduce you can use any Pharo image with the tests loaded, or use those that I used:
http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifact...
http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifact...
Open the Test Runner, select 'AST-Tests-Semantics' and 'Run Coverage'.
Any help or clarification would be appreciated :-)
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Mariano http://marianopeck.wordpress.com
-- best, Eliot
-- Jorge Ressia www.jorgeressia.com
Hi Eliot,
I put the image in http://dl.dropbox.com/u/14991225/Bifrost-Eliot.zip I am using VM.r2486.
The object as method class is called HLMethod. I reverted the change on flushCache to have the previous implementation that breaks. If you run the tests in BFBehavioralMetaObjectTest, particularly the category "test - state write" several time at some point some tests are going to fail due to a DNU on GMDualCounter>>initialize.
If you change the HLMethod>>flushCache to
flushCache <primitive: 116>
This errors disappear.
Sorry that I do not have a simpler example to reproduce the case but i tried to simplify it but could not reproduce it. I think that is has to do with the number of times that I change the compiled method at runtime.
Cheers,
On Mon, Aug 8, 2011 at 9:32 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Jorge,
On Mon, Aug 8, 2011 at 12:20 PM, Jorge Ressia jorge.ressia@gmail.com wrote:
Hi Eliot,
I am experiencing the same problem as Lukas. I was having random DNU on replaced methods. I fixed the problem by flushing the cache on the compiled methods only, before I was flushing on the selector and on the class. It is not yet clear to me what is the right way of flushing the cache. Any explanation on that?
Hmmm, no. I would have thought that the right thing to do was to flush the selector. Do you have an image containing a reproducible case I can test?
I think that this goes along with http://code.google.com/p/pharo/issues/detail?id=2255 http://forum.world.st/flushCache-with-MethoWrappers-in-CogVM-td3381310.html
Eliot, if you need help debugging or testing a potential solution let me know, I have a bunch of test working on top of this.
Cheers,
On Mon, Jul 11, 2011 at 6:31 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All, I'm in touch with Lukas on this but have no time to address it right now. worry not :)
On Mon, Jul 11, 2011 at 3:05 AM, Mariano Martinez Peck marianopeck@gmail.com wrote:
Maybe cc'ing VM mailing list can help.
On Fri, Jul 1, 2011 at 9:32 AM, Lukas Renggli renggli@gmail.com wrote:
Hi Eliot,
I am using one of the latest VMs from your site (VM.r2434) and I continue to have subtle problems with objects as methods (#flushCache, #run:with:in:).
The issue is that the test coverage in Pharo is kind of broken on Cog for a long time already. It reports methods as not covered that are clearly covered, and tests seem to randomly fail.
I suspected that there is something wrong with the coverage code itself. So I started to experiment with TestCoverage>>flushCache and noticed that the current implementation
TestCoverage>>flushCache self reference methodSymbol flushCache
performs not that well: The set of not covered methods is wrong and many tests suddenly fail. If I replace it with
TestCoverage>>flushCache self reference actualClass flushCache
I actually get accurate coverage information, but there are still a few tests constantly failing. I tried to use all possible combinations of #flushCache (also calling it on the compiled method), but only flushing the cache on the class seems to work properly. So far so good, but I really wonder what the correct way is to flush the cache? :-)
For my experiments I was using the package 'AST-Tests-Semantics'. This is a small package with lots of test methods that cover each method but one (RBSemanticAnnotationMisssing>>#isResumable). Now the "real" problem is that when running these tests in coverage mode, the same 4 tests always fail:
RBSemanticTest>>testBlockScope RBSemanticTest>>testCascadeReceiver RBSemanticTest>>testClassVariableBinding RBSemanticTest>>testGlobalVariableBinding
Not sure of how to debug that? Do you have an idea why these otherwise passing tests suddenly fail? If you want to try to reproduce you can use any Pharo image with the tests loaded, or use those that I used:
http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifact... http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifact...
Open the Test Runner, select 'AST-Tests-Semantics' and 'Run Coverage'.
Any help or clarification would be appreciated :-)
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Mariano http://marianopeck.wordpress.com
-- best, Eliot
-- Jorge Ressia www.jorgeressia.com
-- best, Eliot
Hi Jorge,
I've taken a look at this and its horrible. Basically the debug VM (no optimization, asserts, and so fully debuggable) doesn't fail. Only the production and assert (-O1, asserts) show failuresa. But since this is in TestRunner it is extremely difficult to compare the three VMs rto find out where the difference lies becauee TestRunner runs things in a random order.
So could you do me a favour and construct an image where the tests are run in a fixed order and show the error? Please try and avoid the test that asks for one's name. I want to be able to run the image from the C debugger without user intervention to analyse exactly what's going on.
Thanks in advance
On Mon, Aug 8, 2011 at 2:27 PM, Jorge Ressia jorge.ressia@gmail.com wrote:
Hi Eliot,
I put the image in http://dl.dropbox.com/u/14991225/Bifrost-Eliot.zip I am using VM.r2486.
The object as method class is called HLMethod. I reverted the change on flushCache to have the previous implementation that breaks. If you run the tests in BFBehavioralMetaObjectTest, particularly the category "test - state write" several time at some point some tests are going to fail due to a DNU on GMDualCounter>>initialize.
If you change the HLMethod>>flushCache to
flushCache <primitive: 116>
This errors disappear.
Sorry that I do not have a simpler example to reproduce the case but i tried to simplify it but could not reproduce it. I think that is has to do with the number of times that I change the compiled method at runtime.
Cheers,
On Mon, Aug 8, 2011 at 9:32 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Jorge,
On Mon, Aug 8, 2011 at 12:20 PM, Jorge Ressia jorge.ressia@gmail.com
wrote:
Hi Eliot,
I am experiencing the same problem as Lukas. I was having random DNU on replaced methods. I fixed the problem by flushing the cache on the compiled methods only, before I was flushing on the selector and on the class. It is not yet clear to me what is the right way of flushing the cache. Any explanation on that?
Hmmm, no. I would have thought that the right thing to do was to flush
the selector. Do you have an image containing a reproducible case I can test?
I think that this goes along with http://code.google.com/p/pharo/issues/detail?id=2255
http://forum.world.st/flushCache-with-MethoWrappers-in-CogVM-td3381310.html
Eliot, if you need help debugging or testing a potential solution let me know, I have a bunch of test working on top of this.
Cheers,
On Mon, Jul 11, 2011 at 6:31 PM, Eliot Miranda eliot.miranda@gmail.com
wrote:
Hi All, I'm in touch with Lukas on this but have no time to address it
right now. worry not :)
On Mon, Jul 11, 2011 at 3:05 AM, Mariano Martinez Peck <
marianopeck@gmail.com> wrote:
Maybe cc'ing VM mailing list can help.
On Fri, Jul 1, 2011 at 9:32 AM, Lukas Renggli renggli@gmail.com
wrote:
Hi Eliot,
I am using one of the latest VMs from your site (VM.r2434) and I continue to have subtle problems with objects as methods
(#flushCache,
#run:with:in:).
The issue is that the test coverage in Pharo is kind of broken on
Cog
for a long time already. It reports methods as not covered that are clearly covered, and tests seem to randomly fail.
I suspected that there is something wrong with the coverage code itself. So I started to experiment with TestCoverage>>flushCache and noticed that the current implementation
TestCoverage>>flushCache self reference methodSymbol flushCache
performs not that well: The set of not covered methods is wrong and many tests suddenly fail. If I replace it with
TestCoverage>>flushCache self reference actualClass flushCache
I actually get accurate coverage information, but there are still a few tests constantly failing. I tried to use all possible
combinations
of #flushCache (also calling it on the compiled method), but only flushing the cache on the class seems to work properly. So far so good, but I really wonder what the correct way is to flush the
cache?
:-)
For my experiments I was using the package 'AST-Tests-Semantics'.
This
is a small package with lots of test methods that cover each method but one (RBSemanticAnnotationMisssing>>#isResumable). Now the "real" problem is that when running these tests in coverage mode, the same
4
tests always fail:
RBSemanticTest>>testBlockScope RBSemanticTest>>testCascadeReceiver RBSemanticTest>>testClassVariableBinding RBSemanticTest>>testGlobalVariableBinding
Not sure of how to debug that? Do you have an idea why these
otherwise
passing tests suddenly fail? If you want to try to reproduce you can use any Pharo image with the tests loaded, or use those that I used:
http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifact...
http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifact...
Open the Test Runner, select 'AST-Tests-Semantics' and 'Run
Coverage'.
Any help or clarification would be appreciated :-)
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Mariano http://marianopeck.wordpress.com
-- best, Eliot
-- Jorge Ressia www.jorgeressia.com
-- best, Eliot
-- Jorge Ressia www.jorgeressia.com
Hi Eliot,
I managed to reproduced the error outside the test runner. http://dl.dropbox.com/u/14991225/Bifrost-Eliot.zip
I have added the class FlushingCacheTester which does the same the failing methods were doing. If you execute FlushingCacheTester failingMethod
you should get the error. It seems that there is a problem in the sequence
This does not produce the error FlushingCacheTester new run
But this does FlushingCacheTester new run; run2.
In #run2 I only changed the order of one method.
You should not have the Author problem anymore.
Let me know if you need anything else.
Thanks for the effort.
Cheers,
On Wed, Aug 10, 2011 at 9:31 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Jorge, I've taken a look at this and its horrible. Basically the debug VM (no optimization, asserts, and so fully debuggable) doesn't fail. Only the production and assert (-O1, asserts) show failuresa. But since this is in TestRunner it is extremely difficult to compare the three VMs rto find out where the difference lies becauee TestRunner runs things in a random order. So could you do me a favour and construct an image where the tests are run in a fixed order and show the error? Please try and avoid the test that asks for one's name. I want to be able to run the image from the C debugger without user intervention to analyse exactly what's going on. Thanks in advance
On Mon, Aug 8, 2011 at 2:27 PM, Jorge Ressia jorge.ressia@gmail.com wrote:
Hi Eliot,
I put the image in http://dl.dropbox.com/u/14991225/Bifrost-Eliot.zip I am using VM.r2486.
The object as method class is called HLMethod. I reverted the change on flushCache to have the previous implementation that breaks. If you run the tests in BFBehavioralMetaObjectTest, particularly the category "test - state write" several time at some point some tests are going to fail due to a DNU on GMDualCounter>>initialize.
If you change the HLMethod>>flushCache to
flushCache <primitive: 116>
This errors disappear.
Sorry that I do not have a simpler example to reproduce the case but i tried to simplify it but could not reproduce it. I think that is has to do with the number of times that I change the compiled method at runtime.
Cheers,
On Mon, Aug 8, 2011 at 9:32 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Jorge,
On Mon, Aug 8, 2011 at 12:20 PM, Jorge Ressia jorge.ressia@gmail.com wrote:
Hi Eliot,
I am experiencing the same problem as Lukas. I was having random DNU on replaced methods. I fixed the problem by flushing the cache on the compiled methods only, before I was flushing on the selector and on the class. It is not yet clear to me what is the right way of flushing the cache. Any explanation on that?
Hmmm, no. I would have thought that the right thing to do was to flush the selector. Do you have an image containing a reproducible case I can test?
I think that this goes along with http://code.google.com/p/pharo/issues/detail?id=2255
http://forum.world.st/flushCache-with-MethoWrappers-in-CogVM-td3381310.html
Eliot, if you need help debugging or testing a potential solution let me know, I have a bunch of test working on top of this.
Cheers,
On Mon, Jul 11, 2011 at 6:31 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All, I'm in touch with Lukas on this but have no time to address it right now. worry not :)
On Mon, Jul 11, 2011 at 3:05 AM, Mariano Martinez Peck marianopeck@gmail.com wrote:
Maybe cc'ing VM mailing list can help.
On Fri, Jul 1, 2011 at 9:32 AM, Lukas Renggli renggli@gmail.com wrote: > > Hi Eliot, > > I am using one of the latest VMs from your site (VM.r2434) and I > continue to have subtle problems with objects as methods > (#flushCache, > #run:with:in:). > > The issue is that the test coverage in Pharo is kind of broken on > Cog > for a long time already. It reports methods as not covered that are > clearly covered, and tests seem to randomly fail. > > I suspected that there is something wrong with the coverage code > itself. So I started to experiment with TestCoverage>>flushCache > and > noticed that the current implementation > > TestCoverage>>flushCache > self reference methodSymbol flushCache > > performs not that well: The set of not covered methods is wrong and > many tests suddenly fail. If I replace it with > > TestCoverage>>flushCache > self reference actualClass flushCache > > I actually get accurate coverage information, but there are still a > few tests constantly failing. I tried to use all possible > combinations > of #flushCache (also calling it on the compiled method), but only > flushing the cache on the class seems to work properly. So far so > good, but I really wonder what the correct way is to flush the > cache? > :-) > > For my experiments I was using the package 'AST-Tests-Semantics'. > This > is a small package with lots of test methods that cover each method > but one (RBSemanticAnnotationMisssing>>#isResumable). Now the > "real" > problem is that when running these tests in coverage mode, the same > 4 > tests always fail: > > RBSemanticTest>>testBlockScope > RBSemanticTest>>testCascadeReceiver > RBSemanticTest>>testClassVariableBinding > RBSemanticTest>>testGlobalVariableBinding > > Not sure of how to debug that? Do you have an idea why these > otherwise > passing tests suddenly fail? If you want to try to reproduce you > can > use any Pharo image with the tests loaded, or use those that I > used: > > > http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifact... > > http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifact... > > Open the Test Runner, select 'AST-Tests-Semantics' and 'Run > Coverage'. > > Any help or clarification would be appreciated :-) > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >
-- Mariano http://marianopeck.wordpress.com
-- best, Eliot
-- Jorge Ressia www.jorgeressia.com
-- best, Eliot
-- Jorge Ressia www.jorgeressia.com
-- best, Eliot
vm-dev@lists.squeakfoundation.org