Newest at the top
| 2025-02-26 19:39:24 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2025-02-26 19:37:28 +0100 | Everything | (~Everythin@46-133-48-141.mobile.vf-ua.net) Everything |
| 2025-02-26 19:35:30 +0100 | Everything | (~Everythin@46-133-48-141.mobile.vf-ua.net) (Quit: leaving) |
| 2025-02-26 19:29:01 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2025-02-26 19:28:47 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f80fcc6edffa39079b3.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2025-02-26 19:26:47 +0100 | <dolio> | I guess it's possible you could accomplish that while doing some reordering, but it'd be pretty complicated to pull off. |
| 2025-02-26 19:26:22 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 252 seconds) |
| 2025-02-26 19:25:44 +0100 | <mauke> | yes, the "common prefix" hack |
| 2025-02-26 19:25:33 +0100 | <dolio> | They need to be in order because you're allowed to do a rudimentary sort of subtyping on structs, I think. |
| 2025-02-26 19:24:51 +0100 | <mauke> | (public:, private:, protected:) |
| 2025-02-26 19:24:43 +0100 | <c_wraith> | ah. Silly language. Make no guarantees about their relative offsets, but require them to be in order. |
| 2025-02-26 19:24:37 +0100 | <mauke> | C++ compilers are allowed to re-order segments separated by visibility markers, but that's it |
| 2025-02-26 19:24:37 +0100 | califax | (~califax@user/califx) califx |
| 2025-02-26 19:23:54 +0100 | <mauke> | nope |
| 2025-02-26 19:23:46 +0100 | <c_wraith> | I thought compilers were allowed to re-order members |
| 2025-02-26 19:22:32 +0100 | tv | (~tv@user/tv) (Read error: Connection reset by peer) |
| 2025-02-26 19:22:32 +0100 | <mauke> | the idea is to declare a struct with a char as its first member (which throws off the alignment of the second member) and then check how much padding the C compiler inserted before the second member |
| 2025-02-26 19:20:51 +0100 | <hseg> | yeah, the #alignment macro, looking at the hsc2hs docs |
| 2025-02-26 19:20:17 +0100 | <mauke> | nowadays it's built into hsc2hs, I believe |
| 2025-02-26 19:20:08 +0100 | <mauke> | computes the required alignment of a given type (by asking the C compiler) |
| 2025-02-26 19:19:32 +0100 | <hseg> | what does that alignment macro do? |
| 2025-02-26 19:19:15 +0100 | <hseg> | I see the package is used by darcs and idris, loos like a safe dependency |
| 2025-02-26 19:19:05 +0100 | <mauke> | oh hey, that's my alignment macro! I invented that |
| 2025-02-26 19:18:40 +0100 | <mauke> | yeah, needs capi if you don't want to write a C wrapper |
| 2025-02-26 19:17:59 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2025-02-26 19:17:18 +0100 | <hseg> | AFAICT, it looks sensible |
| 2025-02-26 19:16:51 +0100 | <hseg> | https://github.com/biegunka/terminal-size/blob/master/src/System/Console/Terminal/Posix.hsc |
| 2025-02-26 19:16:45 +0100 | <hseg> | right -- the code I'm considering including FFIs to it and only exposes it already partially applied in its second parameter |
| 2025-02-26 19:16:24 +0100 | califax | (~califax@user/califx) (Ping timeout: 264 seconds) |
| 2025-02-26 19:15:38 +0100 | <geekosaur> | I was commenting on the recommendation to use `ioctl`; if you do that, you should FFI to it directly because a generalized ioctl binding is pretty much impossible (the third type depends on the value of the second parameter) |
| 2025-02-26 19:15:08 +0100 | <mauke> | terminfo size entries are kinda useless unless you're dealing with an actual terminal, which no one does |
| 2025-02-26 19:14:41 +0100 | <geekosaur> | yes, I started from the ticket |
| 2025-02-26 19:14:15 +0100 | <hseg> | geekosaur: Right -- if you look at the ticket I'm working on, this is a fallback for if the terminfo entry is absent |
| 2025-02-26 19:13:43 +0100 | <EvanR> | a right arrow that forks, one way goes to the target type, the other way doesn't |
| 2025-02-26 19:13:30 +0100 | <tomsmeding> | (for best effect, view on a dark terminal) |
| 2025-02-26 19:13:23 +0100 | <dolio> | ⇀ |
| 2025-02-26 19:12:50 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-02-26 19:12:42 +0100 | <tomsmeding> | Y 15-14> X |
| 2025-02-26 19:12:41 +0100 | <EvanR> | ⇀ |
| 2025-02-26 19:12:22 +0100 | Everything | (~Everythin@46-133-48-141.mobile.vf-ua.net) Everything |
| 2025-02-26 19:12:08 +0100 | <dolio> | Often it's an arrow with only the top point. |
| 2025-02-26 19:12:06 +0100 | <EvanR> | right arrow with a hazard badge |
| 2025-02-26 19:10:42 +0100 | <EvanR> | tomsmeding, right arrow but it fades out from black ink to nothing as you go right |
| 2025-02-26 19:10:19 +0100 | <geekosaur> | ioctl is kind of a nightmare to work with, you really want to wrap the POSIX higher level routines — but the terminal width and height appear to not be POSIX |
| 2025-02-26 19:10:14 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 252 seconds) |
| 2025-02-26 19:10:02 +0100 | <hseg> | https://hackage.haskell.org/package/terminal-size appears to be the most recent package supporting this, and it supports windows! |
| 2025-02-26 19:09:45 +0100 | <hseg> | People on #linux recommended using the TIOCGWINSZ ioctl as a fallback instead |
| 2025-02-26 19:09:15 +0100 | <hseg> | Was going to just catch and work with TERM=dumb, but was worrying that was standards-incorrect |
| 2025-02-26 19:08:36 +0100 | <haskellbridge> | <sm> Are you considering something more fancy than just catching the setupTermFromEnv error ? |
| 2025-02-26 19:07:55 +0100 | <haskellbridge> | <sm> Thanks for looking at that @hseg. I don't know the answer, but it would need to be installable on windows also to avoid complicating packaging. |