00:00:00 --- log: started forth/20.04.10 00:02:12 --- join: rdrop-exit joined #forth 00:14:57 --- quit: reepca (Ping timeout: 250 seconds) 00:15:24 --- nick: tp -> tp___ 00:19:41 --- join: reepca joined #forth 01:10:53 --- quit: reepca (Read error: Connection reset by peer) 01:10:59 --- join: reepca` joined #forth 01:32:24 --- join: xek joined #forth 01:47:25 rdrop-exit: Regarding P@ P! PB@ PB! is that from an existing Forth? 01:47:35 For PORT fetch etc 01:50:49 hi Veltas, IIRC p@ p! were common on x86/z80 Forths (native, CPM, DOS) 01:51:10 So were pc@ pc! for single bytes 01:51:43 Myself I used pb@ pb! for single bytes, but that's a personal affectation 01:53:00 I'd have to dig to name specific Forths 01:54:04 Let me check my shelf 02:00:05 ok, according to All About Forth 3rd Edition: 02:00:58 F83 and FP-C had p@ p! pc@ pc! 02:02:46 FIG also 02:03:15 MVP had pw@ pw! 02:04:55 MVP used pw@ pw! for words, p@ p! for bytes 02:05:46 LaForth also used p@ p! pc@ pc! 02:08:58 I don't recall what eForth for x86 uses 02:12:43 Note, when earlier I mentioned F83, that's a particular Forth system, i.e. Laxen & Perry's F83, not to be confused with the Forth 83 standard itself 02:15:52 HS/Forth (Harvard Softworks) uses pw@ pw! for words, and p@ p! for bytes 02:18:36 I suspect the most common was p@ p! for words, and pc@ pc! for bytes, but by no means universal 02:20:14 Myself, I tend to use "b" for byte, instead of the more common "c" for character 02:24:14 I can't recall if if any Forths used something other than "p" for port I/O 02:25:23 You'd need to dig through the old Forth Interest Group archives 02:37:39 --- nick: jsoft -> jsoft_ 02:38:42 --- nick: jsoft_ -> jsoft 02:40:01 --- nick: jsoft -> jsoft__ 02:40:10 --- nick: jsoft__ -> jsoft___ 02:40:19 --- nick: jsoft___ -> jsoft 02:46:38 --- nick: tp___ -> tp_ 02:46:51 --- nick: tp_ -> tp__ 02:47:00 --- nick: tp__ -> tp 03:05:02 --- join: rdrop-ex1t joined #forth 03:05:10 --- quit: rdrop-exit (Read error: Connection reset by peer) 03:06:58 It seems MMS also used p@ p! pc@ pc! 03:24:28 --- quit: reepca` (Read error: Connection reset by peer) 03:24:35 --- join: reepca`` joined #forth 03:42:35 --- join: iyzsong joined #forth 03:43:02 --- quit: WickedShell (Remote host closed the connection) 03:48:47 --- join: webchat9 joined #forth 04:16:24 --- join: rdrop-exit joined #forth 04:16:55 --- quit: rdrop-ex1t (Read error: Connection reset by peer) 04:46:47 --- join: dddddd joined #forth 04:56:10 --- nick: reepca`` -> reepca 04:59:40 --- quit: rdrop-exit (Read error: Connection reset by peer) 05:46:45 Is there an easy way of sending a message to rdrop *when they're on*? 05:47:16 I want to reply but we seem to have an almost perfect complement of activity 05:47:31 /msg boo rdrop-exit 05:47:39 Thanks 05:48:14 oops 05:48:25 it's /msg rdrop-exit boo 05:48:48 There's also the freenode service memoserv; /msg memoserv help 05:49:00 hey boru! 05:49:12 Hey tp. Long time no see, old chap. 05:49:41 boru, so true, time flies when one is having fun 05:49:53 Indeed it does. How are things? 05:49:59 Thanks boru that's what I was after 05:50:10 Sure, you're welcome. 06:52:15 --- quit: iyzsong (Ping timeout: 265 seconds) 06:55:38 --- quit: proteus-guy (Ping timeout: 256 seconds) 06:56:13 --- quit: dave0 (Quit: dave's not here) 07:04:47 --- quit: webchat9 (Ping timeout: 264 seconds) 08:00:07 --- join: proteus-guy joined #forth 08:02:49 --- join: webchat9 joined #forth 08:03:43 tp: i managed to get something close to your screen setup working with picocom and tmux 08:04:17 crest, wow, thats impressive 08:04:36 all automatic ? 08:06:07 make upload 08:06:22 invokes tmux send-keys -t $SERNUM:0.0 ... 08:06:29 that tells picocom to upload a file 08:06:41 the picocom send command is a shell script 08:06:44 well thats as automatic as me! 08:07:00 this shell script queries the forth system is a word is in the dictionary 08:07:13 and if it's defined skips the upload 08:07:14 and can you do multiple connection ? 08:07:43 to multiple forth systems or multiple makes in parallel? 08:08:01 both should be possible with a simple lock file including the serial number 08:09:05 the problem is that my solution includes a sleep 0.1 to give picocom time to spawn the upload command 08:09:21 I have a few and longer than that 08:09:22 i need something better than a race condition by design 08:09:39 yeah, a purpose program 08:10:06 the right solution would be a smarter picocom replacement 08:11:05 I meant I process the rx data from the MCU separately with screen so I have a parser to make the error RED and beep the bell 08:11:26 screen feeds it to a shell script with SED 08:11:34 so you have nothing to stop after the first error either? 08:11:48 because a sending code line by line would be nice 08:12:00 to stop at the first error 08:12:09 and print the the line number 08:12:10 no, not in the terminal system, but I can stop on error with a kernel mod I did 08:12:36 does that include a line counter that can be reset? 08:12:42 it just uses hardware handshaking and a error raises CTS 08:12:53 no, I have to reset the board anyway 08:13:08 I upload everything every iteration 08:13:14 not after successful uploads 08:13:32 lets say i want to upload a few files and the first two succeed 08:13:34 sure, right up until the final upload 08:13:48 when the project is turnkey 08:13:52 it would be nice to get to line number that failed in the last file 08:13:59 not just the total number of lines processed 08:14:37 i get the error in red and just mousewheel up to see it 08:15:42 after that I stopped using hardware handshaking to find the error 08:15:43 which is good enough i guess 08:15:57 it really stands out, plus I have the BEEP! 08:17:18 this is my picocom send command: https://pastebin.com/00CPcNaa 08:18:08 --- quit: proteus-guy (Ping timeout: 256 seconds) 08:18:18 a special purpose replacement for ascii-xfr could upload each line and parse the response 08:19:46 crest, hmm Im getting more and more suspicious that you're a programmer ... ;-) 08:20:21 tp: you're on to something :-P 08:20:35 heheh 08:20:45 as you said I see youre using Expect 08:20:53 thats pretty slick 08:21:10 yeah but i got rid of it because i simplified my code 08:21:16 at the moment zsh is enough 08:21:27 but I wont do that, I prefer to reupload all the new source everytime 08:21:29 maybe if i want more i 08:21:36 'll return to expect 08:22:36 which is why I run the MCU as fast as it will go and use the hightest serial rate I can 08:22:36 how much buffering would be required on the uC to make software flowcontrol work? 08:22:46 I dont use any 08:23:34 all I do is enable RTS 08:23:44 thats all it needs 08:24:03 and connect the MCU RTS to the PC CTS 08:24:22 oops! 08:24:39 you said software ... 08:24:56 I dont know, tabemann is the expert there 08:25:10 I only do hardware flow control 08:26:49 the unofficial documentation states that part of the problem with software flowcontrol is that the host and usb<->serial adapter contain buffers 08:27:15 and modern desktop operating systems are slow to respond compared to a microcontroller 08:28:14 but how slow? 08:28:35 is a 128 bytes buffer enough to get software flowcontrol working? 08:28:57 that would save two wires after all 08:34:05 i tried XON/XOFF and had a big fail 08:34:47 tabemann, had problems but then swiched to some ACK/NAK system and said it's flawless 08:39:21 so i can now upload multitask.txt and blinky in 0,3sec 08:39:48 most of that is spend waiting 100ms for picocom to spawn its send command 08:41:10 wait ... you mean I've a competitor in the 'fastest Forth feeder' sweepstakes now ?? 08:42:39 crest, now it's so fast, you need that bell 08:42:50 or you will miss errors 08:43:11 sure 08:44:10 do you remember under which condition your old image prints "ok." in red? 08:44:12 crest this is mine 08:44:31 screen -p $PROJECT -X exec :sed -nr 's/.*compile-only.*|.*found.*|.*flow.*|.*Redefine.*/\007\033[31;1;4mERR\033[0m/p' 08:45:01 i want to do the error handing in the send command 08:45:13 to stop uploading at the first error 08:45:22 I input "ERR" in RED into the receive stream 08:45:44 it would be really useful to have two consoles in mecrisp 08:45:46 but the error comes from the MCU in the RX data 08:45:58 the normal one and a second just to upload code 08:46:20 with the option to echo all code or just a brief report to the main console 08:46:22 thats kinda what I have 08:46:54 I click make to upload code from my editor, read the terminal and use the term for manual entry if needed 08:49:07 because with usb it should be possible two have to serial ports at the same time 08:50:01 someone here advised me to use a python terminal as it offrs non blocking 08:50:14 but I'm just not that into python 08:50:26 i don't want to clobber the main terminal 08:51:14 they recommended python as a main terminal 08:51:36 but I'm just not interested 09:02:35 crest, your system is the best I've heard off so far! 09:02:57 why? i just reimplemented a subset of your setup 09:03:17 no one else has mentioned doing it yet 09:03:30 with my prefered tools (picocom and tmux) instead of screen 09:03:37 everyone is using e4thcom at 115200 boaud on Linux 09:03:55 i tried e4thcom on freebsd, but it didn't work 09:04:11 it kind of worked with the linux64 abi 09:04:12 no, Linux only 09:04:27 it's also written in Forth 09:04:43 isn't that something positive about it 09:05:09 the annoying thing is that lots of people just release their executables instead of the source and buildsystem 09:06:24 I used to only release my source but hardly anyone used it 09:06:45 recently Ive been building binaries and they are much more popular 09:07:05 but I have a ton of source on the site 09:07:35 it is something positive about e4thcom, and it works really well on Linux 09:08:18 --- join: proteus-guy joined #forth 09:08:18 i ran it for about 12 months on a RPI with NSF for file sharing with this FreeBSD box 09:08:23 NFS 09:10:50 it got it working as terminal program, but #r and #i didn't work as expected 09:11:02 uploads stopped after the first word definition 09:11:24 I'm just not a fan of that system 09:11:58 maybe it isn't compatible with your old image 09:12:38 i could try again with a usb serial adapter instead 09:12:53 maybe 09:13:13 but all the comment stripping and including could be done in the picocom send command instead 09:14:02 thats true 09:14:02 ok it would require you to use C-a C-s to include anything which is slightly more annoying to type than \r 09:14:23 any of that annoys me 09:14:29 I like my editor 09:14:50 edit click make, everything is stripped and uploaded very fast 09:14:58 but that could probably fixed with a modified keyboard layout or xbindkeys 09:15:12 sure 09:16:48 how would anything i mentioned mess with your $EDITOR (probably gvim) 09:17:11 just type esc colon make 09:17:54 it is GVIM 09:18:00 hey guys 09:18:03 I'm all 'click and grunt' 09:19:00 --- quit: Zarutian_HTC (Ping timeout: 256 seconds) 09:19:08 het tabemann 09:19:14 -t+y 09:19:36 --- quit: dave9 (Ping timeout: 240 seconds) 09:19:44 tabemann, crest has a optimised fast terminal now! 09:20:05 e4thcom needs to be configured for your particular forth configuration - of course, you probably already know this 09:21:51 @crest 09:21:52 tabemann, crest if far beyond that 09:21:53 is 09:22:30 tabemann: i gave e4thcom a chance but it didn't convince me 09:22:41 to fragile and annoying 09:22:52 and i had to run a linux executable 09:23:09 tp: I should start releasing binaries, based on your advice above 09:23:23 tabemann: please release both 09:23:33 I already release source 09:23:43 binaries are great to test something quickly without dealing with build systems 09:24:01 because most build systems are quite prone to breakage on untested systems 09:25:09 binaries are great if you dont have the same setup 09:27:23 for instance tabemann's #includes are useless to me 09:28:13 so a binary is excellent 09:30:25 back 09:31:22 created release binaries 09:31:35 note that these do not include compiled forth code 09:32:27 just the binaries generated with gas and ld 09:33:22 but you have the ihex working, youre almost there ? 09:33:59 I add a menu and they can run stuff without even knowing how to upload to the target 09:34:53 --- join: dave9 joined #forth 09:40:31 tp: how did you change the compiler to emit a bell on errors? 09:41:12 I didnt 09:41:21 it's in that shell script above 09:41:33 screen -p $PROJECT -X exec :sed -nr 's/.*compile-only.*|.*found.*|.*flow.*|.*Redefine.*/\007\033[31;1;4mERR\033[0m/p' 09:41:58 hidden there like CoV-19 in a bat is the bell escape sequence 09:42:11 lol 09:42:16 It's weird how one of the most active channels I'm in is #forth 09:42:21 \007 09:43:07 doesn't the compiler throw an exception on compile errors? 09:43:28 crest, no 09:43:40 --- join: Zarutian_HTC joined #forth 09:43:42 i asked for that ages ago 09:44:43 tp: Also CoV-19 isn't in bats, it's SARS-CoV-2. CoV-19 is the disease of the virus SARS-CoV-2 activating in a human 09:44:47 but matthias is like the god of Forth, he doesnt need stuff like that 09:44:54 It's like the difference between AIDS and HIV 09:44:59 veltas, oops! 09:45:07 --- join: WickedShell joined #forth 09:45:21 veltas, thanks for that, I realise youre right 09:46:22 veltas: technically correct 09:46:29 The most annoying thing right now is people 'correcting' me and saying it's "COVID-19" and not "coronavirus", even though "coronavirus" is actually more accurate if you're talking about the virus 09:46:40 People prefer the name "COVID-19" because it sounds more 'official' 09:47:53 well 'coronavirus' sounds like a trademark to me ;-) 09:49:40 back 09:49:43 I want my Forth to print RED errors too, might even be flashing 09:50:03 I think I will customise ABORT" to do that 09:50:04 COVID-19 is annoying 09:50:16 I made zeptoforth ring a bell when there's an error 09:50:27 I might beep 09:51:10 I've gotta figure out how to log with screen 09:51:34 tabemann, e4thcom will log 09:51:51 tabemann, I have a shell script for that 09:52:10 looks like the compiler doesn't provide a nice hook for error handling 09:52:10 tabemann: tee 09:53:47 http://dpaste.com/0E0HR2G <-- script that works with ihex.fs to clone a chip 09:53:50 why is data transparency so often just an afterthought? 09:54:35 crest, probably not 09:55:06 so my shell script fue is now available for all to see and wonder ... 09:55:11 -e 09:55:24 mainly wonder how it ever worked 09:55:26 wouldn't it make sense to throw an interrupt? 09:55:56 i think there are many ways to handle it 09:55:57 is there no better way than grepping for all strings used with Fehler_Quit_n 09:56:40 no 09:56:55 well, you tell me :) 09:57:08 I'm a tech, this stuff isnt fun for me 09:57:38 I just drive it man, I don't know nuffin about the engine 10:01:24 back 10:09:53 night all it's 3am here 10:10:31 g'night 10:10:49 * tabemann is now using a modified version of the ihex script to dump his ROMs 10:11:56 wow, you guys are FAST! 10:11:58 night! 10:29:20 it looks like the correct way would be to turn the error reporting function into a hook that defaults to a simple "type" 10:46:22 --- quit: phadthai (Ping timeout: 256 seconds) 10:46:30 --- join: phadthai joined #forth 10:59:57 --- quit: X-Scale (*.net *.split) 11:00:00 --- quit: jimt[m] (*.net *.split) 11:00:00 --- quit: siraben (*.net *.split) 11:00:00 --- quit: tp (*.net *.split) 11:00:00 --- quit: APic (*.net *.split) 11:04:13 --- join: jimt[m] joined #forth 11:04:13 --- join: siraben joined #forth 11:04:13 --- join: tp joined #forth 11:04:13 --- join: APic joined #forth 11:04:47 --- join: X-Scale joined #forth 11:22:00 --- part: keltono left #forth 11:45:14 tp: the only clean solution i can see would be to add ascii control chars into all error messages 11:45:41 w.e. wrap them with shift in/out 11:53:28 --- quit: webchat9 (Ping timeout: 256 seconds) 11:55:34 okay, I have released binaries! 11:55:42 both with and without compiled-in Forth code 11:56:20 https://github.com/tabemann/zeptoforth/tree/master/bin 11:58:32 find you that at the moment they require one to own an stm32l476 or stm32f407 board to be of much use to oneself 11:58:40 *DISCOVERY board 12:38:10 tabemann: interesting the ack/nak flow control looks like a nice touch 12:38:47 it works better with e4thcom because then e4thcom can detect errors and stop execution 12:39:16 exactly the problem i'm facing with my mecrisp setup 12:39:35 there is no machine readable error reporting 12:41:44 at least not as far as can tell 12:50:05 ugh 12:50:27 I'm trying to set erasing to work properly across the board 13:12:49 --- quit: cheater (Ping timeout: 260 seconds) 13:14:18 --- join: cheater joined #forth 14:14:30 --- quit: Zarutian_HTC (Remote host closed the connection) 14:43:42 --- quit: xek (Ping timeout: 256 seconds) 14:58:36 --- quit: gravicappa (Ping timeout: 240 seconds) 16:10:16 --- quit: jsoft (Ping timeout: 240 seconds) 17:14:39 --- quit: heredoc (Ping timeout: 260 seconds) 17:15:09 --- nick: tp -> tp_ 17:15:14 --- nick: tp_ -> tp 17:15:41 hey tp 17:16:00 hey tabemann ! 17:21:13 I'm already working on a new release of zeptoforth (I'll call the previous "release" 0.1) 17:21:21 well, 0.1.0 17:22:02 the main improvement will be getting erasing to work as expected (it does already on the l476, but is broken on the f407) 17:23:23 changed your file structure ? 17:24:07 for 0.1.0 I added premade binaries 17:24:46 so someone can just take st-flash, write a binary to their board, and wahoo they're off and running already 17:26:28 people love that to get started 17:26:42 and of course Mecrisp-Stellaris always came with binaries and source 17:27:43 no need to get the arm-none-eabi toolchain 17:29:12 *everyone* has that, even arduinees 17:29:57 the hardest part of doing it the build it yourself way is remembering to write to $08000000 17:30:07 I had that problem with mecrisp-stellaris 17:30:25 (and that problem also applies with prebuilt binaries as well) 17:31:18 tabemann, thats why some of us use a script :) 17:35:59 ugggh 17:36:43 why is it (semi)bricking the board after erasing the interrupt-driven IO driver (along with everything else but the kernel) on the F407 board (but not the L476 board)? 17:36:50 tabemann, youve seen I use the occasional script to get stuff done 17:37:20 (semi)bricking as in it locks up and refuses to boot, but can be simply restored to working order with st-flash 17:38:00 bricking was only a Linksys WRT54 problem until people discovered JTAG 17:40:00 bbl 17:40:27 no problemo 18:12:17 back 18:15:44 tabemann, $8000000 is burned into my memory, I cant forget it anyway :) 18:17:55 as it is into mine 18:18:28 not that I use it much now 18:18:40 Forth isolates one from all that 18:27:35 you mean your scripts isolate you from all that 18:28:18 no, I mean I rarely upgrade the Forth binary 18:28:43 all my flashing is done New York Forth itself in the normal course of program development 18:28:48 oops 18:28:53 tabemann: that's why you use a Makefile instead of ^Rgcc to invoke the compiler 18:28:59 all my flashing is done in Forth itself in the normal course of program development 18:29:24 crest, exactly, or a script 18:29:56 whereas I very regularly flash the zeptoforth kernel 18:30:08 tp: most people forget that scripts can be interrupted and fail to recover from a simple ^C 18:30:17 because I'm constantly bricking the board, over and over 18:30:43 having to deal with broken scripts reinventing dependency tracking etc. is annoying 18:31:04 make isn't perfect, but it works and saves a lot of time and pain 18:31:20 tabemann, yes of course as youre doing a lot in assembly 18:31:37 tabemann, do you use stlink instead of openocd ? 18:31:40 and if want to do it in scripts at least provide a makefile wrapping them 18:31:48 tabemann, it's heaps easier 18:32:12 #!/bin/sh 18:32:13 st-flash erase 18:32:13 st-flash write mecrisp-stellaris-stm32f051.bin 0x08000000 18:33:50 I use st-flash, yes 18:34:05 I only use openocd if I plan on using gdb 18:34:43 aha 18:35:21 --- join: jsoft joined #forth 18:45:30 --- join: boru` joined #forth 18:45:33 --- quit: boru (Disconnected by services) 18:45:35 --- nick: boru` -> boru 18:51:39 back 18:51:40 tp 18:51:53 yes tabemann 18:51:54 do you know how to trigger a true warm reset on Cortex-M 18:52:16 whats a ' true warm reset' ? 18:52:28 because my "reboot" on zeptoforth is really just a branch to its entry point, it does not truly reset the hardware 18:52:30 I know how to clear ram 18:52:43 essentially pressing the reset button, but in software 18:53:02 um, yeah ... I enter 'reset' :) 18:53:23 I havent looked into the mechanism tho 18:53:54 as a tech Im familar with the way to reset the chip using the BRST pin 18:53:59 NRST 18:54:43 tabemann, the other thing is that a cortex-m reset sets all peripheral registers to defaults 18:56:16 that's the point 18:56:24 I want to reset all peripheral registers 18:59:17 tabemann, cant you see how matthias does that in his source ? 18:59:50 oh, I found it 19:00:44 --- quit: dddddd (Ping timeout: 256 seconds) 19:02:02 tabemann, if you ever get inclined to poet to the GD32VF103 bear in mind that it DOES NOT HAVE a global register reset to defaults like cortex-m 19:02:36 tabemann, one has to reset every peripheral to defaults individually with the GD32CF103 RISC-V chip 19:04:42 ugh 19:05:06 why did they have to do it that way? 19:06:05 YES 19:06:13 my software reset now really works 19:06:30 i.e. a real software reset, not the fake software reset I was doing before 19:10:21 FAKE RESET NEWS! 19:13:13 lol 19:32:41 tabemann, and that may have been a cause of much of your 'undefined behaviour' 19:32:53 as peripherals were not being reset 19:34:59 yeah 19:35:13 and btw, new binaries are available! 19:35:25 awesome ill grab one right now 19:36:45 I should put some work into writing better docs for this now that it's in a good state 19:37:13 like guides on how to use the multitasker and the event scheduler APIs 19:38:35 you mean 'write some docs' ? 19:38:46 you havent started yet :P 19:39:37 when you do a cortex-m0 version I'll document it on my site 19:40:02 but you have to get over your thumb1 revulsion first I know 19:41:08 I have docs, but they are just a list of words with stack comments and very short explanations (in the case of the Forth routines, the kernel ones have no such explanation) 19:41:52 tp: the big problem is that with thumb1 literals may be gigantic, and there is no way to know ahead of time how big an arbitrary literal that will be set later will be 19:42:12 and also, if you use the approach of storing literals in separate locations in memory from the code 19:42:16 yeah I know 19:42:31 it has the problem of not being able to predict where those locations will be, which is a problem for compiling to flash 19:42:55 I doubt youll ever feel the need to port, but I dont use M4 so I have no interest in documenting it 19:42:57 at least for thumb-2, you can know that a literal will be a maximum of eight bytes 19:43:31 I'm a user, I dont care how hard or inefficient the Forth kernel is 19:44:05 I'll probably have to do a partial rewrite to support M0 19:44:09 look at my benchmark : 19:44:11 MCU Clock (MHz) Time (sec) Comments 19:44:11 STM32F103 75 0.1505 Mecrisp-Stellaris RA 2.5.1 with M3 core for STM32F103 19:44:11 STM32F051 96 (overclocked) 0.3 Mecrisp-Stellaris RA 2.3.7 with M0 core for STM32F051 19:44:11 STM32F051 72 (overclocked) 0.516 Mecrisp-Stellaris RA 2.5.3 with M0 core for STM32F051 19:44:12 STM32F051 48 0.6 Mecrisp-Stellaris RA 2.3.7 with M0 core for STM32F051 19:44:13 STM32F051 8 2.59 Mecrisp-Stellaris RA 2.3.7 with M0 core for STM32F051 19:44:15 Atmega328 16 4 Flash Forth 5 19:44:18 STM8S003F3P6 ( From Flash ) 16 6.4 optimized for size not speed 19:44:19 STM8S003F3P6 ( From Ram ) 16 6.9 optimized for size not speed 19:44:48 Mecrisp-Stellaris for cortex-m thumb1 is the fastest in existence 19:45:16 regardless of the thumb1 issues, which mattias also hated, in fact he hates all cortex-m 19:46:16 prople are still making forths for cortex-m that use python, java, C etc and theyre so slow I could die laughing 19:48:44 writing a forth in python that runs on cortex-m? lol 19:51:11 every programmer trying out forth for the first time has a unique Forth 19:51:23 the repos are full of hundreds of them 19:51:49 they bring all their previous software attitudes 19:52:41 i think Forth must be the most reimplemented language *ever* 19:53:19 it's probably because it's the easiest language to try to implement 19:54:07 I guess, but youre the expert here, not me 19:54:37 you probably know way more about the matter than your average forth newbie 19:54:48 compared to you, I am a forth newbie 19:54:50 only using Forth 19:55:05 nooo, youre confusing a user with a programmer 19:55:18 is a linus user a Linux programmer ? 19:55:46 nope, that have no idea what a spinlock is, and I dont have much either 19:56:17 but it doesnt stop them using Linux to design a pcb, a 3dcad drawing etc 19:56:32 you're a Forth programmer, you just aren't a Forth compiler implementor 19:56:48 ok, I'll use that description in future 19:56:53 :) 19:57:59 I'm the opposite - I've implemented three different Forths, but most of my use of Forth has been in the form of writing example programs or add-ons to the compiler 19:57:59 I havent even acquired a basic understanding of yet, ... please don't anyone try and explain it to me, no spoilers! 19:58:31 yeah, users and programmers have differnt skill sets, mine arer hardware 19:58:39 -r 19:59:29 hardware programming for me is limited to programming LEDs to turn on or off 20:00:48 thats a start 20:01:00 seriously, the most elaborate programs I've written for zeptoforth are ones that use the multitasker and the event scheduler to turn LEDs on and off in different patterns 20:01:07 tabemann, your binary works fine has no 'words' 20:01:20 which binary 20:01:30 tabemann, whats the point of a binary that doesnt include everything ? 20:01:38 there's two binaries 20:01:42 one's just the kernel 20:01:54 one includes everything aside from the blinkies themselves 20:01:59 https://github.com/tabemann/zeptoforth/tree/master/bin/stm32f407 20:02:12 there's two binaries in there 20:02:27 no one will want just the kernel binary imho 20:03:20 ahh, I grabbed it too soon! 20:03:34 early aqdopter pitfall! 20:03:39 --- join: dave0 joined #forth 20:04:30 I'll rename the binaries to make it more obvious which is just the kernel and which has everything 20:05:16 zf-everything.bin 20:05:21 is a good name :) 20:05:40 cool this one has words 20:06:06 plus a version number in your binary file and at the greeting would be handy 20:06:29 make it automatic from your SCM if GIT can do it 20:07:08 if users cant quite the version you wont get any decent bug reports 20:09:06 back 20:10:30 quite = quote 20:16:21 back 20:16:25 added version numbers 20:16:30 starting from 0.1.0 20:17:23 eww 20:17:33 youre at v1 arent you ? 20:17:40 1.0 ? 20:17:58 it works, it boots, it has apps that run ? 20:18:42 hey youre the programmer here, ignore me if I'm wrong :) 20:19:13 a lot of programs start out at 0.1.0 or 0.0.1 and take forever to reach 1.0 20:19:27 I would still call it beta software, so 0.1.0 it is 20:19:52 after all, erasure for stm32f407 was broken until today 20:20:28 aha 20:20:29 I'm calling it 0.1.0 rather than 0.0.1 since at this point it mostly works as far as I can tell 20:20:55 but isnt x.x.1 a patch level ? 20:21:07 semantic versioning annoys me 20:21:12 it can be if you want it to be 20:21:34 altho I use it for my tarballs, inside they all use the SCM hash version number 20:21:58 I even name mu binaries with the hash 20:23:58 oops, that's a to-do 20:24:25 atm i compute the checksum of the binary and thats the name, it's not really suitable any more 20:24:37 all your leds work :) 20:25:08 tabemann, suggestion, a 'words4' ie 4 columns and sorted ? 20:25:44 I cant really read a words dump with only a space between them and unsorted 20:26:00 the author of course has no problem 20:28:27 back 20:29:31 columns is easier than sorting 20:30:08 even I did a 4 column version 20:30:20 I asked matthias for one and he said "why?" 20:30:22 hahah 20:30:52 so I did my own and hes included it now in the releases 20:36:46 --- join: webchat9 joined #forth 20:43:04 okay, I've now updated my README file 20:43:17 and included a log entry on hackaday.io 20:43:52 may I suggest some decent doc system rather than a bunch of text files ? 20:44:20 programmers think a bunch of text files are doc, I disagree 20:44:35 Retro had a enviable doc system 20:44:38 has 20:44:57 http://forth.works/book.html#retro-a-modern-pragmatic-forth 20:45:21 and the sooner you implement it, the easier your doc generation becomes 20:46:33 I assume to you Markdown counts as "bunch of text files" 20:47:04 well not quite unless they have no index 20:47:35 but lets face it *.md is text 20:47:56 unless it's viewed by a browser 20:48:17 not that I'm a markdown expert 20:48:57 fact is the harder unconnected text files are to read, the less people will read them 20:49:29 youll get tons of emails asking questions yove answered already in various unindexed md files if you dont 20:49:52 once zeptoforth hits critical mass ... 20:50:03 youll be *buried* in emails 20:50:48 then your marriage will suffer, you'll become an alcholic and end up on skid row ... mark my words! 20:51:07 save yourself NOW! 20:52:42 back 20:53:03 lol 20:53:24 this is why GIT sucks and fossil rules, fossil has built in tickets, wiki, technotes, forum etc 20:54:32 I expect CRC built his excellent doc in fossil as he developed, right from the start which is the right place to begin doc, and I dont mean 'Doxygen' which is FAKE DOC! 20:55:46 in a way I now wish Id used fossil for my doc instead of py.sphinx, except I was a double dumbass when I started my docs 20:56:01 now I'm just a dumbass 20:56:29 I had come from Zim before py.sphinx so that was a big improvement 20:56:59 and markdown has no indesing or cross refs afaik which is a big negative imho 20:57:04 indexing 20:57:40 but one think Ive learned is 'if DOC isnt dead easy to create, it won't happen' 20:58:33 why do you think I have 10 million viewers of my online webdoc ? 20:59:00 .. ok it's really only 42 viewers but '10 million sounds so awesome' 21:00:27 lol 21:07:56 tabemann, i think markdown doc required masterful editing to be useful, and thats what CRC does 21:08:54 tabemann, otoh, py.sphinx has indexing and search, plus pictures etc and that ameliorates my crap writing and editing to a great degree 21:09:52 tabemann, take my 'dictionary' https://mecrisp-stellaris-folkdoc.sourceforge.io/words.html ... I think a lot of visitors only come there to use it 21:10:06 because it's easy to read, and they can search etc 21:16:22 okay, I'm going to head off to bed 21:16:37 have a good night (well, it's not night for you) 21:16:49 night-o 21:17:13 keep up the awesome dev! 21:56:24 --- quit: WickedShell (Remote host closed the connection) 21:57:46 http://kestrelcomputer.github.io/kestrel/2018/01/29/on-elf 22:05:17 --- join: rdrop-exit joined #forth 22:23:01 --- join: gravicappa joined #forth 23:30:37 --- quit: webchat9 (Quit: Leaving) 23:59:59 --- log: ended forth/20.04.10