Alcor6L software updates

[Martin Guy]

hi All
I see Raman has been busy again, adding tinyscheme, so now Lua,
PicoC, PicoLisp, MyBASIC and tiny scheme all run on the Mizar32.
That leaves one language for the magic 6. I'd like a Forth, for its
diversity and long history of use in embedded systems, but don't have
the time or enthusiasm to do a port.
An alternative is a pure functional language, but Hugs, the standard
Haskell interpreter, is too big, leaving it predecessors, KRC and
Miranda, whose interpreter source code I am seeking. There may be
others (Hope? Ocaml? Erlang?)
Binaries of the first four languages in various flavours are visibile under
http://simplemachines.it/downloads/Alcor6L:

Flash according to the instructions in
http://en.wikibooks.org/wiki/Mizar32/Flashing_firmware

Alcor6L_lua_fp_at32uc3a0256.elf
Alcor6L_lua_fp_at32uc3a0256.hex
Alcor6L_lua_long_at32uc3a0256.elf
Alcor6L_lua_long_at32uc3a0256.hex
Alcor6L_lua_longlong_at32uc3a0256.elf
Alcor6L_lua_longlong_at32uc3a0256.hex
Alcor6L_mybasic_fp_at32uc3a0256.elf
Alcor6L_mybasic_fp_at32uc3a0256.hex
Alcor6L_picoc_fp_at32uc3a0256.elf
Alcor6L_picoc_fp_at32uc3a0256.hex
Alcor6L_picoc_long_at32uc3a0256.elf
Alcor6L_picoc_long_at32uc3a0256.hex
Alcor6L_picolisp_fp_at32uc3a0256.elf
Alcor6L_picolisp_fp_at32uc3a0256.hex

@Raman, can we rename the binaries like this in the builder, with
build date included?

M

[Martin Guy]

On 28/09/2013, Martin Guy <marti...@gmail.com> wrote:
> Alcor6L_lua_long_at32uc3a0256.elf

> @Raman, can we rename the binaries like this in the builder, with
> build date included?

Anzi.

Alcor6L_eLua_long_at32uc3a0256_20130817.elf

?

M

[Raman Gopalan]

Dear Martin, dear List,

>    I see Raman has been busy again, adding tinyscheme, so now Lua,
> PicoC, PicoLisp, MyBASIC and tiny scheme all run on the Mizar32.
>   That leaves one language for the magic 6.

There are many interesting languages/virtual machines that can run on
Mizar32. I hope we don't stay at 6. List: Just a thought - Can we change
the significance of 6 to paradigms instead of languages? :)

> I'd like a Forth, for its

I've been looking around for a nice Forth implementation. We will have

a Forth soon. If you have a specific preference/implementation, please

give me your suggestion; We could start hacking on it.

> An alternative is a pure functional language, but Hugs, the standard
> Haskell interpreter, is too big, leaving it predecessors, KRC and
> Miranda, whose interpreter source code I am seeking. There may be
> others (Hope? Ocaml? Erlang?)

Ocaml, Erlang - interesting. I was able to compile Hugs for Mizar32
(SMALL_HUGS mode with changes in the code base). It reaches a
point where it loads Prelude.hs from /mmc and crashes. I'm debugging

this. But as Martin said it is very big. It takes away 88% - 90% of
flash on Mizar32 A.

>    Binaries of the first four languages in various flavours are visibile under
> http://simplemachines.it/downloads/Alcor6L:

Martin: Thank you very much for putting the binaries up.

> @Raman, can we rename the binaries like this in the builder, with
> build date included?

Certainly Martin. I'll include this in SConstruct.

Best,
Raman

    M

--
You received this message because you are subscribed to the Google Groups "Mizar32" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mizar32+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Martin Guy]

n 02/10/2013, Raman Gopalan <ramang...@gmail.com> wrote:
>> I see Raman has been busy again, adding tinyscheme, so now Lua,
>> PicoC, PicoLisp, MyBASIC and tiny scheme all run on the Mizar32.
>> That leaves one language for the magic 6.
>
> There are many interesting languages/virtual machines that can run on
> Mizar32. I hope we don't stay at 6. List: Just a thought - Can we change
> the significance of 6 to paradigms instead of languages? :)

Of course, but see below for a possible workflow to avoid eternal
development never released...

>> I'd like a Forth, for its

> If you have a specific preference/implementation, please
> give me your suggestion

I have no preferences, and I think you are the best judge of the
suitability of different implementations.

>> An alternative is a pure functional language, but Hugs, the standard
>> Haskell interpreter, is too big, leaving it predecessors, KRC and
>> Miranda, whose interpreter source code I am seeking.
>

> Ocaml, Erlang - interesting. I was able to compile Hugs for Mizar32
> (SMALL_HUGS mode with changes in the code base). It reaches a
> point where it loads Prelude.hs from /mmc and crashes. I'm debugging
> this. But as Martin said it is very big. It takes away 88% - 90% of
> flash on Mizar32 A

Excellent news, I didn't think it would fit at all, having seen that
the x86 binary is 785K of compiled code, without counting the
libraries that it uses. Well done!

>> Binaries of the first four languages in various flavours are visibile
> under

>> http://simplemachines.it/downloads/Alcor6L<http://simplemachines.it/downloads/Alcor6L>

> Martin: Thank you very much for putting the binaries up.

Not at all the "release" I promised you! That turned out to be too
much work, so for the moment I can put up a monthly compile of the
binaries.

>> @Raman, can we rename the binaries like this in the builder, with
>> build date included?
> Certainly Martin. I'll include this in SConstruct.

Thanks. That makes release management abd version tracking much easier.

On a different topic, there is an interesting problem to solve with
pure functional languages.
All of Alcor6L's current languages, including the functional ones,
handle the devices by supplying functions which, when you call them,
either have some side-effect on an I/O device as a side effect of what
they do, or their return value depends on the current state of some
input pin or I/O device.
In pure functional languages, a function cannot have side effects:
its return value depends ONLY on the function's code and the
parameters supplied at runtime, and cannot be different depending on
the voltage on some input pin.
Similarly, the only thing a pure function does is return a result:
it cannot have the additional effect of twiddling an output pin.
These concepts are essential to pure functional languages: if you call
the same function twice with the same parameters, it is free to
execute once and return you the same result twice. In fact, the
functions are not "evaluted" as in other languages: they are rewritten
at runtime, so add(2, 3) is rewritten as 5 the first time it is
called. As a concrete example, delay(1 second) might delay for a
second and say "yes, that worked" the first time you call it, but any
further calls would immediately return "yes, that worked" as the
function call would have been replaced by its result.
In a pure functional language, you have to work by saying: "the main
function's parameter is all the program's input, and its return value
is all program's output".
For a visual editor, for example, the input is the original file and
the keystrokes the user types, and the output is the sequence of
screen updating characters and the modified version of the file. While
the editor is running, it is driven by the need to produce output, and
that output depends on what the user types. If they type the
"delete-line" command, that input gives the main function the info it
needs to be able to generate some more output: the screen-updating
ANSI sequences to make the line in question disappear from the screen.
For something like a file-copy program that takes a filename
argument, the main program's input is the entire filesystem, and its
output is the entire (maybe modified) filesystem.

This turns out to be a huge (and automatic and unavoidable)
performance gain, as well as letting you to handle infinite-sized data
structures like "[1..]" (the list of all positive integers). However,
it also means changing the way we think about programming, which is
the hallmark of a worthwhile proramming language...

For these reasons, maybe Forth would be better as number 6, giving us
time to think about how to do pure I/O in an embedded environment...

M

[Martin Guy]

On 03/10/2013, Martin Guy <marti...@gmail.com> wrote:
> n 02/10/2013, Raman Gopalan <ramang...@gmail.com> wrote:
>>> I see Raman has been busy again, adding tinyscheme, so now Lua,
>>> PicoC, PicoLisp, MyBASIC and tiny scheme all run on the Mizar32.
>>> That leaves one language for the magic 6.
>>
>> There are many interesting languages/virtual machines that can run on
>> Mizar32. I hope we don't stay at 6. List: Just a thought - Can we change
>> the significance of 6 to paradigms instead of languages? :)
>
> Of course, but see below for a possible workflow to avoid eternal
> development never released...

Oops, missed a bit...

i wanted to suggest that, when you are happy with your choice of the
best 6 languages to include in the first release, you change direction
to completing the platform library support and the reference
documentation for those 6. That doesn't stop you experimenting with
other languages or interpreters, but creates, in project jargon, a
"target milestone", as a way of avoiding having a project that is
always being developed and never produces anything that normal people
can use.
The best guide I know on how to make the project succeed is the book
Producing Open Source Software, available at http://producingoss.com
Note particularly the first sentence of the book. "Most open source
software projects fail". Although technically Alcor6L is an
open-source software project (it's code is on github!) and works
(compiles! runs!), it's lacking many aspects to make it a successful
open source software project, in particular, missing the "Release
early, release often" aspect.
Let's work on making this a successful Open Source project by
targetting on its first release with 6 languages.

Does that sound like a good strategy?

M

[Raman Gopalan]

Dear Martin,

Firstly, I'm sorry for the delay in response. I meant to write to
you sooner.

>> Ocaml, Erlang - interesting. I was able to compile Hugs for Mizar32
>> (SMALL_HUGS mode with changes in the code base). It reaches a
>> point where it loads Prelude.hs from /mmc and crashes. I'm debugging
>> this. But as Martin said it is very big. It takes away 88% - 90% of
>> flash on Mizar32 A

> Excellent news, I didn't think it would fit at all, having seen that
> the x86 binary is 785K of compiled code, without counting the
> libraries that it uses. Well done!

Thanks Martin. That was some fun. In REGULAR_HUGS mode (slightly
bigger then the SMALL_HUGS mode), I found a .bss section overflow
by about 340 kilobytes! The third mode - LARGE_HUGS is out of the way;
it is very heavy.

I had to rewrite some of the lower level functions for SMALL_HUGS to load
Prelude.hs (among a few other files) from the memory card on Mizar32.
Because of the crashes, the way is to either debug and fix SMALL_HUGS
(I'm trying this with Valgrind) or figure out a way to optimize REGULAR_HUGS.

>>> @Raman, can we rename the binaries like this in the builder, with

>>> build date included?
>> Certainly Martin. I'll include this in SConstruct.
> Thanks. That makes release management abd version tracking much easier.

In case you haven't seen this [1] already, I've included it in SConstruct. The

date will now be appended to the binary file name.

> On a different topic, there is an interesting problem to solve with
> pure functional languages.
>   All of Alcor6L's current languages, including the functional ones,
> handle the devices by supplying functions which, when you call them,
> either have some side-effect on an I/O device as a side effect of what
> they do, or their return value depends on the current state of some

> input pin or I/O device. [...]

> For these reasons, maybe Forth would be better as number 6, giving us
> time to think about how to do pure I/O in an embedded environment...

Certainly. That would be an excellent project. So, I'll keep looking for a nice
Forth. I'll write to you as soon as I've found something interesting.

> i wanted to suggest that, when you are happy with your choice of the
> best 6 languages to include in the first release, you change direction
> to completing the platform library support and the reference
> documentation for those 6. That doesn't stop you experimenting with
> other languages or interpreters, but creates, in project jargon, a
> "target milestone", as a way of avoiding having a project that is
> always being developed and never produces anything that normal people

> can use. [...]

> Does that sound like a good strategy?

Understood and agreed Martin. Let's proceed this way.

But just a question/thought; Going by the release early, release often
strategy, could we tackle a subset of 6 first? Would it be possible to
focus on complete usable support for Lisp and C for Alcor6L first (including
the doc work) and have frequent other releases for the other languages?
(since Lisp and C started early and we have support for almost all
platform modules). I anticipate additional time requirements for the first
release if we support the first 6 (including Forth) for 0.1. What would
you recommend?

Best,
Raman

PS: Thank you very much for introducing me to the book on producing
free/open source software. I've started reading it.

Links:

[1]: https://github.com/simplemachines-italy/Alcor6L/commit/99a0261e1a6731982355444dcb90b14071456f77

[Martin Guy]

On 15/10/2013, Raman Gopalan <ramang...@gmail.com> wrote:
Because of the crashes, the way is to either debug and fix SMALL_HUGS
> (I'm trying this with Valgrind) or figure out a way to optimize
> REGULAR_HUGS.

For smallest code, use the AVR32 built using
http://spaces.atmel.com/gf/project/ct-ng/
which generates code a few percent smaller (and correcter!) than any other.
Alternatively, twiddle the size optimizer as described in the above
link at section
"Further size optimizations / Alternative inliner tuning"

>
>>>> @Raman, can we rename the binaries like this in the builder, with
>>>> build date included?

> In case you haven't seen this [1] already, I've included it in SConstruct.
> The date will now be appended to the binary file name.

Fab, thanks!

> But just a question/thought; Going by the release early, release often
> strategy, could we tackle a subset of 6 first? Would it be possible to
> focus on complete usable support for Lisp and C for Alcor6L first

Absolutely, yes.

M

[Martin Guy]

On 15/10/2013, Raman Gopalan <ramang...@gmail.com> wrote:

> support for Lisp and C for Alcor6L first
> (including the doc work)

Ah, the eLua-specific Mizar32 Quick Start Guide
https://en.wikibooks.org/wiki/Mizar32
has now been printed as a booklet, visible under
http://simplemachines.it/downloads/Mizar32
so we can now modify that for the next edition of the book.
One way to document the modules would be to add sections "PicoC view"
and "PicoLisp view" after "eLua view" in each device section, giving
examples of using the device from those languages.

M

[Sergio Sorrenti]

Hi all,

i also agree to not be stuck with only 6 Languages,

of course it was one of the reason to append to Alcor "6L"

but it seems now that supported languages will be more than 6,

also we should be open to contributors to port their preferred

interpreted language / VM on Alcor6L .

May i suggest to think at 6L as 6LoWPAN connectivity wich is
one of our target?

2013/10/15 Martin Guy <marti...@gmail.com>