RE Ivory and Tower, and similar efforts in Haskell, I am aware of them and I do find them really interesting. Since Rust is based on the same type theory as Haskell, I'm hoping similar things will be possible in Rust, without having an additional layer of code generation. I'm still trying to work out how much of the special sauce in Haskell is in the type system, and how much is in the "functional purity."
On Mon, Sep 15, 2014 at 12:13 PM, Uwe Fechner <[email protected]> wrote: > 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 >>>>>>>> >>>>>>> >>>>> >>>
