On 3/13/2015 8:04 PM, Tim Wescott wrote:> On Fri, 13 Mar 2015 15:03:09 -0700, Don Y wrote: > >> Hi Tim, >> >> On 3/13/2015 2:27 PM, Tim Wescott wrote: >>> The title says most of it. >>> >>> I'm working on a project for which the customer wants a lot of >>> flexibility to customize a product. The existing "macro language" is >>> ancient (ca 1985), cryptic (it looks like machine language), limited, >>> clunky, etc. The customer is willing to change. >>> >>> I'm planning on having a chunk of serial flash (or an SD card) with a >>> file system on it (maybe FAT, maybe something home-rolled and >>> primitive). Scripts will be stored as text files, and read in as >>> appropriate. >>> >>> Rather than just use some clunky cryptic and limited language that's >>> unique to the problem and to me (and charging my customer up the wazoo >>> for it), I'd like to use something that's open-source and available. >>> Something that uses modest resources is to be preferred -- my >>> understanding is that I can expect Lua to use about 100k of flash, >>> which is a bit much for me but bearable. I don't know how Tcl compares >>> -- I just know that it's an alternative. >>> >>> So -- anyone have any direct experience with either of these, or with >>> something else? We briefly considered Java, but it just looks entirely >>> too big -- it would basically drive us to use Linux or some other >>> "real" OS (even the little linuxes are too big for my tastes) -- I'd >>> really rather just have a scripting engine that gets called whenever a >>> script needs to run, and otherwise doesn't need much hand-holding from >>> the application code. >>> >>> I'm looking for opinions, so fire away! >> > << smart-assery snipped >> >> >> As to *your* question... >> >> What sorts of things does the customer expect to *do* with those >> scripts? >> And, (besides space) what other constraints are you needing to place on >> those actions? E.g., any timeliness constraints? Performance? >> Numerical precision? etc. >> >> Who is the intended user: *just* the client? Or, will these things be >> exposed to users? >> >> What sorts of things do the scripts interact with (displays, etc.)? >> E.g., do you need to be able to manipulate a GUI without constraint? >> Or, are you just serving up text and/or canned dialogs? >> >> What sort of user input device (keyboard, keypad, etc.)? Other I/O's? >> >> I opted for a (bastardized) Limbo as my scripting language. But, I use >> it to generate "real" applications and not just automate some >> preexisting actions. However, it won't fit your memory requirements. >> >> Can you tolerate something as "crude" as a bastardized BASIC? I.e., >> add "product specific" hooks to it to address some of the special needs >> (displays, etc.) at a "native" level. A BASIC interpreter/compiler can >> be really small. >> >> The same can be said of C interpreters, mini-compilers (JIT). But, >> you'd be targeting a different class of "developer" (user). > > The product will have a character display, and it'll store text files for > later retrieval. It has a measurement thingie (I don't want to get too > specific -- but it makes measurements) that'll cough up a number when it's > actuated, and it has a sea of (well, around 100) buttons that the user can > press. > > My intention at the moment is to make the box this big dumb thing with > some system code that knows to call a function for each measurement and > button press (i.e., when the user presses button 1, the function named > "button_1" will get called if it exists). Then I'll encode the actual > functionality as a bunch of functions in the language-o-choice. > > The nice thing about this is that if a user comes up with some desired > customization (which we expect, as we're replacing an existing product for > which this was common), we can either tell them to start coding and have > fun, or we can charge them $$ to code the thing up to their specifications. > > The real driver for wanting to do this as a scripting language is to make > it easy for the user to customize. I'm imagining that some users won't > want to touch the customization with a 10 foot pole, some will be happy to > customize a button or two, some will get their feet wet and then call us, > and some will go whole hog with the thing, and do entire systems without > us even knowing it's going on.I think what you are describing is Forth. There are two commercial vendors, MPE and Forth Inc. I know the MPE license allows you to embed the "interpreter" into your product for the customer to use. There are also open source Forths around, but with varying levels of embeddability and support. One is Mecrisp which is available for a few of the many ARM processors around and the TMS430 I believe. There are many others. Forth can be idiot simple to use. The assumption is it has a serial terminal for I/O or something much like it. I/O can be redirected from/to files or anything else by using deferred words. It can run on the bare metal or under an OS. You can give as much power to your customer as you think they can handle or as little as you think is wise. I've cross posted this to the forth group to get input from some of the regulars there. Oh, about the "file system". If you are happy with no file system at all, Forth can treat your storage as "blocks" of 1 KB and no real files at all. You can't get much simpler than that. -- Rick
Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions?
Started by ●March 13, 2015
Reply by ●March 18, 20152015-03-18
Reply by ●March 18, 20152015-03-18
On Fri, 13 Mar 2015 16:27:12 -0500, Tim Wescott <seemywebsite@myfooter.really> wrote:>I'm planning on having a chunk of serial flash (or an SD card) with a file >system on it (maybe FAT, maybe something home-rolled and primitive). >Scripts will be stored as text files, and read in as appropriate. > >Rather than just use some clunky cryptic and limited language that's >unique to the problem and to me (and charging my customer up the wazoo for >it), I'd like to use something that's open-source and available.There are a number of Forth systems out there that fit the bill, including ours. A basic multi-tasking Forth system with SD card driver, FAT file system and file API layer can be done in around 32 kb of Flash on a Cortex-Mx class CPU. Note that our Forth systems are proprietary, not FOSS. Our website and contact details are below. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
Reply by ●March 18, 20152015-03-18
On Tue, 17 Mar 2015 23:32:50 -0700, Don Y <this@is.not.me.com> wrote:>On 3/17/2015 10:50 PM, George Neuner wrote: >> On Tue, 17 Mar 2015 19:36:34 -0700, Don Y <this@is.not.me.com> wrote: >> >>> I prefer real names for things instead of yet another cryptic "special >>> combination" of symbols. One of limbo's problems is it's not very >>> effective as a "read over the phone" language. (unless you preagree >>> as to how to name particular character combinations: -> <- => :: etc) >> >> I've never had to read - or listen to - code over the phone. 8-) > >You have vision. How would a blind user "see" the code? How >would I tell him what to write to solve one of his problems? > >[I've fed various sources into several different speech synthesizers, >haptic interfaces, etc. It is only then that you truly realize how much >our programming languages have come to rely on "symbols"] > >Or, do you just exclude them from that technology? :> One of the >driving motivations for my current project is accessibility -- in more >than just a "token" sense. > >As I said, you can adopt *conventions* to make what you see more >readily conveyed in (e.g., spoken) conversation. E.g., I'd never >say "colon colon equals" when reading an Algol fragment to someone...I've advocated using Victor Borge's approach. But alas, I seem not to be taken seriously...
Reply by ●March 18, 20152015-03-18
rickman wrote: [%X]>> The real driver for wanting to do this as a scripting language is to make >> it easy for the user to customize. I'm imagining that some users won't >> want to touch the customization with a 10 foot pole, some will be happy >> to customize a button or two, some will get their feet wet and then call >> us, and some will go whole hog with the thing, and do entire systems >> without us even knowing it's going on. > > I think what you are describing is Forth. There are two commercial > vendors, MPE and Forth Inc. I know the MPE license allows you to embed > the "interpreter" into your product for the customer to use. There are > also open source Forths around, but with varying levels of embeddability > and support. One is Mecrisp which is available for a few of the many > ARM processors around and the TMS430 I believe. There are many others. > > Forth can be idiot simple to use. The assumption is it has a serial > terminal for I/O or something much like it. I/O can be redirected > from/to files or anything else by using deferred words. It can run on > the bare metal or under an OS. You can give as much power to your > customer as you think they can handle or as little as you think is wise. > > I've cross posted this to the forth group to get input from some of the > regulars there. > > Oh, about the "file system". If you are happy with no file system at > all, Forth can treat your storage as "blocks" of 1 KB and no real files > at all. You can't get much simpler than that.Sometimes don't you wish Usenet had a "Like" button? MPE's VxfForth is probably best for most of the platforms you are likely to be dealing with these days. I do recall suggesting Forth earlier in this thread. You really can design the script language you want and make it seem quite natural to the user. -- ******************************************************************** Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk> Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk> Mob: +44 (0)7811-639972 Tel: +44 (0)1392-426688 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
Reply by ●March 18, 20152015-03-18
On 3/18/2015 3:30 AM, Robert Wessel wrote:>>>> I prefer real names for things instead of yet another cryptic "special >>>> combination" of symbols. One of limbo's problems is it's not very >>>> effective as a "read over the phone" language. (unless you preagree >>>> as to how to name particular character combinations: -> <- => :: etc) >>> >>> I've never had to read - or listen to - code over the phone. 8-) >> >> You have vision. How would a blind user "see" the code? How >> would I tell him what to write to solve one of his problems?>> Or, do you just exclude them from that technology? :> One of the >> driving motivations for my current project is accessibility -- in more >> than just a "token" sense. >> >> As I said, you can adopt *conventions* to make what you see more >> readily conveyed in (e.g., spoken) conversation. E.g., I'd never >> say "colon colon equals" when reading an Algol fragment to someone... > > I've advocated using Victor Borge's approach. But alas, I seem not to > be taken seriously...Not sure I follow. Wasn't he the wonky pianist/comic?
Reply by ●March 18, 20152015-03-18
On Wed, 18 Mar 2015 10:32:38 -0700, Don Y <this@is.not.me.com> wrote:>On 3/18/2015 3:30 AM, Robert Wessel wrote: > >>>>> I prefer real names for things instead of yet another cryptic "special >>>>> combination" of symbols. One of limbo's problems is it's not very >>>>> effective as a "read over the phone" language. (unless you preagree >>>>> as to how to name particular character combinations: -> <- => :: etc) >>>> >>>> I've never had to read - or listen to - code over the phone. 8-) >>> >>> You have vision. How would a blind user "see" the code? How >>> would I tell him what to write to solve one of his problems? > >>> Or, do you just exclude them from that technology? :> One of the >>> driving motivations for my current project is accessibility -- in more >>> than just a "token" sense. >>> >>> As I said, you can adopt *conventions* to make what you see more >>> readily conveyed in (e.g., spoken) conversation. E.g., I'd never >>> say "colon colon equals" when reading an Algol fragment to someone... >> >> I've advocated using Victor Borge's approach. But alas, I seem not to >> be taken seriously... > >Not sure I follow. Wasn't he the wonky pianist/comic?Yes, one of the things he was famous for was a routine in which he'd read something, and pronounce all the punctuation. https://www.youtube.com/watch?v=6bpIbdZhrzA
Reply by ●March 18, 20152015-03-18
On 3/18/2015 2:11 PM, Robert Wessel wrote:> On Wed, 18 Mar 2015 10:32:38 -0700, Don Y <this@is.not.me.com> wrote: >>>> You have vision. How would a blind user "see" the code? How >>>> would I tell him what to write to solve one of his problems? >> >>>> Or, do you just exclude them from that technology? :> One of the >>>> driving motivations for my current project is accessibility -- in more >>>> than just a "token" sense. >>>> >>>> As I said, you can adopt *conventions* to make what you see more >>>> readily conveyed in (e.g., spoken) conversation. E.g., I'd never >>>> say "colon colon equals" when reading an Algol fragment to someone... >>> >>> I've advocated using Victor Borge's approach. But alas, I seem not to >>> be taken seriously... >> >> Not sure I follow. Wasn't he the wonky pianist/comic? > > Yes, one of the things he was famous for was a routine in which he'd > read something, and pronounce all the punctuation.Ah! I'd only heard him playing piano with sheet music upside down, wearing a seat belt to the piano bench, etc. A programmer can exercise some control/discipline over his/her choice of identifiers *if* non-grapheme output is a goal. But, the *language* tends to give very little flexibility in how and where symbols are used. Do you really need (want) to hear "open paren" <expression> "closed paren" for every conditional? loop? etc.? You can create "modes" whereby special types of "displays" are interpreted according to a different set of rules (e.g., read "==" as "is equal to" and "=" as "gets", etc.). But, the more of these you encounter as a matter of course in a given bit of "input", the more taxing it gets to become. Nonsense example (unchecked for correctness/syntax -- but, everything over which the developer has control has been chosen to be "pronounceable"; all other "words" are defined by the language): implement fudge; include "sys.m"; sys: Sys; SHORT, MEDIUM, LONG: con iota; FOREVER: con 1; text: list of string; pipe: chan of (string, int); init(args: list of string): int { argv = tl args; argc = len argv; sys = load Sys Sys->PATH; spawn consumer(pipe); while (argc > 0) { line := hd argv; argv = tl argv; argc--; size := LONG; // assumption else otherwise if (line == nil) { break; } else if (len line < 10) { size = SHORT; } else if (len line < 40) { size = MEDIUM; } pipe <-= (line, size); text = line :: text; } ... return 0; } consumer(hose: chan of (string,int)) { input: string; size: int; shorts, mediums, longs := 0; while (FOREVER) { (input, size) =<- hose; case size { SHORT => shorts++; MEDIUM => mediums++; LONG => LONGS++; * => /* can't happen */ exit; } sys->print("Received '%s'\n", input); } }
Reply by ●March 19, 20152015-03-19
On Tue, 17 Mar 2015 23:32:50 -0700, Don Y <this@is.not.me.com> wrote:>On 3/17/2015 10:50 PM, George Neuner wrote: > >> I've never had to read - or listen to - code over the phone. 8-) > >You have vision. How would a blind user "see" the code? How >would I tell him what to write to solve one of his problems?I wouldn't expect a blind user - or ANY user for that matter - to be reading code. At most I would expect to be read some error messages. *Those* should be able to be pronounced by a screen reader.>Or, do you just exclude them from that technology?No. I expect blind and deaf to be abe to use things, but I don't expect any non-technical person (~95% of the population) to be programming them. George
Reply by ●March 19, 20152015-03-19
Hi Tim, I am the author of Mecrisp-Stellaris, a Forth implementation that compiles to native code on the target and needs 16 kb Flash and about 1.5 kb RAM on an ARM Cortex M0/M3/M4 for its core when used standalone. RAM is necessary mostly for input buffers and its two stacks. As you called for Open Source, I think you are fine with GPL3 licencing ? If you are, then I am there for your help. Until now, Mecrisp-Stellaris is designed to be monolithic, but you can change initialisation code, memory map and interrupt handling for your needs. Something you still need to think of is wiring the parts of your code which should be user available into the dictionary and do parameters-on-stack interfaces for them. If you like to try, Mecrisp-Stellaris already runs on chips from TI, STM, Freescale and NXP. An emulator for a Freescale M0 target running on Linux is included. Best wishes from Germany, Matthias Koch mecrisp.sourceforge.net
Reply by ●March 19, 20152015-03-19
On 3/18/2015 11:09 PM, George Neuner wrote:> On Tue, 17 Mar 2015 23:32:50 -0700, Don Y <this@is.not.me.com> wrote: > >> On 3/17/2015 10:50 PM, George Neuner wrote: >> >>> I've never had to read - or listen to - code over the phone. 8-) >> >> You have vision. How would a blind user "see" the code? How >> would I tell him what to write to solve one of his problems? > > I wouldn't expect a blind user - or ANY user for that matter - to be > reading code. At most I would expect to be read some error messages. > *Those* should be able to be pronounced by a screen reader.So, they should *hire* folks to customize things to their needs? bedtime() { if (stove on) warn("You left the stove on!") if (door unlocked) warn("Don't forget to lock the door!") if (garage open) warn("Don't forget to close the garage!") if (lights on) { warn("There are still some lights unexpectedly left on. "\ "Should I shut them off?") if (yes) lights(off) } heat(bedtime) }>> Or, do you just exclude them from that technology? > > No. I expect blind and deaf to be abe to use things, but I don't > expect any non-technical person (~95% of the population) to be > programming them.I think that is changing. Things are getting too complex for a "one size fits all" approach to all users. "Non-programmers" already write macros in Excel, Word, etc. And, even write VB scripts "without formal training". I don't think it a stretch to assume they'll be able to "code" these sorts of things -- esp if there are very high level abstractions at their disposal.
