Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    john-j-mclaughlin
    @john-j-mclaughlin
    The data for an event (if any is required) are just properties of the event object and are accessible by any handers invoked by the event.
    Eric Walkingshaw
    @walkie
    That's not the way frame works though, which is the language we're making this decision about. :-) In Frame, there are potentially state variables, state parameters, and event parameters, which would all be in scope in a handler in state A, and would not be in scope in the on_entry handler in state B, and there would be no way to access them any more from the handler in state B.
    john-j-mclaughlin
    @john-j-mclaughlin
    Ah... OK... I cannot speak specifically to Frame :)
    Mark Truluck
    @frame-lang
    Just wrapped up the day and finally have a moment to comment but looks like a great discussion. I can argue it either way theoretically but there may be a forcing function that dictates a particular decision. In v6.0 I want to make the transition type to be configurable. Currently all transitions are what I'm thinking to call "immediate". As we have been discussing, I would like to get "deferred" transitions in next. If it was confusing to have actions happen after an immediate transition, it would be nonsensical to have them after a deferred transition. In effect, for deferred, one would always execute all actions prior to the transition regardless of if you specified them before or after the transition because, well, the the transitions were deferred :).
    So as to not have completely different behavior between the two architectures, I am leaning towards having the grammar enforce a return immediately after a transition. What do ya'll think?
    The deferred architecture example: https://dotnetfiddle.net/rQaB9R
    Mark Truluck
    @frame-lang
    On a different point that was raised - the frame event is referenceable using the @ token. Search for Frame Event here: https://frame-lang.org/notation/
    You can also reference it's component parts as well and pass the event as well as its parts to actions
    action1(@ @|| @["p1"] @^) // etc
    So I believe you can pass the "source event" to an interface call like this (but haven't tried it yet :) )
    iface1(@)
    Mark Truluck
    @frame-lang
    I'll give it a try later.
    Eric Walkingshaw
    @walkie
    Hi Mark, that makes sense to me. I'll adjust my (still in progress...) refactor of the Rust backend to only support transitions at the end of the handler. Currently, since the frontend doesn't rule these programs out, the backend will just generate code that doesn't compile (due to an ownership issue). But once the frontend is modified to enforce returns after transitions, hopefully the errors will be a bit more comprehensible.
    Mark Truluck
    @frame-lang
    Considering the use of https://readthedocs.org/ for documentation. I agree getting the grammar documented is a top priority. Any other ideas for the documentation?
    I found that resource when learning Godot: https://docs.godotengine.org/en/stable/index.html
    Eric Walkingshaw
    @walkie

    Using readthedocs.org seems like a solid choice to me.

    The documentation that you have already on frame-lang.org is a great start I think. Just needs to be expanded a bit and a way to make it easier to navigate. Using readthedocs.org should be good for that because you'll get section header links in the menu and so on, which will help a lot.

    The demos you have linked at the bottom of this page were also very helpful to us getting started. Might be worthwhile to have one medium complexity example like this that is explained piece-by-piece in the documentation, as a sort of tutorial. Then you can just include links to other examples like you have already.

    Bradley Nelson
    @bradnelson
    I've liked readthedocs as well :thumbsup: (Also came across it when learning Godot!)
    walni
    @walni
    Hi Mark. Do you intend to release a Frame CLI at some point in your roadmap? It would ease the the code generation directly for many developers. Well, I can also dream of a Frame PyPi package...
    Mark Truluck
    @frame-lang
    Hi @walni . Not quite sure how you mean CLI. You can already use framec as part of a toolchain but it isn't really documented yet. If so I can get that written up.
    Please LMK what is blocking for you to be able to start to use and what your main use cases are.
    walni
    @walni
    CLI
    walni
    @walni

    A command line interface to use Frame from the terminal.
    Ex.:
    user@machine:~$: FrameCLI(timer.frm --path "/shared/conda/frame" --lang python3 --transpile-to newtimer.py --new-classname AutoTimeout --add-context framecontext.py --add-actions myactions.py --action-suffix '' --loglevel INFO --ulm timer.png)

    My use case: embedding of HSMs in python scripts for web automation purposes.
    Can be called from any script. A (better) alternative would be a Frame PyPi package, but it would specialize a ‘Frame for Python users only’ approach.

    Mark Truluck
    @frame-lang
    So both the CLI and the PyPi packages would wrap the framec to provide more general functions useful in CI/CD pipelines?
    walni
    @walni
    Yes. A PyPi package would be quite specialized (Python users only), while a CLI would work in any terminal regardless the target language, ie for a larger community. To be honest, as some effort is involved, this kind of decision requires a much better vision of Frame users needs & roadmap that I can have.
    Mark Truluck
    @frame-lang
    Is there a cli you use for other languages that might give guidance to what the feature set should be?
    walni
    @walni
    In a quite specialized and similar field (Petri nets compilation), there is for example Neco (https://code.google.com/archive/p/neco-net-compiler/wikis/UsingNecoCLI.wiki), there is no doubt there are lots of similar tools. I use everyday the Anaconda CLI (Python/R oriented platform - see https://docs.conda.io/projects/conda/en/4.6.0/_downloads/52a95608c49671267e40c689e0bc00ca/conda-cheatsheet.pdf). You can also look at the doc of very well done non-language specific CLIs (Docker, Wordpress...), they more or less share the same logic.
    Mark Truluck
    @frame-lang
    Thanks for those. As they have large and varied sets of functionality can you identify a core that would unblock you starting to use Frame?
    walni
    @walni

    A Linux package to install a minimalist Frame CLI would be very nice.
    For example the command:

    Framecli mysourcefile.frm --lang python3 --out mytranspiledfile

    would transpile the Frame source file mysourcefile.frm to a python file.

    Mark Truluck
    @frame-lang
    Ok that is quite doable. @walkie would this be useful to you as well?
    Eric Walkingshaw
    @walkie
    The current CLI is a bit idiosyncratic, but it's working for us now that we've standardized the YAML+attribute config. Here's what we do:
    • Put shared config in a YAML file
    • Put state machine-specific config in attributes at the top of the Frame specs
    • Specify the input file and target language on the command line, and redirect the output to our desired output file name.
    The way I implemented the new config system, attributes should just work for new languages as the config options are added for those languages (i.e. it's not tied to the Rust backend). That said, it's completely untested for anything but Rust!
    I can definitely see that being able to set config options via the CLI would be handy, but ideally these would be integrated with the existing config system so that there's one set of config options, which can be set in multiple different ways (YAML, attributes, CLI). Not sure the best way to do this with minimal code duplication...
    The config system uses the figment crate. I did a quick search and don't see any Figment providers for clap, which seems to be by far the most widely used command-line arg parser library. However, writing a provider to link up the two probably wouldn't be too hard... I wrote a custom provider for Frame attributes, so could help with that.
    Eric Walkingshaw
    @walkie
    A "provider" is just something that implements a trait from figment that lets it ingest new config settings.
    Eric Walkingshaw
    @walkie
    Just double checked, and we're actually running framec's Exe::run_file method directly from a build.rs file, not via the command line. The config stuff is all the same, and running it this way should be a equivalent to running it from the command line.
    Mark Truluck
    @frame-lang
    So my read on this idea is to have a companion tool for secondary duties like cargo is to rustc. To start it could just be a cleaner way to build target files but going forward would be the collector of all the other responsibilities modern language systems support.
    Mark Truluck
    @frame-lang
    @walkie have you ever heard of this? https://bobbuildtool.dev/
    Eric Walkingshaw
    @walkie
    I haven't. Are you thinking of using that for inspiration? Looks like it's trying to be a better Bitbake. Bitbake is an outrageously hacky mess, so there's definitely space for that IMO!
    Mark Truluck
    @frame-lang
    Well in thinking about a name for this new tool I was riffing on Frame and thought of Bob the builder. I guess someone else did too. Regardless this doesn't seem to be a good fit for a simple tool to do various frame related build tasks. I'm thinking of calling it 'jig' now. Any nay votes?
    Eric Walkingshaw
    @walkie
    Jig is a good name! Nice and short and a good fit thematically.
    Also, FYI I'm on vacation the rest of this week and all of next, so probably won't be replying until I'm back.
    Mark Truluck
    @frame-lang
    OK - jig it is. I've setup a new repo - please add thoughts to this (minimal) spec: frame-lang/jig#1
    Mark Truluck
    @frame-lang
    Did the first checking for golang. I believe I followed all the correct procedures but please safely validate - git foo dissipates with extraordinary rapidity.
    Eric Walkingshaw
    @walkie
    I'm gonna roll another release with the additions to MachineInfo (path + checksum of source spec). I'll follow the release process in Issue #81 and see later if we missed anything. :-)
    Mark Truluck
    @frame-lang
    Excellent!
    Eric Walkingshaw
    @walkie
    Done! Having the process was really helpful, even though I've done this several times now. I would've forgotten to update the version string in compiler.rs without it. :-)
    I left the brief v0.7.4 release note in the README too so the new golang support wouldn't fall off the front page too quickly.
    Mark Truluck
    @frame-lang
    I have released v0.9.0 which has Golang implementations of all of the major features I have thought of for Frame so far. Frame Demos (https://github.com/frame-lang/frame-demos) contains small samples of the new language features while cloudtraffic (https://github.com/frame-lang/cloudtraffic) is a complete webapp demonstrating how to build a webapp w/ front-end managing a set of persisted workflows. I will be spending a lot of time documenting these in the coming weeks.
    Eric Walkingshaw
    @walkie
    Congrats, Mark!