00:00:00 --- log: started forth/20.02.27 00:17:13 --- join: nonlinear joined #forth 00:28:46 --- quit: WickedShell (Remote host closed the connection) 00:40:10 --- quit: nonlinear (Ping timeout: 260 seconds) 00:47:37 --- quit: gravicappa (Remote host closed the connection) 01:07:03 --- join: dys joined #forth 01:15:17 --- quit: jsoft (Ping timeout: 265 seconds) 01:18:15 --- join: nonlinear joined #forth 01:22:48 --- quit: nonlinear (Ping timeout: 240 seconds) 01:43:50 --- join: xek__ joined #forth 02:02:04 --- quit: rdrop-exit (Quit: Lost terminal) 02:03:34 --- join: jsoft joined #forth 02:47:26 --- quit: jsoft (Ping timeout: 255 seconds) 03:02:27 --- quit: iyzsong (Remote host closed the connection) 03:02:43 --- join: iyzsong joined #forth 03:23:56 --- join: proteus-guy joined #forth 04:17:46 --- quit: iyzsong (Ping timeout: 245 seconds) 04:45:38 --- join: dave0 joined #forth 06:01:02 --- quit: dave0 (Quit: dave's not here) 06:08:43 --- join: gravicappa joined #forth 06:34:10 --- quit: proteus-guy (Ping timeout: 240 seconds) 06:36:18 --- nick: Lord_Nightmare -> LordNLptp 06:36:25 --- nick: LordNLptp -> LordNAway 06:36:40 --- nick: LordNAway -> Lord_Nightmare 06:37:11 --- nick: Lord_Nightmare -> Lord_Nightmare2 06:37:19 --- nick: Lord_Nightmare2 -> Lord_Nightmare 07:07:38 --- join: dddddd joined #forth 07:28:28 --- quit: tabemann (Ping timeout: 240 seconds) 07:50:38 --- join: proteus-guy joined #forth 07:51:22 --- quit: cheater (Ping timeout: 260 seconds) 07:53:17 --- join: cheater joined #forth 08:28:14 --- quit: cheater (Ping timeout: 260 seconds) 08:30:12 --- join: cheater joined #forth 08:37:03 --- quit: cheater (Ping timeout: 265 seconds) 08:37:46 --- join: cheater joined #forth 09:06:35 --- quit: dys (Ping timeout: 248 seconds) 09:24:29 --- join: X-Scale` joined #forth 09:24:34 >Forth is 'read only', 'untyped', 'ancient', 'unsuitable for teams' and 'arcane' didn't you know ? 09:25:06 I hear those same excuses for almost every tool I know that actually works well and isn't bloated 09:26:20 I have to be honest though I would not trust most of the programmers I know to write Forth, there is such a thing as 'read-only' code and most such code I've read is in C, and you can achieve it in any language 09:26:21 --- quit: X-Scale (Ping timeout: 265 seconds) 09:26:22 --- nick: X-Scale` -> X-Scale 11:21:25 --- quit: _whitelogger (Remote host closed the connection) 11:24:29 --- join: _whitelogger joined #forth 11:49:26 --- join: dave0 joined #forth 12:12:19 don't we mean "write only"? 12:17:03 I was just pondering what read-only code is... APL? because you cannot type it? :P 12:38:49 --- quit: proteus-guy (Ping timeout: 260 seconds) 12:44:04 --- join: WickedShell joined #forth 13:07:57 my code isn't write only (or read only) and has normally plenty of comments 13:16:25 --- quit: gravicappa (Ping timeout: 265 seconds) 13:53:56 --- quit: xek__ (Ping timeout: 258 seconds) 13:56:26 veltas, youre right, I misquoted, Forth is normally accused of being "write only" 14:08:47 dzho, oops also meant yourself and ecraven, my mistake, I did mean to type "write only". Crc your source is totally readable along with your own literate source extraction tool and documentation 14:53:17 Well read-only usually means unchangeable so it works as well 14:54:03 just a brain fart on my part 14:54:17 It made sense to me anywya 14:54:40 thats Forth people for ya, they can understand most things :) 14:55:08 i was just ranting after transcribing some C examples to Forth 14:55:14 Right 14:55:27 I skimmed those logs it was an interesting rant 14:55:46 I have opinions about C code too ;) 14:55:57 But not a strong opinion on Forth since I am brand new to it 14:56:09 oh! 14:56:36 just the fact that you're looking at Forth puts you in a quite exclusive group 14:58:39 I have seen it mentioned multiple times over the years and it seemed interesting, I didn't learn anything other than it can have very minimal implementations, is stack-based, reverse-polish, and can extend/rewrite itself 14:59:09 The last few weeks I suddenly got the inspiration to go learn it from Starting FORTH and I have been enjoying the experience 15:00:06 It is highly unconventional but still very capable and worth trying just for that reason alone, most programming languages are too similar 15:00:38 starting Forth is quite old now and some of the examples wont work on modern Forths, so don't immediately assume it's you when that happens 15:00:51 Yeah I get that 15:01:21 The beautiful thing about it is that the implementation is so simple in Starting FORTH that I can kind of tell how it worked on their system, and can guess why it doesn't always work now 15:01:49 I guess "it can have very minimal implementations, is stack-based, reverse-polish, and can extend/rewrite itself" are some of the very important points, but one of the main ones is 'its interactive' 15:01:51 Like 'forget' not working on gforth makes sense that the dictionary would be a bit more sophisticated now (although it needn't be) 15:02:23 tp: Well that was my impression before learning it 15:02:51 Im a poor fit in this channel because I'm a electronics technician and not a programmer. I only use Forth on small embedded systems 15:03:11 and in that field, interactivity is everything 15:03:39 yet the points you mentioned above cant be stressed enough in my opinion also 15:03:53 I work with electrical engineers every day 15:04:16 the ability to rewrite itself is a MASSIVE thing shared only with LISP 15:04:18 aha 15:05:07 It's not as novel anymore, LISP is the other 'old' language that really took this to the limit, and Haskell maybe since Haskell is quite old and can extend its syntax 15:05:11 the Forth I use is very small, fits in 19kB and runs on ARM cortex-M microprocessors 15:05:21 The impressive thing about Forth is how it can rewrite itself *and* it's really tiny 15:05:47 I believe I have spent a lot of time on a Cortex-M microprocessor 15:06:14 haskep could do something like rewrite itself so one equals 2 in such a way that "1 + 1 = 3 " ? 15:06:19 Haskel I mean 15:07:00 veltas, really ? youre familiar with cortex-m, awesome 15:07:09 Not too familiar with the details 15:07:28 I mainly use cortex-m0 but have done some stuff lately with cortex-m3 15:07:32 Just did a lot of work on a real-time system on a smartfusion 15:07:41 SmartFusion was Cortex-M3 I think 15:07:58 yeah, m0 is very small but ideal for what I do 15:08:23 in my tests, m3 is usually 3 - 5 times faster than m0, not that it matters for me 15:08:40 Hmm it didn't matter for me either probably 15:09:08 most of the bigger dev environments need at least M3 and bigger 15:09:55 but Im at the really small end, tho I'd like a M0 with a couple of MB of flash just to fit all the Forth dev aids I have built 15:09:56 tp: Was that a question about Haskell? I missed that 15:10:03 I'm not sure honestly, I don't know Haskell well 15:10:04 yeah it was 15:10:31 But you can add operators and define e.g. precedence, and I have seen some weird stuff in Haskell that implies a lot of control over syntax 15:10:42 I dont know Haskell at all 15:11:39 it sounds very complicated, and I try and avoid complicated things, hence my love for Forth (not that Forth isnt complicated in areas) 15:11:55 Yes that is what I was saying earlier really by saying Forth was minimal 15:12:01 I started learning Forth in 2014 myself, Im slow but steady 15:12:22 Because if something is really tiny then it can only be so complicated (well, that logic is somewhat true anyway) 15:12:28 after 6 years I have a basic understanding I feel 15:13:14 I used to use C, but nowdays it's all Forth for me 15:13:53 I have been enjoying Forth a lot, I hope I do keep using it 15:14:05 but when learning about how to configure a unfamiliar Cortex-m0 peripheral I have to wade thru C examples 15:14:37 if youve just started and youre liking it, you may now be on a journey that will last decades :) 15:15:35 sadly almost all of the STMicro tech docs only give C examples as tho C is the 'language of microprocessors' 15:16:06 Hmm 15:16:07 and that supplies a lot of the ammunition for my rants 15:17:18 C is the language of a PDP-11 15:17:32 I mean it's bad enough to read examples that dont actually explain a particular C syntax, such as "TSC_CR_PGPSC_2" 15:18:28 I have nothing against C, I know it and I like it but for me thesedays it's just too complex and limited for small embedded in comparison to Forth 15:19:23 It is an alright 'portable assembler' and general systems language in my opinion. 15:19:50 Probably the biggest issue with C is the standard 15:19:52 the "TSC_CR_PGPSC_2" is from a 2014 tech document example, and STMicro have gone thru about 4 different systems since then in their search for the one easy method ... theyre still trying 15:20:49 yeah I agree, on larger systems C is great and very portable 15:21:30 Do you know K&R C at all? 15:21:37 I mean pre-standard C 15:21:59 I always thought Id only use Perl,Tk/tcl, and C on my PC when writing apps, but of late Ive begun using Forth thanks to CRC's "retro" 15:22:16 yeah, thats what I started with when I learnt C in 1997 15:22:25 I still have that blue book 15:22:32 I don't mean the book 15:22:54 I mean the style of C that was supported and defined in the first edition of that book 15:22:55 oh, in that case I'm probably not familiar 15:23:09 It is pre-1989 standard 15:23:22 Before e.g. prototypes were defined 15:23:41 If you can find the first edition of K&R online (it is not hard on google) then have a look, very interesting read 15:24:34 C used to be much less verbose, and you can see how they were so productive with it in the early days 15:25:10 We took a long time to come back to that kind of syntax now in languages with type inference, in the 70s they just had very weak types and they managed fine 15:25:38 ahh! 15:25:58 I pretty much just learnt enough C to use in simple embedded programs 15:26:01 One of the reasons I like Forth is it reminds me of that ... even in Forth 2012 15:26:26 thats a excellent point you raise 15:26:41 'they managed fine' 15:27:29 consider 1969 ? the USA landed men on mars and their 'computer' was all discrete components, the assembly was written by one man 15:27:37 it had zero bugs 15:28:21 Was that the one they had to debug and modify live to work around some issue (hardware issue maybe, if the code had 0 bugs)? 15:28:33 they had problems, serious ones as they were landing, but they were hardware ones, the computer and software was bug free and even allowed a workaround for the most serious hardware bug 15:28:45 thats the one 15:28:51 Yeah I read about that, very cool 15:29:00 and that was 1969 15:29:03 I think it was in an article about the nature of 'real time' programming 15:29:28 yet now in 2020, Boeing fail to get a capsule into orbit because of a 'clock sync error' 15:29:30 The program was one big continuous loop, simple flat state, so it was real time for free 15:30:05 Honestly Boeing's biggest fail is the decision that their products don't need to be owned and maintained by dedicated teams 15:30:06 the lander problem was caused by a faulty switch 15:30:26 And that you can just purchase work from anyone based on management's requirements and expect good code to come out of it 15:30:40 They have dropped all sense and rely entirely on the 'process', it turns out the process is not good enough 15:30:44 on its own 15:30:55 and that switch wanted to cause a abort which meant rocketing away from moon while attempting to land 15:31:46 no one even new what the error code meant, only the one guy who wrote it all 15:31:50 knew 15:32:06 If I wrote 'requirements' for my garden and then hired different people every day to come and 'implement' the maintainance for my garden derived from those high-level requirements they probably would mess it up and leave it horribly inconsistant and ugly 15:32:15 and he quickly designed a workaround to prevent the switch aborting everything 15:32:25 yeah, I can see that 15:32:27 If they can't even get that right then how are they meant to write mission critical software 15:33:14 well Boeing has had a number of fatal issues of late so it seems to me that modern software development is going backwards 15:33:39 I think the issue is more to do with corporatism 15:33:53 good point 15:34:19 Im a one man band, my own development is easy and straightforward in Forth, life is easy 15:34:51 and thats the thing with forth, no one uses my system because I built it for myself 15:35:23 no one wants to use it either, other Forth users have their own systems, and theyre all different 15:35:46 and theyre all different because Forth is so malleable 15:35:53 we make what we want 15:36:13 if I really want 1 to actually be 2, with Forth I can 15:36:19 Forth users are all too busy talking to the computer to bother talking to other Forth users apparantly 15:36:30 Can you make 1 + 1 = 3? 15:36:45 Forth users are the most independent free thinkers Ive ever met 15:36:59 sure 15:37:02 You would have to redefine +, not '1' to do that, right? 15:37:10 if I use fixed point :) 15:37:22 Good point 15:37:38 Well also depending on the size of your floats but yes 15:37:46 Wait ... is that right? 15:38:00 I dont use floating point, only fixed point 15:38:03 You would still need to redefine + because it's for single word integers 15:38:20 youre also right, there are multiple ways to do it 15:38:26 Hmmm 15:38:59 + also works with fixed point 15:39:26 Forth has just one thing to say about this 15:40:04 "ok" 15:40:45 Nighty night 15:41:29 oh, thanks for the chat :) 15:41:49 i hope Forth holds your interest 15:48:25 --- quit: remexre (Ping timeout: 240 seconds) 15:50:11 --- join: remexre joined #forth 16:12:40 --- join: kori joined #forth 16:12:40 --- quit: kori (Changing host) 16:12:40 --- join: kori joined #forth 16:23:33 --- quit: kori (Read error: Connection reset by peer) 16:44:35 --- join: kori joined #forth 17:08:26 --- join: tabemann joined #forth 17:27:59 --- join: jsoft joined #forth 17:29:38 hey guys 17:29:48 Hi Tabemann 18:07:24 --- join: X-Scale` joined #forth 18:08:05 --- quit: X-Scale (Ping timeout: 258 seconds) 18:08:05 --- nick: X-Scale` -> X-Scale 18:13:13 --- quit: tabemann (Ping timeout: 240 seconds) 18:24:59 --- join: boru` joined #forth 18:25:03 --- quit: boru (Disconnected by services) 18:25:05 --- nick: boru` -> boru 18:31:18 --- join: proteus-guy joined #forth 19:00:42 --- join: tabemann joined #forth 19:14:15 --- quit: tp (Read error: Connection reset by peer) 19:14:58 --- join: tp joined #forth 19:14:58 --- quit: tp (Changing host) 19:14:58 --- join: tp joined #forth 19:22:30 --- join: rdrop-exit joined #forth 19:22:34 wahoo - I fixed my problems with loops! 19:22:46 it turned out that the PC is offset by 4 in Thumb-2 19:22:59 kudos! 19:23:00 so I was miscalculating my jump offsets 19:23:04 ahh 19:23:19 thats because 4 8 * = 32 19:23:21 ? 19:23:38 that's because the processor does instruction lookahead 19:23:53 so the PC is always the current instruction's address plus 4 19:24:18 I know I have to add 4 to the pc when reading 32 bit words 19:24:48 oops 19:24:55 I mean add 4 to the address! 19:25:04 that's how PCs usually work, they point to the next instruction while the current instruction is executed 19:25:10 I have no idea what my PC is doing 19:27:14 rdrop-exit: for Thumb-2, though, instructions can be 16 or 32 bit 19:27:35 so with 16-bit instructions, it actually points to the instruction *after* the next instruction 19:29:20 that sounds wonky, when is it adjusted back? 19:31:13 (i.e. at what point in the instruction cycle?) 19:31:35 the reason why is that it fetches 16 bits, and then fetches another 16 bits, and decides whether the instruction is to be 16-bit or 32-bit 19:31:53 the reason why it does two fetches is that 32 bit instructions are only 16 bit aligned 19:33:12 aha 19:34:46 thanks, my Google-fu didn't bring up a quick diagram of the ARM instruction cycle 19:35:07 actually, my duckduckgo-fu 19:35:31 thumb seems a hack 19:35:57 thumb is annoying 19:36:11 probably is as it stated life as the acorn 19:36:34 the thing about thumb is it isn't consistent 19:37:04 the way RISC-V handles this aspect is much better 19:37:14 like why in hell are instructions that set the status register typically 16 bit and instructions that do not are typically 32 bit 19:37:21 the good thing about Forth is it makes thumb skills unnecessary usually 19:38:07 I can't decide whether to implement inlining or fix string handling next 19:38:19 apparently ALL internal ARM instructions are 32 bit anyway 19:38:22 what's fix string handling? 19:38:45 rdrop-exit: words like .( and ." are horrifically broken in zeptoforth ATM 19:39:09 ah, string literals 19:39:18 gtg, back in a few hours, cya folks! 19:39:25 see ya tp 19:39:26 ciao tp! 19:42:52 IIRC "standard" Forth doesn't provide explicit inlining related words 19:43:52 the thing is that RAM to Flash calls in zeptoforth are really expensive 19:44:00 Some Forths do implicit inlining in their optimizer, I prefer explicit inlining 19:44:12 so a significant gain can be obtained through inlining common builtin words 19:44:52 a single call from RAM to Flash is 10 bytes 19:45:01 inlining can also be useful for factoring return stack related code 19:45:35 it'd also make it cheaper processing-time-wise, as you say, because then I don't need to push and pop return addresses 19:45:48 might be cheaper for you to load code from flash into ram at startup 19:46:24 rdrop-exit: yes, Flash to Flash calls are far cheaper, only being 4 bytes 19:47:19 explicit inlining is very simple to implement, I've never bothered with implicit inlining 19:48:06 I could probably implement implicit inlining pretty easily 19:48:08 implicit requires too much special handling 19:48:47 when compiling a word, check to see if any calls are made in the word, or if the word is over a certain size 19:48:57 if neither are true, set a flag in the word 19:49:03 when the word is finalized 19:49:23 then, when compiling that word into another word 19:49:29 check for that flag 19:49:38 if it is set 19:50:05 strip the push {lr} and pop {pc} instructions from the start and end of the word 19:50:18 and insert it into the word being compiled 19:50:38 you're assuming the word doesn't do anything special with the return stack 19:51:00 that's true 19:51:02 if the word has early exits for example 19:51:14 I'm better of only doing that if an inline flag is set explicitly by the user 19:51:19 implicit requires understanding what the word is up to 19:51:41 explicit doesn't 19:52:08 I probably with explicit will still have a check for whether any calls are made 19:52:10 it's just you explicitly saying this word is for inlining rather than calling 19:52:25 much simpler 19:52:39 I use ;inline 19:52:49 e.g. : foo ... ;inline 19:53:39 that's me explicitly indicating to the compiler that this word should be inlined at compile time 19:54:16 the compiler doesn't require any smarts, I told it what I want 19:55:32 COMPILE, takes care of the actual inlining 19:57:14 it's up to me to make sure I know what I want 19:57:26 and that it makes sense 19:58:44 If the inline-able word is not compile-only then it should have a ret at the end that doesn't get inlined 19:59:08 that way you can interpret it normally 20:02:39 I find implicit inlining has too many gotchas which require too much smarts to be built into the optimizer/compiler, and then you need workarounds when the smarts get in the way of what you actually need 20:03:12 But that's just my personal take on inlining in Forth 20:04:13 back 20:04:20 wb :) 20:04:41 yeah, I'm just going to do explicit 20:05:47 I posted a description of one approach to explicit inlining on reddit a while back 20:06:08 just a sec 20:07:55 https://www.reddit.com/r/Forth/comments/9u0h7u/idea_for_making_forth_compiler_more_pluggable/e91ne3l?utm_source=share&utm_medium=web2x 20:08:13 see if that link works for you 20:10:45 --- join: gravicappa joined #forth 20:22:04 the most difficult part of x11 so far is figuring out what's unofficially deprecated 20:33:17 back 20:33:34 like server-side font rendering 20:33:43 WB 20:34:01 apparently everyone just renders their fonts client-side these days, and then sends over the rendered fonts as images 20:34:35 you'd better familiarize yourself with the likes of freetype2 20:35:19 (which, if you're doing this all in forth, requires writing either an FFI layer, or a separate process that offloads font rendering) 20:35:56 I'm planning on using my own raster font, won't need to deal with that, i'll just be pushing pixmaps to the server with the font already rendered 20:36:49 X won't have anything to do with my fonts 20:37:47 my window will be fixed-sized so no rescaling of fonts required 20:40:09 X will only receive pixels to put on the screen 20:45:34 I'm not plaaning on using any libraries, just the x11 wire protocol 20:46:36 my needs are simple enough that I think I can get away with ignoring big chunks of the X ecosystem 20:49:10 I do need to figure out which protocol extensions I need though, probably the Sync one, the newer keyboard one, and if performance is too slow I might have no choice but to look into the shared memory extension 20:51:00 apparently the double buffering extension is deprecated, but there are simpler ways of accomplishing its purpose 20:52:59 I'm spending most of my time figuring out what can or should be ignored, so much cruft 20:53:15 yess!! inlining works! 20:53:24 bravo! :) 20:56:58 late lunch, catch you later :) 20:57:04 --- quit: rdrop-exit (Quit: Lost terminal) 21:05:43 --- quit: WickedShell (Remote host closed the connection) 21:52:41 --- quit: tp (Read error: Connection reset by peer) 21:52:51 --- join: tp joined #forth 21:52:51 --- quit: tp (Changing host) 21:52:51 --- join: tp joined #forth 21:55:51 --- join: nonlinear joined #forth 23:19:32 --- quit: dddddd (Ping timeout: 255 seconds) 23:59:59 --- log: ended forth/20.02.27