No worries. I just wanted to provide a link for context. On Sun, Apr 3, 2016 at 12:49 PM, Oliver Schulz <[email protected] > wrote:
> Oh, darn - sorry, Stefan. I wanted to change the topic since the > discussion had moved quite a bit from the original question, but I didn't > consider email clients. > > On Sunday, April 3, 2016 at 2:06:06 PM UTC+2, Stefan Karpinski wrote: >> >> I'm afraid that changing the subject here removes all context for this >> message in most email systems. Groups seems to keep the message in context: >> >> https://groups.google.com/d/msg/julia-users/Dt6nbfhtaNQ/TCy6zT9HAAAJ >> >> On Sun, Apr 3, 2016 at 4:34 AM, Oliver Schulz <[email protected]> >> wrote: >> >>> Hi Andrew, >>> >>> On Saturday, April 2, 2016 at 7:10:00 PM UTC+2, Andrew Keller wrote: >>>> >>>> Regarding your first question posed in this thread, I think you might >>>> be interested in this documentation >>>> <http://docs.julialang.org/en/latest/devdocs/functions/> of how >>>> functions will work in Julia 0.5 if you haven't read it already. >>>> >>> >>> Yes, I'm aware that some big changes are coming with 0.5, and many of >>> them (e.g. threads and fast anonymous functions) are of course highly >>> relevant to this kind of application. For now I'm kinda stuck with 0.4 for >>> actual use cases, because so many packages (e.g. PyPlot, Gadfly, ...) have >>> trouble with 0.5 at the moment. But once 0.5 is ready, I will probably not >>> even try to keep things compatible with 0.4, as this is a new project >>> anyway. >>> >>> >>> I hope you don't mind that I've tried out your setindex and getindex >>>> approach. [...] It is very pleasant to use but I have not benchmarked it in >>>> any serious way [...] If you'd like me to try out something I'll see what I >>>> can do. >>>> >>> >>> Thanks, you're more than welcome! The more the merrier, and this can >>> only profit from wide testing. It would be good to try how this performs >>> with, say, about 500 feature types and 500 device types, each implementing >>> like 100 features. I hope this will still perform well in dynamic dispatch >>> situations - maybe one of the Julia experts can weigh in here? >>> >>> >>> It sounds like you have probably been thinking deeply about instrument >>>> control for a much longer period of time than I have. >>>> >>> >>> Well, thinking and learning a lot from my earlier mistakes. :-) >>> >>> >>> You can find any number of discussion threads, GitHub issues, etc. on >>>> traits in Julia but I don't know what current consensus is. >>>> >>> >>> I did play with some of the current approaches to traits in Julia a >>> while ago (Mauro's and Tim's work), and it's definitely something to watch >>> (I'd love to see something like that in Base some day). For now, I hope we >>> may be able to get by without explicit "device classes". >>> >>> >>> >>>> Thanks for linking to your code. I have no experience with Scala but I >>>> will take a look at it. >>>> >>> >>> Don't judge to harshly. :-) This has been a work in progress for many >>> years, and it is in active use for two long-term physics experiments and >>> multiple lab applications - but since it was always driven by our current >>> needs, I often didn't find time to port new ideas and concepts to older >>> portions of the code. One of the goals was always to use it for both >>> high-rate physics DAQ, and low-rate "slow-control"/SCADA applications. I >>> was planning a major overhaul, but recently decided that Julia will be a >>> better platform in the long run for various reasons (one of them that most >>> students don't have time to learn several programming languages, and Scala >>> isn't really an option for our kind of data analysis). >>> >>> Implementing specific devices has actually only been a fraction of the >>> work - a large part has always been implementing communication protocols. >>> For various devices, I needed (and implemented) VXI11, Modbus, SNMP, VME >>> (over ethernet bridge), CANOpen (for one speficic gateway), and various >>> vendor specific ASCII and binary protocols (e.g. Pfeiffer vaccum, old >>> Keithley ASCII, etc.). Plus things like an SCPI parser, etc.. I look >>> forward to port all of that to Julia - well, eventually ... ;-) >>> >>> I'd like the core to stay pure-Julia, though this will be challenging >>> with VXI11 and SNMP, as there's no native-Julia ONC-RPC or SNMP library. >>> And for devices that really need a vendor-specific VISA driver (because >>> SCPI over VXI11 is not enough) Instruments.jl ( >>> https://github.com/BBN-Q/Instruments.jl) may come in play (haven't >>> tried it yet). >>> >>> I'd love to work with other people interested in this - Julia is great >>> at making data analysis fast and easy, not reason it shouldn't be as great >>> at taking the data in the first place! >>> >>> >>> >>>> Unitful.jl and SIUnits.jl globally have the same approach [...] My >>>> package only supports Julia 0.5 though. [...]An open question is how one >>>> could dispatch on the dimensions (e.g. x::Length). >>>> >>> >>> Ah, right, now I remember - i kinda mixed up SIUnits and Unitful, sorry. >>> I did give Unitful a quick try when you announced it on the list, and I was >>> very impressed. But then I kinda had to force myself to put it aside for a >>> while, since I can't really switch to 0.5 yet. ;-) I do recall the >>> discussion about dispatching on units, though - that would be way cool, but >>> even without, Unitful will be a great ingredient to any Julia data >>> acquisition solution. >>> >>> >>> Cheers, >>> >>> Oliver >>> >>> >>
