2024-12-24 00:29:02 it's fun, just... not very practical (but that's what many esoteric languages are about) 2024-12-24 00:32:21 I never got the allure of esolangs beyond messing with brainfuck a bit 2024-12-24 00:50:52 same thing as solving a crossword puzzle I think 2024-12-24 00:50:52 the thing I liked about Brainfuck was that there was existing software out there for it 2024-12-24 02:11:49 sounds to me like a Turing machine with a 512-bit tape isn't very capable though... are you sure you don't mean a Turing machine with a 512-bit tape position? 2024-12-24 02:16:43 I mean a Turing machine that happens not to move beyond the first 512 bits of its tape (so it only needs a 9-bit tape position, or maybe 8 bits or 7 bits if the symbols on the tape are more than one bit) 2024-12-24 02:23:20 but that's not very practical, how can it compute the first 513 bits of pi, for example? 2024-12-24 02:25:43 pi spigot algo 2024-12-24 02:55:56 there are definitely things it can't compute that you would want a Turing machine to be able to compute 2024-12-24 02:56:17 but what I mean is that it's already big enough for Rice's Theorem to apply for all practical purposes 2024-12-24 09:30:56 I'll ring the bell for another computer science theory derailment 2024-12-24 09:51:24 This channel is actually a big Derailleur from Forth to Entscheidung 2024-12-24 09:52:50 I've taken one look at my forth again and succesfully managed to make my problem harder than it needs to be 2024-12-24 09:53:16 Think I'll have to simplify and get it running before I try anything fancy, just don't have any time for this stuff 2024-12-24 09:53:48 Adding exceptions etc, and thinking "oh I'll implement the ABI exception handling / longjmp stuff"... yeah another day. 2024-12-24 09:54:56 Weird fact about assembly is that it's easier to debug than anything else 2024-12-24 09:55:10 I just spit asm out and hope for best, fix it all in gdb 2024-12-24 13:10:50 : mouse-on 0x1b emit ." [?1003h" ; : mouse-off 0x1b emit ." [?1003l" ; : mouse-monitor mouse-on begin key 0x1b = while 5 0 do key . loop cr repeat mouse-off ; <- i want to monitor mouse movements and clicks - this seems to indicate that it should be quite easy to do ... but .. this crashes in gforth if the terminal width or height > 223 2024-12-24 13:13:25 any suggestions on ways to improve that, or do i just exit if rows/cols exceed the limit? 2024-12-24 13:17:50 I want to be annoying and say not to do stuff like this in the terminal 2024-12-24 13:17:58 I don't understand what's special about 223 here 2024-12-24 13:18:17 top left is 32, 32 not 0, 0 2024-12-24 13:18:38 and why wouldn't i want to use the terminal in this way? :) 2024-12-24 13:19:42 You're writing stuff that only works on something with rich graphics etc, but are going through a cumbersome indirect protocol 2024-12-24 13:20:48 yeah - you're not convincing me that i wouldn't want to do this though :) 2024-12-24 13:21:05 Which ... I don't fully understand why the code breaks still, forgive me ... but this is probably why this is difficult, when it should be trivial 2024-12-24 13:21:20 This is in the "making life a misery for yourself" camp of Forth programming that I try to discourage :P 2024-12-24 13:22:35 it breaks because everything is 8bit - once you roll over 255, it does go back to 0 - when it sees 2, it treats it as a ctrl-c 2024-12-24 13:23:11 if i could read wide chars instead of chars, it'd work fine 2024-12-24 13:23:23 'everything is 8bit' which 'everything' are we talking about? 2024-12-24 13:23:51 well, we're reading characters with key - so those 2024-12-24 13:23:56 You know that the terminal uses a byte protocol? It probably has some way to encode larger numbers you need to decode? 2024-12-24 13:24:38 You are the one who wants to use a telephone printer protocol for mouse interaction ;) 2024-12-24 13:25:23 indeed :) - it's quite common to find mouse interaction in terminal stuff these days - it's not like i'm inventing anything here :) 2024-12-24 13:27:06 tmux, weechat, dialog, etc - all allow mouse interactions - seems quite sane to me 2024-12-24 13:28:29 Yeah you're right, other software does it, so it must be a good idea 2024-12-24 13:28:36 sigh 2024-12-24 13:30:55 Which gforth are you on? I wonder if key is being messed up by all the xkey crap that's in there 2024-12-24 13:33:53 cool - yeah - will check those directions 2024-12-24 13:35:01 Because I forget sometimes but there's an awful lot of 'helpful' stuff on top of this ancient telephone printer thing that defies my basic understanding 2024-12-24 13:35:33 ah - gforth 0.7.3 - it has a max of 255, so it avoids tripping the ctrl-c 2024-12-24 13:35:55 Yes but I would expect KEY to pass in the raw UTF-8 byte stream 2024-12-24 13:35:58 Does it not do that? 2024-12-24 13:36:02 Or am I confusing myself? 2024-12-24 13:36:42 well, this wouldn't be a valid utf-8 value (though i guess it could be mapped to one...) 2024-12-24 13:37:22 ideally, i could just have every character delivered as a wchar_t/32 bit value 2024-12-24 13:38:43 No I think my point is that KEY should return the bytestream, not UTF-8 encoded codepoints 2024-12-24 13:38:46 If that makes sense 2024-12-24 13:38:54 Like literally just give use the bytes, don't interpret it 2024-12-24 13:39:07 If gforth is interpreting it then it's doing something wrong, which is quite possible 2024-12-24 13:39:11 Especially 0.7.3 2024-12-24 13:39:37 You have to do somersaults to get Python et al not to do this as well 2024-12-24 13:40:33 i know xkey does do utf-8 interpretation - and that was tripping up with invalid utf8 combos when i tried with 0.7.1 2024-12-24 13:40:43 Well xkey should do that 2024-12-24 13:40:49 I think I am confusing myself 2024-12-24 13:41:40 I'm too stupid to do this telephone printer stuff, totally beyond me, I'll stick to SDL and the like 2024-12-24 13:44:05 :) - i was looking at sdl at one point, but i hit incompatability with 0.7.1 and 0.7.3 immediately, and there did seem like a lot of scaffolding needed to setup the event loop/handlers - with the incompatabilty, i didn't dig too deep though 2024-12-24 14:11:19 I don't blame you 2024-12-24 14:11:48 I'm hoping to make things easy in my forth for calling C code 2024-12-24 14:33:33 i was also trying to think of a way to keep the forth interpreter accessible while running the event loop (although not strictly necessary of linux, most operating systems require the gui side of things to run on the main thread) 2024-12-24 15:47:08 I don't think events typically get handled in another thread 2024-12-24 15:55:20 indeed - they typically (have to) run on the main thread - on linux, you can technically run the event loop on a background thread, but not if you want portability - in my own video playout environment, i run the sdl or qt event loop on the main thread, and the shell/interpreter in the background (so it supports zero or many playout windows) 2024-12-24 15:57:40 I seemed to remember being told by SFML docs that Mac specifically didn't like drawing on other threads 2024-12-24 15:58:01 I don't think it's really a big limitation if you can't do basic GUI stuff on other threads, but that's just my opinion 2024-12-24 15:58:20 It's quite normal for multithreading to only allow one thread to access a resource 2024-12-24 15:58:50 nope - not a big issue - and much easier for a ui design point of view not to allow it 2024-12-24 15:59:58 The whole thing is interesting to me, I have been re-reading the polyforth manual because they have a Forth multithreading system, although it's mostly cooperative + limited interrupts support 2024-12-24 16:01:25 They explain in detail how it works 2024-12-24 16:01:55 yeah - i would rather have pre-emptive if possible - i think gforth allows it, but as i kinda got blocked at the first hurdle with sdl, i haven't looked too deep into any of it yet :) 2024-12-24 16:02:12 Definitely I/O driven and prone to CPU starvation if multiple compute jobs are running, but they deployed this on minicomputers with hundreds(?) of terminals and simultaneous users 2024-12-24 16:02:40 makes sense 2024-12-24 16:46:58 I think cooperative multitasking is just fine in many cases when you control all of the things going on on your system. Some external applications encourage interrupt support, but you really only NEED that in cases where it's imperative that that external device get more or less immediate attention. 2024-12-24 16:47:55 Processors these days are so fast that you could support cooperative sharing with fine enough resolution to keep a human from noticing any delays up to a rather large number of threads. 2024-12-24 16:48:41 From a human perspective I doubt anyone could notice a 10 ms delay, and 10 ms is an eternity for modern chips. 2024-12-24 17:06:54 10ms might be long enough to bother some musicians 2024-12-24 20:57:27 veltas: maybe the repeated Forth enlightenment experience is "I managed to make my problem harder than it needs to be", which is to say, "I can make this problem simpler now that I understand it" 2024-12-24 21:00:44 I wrote a long letter as there was not time for a short one 2024-12-24 21:03:09 lilo_booter: I suspect that what's crashing is not the code you showed but something else that expects the mouse position to be nonnegative 2024-12-24 21:03:24 12:19 < veltas> You're writing stuff that only works on something with rich graphics etc, but are going through a cumbersome indirect protocol 2024-12-24 21:03:40 this is almost my objection to character-cell graphics 2024-12-24 21:04:36 my objection is not so much the cumbersome indirect protocol itself 2024-12-24 21:04:41 12:22 < lilo_booter> it breaks because everything is 8bit - once you roll over 255, it does go back to 0 - when it sees 2, it treats it as a ctrl-c 2024-12-24 21:05:05 3 I think you mean but that sounds likely. so I guess you can't handle big terminal windows unless you disable ^C 2024-12-24 21:05:13 12:23 < veltas> You know that the terminal uses a byte protocol? It probably has some way to encode larger numbers you need to decode? 2024-12-24 21:05:18 I wouldn't count on it 2024-12-24 21:12:48 minicomputers with hundreds of terminals sounds very plausible 2024-12-24 21:13:33 10 ms delays are noticeable to musicians, yes, but usually tolerable 2024-12-24 21:13:59 for some other kinds of real-time tasks, like generating a video or motor control waveform, it's orders of magnitude too large 2024-12-24 21:14:18 merry christmas! 2024-12-24 21:18:19 latency on a pipe organ is much higher than milliseconds, but the player their trains to ignore what they hear 2024-12-24 21:18:26 there 2024-12-24 22:36:35 Well, give how far away the pipes might be from an organist in a big setup like in a church, just that can give you >10ms easily. Sound only travels about a foot per ms. 2024-12-24 22:37:50 But my bet is that how you perceive it has more to do with the extended notes and not precisely when they begin or end. 2024-12-24 22:42:15 In an old many-terminal time sharing system, I believe there was local hardware for handling the renering of locally typed keys on-screen. The mainframe processor wasn't handling all the keystrokes - I think it was handling things at the command/response level. That was pre-microprocessor, so I don't know precisely what that local hardware was, but somehow they handled it right there, I think. 2024-12-24 22:42:39 Later on as the tech emerged it started getting done with microcontrollers or whatever. 2024-12-24 22:44:03 The DEC VT100 used an 8080 processor 2024-12-24 22:44:29 "Tracing the roots of the 8086 instruction set to the Datapoint 2200 minicomputer" https://www.righto.com/2023/08/datapoint-to-8086.html 2024-12-24 22:45:57 https://en.wikipedia.org/wiki/VT05 2024-12-24 22:46:52 That put typed characters into a shift register. 2024-12-24 22:47:31 Of course the really early ones used paper output, but those are a lot less interesting on this topic.