<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1007: With all the time that this painful issue is taking, it seems that meanwhile a number of people have been using development versions that have the problem. How much of an impact does it actually have? Does it make sense to delay releases further? @cjbe @dhslichter @jordens https://github.com/m-labs/artiq/issues/1007#issuecomment-427706450
<sb0>
"Defined in nature by their atomic structure, our trapped-ion qubits can be uniformly manufactured and controlled more easily and quickly compared to alternative qubit technologies that do not directly use atoms. This is why we use the term “Nature’s Qubit”, for our systems - our qubits are all identical and defect-free. "
rohitksingh_work has joined #m-labs
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 260 seconds]
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 268 seconds]
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1155: @jordens I only fixed it on the switching (and switching125) branch for now, will merge switching into master after @hartytp tests it. The commit you mention is on master. https://github.com/m-labs/artiq/issues/1155#issuecomment-427786445
<GitHub-m-labs>
[artiq] jordens commented on commit 469a66d: I know. But I need it in the master branch. I don't need the switching branch and I don't want to wait for that to stabilize. Since it's a bug in master that seems fair. It's going to be two small straightforward conflicting hunks for you to resolve. https://github.com/m-labs/artiq/commit/469a66db61da4c40d72b8627053821df169a8dbe#commitcomment-30812461
<GitHub-m-labs>
[artiq] dhslichter commented on issue #1007: Agreed, having a 4 release would be very good. In the lab, we are only running on release versions, not dev versions, and just suffering through bugs for now while we wait for new releases. We could run on dev versions, but we tend to be paranoid about upgrading in the middle of data-taking for a given experiment. The Magtrap will upgrade directly from ARTIQ 2 to
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1007: No, this issue is not related to compilation speed. It slows down *execution* in several cases where floating point is used, and can be worked around by using the ``_mu`` functions.... https://github.com/m-labs/artiq/issues/1007#issuecomment-427861889
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1007: @dhslichter Is the scan slowness you mention due to #804 or another already reported issue? If not, can you open a new one with a repro? https://github.com/m-labs/artiq/issues/1007#issuecomment-427862640
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #1007: @dhslichter Is the scan compilation slowness you mention due to #804 or another already reported issue? If not, can you open a new one with a repro? https://github.com/m-labs/artiq/issues/1007#issuecomment-427862640
<GitHub-m-labs>
[artiq] dhslichter commented on issue #1007: We use the `_mu` functions always just because it has always provided better performance. I would go ahead and release all the other bug fixes in 3.7, and let this one slide to version 4. In the balance of making things better/easier for new users vs. bringing bug fixes to current users, I think here the best way to go is to push bug fixes for current users while w
<GitHub-m-labs>
[artiq] dhslichter commented on issue #1007: @sbourdeauducq I am not sure if it is due to #804 or another, to be honest I haven't tried benchmarking it. I have just noticed that it happens. I will write up some code to test this out and open a fresh issue if it appears to be unrelated to existing stuff. First I need to figure out if there is a particular feature of the code that is causing it... https://
<GitHub-m-labs>
[artiq] dhslichter commented on issue #1007: More about the core device flashing issues; we get paranoid about doing this in a live experiment unless we have to. Note that this is just generally true for changing/upgrading any component of the experiment that is not the fundamental limit on the experiment's performance -- including lasers, electronics, cryogenics, etc. The time for upgrades is while the paper
m4ssi has quit [Remote host closed the connection]
rohitksingh has joined #m-labs
rohitksingh1 has quit [Ping timeout: 252 seconds]
<rjo>
bb-m-labs: force build --props=package=artiq-board,artiq_target=kasli,artiq_variant=vlbaisatellite artiq-board
<bb-m-labs>
build forced [ETA 16m32s]
<bb-m-labs>
I'll give a shout when the build finishes
<rjo>
bb-m-labs: force build --props=package=artiq-board,artiq_target=kasli,artiq_variant=vlbaimaster artiq-board
<bb-m-labs>
The build has been queued, I'll give a shout when it starts
<GitHub-m-labs>
[artiq] dhslichter commented on issue #1007: > That way, when the reviewers ask you to take some extra piece of data you can reply "sorry, broke the experiment already, no can do!" :)... https://github.com/m-labs/artiq/issues/1007#issuecomment-427899151
<GitHub-m-labs>
[artiq] jordens commented on pull request #1170 95217d3: That's the question. Is it worth trying to unify the cpld gateware over v1.2 and v1.3, not icrement the protocol and ignore the missing functionality on v1.2 **or** should we be strict and add the complexity of supporting multiple protocol versions and different gateware for different hardware.... https://github.com/m-labs/artiq/pull/1170#discussi
<GitHub-m-labs>
[artiq] jordens commented on pull request #1170 95217d3: Yes. Sorry, I meant: I am leaning towards keeping the protocol version and documenting the NOP-ness of clk_sel1 on old hardware it in the constructor. https://github.com/m-labs/artiq/pull/1170#discussion_r223501743