Hello, and a few suggestions
AndrewHolt
I have just discovered retro, and as a long time Forth user it looks
interesting.
I have a couple of suggestions for new 'features' and would welcome
your comment & advice on the best way to implement these (if you think
they make sense).
1. (Really simple) add a --help switch to display usage
2. (Simple) Have a default location, and an environment variable for
the image file, so the search order would go:
--image
env variable
default location
3. The ability to make use of system libraries. e.g. dlopen, dlcose,
dlsym, dlcall.
I plan to become a more conversant with the language and then do some
simple benchmarks to get a feel for performance. It's small footprint
makes it a candidate for use in an embedded system (already running on
ARM linux)
Regards,
Andrew
Charles Childers
On Jan 17, 2012, at 2:41 AM, AndrewHolt <andrew...@yahoo.co.uk> wrote:
> Hi,
>
> I have just discovered retro, and as a long time Forth user it looks
> interesting.
>
> I have a couple of suggestions for new 'features' and would welcome
> your comment & advice on the best way to implement these (if you think
> they make sense).
>
> 1. (Really simple) add a --help switch to display usage
I've added this to the C implementation and will also add it to the other implementations that accept command line arguments.
> 2. (Simple) Have a default location, and an environment variable for
> the image file, so the search order would go:
> --image
> env variable
> default location
This is a very good idea. I should be able to add it later this week. Any recommendations for the environment variable name?
> 3. The ability to make use of system libraries. e.g. dlopen, dlcose,
> dlsym, dlcall.
And this is a hard one. I'm not opposed to it (though I personally don't need it), but I haven't figured out a way to implement it in a clean manner.
>
> I plan to become a more conversant with the language and then do some
> simple benchmarks to get a feel for performance. It's small footprint
> makes it a candidate for use in an embedded system (already running on
> ARM linux)
>
I'm very interested in using Retro on embedded devices. I'm working with an mbed (ARM-based board w/32k RAM, mbed.org) and Oleksandr is running Retro on an Arduino Mega.
> Regards,
> Andrew
>
> --
> --
> You received this message because you are RETRO 10 discussion group.
> To post to this group, send email to retr...@googlegroups.com
> To unsubscribe from this group, send email to retro-10-u...@googlegroups.com
-- crc
Andrew Holt
See below ...
On 25 Jan 2012, at 16:20, Charles Childers wrote:
> Hi Andrew,
>
>
>
> On Jan 17, 2012, at 2:41 AM, AndrewHolt <andrew...@yahoo.co.uk> wrote:
>
>> Hi,
>>
>> I have just discovered retro, and as a long time Forth user it looks
>> interesting.
>>
>> I have a couple of suggestions for new 'features' and would welcome
>> your comment & advice on the best way to implement these (if you think
>> they make sense).
>>
>> 1. (Really simple) add a --help switch to display usage
>
> I've added this to the C implementation and will also add it to the other implementations that accept command line arguments.
OK
>
>> 2. (Simple) Have a default location, and an environment variable for
>> the image file, so the search order would go:
>> --image
>> env variable
>> default location
>
> This is a very good idea. I should be able to add it later this week. Any recommendations for the environment variable name?
As an experiment I did this anyway :) I chose RETROIMAGE it the contents were the path and file name.
>
>> 3. The ability to make use of system libraries. e.g. dlopen, dlcose,
>> dlsym, dlcall.
>
> And this is a hard one. I'm not opposed to it (though I personally don't need it), but I haven't figured out a way to implement it in a clean manner.
It’s useful on linux systems things like sockets etc
>
>>
>> I plan to become a more conversant with the language and then do some
>> simple benchmarks to get a feel for performance. It's small footprint
>> makes it a candidate for use in an embedded system (already running on
>> ARM linux)
>>
>
> I'm very interested in using Retro on embedded devices. I'm working with an mbed (ARM-based board w/32k RAM, mbed.org) and Oleksandr is running Retro on an Arduino Mega.
That’s interesting. I’ll take a look at the source but I’m curious as to how you address the hardware.
BTW do you have an SVN or git repository, then I get get the bleeding edge code :)
Regards,
Andrew
Charles Childers
On Jan 25, 2012, at 11:27 AM, Andrew Holt <andrew...@yahoo.co.uk> wrote:
> Hi Charles,
>
> See below ...
>
> On 25 Jan 2012, at 16:20, Charles Childers wrote:
>
>> Hi Andrew,
>>
>>
>>
>> On Jan 17, 2012, at 2:41 AM, AndrewHolt <andrew...@yahoo.co.uk> wrote:
>>
>>> Hi,
>>>
>>> I have just discovered retro, and as a long time Forth user it looks
>>> interesting.
>>>
>>> I have a couple of suggestions for new 'features' and would welcome
>>> your comment & advice on the best way to implement these (if you think
>>> they make sense).
>>>
>>> 1. (Really simple) add a --help switch to display usage
>>
>> I've added this to the C implementation and will also add it to the other implementations that accept command line arguments.
>
> OK
>
>>
>>> 2. (Simple) Have a default location, and an environment variable for
>>> the image file, so the search order would go:
>>> --image
>>> env variable
>>> default location
>>
>> This is a very good idea. I should be able to add it later this week. Any recommendations for the environment variable name?
>
> As an experiment I did this anyway :) I chose RETROIMAGE it the contents were the path and file name.
Can you send me the code or a patch?
>>
>>> 3. The ability to make use of system libraries. e.g. dlopen, dlcose,
>>> dlsym, dlcall.
>>
>> And this is a hard one. I'm not opposed to it (though I personally don't need it), but I haven't figured out a way to implement it in a clean manner.
>
> It’s useful on linux systems things like sockets etc
I do have a VM implementation with support for sockets...
>>
>>>
>>> I plan to become a more conversant with the language and then do some
>>> simple benchmarks to get a feel for performance. It's small footprint
>>> makes it a candidate for use in an embedded system (already running on
>>> ARM linux)
>>>
>>
>> I'm very interested in using Retro on embedded devices. I'm working with an mbed (ARM-based board w/32k RAM, mbed.org) and Oleksandr is running Retro on an Arduino Mega.
>
> That’s interesting. I’ll take a look at the source but I’m curious as to how you address the hardware.
The mbed has libraries for interfacing with the IO pins; I've mapped the basic read/write operations into Retro's VM and have done some limited tests.
>
> BTW do you have an SVN or git repository, then I get get the bleeding edge code :)
>
No SVN or git; development is in a bzr repo (see https://code.launchpad.net/retro-language). I'm planning to setup a git mirror in the near future.
Simon Waite
<charles....@gmail.com> wrote:
> On Jan 17, 2012, at 2:41 AM, AndrewHolt <andrew...@yahoo.co.uk> wrote:
>> 2. (Simple) Have a default location, and an environment variable for
>> the image file, so the search order would go:
>> --image
>> env variable
>> default location
>
> This is a very good idea. I should be able to add it later this week. Any recommendations for the environment variable name?
$RETRO
$RETRO_IMAGE
$RETROIMG
>> 3. The ability to make use of system libraries. e.g. dlopen, dlcose,
>> dlsym, dlcall.
>
> And this is a hard one. I'm not opposed to it (though I personally don't need it), but I haven't figured out a way to implement it in a clean manner.
<devils_advocate>What about non-native foreign functions?</devils_advocate>
Perhaps having a look at scheme/lisp FFIs? Things along the line of
.NETs pinvoke and javas JNI might be overkill tho.
I've not looked at retro since I did the .NET port from Java many
moons ago, so feel free to discard my two cents
--
Earth. What a planet. On Earth, you enjoy eating a tasty clam. On my
planet, clams enjoy eating a tasty you.
-Dr ZoidBerg
Andrew Holt
See below .....
On 25 Jan 2012, at 16:33, Charles Childers wrote:
>
>
>
>
> On Jan 25, 2012, at 11:27 AM, Andrew Holt <andrew...@yahoo.co.uk> wrote:
>
>> Hi Charles,
>>
>> See below ...
>>
>> On 25 Jan 2012, at 16:20, Charles Childers wrote:
>>
>>> Hi Andrew,
>>>
>>>
>>>
>>> On Jan 17, 2012, at 2:41 AM, AndrewHolt <andrew...@yahoo.co.uk> wrote:
>>>
>>>> Hi,
>>>>
>>>> I have just discovered retro, and as a long time Forth user it looks
>>>> interesting.
>>>>
>>>> I have a couple of suggestions for new 'features' and would welcome
>>>> your comment & advice on the best way to implement these (if you think
>>>> they make sense).
>>>>
>>>> 1. (Really simple) add a --help switch to display usage
>>>
>>> I've added this to the C implementation and will also add it to the other implementations that accept command line arguments.
>>
>> OK
>>
>>>
>>>> 2. (Simple) Have a default location, and an environment variable for
>>>> the image file, so the search order would go:
>>>> --image
>>>> env variable
>>>> default location
>>>
>>> This is a very good idea. I should be able to add it later this week. Any recommendations for the environment variable name?
>>
>> As an experiment I did this anyway :) I chose RETROIMAGE it the contents were the path and file name.
>
> Can you send me the code or a patch?
I’ve just cloned the git repository. I’ll apply my changes, after I have tidied them up :) and mail you the modified file, if that’s OK ?
>
>>>
>>>> 3. The ability to make use of system libraries. e.g. dlopen, dlcose,
>>>> dlsym, dlcall.
>>>
>>> And this is a hard one. I'm not opposed to it (though I personally don't need it), but I haven't figured out a way to implement it in a clean manner.
>>
>> It’s useful on linux systems things like sockets etc
>
> I do have a VM implementation with support for sockets...
I’ll take a look.
>
>>>
>>>>
>>>> I plan to become a more conversant with the language and then do some
>>>> simple benchmarks to get a feel for performance. It's small footprint
>>>> makes it a candidate for use in an embedded system (already running on
>>>> ARM linux)
>>>>
>>>
>>> I'm very interested in using Retro on embedded devices. I'm working with an mbed (ARM-based board w/32k RAM, mbed.org) and Oleksandr is running Retro on an Arduino Mega.
>>
>> That’s interesting. I’ll take a look at the source but I’m curious as to how you address the hardware.
>
> The mbed has libraries for interfacing with the IO pins; I've mapped the basic read/write operations into Retro's VM and have done some limited tests.
I’m still finding my way around retro but how about a library, say called hardware’ which has functions such as:
@ addr -- data Read a 32 bit value from the physical address
w@ addr -- data Read a 16 bit value . . . . .
c@ addr -- data Read an 8 bit value . . . .
! data adr -- Write a 32 bit value to . . . .
You get the idea :)
Regards,
Andrew
Andrew Holt
On 25 Jan 2012, at 16:34, Simon Waite wrote:
>>>
>>> 3. The ability to make use of system libraries. e.g. dlopen, dlcose,
>>> dlsym, dlcall.
>>
>> And this is a hard one. I'm not opposed to it (though I personally don't need it), but I haven't figured out a way to implement it in a clean manner.
>
> <devils_advocate>What about non-native foreign functions?</devils_advocate>
>
> Perhaps having a look at scheme/lisp FFIs? Things along the line of
> .NETs pinvoke and javas JNI might be overkill tho.
>
> I've not looked at retro since I did the .NET port from Java many
> moons ago, so feel free to discard my two cents
Another way to do this is to make use of a portable IPC/messaging ‘bus’ something like D-Bus, or (my personal favourite) Spread. So if there is a service you want to make use of you wrap it in a small daemon, define a simple protocol and away you go. I know that this imposes overhead and will be slower than using the standard API, but it nicely decouples retro from the libraries, and also make the library accessible from other apps. As an aside spread also works over the network. So a service running on one machine can be made use of by another, useful if the client is a little ARM board & the server is .... bigger :)
Regards,
Andrew
Simon Waite
>> <devils_advocate>What about non-native foreign functions?</devils_advocate>
>>
>> Perhaps having a look at scheme/lisp FFIs? Things along the line of
>> .NETs pinvoke and javas JNI might be overkill tho.
>>
>> I've not looked at retro since I did the .NET port from Java many
>> moons ago, so feel free to discard my two cents
>
> Another way to do this is to make use of a portable IPC/messaging ‘bus’ something like D-Bus, or (my personal favourite) Spread. So if there is a service you want to make use of you wrap it in a small daemon, define a simple protocol and away you go. I know that this imposes overhead and will be slower than using the standard API, but it nicely decouples retro from the libraries, and also make the library accessible from other apps. As an aside spread also works over the network. So a service running on one machine can be made use of by another, useful if the client is a little ARM board & the server is .... bigger :)
Hmm, spread looks interesting ... might not make sense on an ardiuno
though. Bookmarked for later reading - Thanks :)
Andrew Holt
Indeed, but if the Arduino is talking to a bigger box, perhaps over a serial line, then a process listening to the tty and forwarding the messages to spread might be useful. These days most of the kit I use is large enough to run Linux (Beagle etc).
Regards,
Andrew
>
> --
> Earth. What a planet. On Earth, you enjoy eating a tasty clam. On my
> planet, clams enjoy eating a tasty you.
> -Dr ZoidBerg
>
Simon Waite
> Hi,
>
>
> On 26 Jan 2012, at 10:43, Simon Waite wrote:
>
>> On Thu, Jan 26, 2012 at 10:38, Andrew Holt <andrew...@yahoo.co.uk> wrote:
>>
>>>> <devils_advocate>What about non-native foreign functions?</devils_advocate>
>>>>
>>>> Perhaps having a look at scheme/lisp FFIs? Things along the line of
>>>> .NETs pinvoke and javas JNI might be overkill tho.
>>>>
>>>> I've not looked at retro since I did the .NET port from Java many
>>>> moons ago, so feel free to discard my two cents
>>>
>>> Another way to do this is to make use of a portable IPC/messaging ‘bus’ something like D-Bus, or (my personal favourite) Spread. So if there is a service you want to make use of you wrap it in a small daemon, define a simple protocol and away you go. I know that this imposes overhead and will be slower than using the standard API, but it nicely decouples retro from the libraries, and also make the library accessible from other apps. As an aside spread also works over the network. So a service running on one machine can be made use of by another, useful if the client is a little ARM board & the server is .... bigger :)
>>
>> Hmm, spread looks interesting ... might not make sense on an ardiuno
>> though. Bookmarked for later reading - Thanks :)
>
> Indeed, but if the Arduino is talking to a bigger box, perhaps over a serial line, then a process listening to the tty and forwarding the messages to spread might be useful. These days most of the kit I use is large enough to run Linux (Beagle etc).
>
A good point well made!
Charles Childers
Very much so. I've applied the patch and pushed it to the repository. Thanks!
-- crc
Andrew Holt
Well that’s the simple things on my list :)
In my ‘copious free time’ :) I’m going to add the ability to use spread. So that’s (aprox) 6 new functions, connect, disconnect, join, leave, send, receive. I guess the best way to be to modify the vm (I’ll create one in vm/experimental called retro-spread.c) and add a library (called spread’).
Does that sound like a good way to proceed ?
Regards,
Andrew
Andrew Holt
I managed to find a few hours today. I am impressed by how easy it is to add new functionality.
I now have a first cut at the spread code. I will create some docs and some sample/test code and if you can tell me how I can best send that to you.
Regards,
Andrew
Charles Childers
On Fri, Jan 27, 2012 at 12:22 PM, Andrew Holt <andrew...@yahoo.co.uk> wrote:
> Hi,
>
> I managed to find a few hours today. I am impressed by how easy it is to add new functionality.
Thanks. I've tried to keep things clean enough to be easily extended
for specific needs.
> I now have a first cut at the spread code. I will create some docs and some sample/test code and if you can tell me how I can best send that to you.
If your git repository is somewhere public, I can clone it and merge
the changes into my repo. If not, email the files and any instructions
on their placement within the tree to me and I'll add them to my
source tree.
-- crc