| 4 Jun 2025 | |||
| japhb | Now I know why so many Mac folk are iTerm2 fans | 16:44 | |
| What are the env variables LANG and LC_ALL in that terminal? | 16:51 | ||
| lizmat | they are not set | 18:09 | |
| japhb smacks Apple around with a wet POSIX spec | 19:40 | ||
| lizmat: Are there *any* environment variables set that include mention of UTF-8? (ignoring case and punctuation, since they might instead say 'utf8' or somesuch) | 19:42 | ||
| (The lack of LANG and LC_ALL are why the autodetection is assuming ASCII semantics.) | 19:43 | ||
| Xliff_ | So what's the difference between "static inline" and not "static inline"? | 19:55 | |
| Aside from the fact that functions marked as such are not shared lib friendly. | 19:56 | ||
| japhb | This matches my (admittedly slightly rusty) memory, more or less: stackoverflow.com/questions/776273...on#7767858 | 20:01 | |
| lizmat: Also, what version of macOS are you running? | 20:09 | ||
| Ah, looking at old Terminal-Tests results, it looks like LizyPro is your *old* macOS install, 10.14 or so? | 20:26 | ||
| That would explain why it looked so "off" | |||
| lizmat: And can you send terminal-quick-test screenshot, terminal-autodetect results, macOS version, and LANG/LC_ALL/UTF-8 env var info for the *newer* install as well. | 20:29 | ||
| 5 Jun 2025 | |||
| lizmat | japhb: raku -e 'dd $*DISTRO' | 14:51 | |
| Distro.new(release => "24F74", path-sep => ":", name => "macos", auth => "Apple Inc.", version => v15.5, signature => Blob, desc => "Sequoia") | |||
| gist.github.com/lizmat/924890d8ee4...150d628bee | 14:55 | ||
| japhb | Wait, LizyPro is running 15.5 now? Now why does the screenshot look like the old one I had from 10.14 ... hmmm, there must be something else different. Different font chosen for the terminal maybe? | ||
| lizmat | I guess I didn't bother to change my machine name moving to the new MBP | 14:59 | |
| japhb | Fair enough. I'm just confused why it still *looks* like an old version of the Terminal. For comparison the 12.6 screenshot you'd sent me from M1Mini looked a lot better than *either* of the LizyPro images (either when it was 10.14 or now at 15.5) | 15:04 | |
| So the question becomes: What's different about M1Mini's terminal config? | |||
| lizmat | because I'm going through VLC to that macmini ? | 15:12 | |
| japhb | VLC? Is that related to the media player, or something different? | 15:13 | |
| Or did you mean VNC? | 15:14 | ||
| lizmat | yeah, duh :-) | ||
| japhb | .oO( Geez guys, do you suppose your project names could be *slightly* easier to confuse? Asking for a friend. ) |
15:15 | |
| OK, so you use VNC to get into the M1Mini ... but wouldn't that show you exactly what *would* be displayed locally on the M1Mini if it had its own monitor? | 15:16 | ||
| lizmat | you would think so, yes | 15:27 | |
| hmmm... | |||
| except that the MacMini is still running Sonoma | 15:28 | ||
| japhb: what installs terminal-autodetect again ? | 15:34 | ||
| japhb | Terminal::Capabilities | 15:49 | |
| lizmat | gist.github.com/lizmat/b950e2b727f...89904cc84e | 15:53 | |
| that's sonoma on the macmini | |||
| japhb | WTA? | 16:15 | |
| That makes no sense, and I'm grumbly about it | |||
| 25 Jul 2025 | |||
| patrickb | I'm still working on PTY support in raku. (Currently implements PTY support in libuv). I've taken a lot of inspiration from node-pty. There is one commit in there, where the termios of the PTY is explicitly specified. 30 lines with loads of options. Other PTY libraries don't do this. I think I don't have enough context to judge if I should copy that code or not. | 22:17 | |
| github.com/microsoft/node-pty/comm...29f41b6979 | |||
| That's the commit. | |||
| I'd value any opinions and insights. | 22:19 | ||
| Questions I have: Why would the defaults be bad? How did that committer come up with those specific values? | 22:20 | ||
| japhb | My recollection is that the CC array is just a way to remap the terminal control codes. I think you'd need them if you wanted a way for an embedded PTY to accept an alternate set of keys for control so as to differentiate from the ones that affect the surrounding UI, without having to do some sort of modal control or escape-control UX | 22:29 | |
| As for the i/o/c/l flag bitfields, on first glance that looks like "made some specific set of default flags explicit, so that we're not surprised if some OS/kernel uses a slightly different default set" | 22:32 | ||
| But actual useful comments would have been nice ... JEREMY. *glares in disappointed dad/manager* | 22:33 | ||
| 26 Jul 2025 | |||
| patrickb | That's insight full. Thanks! I slightly tend towards not doing that for now. Better some day hit the actual issue and then port that solution instead of cargo cutting it now. | 08:53 | |
| japhb | Yeah, fully agreed. I'm all from learning from other languages struggling with the same problems, but if it's not clear whether they're actually correct, that's a nope. | 18:37 | |
| 29 Jul 2025 | |||
| patrickb | It's finally done! The libuv PTY PR is ready for review. This has been a long way coming. It will be a few more steps to land this in Rakudo. That should hopefully happen soon-ish as well. | 15:02 | |
| With that out of the way, I can finally move on to working on vararg support in NativeCall again. | 15:03 | ||
| japhb | patrickb++ | 17:59 | |
| 27 Aug 2025 | |||
| japhb waves | 01:56 | ||
| apogee_ntv waves back. | 01:59 | ||
| 11 Sep 2025 | |||
| Geth | Terminal-Widgets/main: e301c07b40 | (Geoffrey Broadwell)++ | 2 files Support capabilities autodetection on controlling terminal |
04:48 | |