excited-mango[m] | Hey, sorry I didn't see the invite earlier. That sounds awesome! I'm looking forward to it next week! | 03:45 |
---|---|---|
lkcl | excited-mango[m], email me, there's a reminder sent out each week, 24hr before. | 04:30 |
programmerjake | what fun, a compiler segfault: https://salsa.debian.org/Kazan-team/mirrors/ieee754fpu/-/jobs/2752048#L5565 | 09:52 |
lkcl | yep had one in /usr/bin/python3.7 as well last year | 10:15 |
programmerjake | ah, that one in cpython i think is a overflowed recursion limit...i saw a similar error when trying to leave out setup() in cldivrem's new fsm | 10:18 |
programmerjake | basically setup in the base class sees stage is set, so calls stage.setup, but never bothers to check if stage is self, so recurses infinitely | 10:20 |
programmerjake | if you have a sec, you could fix that. | 10:23 |
programmerjake | https://git.libre-soc.org/?p=nmutil.git;a=blob;f=src/nmutil/stageapi.py;hb=1ad8942d98f70aa237f2f2f86dbb0caa720ddf0c#l198 | 10:23 |
ghostmansd | OK, I surrendered and decided to post a message about this field to binutils mailing list :-) | 10:25 |
ghostmansd | Because, well, I know how to address it, but it means either re-implementing some parsing/emitting chunks of binutils all over again... | 10:25 |
ghostmansd | ...or heavily re-factoring what we have there for now. | 10:26 |
ghostmansd | I added Alan Modra, it looks like he's maintainer of PPC, plus, he replied to my first email | 10:29 |
programmerjake | https://sourceware.org/pipermail/binutils/2022-May/120775.html | 10:32 |
lkcl | programmerjake, no, it was an actual core-dump of the actual /usr/bin/python3.7 binary, not a "python exception as interpreted and caught and then displayed on-screen and the binary named /usr/bin/python3.7 exits normally". infinite recursion is something that should be caught by the python interpreter. | 11:12 |
lkcl | ok will take a look, should be easy to sort | 11:13 |
programmerjake | infinite recursion can be not caught by cpython if it runs out of stack space first...that ends up as a segfault | 11:13 |
programmerjake | e.g. it called some c extension that used a bunch of stack space and called back into python | 11:15 |
lkcl | true. | 11:15 |
lkcl | ahh i know why | 11:16 |
lkcl | i raised the recursion limit to be able to deal with massive yield usage in nmigen Simualtions | 11:16 |
lkcl | that's why | 11:16 |
programmerjake | ah | 11:16 |
lkcl | ghostmansd, oh? the one you sent a while back? | 11:30 |
programmerjake | he sent the email today, i linked to it | 11:32 |
programmerjake | or did you mean the first email? | 11:33 |
lkcl | i meant alan modra | 11:33 |
lkcl | i think ghostmansd means the message we planned a few months ago | 11:33 |
lkcl | programmerjake, done, added "if self.stage is not self" which is an actual-memory-object-based-compare not a call to __eq__. | 11:37 |
programmerjake | ah, process() has the same flaw, as well as checking `if self.stage` rather than `if self.stage is not None` | 11:40 |
lkcl | mumble mumble ok :) | 11:40 |
ghostmansd[m] | Yeah, few months ago Alan shared his vision on fields when I asked about it | 11:45 |
lkcl | ghostmansd[m], can you remember where it was? | 11:47 |
lkcl | so i can cross-reference it. we should have kept a record here https://bugs.libre-soc.org/show_bug.cgi?id=550 | 11:48 |
ghostmansd[m] | Yeah I posted it to task | 11:52 |
lkcl | ahh magic, thx. interested to hear what alain had to say | 11:57 |
lkcl | oh. er. i could only find this. https://sourceware.org/pipermail/binutils/2022-February/119633.html | 12:00 |
ghostmansd[m] | Yeah, that's basically all :-) | 12:23 |
ghostmansd[m] | But this actually was all we needed | 12:24 |
lkcl | ah :) | 14:12 |
ghostmansd[m] | Good news | 14:15 |
ghostmansd[m] | https://sourceware.org/pipermail/binutils/2022-May/120778.html | 14:15 |
lkcl | ah brilliant | 14:16 |
ghostmansd[m] | Yeah | 14:16 |
ghostmansd[m] | I frankly hoped for exactly this answer | 14:16 |
ghostmansd[m] | But decided to ask first, who knows what might happen if I touch this part | 14:17 |
ghostmansd[m] | Hic sunt dracones | 14:17 |
lkcl | i think, really, Power ISA v3.1 has kicked things close to the limit, especially with the really new instructions, Matrix-Multiply-Assist etc | 14:17 |
lkcl | hic sunt gloria mundae | 14:17 |
ghostmansd[m] | Yeah 241 already | 14:17 |
ghostmansd[m] | lol | 14:17 |
lkcl | remind me why we're doing quotes in latin? | 14:17 |
ghostmansd[m] | Let's hope it won't "transit" | 14:17 |
ghostmansd[m] | Well I've been learning it for 5 years | 14:18 |
* lkcl feels a need to break out into song with the "Pater Noster" | 14:18 | |
ghostmansd[m] | Makes sense for me lmao | 14:18 |
lkcl | which i can still remember, 42 years after having had to sing it every week for 5 years | 14:18 |
lkcl | pater noster qui es in coelis, santficicetum nostrum tuum | 14:18 |
lkcl | :) | 14:18 |
* lkcl thinks | 14:19 | |
ghostmansd[m] | I even know it's Greek origins | 14:19 |
lkcl | would it be worthwhile to... good god :) | 14:19 |
ghostmansd[m] | Hell I'm not even programmer officially, you know? | 14:19 |
ghostmansd[m] | I'm a Latin teacher | 14:19 |
ghostmansd[m] | Not kidding at all | 14:19 |
lkcl | would it be worthwhile to bring binutils up-to-date with mainline and submit a single one-off patch for that ppc_fix_extra? | 14:20 |
ghostmansd[m] | Yes, I think so | 14:20 |
lkcl | or, perhaps, rather than do that, have it as a single patch that's cherry-picked? | 14:20 |
ghostmansd[m] | That's why it's a standalone patch in my branch | 14:20 |
ghostmansd[m] | Yeah | 14:20 |
lkcl | ahh | 14:20 |
lkcl | nice | 14:20 |
ghostmansd[m] | But it needs a bit of tuning yet | 14:20 |
ghostmansd[m] | Mask and the field itself | 14:20 |
ghostmansd[m] | But yeah, there's the patch which I will use | 14:21 |
lkcl | ghostmansd[m], can you push that standalone branch to the repo? | 14:26 |
ghostmansd[m] | The branch is the same, it's the patch that is different | 14:26 |
ghostmansd[m] | But sure I can branch off the binutils | 14:26 |
ghostmansd[m] | Will do it today later | 14:27 |
lkcl | mainline, yes please. then alain (et al) can review it | 14:29 |
lkcl | i can then reply to alan/binutils saying "there's a branch, here it is" | 14:30 |
octavius | lkcl, in the psuedo code in bug #462 c#18, the line "GPIO_num = adr*len(sel)+i" | 16:20 |
octavius | What would be the size of the signal? | 16:20 |
octavius | I just remembered, this "GPIO[GPIO_num]" wouldn't work | 16:26 |
octavius | I tried a similar thing when I fixing the block | 16:26 |
octavius | GPIO is an Array(), and is indexed by integers | 16:27 |
octavius | All of my code generates the indeces beforehand, thus they are hard-coded and can't be changed during operation | 16:28 |
lkcl | Array() is dynamically indexable, by a Signal(), that's the whole point | 16:29 |
lkcl | so you would interpret that as: | 16:29 |
lkcl | GPIO_num = Signal(width=whatever) | 16:29 |
lkcl | comb += GPIO_num.eq(adr*len(sel)+i) | 16:30 |
octavius | For example when adr[0] is equal 1 (in my current code), the index is GPIO[byte+offset] | 16:30 |
lkcl | right, ok, yes, this is a misunderstanding on your part as to how Array() works | 16:30 |
lkcl | Array *can* be indexed by a Signal, that is in fact its entire purpose | 16:31 |
lkcl | it may be better to use a Memory() but let's not go down that route right now | 16:31 |
lkcl | so | 16:31 |
lkcl | GPIO_num = Signal(width=whatever) | 16:31 |
lkcl | comb += GPIO_num.eq(adr*len(sel)+i) | 16:32 |
lkcl | then sync += GPIO[GPIO_num] will work | 16:32 |
lkcl | if you're not doing it like that then it's a bug | 16:32 |
lkcl | or | 16:32 |
lkcl | you should not be using Array because it's pointless | 16:33 |
lkcl | you *could* do this: | 16:33 |
lkcl | for i in range(len(GPIO)): | 16:33 |
lkcl | with m.If(index == i): | 16:33 |
lkcl | sync += GPIO[i].eq(value) | 16:33 |
lkcl | but then you have quite literally implemented Array() | 16:33 |
lkcl | as in, that entire function that you wrote can - and should - be wholly and 100% replaced with: | 16:34 |
lkcl | sync += GPIO[index].eq(value) | 16:34 |
lkcl | the core of this code is much simpler than you think it ought to be. | 16:35 |
octavius | ok, I'll try the Array() indexing | 16:42 |
Veera[m] | Hi | 16:43 |
lkcl | nice to see you back Veera[m], apologies, do write, i'll be back in about 2hrs | 16:51 |
lkcl | octavius, https://gitlab.com/nmigen/nmigen/-/blob/master/examples/basic/gpio.py | 16:52 |
lkcl | which is an extremely weird example that enumerates the *bits* of pins=Signal(8) | 16:53 |
lkcl | and consequently allows *bit*-level addressing (!) | 16:53 |
octavius | horrific XD | 16:54 |
lkcl | but functional and illustrative :) | 16:54 |
octavius | Imagine all the logic required | 16:54 |
lkcl | make pins a list, | 16:54 |
lkcl | expand r_data and w_data to 8-bit | 16:54 |
lkcl | and you have near-identical to exactly what is needed | 16:55 |
octavius | "make pins a list", what's in the list? Each "pin" requires 8-bits of configuration, no? | 16:55 |
lkcl | l = [] | 16:55 |
lkcl | for i in range(num_gpios): | 16:56 |
lkcl | l.append(Signal(8)) | 16:56 |
lkcl | GPIO = Array(l) | 16:56 |
octavius | And not use Layouts at all? | 16:57 |
Veera[m] | lkcl: One personal query: did you worked somewhere in and around India. I saw a linkedin page with some data? | 16:57 |
lkcl | i leave it to you to include Layouts | 16:57 |
lkcl | i visited IIT Madras and helped out the Shakti Group. i did not work *for* them, that would require a different Visa. | 16:58 |
Veera[m] | O, that I know. | 16:58 |
Veera[m] | I saw a page in linkedin with some luke leighton who did some oceanography (Around India) work. So thought it may be you!! | 17:00 |
lkcl | nope :) | 17:00 |
lkcl | definitely not done oceanography :) | 17:00 |
Veera[m] | O O Oh. Doubt cleared. | 17:00 |
lkcl | this is me https://www.linkedin.com/in/lkclnet/?lipi=urn%3Ali%3Apage%3Ad_flagship3_feed%3BsDMzBA0AQgCPQeQKVsvpzA%3D%3D | 17:00 |
lkcl | sigh | 17:00 |
lkcl | https://www.linkedin.com/in/lkclnet/ | 17:00 |
Veera[m] | Anyway, did you completed that NGI POINTER work for fpga ls2 linux demo, or still stuck at making RAM/Hyperram work? | 17:02 |
lkcl | Veera[m], hyperram works great. DRAM not so much | 18:40 |
lkcl | but there's a stability problem with using nextpnr-xilinx | 18:41 |
lkcl | ghostmansd, you can ssh into talos1.libre-soc.org and run explicit unit tests there | 18:42 |
Veera[m] | nextpnr-xilinx is not a complete project yet!!! | 18:42 |
lkcl | it's actually pretty functional | 18:43 |
Veera[m] | so did NGI POINTER approved the project with Hyperram demo | 18:43 |
lkcl | the 2nd milestone, yes | 18:44 |
Veera[m] | good | 18:55 |
ghostmansd | https://sourceware.org/pipermail/binutils/2022-May/120783.html | 19:00 |
ghostmansd | heck, that's the second time I send git patches over email, it seems I should've done it via reply :-( | 19:01 |
ghostmansd | the stuff is pretty annoying with gmail I must admit | 19:01 |
ghostmansd | they'll drop the support for `git send-email`/`git send-imap` by the end of this month | 19:01 |
ghostmansd[m] | should I re-format it so that it is a mail and two replies to it? | 19:03 |
ghostmansd | I'll re-check for tests now, though I did it some time ago, before I hit fx_pcrel_adjust limit, and stuff worked by then | 19:05 |
programmerjake | i got it to work with app passwords (actually as part of postfix rather than git, but it'll likely work with git too, if not you could install postfix and tell git to send via your local mail server): https://support.google.com/accounts/answer/185833?hl=en | 19:06 |
ghostmansd[m] | programmerjake, thank you! | 19:07 |
programmerjake | iirc i followed https://www.linode.com/docs/guides/configure-postfix-to-send-mail-using-gmail-and-google-workspace-on-debian-or-ubuntu/ | 19:12 |
programmerjake | or something very similar | 19:12 |
programmerjake | app passwords apparently do work with gmail and git send-email: https://stackoverflow.com/questions/68238912/how-to-configure-and-use-git-send-email-to-work-with-gmail-to-email-patches-to | 19:17 |
ghostmansd[m] | programmerjake, do you know how to send all but the first mails as replies? | 19:30 |
ghostmansd[m] | Because that's exactly where I lost :-( | 19:30 |
ghostmansd[m] | And, from archives, I see that's not the stuff anyone expects | 19:31 |
ghostmansd[m] | FWIW, I used send-imap, not send-email | 19:31 |
excited-mango[m] | So when do people communicate here versus using the mailing list? | 19:38 |
programmerjake | according to: https://git-scm.com/docs/git-send-email you want `--thread --no-chain-reply-to` | 19:38 |
programmerjake | people generally use the mailing list for stuff that's important enough that everyone should see it, and/or people can reply asynchronously. | 19:40 |
programmerjake | irc is generally used for stuff that doesn't matter as much and/or realtime communication | 19:40 |
excited-mango[m] | programmerjake: Okay, thanks for clarifying | 19:43 |
lkcl | excited-mango[m], like programmerjake said, irc is real-time | 20:25 |
lkcl | mailing list is - as always - general topics that need discussion or communication that is beyond 250 chars in length | 20:26 |
lkcl | but which don't - yet - have clear goals | 20:26 |
lkcl | once there's a clear goal / issue / need that needs action, it goes in the bugtracker | 20:26 |
lkcl | and if it's instructions, crucial information or important notes, it goes in the wiki | 20:27 |
lkcl | with cross-referencing between all of them, including in the source code, because a project of this magnitude simply can't be achieved without proper cross-referencing | 20:28 |
lkcl | not at 100,000 lines and climbing | 20:28 |
lkcl | and when some things take well over a year to get right | 20:28 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!