Re: GPIO and timer interrupts for AVR32

[Martin Guy]

Hi, I'm incuding the list in this, as it regards a user-visible change

On 30 November 2011 08:54, Bogdan Marinescu <[hidden email]> wrote:

> On Wed, Nov 30, 2011 at 8:38 AM, Martin Guy <[hidden email]> wrote:
>> Hi again. I've fixed some breakage in the timer interface:
>>
>> > tmr.delay(0, 500000)
>> stdin:1: timer 500000 does not exist
>>  - two params got swapped in one commit.
>
> They're not swapped, the API was changed. This was announced on the list:
>
> http://elua-development.2368040.n2.nabble.com/IMPORTANT-New-feature-on-the-master-branch-system-timer-td6918200.html
>
> I also updated the documentation with this information.

Ah. My mistake, sorry.

Can I suggest rethinking that change in a way that lets existing code
continue to work, and lets people's existing knowledge of eLua
continue to be valid?
Swapping the parameters round has a high short-term cost in
user-surprise and long-term makes it impossible to write portable eLua
code, since tmr.delay() becomes unusable.

In general, optional parameters are not at attractive as they seem, as
they only lets you have one optional parameter per function (or a
series of them where each one's optionality depends on the previous
one being present).

How about, instead of

tmr.delay(id, delay) -> timer.delay(delay, [id])

use

tmr.delay(id, delay) -> timer.delay(id, delay)

where id may be nil to mean "you choose", or to mirror the rest of the
timer-choice structure by defining tmr.SYS or .SYSTEM or .SYSTICK or
something?

   M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Wed, Nov 30, 2011 at 5:06 PM, Martin Guy <[hidden email]> wrote:

Hi, I'm incuding the list in this, as it regards a user-visible change

On 30 November 2011 08:54, Bogdan Marinescu <[hidden email]> wrote:
> On Wed, Nov 30, 2011 at 8:38 AM, Martin Guy <[hidden email]> wrote:
>> Hi again. I've fixed some breakage in the timer interface:
>>
>> > tmr.delay(0, 500000)
>> stdin:1: timer 500000 does not exist
>>  - two params got swapped in one commit.
>
> They're not swapped, the API was changed. This was announced on the list:
>
> http://elua-development.2368040.n2.nabble.com/IMPORTANT-New-feature-on-the-master-branch-system-timer-td6918200.html
>
> I also updated the documentation with this information.

Ah. My mistake, sorry.

Can I suggest rethinking that change in a way that lets existing code
continue to work, and lets people's existing knowledge of eLua
continue to be valid?
Swapping the parameters round has a high short-term cost in
user-surprise and long-term makes it impossible to write portable eLua
code, since tmr.delay() becomes unusable.

In general, optional parameters are not at attractive as they seem, as
they only lets you have one optional parameter per function (or a
series of them where each one's optionality depends on the previous
one being present).

How about, instead of

tmr.delay(id, delay) -> timer.delay(delay, [id])

use

tmr.delay(id, delay) -> timer.delay(id, delay)

where id may be nil to mean "you choose", or to mirror the rest of the
timer-choice structure by defining tmr.SYS or .SYSTEM or .SYSTICK or
something?

I understand what you're suggesting, but the whole idea of a system timer was to allow people to worry about timer IDs as little as possible. Therefore it seemed like a good idea to make them not only have default values, but also completely optional.

Also, please note that until eLua 1.0 the API is volatile and quite likely to change (if you think this is bad, wait until you see the new TCP/IP stack :) ). This was mentioned on the list a number of times, we should probably make it explicit on the main project page too. I think it is unavoidable, as we learn from our mistakes the API changes are bound to happen sooner or later. This is of course also true after 1.0, but at that point we'll make sure that we'll provide a compatibility layer with the old API for a while (a simple depreciation mechanism). Until 1.0 we get a bit more liberty for playing with the API, starting from the assumption that it is not too mature yet and that our projects/user base are still reasonably small and thus these kind of changes are unlikely to require a large development effort on our user side.

Best,

Bogdan

  M

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Dado Sutter]

Hi,

On Wed, Nov 30, 2011 at 13:19, Bogdan Marinescu <[hidden email]> wrote:

On Wed, Nov 30, 2011 at 5:06 PM, Martin Guy <[hidden email]> wrote:

Hi, I'm incuding the list in this, as it regards a user-visible change

On 30 November 2011 08:54, Bogdan Marinescu <[hidden email]> wrote:
> On Wed, Nov 30, 2011 at 8:38 AM, Martin Guy <[hidden email]> wrote:
>> Hi again. I've fixed some breakage in the timer interface:
>>
>> > tmr.delay(0, 500000)
>> stdin:1: timer 500000 does not exist
>>  - two params got swapped in one commit.
>
> They're not swapped, the API was changed. This was announced on the list:
>
> http://elua-development.2368040.n2.nabble.com/IMPORTANT-New-feature-on-the-master-branch-system-timer-td6918200.html
>
> I also updated the documentation with this information.

Ah. My mistake, sorry.

Can I suggest rethinking that change in a way that lets existing code
continue to work, and lets people's existing knowledge of eLua
continue to be valid?
Swapping the parameters round has a high short-term cost in
user-surprise and long-term makes it impossible to write portable eLua
code, since tmr.delay() becomes unusable.

In general, optional parameters are not at attractive as they seem, as
they only lets you have one optional parameter per function (or a
series of them where each one's optionality depends on the previous
one being present).

How about, instead of

tmr.delay(id, delay) -> timer.delay(delay, [id])

use

tmr.delay(id, delay) -> timer.delay(id, delay)

where id may be nil to mean "you choose", or to mirror the rest of the
timer-choice structure by defining tmr.SYS or .SYSTEM or .SYSTICK or
something?

I understand what you're suggesting, but the whole idea of a system timer was to allow people to worry about timer IDs as little as possible. Therefore it seemed like a good idea to make them not only have default values, but also completely optional.

Also, please note that until eLua 1.0 the API is volatile and quite likely to change (if you think this is bad, wait until you see the new TCP/IP stack :) ). This was mentioned on the list a number of times, we should probably make it explicit on the main project page too. I think it is unavoidable, as we learn from our mistakes the API changes are bound to happen sooner or later. This is of course also true after 1.0, but at that point we'll make sure that we'll provide a compatibility layer with the old API for a while (a simple depreciation mechanism). Until 1.0 we get a bit more liberty for playing with the API, starting from the assumption that it is not too mature yet and that our projects/user base are still reasonably small and thus these kind of changes are unlikely to require a large development effort on our user side.

Yep.
I know this can be annoying to early users and (specially) for bleeding-edge commercial uses, like Martin's and SimpleMachine's (Mizar32). But this is the main reason we don't call any of our versions v1.0 yet.
The right time to discuss and refine the API, as Martin and others are doing, is now.
And as Bogdan's mentioned, this is likely to happen even after v1.0, less often but probably. We'll then do our best not to break legacy code. This happens with Lua (and mostly everything else) too.
To make this clear on our main doc/site is a good idea. I actually think this is written somewhere but not highlighted as we can see now.


Dado

 

Best,

Bogdan

  M

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jbsnyder]

I think one thing we could clearly do better on is getting "dev" revision docs posted to the site. API changes cause confusion, but especially so when the information we put front and center on how to use the platform are outdated.

Regarding the timers:

1) the only major thing that has been a bit extra confusing was the change in ordering of parameters related to elapsed time functionality (which is start and end time?). It would be kind of nice if we could just do the absolute value/difference, but I think the code currently contains handling so that if the start time is in the middle of the cycle and the end time wraps at the end but doesn't pass the other time again it measures elapsed time correctly.  Even though we've already made this change this is one adjustment I would prefer:

delta = tmr.gettimediff( end, start, [id] ) -> delta = tmr.gettimediff( start, end, [id] )

2) It is inconsistent with how we use resource ids elsewhere in the project, but it also is encouraging of not using timer numbers where a specific timer resource isn't needed, and it's more compact.

I guess one other backwards compatible alternative is to have some wrappers in eLua that provide shorthand for the system timer (like tmr.delay(tmr.SYS_TIMER,1e6) (under older style) becomes tmr.sys.delay(1e6). That would grow our code a little bit if we implement this using a metatable index function.

There wasn't a huge amount of feedback suggesting changes when this was originally brought in, so I'm not sure how other users feel aside from some irritation at docs matching v0.8 and not the current dev release (we'll try and get this corrected in the near future).

-jsnyder

--

James Snyder

Biomedical Engineering

Northwestern University

http://fanplastic.org/key.txt

ph: <a href="tel:%28847%29%20448-0386" value="[phone]" target="_blank">[phone]

On Nov 30, 2011, at 9:19, Bogdan Marinescu <[hidden email]> wrote:

On Wed, Nov 30, 2011 at 5:06 PM, Martin Guy <[hidden email]> wrote:

Hi, I'm incuding the list in this, as it regards a user-visible change

On 30 November 2011 08:54, Bogdan Marinescu <[hidden email]> wrote:
> On Wed, Nov 30, 2011 at 8:38 AM, Martin Guy <[hidden email]> wrote:
>> Hi again. I've fixed some breakage in the timer interface:
>>
>> > tmr.delay(0, 500000)
>> stdin:1: timer 500000 does not exist
>>  - two params got swapped in one commit.
>
> They're not swapped, the API was changed. This was announced on the list:
>
> http://elua-development.2368040.n2.nabble.com/IMPORTANT-New-feature-on-the-master-branch-system-timer-td6918200.html
>
> I also updated the documentation with this information.

Ah. My mistake, sorry.

Can I suggest rethinking that change in a way that lets existing code
continue to work, and lets people's existing knowledge of eLua
continue to be valid?
Swapping the parameters round has a high short-term cost in
user-surprise and long-term makes it impossible to write portable eLua
code, since tmr.delay() becomes unusable.

In general, optional parameters are not at attractive as they seem, as
they only lets you have one optional parameter per function (or a
series of them where each one's optionality depends on the previous
one being present).

How about, instead of

tmr.delay(id, delay) -> timer.delay(delay, [id])

use

tmr.delay(id, delay) -> timer.delay(id, delay)

where id may be nil to mean "you choose", or to mirror the rest of the
timer-choice structure by defining tmr.SYS or .SYSTEM or .SYSTICK or
something?

I understand what you're suggesting, but the whole idea of a system timer was to allow people to worry about timer IDs as little as possible. Therefore it seemed like a good idea to make them not only have default values, but also completely optional.

Also, please note that until eLua 1.0 the API is volatile and quite likely to change (if you think this is bad, wait until you see the new TCP/IP stack :) ). This was mentioned on the list a number of times, we should probably make it explicit on the main project page too. I think it is unavoidable, as we learn from our mistakes the API changes are bound to happen sooner or later. This is of course also true after 1.0, but at that point we'll make sure that we'll provide a compatibility layer with the old API for a while (a simple depreciation mechanism). Until 1.0 we get a bit more liberty for playing with the API, starting from the assumption that it is not too mature yet and that our projects/user base are still reasonably small and thus these kind of changes are unlikely to require a large development effort on our user side.

Best,

Bogdan

  M

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev