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

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

by Herby VojÄÃk

Interesting thoughts, but it reminds me of: 1. CouchDB. It is able to connect and synchronize two-way, master-master, and has implementation for server as well as for mobile, so, in a way, they are already there - you work, online of offline, on the same data. But they have problems, when conflict occurs, someone must resolve it. CouchDB's way is to not accept one or the other, but creates 'confict' object and someone with enough authority must resolve it (automatically or by-hand). 2. Object databases. This is more smalltalkish, but smells of 'we already tried it and the world did not embrace'. In a sense, what you describe seems to me like a distributed object db. If this would work (and, for example, there would be something like CouchDB+CouchApps, but in Smalltalk, I'd be really glad). But I don't know, if it is feasible. Herby 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

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

by Sebastian Nozzi

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

[Pharo-project] Bug 6596

by Benoit St-Jean

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?Â 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 Udo Schneider

Hi Stef, but isn't Amber targeting the client side? My Deployment Platform would be the server. 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 Udo Schneider

Hi Sebastian, thanks for the pointer - I'll take a look at it. From what I can tell this is basically node.js with a Smalltalk->JavaScript "cross-interpreter". Definitely looks interesting! Best Regards, Udo On 27.10.12 13:24, Sebastian Sastre wrote: > Hey Udo! > > well, if node does a great job and you love Smalltalk, then this > <http://u8.smalltalking.net/contribution.aspx?contributionId=133> [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 Udo Schneider

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. 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 >> >> > > >

Oct. 28, 2012

[Pharo-project] [update 2.0] #20368

by Marcus Denker

20368 ----- Issue 6868: Failing test: Tests.Release.ReleaseTest.testUnpackagedClasses http://code.google.com/p/pharo/issues/detail?id=6868 MCWorkingCopy allManagers do: #packageSet. RPackageOrganizer initialize Diff information: -- Marcus Denker -- http://marcusdenker.de

Oct. 28, 2012

Re: [Pharo-project] Please review DrGeo

by Olivier Auverlot

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

Oct. 28, 2012

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

by Sebastian Sastre

Stef, now you mention it... do you know if Amber has something in relation to node.js? I mean for the server side would be possible to program the server side of an app with amber smalltalk? sebastian o/ On Oct 27, 2012, at 1:30 PM, 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. 27, 2012

Re: [Pharo-project] Please review DrGeo

by Hilaire Fernandes

Le 27/10/2012 14:00, StÃ©phane Ducasse a Ã©crit : > justement j'ai essayer de mettre une note mais je ne sais pas comment on fait. > On peut installer DRGeo sur Ipad? Depuis iTunes, mais tu dois installer Dr. Geo avant et il faut un identifiant. Hilaire

Oct. 27, 2012