sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
fengling_ has joined #m-labs
fengling has quit [Ping timeout: 272 seconds]
<GitHub60> [artiq] jordens pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/e42fd9ca311e7ef57745ff2bfc6b42b1b68532b1
<GitHub60> artiq/master e42fd9c Robert Jordens: doc: use actual version
evilspirit has joined #m-labs
<rjo> whitequark: do we have to add artiq_builtin to all exceptions now? (https://github.com/m-labs/artiq/blob/master/artiq/devices/pdq2/mediator.py#L12)
fengling_ has quit [Ping timeout: 272 seconds]
fengling_ has joined #m-labs
<rjo> whitequark: what is the plan for binding builtins like min(), max()?
<whitequark> rjo: no, this is only necessary for exceptions which are raised from the runtime, using artiq_raise_from_c
<whitequark> all other exceptions are handled transparently
<whitequark> rjo: min/max have overloaded invocations (different sets/types of arguments) so they have to be explicitly handled in inferencer and codegen
<whitequark> those (and also the entry in types and prelude) are the only two places that need to be modified
<whitequark> if you feel adventurous you might look at adding those two by analogy with existing ones
evilspirit has quit [Ping timeout: 240 seconds]
<rjo> whitequark: i'll just file a bug about min/max so i don't forget that i already asked.
<rjo> whitequark: do we call our Python ARTIQlang or APython or ARTIQPython?
<whitequark> rjo: I prefer "ARTIQ Python"
<whitequark> it *is* a Python, I put way too much effort into ensuring that it is, in fact, a strict subset,
<whitequark> (with the exception of numerics, I guess)
<whitequark> and it's also a part of ARTIQ, so "ARTIQ Python" seems most fitting and also self-explanatory.
<rjo> then ARTIQPython is good to point out that it is a well defined and distinct thing and not just some random compound.
<whitequark> that seems excessively ugly to me
<whitequark> ARTIQ-Python maybe?
<rjo> fine
<GitHub0> [artiq] jordens pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/f0860beffd0143a543be3c76785c9a096fc5aee2
<GitHub0> artiq/master f0860be Robert Jordens: pdq2: wire up more of the pipeline
<rjo> you should be able to reproduce that Exception problem now. Want me to file a bug about it as well?
<whitequark> no, it's not a bug, but let me do something about it anyway
<rjo> is it a feature?
<whitequark> it's a side effect of having a type system, I guess?
<whitequark> raise Exception() works, raise Exception doesn't
<rjo> ah. do you want to handle that case or should i rewrite the code?
<whitequark> I thought about adding a diagnostic that suggests rewriting code
<rjo> good.
<GitHub148> [artiq] jordens pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/641ef57458a7c2a90e2c4f87437243c09744b197
<GitHub148> artiq/master 641ef57 Robert Jordens: pdq2/mediator: raise instances, not classes
<rjo> now i have to figure out why it takes 22s cpu to compile that.
<whitequark> any huge arrays?
<whitequark> well, nevermind, don't guess, use the embedding performance testbench
<GitHub53> [artiq] whitequark pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/3573a8750aa46860b03df94c213c83fd7be84303
<GitHub53> artiq/master 3573a87 whitequark: transforms.inferencer: give a suggestion on "raise Exception".
<whitequark> python3.5 -m artiq.compiler.testbench.perf_embedding foo.py
<whitequark> the class has to be named Benchmark and have a method run(), also you need device_db.py in the same directory as foo.py
evilspirit has joined #m-labs
siruf has quit [Ping timeout: 264 seconds]
siruf has joined #m-labs
ylamarre has quit [Quit: ylamarre]
rohitksingh has joined #m-labs
fengling_ has quit [Ping timeout: 272 seconds]
fengling_ has joined #m-labs
rohitksingh has quit [Ping timeout: 260 seconds]
balrog has quit [Ping timeout: 265 seconds]
balrog has joined #m-labs
rohitksingh has joined #m-labs
<whitequark> wtf
<whitequark> apparently NIST wrote a SIP library for Android that I seem to use?
ylamarre has joined #m-labs
sb0 has joined #m-labs
<sb0> rjo, i'd think something called "1.0" is more tested/debugged/maintained/supported than that...
<whitequark> just go the Chrome route. it's ok.
<sb0> the compiler merge is significant from a technical standpoint, and the git history shows that. but this release system is only about users...
<sb0> so again, i'd make 1.0 a later version, with the new compiler, which has users, and where bugfixes are backported in its branch for a while
<sb0> also we should probably have a roadmap document and release notes for the later stable versions
<sb0> release notes should list API changes and major features
<sb0> whitequark, what's wrong with "raise ExceptionClass"?
<sb0> it's explicitly documented and supported in python
<whitequark> excessive polymorphism...
<whitequark> if you really want it, open an issue, I will implement that
<sb0> ?
<whitequark> taking arguments of more than one type.
<whitequark> (where it's not really semantically warranted; min or such is OK.)
<sb0> for raise?
<whitequark> sure
<sb0> ok. well i'd consider that a pretty low priority for now
<sb0> how is the windows install and qt packaging going? we need to know if embedding craps out on windows and whether that needs to be fixed
<whitequark> I didn't do almost anything on that front
<whitequark> well, windows install should be straightforward, packaging will be weeks of pain
<sb0> weeks?
<whitequark> (hopefully less than weeks but... I don't even know)
<sb0> someone already made a qt5 package, can't that be copied?
<whitequark> I did copy that and see how much it gained me on Linux alone
<whitequark> (where we also don't have qt5 yet)
<whitequark> why can't conda use system qt5, anyway?
<sb0> that would maybe be okay on linux, but there is no system qt5 on windows
<whitequark> we have apt-get for a reason, no need to reinvent half of debian repositories because you have an extreme form of NIH
<whitequark> there is!
<whitequark> Qt provides Windows binaries
<sb0> hmm, more install steps for users...
<whitequark> no, we should be able to just repackage those
<whitequark> the key point being not having to rebuild the transitive closure of its dependenciees
<whitequark> Qt specifically supports relocatable installs using some configuration files (that the conda packages use already)
<sb0> ok, well, whatever works and doesn't introduce an additional installation step
<sb0> never underestimate how many mistakes users will make at every install step ...
<whitequark> sure
kmehall has joined #m-labs
[florian1 has joined #m-labs
felix___1 has joined #m-labs
tmbinc___ has joined #m-labs
kyak_ has joined #m-labs
kyak_ has quit [Changing host]
kyak_ has joined #m-labs
ylamarre has quit [Ping timeout: 264 seconds]
<sb0> rjo, is anyone looking into/cares about #65?
felix_ has quit [*.net *.split]
[florian] has quit [*.net *.split]
attie has quit [*.net *.split]
kyak has quit [*.net *.split]
larsc has quit [*.net *.split]
* sb0 wonders when we will find a linux kernel bug, to continue the tradition of making every piece of software we depend on crap out at some point
tmbinc__ has quit [*.net *.split]
kmehall_ has quit [*.net *.split]
folkert has quit [*.net *.split]
attie has joined #m-labs
lars__ has joined #m-labs
<GitHub145> [artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vzBIv
<GitHub145> artiq/master e664fe3 Sebastien Bourdeauducq: targets/kc705: fix DDS_RTIO_CLK_RATIO for AD9914. Closes #238
<bb-m-labs> build #94 of artiq-kc705-nist_qc1 is complete: Failure [failed conda_build] Build details are at http://m-labs-buildserver.lan/buildbot/builders/artiq-kc705-nist_qc1/builds/94 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<bb-m-labs> build #81 of artiq-kc705-nist_qc2 is complete: Failure [failed conda_build] Build details are at http://m-labs-buildserver.lan/buildbot/builders/artiq-kc705-nist_qc2/builds/81 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined #m-labs
<GitHub84> [artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vzBmw
<GitHub84> artiq/master cb5fd08 Sebastien Bourdeauducq: targets/kc705: fix e664fe3
mumptai has joined #m-labs
bob has joined #m-labs
bob is now known as Guest76298
<bb-m-labs> build #82 of artiq-kc705-nist_qc2 is complete: Success [build successful] Build details are at http://m-labs-buildserver.lan/buildbot/builders/artiq-kc705-nist_qc2/builds/82
Guest76298 has quit [Client Quit]
<bb-m-labs> build #95 of artiq-kc705-nist_qc1 is complete: Success [build successful] Build details are at http://m-labs-buildserver.lan/buildbot/builders/artiq-kc705-nist_qc1/builds/95
folkert has joined #m-labs
sb0 has quit [Quit: Leaving]
ylamarre has joined #m-labs
felix___1 is now known as felix_
ylamarre has quit [Ping timeout: 240 seconds]
FabM has quit [Quit: ChatZilla 0.9.92 [Firefox 43.0.4/20160105164030]]
ylamarre has joined #m-labs
rohitksingh has quit [Ping timeout: 255 seconds]
rohitksingh has joined #m-labs
evilspirit has quit [Ping timeout: 264 seconds]
mindrunner_ has joined #m-labs
bb-m-labs_ has joined #m-labs
mumptai has quit [*.net *.split]
bb-m-labs has quit [*.net *.split]
mindrunner has quit [*.net *.split]
kaalia has quit [*.net *.split]
fengling_ has quit [Ping timeout: 272 seconds]
kaalia has joined #m-labs
mumptai has joined #m-labs
evilspirit has joined #m-labs
[florian1 is now known as [florian]
[florian] has quit [Changing host]
[florian] has joined #m-labs
evilspirit has quit [Ping timeout: 265 seconds]
fengling_ has joined #m-labs
fengling_ has quit [Ping timeout: 272 seconds]
fengling_ has joined #m-labs
fengling_ has quit [Ping timeout: 272 seconds]
fengling_ has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
fengling_ has quit [Ping timeout: 272 seconds]
<rjo> sb0: i have never seen something called 1.0 that was tested/debugged/maintained/useful/supported. usually the things after 1.0 are interesting. but feel free to rename the branches and tags. i don't care as long as there is something at that revision.
<rjo> sb0: i am not aware of anybody looking into #65. iirc kevin was testing that previously.
fengling_ has joined #m-labs
mumptai has quit [Quit: Verlassend]
sb0 has joined #m-labs
<sb0> rjo, so essentially you want a tag right before the new compiler merge?
<rjo> sb0: yes. that is where i placed one iirc.
<sb0> whitequark, rjo: what is the decision regarding "storage of kernels"?
<sb0> rjo, ok, i'll rename that tag and see if i can find a way that it won't break the versioning system without creating a branch ...
<sb0> probably not
<rjo> sb0: that was in a "waiting for input from others" phase iirc. i would propose the following: determine wether this is still needed when the staging of kernels works, then, if yes, implement the thing with "divergent self".
<sb0> I don't like having a lot of stale branches laying around
<rjo> the problem is now that there is a 1.0 out there, conda won't voluntarily upgrade.
<sb0> we can also just keep the commit id in the wiki
<rjo> i don't care so much about the branch (since there would be nothing in that branch currently).
<sb0> i don't think the package was built, was it?
<sb0> only the master branch gets built
<rjo> and master is now 1.0+700something
<rjo> at least in the dev channel.
<sb0> wasn't the tag on the other branch?
<sb0> well fuck.
<sb0> that's the exact breakage I said I wanted to avoid above...
<rjo> there is no breakage yet. there will be if you insist on not calling that thing 1.0
<sb0> aaargh yes
<sb0> fuck
<rjo> but who cares if there is a highly publicized 1.0?
<sb0> aren't tags not local to branches?
<rjo> the tag is at the junction point. thus in both branches.
<sb0> meh
<sb0> well, now i either have to accept your solution, or deal with more conda support hell
<sb0> :(
<rjo> if you really want to save that 1.0 for something better, then we can just tell those few people to downgrade explicitly.
<rjo> that is also not hard.
<rjo> delete them now. nobody has downloaded them.
<GitHub46> [artiq] sbourdeauducq deleted 1.0 at de30a4b: https://git.io/vz0sC
<sb0> k i'll put the commit id on the github wiki
<rjo> impressive: qt5 pulls in wayland already on ubuntu 14.04...
ylamarre has quit [Ping timeout: 265 seconds]
<rjo> sb0: which id?
<sb0> de30a4b0603e18b35956ab1656c6a85303ce7f18'
<rjo> we can call that thing 0.1
<sb0> yeah, if you insist...
<sb0> bbl
sb0 has quit [Quit: Leaving]
<rjo> sb0: it saves us from having to maintain that wiki page and from having to point people at the wiki.
<whitequark> rjo: it's not strictly dependent on wayland, e.g. it is a separate package on debian
sb0 has joined #m-labs
<rjo> qt5-defaults -> gles -> egl -> wayland here. it strictly depends on it.
<whitequark> I think -defaults is a metapackage?
<rjo> almost. but that is pretty much irrelevant. there are also other dependency paths.
<whitequark> hm, odd, especially given Ubuntu's infatuation with Canonical's awful display server