01:02 <sb0> rjo, yes, this is a new check and warning that appeared with vivado 2018.1 (after I changed the clock)

01:02 <sb0> it doesn't seem to affect functionality, but I still think it should be fixed

01:02 <sb0> though xilinx being xilinx, you have to put the parameter on every idelay and not on the idelayctrl, which is nonsensical and unwieldy

01:04 <sb0> whitequark, it only adds numbers after other technique, it doesn't "just" do that, so without more information I cannot tell what the problem is

01:04 <whitequark> sb0: I figured it out I think

01:05 <whitequark> e.g. if there's a module a, submodule a.b, and signals a.b.s as well as a.s, it renames those to s0 and s1

05:58 <GitHub-m-labs> [misoc] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/misoc/commit/3fb4a55a52d4f343661372e85c386adf76b66a54

05:58 <GitHub-m-labs> misoc/master 3fb4a55 Sebastien Bourdeauducq: kasli: fix permissions

05:58 <sb0> whitequark, any comments on my idea of merging the artiq_core* tools?

06:11 <bb-m-labs> build #428 of misoc is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/misoc/builds/428

07:10 <sb000> what do you think of this? https://arxiv.org/abs/1703.05290

07:12 <sb000> is there a mass defect with non-nuclear interactions?

07:13 <sb000> (those guys are presenting tomorrow at the workshop where I am right now)

07:17 <larsc> isn't that the codename of vivado? (mass defect) ;)

13:31 <whitequark> sb0: sure that can be done

13:31 <whitequark> I mostly think it's needless churn

13:31 <whitequark> but I don't have a strong opinion one way or another

13:46 <GitHub-m-labs> [artiq] gkasprow commented on issue #854: Today I connected logic analyzer to the DIO header where RGMII Rx port was forwarded.... https://github.com/m-labs/artiq/issues/854#issuecomment-383936217

13:48 <GitHub-m-labs> [artiq] gkasprow commented on issue #854: @sbourdeauducq any idea why microscope don't see any packets? https://github.com/m-labs/artiq/issues/854#issuecomment-383937100

13:54 <GitHub-m-labs> [artiq] gkasprow commented on issue #854: funny thing, with RGMII pins forwarded to DIO, the Microscope sees some packets... https://github.com/m-labs/artiq/issues/854#issuecomment-383939250

14:01 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #854: What is the code you are using for Microscope?... https://github.com/m-labs/artiq/issues/854#issuecomment-383942234

14:06 <GitHub-m-labs> [artiq] gkasprow commented on issue #854: no, U cannot connect it directly, At the moment the Microscope samples only rising edge data.... https://github.com/m-labs/artiq/issues/854#issuecomment-383943975

14:07 <GitHub-m-labs> [artiq] gkasprow commented on issue #854: @marmeladapk added RGMII converter and it works 😀 https://github.com/m-labs/artiq/issues/854#issuecomment-383944649

14:10 <GitHub-m-labs> [artiq] marmeladapk commented on issue #854: @sbourdeauducq I think it was my fault - I wrote (or more like copy-pasted) it second time and it works. Code looks like it was duct-taped together. https://github.com/m-labs/artiq/issues/854#issuecomment-383945703

14:45 <rjo> terrible. these emojis survive all the way through the browser, github, irc, weechat, tmux, mosh, tmux, terminal...

14:49 <cr1901_modern> What's wrong w/ emojis besides indicating the decay of civilized society?

14:51 <whitequark> terrible? quite the opposite, they work brilliantly right, preserving semantics of text across any amount of transformation

15:06 <rjo> what? they don't even have well defined semantics, and whatever "meaning" they have gets mangled all the time.

15:07 <rjo> aside: why don't they work as python identifiers while other unicode does? https://hastebin.com/cixejixipo.rb

15:09 <whitequark> because python's unicode implementation is broken?

15:10 <whitequark> lots of software doesn't handle astral plane characters correctly

15:19 <rjo> my point exactly. they don't really work. neither technically nor semantically.

15:20 <whitequark> um, what?

15:20 <whitequark> python is the broken part here

15:20 <whitequark> ruby has no issues:

15:20 <whitequark> irb(main):002:0> 😀 = 1

15:20 <whitequark> => 1

15:24 <larsc> https://www.python.org/dev/peps/pep-3131/

15:26 <whitequark> exposing broken unicode implementations is quite good, actually

15:26 <whitequark> emoji did more for adoption of unicode than any single other phenomenon

15:50 <rjo> what a wild and unsubstantiated claim! that statement is obviously bullshit: just take "other phenomenon" == "unicode definition". and what data do you have that i18n is not the main driver for unicode? the applications of emojis and the problems they solve for technology-saturated and pampered individuals are completely dwarfed by i18n and the other scripts.

15:56 <rjo> larsc: but that pep is implemented and doesn't seem to mention why some unicode would not work.

16:00 <whitequark> rjo: it's the other way around.

16:01 <whitequark> no one cared enough about baseline technologies required for i18n and "other scripts" until emoji came around and it stopped being viable to not support anything properly that wasn't ASCII

16:02 <whitequark> and you using "unicode definition" as "other phenomenon" is just irrelevant sophistry

16:02 <whitequark> I said "adoption", that, ahem, obviously implies that it happens after the standard is released

16:06 <rjo> i think you want to rephrase your state and restrict that from any other phenomenon in the universe to use case for unicode. but it's still an unsubstantiated claim. it would imply that unicode was flawed before 2010 and that getting emojis into unicode was somehow revolutionary. both simply note the case.

16:07 <rjo> *statement

16:07 <rjo> *are simply untrue

16:07 <whitequark> it doesn't imply that, and I don't think either of those two statements are true

16:08 <whitequark> emoji are fundamentally superficial, but fundamentally superficial things may well drive adoption of fundamentals

16:09 <whitequark> for example, many applications of smartphones are superficial, but those subsidized creation of cheap and accessible modern communication in many places where previously was none

16:09 <rjo> sure. in general and maybe. but what's your evidence in this case?

16:10 <rjo> weren't the hundreds of millions of non-ascii smartphone users back in 2010 driving unicode adoption before any emoji made it there?

16:12 <whitequark> sure, it's not like there *wasn't* unicode adoption, it's that it was incomplete and often broken

16:13 <whitequark> there was essentially no incentive to implement and test support for astral plane characters, so few did it

16:17 <rjo> you seem to be reducing unicode to astral plane. if you imagine taking away astral plane stuff versus taking away bmp then what would have the bigger impact?

16:19 <whitequark> my point is if you're implementing unicode but don't handle astral plane correctly you haven't actually implemented unicode

16:20 <whitequark> if we restrict the scope to BMP then the impact is much smaller, yes

16:21 <whitequark> I'm essentially putting emoji to the same role as the web browser ACID tests back in the day. stress the implementation to make sure it is, in fact, compliant, and not just handling the more common cases

22:39 <GitHub100> [smoltcp] barskern commented on issue #104: I've been reading the documentation, and started to dig into the code. Today I've been trying to write a test to isolate a situation where a fast retransmit would occur, however it doesnt seem to be right. Currently the test looks like this:... https://github.com/m-labs/smoltcp/issues/104#issuecomment-384102123