Squeak-dev July 2008

squeak-dev@lists.squeakfoundation.org

136 participants
183 discussions

Start a nNew thread

off-topic: another Lively...
by Craig Latta 09 Jul '08

09 Jul '08

http://www.techcrunch.com/2008/07/08/google-launches-virtual-world-called-l… -C

1 0

Differencing ordered sets
by Bergel, Alexandre 08 Jul '08

08 Jul '08

Dear list, Is there a diff-like mechanism in Squeak? I've heard there is a diff tool in Squeak that operates on texts. Anyone has the url? Although I want to be able to work with any arbitrary ordered sets, beginning with texts might be a good start. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 3

Fwd: [Esug-list] [ESUG conf] Hotel discount dead-line is July 11th
by Noury Bouraqadi 08 Jul '08

08 Jul '08

Thanks Mathilde. Noury Begin forwarded message: > From: Mathilde Mupe <mathilde(a)soops.nl> > Date: 8 juillet 2008 14:45:26 HAEC > To: esug-list(a)lists.esug.org > Subject: Re: [Esug-list] [ESUG conf] Hotel discount dead-line is > July 11th > > > Hi, I'm a ESUG list lurker for some years... > The list of hotel locations is fine. Great work Adriaan, making the > map. > For those who attend Esug by car and stay in a different location; > Roads from Central Station upto IJ-tunnel partly/fully closed due > to maintenance. > > see you, > > Mathilde > > Noury Bouraqadi wrote: >> Dear Smalltalkers, >> >> If you didn't book your hotel, it's time to do it. Some hotels >> agreed for discounts for the ESUG conference attendees (thanks >> local organizers!). But, the offer applies till july 11th. More >> info on the conference page: >> http://www.esug.org/conferences/2008 >> >> Cheers, >> Noury >> ------------------------------------------------------------------ >> Dr. Noury Bouraqadi - Enseignant/Chercheur >> Responsable de l'enseignement de l'informatique >> ARMINES - Ecole des Mines de Douai - Dept. I.A. >> http://vst.ensm-douai.fr/noury >> >> European Smalltalk Users Group Board >> http://www.esug.org >> ------------------------------------------------------------------ >> >> >> >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/listinfo/esug-list >> > > > -- > Graphic design and publicity Soops b.v. > Soops - Specialists in Object Technology > > Tel : +31 (0) 20 6222844 > Fax : +31 (0) 20 6360827 > Web: www.soops.nl > > Please consider the environment before printing this e-mail > ********************************************************************* > Dit e-mailbericht is alleen bestemd voor de geadresseerde(n). > Gebruik door anderen is niet toegestaan. Indien u niet de > geadresseerde(n) bent wordt u verzocht de verzender hiervan > op de hoogte te stellen en het bericht te verwijderen. > Door de elektronische verzending kunnen aan de inhoud van > dit bericht geen rechten worden ontleend. > > Soops B.V. is gevestigd te Amsterdam, Nederland, en is > geregistreerd bij de Kamer van Koophandel onder nummer 33240368. > Soops B.V. levert volgens de Fenit voorwaarden, gedeponeerd > te Den Haag op 8 december 1994 onder nummer 1994/189. > > ********************************************************************** > This e-mail message is intended to be exclusively for the addressee. > If you are not the intended recipient you are kindly requested not to > make any use whatsoever of the contents and to notify the sender > immediately by returning this e-mail message. No rights can be > derived from this message. > > Soops B.V. is a private limited liability company and has its seat at > Amsterdam, The Netherlands and is registered with the Trade Registry > of the Chamber of Commerce and Industry under number 33240368. > Soops B.V. delivers according to the General Terms and Conditions of > Business of Fenit, registered at The Hague, The Netherlands on > December 8th, 1994, under number 1994/189 > > ********************************************************************** > > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/listinfo/esug-list > Noury Bouraqadi ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Responsable de l'enseignement de l'informatique ARMINES - Ecole des Mines de Douai - Dept. I.A. http://vst.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org ------------------------------------------------------------------

1 0

Squeak by Example
by "Hübner, Uwe" 08 Jul '08

08 Jul '08

Hi, first of all: Great book!!! Currently I've made it through the book up to page 153 (that is end of chapter 6). While reading I've made some comments in the printout. Someone interested? If yes: To whom should I send it? Uwe (Still I'm a beginner to Squeak!)

3 2

Integer bits
by nicolas cellier 08 Jul '08

08 Jul '08

To speed a little bit SmallInteger highBit and lowBit, see http://bugs.squeak.org/view.php?id=7113 This is not a premature optimization. These low level messages are important for a number of packages. - DigitalSignature - ArbitraryPrecisionFloat - LargeInteger arithmetic / printing (mantis #6887) - conversions: - Float asTrueFraction (mantis #3373) - Fraction asFloat (mantis #3568) - SqNumberParser (mantis #3512 #6976 #6982) - ... We can optimize further. The precomputed array could be easily extended to 256 elements if needed. Concerning space, a ByteArray would also be sufficient, but would require a Class variable. This helped me finding http://bugs.squeak.org/view.php?id=7114 Analysis of senders seems to indicate this flaw did not strike yet. A long time since i did not find a bug. Is kernel stabilizing? Last, for manipulating bits, i found that a bitAt: was lacking. See http://bugs.squeak.org/view.php?id=6985 Nicolas

1 0

Namespaces
by Michael van der Gulik 08 Jul '08

08 Jul '08

Hi all. My Namespaces architecture(1) seems stable enough for other people to look at. I'd like to release an image so that other people can check it out. Is there somewhere I could put an image? Gulik. (1) http://gulik.pbwiki.com/Namespaces -- http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/

5 19

Fwd: [Webteam] Choosing the platform for website
by Igor Stasenko 07 Jul '08

07 Jul '08

Janko, i forwarded your message to squeak-dev, to be more visible to public :) ---------------- Dear all, I think now a time came to finally choose a platform and to upgrade our website. You know, Jun with exams is over and every Squeaker has now a time. Holidays? What holidays? ;) So, we have two proposals on-line: Aida/Web/Scribo based: http://squeaksite.aidaweb.si/ Seaside/Pier based: http://squeak.lukas-renggli.ch/ One is also mine as you know, so I will from now on always declare in advance if I speak as a webteam leader or a proposer. Now I'm speaking as a team leader. I promise to be as honest as possible. I propose that the end of July is a deadline to a final decision. In the meantime both contenders should: - prepare a replica of current website with all existing features and the same design - prepare a Contact Us solution to prevent spam Any suggestions, any comments? Best regards Janko Web team leader _______________________________________________ Webteam mailing list Webteam(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/webteam --------------------- Just 1 question: who will decide which platform will be taken? Because if we don't decide who is in charge to decide it, we still have a 50/50 situation and no decision will be made. My personal preferences: Board? - i don't think so Community alltogether? - maybe Web-team? - i think web-team having full right to decide And second question (just born): is it worth arguing which platform to choose, to again, lose more time (we could be able to start migrating to new platform as far back in April, if there would be a decision made)? -- Best regards, Igor Stasenko AKA sig.

7 9

All tests running green
by Jerome Peace 07 Jul '08

07 Jul '08

All tests running green Ken G. Brown wrote: > I think that the dev images should ship with all tests running green. Cool. How? 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. 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. *** 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? 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

10 20

Bootstrapping closures
by Eliot Miranda 07 Jul '08

07 Jul '08

(subject changed; was Anyone know the following about Slang?) On Mon, Jul 7, 2008 at 3:18 AM, Keith Hodges <keith_hodges(a)yahoo.co.uk> wrote: > Eliot Miranda wrote: > >> David, >> >> thanks a lot! I have some integration to do :) Not least I want to >> integrate the pragma support in 3.9 back into 3.8 because using pragmas >> instead of the null statements (self var: #foo type: #barf) etc is so much >> nicer. I also have to produce bootstraps for the closure compiler in a few >> images, e.g. Croquet 1.0, 3.9, 3.10 & Spoon. Once I get the Croquet >> bootstrap done I would welcome volunteers for the others. >> >> cheers! >> > I am curious as to how you intent to distribute these backported > bootstraps? Is this something > http://installer.pbwiki.com/LevelPlayingField can help you with? I'm not yet sure how I'll distribute. Ideally I think a set of Monticello packages plus a Monticello package containing a bootstrap script. This is what I have internally for our Qwaq Forums image bootrtap (derived from Croquet 1.0, in turn derived from 3.8). But when I tried to modify this bootstrap to boot a minimal 3.8 for testing the new VM I failed to get it working and gave up after about a day and a half. The thing I know will work is a set of change sets but that's not ideal. Thanks for the pointer to LPF. That could indeed help. But the real issue with this bootstrap is the related changes straddling Compiler (a new compiler for Closures), Kernel (a new BlockClosure and related changes in ContextPart, InstructionStream, CompiledMethod et al), System (new specialObjectsArray etc) and Tools (new interface between debugger and contexts). It is really easy to break the debugger when loading the bootstrap incorrectly and that makes working out what's wrong tricky. So progress is slow. Moving to change sets is easier because one doesn't have to filter out as many extraneous changes in a package which are the result of other changes unrelated to closures.

1 0

Anyone know the following about Slang?
by Eliot Miranda 07 Jul '08

07 Jul '08

Hi All, does anyone know (or even better has anyone fixed it) how hard it is to make Slang inline methods that contain simple type declarations? I would like to eliminate compile-time integer/pointer mismatch errors in the new StackInterpreter I'm writing. I'd like to say things like: callerSPOf: theFP "Answer the SP of the caller provided theFP is not a base frame. This points to the hottest item on the frame's stack." self var: #theFP type: 'char *'. self returnTypeC: 'char *'. self assert: (self isBaseFrame: theFP) not. ^theFP + FoxCallerSavedIP + ((self frameNumArgs: theFP) + 2 * BytesPerWord) but Slang refuses to inline anything that has C declarations. I'm guessing that the issue is moving the type information from the method to its inlined form. It took me half a day to discover where Slang refuses to inline (should have looked in the obvious place CCodeGenerator>>collectInlineList, instead of in the inlining code :/ ). So I'm afraid to waste the time trying to find out where the restriction bites. Anyone know how to fix this or better still have a fix? best Eliot

7 23

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

Jump to page: