March 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] squeakToUTF-8 and related?

by Philippe Marschall

Nicolas Cellier wrote: > 2010/3/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> You should ask Sophie team, their knowledge certainly is far more >>> advanced than mine. >> The problem is that most of them disappeared after the java rewrite announce. >> >>> String should be a SequenceableCollection of Character. >>> Internally, for space/speed reasons they rather store a code >>> representing the value of a Character. >>> >>> In a simple model, this value would be the Unicode encoding... >>> In squeak, only lowest 22 bits of a Character value are used to encode >>> the character (#charCode). >>> Bits of rank 23 to 30 encode a so called #leadingChar. >>> I guess we stopped at bit #30 just to be sure to handle SmallInteger values. >>> Don't count on me to explain leadingChar, I can't... >> :) >> I read the comment of the class and some code and got lost >> >>> For leadingChar ~~ 0, i'm not event sure of correct charCode interpretation... >>> >>> For value < 256, the interpretation of the charCode is not exactly unicode... >>> It's more CP1252 (with assigned values to codes from 128 to 159). >>> >>> Once upon a time, it used to be Mac Roman encoding instead... >>> Let's forget the past (but you could so some remnants in old code). >>> >>> ------------------------------ >>> >>> When marshalling/unmarshalling strings to/from outside world we >>> could/should use ByteArray... >>> Unwisely, we don't. >>> Instead, we reuse a String as storage for these codes. >>> As a result, you see all these squeakToUtf8, utf8ToSqueak etc... >>> That means that the contents of the String cannot be interpreted >>> outside of its context... Very very bad IMHO. >>> Under this point of view, the String has no more a self-contained >>> meaning, but is just a blob of codes (on 8 or 32 bits). >>> Fortunately, we mostly use these forms for temporary storage, but >>> even, I don't like it. >>> >>> There are other alternatives like defining subclasses of String that >>> encapsulate their encodings and know how to be well behaved Strings, >>> not just context dependent blobs. >>> For example, you could as well define an UT8String. >>> VW went on this kind of path long time ago (not sure for utf8 though). >>> >>> Well, I'm not sure whether I succeeded in explaining something at all >>> or just added confusion... >> don;t worry. >> for the seaside book I started to read unicode standard and history now it would be good to >> know what to do and do it :) >> > > Ask Seaside folks, they certainly have some ideas. I don't like the #squeakToXXX methods because for every encoding you support you need to add a method. That's why I prefer the #convertToEncoding: method, one method for every use case. I like even less the #xxxToSquak methods, the #convertFromEnoding: method does the same. In addition you have the fact that you're dealing with strings not in the native Squeak format. If you pass them anywhere you're unlikely to get the expected result. I prefer ByteArrays for this use case which have no semantic and make it clear that it's not a native string. Cheers Philippe

March 30, 2010

Re: [Pharo-project] Squeak VM+FT2Plugin, all Pharo 1.0 rc3 tests green

by Adrian Lienhard

Hi Laurent, Here a problem report concerning your VM (http://lolgzs.free.fr/pharo/squeak-vm/Squeak-3.11.3.2135-pharo-bin.tar.gz) from a Ubuntu 64bit user. His machine: (k)ubuntu karmic x64 Linux toat 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 04:38:19 UTC 2010 x86_64 GNU/Linux Pulseaudio: 1:0.9.19-0ubuntu4.1 Intel(R) Core(TM) i7 CPU, 950 @ 3.07GHz The first problem he had was that the VM segfaulted. He then disabled psdsp in the startup script. This fixed the crash and sound worked (Beeper beep). His tinyBenchmark results are: 582811610 bytecodes/sec; 15102233 sends/sec 562946673 bytecodes/sec; 16346261 sends/sec 583475783 bytecodes/sec; 16404381 sends/sec 589522164 bytecodes/sec; 16288551 sends/sec 570791527 bytecodes/sec; 16389812 sends/sec 527835051 bytecodes/sec; 14646769 sends/sec 590201729 bytecodes/sec; 16288551 sends/sec 586483390 bytecodes/sec; 16231248 sends/sec 590542099 bytecodes/sec; 16259849 sends/sec 542085759 bytecodes/sec; 14763943 sends/sec ...compared to a 3.9-8 #1 Tue Jan 13 16:33:40 UTC 2009 gcc 4.3.3 VM: 580828133 bytecodes/sec; 18995358 sends/sec 539515279 bytecodes/sec; 17677135 sends/sec 552617377 bytecodes/sec; 17865371 sends/sec 588167719 bytecodes/sec; 19129213 sends/sec 579185520 bytecodes/sec; 18947146 sends/sec 585812356 bytecodes/sec; 16785105 sends/sec 545551411 bytecodes/sec; 18164300 sends/sec 577226606 bytecodes/sec; 19227754 sends/sec 587155963 bytecodes/sec; 19080321 sends/sec 580498866 bytecodes/sec; 18815817 sends/sec The new VM is slower on sends/sec, but the really astonishing difference is not in the benchmarks but in the GUI performance. It is really slow. Just moving the mouse around on an empty world makes CPU consumption go up to over 70%! He didn't experience this problem with the old 3.9-8 VM. Cheers, Adrian On Mar 26, 2010, at 22:11 , laurent laffont wrote: > Hi, > > Finally I've managed to build squeak vm rev. 2135 (current stable) with > FT2Plugin which makes all tests green on Pharo 1.0 rc3 image........ on my > machine :) > > If some Linux users can test it on their distro, thanks. > > The clean binary archive: > http://lolgzs.free.fr/pharo/squeak-vm/Squeak-3.11.3.2135-pharo-bin.tar.gz > > The generated source archive: > http://lolgzs.free.fr/pharo/squeak-vm/Squeak-3.11.3.2135-pharo-src.tar.gz > > PharoCore-1.0 + configured VMMaker 1.2 image (for new vm builders, to have > a known working base): > http://lolgzs.free.fr/pharo/squeak-vm/PharoCore-1.0-VMMaker-1.2.tar.gz > > > To build from source archive: > ======================= > wget > http://lolgzs.free.fr/pharo/squeak-vm/Squeak-3.11.3.2135-pharo-src.tar.gz > tar -xvzf Squeak-3.11.3.2135-pharo-src.tar.gz > cd Squeak-3.11.3.2135-pharo-src/ > mkdir build && cd build > ../unix/cmake/configure > make > sudo make install > > > Internal plugins: > ====================== > UUIDPlugin > > External plugins: > ====================== > ADPCMCodecPlugin > AioPlugin > AsynchFilePlugin > B2DPlugin > B3DAcceleratorPlugin > BMPReadWriterPlugin > BitBltPlugin > CroquetPlugin > DSAPrims > DropPlugin > FFTPlugin > FT2Plugin > FileCopyPlugin > FilePlugin > FloatArrayPlugin > FloatMathPlugin > GeniePlugin > HostWindowPlugin > JPEGReadWriter2Plugin > JPEGReaderPlugin > JoystickTabletPlugin > Klatt > LargeIntegers > LocalePlugin > MIDIPlugin > Matrix2x3Plugin > MiscPrimitivePlugin > Mpeg3Plugin > QuicktimePlugin > RePlugin > SecurityPlugin > SerialPlugin > SocketPlugin > SoundCodecPrims > SoundGenerationPlugin > SoundPlugin > Squeak3D > SqueakFFIPrims > StarSqueakPlugin > SurfacePlugin > UnixOSProcessPlugin > XDisplayControlPlugin > ZipPlugin > > > Fun story: if you don't have SecurityPlugin, LocaleTest>>testFontFullName > deletes your image :) > testFontFullName > "self debug: #testFontFullName" > | env dir | > env := (Locale isoLanguage: 'ja') languageEnvironment. > dir := FileDirectory on: SecurityManager default untrustedUserDirectory. > [dir recursiveDelete] <-------------- Cool !! > on: Error > do: [:e | e]. > env fontFullName. > self assert: dir exists > > > Cheers, > > Laurent Laffont > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 30, 2010

Re: [Pharo-project] TeaTime (Re: nebraska?)

by StÃ©phane Ducasse

On Mar 30, 2010, at 12:17 PM, Fernando olivero wrote: > Tea Time is a great implementation of how to synch two replicas of the same world of objects. > > Replication of Computation vs Replication of Data! > > Islands encapsulate a world of objects, that whenever send each other messages make the controller/router for that island to forward to all other replicated islands, the sent message (hence, computation vs data ( croquet vs Second Life ). > > > And every island has a controller and a router with a message queue. > > Two replicas are consistent, because the same messages are "sent" in every replica. what about if the messages arrives in different order ? > > Every object ( TObject) tells its island that is has received a message. > > > Fernando > > pd: I know a bit, because i've used Croquet for my master thesis. > > > On Mar 30, 2010, at 10:44 AM, StÃ©phane Ducasse wrote: > >> Good I like simple things. I'm really curious to learn it. >> So in a nutshell what is the idea of the synchronisation? >> How do do know which objects changed in an image? >> >> Stef >> >> On Mar 30, 2010, at 10:22 AM, Andreas Raab wrote: >> >>> On 3/20/2010 4:43 PM, Michael Rueger wrote: >>>> On 3/20/10 4:35 PM, Marcus Denker wrote: >>>>>> So why does everyone ignore TeaTime? I admit I don't understand the >>>>>> internals, but it obviously *looks* like it could be the basis of >>>>>> Nebraska (or any other P2P solution). >>>>>> >>>>> Can you point me to a real good publication about it? I mean, a >>>>> *real* one? >>>> >>>> AFAIK TeaTime never happened but they (Croquet/Cobalt) switched to some >>>> multiplayer game like sync scheme (at least the poor me understood when >>>> I saw the implementation ;-) ). >>> >>> Actually we didn't. TeaTime (as conceived by David Reed) consisted of two separate ideas, namely that of a world synchronization protocol and that of a P2P network protocol. When David Smith and I implemented the version we shipped in Hedgehog we dropped the P2P network protocol part and only concentrated on the synchronization aspect which resulted in *major* simplifications. >>> >>> That turned out to be a real win because the original design required N^2 connections for N participants with the obvious resulting problems if you get to larger numbers of users (today we can run sessions in Teleplace with 250+ active participants). David and I originally replaced the P2P communication with a single central entity (the router) but today this is actually a router overlay network that gives us theoretical scalability to 10,000s of users in the same space (unfortunately the client currently cannot cope with the rendering of all the stuff today at scales > 250). >>> >>> Anyway. The important part is that due to the practical connectivity restrictions for most users (bandwidth, latency, firewalls) running purely P2P is really stupid. You need a fixed point outside the firewall that you connect to via TCP through proxy and whatever BS the local environment requires and from that fixed point it goes into the overlay network. This has many additional advantages that I won't elaborate on here. >>> >>> As for publications, I don't know what amounts for a "real" publication in your eyes Marcus but considering that neither David nor myself are measured by number or quality of our publications you'll have to do with the publications listed at http://opencroquet.org/index.php/Overview I would in particular recommend the Hedgehog architecture presentation at http://opencroquet.org/images/e/ee/2005_Hedgehog_Architecture.pdf which is from the talk David and I gave at the OOPSLA workshop. As you look at the presentation read the documentation at http://opencroquet.org/index.php/Croquet_SDK which talks about the stuff in the slides. >>> >>> Coincidentally, I am toying regularly with the idea of using an even more simplified version of TeaTime to do something like Nebraska. Might get around to it one of these days, it's actually straightforward. >>> >>> BTW, it's a misconception to think TeaTime is something complicated. Complicated things don't work. Simple things do. TeaTime is actually VERY simple. That's why it works. >>> >>> Cheers, >>> - Andreas >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 30, 2010

Re: [Pharo-project] TeaTime (Re: nebraska?)

by Lawson English

Intel engineer now speaking on "Designing Extensible and Scalable Virtual World Platforms" http://slurl.com/secondlife/IBM%20Business%20Center2/65/1/27 Part of virtual worlds workshop in Arkansas. http://vw.ddns.uark.edu/X10/X10--Schedule.html Lawson

March 30, 2010

[Pharo-project] The Windows VM

by Torsten Bergmann

>No, I don't think so. I don't know who did it I did it and will redo a new one based on the new 4.0 hopefully this week to create a new installer. Is the new 1.0 dev-image already in place? However - the changes from Andreas should only affect Squeak and there should also be no problem in still using the 3.11.8. VM Bye T. -- GMX DSL: Internet, Telefon und Entertainment fÃ¼r nur 19,99 EUR/mtl.! http://portal.gmx.net/de/go/dsl02

March 30, 2010

Re: [Pharo-project] TeaTime (Re: nebraska?)

by Fernando olivero

Tea Time is a great implementation of how to synch two replicas of the same world of objects. Replication of Computation vs Replication of Data! Islands encapsulate a world of objects, that whenever send each other messages make the controller/router for that island to forward to all other replicated islands, the sent message (hence, computation vs data ( croquet vs Second Life ). And every island has a controller and a router with a message queue. Two replicas are consistent, because the same messages are "sent" in every replica. Every object ( TObject) tells its island that is has received a message. Fernando pd: I know a bit, because i've used Croquet for my master thesis. On Mar 30, 2010, at 10:44 AM, StÃ©phane Ducasse wrote: > Good I like simple things. I'm really curious to learn it. > So in a nutshell what is the idea of the synchronisation? > How do do know which objects changed in an image? > > Stef > > On Mar 30, 2010, at 10:22 AM, Andreas Raab wrote: > >> On 3/20/2010 4:43 PM, Michael Rueger wrote: >>> On 3/20/10 4:35 PM, Marcus Denker wrote: >>>>> So why does everyone ignore TeaTime? I admit I don't understand the >>>>> internals, but it obviously *looks* like it could be the basis of >>>>> Nebraska (or any other P2P solution). >>>>> >>>> Can you point me to a real good publication about it? I mean, a >>>> *real* one? >>> >>> AFAIK TeaTime never happened but they (Croquet/Cobalt) switched to some >>> multiplayer game like sync scheme (at least the poor me understood when >>> I saw the implementation ;-) ). >> >> Actually we didn't. TeaTime (as conceived by David Reed) consisted of two separate ideas, namely that of a world synchronization protocol and that of a P2P network protocol. When David Smith and I implemented the version we shipped in Hedgehog we dropped the P2P network protocol part and only concentrated on the synchronization aspect which resulted in *major* simplifications. >> >> That turned out to be a real win because the original design required N^2 connections for N participants with the obvious resulting problems if you get to larger numbers of users (today we can run sessions in Teleplace with 250+ active participants). David and I originally replaced the P2P communication with a single central entity (the router) but today this is actually a router overlay network that gives us theoretical scalability to 10,000s of users in the same space (unfortunately the client currently cannot cope with the rendering of all the stuff today at scales > 250). >> >> Anyway. The important part is that due to the practical connectivity restrictions for most users (bandwidth, latency, firewalls) running purely P2P is really stupid. You need a fixed point outside the firewall that you connect to via TCP through proxy and whatever BS the local environment requires and from that fixed point it goes into the overlay network. This has many additional advantages that I won't elaborate on here. >> >> As for publications, I don't know what amounts for a "real" publication in your eyes Marcus but considering that neither David nor myself are measured by number or quality of our publications you'll have to do with the publications listed at http://opencroquet.org/index.php/Overview I would in particular recommend the Hedgehog architecture presentation at http://opencroquet.org/images/e/ee/2005_Hedgehog_Architecture.pdf which is from the talk David and I gave at the OOPSLA workshop. As you look at the presentation read the documentation at http://opencroquet.org/index.php/Croquet_SDK which talks about the stuff in the slides. >> >> Coincidentally, I am toying regularly with the idea of using an even more simplified version of TeaTime to do something like Nebraska. Might get around to it one of these days, it's actually straightforward. >> >> BTW, it's a misconception to think TeaTime is something complicated. Complicated things don't work. Simple things do. TeaTime is actually VERY simple. That's why it works. >> >> Cheers, >> - Andreas >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 30, 2010

Re: [Pharo-project] squeakToUTF-8 and related?

by Norbert Hartl

On 30.03.2010, at 11:00, Nicolas Cellier wrote: > 2010/3/30 Norbert Hartl <norbert(a)hartl.name>: >> >> On 29.03.2010, at 11:52, Nicolas Cellier wrote: >> >> 2010/3/29 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >> >> On Mar 29, 2010, at 11:16 30AM, Nicolas Cellier wrote: >> >> I presume that under the idiom "latin1" you refer to code page 1252 >> >> rather than iso8859-L1, right ? >> >> Nicolas >> >> Good question :) >> >> What IS the presumed internal encoding of Bytestrings in Squeak? >> >> That's the one I meant, I merely assumed it was latin1 seeing as how the >> text converter refers to it as such. >> >> Personally I thought it was iso8859-L1, seeing as the bytestring to unicode >> conversion does a simple shift of chars > 127 to the 0080 - 00FF range. >> >> Cheers, >> >> Henry >> >> >> From what I understood, CP1252 is Microsoft "latin1" and use codes 128 to >> 159. >> ISO8859-L1 match fisrt 256 codes of unicode latin-1 and has codes 128 >> to 159 unused. >> You know, when Microsoft "uses" a standard, it's always a better standard ;) >> >> I have nothing against CP1252, it's an optimization which avoid >> wasting 32 cheap codes. >> But I'm not sure about various compatibility issues in/with the >> external world... >> >> If you know how to easily assure that >> (String with: (Character value: (Integer readFrom: '20AC' base: 16))) >> = (String with: (Character value: (Integer readFrom: '80' base: 16))) >> than you might be safe. By using Windows-1252 code points aren't unique >> anymore. Every code point in the range 0x80 - 0x9F exists somewhere else, >> too. So my estimation would be that it will cause more trouble than it might >> solve. >> > > Agree. > I see two different problems here: > 1) absence of explicit encoding information in external data > 2) existence of a canonical representation which can be easily compared... > > Generalization of UTF8 should solve 1 (slowly with lot of inertia), > then we can simply assume implicit=UTF8. > Unicode could solve 2... > ...Well, as long as diacriticals are ignored. > To me Unicode still has problems with: > (String with: 16r61 asCharacter with: 16r0302 asCharacter) = (String > with: 16rE2 asCharacter) > Oh well, I forgot about this. There are less chances to get this right without changing a lot of stuff. In my opinion Character has to go the way of the SmallInteger. If the world will be unicode centric than a character needs to be a sequence of code points. A character that has only one code point will be the special case that needs to be optimized, that will resemble what Character how it is now. Having those sequences you will still need to have a table that states the equality of the code point sequence and the 8bit equivalent of e.g. Ã¢. But this is due to the western centric specification of unicode. And we have to live with that. Another 2 cents, Norbert > Nicolas > >> Squeak clearly uses CP1252. >> For Pharo, there might be a mix of the two since Sophie-like >> refactorings. Surely what John was refering to. >> >> In pharo the 20AC string gives me a euro sign but the 80 hex one prints a >> rectangle which is _a_ interpretation of '?' ;) >> Norbert >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 30, 2010

Re: [Pharo-project] [squeak-dev] IWST 2010 Call for Papers

by Mariano Martinez Peck

One of the reasons I created smalltalk-research(a)googlegroups.com was exactly not having to do this ;) On Tue, Mar 30, 2010 at 5:29 AM, Michael Haupt <mhaupt(a)gmail.com> wrote: > * Apologies for multiple copies. * > > Call for Papers > > International Workshop on Smalltalk Technologies (IWST) 2010 > > co-located with European Smalltalk User Group Conference (ESUG) > Barcelona, Spain, September 11-17, 2010 > > > ** Description > > The goal of the IWST workshop series is to create and foster a forum > around advances or experience in Smalltalk. We welcome contributions > on all aspects, theoretical as well as practical, of Smalltalk-related > topics. > > There are two possible kinds of submissions, which must be in ACM SIGPLAN > style: > > * Research papers (up to 10 pages). Submissions in this category will > be rigorously reviewed, and accepted papers will be published in the > ACM Digital Library (ACM SIGPLAN has approved, the final ACM approval > is pending). > > * Demonstration papers (up to 4 pages). Submissions in this category > will not be published in the ACM Digital Library, but will be > available for download from the workshop web page. > > > ** Submission and Reviewing Process > > The EasyChair submission web site is at > http://www.easychair.org/conferences/?conf=iwst10. > > Authors will be given the opportunity to comment on reviewers' work by > providing feedback on the reviews. For this purpose, a questionnaire > will be sent to authors. Their answers will be evaluated anonymously, > and feedback will be handed on to reviewers. > > > ** Important Dates > > Submission: May 14, 2010 (Samoa time) > Feedback: June 28, 2010 > ESUG Early Registration Deadline: July 9, 2010 > Workshop: September 12, 2010, Barcelona, Spain > > > ** Programme Committee > > Co-Chairs: > Michael Haupt, Hasso-Plattner-Institut, University of Potsdam, Germany > Robert Hirschfeld, Hasso-Plattner-Institut, University of Potsdam, Germany > > PC Members: > Gabriela Arevalo, Universidad Nacional de La Plata, Argentina > Johannes Brauer, NORDAKADEMIE, Germany > Johan Brichau, UniversitÃ© catholique de Louvain, Belgium > Marcus Denker, INRIA Lille - Nord Europe, France > Theo D'Hondt, Vrije Universiteit Brussel, Belgium > StÃ©phane Ducasse, INRIA Lille - Nord Europe, France > James Foster, GemStone Systems, Inc., USA > Andy Kellens, Vrije Universiteit Brussel, Belgium > Andreas Raab, Teleplace Inc., USA > Lukas Renggli, Software Composition Group (SCG), University of Bern, > Switzerland > Randal L. Schwartz, Stonehenge Consulting Services, Inc. > Dave Ungar, IBM Research > >

March 30, 2010

Re: [Pharo-project] squeakToUTF-8 and related?

by Nicolas Cellier

2010/3/30 Norbert Hartl <norbert(a)hartl.name>: > > On 29.03.2010, at 11:52, Nicolas Cellier wrote: > > 2010/3/29 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On Mar 29, 2010, at 11:16 30AM, Nicolas Cellier wrote: > > I presume that under the idiom "latin1" you refer to code page 1252 > > rather than iso8859-L1, right ? > > Nicolas > > Good question :) > > What IS the presumed internal encoding of Bytestrings in Squeak? > > That's the one I meant, I merely assumed it was latin1 seeing as how the > text converter refers to it as such. > > Personally I thought it was iso8859-L1, seeing as the bytestring to unicode > conversion does a simple shift of chars > 127 to the 0080 - 00FF range. > > Cheers, > > Henry > > > From what I understood, CP1252 is Microsoft "latin1" and use codes 128 to > 159. > ISO8859-L1 match fisrt 256 codes of unicode latin-1 and has codes 128 > to 159 unused. > You know, when Microsoft "uses" a standard, it's always a better standard ;) > > I have nothing against CP1252, it's an optimization which avoid > wasting 32 cheap codes. > But I'm not sure about various compatibility issues in/with the > external world... > > If you know how to easily assure that > (String with: (Character value: (Integer readFrom: '20AC' base: 16))) > =Â (String with: (Character value: (Integer readFrom: '80' base: 16))) > than you might be safe. By using Windows-1252 code points aren't unique > anymore. Every code point in the range 0x80 - 0x9F exists somewhere else, > too. So my estimation would be that it will cause more trouble than it might > solve. > Agree. I see two different problems here: 1) absence of explicit encoding information in external data 2) existence of a canonical representation which can be easily compared... Generalization of UTF8 should solve 1 (slowly with lot of inertia), then we can simply assume implicit=UTF8. Unicode could solve 2... ...Well, as long as diacriticals are ignored. To me Unicode still has problems with: (String with: 16r61 asCharacter with: 16r0302 asCharacter) = (String with: 16rE2 asCharacter) Nicolas > Squeak clearly uses CP1252. > For Pharo, there might be a mix of the two since Sophie-like > refactorings. Surely what John was refering to. > > In pharo the 20AC string gives me a euro sign but the 80 hex one prints a > rectangle which is _a_ interpretation of '?' ;) > Norbert > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 30, 2010

Re: [Pharo-project] TeaTime (Re: nebraska?)

by StÃ©phane Ducasse

Good I like simple things. I'm really curious to learn it. So in a nutshell what is the idea of the synchronisation? How do do know which objects changed in an image? Stef On Mar 30, 2010, at 10:22 AM, Andreas Raab wrote: > On 3/20/2010 4:43 PM, Michael Rueger wrote: >> On 3/20/10 4:35 PM, Marcus Denker wrote: >>>> So why does everyone ignore TeaTime? I admit I don't understand the >>>> internals, but it obviously *looks* like it could be the basis of >>>> Nebraska (or any other P2P solution). >>>> >>> Can you point me to a real good publication about it? I mean, a >>> *real* one? >> >> AFAIK TeaTime never happened but they (Croquet/Cobalt) switched to some >> multiplayer game like sync scheme (at least the poor me understood when >> I saw the implementation ;-) ). > > Actually we didn't. TeaTime (as conceived by David Reed) consisted of two separate ideas, namely that of a world synchronization protocol and that of a P2P network protocol. When David Smith and I implemented the version we shipped in Hedgehog we dropped the P2P network protocol part and only concentrated on the synchronization aspect which resulted in *major* simplifications. > > That turned out to be a real win because the original design required N^2 connections for N participants with the obvious resulting problems if you get to larger numbers of users (today we can run sessions in Teleplace with 250+ active participants). David and I originally replaced the P2P communication with a single central entity (the router) but today this is actually a router overlay network that gives us theoretical scalability to 10,000s of users in the same space (unfortunately the client currently cannot cope with the rendering of all the stuff today at scales > 250). > > Anyway. The important part is that due to the practical connectivity restrictions for most users (bandwidth, latency, firewalls) running purely P2P is really stupid. You need a fixed point outside the firewall that you connect to via TCP through proxy and whatever BS the local environment requires and from that fixed point it goes into the overlay network. This has many additional advantages that I won't elaborate on here. > > As for publications, I don't know what amounts for a "real" publication in your eyes Marcus but considering that neither David nor myself are measured by number or quality of our publications you'll have to do with the publications listed at http://opencroquet.org/index.php/Overview I would in particular recommend the Hedgehog architecture presentation at http://opencroquet.org/images/e/ee/2005_Hedgehog_Architecture.pdf which is from the talk David and I gave at the OOPSLA workshop. As you look at the presentation read the documentation at http://opencroquet.org/index.php/Croquet_SDK which talks about the stuff in the slides. > > Coincidentally, I am toying regularly with the idea of using an even more simplified version of TeaTime to do something like Nebraska. Might get around to it one of these days, it's actually straightforward. > > BTW, it's a misconception to think TeaTime is something complicated. Complicated things don't work. Simple things do. TeaTime is actually VERY simple. That's why it works. > > Cheers, > - Andreas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 30, 2010