Domain specific language. Sometimes with an E in front for "embedded" domain specific language, meaning a DSL embedded within a different general-purpose language as opposed to a standalone DSL that only does one thing. (not the type of embedded that the rest of this conversation has been about)
On Monday, September 15, 2014 3:13:42 AM UTC-7, Uwe Fechner 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 >>>>>>>> >>>>>>> >>>>> >>>
