Newest at the top
| 2024-04-28 12:55:45 +0200 | <lambdabot> | True |
| 2024-04-28 12:55:44 +0200 | <tomsmeding> | > [1] >= repeat 0 |
| 2024-04-28 12:55:31 +0200 | <lambdabot> | False |
| 2024-04-28 12:55:30 +0200 | <yin> | > [] >= [0] |
| 2024-04-28 12:55:25 +0200 | <lambdabot> | False |
| 2024-04-28 12:55:23 +0200 | <yin> | > [0] >= [0,0] |
| 2024-04-28 12:54:04 +0200 | <tomsmeding> | hm I guess |
| 2024-04-28 12:53:47 +0200 | <lambdabot> | False |
| 2024-04-28 12:53:46 +0200 | <int-e> | > [1,0] >= [1,0,0] |
| 2024-04-28 12:53:12 +0200 | <tomsmeding> | can somebody tell me why cabal does not consider 1.0 >= 1.0.0 |
| 2024-04-28 12:52:26 +0200 | Lord_of_Life_ | Lord_of_Life |
| 2024-04-28 12:52:04 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2024-04-28 12:51:16 +0200 | <tomsmeding> | (had to choose some value) |
| 2024-04-28 12:51:10 +0200 | <ski> | *nod* |
| 2024-04-28 12:50:59 +0200 | <tomsmeding> | it switches to a vertical stack below 800px width |
| 2024-04-28 12:50:54 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-04-28 12:50:51 +0200 | <tomsmeding> | yes |
| 2024-04-28 12:50:38 +0200 | <ski> | does it display the GHC output below, if the window's not wide enough ? |
| 2024-04-28 12:50:03 +0200 | <tomsmeding> | (oh that bug is trivially fixable) |
| 2024-04-28 12:49:58 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 256 seconds) |
| 2024-04-28 12:49:55 +0200 | <ski> | top is already a bar with some elements. could display it in there ? or, i guess, maybe could make a pop-up for some stuff, if reasonable |
| 2024-04-28 12:49:40 +0200 | <tomsmeding> | (there is already a UI bug where there is a range of window widths where the top bar doesn't fit but doesn't scroll yet) |
| 2024-04-28 12:49:32 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2024-04-28 12:49:08 +0200 | <tomsmeding> | considering that the UI should still make some sense if the window is not terribly wide |
| 2024-04-28 12:48:51 +0200 | <tomsmeding> | where in the UI |
| 2024-04-28 12:48:47 +0200 | <Rembane> | +1 |
| 2024-04-28 12:48:27 +0200 | <ski> | (incidentally, having the page display when the paste was made, would also be useful info, imho) |
| 2024-04-28 12:45:11 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2024-04-28 12:43:46 +0200 | <ski> | (s/the more annoying thing/the more annoying case/) |
| 2024-04-28 12:42:42 +0200 | <ski> | "I now see that having a \"raw\" link would be terribly useful in that case, so I'll add that" -- great, thanks a bunch |
| 2024-04-28 12:42:32 +0200 | <tomsmeding> | or, rather, not thought about that at all |
| 2024-04-28 12:42:23 +0200 | <tomsmeding> | oh interesting, I would indeed have forgotten that |
| 2024-04-28 12:41:42 +0200 | <ski> | i mean that if i `wget' the raw (or "download") source link, i get a timestamp on the downloaded file that represents when the paste was made, rather than when i downloaded it. not all sites are configured to give this information, though |
| 2024-04-28 12:40:46 +0200 | <ski> | (i sometimes check out the raw link, or do such hunting through the page source, for other paste sites. enough that i've started to memorize the URL pattern for it in some cases, and immediately modify the given paste link before loading it in browser) |
| 2024-04-28 12:39:46 +0200 | euleritian | (~euleritia@2a02:810a:b00:1568:71f7:8ec:15a3:342f) |
| 2024-04-28 12:39:40 +0200 | <tomsmeding> | what do you mean with "with accurate timestamp"? |
| 2024-04-28 12:39:28 +0200 | euleritian | (~euleritia@dynamic-176-007-168-231.176.7.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-04-28 12:39:18 +0200 | <ski> | there's no Javascript is the more annoying thing) |
| 2024-04-28 12:39:12 +0200 | <ski> | "would it be acceptable if I put the "raw" link there only if there is no javascript?" -- okay, i guess, if you think it clutters the interface up too much otherwise ? (i suppose i'd prefer to have the link, regardless, so i don't have to hunt through the page source for it, if i'd like to e.g. download (e.g. with accurate timestamp, if available) or link directly to the raw text. but having it available if |
| 2024-04-28 12:36:56 +0200 | Guest83 | (~Guest83@79.113.204.176) (Client Quit) |
| 2024-04-28 12:36:21 +0200 | <ski> | "that's a separate issue" referred to it being separate from the issue being able to put a type ascription on the whole definiendum (as well as to name tyvars in opened existentials, for that matter) |
| 2024-04-28 12:35:15 +0200 | <tomsmeding> | (with working JS you get the source with just select-all, copy) |
| 2024-04-28 12:34:44 +0200 | <tomsmeding> | I'm just thinking to hide that link if there is JS so that it doesn't clutter the UI for the majority of users, only for those for whom it would help |
| 2024-04-28 12:34:35 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-04-28 12:34:24 +0200 | <tomsmeding> | I don't think it's worth the effort to make it work better in a no-JS environment, but I now see that having a "raw" link would be terribly useful in that case, so I'll add that |
| 2024-04-28 12:34:05 +0200 | Guest83 | (~Guest83@79.113.204.176) |
| 2024-04-28 12:33:39 +0200 | <tomsmeding> | if you open the playground without JS it's completely nonfunctional anyway, even in a state-of-the-art graphical browser |
| 2024-04-28 12:33:15 +0200 | <ski> | well, opening it in W3m shows me the buttons (but they are not clickable, unlike other buttons on many pages), and doesn't show the source at all (neither readable, or with garbled formatting, as some paste sites do) |
| 2024-04-28 12:32:44 +0200 | <tomsmeding> | would it be acceptable if I put the "raw" link there only if there is no javascript? |
| 2024-04-28 12:32:24 +0200 | <ski> | maybe beside the "Save & share code" button ? |