ionous / iffy Goto Github PK

td be interesting to see a graph of now and future choices when clicking or editing; maybe a two dimensional,horizontal,expanding schematic graph.

basically, i want state chart like behavior where new nouns can be introduced for the length of the state.
a more generalized form of inform's scenes.
used for replicating inform's scenes, for implementing tests, for implementing libraries too.
can specify a parent nouns status ( properties, locations ) on begin / end stage.
stages have specific parents. nouns are unique within the branch of the tree.
runtime has a list of active stages. jumping to a stage activates all of its parents, deactivates any others. so multiple stages can be active, but you know in advance the hierarchy; you dont dynamically start multiple scenes programmatically.

if this were mobile,maybe there'd be an active line or focus somehow for single click additions on the side bar. maybe cursrorial ghosts. could you have a hover ghost somehow to allow you to shift focus. if you have dynamic swapping of lines and groups,you could select the one at the end of a line,and press enter to get a new line

swaps in go: can an a swap be an interface? if not can it implement an interface?
could be the interface noun,or it could implement and interface.
the former makes swap a sort combined slot/slat; the latter makes it a sort of one parameter run.

{ .something },{ cmd: .something },{ pat: .something }

This would help testing. Look at thingaverse in thing_test.go. note: activate domain should be a counter inc/dec. after sussing domain hierarchy,could you just loop over all existing code,selecting the names for each domain. incl. find the root domain for a given name,ensure that it was designated explicitly as a domain,otherwise theres an ambiguity. ex. ( domains A,AB,AC. if noun X is in B and C -- but not A that's a potential problem -- those technically should be two different nouns )

By convention,one-method interfaces are named by the method name plus an -er suffix or similar modification to construct an agent noun: Reader,Writer,Formatter,CloseNotifier etc. https://golang.org/doc/effective_go.html#interface-names

esp. types,and consider removing the nods pool altogether. see what can be moved to created() from data()

and its annoying

using 'our' as a generic determiner might simplify the tweakness of shifting from common to proper nouns,etc.

Maybe find a way to combine the test sections better? Possibly some sort of structured layout like rules in patterns

see newnames.txt

beyond just writing patterns, "understandings" should allow an author to create a typespect which would then show up in the composer like any other command.

its almost required due to the way go build and go install work. [ cant reliably rebuild multiple commands without simultaneously publishing them ]

import code generates templates from text lines, and stores the resulting bytes, it should instead, probably generate opcodes, and process those opcodes for facts -- maybe as the opcodes are generated -- but store the opcodes, and delay converting to commands till assembly if at all possible.

• consider replacing "Decoder" with conversion to postfix.Function(s). It would allow template string evaluation and the importer to use the same code conversion. It'd also be easier to replace / synthesize commands during "compile"

• consider: FromVar supports untyped values ( previous was interface{} ) which is currently necessary for template calls to patterns because those calls are untyped. replacing the "import" callbacks with opcode / chart manipulation might remove the need for FromVar.

is case sensitive,
is a bad size,
isn't alphabetically sorted,
would be better 'embedded' than as a popup.
clipping of autocomplete box"

"https://css-tricks.com/popping-hidden-overflow/,
https://popper.js.org/docs/v2/modifiers/prevent-overflow/,
https://leaverou.github.io/awesomplete/,
https://popper.js.org/

could be a separate tab for the context window

idea: it'd be cool if the command listings (ex.core.go) were generated from go generate. could maybe snag the comment,or command text,and put it as a comment along side.

ahg. my kingdom for a vue based statechart system

i forget exactly what they are. fullstop i think generates a new line when its at the end of a say

appeng hosting

ex. Things doesnt match things,and composer text entry is forcibly uppercasing the starts of sentences,so compilation easily fails.

no idea how dragging a section/header should work. the sections would be visually spaced. bold headers. show in the side bar

ie. detect running as local file, use relative dir for picking out files

the current json format is painfully verbose. the composer can generate the compact format, but nothing reads it in except tests right now.

eventually some sort of document server with ability to list files,open into composer/atlas,etc. using actually separate files on disk is good: then you dont need the document server to do everything ( ex. source control,copying,etc. ) is there anything off the shelf? for local or appengine?

this might be a feature sized task. Issues with spacing between optional elements might matter here too.

apply changes as commands,almost as if there were a front end and backend,then: allow multiple views/windows to edit the same text

cmd/import skips unknown, unhandled commands.
unhandled commands should report an issue.

it makes you think you cant drag the numbers. not sure what could improve things. maybe highlight some rectangles?

make unroll handle the optional/required creation. consider creating all elements as at least null so you dont need to / elsewhere.

ctrl-c,ctrl-v would be greate

especially dragging in any/all true

i forget exactly what they are. fullstop i think generates a new line when its at the end of a say

currently, range looks like:

for each num range 031

Among other things, step should be optional, and so should probably start. Help text regarding "is inclusive" or not, with example should exist.

number and boolean templates can't be fully utilized because express doesn't know the output type for the template commands getting generated.

ex {random_number} where random_number is a numeval would fail, because express expects the template output to be text

this would save having to write a ui for it.

ex. the target