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