(E)DSL is a buzzword functional programming people use that really just means "API".
On Mon, Sep 15, 2014 at 12:16 PM, Tony Kelman <[email protected]> wrote: > 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 >>>>>>>>> >>>>>>>> >>>>>> >>>>
