So, since we got you on this thread, Stefan - what's your take on the original question? :-)
I mean, is it Ok to have (potentially) thousands of methods for getindex and setindex, or will this have serious consequences for compile time and/or dynamic dispatch situations? On Sunday, April 3, 2016 at 6:57:23 PM UTC+2, Stefan Karpinski wrote: > > No worries. I just wanted to provide a link for context. > > On Sun, Apr 3, 2016 at 12:49 PM, Oliver Schulz <[email protected] > <javascript:>> 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 >>>> >>>> >>> >
