October 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Bug 6596

by Camillo Bruni

I started a (STAMP)[https://github.com/jeremyw/stamp] port for Pharo http://smalltalkhub.com/mc/dh83/c/main which follows an example drive date-formatting scheme. Instead of using a cryptic compressed form you use an example string DateAndTime now stompFormat: '2012-12-31 14:32:12'. DateAndTime now stompFormat: '2012/31/12 14:32:12'. best cami On 2012-10-28, at 17:56, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Oct 28, 2012, at 11:08 AM, Benoit St-Jean wrote: > >> Hello everyone, >> >> While looking at bug 6596, I started wondering why we didn't have more options to print dates (and/or their parts). I've gathered "date formats" printing options from various sources and started implementing all those different formats and options. >> I have implemented 6 new methods to print the different date components/parts/timespans. >> >> Do you think this stuff would be useful? > > Yes > I often just want the one that is not there :) > Note that in French we have > >> 14 mai 2002 > > So it would be good to support it. I imagine that we can with the #(d m y) description. > > > > >> Anything missing? >> >> Here are the supported format options I came up with. Most of them are already implemented, now it's just a matter of writing the numerous missing unit tests! ;) >> >> Comments, complaints and suggestions are welcome! >> >> a) Year formats (#printYearWithFormat:) >> >> May 14, -7 >> May 14 2002 >> >> 1-Year, signed (-7 and 2002) >> 2-Year, last 2 digits, signed (-07 and 02) >> 3-Year, last 3 digits, signed (-007 and 002) >> 4-Year, last 4 digits or more digits if year is greater than 9999, signed (-0007 and 2002) >> 5-Year, unsigned (7 and 2002) >> 6-Year, last 2 digits, unsigned (07 and 02) >> 7-Year, last 3 digits, unsigned (007 and 002) >> 8-Year, last 4 digits or more digits if year is greater than 9999, unsigned (0007 and 2002) >> 9-Year in roman numerals (n/a and MMII) >> 10-Year (full, no padding) with epoch AD/BC (7 BC and 2002 AD) >> 11-Year (full, no padding) with epoch A.D./B.C. (7 B.C. and 2002 A.D.) >> 12-Year (full, no padding) with epoch ad/bc (7 bc and 2002 ad) >> 13-Year (full, no padding) with epoch a.d./b.c. (7 b.c. and 2002 a.d.) >> >> b) Month formats (#printMonthWithFormat:) >> >> Tuesday, September 18 2012 >> >> 1-Month , no padding (9) >> 2-Month padded to 2 digits (09) >> 3-Month name abreviation (Sep) >> 4-Month name (September) >> 5-Month name abreviation in uppercase (SEP) >> 6-Month name in uppercase (SEPTEMBER) >> 7-Month name abreviation in lowercase (sep) >> 8-Month name in lowercase (september) >> 9-Month number in Roman numerals (IX) >> >> c) Day formats (#printDayWithFormat:) >> >> Saturday, December 1 2012 >> >> 1-Day of the month, no padding (1) >> 2-Day of the month padded to 2 digits (01) >> 3-Abbreviated day of week (Sat) >> 4-Complete day of week (Saturday) >> 5-Abbreviated day of week in uppercase (SAT) >> 6-Complete day of week in uppercase (SATURDAY) >> 7-Abbreviated day of week in lowercase (sat) >> 8-Complete day of week lowercase (saturday) >> 9-Day of the month with english suffix (1st) >> 10-Day of the year (336) >> 11-Day of the year with English suffix (336th) >> 12-Day of the week index [0=sunday 6 = saturday] (6) >> 13-Day of the week index [1=sunday 7 = saturday] (7) >> 14-Day of the week index [0=monday 6 = sunday] (5) >> 15-Day of the week index [1=monday 7 = sunday] (6) >> 16-Julian day, i.e. days since January 1, 4712 BC (2456263) >> >> d) Week formats (#printWeekWithFormat:) >> >> 1-Week of the year (1..53) where Sunday if the first day of the week >> 2-Week of the year (1..53) where Monday if the first day of the week >> >> e) Era formats (#printEraWithFormat:) >> >> 1-Era AD or BC >> 2-Era A.D. or B.C. >> 3-Era ad or bc >> 4-Era a.d. or b.c. >> >> f) Century formats (#printCenturyWithFormat:) >> >> 1-Century (20) >> 2-Century with English suffix (20th) >> >> >> ----------------- >> Benoit St-Jean >> Yahoo! Messenger: bstjean >> A standpoint is an intellectual horizon of radius zero. >> (Albert Einstein) > >

Oct. 28, 2012

Re: [Pharo-project] Bug 6596

by Benoit St-Jean

Yeah, same thing here...Â But I was wondering about other languages...Â I mean, yes we can support French and English but what about Spanish, Italian, etc?Â Should we use the NaturalLanguageTranslator tool/mechanism ? Â ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) >________________________________ > From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >To: Pharo-project(a)lists.gforge.inria.fr; Benoit St-Jean <bstjean(a)yahoo.com> >Sent: Sunday, October 28, 2012 12:56:24 PM >Subject: Re: [Pharo-project] Bug 6596 > > >On Oct 28, 2012, at 11:08 AM, Benoit St-Jean wrote: > >> Hello everyone, >> >> While looking at bug 6596, I started wondering why we didn't have more options to print dates (and/or their parts).Â I've gathered "date formats" printing options from various sources and started implementing all those different formats and options. >> I have implemented 6 new methods to print the different date components/parts/timespans. >> >> Do you think this stuff would be useful?Â > >Yes >I often just want the one that is not there :) >Note that in French we have > >>Â 14 mai 2002 > >So it would be good to support it. I imagine that we can with the #(d m y) description. > > > > >> Anything missing?Â >> >> Here are the supported format options I came up with.Â Most of them are already implemented, now it's just a matter of writing the numerous missing unit tests!Â ;) >> >> Comments, complaints and suggestions are welcome! >> >> a) Year formatsÂ (#printYearWithFormat:) >> >> May 14, -7 >> May 14 2002 >> >> 1-Year, signed (-7 and 2002) >> 2-Year, last 2 digits, signed (-07 and 02) >> 3-Year, last 3 digits, signed (-007 and 002) >> 4-Year, last 4 digits or more digits if year is greater than 9999, signed (-0007 and 2002) >> 5-Year, unsigned (7 and 2002) >> 6-Year, last 2 digits, unsigned (07 and 02) >> 7-Year, last 3 digits, unsigned (007 and 002) >> 8-Year, last 4 digits or more digits if year is greater than 9999, unsigned (0007 and 2002) >> 9-Year in roman numerals (n/a and MMII) >> 10-Year (full, no padding) with epoch AD/BC (7 BC and 2002 AD) >> 11-Year (full, no padding) with epoch A.D./B.C. (7 B.C. and 2002 A.D.) >> 12-Year (full, no padding) with epoch ad/bc (7 bc and 2002 ad) >> 13-Year (full, no padding) with epoch a.d./b.c. (7 b.c. and 2002 a.d.) >> >> b) Month formats (#printMonthWithFormat:) >> >> Tuesday, September 18 2012 >> >> 1-Month , no padding (9) >> 2-Month padded to 2 digits (09) >> 3-Month name abreviation (Sep) >> 4-Month name (September) >> 5-Month name abreviation in uppercase (SEP) >> 6-Month name in uppercase (SEPTEMBER) >> 7-Month name abreviation in lowercase (sep) >> 8-Month name in lowercase (september) >> 9-Month number in Roman numerals (IX) >> >> c) Day formats (#printDayWithFormat:) >> >> Saturday, December 1 2012 >>Â Â >> 1-Day of the month, no padding (1) >> 2-Day of the month padded to 2 digits (01) >> 3-Abbreviated day of week (Sat) >> 4-Complete day of week (Saturday) >> 5-Abbreviated day of week in uppercase (SAT) >> 6-Complete day of week in uppercase (SATURDAY) >> 7-Abbreviated day of week in lowercase (sat) >> 8-Complete day of week lowercase (saturday) >> 9-Day of the month with english suffix (1st) >> 10-Day of the year (336) >> 11-Day of the year with English suffix (336th) >> 12-Day of the week index [0=sunday 6 = saturday] (6) >> 13-Day of the week index [1=sunday 7 = saturday] (7) >> 14-Day of the week index [0=monday 6 = sunday] (5) >> 15-Day of the week index [1=monday 7 = sunday] (6) >> 16-Julian day, i.e. days since January 1, 4712 BC (2456263) >> >> d) Week formats (#printWeekWithFormat:) >> >> 1-Week of the year (1..53) where Sunday if the first day of the week >> 2-Week of the year (1..53) where Monday if the first day of the week >> >> e) Era formats (#printEraWithFormat:) >> >> 1-Era AD or BC >> 2-Era A.D. or B.C. >> 3-Era ad or bc >> 4-Era a.d. or b.c. >> >> f) Century formats (#printCenturyWithFormat:) >> >> 1-Century (20) >> 2-Century with English suffix (20th) >> >>Â >> ----------------- >> Benoit St-Jean >> Yahoo! Messenger: bstjean >> A standpoint is an intellectual horizon of radius zero. >> (Albert Einstein) > > > >

Oct. 28, 2012

Re: [Pharo-project] Bug 6596

by StÃ©phane Ducasse

On Oct 28, 2012, at 11:08 AM, Benoit St-Jean wrote: > Hello everyone, > > While looking at bug 6596, I started wondering why we didn't have more options to print dates (and/or their parts). I've gathered "date formats" printing options from various sources and started implementing all those different formats and options. > I have implemented 6 new methods to print the different date components/parts/timespans. > > Do you think this stuff would be useful? Yes I often just want the one that is not there :) Note that in French we have > 14 mai 2002 So it would be good to support it. I imagine that we can with the #(d m y) description. > Anything missing? > > Here are the supported format options I came up with. Most of them are already implemented, now it's just a matter of writing the numerous missing unit tests! ;) > > Comments, complaints and suggestions are welcome! > > a) Year formats (#printYearWithFormat:) > > May 14, -7 > May 14 2002 > > 1-Year, signed (-7 and 2002) > 2-Year, last 2 digits, signed (-07 and 02) > 3-Year, last 3 digits, signed (-007 and 002) > 4-Year, last 4 digits or more digits if year is greater than 9999, signed (-0007 and 2002) > 5-Year, unsigned (7 and 2002) > 6-Year, last 2 digits, unsigned (07 and 02) > 7-Year, last 3 digits, unsigned (007 and 002) > 8-Year, last 4 digits or more digits if year is greater than 9999, unsigned (0007 and 2002) > 9-Year in roman numerals (n/a and MMII) > 10-Year (full, no padding) with epoch AD/BC (7 BC and 2002 AD) > 11-Year (full, no padding) with epoch A.D./B.C. (7 B.C. and 2002 A.D.) > 12-Year (full, no padding) with epoch ad/bc (7 bc and 2002 ad) > 13-Year (full, no padding) with epoch a.d./b.c. (7 b.c. and 2002 a.d.) > > b) Month formats (#printMonthWithFormat:) > > Tuesday, September 18 2012 > > 1-Month , no padding (9) > 2-Month padded to 2 digits (09) > 3-Month name abreviation (Sep) > 4-Month name (September) > 5-Month name abreviation in uppercase (SEP) > 6-Month name in uppercase (SEPTEMBER) > 7-Month name abreviation in lowercase (sep) > 8-Month name in lowercase (september) > 9-Month number in Roman numerals (IX) > > c) Day formats (#printDayWithFormat:) > > Saturday, December 1 2012 > > 1-Day of the month, no padding (1) > 2-Day of the month padded to 2 digits (01) > 3-Abbreviated day of week (Sat) > 4-Complete day of week (Saturday) > 5-Abbreviated day of week in uppercase (SAT) > 6-Complete day of week in uppercase (SATURDAY) > 7-Abbreviated day of week in lowercase (sat) > 8-Complete day of week lowercase (saturday) > 9-Day of the month with english suffix (1st) > 10-Day of the year (336) > 11-Day of the year with English suffix (336th) > 12-Day of the week index [0=sunday 6 = saturday] (6) > 13-Day of the week index [1=sunday 7 = saturday] (7) > 14-Day of the week index [0=monday 6 = sunday] (5) > 15-Day of the week index [1=monday 7 = sunday] (6) > 16-Julian day, i.e. days since January 1, 4712 BC (2456263) > > d) Week formats (#printWeekWithFormat:) > > 1-Week of the year (1..53) where Sunday if the first day of the week > 2-Week of the year (1..53) where Monday if the first day of the week > > e) Era formats (#printEraWithFormat:) > > 1-Era AD or BC > 2-Era A.D. or B.C. > 3-Era ad or bc > 4-Era a.d. or b.c. > > f) Century formats (#printCenturyWithFormat:) > > 1-Century (20) > 2-Century with English suffix (20th) > > > ----------------- > Benoit St-Jean > Yahoo! Messenger: bstjean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein)

Oct. 28, 2012

Re: [Pharo-project] Tips for efficient multi-serial handling

by StÃ©phane Ducasse

On Oct 28, 2012, at 10:46 AM, Udo Schneider wrote: > > > Hi Stef, > > but isn't Amber targeting the client side? My Deployment Platform would be the server. yes amber is more client side. But if you have a JS VM on a server then Amber is server side. Now we should definitively improves the pharo infrastructure we have. I think that sven work is definitively showing the way. Two years ago we did not have - https - websockets - Oathâ¦ Stef > Best Regards, > > Udo > > > On 27.10.12 17:30, StÃ©phane Ducasse wrote: >> better look at amber (because it is better to get the original than the copy). >> >> Stef >>> Hey Udo! >>> >>> well, if node does a great job and you love Smalltalk, then this [1] could get your attention >>> >>> sebastian >>> >>> o/ >>> >>> [1] http://u8.smalltalking.net/contribution.aspx?contributionId=133 >>> >>> >>> >>> >>> On Oct 27, 2012, at 6:09 AM, Udo Schneider wrote: >>> >>>> All, >>>> >>>> coming from a Node.JS background for those kind of tasks I'm not quite sure how to do it "correctly" in Pharo. I need to >>>> >>>> * listen on up to 32 serial (USB) ports for incoming commands. Each might use a different "protocol". >>>> * listen to network ports, midi channels or OSC >>>> * if communication is received then a response could be send over multiple of the channels mentioned above >>>> * reaction time - means incomming message, decode, encode of response and distribution over other channels should ideally be around 10^-2 s. >>>> >>>> I already found all the necessary communication classes in Pharo - and being back in Smalltalk again parsing the commands is a real pleasure :-) The one thing that makes me really nervous though is serial support. Up to now I spawn a separate (Smalltalk) process for each serial port that polls the serial port for new bytes - as far as I see polling is the only available option. Although this seems to work it wastes a considerable amount of CPU cycles IMHO. On my current system (MBP/i7) I can't have enough channels to even barely bog the system down. However the deployment platform I'm looking at is more in the range of an Raspberry Pi... >>>> >>>> In Node.JS I'd simply create callbacks for all the different incoming channels - so I wouldn't waste cycles for polling. So what would be the best/recommended way to achieve this in Pharo? >>>> >>>> Thanks, >>>> >>>> Udo >>>> >>>> >>> >> >> >> > > >

Oct. 28, 2012

Re: [Pharo-project] Tips for efficient multi-serial handling

by Igor Stasenko

On 28 October 2012 10:45, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: > > > Hi Sven, > > >> Dealing with a set of IO channels using 1 thread/process per channel >> like you describe should not be a problem. To do it efficiently, you >> have to consider if the low level API you are dealing with is >> blocking or not. If it is blocking (optionally with a timeout), like >> for sockets, there is no problem. If it is non-blocking, you can >> easily built something around it using delays and some polling at a >> reasonable values. If have no experience with serial ports, so I >> can't offer any specific advice there. For TCP/UDP networking there >> shouldn't be any problem. Feel free to ask concrete questions. > Thanks for all the tips. The current VM Implementation is non-blocking - > e.g. return an empty byte array if nothing was recieved. So my procecces > (per port) are polling seperated by calls to Delay. > > BTW: Does "(Delay forMilliseconds: time) wait" actually "cost" something in > terms of CPU cycles. Reading through the comments I got the impression that > besides delaying the current process it doesn't cause any penalty for other > processes. > it doesn't. smalltalk employs green threading model. while js dont even have a notion of a process (thread) in language. > Best Regards, > > Udo > > > > On 27.10.12 17:45, Sven Van Caekenberghe wrote: >> >> Hi Udo, >> >> Yes, Smalltalk is a very nice environment to work in, it is only natural >> to try to do as much work in it as possible. >> >> It looks like you are doing a nice, interesting project ;-) >> >> As a language/environment born in a time when computing resources were >> very small compared to what we have today, you can rest assured that >> Smalltalk can keep up performance wise with almost any other language out >> there, especially JavaScript, Ruby, Python, PHP or Perl. >> >> Dealing with a set of IO channels using 1 thread/process per channel like >> you describe should not be a problem. To do it efficiently, you have to >> consider if the low level API you are dealing with is blocking or not. If it >> is blocking (optionally with a timeout), like for sockets, there is no >> problem. If it is non-blocking, you can easily built something around it >> using delays and some polling at a reasonable values. If have no experience >> with serial ports, so I can't offer any specific advice there. For TCP/UDP >> networking there shouldn't be any problem. Feel free to ask concrete >> questions. >> >> Regards, >> >> Sven >> >> -- >> Sven Van Caekenberghe >> http://stfx.eu >> Smalltalk is the Red Pill >> >> >> >> On 27 Oct 2012, at 10:09, Udo Schneider >> <udo.schneider-1KM8gpPNTmzSOrrRgtP2Kg(a)public.gmane.org> wrote: >> >>> All, >>> >>> coming from a Node.JS background for those kind of tasks I'm not quite >>> sure how to do it "correctly" in Pharo. I need to >>> >>> * listen on up to 32 serial (USB) ports for incoming commands. Each might >>> use a different "protocol". >>> * listen to network ports, midi channels or OSC >>> * if communication is received then a response could be send over >>> multiple of the channels mentioned above >>> * reaction time - means incomming message, decode, encode of response and >>> distribution over other channels should ideally be around 10^-2 s. >>> >>> I already found all the necessary communication classes in Pharo - and >>> being back in Smalltalk again parsing the commands is a real pleasure :-) >>> The one thing that makes me really nervous though is serial support. Up to >>> now I spawn a separate (Smalltalk) process for each serial port that polls >>> the serial port for new bytes - as far as I see polling is the only >>> available option. Although this seems to work it wastes a considerable >>> amount of CPU cycles IMHO. On my current system (MBP/i7) I can't have enough >>> channels to even barely bog the system down. However the deployment platform >>> I'm looking at is more in the range of an Raspberry Pi... >>> >>> In Node.JS I'd simply create callbacks for all the different incoming >>> channels - so I wouldn't waste cycles for polling. So what would be the >>> best/recommended way to achieve this in Pharo? >>> >>> Thanks, >>> >>> Udo >>> >>> >> >> >> > > > -- Best regards, Igor Stasenko.

Oct. 28, 2012

Re: [Pharo-project] File sharing on the network

by Hilaire Fernandes

So it does not need any Smalltalk code ? Does it work with http messages or something like that? I am total newby on that. I wrote an interface for file shareing through FTP with DrGeo (on its repo) but it is too cryptic for users. Hilaire Le 28/10/2012 17:11, Sebastian Sastre a Ã©crit : > > why not? > https://www.dropbox.com/developers/start > > https://developers.google.com/drive/ > > sebastian <https://about.me/sebastianconcept> > > o/ > > > > > > On Oct 28, 2012, at 1:56 PM, Hilaire Fernandes wrote: > >> Hello >> >> Is there anyway to implement fileshareing with Dropbox or GoogleDrive on >> a Pharo client application? >> >> Thanks >> >> Hilaire >> >> >

Oct. 28, 2012

Re: [Pharo-project] File sharing on the network

by Sebastian Sastre

why not? https://www.dropbox.com/developers/start https://developers.google.com/drive/ sebastian o/ On Oct 28, 2012, at 1:56 PM, Hilaire Fernandes wrote: > Hello > > Is there anyway to implement fileshareing with Dropbox or GoogleDrive on > a Pharo client application? > > Thanks > > Hilaire > >

Oct. 28, 2012

[Pharo-project] File sharing on the network

by Hilaire Fernandes

Hello Is there anyway to implement fileshareing with Dropbox or GoogleDrive on a Pharo client application? Thanks Hilaire

Oct. 28, 2012

Re: [Pharo-project] Please review DrGeo

by Hilaire Fernandes

I can't. I am bound to GooglePlay once I start using it. Hilaire Le 28/10/2012 08:42, Olivier Auverlot a Ã©crit : > Hi Hilaire, > > Could you provide a direct download of the free version of drGeo on the > drGeo web site because many Android tablets have no access to Google Play ? > > Another solution is to distribute your product on the other Android > shops (Amazon, Archos appstore, Luxia download center, Soc.io Mall, > etc.) but It's probably a lot of work. > > Best regards > Olivier :-) > > Le 27 oct. 2012 Ã 07:52, Hilaire Fernandes a Ã©crit : > >> hello, >> >> For those who installed free or paid version of DrGeo on iPad or >> Android, it will be very helpful you review it on GooglePlay or iTunes. >> Some users Install DrGeo on Android phone and are disappointed (not >> enough memory then crash, slow, screen too small) and they are killing >> DrGeo because of that, but DrGeo is for tablet (although I use it >> happily on my galaxy note phone). For next release I will be careful >> to limit the Android user base. >> >> Thanks >> >> -- >> Dr. Geo - http://www.drgeo.eu <http://www.drgeo.eu/> >

Oct. 28, 2012

Re: [Pharo-project] How to deliver real-time web and mobile applications?

by Sebastian Sastre

Awesome vision Seba! It leaves me with the kind of unrealistic feeling that great ideas provoke :D 3 thoughts: 1. homogeneity sounds great but the tech future is heterogeneous (and not a little but in a Long Tail fashion!) 2. dynamic technologies already won. So we might try to take more advantage of this fact. You'll have VM's for every device available (V8, Dart and friends) 3. if doesn't have an impact on the experience, people are not even close to care about what tech are we using to provide it* How us nerds of all kinds are going to deal with this is not clear, but for anthropological and cognitive and economic reasons, this we do know: clients and consumers are not going to ask and pay for... 1. less collaboration 2. less connection (among people in their tribes and other audiences) 3. less device-diversity (for same experience) 4. less availability (of the software that gives them the experience) but quite the opposite. In case of doubt: observe how you, family and colleagues (and their teen children) consume the opportunity is right there for those who can deliver sebastian o/ *actually some of them will (innovators and some early adaptors), but only after they got really excited about the product or service done with it On Oct 28, 2012, at 10:02 AM, Sebastian Nozzi wrote: > Hello Sebastian, > > [for the interesint part skip to *here*] > > I also think that the collaboration platforms that offer more > "real-time" features will win. Even more if they can solve the problem > of not always being connected (on the other hand, this is happening > less and less). Although I think that there is still time, it is not > by much (Google Docs does not currently support offline-mode, though > they had that in the past. For some reason they cancelled the feature; > they also cancelled Wave - maybe it's too complex even for them!??!). > > A good approach to making it work with and without connection would > seem to be to assume the worst: assume there is no connection. Model > all updates and sync as delayed and a-sync. And if you DO have > connection, the better :-) > > I would go so far as to say that this is how Apple solves the problem > with iCloud and Core-Data. If you are interested in this subject, I > would recommend reading their documentation even if you don't code for > Apple platforms (I don't either, although I planned to). They are not > at the real-time modifications yet, although very close. For me it > WILL be one of their next moves against Google and the Web. > > *here* > > As for a "Smalltalk" way to solve this, one thing I would love to have > at some point is a framework for automatic (seamless) > data-synchronization. Only that it would not be "data" but "objects" > ;-) > > Something like that /could/ then be a core Pharo feature, if not a > KILLER feature. > > Imagine having 2 related VMs (or unrelated, but with some related > object graph) in two parts of the world. One user changes one object > in the fist one, another changes another (or the same) object in the > second one. When they contact the cloud they synchronize automatically > (either peer-to-peer or to/from a trusted server). And I see the > changes happening automatically, without having to do a thing. Awesome > right? Now that "VM" (or object graph) could be Pharo, or a web-app in > Amber, why not... > > If both are connected, then the changes occur immediately, and we > experience it in "real-time". If the connect at different points in > time, then the changes are delayed (delayed collaboration, or > synchronization). > > I think the problem is rather complex and I am afraid that it's not > that easy to come up with a solution that is, on the one hand, easy > enough, and on the other hand flexible enough to accommodate for all > cases. Google Docs, or Apple iCloud, are "document-centric". Much > different is to deal with an object graph of any possible shape, I > think. > > But there are much brighter minds in this list than mine, and I am > sure that some day one will come with this killer-framework and > Smalltalk will be, once again, at the forefront of innovation :-) > > Best regards, > > (also) Sebastian >

Oct. 28, 2012