Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Mark Truluck
    @frame-lang
    New versions of he transpiler and editors available now with much better UML image manipulation (zoom) as well as a few key bug fixes with code generation
    Bradley Nelson
    @bradnelson
    Sweet! Sounds great, I keep saying this but I think soon I'll get to further testing!! ><
    Mark Truluck
    @frame-lang
    no worries :) And just lmk whats top priority for config as that is the theme for 0.5. I'm going to make all codegen to be as modifiable as possible but don't know what else you might like in there.
    Bradley Nelson
    @bradnelson
    Yeah, I think the yaml file could work. A lot of the needs could also be covered by the attribution system you added recently also, that seems to be pretty handy and could cover a lot of language- or system-specific fine-tuning. Both are decent options IMO.
    Mark Truluck
    @frame-lang
    There will be a meetup at 7PM PT on July 14 to introduce Frame. I plan to do one every other week for people interested in connecting: https://www.meetup.com/seattle-software-architecture-and-modeling/events/279096204/
    Mark Truluck
    @frame-lang
    @bradnelson @walkie So I took some time to experiment with a new pattern for the state machines which would solve a key problem for non-reactive applications that I'd like to get your thoughts on.
    Basically if you write a machine that is called once and it just iterates through states then the stack will eventually blow up due the the way the enter event handler works. If you transition in it, you leave the previous state on the stack.
    I've got a proposal that fixes that and I wrote a couple of test cases.
    The solution is to 1) make all transitions "asynchronous" and are put on a queue rather than executed immediately and 2) introduce a machine() method that is a choke point for all events coming out of the interface into the state machine which execute any transitions queued in the last state call.
    Mark Truluck
    @frame-lang
    I'm sure there are ways to completely bugger yourself but hope that might be handled in the parser to detect.
    I'm also thinking to keep both codegen options and make it configurable which you want. In the future I want to support multiple output formats so this would be a first instance of that capability.
    Thoughts?
    Bradley Nelson
    @bradnelson
    yeah, fernando took a look in there and we think that makes sense :thumbsup:
    Mark Truluck
    @frame-lang
    cool thx
    Mark Truluck
    @frame-lang
    Checked in v0.5.1 a lot of cleanup of rust formatting. Haven't exhaustively gone through the options so send me samples to fix.
    Also now generate a config.yaml file from the internal default if one is not found and load parameters from it if it is.
    I think I'm feature complete for this release so starting testing
    Bradley Nelson
    @bradnelson
    Exciting! I'll start testing from your branch later today! I had to make a few modifications to get the latest state machine I'm working on to run, I might submit a patch (if the problem is still there). I think Eric possibly has a PR queued up as well that might be nice to get into the release.
    Mark Truluck
    @frame-lang
    I have merged Erics PR too
    LMK if you guys would like to meet sometime this week to discuss progress and roadmap
    Bradley Nelson
    @bradnelson
    I think Eric had another PR he was holding on to, and I have made a few minor mods as well to send your way (but I made my mods off of Eric's fork, lol). Probably no big deal, up to you if you want to wrap the release go for it!
    Eric Walkingshaw
    @walkie
    I think the PR I was working on needs more discussion before we send it your way. We want some mechanism for generically monitoring state transitions and my PR provides a way to do this by generating hook functions that will be called on each transition. But there are some drawbacks to this approach and we discussed an alternative callback mechanism quite a bit too. I definitely think we should sync up with Mark at some point soon about this since it's a pretty subtle design decision that it'd be good to get right.
    I agree with Brad though, we shouldn't let this block your release!
    Mark Truluck
    @frame-lang
    I'm not under any pressure to get the release out - nothing is hinging on it and I'm just doing more of the tidying Fernando requested to comply with rustfmt right now. So we can take the time to consider the right approach.
    Mark Truluck
    @frame-lang
    @walkie @bradnelson here is a link to the talk I've been giving on my meetups: https://docs.google.com/presentation/d/1PgjP6WvR1W0i0B_RiWLPEWQtHKUPvtGsku8ziZmEEN8/edit#slide=id.p
    There is a roadmap slide which might be useful for the discussion today
    (available for all to checkout)
    Eric Walkingshaw
    @walkie
    Thanks for sharing the talk slides, Mark. Super helpful to see your motivation and long-term vision.
    I ran a programming languages reading group at OSU for the last several years and coincidentally, one of the papers we read just a few months before I left was Harel's statecharts paper, so it was really fun to see this come up again. :-)
    Mark Truluck
    @frame-lang
    Cool. I've interacted w/ Harel a couple of times asking for permission to use images from his paper, which he graciously gave. Also thanked him for all the great ideas! A very gracious man.
    john-j-mclaughlin
    @john-j-mclaughlin
    It's cool that Harel's work has inspired others. I've been using his paradigm since the mid 90's and have always found it very liberating when dealing with complex behaviors and error handling/recovery.
    Go Beavers!
    Mark, FWIW, your comments about asynchronous transitions and queuing are spot-on from my experience. We found this decoupling made for much more intuitive execution, especially with multiple levels of state and event handlers at more than one level. Also good when using parallel sub-states.
    john-j-mclaughlin
    @john-j-mclaughlin
    A little anecdote about the benefits of HFSM-based development... When we started this work the typical man-power needed to build a new semi cleanroom tool interface was in the 6-8 man-weeks. Once we got to a production-suitable release stage we were doing these in 4-8 man-hours.
    Mark Truluck
    @frame-lang
    Thanks John and glad you've found us. Are you working with other people in the community here or stumble upon us (apologies if we have interacted in the past - my social memory is extremely limited in registers)
    john-j-mclaughlin
    @john-j-mclaughlin
    Just stumbled upon your reddit group when doing some FSM searching.
    And I saw the OSU folk here... I am a life-long Oregonian who moved to SoCal recently.
    Mark Truluck
    @frame-lang
    So far the Frame community is very northwest centric. I have wonder if Reddit is overweighted that way...
    Well welcome John. What languages do you typically use? Rust has been the focus as of late.
    john-j-mclaughlin
    @john-j-mclaughlin
    Well, I was a C/C++ guy for decades. But, as of late, I am using Go for the production code and Python in development support roles. Been planning to give Rust a tryout, but time has not allowed for that, yet.
    Mark Truluck
    @frame-lang
    Cool! Generating Go is on the shortish term list of things to do as it would be good for me to know. It would be great to have an expert trying to make use of it (and any of the other languages for that matter). LMK if you are interested in giving it a try - I am eager to have people putting it to use. If you would like more info about Frame first I'll be hosting another intro session in a couple of weeks.
    Also would be very interested in any patterns you like for implemeting statecharts in C. That is another target language I want to tackle soonish
    john-j-mclaughlin
    @john-j-mclaughlin
    Mark, it seems we are on the same path with regard to HFSM-based software development. We built a DSL with a concise and intuitive grammar and full Harel/UML support back in the 90's which generated production quality ANSI C code. More recently, I have redesigned and reimplemented the same capabilities with Go as the target (however, the new version can really target practically any language). It also has a very rich set of event publishing and handling capabilities. Let me know if you want to see some sample code.
    It's fairly performant already without any code optimization, handling about 1M events and state transitions per second on my couple year old laptop.
    Mark Truluck
    @frame-lang
    I would love to see any examples of your technology - it sounds impressive. Who is involved with the project and is a company backing it? Have you open sourced it?
    john-j-mclaughlin
    @john-j-mclaughlin

    In the 90's I had a small consulting company specialized in factory automation. The FSM (and other) technology was done by me and my team and was funded by a $750K project we had won. It was later used in many other automation contracts, and in fact is still running some fabs 24x7 yet today.

    The rewrite I have done myself, taking all the concepts and lessons learned and using more modern tools, such as a modern Parser Generator. The original was done with Yacc/Lex.

    Re: Open Sourcing it... I have never really understood the benefit to giving away software, unless it's something that warrants a group effort in development. And for those, my experience so far has been if it's needed, someone will usually fund the development. But, I am still open to the idea of open sourcing it.

    john-j-mclaughlin
    @john-j-mclaughlin

    Here's a trivial example of the new version. It shows only a few of the features but gives a decent introduction. Since I did not want to repeat the previous approach (full ANSI C parsing, or in this case Go) I enclose the desired "target language" fragments in ${ ... $} blocks. Handler code can (but is not required to) be added to any event or timer handler, as well as to state entry and/or exit blocks. As I mentioned, there's a lot more possible with events (matching and delivery options), and more state constructs, as well.

    https://gist.github.com/john-j-mclaughlin/6c1b3912b40ca78fdab3c2bef0e24e4b

    Let me know if you have questions.

    Mark Truluck
    @frame-lang
    Cool! Looks like an elegant syntax. I would like to know a lot more. What is the language called? Do you have any documentation?
    Mark Truluck
    @frame-lang
    I've started a wiki to track release goals and work here: https://github.com/frame-lang/frame_transpiler/wiki/Framepiler-v0.6