sumeet / codemaestro Goto Github PK

you can't see the output (which in this case will be a number), or even intermediate values, without converting back into a string and printing it in the chat test window.

there should be another way, either some sort of script abstraction, or debugging.

should you have to wait for your program to reduce values, or call a logging function? or can that be part of the overall dev flow.

here are some ideas that i think demonstrate the direction i'm thinking in:

• Log function. It's generic (doesn't require a String, but any type works) and uses the ValueRenderer to print... somewhere. maybe inline next to the code, or to a separate log window. (and maybe the log window would have a backref to the code?)
• Support "scripts" which are like functions in that they're a series of expressions, but don't have arguments. But there is a Run button.
• Automatic "debugger" sort of thing. When code is executed inside the editor, we automatically show the last value that expression returned inline next to the code.
• Run-as-you-code. If you're coding say a function, you have the option of specifying test / example values for the function arguments. Now that you've specified inputs, we can show intermediate values inline next to the code.

i think this might be related to the "test" question from #3 for the JSON builder

regarding the ideas, i don't think it's necessary to go too deep if it takes too long. the main goal here is just to be able to code the solution to aoc2019 day1. however if we can pull of some of the debugging stuff, it could be a really cool way of solving the problem (how the hell do we see output?) that simultaneously achieves a big improvement in the coding process. that is, making it easier to see what's going on while you're coding. all of the ideas above don't actually seem that hard to implement

instead of having the assignment_id and name inside of the Assignment itself. this opens itself to

• being able to highlight ONLY the variable definition
• being able to edit variable names in things that aren't variables like anon funcs, for loops, and match statements
• i think totally removes the need for match.make_variant_id (phew, that was scary)
• simplifies lookback code for Variables, instead of all those different cases, only look for VariableDefinitions

#6 may be too much of a hurdle, if we want people to actually use this in their browsers. getting the performance right might be a lot of work, and the yew/wasm UI feels really janky right now compared to the wasm UI.

i would still like for the environment to work with the DOM, however, using imgui wasm may be a good shortcut to be at least usable on the web.

probably not just plug and play because the current imgui adapter layer is doing event loop and glutin stuff, probably works differently in wasm. probably worth trying a clean wasm-imgui-rs project just to see what's involved.

i don't think it'll be that difficult, and includes selecting regions of code, which will be useful for #8.

i think it's important to call it "Pull out function" and make it top-level not buried under Refactor menu. "Extract function" is just harder to understand, i can feel that people are more likely to click on Pull out function, it feels nicer

requirement for aoc2019 day1

hopefully also figure out a way to make doing this sort of arithmetic more legible, it's probably illegible if it looks like function calls

this is easy to see when there are a lot of objects on the screen. happens when the easy way to repro is when the ValueRenderer renders a deeply nested JSON response, everything slows down to a crawl.

talked with yew developers, and we should try the following steps to improve things:

• finish converting all UiToolkit draw_* functions to build components instead of rendering HTML directly. yew is faster at comparing components which know if they need to rerender, rather than diffing their generated HTML.
• probably as follow-up, the callback->mutation structure may need to be revisited. Components will contain callbacks that "do the action", like for example a Button component would contain what to do when the button is clicked. there's no good way of comparing these callbacks.

options:

• Do we refactor the application to make these not be callbacks? (rather declarative data-packages containing request information about the mutation that needs to be done)
• or does that not end up mattering really? maybe we just treat all callbacks as "equal" (i.e., don't compare them when comparing the component)

• left clicking on the variable should let you do a special menu

  • Edit variable name
  • "Unassign" the expression
  • Delete the entire expression

• You should be able to click on the expression (RHS of assignment) and change the expression

  • if the variable is being used somewhere, then the expression stay the same type (unless it's generic... but we'll get there later lol)

we need this for the List<String> => List<Number> conversion of the input data.

this is actually mostly complete, but just has a crasher related to local variables.

these trait methods, which are currently stubbed out:

    fn draw_form<T: Serialize + DeserializeOwned + 'static, R>(&self,
                                                               _form_id: u64,
                                                               initial_values: T,
                                                               draw_form_fn: &dyn Fn(&T) -> R)
                                                               -> R {
        draw_form_fn(&initial_values)
    }

    fn change_form<T: Serialize + DeserializeOwned + 'static>(_form_id: u64, _to: T) {
        unimplemented!()
    }

    fn submit_form<T: Serialize + DeserializeOwned + 'static>(_form_id: u64) -> T {
        unimplemented!()
    }

should be able to drag pieces of code around, possibly placeholders get inserted when doing a move referencing a variable that's not defined if changing scope.

the new schema builder interface makes a lot of sense compared to the old checkbox interface, but the organization of the menus doesn't make sense. furthermore, doesn't really work and isn't fluid.

instead of fixing the crashers with the current implementation of the JSON HTTP Client builder, i would like to put design energy into the UI and flow.

current implementation:

after running the "test"

there are a number of issues here. i think it's a little unclear and unnatural how to use this, and another UI issue is that the schema builder takes up a lot of room, there's a lot of vertical scrolling.

what i actually had in mind

i wanted some sort of way to tie together the concept of unit testing, and knowing up front some example inputs (related to #4) and using that to actually execute said request against external server, in essence combining the steps of playing with an external API (like you would using a tool like curl or postman) and turning it into executable code.

as a UI puzzle, it may be too difficult to figure all of these things out at once. possibly the "testing" part of it could be figured out as part of #4 and implemented at another time. maybe "schema builder" should just let you paste JSON into it instead of doing requests itself.

i'm not sure about any of these ideas, and i don't know where to go with this.

copy+paste would probably need to generate new code node IDs, otherwise we'd have duplicates. not sure what would work for cut, so we could leave that out.

similar to #7, it's possible to paste into a place where the variable references don't apply. also variable references work by UUID... so if it was referring to the same variable ID being pasted into a totally new context, that would probably not be good.

should be pretty straightforward

• imgui (definitely doesn't work right)
• yew (works fine in yew)

normally this lets you do a "replace" operation (like in vim), but for some reason inside of a list literal, it does nothing.

• format certain function calls as "infix" style (mostly done at least)
• there needs to be a handle for dragging these around

the child region is too large. it needs to look like it's just sprinkled on top of the code, it's too prominent. the Output should be exactly the size of the "inner" rectangle, and that should be a scrollable region.

also, this should be shift-enter instead of ctrl+enter. probably not a hard bug to fix.