- Pharo-dev - lists.pharo.org

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

by Camillo Bruni

On 2012-10-28, at 20:38, Hilaire Fernandes <hilaire.fernandes(a)edu.ge.ch> wrote: > Le 28/10/2012 20:30, Alexandre Bergel a Ã©crit : >>> So it does not need any Smalltalk code ? Does it work with http messages >>> or something like that? >> >> I think so since you get files from a webbrowser >> >> Alexandre >> > > Do you know Smalltalk code example I can get inspiration from ? If you plan to go big, why not an Amazon S3 backend for FileSystem? I checked once, shouldn't be that much of work. Once you got that, sharing files is as easy as accessing local ones... best cami

Oct. 28, 2012

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

by Hilaire Fernandes

Le 28/10/2012 20:30, Alexandre Bergel a Ã©crit : >> So it does not need any Smalltalk code ? Does it work with http messages >> or something like that? > > I think so since you get files from a webbrowser > > Alexandre > Do you know Smalltalk code example I can get inspiration from ? Thanks Hilaire

Oct. 28, 2012

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

by Udo Schneider

Hi Igor I should have written process with a capital "P". I meant the Smalltalk class "Process" - a OS process :-) Best Regards, Udo On 28.10.12 17:44, Igor Stasenko wrote: > On 28 October 2012 10:45, Udo Schneider <udo.schneider-1KM8gpPNTmzSOrrRgtP2Kg(a)public.gmane.org> 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-XMD5yJDbdMReXY1tMh2IBg(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

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

by Hilaire Fernandes

Le 28/10/2012 20:30, Alexandre Bergel a Ã©crit : >> So it does not need any Smalltalk code ? Does it work with http messages >> or something like that? > > I think so since you get files from a webbrowser > > Alexandre > Do you know Smalltalk code example I can get inspiration from ?

Oct. 28, 2012

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

by Alexandre Bergel

> So it does not need any Smalltalk code ? Does it work with http messages > or something like that? I think so since you get files from a webbrowser Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 28, 2012

Re: [Pharo-project] Bug 6596

by Sven Van Caekenberghe

On 28 Oct 2012, at 11:08, Benoit St-Jean <bstjean(a)yahoo.com> wrote: > Comments, complaints and suggestions are welcome! Both formatting AND (strict) parsing should be provided, symmetrically. Names of months and weekdays should be translatable into arbitrary languages, probably other aspects as well, like AM/PM or BCâ¦ Timezones have various names as well (Europe/Brussels, CEST, Central European Time). Offset to timezone mapping is not unique. All in all, not easy. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Oct. 28, 2012

Re: [Pharo-project] Bug 6596

by Camillo Bruni

On 2012-10-28, at 18:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 28 Oct 2012, at 18:07, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> 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'. > > I was planning on doing the same thing, based on the way Go does it â¦ > > You write too much code ! it's far from finished :P, so stop complaining :D

Oct. 28, 2012

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

by Sebastian Sastre

yeah right? a great way to completely wipe out all that CoffeScript hype :D and take a look a this too! https://github.com/NicolasPetton/amber/tree/master/examples/nodejs and maybe this: https://groups.google.com/forum/#!topic/amber-lang/sd5UwcXv8mg an architecture that can provide results like this: https://www.youtube.com/watch?feature=player_embedded&v=uUOlzr4XdcY sebastian o/ On Oct 28, 2012, at 7:46 AM, Udo Schneider wrote: > > > 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] Bug 6596

by Sven Van Caekenberghe

On 28 Oct 2012, at 18:07, Camillo Bruni <camillobruni(a)gmail.com> wrote: > 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'. I was planning on doing the same thing, based on the way Go does it â¦ You write too much code !

Oct. 28, 2012

Re: [Pharo-project] Bug 6596

by Denis Kudriashov

Hello 2012/10/28 Camillo Bruni <camillobruni(a)gmail.com> > 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'. > I like it

Oct. 28, 2012