Hi Andrew, sorry, I overlooked your post, somehow ...
On Monday, March 28, 2016 at 3:47:42 AM UTC+2, Andrew Keller wrote: > > Just a heads up that I've been working on something similar for the past > six months or so. > Very nice - I'm open collaborate on this topic, of course. At the moment, we're still actively using my Scala/Akka based system https://github.com/daqcore/daqcore-scala) in our group, but I'm starting to map out it's Julia replacement. daqcore-scala currently implements some VME flash-ADCs and some slow-control devices like a Labjack, some HV Supplies, vaccuum pressure gauges, etc., but the architecture is not device specific. The Julia version is intended to be equally generic, but will initially target the same/similar devices. I'd like to make it more modular, though, it doesn't all have to end up in one package. One requirement will be coordinated parallel access to the instruments from different places of the code (can't have one Task sending a command to an instrument while another task isn't done with his query - which may span multiple I/O operations - yet). Also multi-host operation for high-throughput applications might become necessary at some point. The basis for both came for free with Scala/Akka actors, and I started Actors.jl (https://github.com/daqcore/Actors.jl) with this in mind. Another things that was easy in Scala was representing (potentially overlapping) devices classes using traits. I'm thinking how do best do this in Julia - but due to Julias dynamic nature, explicit device classes may not be absolutely necessary. Still, I'd like to used as much explicit typing as possible: When dealing with hardware, compile-time checks are very much preferable to run-time checks with live devices (can't afford to implement a full simulator for each device). :-) As I've been working on this since I started learning Julia, there are a > number of things I did early on that I regret and am now fixing. One thing > you'll find becomes annoying quickly is namespace issues: if you want to > put different instruments in different modules, shared properties or > functions > Yes, that was one of the reasons I wanted to explore getindex/setindex, it avoids namespace conflicts on the functions. Of course this shifts the issue to the device feature classes, but I hope that a central package can host a set that will cover most devices (and be open to people contributing additional common features). Highly device-specific features can live within the namespace of the package implementing the device in quesiton, and shouldn't be exported. For instance, on a vector network analyzer you could write something like: > > vna[Frequency] = 4GHz:1MHz:10GHz > Yep, this is exactly what I had in mind. Of course there will also have to be a producer/consumer mechanism for devices with high-rate/continuous output (e.g. fast waveform digitizers). Channels and/or actors are an attractive approach. and thereby set frequency start, stop, and step at once. I have a units > package for Julia v0.5 that I'm also developing when I have the time ( > Unitful.jl <https://github.com/ajkeller34/Unitful.jl>) > I've seen Unitful.jl - how does it compare to SIUnits.jl, especially performance-wise? Are they orthogonal or two approaches to the same problem? Cheers, Oliver
