| *** tpb has joined #tomu | 00:00 | |
| *** xkapastel has quit IRC | 01:26 | |
| *** rohitksingh has joined #tomu | 02:16 | |
| *** rohitksingh has quit IRC | 02:24 | |
| *** cdmatter has joined #tomu | 04:16 | |
| *** rohitksingh has joined #tomu | 06:49 | |
| *** rohitksingh has quit IRC | 07:21 | |
| *** cdmatter has quit IRC | 07:22 | |
| *** rohitksingh has joined #tomu | 07:24 | |
| *** cdmatter has joined #tomu | 07:41 | |
| *** ppisati has quit IRC | 09:02 | |
| *** ppisati has joined #tomu | 09:11 | |
| *** rohitksingh has quit IRC | 09:28 | |
| *** xkapastel has joined #tomu | 10:11 | |
| *** cdmatter has quit IRC | 11:23 | |
| *** cdmatter has joined #tomu | 11:57 | |
| *** bluebugs has joined #tomu | 12:37 | |
| *** bluebugs has joined #tomu | 12:37 | |
| *** cedric has quit IRC | 12:38 | |
| *** xkapastel has quit IRC | 12:50 | |
| *** js`xmpp has joined #tomu | 13:06 | |
| *** xkapastel has joined #tomu | 14:38 | |
| *** emeb has joined #tomu | 14:40 | |
| MadHacker | ovf: Miss out the wrap() in that example and it fails to build./ | 18:20 |
|---|---|---|
| MadHacker | There are less obvious failure modes too, where it just generates *wrong* output as a result of the early-exit behaviour of "and" (vs. &). | 18:20 |
| MadHacker | I think if you avoid "and" and "or", all the failure modes result in an exception, though. | 18:22 |
| MadHacker | Use & and | and you should be good. | 18:22 |
| ovf | MadHacker: thanks! not specifically migen's fault, then -- `and` and friends in python are syntactic sugar, not binary operators (x and y is special syntax for !x?0:y in c) | 19:11 |
| MadHacker | Well, it's migen's in the sense that it's a python binding, but yes, it's something unfixable. | 19:12 |
| MadHacker | In older python you could abuse __coerce__ to try and stop that happening (by blocking any coercion to bool) but I think __coerce__ went away in 3. | 19:12 |
| MadHacker | I can live with it, personally. | 19:13 |
| MadHacker | Needing wrap() on the simpler cases, however, is just plain weird. | 19:13 |
| ovf | yes, it's definitely an expected downside of embedding an ast builder in a general purpose language, but i didn't have doubts about that. :-) | 19:13 |
| MadHacker | As you say. :) | 19:13 |
| *** rohitksingh has joined #tomu | 19:16 | |
| ovf | your paste seems to have perished but i thought you shouldn't have needed wrap() there as the lhs of both subexpressions was a migen.Signal? | 19:16 |
| MadHacker | https://pastebin.com/pUw0QKUu have a fresh paste. | 19:17 |
| tpb | Title: jamie@t2:/tmp$ cat minimal_demo.py from migen import * from migen.fhdl.v - Pastebin.com (at pastebin.com) | 19:17 |
| MadHacker | D'you know, I think I'm wrong. I think it was always just an operator precedence issue. | 19:19 |
| MadHacker | It's not the wrap, it's the (). <embarrassed> | 19:19 |
| MadHacker | Yeah. The way the precedence rules work, minus the wrap() and the brackets, you end up with 7 & self.B in the middle, and that's why you get the TypeError about converting a Migen value to a boolean. | 19:21 |
| MadHacker | Hm, maybe not? Still wrong. | 19:21 |
| MadHacker | No, it's even weirder. I don't know now. https://pastebin.com/7xjvJdZG | 19:23 |
| tpb | Title: [Python] >>> from migen import Signal >>> a = Signal() >>> b = Signal() >>> a == 7 (at pastebin.com) | 19:23 |
| MadHacker | https://pastebin.com/LKw0MNgh more complete. | 19:24 |
| tpb | Title: [Python] >>> a = Signal() >>> b = Signal() >>> a == 7 (at pastebin.com) | 19:24 |
| MadHacker | It's even weirder. | 19:24 |
| ovf | >>> (a==7&b).op | 19:48 |
| ovf | '==' | 19:48 |
| ovf | comparison operators have lower precedence than arithmetics (like &) | 19:49 |
| ovf | a==7&b==7 is in fact python's chained comparison (you usually use it in slightly more useful form, like 2<x<5). another syntactic shortcut (like and) that makes your migen experience miserable. :-) | 19:50 |
| *** rohitksingh has quit IRC | 20:00 | |
| *** xkapastel has quit IRC | 20:18 | |
| *** rohitksingh has joined #tomu | 20:19 | |
| *** pollo has quit IRC | 20:21 | |
| *** pollo has joined #tomu | 20:22 | |
| *** rohitksingh has quit IRC | 21:48 | |
| *** js_ has joined #tomu | 21:51 | |
| *** js has quit IRC | 21:52 | |
| *** js_ is now known as js | 21:52 | |
| *** andi- has quit IRC | 22:03 | |
| *** techman83 has quit IRC | 22:10 | |
| *** techman83 has joined #tomu | 22:10 | |
| *** feuerrot has quit IRC | 22:11 | |
| *** andi- has joined #tomu | 22:11 | |
| *** feuerrot has joined #tomu | 22:15 | |
| *** emeb has quit IRC | 22:40 | |
| MadHacker | ovf: That makes sense, but the net effect is still that it's really quite surprising when it gets it wrong. :) | 22:40 |
| *** rohitksingh has joined #tomu | 22:44 | |
| ovf | indeed. at least in this case, you've got a compile-time error (although rather cryptic), not a silent failure. i generally find operator precedence confusing and unnecessary, and one's better off with all operators having the same precedence: back where i come from, 2*2+2 is 8 (and 2+2*2 is 6). | 23:03 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!