Ivory looks interesting. But what does DSL mean (in your post)?
On Monday, September 15, 2014 11:55:03 AM UTC+2, Tony Kelman wrote: > > The initial goal is packaging up conventional Julia code with the > conventional runtime and GC, so no you don't get determinism from that. > Even with explicit memory management you're unlikely to get true hard > real-time determinism unless your code is running on a specialized RTOS > anyway, and those are very restricted environments where nothing aside from > C or a limited subset of C++ is likely to be allowed anyway. Unless you > want to write at that low level, you'll need a DSL to design the > allocation-free purely computational parts of a controller, and the > communication and synchronization algorithms. Galois has done a lot of work > on this kind of thing hosted in Haskell, see their Ivory and Tower DSL's. I > don't know of anyone doing this kind of work in Julia yet, but it would be > cool to see, and in my non-expert opinion I think it should be feasible. > > > On Monday, September 15, 2014 2:26:41 AM UTC-7, Andrew Wagner wrote: >> >> Hi Tony and Uwe! >> >> Sorry, I'm more aware of these issues than I indicated in my post. Of >> course one or two steps of code generation / specialization is necessary to >> get from human readable to machine executable code. >> >> I was actually sitting here reading the thread about the improved garbage >> collector that is in development. Compared to the stack, RAII, and >> reference counting, this still sounds like a mess if you want deterministic >> timings... >> >> Thanks for the info about the standalone executables, Tony; I'll go read >> that too later. If it's just packing up everything into one executable >> that still has very non-deterministic timings when you run it, it's not a >> win for control, of course, but maybe the plan is to also do more >> aggressive specialization of parts of the code (no gc? static binding? >> stack only?) at the same time; I will go read! >> >> Thanks for the anecdote about your experience using Python in the loop >> Uwe; that's interesting! >> >> Cheers, >> Andrew >> >> On Mon, Sep 15, 2014 at 10:45 AM, Tony Kelman <[email protected]> wrote: >> >>> You don't write in assembly, do you? Every stack is implicitly doing >>> multiple languages and some form of code generation in the process of >>> compilation, you just don't have to know whether it's happening. >>> >>> "Systems programming" as intended by Rust and as a software engineer >>> would mean the term is a rather different thing than what you want for the >>> purposes of embedded real-time control. There are plenty of embedded >>> environments where if you're allowed to use C++ at all, it's only a limited >>> subset, anything involving exceptions or RTTI is often not supported. It's >>> tough to audit 3rd-party libraries for these kinds of restrictions, and >>> achieve any kind of code reuse or non-trivial complexity. >>> >>> I'd say reducing the number of mandatory dependencies and making it >>> possible to statically compile Julia code into minimal standalone >>> executables and libraries is absolutely an explicit goal of the main Julia >>> developers, just check the 0.4-projects milestone on Github. It's not there >>> yet, but progress is being made. >>> >>> >>> On Monday, September 15, 2014 1:27:15 AM UTC-7, Andrew Wagner wrote: >>>> >>>> Hi Tony! >>>> >>>> I'm a bit burned out on software systems that are pieced together out >>>> of multiple languages, doing code generation, etc... If there's not a >>>> single language that can do everything I need for the project, I would not >>>> start it yet. It's really hard for me to tell at this point whether it is >>>> more likely in the future for Julia to become suitable for systems >>>> programming, or for rust to become suitable for interactive use... Those >>>> are explicitly non-goals for the main developers of the two languages, so >>>> it's hard to predict. >>>> >>>> Cheers, >>>> Andrew >>>> >>>> On Mon, Sep 15, 2014 at 8:27 AM, Tony Kelman <[email protected]> wrote: >>>> >>>>> Slicot's not ideal from a licensing standpoint, see the earlier >>>>> discussion from February in this thread. There is a GPL-licensed version >>>>> of >>>>> Slicot available from Debian, which works for the sake of a package. Long >>>>> term it makes more sense to reimplement the important parts of Slicot >>>>> that >>>>> wrap Lapack to provide Sylvester and Lyapunov and Riccati solvers for >>>>> discrete and continuous time, in base Julia. >>>>> >>>>> I think Jim Crist spent the summer doing a Python GSoC, so progress on >>>>> control packages for Julia has been mostly stalled. >>>>> >>>>> Eventually I think Julia could make a fine platform for code >>>>> generation of embedded controllers, hard or soft real time. Array views >>>>> and >>>>> the like will make this easier, but I don't see any reason you couldn't >>>>> refactor Julia code to do the vast majority of allocation up-front and >>>>> end >>>>> up generating more or less the same LLVM IR that Rust's compiler would. >>>>> And >>>>> I doubt Rust will ever be as good of an interactive technical computing >>>>> environment as Julia in terms of REPL, plotting, simulation, >>>>> experimenting, >>>>> etc. Compile-run-tweak cycles are not a convenient way to do control >>>>> design >>>>> (or much of anything, let's be honest). >>>>> >>>>> Generating embedded controllers in LLVM IR rather than C is currently >>>>> very atypical, but eventually I think it could be made to work. A Julia >>>>> replacement for "realtime workshop" is a good long-term goal. >>>>> >>>>> >>>>> On Sunday, September 14, 2014 12:58:36 PM UTC-7, Andrew Wagner wrote: >>>>>> >>>>>> Hello again Uwe! >>>>>> >>>>>> It's fun running into someone I know on a language geek forum :) I'm >>>>>> helping one of our bachelor's students implement an LQR controller on >>>>>> our >>>>>> carousel in Freiburg. It's an ugly hack, but I'm calling an octave >>>>>> script >>>>>> to recompute the feedback gains online. Octave wraps slicot, so if the >>>>>> licenses are compatible, perhaps wrapping slicot is the way to go for >>>>>> some >>>>>> functions, if the licenses are compatible. >>>>>> >>>>>> Personally, I have a burning desire for a better language we can >>>>>> actually do control in (rust?). I doubt Julia qualifies due to the >>>>>> garbage >>>>>> collection, but does anyone know if Julia has some sort of way to JIT >>>>>> Julia >>>>>> expressions to code that does ~not have any garbage collection? If so, >>>>>> is >>>>>> there a way to export them as object files and link against them from C? >>>>>> Then you'd still have to write glue code in a systems language, but at >>>>>> least the implementation of the controller wouldn't have to cross a >>>>>> language boundary... >>>>>> >>>>>> Cheers, >>>>>> Andrew >>>>>> >>>>>> On Thursday, February 20, 2014 10:56:20 PM UTC+1, Uwe Fechner wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I could not find any control system library for Julia yet. Would >>>>>>> that make sense? >>>>>>> There is a control system library available for Python: >>>>>>> http://www.cds.caltech.edu/~murray/wiki/index.php/Python-control >>>>>>> >>>>>>> Perhaps this could be used as starting point? I think that >>>>>>> implementing this in Julia >>>>>>> should be easier and faster than in Python. >>>>>>> >>>>>>> Any comments? >>>>>>> Should I open a feature request? >>>>>>> >>>>>>> Uwe Fechner, TU Delft, The Netherlands >>>>>>> >>>>>> >>>> >>
