Smalltalk › Squeak › Squeak - Dev

Physical Etoys released!

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

31 messages Options

K. K. Subramaniam

Re: [etoys-dev] Re: [squeak-dev] Physical Etoys released!

On Wednesday 03 March 2010 05:12:32 am Ricardo Moran wrote:
> I might be missing something obvious here, but why is FFI forbidden in
> Etoys? Is it a matter of security?
AFAIK, Etoys is conceived to be a self-contained computing machine. Primitives
and plugins purely an optimization or facilitation. FFI is a bridge to host-
specific libraries and it is open-ended. It reduces Etoys to a shell for the
libraries. The code within the libraries is not available for
browsing/modification within Etoys.

Subbu

Bert Freudenberg

Re: Physical Etoys released!

In reply to this post by Ricardo Moran

On 03.03.2010, at 00:42, Ricardo Moran wrote:
> I might be missing something obvious here, but why is FFI forbidden in Etoys? Is it a matter of security?

Yes. One of the advantages of having a Virtual Machine is that you can be quite sure what the code running in it can and can not do. It has a pretty narrow interface to the "outer system". By allowing FFI that interface widens to all the libraries on the system, which means all bets are off.

Additionally, FFI calls are highly platform-specific, whereas Etoys projects are supposed to work on any platform.

> Regarding the "generic hardware-interface plugin", I think it would be great to have something like that but don't you think the underlying platforms are very much incompatible with each other?

That's the point of having plugins - they are an extension of the Virtual Machine. Just like the VM itself, they present an abstraction to the code inside the image. The actual implementation can differ a lot across platforms (and often does) but the image doesn't have to care.

So, that generic plugin would present all its actual hardware to the user as a collection of abstract input or output ports. There only need to be a few functions:

- get number of available ports (1 to n)
- get label of a port (just a string to be used in the UI, possibly hierarchical)
- get the kind (input/output) of a port
- get value range (min/max/step) for a port
- open a port for actual use
- read data from an open input port
- write data to an open output port
- close a port

If there is hardware that wouldn't fit into that framework it can be extended of course, but it seems it could cover a lot, no?

- Bert -

Derek O'Connell-2

Re: [etoys-dev] Physical Etoys released!

In reply to this post by Ricardo Moran

I will do some more work on an interface to the Velleman K8055/VM110
Interface Card in a few weeks if you would like to add it to the list.
Here's a wiki page on my last effort some years back:
http://wiki.squeak.org/squeak/5907

Merik Voswinkel-3

Re: Physical Etoys released!

In reply to this post by Benjamin L. Russell

Please don't forget Mac OS X, including the PPC, Intel and Arm
platforms.

On Mar 2, 2010, at 2:33 AM, Benjamin L. Russell wrote:

> Ricardo Moran <[hidden email]>
> writes:
>
>> Unfortunately, this version of Physical Etoys only works in
>> Windows. We are currently working on supporting Linux (especially the
>> Sugar platform) so stay tuned for future releases!
>
> Please keep support for Mac OS X in mind, too (I use 10.5.8 Leopard
> (PPC))!
>
> -- Benjamin L. Russell
> --
> Benjamin L. Russell / DekuDekuplex at Yahoo dot com
> http://dekudekuplex.wordpress.com/
> Translator/Interpreter / Mobile: +011 81 80-3603-6725
> "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^
>
>

Ricardo Moran

Re: [etoys-dev] Re: [squeak-dev] Physical Etoys released!

In reply to this post by K. K. Subramaniam

Oh, I see. Thanks for the explanation.

On Thu, Mar 4, 2010 at 1:36 AM, K. K. Subramaniam <[hidden email]> wrote:

On Wednesday 03 March 2010 05:12:32 am Ricardo Moran wrote:
> I might be missing something obvious here, but why is FFI forbidden in
> Etoys? Is it a matter of security?

AFAIK, Etoys is conceived to be a self-contained computing machine. Primitives
and plugins purely an optimization or facilitation. FFI is a bridge to host-
specific libraries and it is open-ended. It reduces Etoys to a shell for the
libraries. The code within the libraries is not available for
browsing/modification within Etoys.

Subbu

Ricardo Moran

Re: Physical Etoys released!

In reply to this post by Bert Freudenberg

On Thu, Mar 4, 2010 at 9:23 AM, Bert Freudenberg <[hidden email]> wrote:

On 03.03.2010, at 00:42, Ricardo Moran wrote:
> I might be missing something obvious here, but why is FFI forbidden in Etoys? Is it a matter of security?

Yes. One of the advantages of having a Virtual Machine is that you can be quite sure what the code running in it can and can not do. It has a pretty narrow interface to the "outer system". By allowing FFI that interface widens to all the libraries on the system, which means all bets are off.

Additionally, FFI calls are highly platform-specific, whereas Etoys projects are supposed to work on any platform.

Yes, those are very good reasons for excluding FFI from Etoys. If we write a plugin to handle the communication with the external libraries we use, would you reconsider including our work in Etoys? (now that I think of it, we will probably have some license issues... I will have to check that).

Anyway, I think you can include the Arduino and SqueakNxt projects, they don't use FFI at all, only the SerialPlugin. Would that be ok?

I must say, I would really love to see our projects included in Etoys!

> Regarding the "generic hardware-interface plugin", I think it would be great to have something like that but don't you think the underlying platforms are very much incompatible with each other?

That's the point of having plugins - they are an extension of the Virtual Machine. Just like the VM itself, they present an abstraction to the code inside the image. The actual implementation can differ a lot across platforms (and often does) but the image doesn't have to care.

So, that generic plugin would present all its actual hardware to the user as a collection of abstract input or output ports. There only need to be a few functions:

- get number of available ports (1 to n)
- get label of a port (just a string to be used in the UI, possibly hierarchical)
- get the kind (input/output) of a port
- get value range (min/max/step) for a port
- open a port for actual use
- read data from an open input port
- write data to an open output port
- close a port

If there is hardware that wouldn't fit into that framework it can be extended of course, but it seems it could cover a lot, no?

Ok, I understand your idea better now. It seems you want something a lot more low level than what we are doing. But you're right, it would be cool to have a plugin to handle all that stuff and write the corresponding protocols on top of that.

Cheers

Richo

- Bert -

Ricardo Moran

Re: [etoys-dev] Physical Etoys released!

In reply to this post by Derek O'Connell-2

I would love to include it on our list, but I would like to test it first. I'll see if I can get a K8055 (living in Argentina doesn't help very much).

Cheers

Richo

On Thu, Mar 4, 2010 at 11:55 AM, Derek O'Connell <[hidden email]> wrote:

I will do some more work on an interface to the Velleman K8055/VM110
Interface Card in a few weeks if you would like to add it to the list.
Here's a wiki page on my last effort some years back:
http://wiki.squeak.org/squeak/5907

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Ricardo Moran

Re: [squeakland] Re: [squeak-dev] Re: Physical Etoys released!

In reply to this post by Merik Voswinkel-3

Well, I think you're asking for a lot of platforms! :)

We'll see what we can do about Intel, though....

On Thu, Mar 4, 2010 at 12:32 PM, Merik Voswinkel <[hidden email]> wrote:

Please don't forget Mac OS X, including the PPC, Intel and Arm platforms.

On Mar 2, 2010, at 2:33 AM, Benjamin L. Russell wrote:

Ricardo Moran <[hidden email]>
writes:

Unfortunately, this version of Physical Etoys only works in
Windows. We are currently working on supporting Linux (especially the
Sugar platform) so stay tuned for future releases!

Please keep support for Mac OS X in mind, too (I use 10.5.8 Leopard
(PPC))!

-- Benjamin L. Russell
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland

Bert Freudenberg

Re: Physical Etoys released!

In reply to this post by Ricardo Moran

On 05.03.2010, at 20:27, Ricardo Moran wrote:

>
> On Thu, Mar 4, 2010 at 9:23 AM, Bert Freudenberg <[hidden email]> wrote:
>> On 03.03.2010, at 00:42, Ricardo Moran wrote:
>>> I might be missing something obvious here, but why is FFI forbidden in Etoys? Is it a matter of security?
>>
>> Yes. One of the advantages of having a Virtual Machine is that you can be quite sure what the code running in it can and can not do. It has a pretty narrow interface to the "outer system". By allowing FFI that interface widens to all the libraries on the system, which means all bets are off.
>>
>> Additionally, FFI calls are highly platform-specific, whereas Etoys projects are supposed to work on any platform.
>>
> Yes, those are very good reasons for excluding FFI from Etoys. If we write a plugin to handle the communication with the external libraries we use, would you reconsider including our work in Etoys? (now that I think of it, we will probably have some license issues... I will have to check that).
> Anyway, I think you can include the Arduino and SqueakNxt projects, they don't use FFI at all, only the SerialPlugin. Would that be ok?
> I must say, I would really love to see our projects included in Etoys!

I'd love to see more ways to connect Etoys with the real world. We integrated WorldStethoscope support already, and there is Joystick support, the camera works on some machines etc. We have the ScratchPlugin which would allow to connect to the ScratchBoard, and the Etoys code for this is sitting in a ticket already.

Now I can't promise to take your code in before having looked at it, and I'm not the only one deciding that, but we're certainly going to consider it :)

- Bert -

Ricardo Moran

Re: Physical Etoys released!

Hi Bert,

I split the Arduino and SqueakNxt packages on SqueakSource so that the Etoys code wouldn't get mixed with the core classes that manage communication with the devices. I also added a few comments and I translated the spanish comments so that you find the code easier to understand.

For Arduino, you will find the following packages:

* ArduinoCore (http://www.squeaksource.com/ArduinoCore/)

* ArduinoEtoys (http://www.squeaksource.com/ArduinoEtoys/)

* ArduinoCompiler (http://www.squeaksource.com/ArduinoCompiler/) - This is the only package that needs FFI, I use it to automatically upload Firmata into the Arduino board. This package is not required but it makes life easier.

For SqueakNxt, you will find the following packages:

* SqueakNxtCore (http://www.squeaksource.com/SqueakNxtCore/)

* SqueakNxtEtoys (http://www.squeaksource.com/SqueakNxtEtoys/)

I removed all the remaining references to FFI (we used to have a dll to handle the nxt communication but now we only use serial ports) and I'm working on improving the nxt code to fix a few bugs regarding the sensors info.

Anyway, if you look at the code, please send me back what you think. I'm looking forward to learn from your code critics.

Thanks for the interest!

Richo

On Fri, Mar 5, 2010 at 7:38 PM, Bert Freudenberg <[hidden email]> wrote:

On 05.03.2010, at 20:27, Ricardo Moran wrote:
>
> On Thu, Mar 4, 2010 at 9:23 AM, Bert Freudenberg <[hidden email]> wrote:
>> On 03.03.2010, at 00:42, Ricardo Moran wrote:
>>> I might be missing something obvious here, but why is FFI forbidden in Etoys? Is it a matter of security?
>>
>> Yes. One of the advantages of having a Virtual Machine is that you can be quite sure what the code running in it can and can not do. It has a pretty narrow interface to the "outer system". By allowing FFI that interface widens to all the libraries on the system, which means all bets are off.
>>
>> Additionally, FFI calls are highly platform-specific, whereas Etoys projects are supposed to work on any platform.
>>
> Yes, those are very good reasons for excluding FFI from Etoys. If we write a plugin to handle the communication with the external libraries we use, would you reconsider including our work in Etoys? (now that I think of it, we will probably have some license issues... I will have to check that).
> Anyway, I think you can include the Arduino and SqueakNxt projects, they don't use FFI at all, only the SerialPlugin. Would that be ok?
> I must say, I would really love to see our projects included in Etoys!

I'd love to see more ways to connect Etoys with the real world. We integrated WorldStethoscope support already, and there is Joystick support, the camera works on some machines etc. We have the ScratchPlugin which would allow to connect to the ScratchBoard, and the Etoys code for this is sitting in a ticket already.

Now I can't promise to take your code in before having looked at it, and I'm not the only one deciding that, but we're certainly going to consider it :)

- Bert -

Bert Freudenberg

Re: [etoys-dev] Re: [squeak-dev] Re: Physical Etoys released!

On 12.03.2010, at 22:23, Ricardo Moran wrote:

Hi Bert,

I split the Arduino and SqueakNxt packages on SqueakSource so that the Etoys code wouldn't get mixed with the core classes that manage communication with the devices. I also added a few comments and I translated the spanish comments so that you find the code easier to understand.

For Arduino, you will find the following packages:
* ArduinoCore (http://www.squeaksource.com/ArduinoCore/)
* ArduinoEtoys (http://www.squeaksource.com/ArduinoEtoys/)

* ArduinoCompiler (http://www.squeaksource.com/ArduinoCompiler/) - This is the only package that needs FFI, I use it to automatically upload Firmata into the Arduino board. This package is not required but it makes life easier.

For SqueakNxt, you will find the following packages:
* SqueakNxtCore (http://www.squeaksource.com/SqueakNxtCore/)
* SqueakNxtEtoys (http://www.squeaksource.com/SqueakNxtEtoys/)

I removed all the remaining references to FFI (we used to have a dll to handle the nxt communication but now we only use serial ports) and I'm working on improving the nxt code to fix a few bugs regarding the sensors info.

Anyway, if you look at the code, please send me back what you think. I'm looking forward to learn from your code critics.

Thanks for the interest!

Richo

Sounds cool. Why did you create that many repositories? Why not just one "Arduino" and one "SqueakNxt" repository? Or even just one "PhysicalEtoys" repo. Typically you put all the packages belonging to one project in the same repository.

- Bert -