- Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: Adding FasterSets to Pharo: update
by StÃ©phane Ducasse Oct. 31, 2009

Oct. 31, 2009

Thanks. I push the discussion to pharo since lot of people are interested. Stef Begin forwarded message: > From: Ralph Boland <rpboland(a)gmail.com> > Date: October 29, 2009 11:43:04 PM GMT+01:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Cc: Levente Uzonyi <leves(a)elte.hu> > Subject: Adding FasterSets to Pharo: update > > I took a look at FasterSets and Levente Uzonyi's version. > I compared the two versions as of the first release of Levente's > version to Squeak. Note that he has released additional > changes since then. > Here is my report. > > 1) Bugs: > > FasterSets has two problems: > a) KeyedIdentitySet is missing method ScanForNil: > b) PluggableSet is missing method NoCompareOrGrowAddAll: > Both cases should cause failure. Note that I have been using > this code for years without problem. I assume that is because > the subset > of Squeak that I used doesn't include using these classes. > These problems are easily fixed. > > In Levente's code class WeakKeyToCollectionDictionary->rehash > seems to be > missing. This appears to be a mistate to me but I will live it > to Levente to explain > it. The fix, if needed, is simple. > > 2) Code quality: > For me the code quality is about the same but Levente considers > his version to be better. > In any case changes in one version is easily ported to the other > so it would be easy to > perform any cleanup you might want. Three notes in particular. > a) Levente's version of rehash is cleaner and should be used > instead of mine. > b) Levente's version does not use method scanForNilFrom: (He > would probably call > the method scanForEmptySlotFrom:). > I don't know why he didn't do this: it clearly cleaner. > > 3 Performance. > a) According to Levente's stats rehash is clearly faster in > his version than mine. I see > no reason no not prefer his version to mine. > > b) The improvement in performance for method add: in > Levente's version > is insignificant (appx 1%); this difference could easily > be made up in minor > changes to my code. Thus here I consider there to be no > difference. > > b) Levente's version does not apply the FasterSets idea to > MethodDictionary. > I am not sure why he did not do this but it may have > something to do with the fact that > mistakes can easily corrupt your image. The version in > FasterSets works fine though > it took three tries for me to get it right (mostly because > of carelessness). > > c) I left methods intersection and nastyAddNew: out of classes > Set and Dictionary for > the initial version of FasterSets to keep the number of > changes to a minimum. > At your request I added them to the current version. > These methods are not in > Levente's version. They are public methods that provide > performance improvements. > If desired they could easily be added to Levente's version. > > > Based on the above I would say that there is not a great deal of > difference between Levente's version and mine but what difference > there is favors his version. > > I recommend that > > 1) You use Levente's version. > 2) Sort out the issue of no rehash method for Class > WeakKeyToCollectionDictionary. > 3) Modify his code to use method scanForNilFrom: (calling it > scanForEmptySlotFrom:). > 4) Decide if you want to add methods intersect: and > nastyAddNew:. > I can add these if you want. > 5) Release a version of Pharo with these changes. > 6) In the following release of Pharo add the changes to > MethodDictionary to use The > FasterSets Idea. I sugggest doing this separately from > everything else just because it is a > bit hairy. I would not leave this change out because > MethodDictionary is too important > a class not to have these improvements. > > > One final comment. If you really want to make the Set hierarchy > better I would suggest that > you move the Dictionary hierarchy out of the Set hierarchy > altogether. This means some > duplication of code but makes for a much cleaner implementation. For > example you get to > avoid the mess with MethodDictionary. Of the three implementations > of Smalltalk that I > have looked at Squeak/Pharo is the only version that uses one > hierarchy. > This is probably too major a change to make but at least you now know > my opinion on the > matter. > > > You can post this on the Pharo newsgroup if you like but perhaps you > should get Levente's > opinion first. > > Regards > > Ralph Boland

2 1

[Pharo-project] Socket>>socketStream
by Schwab,Wilhelm K Oct. 31, 2009

Oct. 31, 2009

Hello all, What would be involved in adding a socket stream instance variable/accessor to Socket? Is that something you would support? So far, I created a shared dictionary (cleared on true startup) of sockets to streams, so once created, the stream is associated with the corresponding socket, and accessible from same using #socketStream. From there, I have #readStream and #writeStream accessors, which return the one stream - Dolphin separates them, and there is no reason to break the news to my code just yet. Bill

2 6

[Pharo-project] Fwd: Adding FasterSets to Pharo: update
by StÃ©phane Ducasse Oct. 31, 2009

Oct. 31, 2009

Begin forwarded message: > From: Ralph Boland <rpboland(a)gmail.com> > Date: October 30, 2009 6:44:17 AM GMT+01:00 > To: Levente Uzonyi <leves(a)elte.hu> > Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: Adding FasterSets to Pharo: update > > 2009/10/29 Levente Uzonyi <leves(a)elte.hu>: >> Hi! >> >> On Thu, 29 Oct 2009, Ralph Boland wrote: >> >>> In Levente's code class WeakKeyToCollectionDictionary->rehash >>> seems to >>> be >>> missing. This appears to be a mistate to me but I will live it >>> to Levente to explain >>> it. The fix, if needed, is simple. >> >> Only Set and MethodDictionary implements #rehash in the trunk >> version. >> #rehash sends #growTo: which sends #noCheckNoGrowFillFrom: which is >> implemented by WeakKeyToCollectionDictionary. >> > > The version of rehash in WeakKeyToCollectionDictionary is different > from the > other versions. I never bothered to figure out exactly what it does > and just > left it alone. Despite what you say my opinion is still that it is > needed but I will > leave it to those making the final decision to decide. > >>> b) Levente's version does not use method scanForNilFrom: (He >>> would probably call >>> the method scanForEmptySlotFrom:). >>> I don't know why he didn't do this: it clearly cleaner. >> >> It's called #scanForEmptySlotFor:, because WeakSet has a flag for >> empty >> slots, not nil. > > This is not correct. ScanForEmptySlotFor: is analogous to > scanForNil: You did > not implement a method analogous to scanForNilFrom: and obviously > never > used it either. In my opinion the use of scanForNilFrom: makes the > code cleaner > but it is not a major issue if it is not used. >> >>> b) The improvement in performance for method add: in Levente's >>> version >>> is insignificant (appx 1%); this difference could easily >>> be made up in minor >>> changes to my code. Thus here I consider there to be no >>> difference. >> >> Don't let the garbage collector fool you. >> See http://leves.web.elte.hu/collections/DictionaryBenchmarkResults.txt >> . >> The values in the table are microseconds/element without gc time. >> The benchmark code is here >> http://leves.web.elte.hu/collections/DictionaryBenchmark.st >> A similar benchmark's result for Set: >> >> Trunk: >> Size 1000 2000 5000 10000 20000 50000 100000 >> 200000 >> 500000 >> add: (included) 0.5 0.2 0.36 0.46 0.365 0.392 0.394 >> 0.406 0.4112 >> add: (not included) 1.5 1.6 1.38 1.35 1.365 1.25 >> 1.261 1.252 1.5192 >> ... > > I don't know what these stats are about. > I am merely quoting the stats you posted for the first version of > faster sets that you released. They indicated that for class Set > your method rehash was appx 15% faster than the version in > FasterSets and > your method add: was appx 1% faster than the version in FasterSets. > >> >>> b) Levente's version does not apply the FasterSets idea to >>> MethodDictionary. >>> I am not sure why he did not do this but it may have >>> something to do with the fact that >>> mistakes can easily corrupt your image. The version in >>> FasterSets works fine though >>> it took three tries for me to get it right (mostly because >>> of carelessness). >> > > >> It would be easy to modify MethodDictionary, but it has a different >> implementation, so most methods would have to be overridden and the >> performance benefits would be insignificant, because #become: is >> much (~80x) >> slower than the actual rehash for an average sized MethodDictionary. >> Btw, MethodDictionaries are rarely grown. > > >> >>> c) I left methods intersection and nastyAddNew: out of classes >>> Set and Dictionary for >>> the initial version of FasterSets to keep the number of >>> changes to a minimum. >>> At your request I added them to the current version. >>> These methods are not in >>> Levente's version. They are public methods that provide >>> performance improvements. >>> If desired they could easily be added to Levente's >>> version. >> >> #nastyAddNew: is not really useful IMO, if you want to be nasty, >> you can use >> "private" methods: >> aSet atNewIndex: (set scanForNil: anObject) put: anObject. >> It's even faster and if you do this, you probably know what you're >> doing. >> > > I don't know whether nastyAddNew: should be added to Pharo/Squeak > or not. > I'll leave that for others to decide. However, I consider > nastyAddNew: to be > preferable to what you propose. > >> I'm not really interrested in #intersecion:, but I found it >> controversal. >> What's the intersecion of a Set and an IdentitySet? Do you check >> identity or >> equality? >> > > The current code currently supports intersection of sets/dictionaries > but it is slower than > the version in FasterSets because the FasterSets version avoids > unnecessary compares. > If you believe that intersection for sets in the current code is > controversial and should be > changed or removed fine. FasterSets is not entering this debate; it > is merely providing > faster versions of intersection than what is already in the code. > >>> I recommend that >>> >>> 1) You use Levente's version. >> >> Feel free to grab it. >> >>> 2) Sort out the issue of no rehash method for Class >>> WeakKeyToCollectionDictionary. >> >> See above. >> >>> 3) Modify his code to use method scanForNilFrom: (calling it >>> scanForEmptySlotFrom:). >> >> See above. >> >>> 4) Decide if you want to add methods intersect: and >>> nastyAddNew:. >>> I can add these if you want. >> >> See my opinion above. >> >>> 5) Release a version of Pharo with these changes. >>> 6) In the following release of Pharo add the changes to >>> MethodDictionary to use The >>> FasterSets Idea. I sugggest doing this separately from >>> everything else just because it is a >>> bit hairy. I would not leave this change out because >>> MethodDictionary is too important >>> a class not to have these improvements. >>> >> >> See above. >> >>> You can post this on the Pharo newsgroup if you like but perhaps you >>> should get Levente's >>> opinion first. >> >> Go ahead, I'm already subscribed to the pharo list because I >> couldn't stop >> myself to respond to a false statement. >> >> Cheers, >> Levente >> > > Regards, > > Ralph Boland

1 0

[Pharo-project] Fwd: Adding FasterSets to Pharo: update
by StÃ©phane Ducasse Oct. 31, 2009

Oct. 31, 2009

Begin forwarded message: > From: Levente Uzonyi <leves(a)elte.hu> > Date: October 30, 2009 3:29:33 AM GMT+01:00 > To: Ralph Boland <rpboland(a)gmail.com> > Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: Adding FasterSets to Pharo: update > > Hi! > > On Thu, 29 Oct 2009, Ralph Boland wrote: > >> In Levente's code class WeakKeyToCollectionDictionary->rehash >> seems to be >> missing. This appears to be a mistate to me but I will live it >> to Levente to explain >> it. The fix, if needed, is simple. > > Only Set and MethodDictionary implements #rehash in the trunk > version. #rehash sends #growTo: which sends #noCheckNoGrowFillFrom: > which is implemented by WeakKeyToCollectionDictionary. > >> b) Levente's version does not use method scanForNilFrom: (He >> would probably call >> the method scanForEmptySlotFrom:). >> I don't know why he didn't do this: it clearly cleaner. > > It's called #scanForEmptySlotFor:, because WeakSet has a flag for > empty slots, not nil. > >> b) The improvement in performance for method add: in >> Levente's version >> is insignificant (appx 1%); this difference could easily >> be made up in minor >> changes to my code. Thus here I consider there to be no >> difference. > > Don't let the garbage collector fool you. > See http://leves.web.elte.hu/collections/DictionaryBenchmarkResults.txt > . The values in the table are microseconds/element without gc time. > The benchmark code is here http://leves.web.elte.hu/collections/DictionaryBenchmark.st > A similar benchmark's result for Set: > > Trunk: > Size 1000 2000 5000 10000 20000 50000 100000 200000 500000 > add: (included) 0.5 0.2 0.36 0.46 0.365 0.392 0.394 0.406 0.4112 > add: (not included) 1.5 1.6 1.38 1.35 1.365 1.25 1.261 1.252 1.5192 > includes: (included) 0.3 0.5 0.42 0.41 0.395 0.432 0.457 0.4695 0.4442 > includes: (not included) 0.2 0.5 0.56 0.51 0.51 0.632 0.66 0.6525 > 0.5994 > like: (included) 0.5 0.4 0.4 0.36 0.345 0.37 0.393 0.4105 0.3854 > like: (not included) 0.4 0.45 0.52 0.44 0.445 0.566 0.593 0.5895 0.536 > rehash 0.5 0.4 0.32 0.33 0.33 0.338 0.342 0.326 0.3386 > remove:ifAbsent: (included) 0.7 0.95 1.02 0.99 1.015 1.228 1.238 > 1.2485 0.9282 > remove:ifAbsent: (not included) 0.4 0.5 0.58 0.54 0.575 0.686 0.699 > 0.6985 0.6586 > > Pharo: > Size 1000 2000 5000 10000 20000 50000 100000 200000 500000 > add: (included) 0.4 0.45 0.5 0.45 0.44 0.462 0.465 0.4705 0.499 > add: (not included) 2.0 2.0 1.72 1.67 1.715 1.57 1.582 1.57 2.0874 > includes: (included) 0.5 0.5 0.56 0.6 0.52 0.52 0.547 0.5335 0.5814 > includes: (not included) 0.7 0.85 0.8 1.03 0.865 0.804 0.804 0.8265 > 0.8734 > like: (included) 0.7 0.45 0.4 0.5 0.395 0.382 0.399 0.3935 0.4208 > like: (not included) 0.3 0.65 0.66 0.9 0.705 0.66 0.659 0.679 0.783 > rehash 0.9 0.6 0.64 0.69 0.63 0.604 0.615 0.6285 0.6964 > remove:ifAbsent: (included) 2.0 1.95 2.16 6.59 2.165 2.052 1.981 > 2.092 2.0544 > remove:ifAbsent: (not included) 0.9 0.85 0.92 1.05 0.9 0.84 0.878 > 0.869 1.0232 > > Pharo with Andres's hacks: > Size 1000 2000 5000 10000 20000 50000 100000 200000 500000 > add: (included) 0.5 0.5 0.46 0.49 0.475 0.466 0.458 0.4935 0.5306 > add: (not included) 1.7 2.35 2.26 2.02 2.15 2.12 2.298 2.021 2.0332 > includes: (included) 0.6 0.5 0.56 0.53 0.62 0.528 0.539 0.533 0.588 > includes: (not included) 0.8 0.8 0.74 0.77 0.745 0.7 0.694 0.706 > 0.7814 > like: (included) 0.1 0.2 0.36 0.4 0.485 0.386 0.39 0.382 0.4312 > like: (not included) 0.4 0.8 0.6 0.66 0.605 0.576 0.566 0.5835 0.6554 > rehash 0.6 0.55 0.62 0.58 0.575 0.586 0.599 0.5825 0.6044 > remove:ifAbsent: (included) 1.5 1.95 1.86 1.97 1.905 1.786 1.763 > 1.8005 1.9346 > remove:ifAbsent: (not included) 0.7 0.75 0.82 0.82 0.84 0.774 0.771 > 0.7755 0.8418 > > If you're interrested in the benchmark code, let me know. > >> b) Levente's version does not apply the FasterSets idea to >> MethodDictionary. >> I am not sure why he did not do this but it may have >> something to do with the fact that >> mistakes can easily corrupt your image. The version in >> FasterSets works fine though >> it took three tries for me to get it right (mostly because >> of carelessness). > > It would be easy to modify MethodDictionary, but it has a different > implementation, so most methods would have to be overridden and the > performance benefits would be insignificant, because #become: is > much (~80x) slower than the actual rehash for an average sized > MethodDictionary. > Btw, MethodDictionaries are rarely grown. > >> c) I left methods intersection and nastyAddNew: out of classes >> Set and Dictionary for >> the initial version of FasterSets to keep the number of >> changes to a minimum. >> At your request I added them to the current version. >> These methods are not in >> Levente's version. They are public methods that provide >> performance improvements. >> If desired they could easily be added to Levente's version. > > #nastyAddNew: is not really useful IMO, if you want to be nasty, you > can use "private" methods: > aSet atNewIndex: (set scanForNil: anObject) put: anObject. > It's even faster and if you do this, you probably know what you're > doing. > > I'm not really interrested in #intersecion:, but I found it > controversal. What's the intersecion of a Set and an IdentitySet? Do > you check identity or equality? > >> I recommend that >> >> 1) You use Levente's version. > > Feel free to grab it. > >> 2) Sort out the issue of no rehash method for Class >> WeakKeyToCollectionDictionary. > > See above. > >> 3) Modify his code to use method scanForNilFrom: (calling it >> scanForEmptySlotFrom:). > > See above. > >> 4) Decide if you want to add methods intersect: and >> nastyAddNew:. >> I can add these if you want. > > See my opinion above. > >> 5) Release a version of Pharo with these changes. >> 6) In the following release of Pharo add the changes to >> MethodDictionary to use The >> FasterSets Idea. I sugggest doing this separately from >> everything else just because it is a >> bit hairy. I would not leave this change out because >> MethodDictionary is too important >> a class not to have these improvements. >> > > See above. > >> You can post this on the Pharo newsgroup if you like but perhaps you >> should get Levente's >> opinion first. > > Go ahead, I'm already subscribed to the pharo list because I > couldn't stop myself to respond to a false statement. > > Cheers, > Levente

1 0

[Pharo-project] Hashed collection changes, the performance graphs
by Martin McClure Oct. 31, 2009

Oct. 31, 2009

Gotta go see my wife in a play now; will comment on these graphs later. -Martin

4 10

[Pharo-project] About FixedIdentitySet
by Nicolas Cellier Oct. 31, 2009

Oct. 31, 2009

I just noticed this: (FixedIdentitySet withAll: #(a b c)) = #(a a a). I presume that does not matter... FixedIdentitySet also make usage of identityHash - with a basicSize power of two - using bitAnd: rather than modulo (because of the size being power of two, that should be equivalent) I guess it works because used with small size only... Beware not using scaledIdentityHash then ! Shouldn't the read-only version really use an Array, up to a given size greater than 0 or 1 ?

2 1

[Pharo-project] displayWorldAsTwoTone
by Niko Schwarz Oct. 30, 2009

Oct. 30, 2009

Hi list, sending displayWorldAsTwoTone to the global PasteUpMorph does not turn my screen black and white. That is because WorldState does not respond to #displayWorldAsTwoTone, as PasteUpMorph>displayWorldAsTwoTone expects. Cheers, Niko

1 0

Re: [Pharo-project] Segmentation fault when starting pharo 1.0rc1 on Ubuntu 64bit server
by Paul DeBruicker Oct. 30, 2009

Oct. 30, 2009

Hi Hernan, Thanks for the recommendations. Here is the output of the core dump from gdb's bt command. paul@localhost:~$ cd ph paul@localhost:~/ph$ gdb squeak core GNU gdb (GDB) 7.0-ubuntu Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/paul/ph/squeak...done. warning: Can't read pathname for load map: Input/output error. Reading symbols from /lib32/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib32/libutil.so.1 Reading symbols from /lib32/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib32/libdl.so.2 Reading symbols from /lib32/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib32/libm.so.6 Reading symbols from /lib32/libnsl.so.1...(no debugging symbols found)...done. Loaded symbols for /lib32/libnsl.so.1 Reading symbols from /lib32/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib32/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Core was generated by `./squeak deploy.image'. Program terminated with signal 11, Segmentation fault. #0 0xf7f4642f in __kernel_vsyscall () (gdb) bt #0 0xf7f4642f in __kernel_vsyscall () #1 0xf7ee8ff4 in ?? () from /lib32/libc.so.6 #2 0xf7e6f6e7 in sbrk () from /lib32/libc.so.6 #3 0xf7e1ada1 in __default_morecore () from /lib32/libc.so.6 #4 0xf7e17c1d in ?? () from /lib32/libc.so.6 #5 0xf7e19568 in malloc () from /lib32/libc.so.6 #6 0xf7e18f80 in calloc () from /lib32/libc.so.6 #7 0x08051f9d in main (argc=1310076, argv=0xf7f2a540, envp=0xf7f5aa10) at /home/bryce/squeak/exupery/platforms/unix/vm/sqUnixMain.c:1324 I don't know what to check next. Thanks for any help you can provide. Paul > Date: Thu, 29 Oct 2009 19:40:09 -0300 > From: Hern?n Morales Durand <hernan.morales(a)gmail.com> > Subject: Re: [Pharo-project] Segmentation fault when starting pharo > 1.0rc1 on Ubuntu 64bit server > To: Pharo-project(a)lists.gforge.inria.fr > Message-ID: > <70da5dd20910291540t17f92212he42d92b4d1d05666(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Paul, > You may verify if your Linux distribution has core dumping enabled: > > # ulimit -c unlimited > > and check if the directory where the VM resides is writeable. Once you run > again the VM and see "Segmentation fault (core dumped)", You may search the > dumped core with "file core" and run a gdb on it: > > $ gdb squeakvm core > > Inside gdb, the bt command will display a stack trace to see or mail out > detailed information about your SIGSEGV. > Cheers, > > Hern?n > > 2009/10/29 Paul DeBruicker <pdebruic(a)gmail.com> > >> Hi - >> >> Has anyone successfully run a newer version of Pharo on either Ubuntu >> 9.04 or Ubuntu 9.10 64 bit server? When I try to start the command >> line simply says "Segmentation fault" and does not emit a stack >> trace. The UUIDPlugin is named UUIDPlugin.bak. I am attempting to >> use the latest versions of pharo, pharo sources and both the pharo vm >> or squeak 3.11 vm from the pharo-project.org site. I have installed >> ia32-libs and I do know that the latest pharo runs on Ubuntu Desktop >> 9.04. >> >> If you have gotten it running, will you please send me the output of >> >> dkpg -l >> >> or a description of whatever you did to get it started? Thanks >> >> >> Also, I'd be happy to attempt other solutions or provide more >> information as I've tried what I know how to do and checked what I >> know to check. >> >> Thanks >> >> Paul >> >> _______________________________________________

1 0

Re: [Pharo-project] Segmentation fault when starting pharo 1.0rc1 on Ubuntu 64bit server
by Paul DeBruicker Oct. 30, 2009

Oct. 30, 2009

Date: Thu, 29 Oct 2009 22:58:00 +0100 > From: Alain Plantec <alain.plantec(a)free.fr> > Subject: Re: [Pharo-project] Segmentation fault when starting pharo > Â Â Â Â 1.0rc1 on Â Â Â Ubuntu 64bit server > To: Pharo-project(a)lists.gforge.inria.fr > Message-ID: <4AEA0FE8.7000603(a)free.fr> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Paul, > > I'm using ubuntu 9.10 rc 64 (desktop version) since 7 days without any > problem. > Pharo run out of the box. > I send my dpkg -l result to you in private. > > Cheers > Alain > Hi Alain- Yes I also have it working on the Desktop version of Ubuntu 9.10 & 9.04. I'm having trouble with the server version. Thanks Paul

1 0

[Pharo-project] Is serving files different in Pharo?
by Torsten Bergmann Oct. 30, 2009

Oct. 30, 2009

Mart-Mari Breedt wrote on Pharo list [1] > >I got the answer to my problem here: http://bugs.squeak.org/view.php?id=7397 > Why isnt the fix included into KomServer by default or the implementation in pharo changed by default? Pharo has: mimeType ^MIMEDocument guessTypeFromName: self name. The fix is mimeType ^MIMEDocument guessTypeFromName: self asUrl Should we or seaside dev care? Bye T. [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2009-October/015314.ht… -- Neu: GMX DSL bis 50.000 kBit/s und 200,- Euro Startguthaben! http://portal.gmx.net/de/go/dsl02

2 1