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] > <javascript:>> 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 >> >> >
