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

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

hey Goran, just a heads up… none of the examples compile for the current master branch sebastian o/ On Oct 29, 2012, at 6:44 AM, Göran Krampe wrote:

Hi!

On 10/28/2012 10:46 AM, Udo Schneider wrote:

...

Hi Stef,

but isn't Amber targeting the client side? My Deployment Platform would be the server.

Amber works fine on node, in fact, there are several examples (if you do the git clone and check under "examples") and we even run the command line compiler "amberc" in node (written in Amber).

Amber compiles to js, there is nothing client centric about it - but the IDE is written on jQuery to run in a browser, but the packages are cleanly separated from each other (IDE vs kernel etc).

regards, Göran

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

On 28 October 2012 10:45, Udo Schneider <udo.schneider@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@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.

This should have read " not an OS process" of course. Best Regards, Udo On 28.10.12 20:37, Udo Schneider wrote:

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-XMD5yJDbdMReXY1tMh2IBg@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-XMD5yJDbdMReXY1tMh2IBg@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

Hi Igor, thanks for the reply. The idea working with Semaphore has definitly it's own charm. From my last (high-level) check I only found serial primitives which return 0 bytes if nothing was recieved meanwhile - no Semaphore as far as I saw. Regarding adding support for this - I try to stay away from the VM (due to C - no pun intended!) as far as possible. So I'd rather pay somebody who knows his was around in the VM to do it :-) Volunteers? Best Regards, Udo On 08.11.12 05:13, Igor Stasenko wrote:

Sorry, Udo, for quick response.

I think you can do that with Pharo without polling. You just use semaphores (which directly signaled by OS+VM). I am not sure about if everything in VM (usb/midi /etc) uses non-blocking i/o out of the box, but if you really really want to hake it and ready to pay for it (in terms of own time (or somebody else's ;) )) i do not see any impenetrable barriers there.