Date: Sat, 19 Nov 2022 18:18:11 -0800
From: Bret Victor
Subject: Re: Parameters and knobs
Very cool!  I now have four 50mm Lazy Susan Aluminum Bearings for Glass Turntables en route, and am looking forward to turning them.

I also added an editor command (in "Code Editors: Edit keys" for now).  If your cursor is on a line of code such as:

    local agility = 7

and you press control-M (for... paraMeterize?), it transforms into:

    Notice (you) has parameter "agility" with value /agility/ default (7) range {0,10}.

It also works in C:

    float agility = 7;

You can even just type

    x=7 <control-M>

to get a parameter with minimal keystrokes.

It also goes in the other direction.  Once you've adjusted the parameter to a value you're happy with, press control-M again and the Notice transforms back into a local variable with the current value.

The idea is that you can start out with hardcoded constants, and then when you want to start wiggling them, it's just one keypress to make them wiggleable, and another keypress to tuck them away again.

--

I also removed the old "Scrubbable" page, since I think parameters supersede that.  Scrubbable had a syntax like

    local agility = scrubbable(you, 0, 10) or 7

but it was kind of awkward, and had no memories.  (And I didn't like how the notice is hidden inside the function call.)

--

By the way, I wanted to mention a feature about options, since I'm not sure I ever documented this.  Instead of writing:

    When /p/ parameter /name/ has value /value/ with options /o/:
        local o = table.shallow_copy(o)
        o.value = value
        Claim (p) has parameter (name) with options (o).
    End

you can write:

    When /p/ parameter /name/ has value /value/ with options /o/:
        Claim (p) has parameter (name) with value (value) options (o).
    End

It does exactly the same thing.  The given value will override o.value, if any.  I find myself doing this a lot when passing around options -- it makes it easy to "pass through" a given set of options as defaults, while tacking on your additional options.

Especially useful in conjunction with the "Options" macro:

    local o = Options x (1) font size (3) font face "Helvetica B".
    Wish (you) draws "text" "Hello" with y (1) options (o).
    Wish (you) draws "text" "there" with y (2) options (o).

That first line is the same as:

    local o = { y=1, font_size=3, font_face="Helvetica B" }

but you can keep the Realtalk syntax (very handy when you've already written it that way for a wish), and you can tack on additional options easily:

    local o2 = Options color "yellow" options (o).

Since adding these features, I almost never have to shallow_copy the options table, or even think of it as a table.

--

While on the subject of options -- what do you think about merging the Device Kit properties into the options?  That is, instead of:

    When (processor) has connected "input" device path /device_path/ with properties /props/ event interface (true),
         (props.ID_INPUT_KEYBOARD == "1"):

we could write:

    When (processor) has connected "input" device path /device_path/ with ID INPUT KEYBOARD "1" event interface (true):

I think device properties have distinctive enough orthography that they wouldn't collide with our own options, and having a single level would make filtering easier.


On Nov 18, 2022, at 8:33 AM, Luke Iannini wrote:

https://www.vxb.com/50mm-Lazy-Susan-Aluminum-p/50x16-lazy-turntable.htm<50X16-LAZY-TURNTABLE-2.jpeg>
50mm Lazy Susan Aluminum Bearing for Glass Turntables
vxb.com



On Nov 18, 2022, at 10:28 AM, Luke Iannini wrote:

[video.webm]<maxresdefault.jpg>
Recognition Kit: Parameters and Knobs
youtu.be