<whitequark>
ok, so the problem here is, [1] allocates a new list
<whitequark>
on the stack frame of f
<whitequark>
but if you assign a pointer to that to x, it'll escape
<whitequark>
and eventually get corrupted.
<rjo>
with "does not live forever" you mean "does not have a global binding" or "does not live in the enclosing scope"?
<whitequark>
neither, but the former is the closest
<whitequark>
whether there is a global binding doesn't matter, but it matters if it was allocated in the global scope
<whitequark>
since everything allocated in the global scope lives forever.
<whitequark>
I considered the "does not live in the enclosing scope" behavior, but it would require adding parametric polymorphism to a type system which currently lacks it
<rjo>
you seem to be trying to map the language of "pointers" etc to python...
<rjo>
or more like the ownership problem.
<whitequark>
Python works as-if all immutable values were passed by-value and all mutable values were passed by-reference
<whitequark>
and in many cases it literally works that way internally
<whitequark>
what I'm doing is making a strict Python subset that allows me to do all allocations in the stack frame of the current function
<whitequark>
sure, some of the low-level nature of this leaks. I hope the error messages and a little clarification would be enough
<rjo>
a heap-/mmu-free python subset?
<whitequark>
it's the ownership problem, yes. the stack frame owns the data and deallocates it when it is popped
<whitequark>
yeah
<whitequark>
basically, every allocation here is an alloca
<whitequark>
even in global initialization--conceptually, the module-level code is in a function that calls the next function with module-level code that...
<whitequark>
and none of them ever returns, which allows me to stash the allocations made by alloca into global bindings
<rjo>
hmm. i see why these error messages get your juices flowing. but it took me a while to differentiate my knowledge of what i can do in python with what you are telling me i can not do in artiq-python.
<whitequark>
it doesn't have to be this way, but sb0 wants no heap. so I did with no heap
<whitequark>
I think this is the best you can do with Python and no heap
<rjo>
i can believe that.
<whitequark>
and I think it allows quite a bit of the power of python. passing various closures around, that can even refer to upvalues
<rjo>
with a heap there would be gc and less timing determinism. is that the reason?
<whitequark>
given the few days of the development days I had for this system.
<whitequark>
yeah.
<whitequark>
I could easily add heap later, you'd do something like x = heap([1, 2, 3])
<whitequark>
in principle, the region inferencer could fall back to heap automatically, but that makes it harder for a human to reason about the performance, so it is probably a worse idea
<whitequark>
even if it looks easier to use
<rjo>
ok. being able to restrict python to heap-less in a well-defined way is an interesting achievement. nice! i believe and hope people won't hit the limits too frequently (in artiq).
<whitequark>
I have a few more tricks up my sleeve if they do
<whitequark>
but it's not worth implementing right now
<rjo>
hmm. i don't like how you count characters and lines from "1" but i guess that's how people do it... ;)
<whitequark>
I haven't seen anything that counts the lines from 0
<whitequark>
OCaml counts characters from 0, it breaks my editor, and it's annoying as hell
<whitequark>
but I don't have an opinion, really, I can switch it
<whitequark>
do you use emacs, perchance?
<rjo>
nah. keep it. i am spoiled by 0-indexed things.
<rjo>
no. vim
* rjo
gets out his emacs-orcism tools.
<whitequark>
haha no, i don't use emacs. emacs doesn't have a problem dealing with 0-indexed characters
<whitequark>
i use *grin* sublime text three
<rjo>
what do you use to edit stuff on a remote machine?
<whitequark>
nano, if there's nano. vi, if there's no nano. mcedit, if I want automatic indentation, because I don't know how to make the former two do it. sshfs and sublime text, if I have a lot of text
<whitequark>
or, well, just put it in git
<rjo>
mcedit! yay!
<whitequark>
haha, that's usually not the reaction people have when i mention mc
<whitequark>
if the above sounds contrived to you, i should tell you about that time i learned OpenGL and Cocoa by running a non-hackintosh OS X paravirtualized inside KVM on my Linux machine
<whitequark>
... while also ensuring that the same codebase builds in MSVC 2013 on Windows XP
<whitequark>
... voluntarily.
<rjo>
if you do cocoa you should dive right into the artiq-gui and do qt!
<whitequark>
yeah, sb0 already hung a Windows Qt internals bug on me :]
<whitequark>
I can't design a decent GUI if my life hinged on it, but if someone else draws the layout, I can do that
<rjo>
yes. ui stuff is very unrewarding.
<whitequark>
when i did websites, the frontend engineers were quite happy about it. conversely, i was quite happy to take their work and pull it over a decent backend
<whitequark>
but I have never seen a person who would be both happy about doing both and able to actually do it well, or a reliable way to assemble a functional team that does UI, outside of webdev
<whitequark>
this is, I think, one reason why so much software came to converge on using webkit as an UI framework. not as much it being a good fit, but more the good availability of competent developers and designers
<whitequark>
I'm sure you could teach a frontend engineer to work with qt, but it would not be a good business objective
<cr1901_modern>
I've been trying hiro to build my GUIs. It's C++14, but I think it might be worth it in this cae.
<rjo>
i don't think web-uis (and then using webkit) are better than classic ui toolkits.
<rjo>
c++14! does that have hyper-templates?
<cr1901_modern>
I have no idea what hyper templates are. I can barely read C++11
<rjo>
exactly.
<whitequark>
I absolutely don't think that. the only thing I'm saying is that there are readily available people who can make a decent GUI on top of it, because they are good at their jobs
<whitequark>
not so much for Qt
<rjo>
that might be true.
<whitequark>
c++14, uh, fixes a few warts introduced by c++11
<rjo>
i was floating the idea of a web-ui for artiq a while ago but since my experience is also very limited i could never make a case.
<whitequark>
generally making the templates more orthogonal. you can forward arguments now and such
<whitequark>
it's not that big of a deal, mainly convenience
<whitequark>
I wouldn't do a web UI for ARTIQ without at least two people who are good at webdev.
<whitequark>
I can do a backend, sure, but without a dedicated frontend engineer it would be crap.
<cr1901_modern>
The problem for me is that C++11 looks nothing like the C++ I learned.
<whitequark>
been there, again and again
<whitequark>
you'd also need a designer, but that one's generally easy to hire and there's less work required from them
<whitequark>
I can try searching through the webdev people I've worked with, if someone's interested...
<whitequark>
cr1901_modern: wth is hiro? doesn't google
<rjo>
it would be a bit of an embarrassment if we do gtk -> qt -> web but hey. three is a charm.
<rjo>
hash it out with sb, i don't think people would be opposed here. and the amount of ui code written so far is still small.
<rjo>
conceptually a web-ui would be nice already because it is inherently client-server, something that is a bit of a pain now.
<whitequark>
cr1901_modern: that's an extremely niche and inflexible wrapper over gtk and qt
<rjo>
but each time i look at the internals of web-ui that appear to be slick and nice on the outside, i get physical reactions...
<rjo>
like wx?
<whitequark>
sorta
<cr1901_modern>
I think that was the point, tbh. byuu wasnt looking to create a totally new toolkit. Just ease the burden of making consistent UIs
<whitequark>
the interface it exports is decent, but it suffers from the same problem as all these projects: you need something simple, like, say, changing background color of a label
<whitequark>
and then you have to drop down into the unmanaged horror of the three platform toolkits it supports
<cr1901_modern>
I think the most recent posts in the linked thread are discussing some WINAPI warts based on that :P
<whitequark>
rjo: web UIs can be done decently. the trick is that there are vast swaths of knowledge required to do it, but the common understanding is that web APIs are 'simple to do'
<whitequark>
and 'everyone can do it after reading a book on PHP
<whitequark>
which predictably leads to disastrous results.
<whitequark>
it helps if you're writing the code on heroin AND meth
<cr1901_modern>
IMHO, GUIs are inherently unportable. I don't think the prerequisite for having a portable *anything* should be to code a web browser either.
<whitequark>
(see, I have a lot of webdev experience. trust me)
<cr1901_modern>
If browsers were gigantic clusterfucked monoliths, I probably wouldn't feel this way.
<cr1901_modern>
weren't*
<rjo>
whitequark: if you want to pitch this to sb, keep http://bokeh.pydata.org/ in mind. the proximity to ipython(-notebook) that al lot of us physicists love is somewhat appealing.
<whitequark>
GUIs are unportable in the sense that the platforms have their own visual languages
<whitequark>
well, windows has, OS X has, linux ...... well
<whitequark>
is linux.
<cr1901_modern>
Linux is technically Motif/Athena XD
<whitequark>
so as long as you want the GUI to match the visual language of the platform, which really good software should, you need three GUIs just because of that.
<whitequark>
/even if you could be using Qt/
<whitequark>
but of course you will soon discover that Qt's Cocoa support is more sub-par than S&P rating of the Greek debt
<whitequark>
rjo: d3 is very good.
<whitequark>
ohh yeah, bokeh is nice
<rjo>
i still get allergic reactions and the urge to throw up if i look at the javascript/css/html behind it.
<rjo>
for d3 and bokeh. all the same to me.
<whitequark>
haven't seen bokeh's internals but d3 is well-engineered. or at least, there are few javascript libraries made better than it
<whitequark>
i don't disagree though, i hate javascript
<rjo>
there was this one talk of a guy describing javascript in ~30 years...
<cr1901_modern>
Wrt visual styles, that is exactly what I meant. Ideally, I should have a Linux, BSD, OSX, and Windows machine to test on. And use MVC or whatever "Design Pattern of the Day" to abstract the GUI away somehow
<whitequark>
cr1901_modern: you can't abstract it away.
<whitequark>
not realistically. you can write three copies of it. I did it. it works, it produces a great GUI
<whitequark>
once you abstract it away, you get to compromise, and when you're ready to compromise, you can just as well do it once in Qt, it's not going to be noticeably worse
<whitequark>
s/you get to/you have to/
<cr1901_modern>
Aww, I thought I had a choice :'(
<whitequark>
free will is an illusion
<cr1901_modern>
Fair enough. I should know that by now anyway.
<cr1901_modern>
I don't mind writing three copies of a GUI. Although I pray it doesn't become a mess of #ifdefs when writing the code that calls the "update widgets"
<whitequark>
well, you need to abstract the backend
<whitequark>
now *that* is paramount, if you want it to function at all
ylamarre has quit [Remote host closed the connection]
ylamarre has joined #m-labs
<cr1901_modern>
Strictly speaking, I should just be using scipy (?) and matplotlib for my purposes. I need to calculate a complicated FFT, modify the time domain signal in real time, and then watch how the FFT changes.
ylamarre has quit [Remote host closed the connection]
ylamarre has joined #m-labs
<rjo>
cr1901_modern: if you are a physicist, you would prototype the algo in ipython-notebook, then speed it up with numpy/numba/python/theano/numexpr and then you might try bokeh.
<rjo>
matplotlib is no good for reatlime/interactive graphics.
<cr1901_modern>
That's what I was afraid of
<rjo>
or else use pyqtgraph.
<rjo>
why afraid?
<cr1901_modern>
Just an expression indicating that I expected plotting a real time graph to be involved. :P
<rjo>
if its _just a graph_ choosing bokeh/pyqtgraph/whatever is not that painful.
<rjo>
but yes. you are in ui yada-yada-land now...
<cr1901_modern>
All this to plot a freaking FFT and vary parameters (use case is a complex type of FM synthesis, fwiw)
<rjo>
use gnuradio/grc then.
<rjo>
might be just what you want.
<cr1901_modern>
Huh... I think I misunderstood what GNUradio was for...
<rjo>
it certainly does not need hardware if that is what you are asking.
ylamarre has quit [Remote host closed the connection]
ylamarre has joined #m-labs
_whitelogger has quit [Ping timeout: 252 seconds]
_whitelogger has joined #m-labs
aeris has joined #m-labs
sb0 has joined #m-labs
_florent_ has joined #m-labs
<GitHub163>
[artiq] fallen pushed 1 new commit to master: http://git.io/vqqtm
<GitHub163>
artiq/master 813a2a2 Yann Sionneau: conda: add missing udev rules files in the package
<ysionneau>
sb0: I don't remember if we settled something about xc3sprog, do we package it in a separate conda package and set it as a requirement for artiq pkg?
<ysionneau>
or we let the user install xc3sprog from source