Squeak-dev August 2008

squeak-dev@lists.squeakfoundation.org

103 participants
139 discussions

Re: Yes, it works - and fast too! (was [Q] File Upload/Download Server, Comanche or Swazoo)
by Janko Mivšek 02 Aug '08

02 Aug '08

Hi all, Göran's work encouraged me to run benchmarks more carefully and repeatably to minimize impact of OS file system performance and as you can see, Kom and Swazoo are actually close in upload performance, about 5-6MB/s. Big apology to Squeak community for that original 1.5MB/s figure, which obviously came out from only one test, instead of repeatable to avoid other impacts. In new tests I didn't change Swazoo code, I just made an additional upload demo on Aida. Here are results in seconds of repeatable test for two files, 572MB and 102MB ones: 572MB file (600.037.00 bytes) Squeak: Kom/Seaside 92 98 117 (avg 5.9MB/s) Swazoo/Aida 108 111 107 (avg 5.6MB/s) VW: Swazoo/Aida 67 68 66 (avg 9MB/s) 102MB file (106.491.000 bytes) Squeak: Kom/Seaside 18 35 25 32 (avg 3.9MB/s) Swazoo/Aida 16 16 17 16 (avg 6.6MB/s) VW: Swazoo/Aida 5 5 6 5 (avg 20MB/s) As you can see for larger files we are very close while for smaller file Swazoo is still faster. Also you can see that Kom results vary a lot while Swazoo ones are stable. It seems that this is due to bigger amount of garbage generation by Kom (this can also be seen from memory consumption variations) while Swazoo garbage is minimal. In any case we can conclude with quite certainty that on Squeak we reached the upload speed limit near 6MB/sec. To be faster we will need to optimize TCP socket and file VM modules. Tests were done on Damien's squeak-dev 3.9 with both Aida and Seaside installed, with Swazoo 2.2beta and Göran's Kom patch. Done on openSuse 10.0 64bit on 3.2GHz PC, bogomips: 6400. Best regards Janko Göran Krampe wrote: > Ok, I just tested this again using this setup on my Dell D420 (small > Dell laptop, bogomips: 2394 according to /proc/cpuinfo) using: > > - 3.8.1-6747 image > - gokr@yoda:~$ squeakvm -version > 3.9-8 #1 Tue Mar 25 22:39:11 UTC 2008 gcc 4.2.3 > Squeak3.9alpha of 4 July 2005 [latest update: #7021] > Linux vernadsky 2.6.15.7 #1 SMP > - Xubuntu Linux yoda 2.6.24-19-generic #1 SMP > > I tested by loading my changeset into a Gjallar image and then using a > firefox 3 browser on: > http://localhost:8080/seaside/tests/alltests > > ...where there is an upload test. Ok the numbers: > > Local test with a file of size 731654144 took circa 138 seconds to > upload giving approximately 5Mb/sec upload speed. Since Janko mentions > 1.5Mb/sec for Swazoo this seems kinda good. :) > > The image size does not move an inch during this - but the CPU shows 95% > load in top - looking closer at this it seems to be a side effect > because Process browser tells me that the actual Process in Squeak doing > the work is showing about 3% time! It is instead Morphic/idle that goes > up. Squeak is also fully responsive as is the OS during the upload. > > I am sure this is related to other mechanisms in Squeak. And oh, yes, > also tried a file of size 1463308288 (double size) giving eh, slightly > larger upload time (not sure why). > > Did not succeed with a 2Gb+ file, not sure why, haven't investigated > further. Code attached, it downloads files into ./seasidetmp > > regards, Göran -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

2 4

history of ideas: subclass responsibility
by Stefan Sobernig 02 Aug '08

02 Aug '08

Dear Squeakers, (sorry for cross-posting; already posted to comp.lang.smalltalk) For a piece of research I am currently working on, I have been reviewing the arsenal of publications on the genealogy of Smalltalk(s) for some hints on the origin of the Smalltalk-specific "subclass responsibility" approach, i.e. the Smalltalk dialect for "abstract object-classes", roughly speaking. I am particularly interested in references to design decisions. It would be particularly enlightening to know whether the Xerox crew was aware of the "virtual quantity" feature introduced in Simula-67 and their perception (beyond the mere difference with respect to type checking). I do have thoroughly studied "original" Smalltalk-related contributions, far beyond the Blue Book, but could not find explicit references beyond the mere fact that this is the Smalltalk way of doing it; but why? Note that I am well aware of more recent discussions on that very matter, especially in your community on the semantic consistency of subclassResponsibility: http://wiki.squeak.org/squeak/472 I am also aware of other language families that approach the idea of deferred-required implementation by means of a /placebo/ (what I would call it as a strategy). Over at comp.lang.smalltalk, I was given as part of a more thorough answer: > Because we also need a way to respond > for the general case of a message received > that is not understood. So, abstract super-classes are considered a special case deriving from a more general issue. Is anybody aware of some nuggets out there? I would be grateful for any hint + your thoughts when looking at your languages' history ... Best, //stefan

2 1

OLPC: what parts are in Squeak?
by Bèrto ëd Sèra 02 Aug '08

02 Aug '08

Hi all, I remember reading somewhere that OLPC was using Squeak. Does anyone know what parts of it are written in Squeak, exactly? Bèrto

2 1

Another FFI/Installer issue
by Igor Stasenko 02 Aug '08

02 Aug '08

This is what i'm doing in workspace: HTTPSocket httpFileIn: 'installer.pbwiki.com/f/LPF.st'. Installer sm install: 'FFI'. The i trying to open an MC and install other things by hand.. And it is deaf to my clicks.. It seems that when FFI overrides/updates a special object array it is also makes sockets defunct. Restarting image does not helps. Can someone please remind me a 'doit' to recreate special objects array? -- Best regards, Igor Stasenko AKA sig.

2 6

Immutability, what it is, why
by Janko Mivšek 02 Aug '08

02 Aug '08

Dear Squeakers, A bit explanation of immutability will help you understand what it is good for and why it is good to be introduced in Squeak. 1. immutable object = read only object. That means you can read it but not write/change its state. Where is this good for? 2. Literals should be immutable by default. Like 'this is a literal string'. Most of debate so far were about such immutable objects. 3. But the immutability become really powerful for persistence support. That is, as transparent persistence as possible, without any special commands for storing objects into a database. How can this be achieved with immutability? 4. With a clever trick: object to be saved into a database (persistent object) is declared as immutable. When we try to change it, an exception occurs. In exception handler we temporary declare object as read/write, allow the change then declare object back to immutable. We also put that object into a set of changed or so called 'dirty' objects. All we need to do now is to save them to a database during a commit. 5. That's how the Gemstone persistency is implemented completely transparently on VisualWorks, which supports immutability for a while. 6. Consider how transparent can become Magma with immutability in Squeak! 7. Consider many other uses when you need to detect object change. We can for instance implement logging of changes into a file and reverting in case of image crash, just as we are doing now with the code changes. In any case introduction of immutability opens us many new opportunities, which outnumber the small performance penalty it introduces. Best regards Janko -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

3 3

Help: need pangocairo.pc
by K. K. Subramaniam 01 Aug '08

01 Aug '08

Hi, The Etoys vm (3.10-3/squeak) reports the following error on Ubuntu Gutsy when running etoys-dev-3.0 image: >ioFindExternalFunctionIn(primitiveUTF8StringWithIndex, 0x810ccf8): > /usr/local/lib/squeak/3.10-3/RomePlugin: undefined symbol: primitiveUTF8StringWithIndex While compiling vm off olpc trunk on Ubuntu Gutsy, I got an error: >checking for PANGOCAIRO... no >******** disabling RomePlugin I traced the error to a missing pangocairo.pc file in the library libpango1.0-0. Has anyone built the olpc vm on Ubuntu Gutsy or later? What was the pangocairo.pc file used to build the VM? TIA .. Subbu

3 5

RepeatTimesMorphicTile
by Luis Valente 01 Aug '08

01 Aug '08

Hi, I recently found the RepeatTimesMorphicTile in SqueakMap but can´t figure out how to use it in Squeak 3.9. Since it is supposed to have a place in the tile to put a number of times to repeat the script I couldn't discover how to achieve this. Is there any missing trick? Squeak OLPC has a tile to control the times we want to repeat a script, but the same functionality isn't present in Squeak 3.9 etoys. A similar feature will be useful. Any hel welcome. -- All the best, Luis Valente

2 1

Serious bug in 3.10
by askoh 01 Aug '08

01 Aug '08

| block | block := [:i | Transcript cr; show: i]. 1 to: 10 do: [:i | block value: i+1] The above should print ten times. But it only prints the five even numbers. That is a bug isn't it? Aik-Siong Koh -- View this message in context: http://www.nabble.com/Serious-bug-in-3.10-tp18764850p18764850.html Sent from the Squeak - Dev mailing list archive at Nabble.com.

6 8

Conditions for infinite recursion in TTCFont>>ascent
by Jerome Peace 01 Aug '08

01 Aug '08

[squeak-dev] Q: Is it all right for TTCfonts to have non-integer heights? Hi Yoshiki, Thanks for the reply and the clues. :-) Yoshiki Ohshima yoshiki at vpri.org Thu Jul 31 22:45:58 UTC 2008 > > In the Squeak world, it is ok if it works^^; > > I know. But I doesn't quite. > TTCFont>>ascent has a code hole > that leads to infinite recursion under certain conditions. > There are several different versions of TTCFont>>ascent. > AFAIK all the ones currently in use including oplc/3.8 have this property. > Ralph Johnson patched around this in 3.10. > To prevent the certain condition, fallback fonts are limited to strikefonts. > IMO this is unsatisfactory and undesirable. Youshiki:> Could you tell me the certain condition? See Mantis: 0006664: TTCFont>ascent can be infinitely recursive. http://bugs.squeak.org/view.php?id=6664 for all the gory details. For strikefonts ascent is just a variable accessor wherever it is used. This should probably be the case for TTCFonts too. (i.e. ascent should be the straight forward calculation without involving the fall back font. For some reason a caluclation for ascent involves the calculation of the fixed fonts ascent. Which means a calculation of the fixed fonts basefont ascent. If we and the basefont are the same, kaboom, infinite recursion. If ascent were just a calculation and the picking of the maximum height happened elsewhere that would be IMO be the elegant fix. In 3.9 - 3.10 I wrote a test which set up these conditions, then left them there in the image. (Not intentionally, but my friend Puck holds I just wrote a better test than I had imagined. And caught this second bug as well. I'm afraid Puck likes the tests that smoke the image best. :-) On the second pass of testing everything blew up on the poor harvesters. Thus finding the recursion bug. > So if you could give this matter a little more serious thought > and help my quest for understanding with a clue or two? > It would be appreciated. Youshiki:> Sorry if my previous message sounded ignorant. I asked the question non-urgently. Your first response led to the second, which has been helpful. Thank you. Yours in curiosity and service, --Jerome Peace

1 0

Jump to page: