Hi Oliver, 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. There is some discussion of how methods are dispatched, as well as compiler efficiency issues. 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, mainly because I'm not sure what a sensible benchmark would be. If you'd like me to try out something I'll see what I can do.
It sounds like you have probably been thinking deeply about instrument control for a much longer period of time than I have. I'll write you again once I've gotten our codebase more stable and documented, and I welcome criticism. I haven't given much thought to coordinated parallel access yet but I agree that it will be important. A short summary is that right now we have one package containing a module with submodules for each instrument. Each instrument has an explicit type and most methods are generated using metaprogramming based off some template for each instrument type. Most instrument types are subtypes of `InstrumentVISA`, and there are a few methods that are assumed to work on all instruments supporting VISA. I must say, it is not obvious what the best type hierarchy is, and I could easily believe that traits are a better way to go when describing the functionality of instruments. You can find any number of discussion threads, GitHub issues, etc. on traits in Julia but I don't know what current consensus is. Unitful.jl and SIUnits.jl globally have the same approach: encode the units in the type signature of a value. Accordingly, Unitful.jl should have great performance at "run-time," and is a design goal. Anytime some operation with units is happening in a tight loop, it should be fast. I have only had time to look at some of the generated machine code but what I've looked at is the same or very close to what is generated for operations without units. I have not optimized the "compile-time" performance at all. Probably the first time a new unit is encountered, some modest performance penalty results. I'd like to relook at how I'm handling dimensions (length, time, etc.) because in retrospect I think I'm doing some odd things. An open question is how one could dispatch on the dimensions (e.g. x::Length). I tried this once and it sort of worked but the type-gymnastics became very ugly, so maybe something like traits would be better. Last I checked, the two packages are different in that Unitful.jl supports: rational powers of the units (you can do Hz^(1/2), useful for noise spectra); non-SI units like imperial units; the ability to add new units on the fly with macros; preservation of exact conversions. My package only supports Julia 0.5 though. I think the differences between the packages arise mainly because SIUnits.jl was written when Julia was less mature. SIUnits.jl is still sufficient for many needs and is remarkably clever. Thanks for linking to your code. I have no experience with Scala but I will take a look at it. Best, Andrew On Saturday, April 2, 2016 at 4:45:04 AM UTC-7, Oliver Schulz wrote: > > 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? >
