Squeak-dev July 2008

squeak-dev@lists.squeakfoundation.org

136 participants
183 discussions

About FarRefs/Islands (Was:Re: [squeak-dev] Re: Prepare for Thousands of Cores --- oh my Chip - it's full of cores!)
by Igor Stasenko 07 Jul '08

07 Jul '08

2008/7/7 Klaus D. Witzel <klaus.witzel(a)cobss.com>: > On Mon, 07 Jul 2008 14:38:21 +0200, Igor Stasenko wrote: > >>> >> of course, a difference lies only in a way how we sending message to >> object, wrapped by FarRef. > > I think that the main difference we have here is induced by your "it is > impossible by design to get direct reference to any object which not belongs > to same island." which I take literally (without objection, to be clear). As > a consequence, when running "in island #1" you cannot do > > proxy := anIsland2Object asFarRef. > yes, in island1 you can't reach any object from island2. So the above makes no sense, because you don't see anIsland2Object. Or if you see it, it is already a FarRef, and therefore you don't need putting #asFarRef. But writing: proxy := myLocalObject asFarRef. does not contradicts with anything. You asking to wrap local object with FarRef - no problem! > instead you must do > > proxy := FarRef with: anIsland2Object. > > and moreover [on a sideline, not so important] one cannot ask to which > island *any* far (but as-yet-not-wrapped) object belongs. > yes, its not really important, because the need in checking to which island belongs FarRef really needed just in couple places when you either sending message to foreign island or receiving message result from it. > Therefore I thought that sending something to a far (but as-yet-not-wrapped) > object is like a DNU which the VM detects and automatically wraps into a > FarMessageSend. > There is no VM, remember? No layer which magically controls such cases, unless you provide such layer yourself ;) They way how object(s) reacting on messages can be vary. And you can't reach 'as-yet-not-wrapped' objects. All foreign objects always seen by local islands as FarRefs. > I think this is quite a difference to systems which would be based on > manually wrapping (developer-driven-wrapping DDW), in which the impossibly > to obtain a direct reference would be left to the developer (and/or her/his > bugs). > >>>> For referencing objects from different island there will be a FarRef, >>>> which will be responsible for handling message sends to object in >>>> different island. >>> >>> Hah :) a natural extension of the #doesNotUnderstand: concept (with >>> FarMessageSend a subclass of MessageSend :) >>> >> Nah! >> You don't need to use DNU pattern, > > See above, not having sort of DNU can easily contradict your "it is > impossible by design to get direct reference to any object which not belongs > to same island". Somehow every *failure* to *not* get a direct reference > must be detected and acted upon (note the negations). > Its not contradicts the rule - the DNU exception will happen in another island and will be handled appropriately. > --------------- > > If you like we can go into more detail in email (also addressing #new > instances and their belonging to an owner). > This really a tough question :) The reason, why i don't want to have island1 to play directly with objects in island2 is because, if we do everything clean, it will be possible to run GC on a per-island basis without preempting any processes running in another islands, and without need in inventing a concurrent GC, running in separate thread. Classes (or at least its parts which responding for behavior of objects) should employ some kind of sharing between islands. Otherwise, everything will fall to same model, which currently Hydra employs - island == separate image. I'm not ready to answer this question. :) I can only describe a situation, and problems i see. (I guess Andreas have more to say, because he did that once) Lets look on it from the very start: Suppose we having island1, and creating new island2. Now we want to populate it with objects. Since island2 initially does not contains any objects, first message(s) would be messages to island itself. Lets suppose a blatant code sample: farIsland2 := Island new. farArray := farIsland2 do: [ Array new ]. So, here we created new island, and putting Array instance in it, and result of the whole expression should be FarRef pointing to that Array. It is clear, that it will not go as we want to: First, an 'Island new' should return a FarRef - a far reference to newly created island. So #perform: is FarMessageSend. But since we passing block closure which belongs to current island, it will be wrapped with FarRef. So, then when its going to send #value to block (in implementation of #do:), this leads to another FarMessageSend. And finally, block will be performed in island1 , and new instance of Array will be created on island1 instead of island2 :) -- Best regards, Igor Stasenko AKA sig.

1 0

SUnit infinite loop detection
by nicolas cellier 07 Jul '08

07 Jul '08

I wanted to assert some infiniteLoop, but found no other support than: should:notTakeMoreThanMilliseconds: I do not really like it, because it may vary - a fast machine could exhaust memory and crash before duration - a slow machine could fail I put a proposal for recursive loops at http://bugs.squeak.org/view.php?id=7111 In case of Error during block execution, my implementation makes the test pass. I think it's wrong, but do not know how to handle... And i am still interested by a way to assert infinite iterative loop (the whileTrue/whileFalse case). Anyone has an idea about it? Nicolas

6 11

All tests running green
by Ken G. Brown 07 Jul '08

07 Jul '08

At 4:30 PM -0700 7/6/08, squeak-dev-request(a)lists.squeakfoundation.org apparently wrote: >Date: Sun, 6 Jul 2008 14:09:15 -0700 (PDT) >From: Jerome Peace <peace_the_dreamer(a)yahoo.com> >Subject: [squeak-dev] All tests running green >To: squeak-dev(a)lists.squeakfoundation.org >Message-ID: <377860.60608.qm(a)web50312.mail.re2.yahoo.com> >Content-Type: text/plain; charset=us-ascii > >All tests running green > > >Ken G. Brown wrote: >> I think that the dev images should ship with all tests running green. > >Cool. How? Of course the basic image would have to have all tests green to start. And I suppose not pre-loading any packages that cause failing tests would be a start. Those ones can be showcased and easily available for loading, and if the package maintainers want them included pre-loaded in the dev images, they would need to fix the issues. >It is a hard task just to get the basic image to run its tests green. >The dev image introduces a lot of packages to each other often for the first time. > >Damien does a mighty service by providing fresh integration every month. +1! >This is probably near the limit of the time service he can give to the community. > >Are you willing to recruit someone to post > the results of the tests runs for a dev image each month? >It seems to me that would be the next step. > >The reports would be the feedback that lead to green tests. I am away from home for a couple weeks and will not be able to do anything towards that during the time away. I will see what I can do when I get back to it. >*** Ken Wrote: >>I'd like to have confidence that everything added to 3.10.2 also includes >>tests for everything added, and that all tests run unattended and everything >>ends green. > >+1 > >>For starters, on Mac 10.5.4, fresh sq3.10.2-7179dev08.07.1 on Squeak >>3.8.18beta1U.app vm, pull out the Test Runner, select all standard tests, >>start to ru > >n 2788 tests, and with manual intervention required several >>times, it only gets to 394 run, 374 passes, 2 expected failures, 5 failures >>13 error, before it quits processing. >*** > > >Cool, what test does it quit on? How can I tell? It said 394 run when it quit. Your comments make good sense. Ken G. Brown >What test expect themselves to fail? >And what are the errors and failures? > >If you take out those tests how does the rest run? > >It would seem to me, just as Damien contributes by producing the images, > someone needs to contribute by producing the reports > on the tests from the images. > >If someone one is willing, then others will be able to add bug removal. >And the dev images can converge until Ken gets his wish. > >Bugs are like litter they can accumulate one at a time > or be eliminated one at a time. > >What the community needs is the accumulated help > of those who are in the right position to tackle the problems. > >I can find bugs and I can puzzle out some good solutions to interesting ones. > >I can't also run tests extensively or continuously to discover > all the possible intergration problems the fixes might lead to. > > >Sqeuak is 30 years old some of the older parts do not share > the same assumptions as the newer parts. >There are a lot of integration bugs. >And the more you integrate the more problems you will find. > > ***And later Ken wrote: >>I'm suggesting that anything pre-loaded by you into the dev images, come with >>tests and all tests be green for the release dev image. >>Other stuff can however be showcased by listing in the dev image and be easy >>to load, but not be pre-loaded if they cause any tests to fail. >***from http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-July/129970.html > >It will probably be important to have distributable images with those properties. > But the fastest way to get there is to make the mistakes first. >Damiens dev images are integration betas. > They are there first and will need to be tested. > >Once the tests are made and reported. >Other integration scripts can be written > s.t. a stable dev image meeting your critriria could be accomplished. >Either by leaving out packages or failing tests. >Progress is made by walking forward. >Walking forward is made by falling > and catching yourself before you land on your face. > >Damien's images are a necessary step. >Someone stepping forward and reporting test results > is the next necessary step. > >Yours in curiosity and service, --Jerome Peace

1 0

[ANN] SqueakLightII Sunday News !!!
by Edgar J. De Cleene 06 Jul '08

06 Jul '08

To the huge multitude of SqueakLightII (3.11 unofficial) fans I got Spirograph 3.005.pr of Diego Gomez Deck (2004 originated) as you could see in the pict. Still need some polish for fool proof newbies, but is running . Also I have Aida / Scribo running on SqueakLightII. And put the loading script on the swiki page. So , is not vaporware and begins to show people could have a smaller , modular image and choices about how he/she wish grow. In the process I learning a lot about the art of put the worms again in the same can as they live some time ago :=) As example , for proper loading my in Ladrillos version EToys-edc.29.mcz needs load ScriptEditorMorph , TwoWayScrollPane and ZoomAndScrollControllerMorph before. My in the way 7189PackagesUniversesGlue.6.cs could "discover" this and intelligent load the classes from ftp. No panic, I only put four classes for show the idea of classes repository I have from 2005 is working. If I have authorization, could put all stuff I have in ftp://squeakros.atspace.com/squeakros.atspace.com/CompressedClasses/ "3.8" ftp://edgardec@squeakros.atspace.com/squeakros.atspace.com/3dot9 ftp://squeakros.atspace.com/squeakros.atspace.com/3dot11. But wait, some classes from past was very weird designed. See by example TileMorph initialize , you should have three morphs and run a commented out method... The only fast solution I see is made a EtoysReload.sar with all the stuff into. Edgar

2 1

Re: Squeak-dev Digest, Vol 67, Issue 20
by Ken G. Brown 06 Jul '08

06 Jul '08

At 11:28 AM -0700 7/6/08, squeak-dev-request(a)lists.squeakfoundation.org apparently wrote: >Date: Sun, 6 Jul 2008 16:28:45 +0200 >From: "Damien Cassou" <damien.cassou(a)gmail.com> >Subject: Re: [squeak-dev] Different squeak-dev flavors 2 >To: "The general-purpose Squeak developers list" > <squeak-dev(a)lists.squeakfoundation.org> >Message-ID: > <6ac749c10807060728w6b8d1d87n3dad99920a6e0cfe(a)mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >On Sun, Jul 6, 2008 at 3:33 PM, Ken G. Brown <kbrown(a)mac.com> wrote: >> At 5:00 AM -0700 7/6/08, squeak-dev-request(a)lists.squeakfoundation.org apparently wrote: >>>Date: Sun, 6 Jul 2008 12:14:23 +0200 >>>From: "Damien Cassou" <damien.cassou(a)gmail.com> >>>Subject: Re: [squeak-dev] Different squeak-dev flavors 2 >>>To: "The general-purpose Squeak developers list" > >> <squeak-dev(a)lists.squeakfoundation.org> ><snip> > > >> I'd like to have confidence that everything added to 3.10.2 also includes tests for everything added, and that all tests run unattended and everything ends green. >> For starters, on Mac 10.5.4, fresh sq3.10.2-7179dev08.07.1 on Squeak 3.8.18beta1U.app vm, pull out the Test Runner, select all standard tests, start to run 2788 tests, and with manual intervention required several times, it only gets to 394 run, 374 passes, 2 expected failures, 5 failures 13 error, before it quits processing. >> >> I think that the dev images should ship with all tests running green. > > >I think these problems must be fixed by the release teams and by the >package maintainer. As an integretor, I can't do more than you on >these fields. The only thing I can do is to base the images on the >latest versions. > >-- >Damien Cassou >Peter von der AhÈ: ´I'm beginning to see why Gilad wished us good >luckª. (http://blogs.sun.com/ahe/entry/override_snafu) I'm suggesting that anything pre-loaded by you into the dev images, come with tests and all tests be green for the release dev image. Other stuff can however be showcased by listing in the dev image and be easy to load, but not be pre-loaded if they cause any tests to fail. Ken G. Brown

1 0

[Squeak-dev Images] About the different flavors
by Damien Cassou 06 Jul '08

06 Jul '08

Hi, I'm responsible for generating each month the squeak-dev images. They currently exist in 4 versions which are all downloaded a lot: - based on 3.9 (174 downloads) - based on 3.9 with web stuffs (158 dl) - based on 3.10 with beta stuffs (129 dl) - based on 3.10 with beta and web stuffs (166 dl) Since 3.10 is not beta anymore, I would like to know what I have to do to suit your needs. It seems 3.9 based images are still used a lot. Is it because 3.10 based images contain beta stuffs or because people don't believe in 3.10 or something else? I have set-up this poll to know if I still need to base the dev-images on top of 3.9 and 3.10. Base squeak-dev images http://www.doodle.ch/5u67s53greapfdu6 Also, I would like to know if you consider some packages still beta or not. Please also answer the following poll: Squeak-dev beta packages: http://www.doodle.ch/9y9r6nr2imci8g38 And what about the web stuffs? Do I need to duplicate all images to have one version with and one without? This thread is also here to collect your remarks and comments. I would like to collect opinions so that future images fit most of your needs. -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)

22 55

Re: [squeak-dev] Prepare for Thousands of Cores --- oh my Chip - it's full of cores!
by K. K. Subramaniam 06 Jul '08

06 Jul '08

On Sunday 06 Jul 2008 1:30:28 am Jecel Assumpcao Jr wrote: > Intel and Microsoft may have forgotten these lessons, but some of us > haven't. And having them cough up $20M for a joint research project in > multi-core software doesn't impress me very much. I bet just the coffee > budget at either of these companies is a lot larger than that. The engineering issues are different this time. Intel is talking about their capability to bring 1K-core boards to the retail store level. This is very different from a research project in a handful of locations accessible to a few researchers. J-Machine builders did not have to deal with battery drain :-). You do have a point about Intel/MS ignoring past work in this area. Their research director could have presented the capability as a revival of prior research instead of making it appear like a new challenge. CST and Actalk are over two decades old and cited in many ACM papers. Their collective amnesia is inexcusable. If processing elements could be wrapped in an object, then 1024 looks like a small number.... Subbu

2 2

Re: [squeak-dev] Different squeak-dev flavors 2
by Damien Cassou 06 Jul '08

06 Jul '08

On Sun, Jul 6, 2008 at 3:33 PM, Ken G. Brown <kbrown(a)mac.com> wrote: > At 5:00 AM -0700 7/6/08, squeak-dev-request(a)lists.squeakfoundation.org apparently wrote: >>Date: Sun, 6 Jul 2008 12:14:23 +0200 >>From: "Damien Cassou" <damien.cassou(a)gmail.com> >>Subject: Re: [squeak-dev] Different squeak-dev flavors 2 >>To: "The general-purpose Squeak developers list" >> <squeak-dev(a)lists.squeakfoundation.org> >>Message-ID: >> <6ac749c10807060314p187b4bao486d8c3e92555fa3(a)mail.gmail.com> >>Content-Type: text/plain; charset=ISO-8859-1 >> >>On Fri, Jul 4, 2008 at 11:31 PM, Ken G. Brown <kbrown(a)mac.com> wrote: >>> >>> At 5:00 AM -0700 7/4/08, squeak-dev-request(a)lists.squeakfoundation.org apparently wrote: >>>>Date: Fri, 4 Jul 2008 13:49:21 +0200 >>>>From: "Damien Cassou" <damien.cassou(a)gmail.com> >>>>Subject: [squeak-dev] Different squeak-dev flavors 2 >>>>To: "The general-purpose Squeak developers list" >>>> <squeak-dev(a)lists.squeakfoundation.org> >>>>Message-ID: >>>> <6ac749c10807040449i74a6105etda14986d34599096(a)mail.gmail.com> >>>>Content-Type: text/plain; charset=ISO-8859-1 >>>> >>>>Hi again, >>>> >>>>the discussions on the other thread are interesting but you forgot to >>>>answer my questions. I would like to know what are the different >>>>flavors you want to see in the future? >>>> >>>>Two polls are available to help me. >>>> >>>>Base squeak-dev images >>>>http://www.doodle.ch/5u67s53greapfdu6 >>>> >>>>Squeak-dev beta packages: >>>>http://www.doodle.ch/9y9r6nr2imci8g38 >>>> >>>>Please also comment on your votes. Doodle allows you to write comments. >>>> >>>>On Monday, I will try to make a proposal based on your votes and comments. >>>> >>>>-- >>>>Damien Cassou >>>>Peter von der Ah»: ¥I'm beginning to see why Gilad wished us good >>>>luck . (http://blogs.sun.com/ahe/entry/override_snafu) >>> >>> I'd like to see the stuff added to the basic 3.10.2 to make the dev version include all their tests, and have all tests green. >> >>What are you talking about? I already base the squeak-dev image on 3.10.2. >> >>-- >>Damien Cassou >>Peter von der AhÈ: ´I'm beginning to see why Gilad wished us good >>luckª. (http://blogs.sun.com/ahe/entry/override_snafu) > > I'd like to have confidence that everything added to 3.10.2 also includes tests for everything added, and that all tests run unattended and everything ends green. > For starters, on Mac 10.5.4, fresh sq3.10.2-7179dev08.07.1 on Squeak 3.8.18beta1U.app vm, pull out the Test Runner, select all standard tests, start to run 2788 tests, and with manual intervention required several times, it only gets to 394 run, 374 passes, 2 expected failures, 5 failures 13 error, before it quits processing. > > I think that the dev images should ship with all tests running green. I think these problems must be fixed by the release teams and by the package maintainer. As an integretor, I can't do more than you on these fields. The only thing I can do is to base the images on the latest versions. -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)

1 0

C++ parser in Smalltalk?
by Peter William Lount 06 Jul '08

06 Jul '08

Hi, Does anyone know of a working C++ parser written in Smalltalk? Just the front end would be fine, it doesn't have to generate any code. I just want to have a Smalltalk/Squeak program read the darn stuff so I can play with the information. If not what would you suggest as an approach for having one with a minimum of effort? Thanks in advance, Peter

10 24

Re: [squeak-dev] Different squeak-dev flavors 2
by Ken G. Brown 06 Jul '08

06 Jul '08

At 5:00 AM -0700 7/6/08, squeak-dev-request(a)lists.squeakfoundation.org apparently wrote: >Date: Sun, 6 Jul 2008 12:14:23 +0200 >From: "Damien Cassou" <damien.cassou(a)gmail.com> >Subject: Re: [squeak-dev] Different squeak-dev flavors 2 >To: "The general-purpose Squeak developers list" > <squeak-dev(a)lists.squeakfoundation.org> >Message-ID: > <6ac749c10807060314p187b4bao486d8c3e92555fa3(a)mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 > >On Fri, Jul 4, 2008 at 11:31 PM, Ken G. Brown <kbrown(a)mac.com> wrote: >> >> At 5:00 AM -0700 7/4/08, squeak-dev-request(a)lists.squeakfoundation.org apparently wrote: >>>Date: Fri, 4 Jul 2008 13:49:21 +0200 >>>From: "Damien Cassou" <damien.cassou(a)gmail.com> >>>Subject: [squeak-dev] Different squeak-dev flavors 2 >>>To: "The general-purpose Squeak developers list" >>> <squeak-dev(a)lists.squeakfoundation.org> >>>Message-ID: >>> <6ac749c10807040449i74a6105etda14986d34599096(a)mail.gmail.com> >>>Content-Type: text/plain; charset=ISO-8859-1 >>> >>>Hi again, >>> >>>the discussions on the other thread are interesting but you forgot to >>>answer my questions. I would like to know what are the different >>>flavors you want to see in the future? >>> >>>Two polls are available to help me. >>> >>>Base squeak-dev images >>>http://www.doodle.ch/5u67s53greapfdu6 >>> >>>Squeak-dev beta packages: >>>http://www.doodle.ch/9y9r6nr2imci8g38 >>> >>>Please also comment on your votes. Doodle allows you to write comments. >>> >>>On Monday, I will try to make a proposal based on your votes and comments. >>> >>>-- >>>Damien Cassou >>>Peter von der Ah»: ¥I'm beginning to see why Gilad wished us good >>>luck. (http://blogs.sun.com/ahe/entry/override_snafu) >> >> I'd like to see the stuff added to the basic 3.10.2 to make the dev version include all their tests, and have all tests green. > >What are you talking about? I already base the squeak-dev image on 3.10.2. > >-- >Damien Cassou >Peter von der AhÈ: ´I'm beginning to see why Gilad wished us good >luckª. (http://blogs.sun.com/ahe/entry/override_snafu) I'd like to have confidence that everything added to 3.10.2 also includes tests for everything added, and that all tests run unattended and everything ends green. For starters, on Mac 10.5.4, fresh sq3.10.2-7179dev08.07.1 on Squeak 3.8.18beta1U.app vm, pull out the Test Runner, select all standard tests, start to run 2788 tests, and with manual intervention required several times, it only gets to 394 run, 374 passes, 2 expected failures, 5 failures 13 error, before it quits processing. I think that the dev images should ship with all tests running green. Ken G. Brown

1 0

← Newer
1
...
12
13
14
15
16
17
18
19
Older →

Jump to page: