00:00:00 --- log: started forth/20.02.11 00:00:48 --- join: jsoft joined #forth 00:02:11 --- quit: WickedShell (Remote host closed the connection) 00:37:19 --- join: dys joined #forth 02:07:36 --- join: xek joined #forth 03:17:12 --- join: pierpal joined #forth 03:23:11 --- join: [1]MrMobius joined #forth 03:24:58 --- quit: MrMobius (Ping timeout: 246 seconds) 03:24:58 --- nick: [1]MrMobius -> MrMobius 04:01:04 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in) 04:01:30 --- quit: dys (Ping timeout: 245 seconds) 04:38:49 --- quit: jsoft (Ping timeout: 246 seconds) 04:44:45 --- quit: pierpal (Quit: Poof) 04:45:02 --- join: pierpal joined #forth 04:55:58 --- quit: pierpal (Ping timeout: 246 seconds) 05:26:13 --- join: pierpal joined #forth 05:32:29 --- quit: pierpal (Ping timeout: 240 seconds) 05:56:31 --- join: proteus-guy joined #forth 05:58:16 --- quit: proteus-guy (Max SendQ exceeded) 06:37:31 --- join: pierpal joined #forth 06:39:18 --- quit: pierpal (Client Quit) 06:39:41 --- join: pierpal joined #forth 06:45:39 --- join: dddddd joined #forth 07:01:58 --- join: dys joined #forth 07:26:36 --- quit: pierpal (Read error: Connection reset by peer) 07:27:01 --- join: pierpal joined #forth 07:35:01 --- quit: pierpal (Quit: Poof) 07:35:21 --- join: pierpal joined #forth 07:38:29 --- quit: tabemann (Ping timeout: 240 seconds) 08:17:10 --- quit: pierpal (Ping timeout: 268 seconds) 08:39:34 --- join: pierpal joined #forth 09:18:51 --- quit: pierpal (Ping timeout: 268 seconds) 09:26:29 --- quit: dys (Ping timeout: 240 seconds) 09:40:12 --- join: X-Scale` joined #forth 09:41:43 --- quit: X-Scale (Ping timeout: 272 seconds) 09:41:44 --- nick: X-Scale` -> X-Scale 09:46:54 --- join: ryke joined #forth 09:54:27 --- join: X-Scale` joined #forth 09:54:45 --- quit: X-Scale (Ping timeout: 260 seconds) 09:55:18 --- nick: X-Scale` -> X-Scale 09:57:34 --- quit: smokeink (Ping timeout: 260 seconds) 09:58:25 --- join: smokeink joined #forth 10:04:31 --- quit: smokeink (Ping timeout: 265 seconds) 10:13:12 --- join: xek_ joined #forth 10:15:45 --- quit: xek (Ping timeout: 260 seconds) 10:42:48 good afternoon 10:47:03 --- join: WickedShell joined #forth 12:01:22 --- join: pierpal joined #forth 12:25:32 --- quit: pierpal (Read error: Connection reset by peer) 12:36:24 --- quit: _whitelogger (Remote host closed the connection) 12:39:01 --- quit: gravicappa (Ping timeout: 260 seconds) 12:39:27 --- join: _whitelogger joined #forth 12:39:28 --- join: dave0 joined #forth 13:01:22 --- join: pierpal joined #forth 13:35:59 --- quit: xek_ (Ping timeout: 268 seconds) 13:45:45 --- quit: pierpal (Ping timeout: 260 seconds) 13:48:28 --- quit: ryke (Quit: ryke) 13:52:12 --- join: pierpal joined #forth 13:59:39 --- quit: pierpal (Read error: Connection reset by peer) 14:29:46 --- quit: Guest9046 (Quit: leaving) 14:30:13 --- join: rprimus joined #forth 14:33:02 --- join: pierpal joined #forth 15:52:02 --- quit: dddddd (Ping timeout: 265 seconds) 16:41:39 afternoon crc 16:47:28 --- join: tabemann joined #forth 16:48:11 --- join: cartwright joined #forth 17:30:36 tp 17:31:33 tabemann, 17:31:40 question 17:32:07 is it necessary that s" and ." be able to compile in more than 255 characters? 17:32:27 tabemann, hey I was just playing with saving data to a flash memory location after a exception was raised ... it corrupted the flash and Mecrisp-Stellaris wouldnt boot 17:32:51 agh 17:33:05 it's understandable I guess 17:33:15 were you able to reflash the board? 17:33:24 or was it permabricked? 17:33:43 tabemann, I dont know re more than 255 characters but I suspect not 17:34:18 no, I was easily able to reflash it. one cant brick flash that has jtag/swd access 17:34:34 I just ask because for implementation reasons implementing s" and ." is much easier if I implement it using c" 17:34:38 *them 17:34:39 Im pretty sure that mecrisp has a 255 char limit 17:34:44 --- part: gabc left #forth 17:35:58 I bet there's a way to permabrick a flash device that has JTAG/SWD access - repeatedly flash and then erase the flash until the flash itself wears out 17:36:10 shouldn't be hard to do if you do it in a tight loop 17:36:25 you don't even need to do it to the full flash, just the part that stores the vectors 17:36:31 yeah but thats not technically 'bricking' imho 17:37:14 I should buy a device just to test how fast I can kill it that way 17:37:14 the whole 'bricking' thing came about with the Linksys WRT54G that placed the bootloader in flash 17:37:58 but as soon as JTAG was figured out, bricked WRT54's became a thing of the past 17:38:09 never put the *real* bootloader in flash, or at least flash you can write without intentionally setting a jumper on the board itself 17:38:26 tabemann, you can get a device for $0.50 and hardwire it to your discovery board 17:38:40 yeah, it was very lame of Linksys 17:38:42 tp: yeah, I wouldn't sacrifice my DISCOVERY board for that 17:39:14 as your disco board has SWD, you can use that to talk to any STM32 device, even hanging off a few wires 17:39:22 I do it myself 17:39:42 I have a STM32F051 deadbugged here, it runs Mecrisp-Stellaris 17:40:14 and it only has a capacitor across it's supply pins, otherwise it's utterly standalone 17:40:54 Id say you could expect 10,000 - 1,000,000 rewrites before you get worn out flash cells 17:41:28 I have a couple of discoboards here I cant use until I replace the reset switch because the originals are utterly worn out 17:41:59 they have been reflashed uncountable times 17:43:12 but I mean if you flash the vectors in a tight loop 17:43:26 i understand 17:45:17 I wonder if they'll ever come out with more wear-resistant flash 17:45:32 I know traditional EEPROMs are more wear-resistant than Flash by far 17:45:43 but hey have far fewer cells and far longer write times 17:45:47 *they 17:45:53 takes about 3 seconds to flash/test/erase a 64KB block so I estimate it would take a minimum of 8 hours in a loop to detect any dead cells 17:46:24 the DISCO board has 2K blocks 17:46:42 and 2K is enough to contain the entire vectors 17:46:54 and possibly as long as 34 days 17:47:27 you have a F4 iirc ? 17:47:39 why waste a F4 ? 17:47:49 get a stm32f030xx 17:47:52 cheap 17:48:58 in any event, it's a bit moot because no one does that 17:49:16 if you want to recycle bits forever you use ram 17:49:39 or core 17:49:40 I'm on an L4 17:49:47 nice 17:49:58 but I'm not gonna sacrifice my L4 to test this 17:50:19 I'd get as cheap a board as possible if I were going to sacrifice it for this kind of test 17:51:06 I have some L162RD's I bought for $0.90 each :) 17:51:06 okay, I've gotta head out - bbl 17:51:14 :D 17:51:19 just get a chip, no board needed 17:51:34 they have 384kB flash :) 17:51:45 the problem is that my hands aren't really steady enough for soldering 17:51:52 oh 17:52:20 well dont buy a Chinese board, theyre full of fakes 17:52:35 I won't 17:52:42 but I need to go 17:52:45 see ya later 17:52:47 no problemo cua 17:58:05 --- quit: tabemann (Ping timeout: 268 seconds) 18:23:13 --- join: iyzsong joined #forth 18:41:06 --- join: boru` joined #forth 18:41:09 --- quit: boru (Disconnected by services) 18:41:11 --- nick: boru` -> boru 19:22:06 --- join: tabemann joined #forth 19:39:05 --- join: rdrop-exit joined #forth 19:40:15 good morning Forthwrights c[] 19:41:15 good afternoon Zen Forth Guru! 19:41:45 hi Master Forth Technician (tm)! 19:43:19 as I was programming earlier, I was rediscovering just how EASY it is to write Forth code for embedded, and briefly I felt sorry for coders having to fight all kinds of "HLL" to get the same things done 19:44:18 nowdays as my Words get bigger I find I'm splitting off parts into other Words automatically 19:44:26 it's just SO EASY! 19:44:30 tp, true that. especially now that these embedded devices have enough memory that you can run a repl against them directly and don't even necessarily require a meta-compiler. 19:44:33 excellent :) 19:45:27 proteusguy, I was working on my STM32F1x 'diagnostics' program menu that a C coder is already calling "fancy" 19:45:52 tp, I prefer the term "expressive" but yeah - I can guess what he means. ;-) 19:45:54 yet it couldnt be simpler in Forth 19:46:51 C, properly used, is simply a platform-independent assembly language with an unfortunately expensive call model. Why would anyone expect more from it? 19:47:04 proteusguy, if your target doesn't have the memory for a resident outer interpreter just use a tether 19:47:38 rdrop-exit, yes indeed - it's still less effort than C in that regard. 19:48:00 The C coders solution is to make decisions in his binary and then push the results into a USB config string to read it 19:50:03 I'm actually curious about people's experiences with tethers and meta compilers. I've ALWAYS had a repl of sorts in my environments. With ActorForth, however, the Ethereum target ultimately has to be a compiled binary of sorts. I've got ideas on how to go about doing this but I figure I should study up on best practices first. Anyone have any insights on techniques or docs for this? Especially for metacompilers because I 19:50:04 anticipate having several such targets eventually. 19:50:19 in this case most of the users are Arduino users, so they are quite clueless, have a usb connection and a serial terminal so they can flash my binary and connect to repl easily 19:51:10 tp is a generous soul always making life easy for Arduino-philes 19:51:23 proteusguy, rdrop-exit and I are great tether and repl antagonishs here, we debate these issues a lot 19:51:27 For Arduino I actually prefer the Atmel ASM over using C. 19:52:08 proteusguy, I agree with rdrop-exit that a tether is the most efficient and versatile embedded Forth system 19:53:02 tp, right - so I have my forth dictionary built up with primitives and forth words - what's the best way to then migrate a compiled version of just the bits that are needed for my "main" forth word so I have an executable on a target platform with a different CPU? 19:53:03 proteusguy, I use mecrisp-across, which is tethered for MSP430 and I use Mecrisp-Stellaris which is a full on chip Forth that needs about 20kB resident flash 19:53:47 proteusguy, depends on the target, but I'd think that JTAG is the very best way 19:53:51 in my case - focus on simplicity of implementation is of primary importance. 19:54:33 proteusguy, Mecrisp-Across uses JTAG to control the target, which appears to have a full resident Forth REPL, but actually has ... nothing 19:55:02 tp - my issue here is that my host CPU and target CPU are completely different. So my primitives will have to be different and compile over to the target. The mechanism for selecting and building the binary easiest is what I'm looking for. 19:55:04 proteusguy, Mecrisp-Across will work with a totally blank target, Ive done that many times 19:55:40 proteusguy, it's the same with Mecrisp-Across, the target is MSP430 and the Host is Cortex-M4 19:55:56 tp, right - that's why this solution doesn't completely work for me. 19:56:12 oh wait - MSP430 is not ARM? 19:56:22 proteusguy, in the case of Mecrisp-Across, the MSP430 'compiler' is written in Forth 19:56:23 or it's a different ARM? 19:56:33 it's totally NOT arm 19:56:43 gotcha - ok so is a similar situation then. 19:56:44 utterly different ISA 19:56:51 yeah, same situation 19:57:19 what's the process of identifying the target and causing the recompilation to occur? just a few forth words? 19:57:24 proteusguy, and as a Across user, it's like magic, very slick 19:57:48 proteusguy, you can interactively lay down words on the target from the host 19:58:03 how? 19:58:05 proteusguy, it doesnt identify the target to my knowledge, it just expects a MSP430 19:58:19 via the tether 19:58:48 I know what it does - at a fairly high level. My question here is implementation details. How do I build that capability into ActorForth? 19:58:55 proteusguy, brief intro for the likes of you ;-) https://mecrisp-across-folkdoc.sourceforge.io/ 19:59:14 user guide or dev guide? I'm in need of dev guide stuff. 19:59:36 proteusguy, there is no dev guide other than the source which is German 19:59:44 it's all GPL 20:00:12 I have modified it a lot quite easily and improved my scant German at the same time 20:01:09 one thing I love about Mecrisp-Across is that a 2kB flash MSP430 appears to have 64kB Flash for it's dictionary 20:01:17 right - I'm trying to find "best practices" details/docs on how to build such a cross compiler. I have some old 8-bit stuff from Brad Rodreguiz (sp?) but am curious if the "science" has been advanced since then. 20:01:53 It's become easier in some ways 20:02:39 The traditional tethered setup had a PC Forth with a serial cable that talked to a debug monitor of some sort on the target 20:02:40 proteusguy, Mecrisp-Across is quite advanced I feel, because it does a lot of optimisation. For instance it produces better assembly than I can! 20:03:23 tp, I saw that in the docs.... "* Constant folding 20:03:24 * Register allocation for both data and return stack 20:03:24 * Dead code elimination (imagine a constant feed into case) 20:03:24 * Register allocation across control structures 20:03:24 * Determination which definitions are in use,just as Freepascals Smartlinking (fpc -XX) 20:03:24 * Automatic inlining of definitions used one time only 20:03:26 * Interrupt handler framing depending on register usage" 20:03:27 rdrop-exit, as in Riscy-Pygness 20:03:34 proteusguy, what are your two systems your working with? 20:03:38 I'm probably gonna have to skip most of that. 20:04:00 the debug monitor was either the usual one for that target, or a you made a custom one 20:04:04 Initial host environment is Python. Target environment is Ethereum EVM (basic single stack machine). 20:04:37 nice 20:04:54 Today many chips come with a standardized debug interface so you can just talk to that, no monitor required 20:05:08 proteusguy, and that claim is very accurate, for instance the best MSP430 'blinky' I could make in assembly was about 80 bytes, but Mecrisp-Across does it in 20 using my very pedestrian Forth 'blinky' source! 20:06:06 So you end up with a Forth on the PC that places code on the target via the debug interface 20:07:05 I think Mecrisp-Across is kinda clever because the first Forth the Author wrote was 'Mecrisp' for MSP430 which is a 11kB resident Forth. He then ported that to Cortex-M and later used a fast Cortex-M4 as the host for his tethered MSP430 Forth 20:07:10 You can limit yourself to just placing machine code on the target, or build up a headless Forth (without outer interpreter), or a full blown redident Forth 20:07:50 If you go headless, the headers are kept on your PC Forth 20:10:59 So in summary, the PC Forth acts serves as a cross-assembling/compiling IDE which you use to build up a target binary or target headless Forth, or target full blown resident Forth, whatever you need for the project in question 20:11:49 exactly 20:12:06 and these days the target debug interface is the way to go 20:12:07 The PC Forth can be on a completely different architecture from the target and use a different thereading model to whatever Forth you place on the target 20:12:20 * threading 20:13:39 For very small projects you might not even put a Forth on the target, and just cross-assemble something 20:14:22 and MSP430 qualifies as very small in many cases with only 2kB of flash 20:15:33 Basically you are splitting the normal functionalities of a Forth between two systems 20:16:20 You're host can be as fat as you like, you're target can be as skinny or fat as you need 20:16:46 sadly my host is limited to 64kB of dictionary 20:16:48 as dictated by the project requirements 20:17:06 (by the Mecrisp-Across design) 20:17:19 My host is POSIX based 20:17:42 I do recommend that the host have tons of resources 20:18:06 I'm starting work on RISC-V as my next target 20:18:15 because it's fantastic to have all the development resources one may ever need 20:18:35 proteusbuy, does that answer your question? 20:18:59 * proteusguy 20:21:37 I will finally get a chance to write some Forth code today, after a two week hiatus 20:23:50 I guess he had to step out 20:24:30 some code! 20:25:00 I've been having a excellent post xmas code writing session :) 20:25:43 I'm up to 116 downloads of my Forth 'diagnostics' binary 20:26:01 I've been distracted by other things, coding is a spare time activity 20:26:06 rdrop-exit, yes thanks. I'm really looking at techniques of how best to build the actual cross-compiler. 20:26:55 like how to organize multiple targets cleanly and generate the code - that kind of stuff. 20:27:00 Have you read Sargeant's 3-Instruction Forth article? 20:30:07 I recall it but I don't recall it being about building a cross compiler - will check it out again. 20:31:26 rdrop-exit, it's more of a "3-Instruction Forth" paper I think 20:31:42 There's also a draft cross-compiling standard written by Elizabeth Rather et al. 20:31:53 I have his Riscy Pygness tethered Forth which is more of a prototype 20:32:37 Riscy-Pygness uses TCL to do the cross compiling 20:33:05 and a resident target binary to talk serial to the host 20:33:31 sadly it has a habit of quietly dying during use 20:33:59 I rate it as very Alpha quality 20:34:28 I only played with his much older DOS one for the Motorial 68HC11 20:34:40 tp, TCL eh? hmm... sounds like my own ideas might already be well advanced of common usage. haha 20:35:09 proteusguy, grab "riscy-pygness" it's well documented and all in english 20:35:59 rdrop-exit, Frank loved the HC11 because after a reset the USART was configured automatically to common easily used defaults, no driver needed 20:36:29 The original Pigmy Forth is mature, while his TCL based one seems alpha 20:36:45 rdrop-exit, pygmy was resident tho ? 20:36:51 tp, yes those little things mean a lot. I always loved Atmels ASM because most instructions were single cycle and it came up with obviously correct defaults. 20:37:33 Pigmy was resident on a host, but you could use his 3-Instruction stuff to build another target 20:37:44 proteusguy, you can get perfectly correct cycle counts from coretex-M3 onwards as they have a debug cycle counter, same as RISC-V 20:38:09 Holon Forth also is interesting to look at 20:38:17 proteusguy, only cortex-m0 lacks that facility 20:38:20 tp, I don't want perfectly correct - I want 1 cycle. ;-) haha 20:38:35 proteusguy, aha! then get a FPGA ! 20:39:14 tp, personally I've always disliked ARM's ISA. It has always felt wrong to me. 6809 and 68k were more my style. Just a personal smell thing I guess. 20:39:22 You can also look at Forth Inc's SwiftX and MPE's equivalent for ideas 20:39:24 tp, I'm definitely going the FPGA route eventually. 20:39:46 --- join: gravicappa joined #forth 20:39:51 rdrop-exit, sadly Franks stuff was too buggy for me. Mecrisp-Across has been rock stable, no silent dying etc 20:40:29 tp, Mecrisp has definitely done some good stuff. 20:40:36 proteusguy, Im a 6800 ISA lover myself, one always remembers ones first true love :) 20:40:59 proteusguy, MSP430 is the closest Ive seen to 6800 ISA 20:41:02 I hated that it was big-endian 20:41:35 I like big endian from a reading memory directly viewpoint 20:42:07 but I'm a user, not a programmer, technician first, coder second 20:43:01 proteusguy, Mecrisp-* done some good stuff for me so far, but Ive also used Riscy-Pygness and Flashforth (PIC) 20:43:01 I'm trying to find Rather's paper on cross-compiling 20:46:07 I've always found big endian more natural but that's probably my very early hardware experience. I've never had an issue with either as a dev. 20:46:35 little-endian is more useful for Forth 20:47:11 you can use b@ 16@ 32@ etc... with the same starting address 20:47:55 rdrop-exit, I quickly expand to higher order functions so that just becomes invisible. 20:48:13 invisible doesn't mean free 20:48:32 but nothing in life is free :) 20:49:06 Forth is all about leveraging such freebies 20:49:09 cortex-m can use either in any event 20:49:35 I may change to big-endian just for fun 20:49:41 rdrop-exit, whether the target was big or little endian - my words would be the same so I didn't lose anything either way. 20:50:54 the ability I just mentioned is free on little-endian but costs on big-endian 20:50:55 proteusguy, but Python as the HLL to compile Forth into machine code ? 20:51:26 proteusguy, I wonder if Forth is actually the best HLL to use as a cross compiler ? 20:52:00 proteusguy, some people use Gforth on a PC as a means of tethered Forth to other targets 20:52:03 back 20:52:07 hey guys 20:52:10 example is sam falvo 20:52:15 hi tabemann! 20:52:46 hey tabemann, finished your evening double latte columbian expresso ? 20:52:55 --- quit: pierpal (Quit: Poof) 20:53:14 --- join: pierpal joined #forth 20:53:19 normally at coffee shops I order an arnold palmer 20:53:35 tabemann, hehe, I'm just stirring 20:53:58 proteusguy, here's Rather's paper on Forth cross-compilers: 20:53:59 https://oco.org.ua/wp-content/files/m3forth/XCpaper.pdf 20:54:24 rdrop-exit, that took a while, was your MAC version of 'recoll' not forthcoming ? 20:55:06 I misremembered the name 20:55:20 * tp hates that! 20:56:00 I don't know if that's the latest version, it's just what Google brought up 21:00:30 rdrop-exit, thanks for the article link for Rather. I had not seen this one before. 21:00:51 my pleasure 21:01:44 she has been my hero ever since she supported after I made this claim on CLF "There is no 'compile cycle', I edit and debug and repeat until it's done." 21:01:54 supported me 21:02:04 haha yes I agree as well. 21:02:09 cool 21:02:13 the C advocates jumped on me of course 21:03:11 --- quit: pierpal (Ping timeout: 272 seconds) 21:04:39 with claims such as "it's called incremental compiling, so the loop is edit, incremental compile, debug, repeat" 21:05:19 Elizabeth replied: "Yes, but it's not a visibly distinct step in a "cycle", as it happens instantly (fraction of a second)." 21:06:19 shes pretty much the only poster on CLF that is *really* a programming and hardware expert imho 21:08:26 yeah I'm afraid all the feedback I get about CLF is negative. I think #forth here is the best place there is as a public pro-forth forum. 21:10:16 --- join: jsoft joined #forth 21:11:26 SNR tends to be bad everywhere on the internet, at least here everyone's civil 21:12:21 proteusguy, agree 100% 21:12:44 rdrop-exit, true here, it's a excellent channel 21:13:12 CLF tends to be heavily ANS oriented 21:13:18 proteusguy, sadly most of Usenet is now full of trolls 21:13:57 rdrop-exit, and full of PC Forth programmers only concerned with the language 21:14:20 ( or is that what "heavily ANS oriented" means ?) 21:14:48 CLF has almost zero hardware interest 21:15:27 it means most people there discuss ANS flavored Forth, which for me personally isn't very interesting 21:15:54 ANS fails the ruthless elimination of all unjustified complexity rule to me to be a proper "forth". 21:16:55 Too much abstraction makes the teeth rot 21:17:00 hahah 21:17:23 #forth does seem to be all about 'real Forth to me 21:17:43 --- quit: dave0 (Quit: dave's not here) 21:19:10 it seems to me that ANS Forths are all the same, but real world Forths are all different... 21:22:08 I keep up with the Forth subreddit, although much of the discussion there will make your teeth rot as well 21:22:36 but it's more civil than CLF 21:23:12 rdrop-exit, no such thing as "too much" it's a matter of "right abstractions" vs "pointless abstractions". 21:23:35 rdrop-exit, I depend on people like you to post links to useful forth reddit articles. ;-) 21:24:27 there's a lot of premature abstraction, especially coming from the functional programming types 21:25:18 yes trying to turn forth into a lambda calculus language is a backwards step. 21:26:14 they tend to treat the stack as random access 21:26:42 Ive noticed that (understandably) new Forth users usually try and turn Forth into whatever they used last 21:27:13 good point 21:27:16 if it was C then the first thing they usually want to know is how to make 'structures' in Forth 21:28:23 structures, local variables, the C++ crowd look for arrays and objects 21:29:25 garbage collection 21:30:55 in the embedded world it's usually structures because C has no data types for handling bits 21:31:11 so it's done with structures in C 21:31:34 which leads to some horrific stuff that always makes me roll my eyes 21:32:19 I've never handled bits via structs in C 21:33:07 in a way the C solution is a bit like how the URL was supposed to websites easier to remember than IP numbers, but nowadays a URL like you get from Google can only be remembered by those with a IQ over 190 21:33:38 rdrop-exit, it seems pretty standard in embedded C 21:34:13 I used the fixed-size integer types in C, uint32_t, uint16_t, etc... 21:34:28 and the pains they go thru to design them are amazing. Luckily they can hide them in header files where no one ever looks 21:35:30 so a C user coming to Forth naturally assumes that Forth needs structures to hable bit manipulation also 21:35:36 handle 21:39:28 really? crazy kids, stdint.h has been around since 99 21:40:39 thats like saying "icecream has been around since 99, 1699" 21:40:46 which flavor ? 21:41:15 there are many stdint.h but this one is mine... 21:41:47 it standardized in the C99 standard 21:41:54 * it was 21:42:19 one of the problems one often encounters with various embedded compilers is "stdint.h" 21:42:37 usually because it only finds the wrong one 21:45:16 so they find it easier to use structs than to figure out the path to the right header file? Like I said, crazy kids :) 21:45:32 rdrop-exit, I love the reaction I get from the haskell/functional zealots when I point out that their "lists" are really just stacks. ;-) 21:45:34 i dunno, I find it a crazy mess myself 21:45:45 proteusguy, hahah 21:46:29 they're always taking the top item off then passing the rest of the "list" to the next function.... goodness. 21:47:10 they're teeth have already rotted away 21:47:21 * their 21:47:28 oddly Forth makes dealing with bits very easy as there are virtually unlimited methods 21:47:52 proteusguy, it's funny how the NIH syndrome is so strong 21:48:21 * tabemann is one of those haskell/functional zealots :) 21:48:54 tp, well I have to say, as a forth advocate, we have the biggest case of NIH that exists - but then we can actually do it so it's not bragging if you can do it! 21:49:00 but personally I prefer fingertrees over tradtitional haskell lists 21:49:04 when I first started trolling a huge Arduino forum, mainly by just mentioning the word 'forth' it caused a frenzy of insulted posters justifying C 21:49:09 anyone want to borrow my Zippo to light their torches? 21:49:20 proteusguy, haha 21:49:33 (they have so many more advantages, such as being able to access both ends efficiently and being able to traverse them in logarithmic time) 21:50:14 tabemann, what's a fingertree? anything like a skip list? 21:50:27 tabemann, not to mention that their trammelgates are fully and harmoniously promulgated! 21:50:53 * proteusguy feels like he's getting trolled... ;-) 21:51:01 proteusguys: I don't understand how they work, but their only real disadvantage compared to traditional lists is that they're strict not lazy 21:51:30 that wont work for me because I'm very lazy! 21:51:31 tabemann, well they must have a size cost over regular lists to offer log access. 21:51:53 proteusguy: yes, they do have a size penalty 21:51:59 as regular lists are very lightweight 21:52:56 I should play with haskell again, as it's been a while since I've worked with it 21:53:13 but I'm too busy hacking on my Cortex-M Forth 21:53:23 tabemann, Ive seen Forth people go to Haskell, then come back again 21:53:34 I think the point was "I don't understand how they work" 21:53:48 tabemann, they seemed to get tired of the endless Haskell rules etc 21:54:18 * tp now has his Forth cortex-m Exceptions under control 21:54:25 Haskell is restrictive, but in a way that it helps you rather than hurts you 21:55:01 tp: have you been able to exit a memfault successfully? 21:55:21 tabemann, that's what the Politburo used to say also ;-) 21:55:24 i.e. without a reset? 21:55:41 tabemann, there is no exiting a memfault 21:55:57 not with cortex-m 21:56:41 the exception halts the cpu and only a hard reset can get it runnig again 21:56:53 I'm annoyed about that, because with hashforth I can gleefully segfault the process, produce a backtrace, and return the user to the prompt to code another day 21:57:42 I can at least get a message out before I lock the irq-fault into a loop 21:58:30 tabemann, perhaps those extra 2 billion transistors in your Pentium class CPU are a help there ? 21:58:55 that's probably because you're just BX-ing the return address provided by the fault, resulting in an infinite loop 21:59:12 or something like that 21:59:18 tabemann, will hashforth put your PC into low power mode where it draws only 4 microamperes ? 21:59:36 well no, it will not 22:00:53 okay, I should get to bed 22:00:57 g'night guys 22:01:44 The low end CPUs of a product line may not be able to recover from all the faults that a high end one could 22:01:55 goodnight tabemann 22:01:57 nighto tabemann 22:02:08 yeah, theyre different beasts 22:02:13 --- quit: tabemann (Remote host closed the connection) 22:02:30 I only do small embedded, Im clueless about PC class cpus 22:02:52 only 1802 for you 22:02:58 well Im clueless about everything, slightly less clueless about embedded 22:03:13 haha, I had a RCA CDP1802 but never used it 22:03:27 it was too wierd for me after the 6800 22:04:11 the 6800 was as American as eating apple pie and cream after church 22:04:32 the 1802 was like hanging out in some dark corner with dudes in overcoats and hats 22:04:55 1802 would be fun to play with in a code golf kinda way 22:05:04 i never even used my Signetics 2650 22:05:55 the 6800 left me as content as a human could be, I wanted nothing else 22:06:11 it was love at first byte 22:06:52 of the big end 22:07:03 yep 22:07:10 I'm a big endian kind of guy 22:07:56 Australians are by definition antipodal 22:09:09 we dont understand big words like that, so we just say that we live at the 'arse end of the earth' 22:10:09 :) 22:10:21 if a Australian were even to utter the word "antipodean", just the time ones mouth would be open would allow at least 3 flies to fly in! 22:11:52 oh man, is my V2 of my diags program going to be cool! 22:12:09 it's developed 'context sensitive' menues! 22:12:39 overkill R us 22:12:56 I'll give them menues so 'fancy' they choke! 22:13:05 :)) 22:13:32 I think of it as 'necessary dumbing down for Arduino users' 22:14:04 once the program has determined which MCU it is actually running on, the menu is refined to suit 22:14:47 for instance, no point showing the "hidden 64kB Flash test" when there is no "hidden 64kB Flash" to test ? 22:15:03 grey it out 22:15:32 they get confused enough as it is 22:15:51 plus, what happens if their terminal has a black background ? 22:17:11 just change a bit on the color to get an adjacent color, or more than one bit to go further away from the original color 22:18:26 xor-ing a color with white gives you the most contrasted color from the original usually 22:18:29 : contrasting ( color -- color' ) white xor ; 22:18:59 changing less bits gets you closer on the color cube 22:19:06 interesting! 22:19:31 of course I have no idea what there terminal is from the CPU 22:19:34 at least that works with RGB colors 22:19:47 as my menu runs on a MCU, not a pc 22:20:17 character-cell terminal codes use RGB 22:21:42 it's too complex, I just use b&w 22:22:01 I may offer a black OR white option later is anyone asks for it 22:23:49 if they change their default background color from black it probably inverts your text color as well, so you probably don't need to worry with b&w 22:24:45 not here it doesnt! 22:25:49 no guarantee, express or implied ;) 22:26:42 youve become far to MACanised! 22:27:18 Nah, this all old character-text terminal stuff from the 70s 22:27:48 * character-cell 22:28:04 thats a HUGE error of logic to make! 22:29:05 you have to bear in mind that the USA could put men on the Moon in 1969 but in 2019, Boeing cant even put a OSS resuply capsule in orbit at the right height 22:30:28 from a user-interface technology perspective I'm still stuck in the 70s, ^KS :) 22:31:08 ^KY ^KC 22:31:22 in other words, youre more advanced and can do more than technology today ? 22:32:14 --- join: smokeink joined #forth 22:32:57 Boeings excuses include "the dog ate our code printout", "the first stage booster and command capsule clocks had a sync problem" 22:35:39 reminds me of those coffee commercials 22:36:44 I mean the USA got paid Boeing $4.8 BILLION and they get "sorry, the first stage booster and command capsule clocks had a sync problem, so it failed" 22:36:52 -got 22:36:52 --- join: pierpal joined #forth 22:38:07 Then we get NASA saying 'the test was just a formality, we will send astronauts on the next flight anyway' 22:38:16 like WTF ??? 22:38:41 This is not your father's Space Program 22:39:17 this is not the spacecraft youre looking for ... 22:42:15 so true .. not even the one I watched live in Primary school in 1969 on a black and white TV 22:43:19 I watched at my grandmother's house, great memories 22:43:41 space-x the privateer had to prove top NASA with a live test that their integrated capsule escape sytem works 22:43:59 and they passsed 100% 22:44:22 now NASA say that boeing is exempt from even proving they can get to orbit ??? 22:45:45 I recall in the shuttle days, the NASA accountants tried to get the independent shuttle 'code checking dept' shut down because the shuttle hadnt had any mission code errors 22:45:56 hence it wasnt needed 22:47:42 wow 22:50:38 NASA had set up the 'code writing' and 'code checking' departments as two separate entities, located far from each other. The employees were not allowed to even associate, no phone calls, no contact whatever 22:51:00 that was my fathers NASA 22:52:05 and obviously all code went thru the 'code checking' dept before approved for flight 22:53:21 nowdays it's normal for a crew capsule to fail to make orbit and abort because 'of a clock sync issue between booster and capsule' 22:53:48 buried in self-imposed complexity 22:54:04 some think that technology has actually regressed in many ways since the 60's 22:54:23 yep, with increased complexity has come reduced reliability 22:54:34 both in design and operation 22:55:37 the biggest advantage of C is actually that it's 'standardised' so one can hire a programmer in Texas, or one in Bangladesh and get the same results 22:55:56 it's all the same C, right ? 22:56:58 they probably abstracted the details away 22:58:28 better yet, use Python because then the dual gramulators may be deployed to prevent framistan micro wobulations! 22:59:10 this is totally independent of the encabulator rotational speed 22:59:29 they forgot to use finger trees 22:59:35 LOL 22:59:47 I'm giving you a 'finger tree' ;-) 22:59:55 :-)) 23:00:11 I just hope I'm facing the right direction 23:01:28 --- quit: pierpal (Ping timeout: 268 seconds) 23:01:32 nope 23:01:33 ironically my C diagnostics program competitor seems to think a menu is in some way difficult in Forth, if only he knew .... 23:04:13 the C solution (59 days later) is to jam a conclusion into a USB config string for the user to read via grepping the USB device and configuration descriptors 23:04:52 what's next? XML? 23:04:58 oops 23:05:08 hahah, Ive done the XML part already, it's finished 23:05:37 thats just a report containing the raw data for use with a database etc 23:06:41 id paste it here but after you'd barfed all over your screen, you'd report me for spamming 23:09:00 --- quit: Croran (Ping timeout: 256 seconds) 23:09:14 damn right :) 23:09:28 lol 23:10:05 V2 is really simple, only 4 menu items because the Arduino users found it had too much stuff 23:10:38 they just wanted the conclusion not the evidence or logic behind the conclusions 23:11:29 --- join: Croran joined #forth 23:12:36 I've been reminding myself continually since grade 6 ... "people don't care about how things work, they're not interested" 23:22:54 true 23:46:14 --- join: pierpal joined #forth 23:59:59 --- log: ended forth/20.02.11