00:00:00 --- log: started forth/20.06.21 01:16:50 --- join: andrei-n joined #forth 02:30:26 --- join: dddddd joined #forth 03:14:58 --- quit: andrei-n (Read error: Connection reset by peer) 03:23:07 --- join: TCZ joined #forth 04:03:57 --- quit: TCZ (Quit: Leaving) 04:59:31 --- join: TCZ joined #forth 05:03:56 --- quit: jsoft (Ping timeout: 240 seconds) 06:53:43 Today I keep thinking "what if we did not have X in Forth" and realising it's better to have it 06:54:36 Like the return stack, I think "what if we did not have return stack ops" and then I realise that's *how* you add control flow, and so we may as well expose the return stack for saving stuff anyway, it's free 06:56:17 Or "what if we didn't have immediate words" and only supported one effectively immediate word [ , well then you would have to make many words much larger to accomodate this switching of state 06:56:34 Just some car thoughts 07:00:13 --- quit: TCZ (Quit: Leaving) 07:17:37 "Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary." - Scheme R5RS 07:20:24 tabemann: i don't 07:20:43 tabemann: did you read my updates on stlink (1.6.1) 07:22:04 oh they fixed the permission issue 07:22:22 so maybe the lockdown wasn't intentional 08:05:25 i added a pull request to reduce the logging on FreeBSD something reasonable 08:19:43 --- join: TCZ joined #forth 08:58:31 --- join: andrei-n joined #forth 09:51:51 --- quit: Zarutian_HTC (Ping timeout: 258 seconds) 09:57:41 tabemann: i'm installing a debian VM to test swdcom on linux 09:58:28 asking you to rebuild one commit at a time is just annoying for both of us 10:28:22 --- quit: Chobbes (Ping timeout: 272 seconds) 10:29:52 --- join: Chobbes joined #forth 10:37:37 --- quit: TCZ (Quit: Leaving) 10:39:02 --- join: Zarutian_HTC joined #forth 10:48:36 hey 11:26:44 tabemann: i fixed the swdcom build on debian 11:27:08 the code is on github 11:27:19 would you mind testing it on your system? 11:28:43 if it works please update your pull request to just include the zeptoforth specific parts 11:50:40 --- join: xek_ joined #forth 12:08:36 tabemann: my freebsd usb logging fixes got merged as well 12:09:25 that takes care of all regressions in stlink 1.6.1 from my point of view 12:09:46 the next release should be useable on linux and freebsd unless something breaks again 12:33:56 --- quit: Zarutian_HTC (Ping timeout: 256 seconds) 13:02:30 back 13:03:12 tabemann: hi 13:03:26 just got home 13:04:03 you mean the stlink code? 13:04:13 in the devel branch? 13:06:36 in the develop branch 13:19:58 swdcom now compiles without any changes 13:20:21 the most important change was a single line #define 13:20:39 #define _XOPEN_SOURCE 500 13:20:59 yeah, I remember seeing that one out there 13:21:58 why must they make it hard to use headers like that (GNU I'm looking at you) 13:22:00 it stops glibc headers from pretending to be even stupider than they are 13:22:45 in the name of "standards compliance" of course, I presume 13:22:46 because the gnu tools are portable to different operating systems and each one is its own kind of stupid 13:23:26 so they seek the lowest common denominator in stupidity 13:23:42 the *bsd avoid a lot of this pain because they are complete operatings systems developed as a single project in a single repo 13:24:32 e.g. in *bsd, solaris and macos the "official" interface to the system is API (and ABI) 13:24:41 not the syscalls 13:25:04 which is annoying for languages that target the syscall interface directly like go and rust 13:25:55 e.g. rust was broken on freebsd 12.0 for months because rustc couldn't support changes to the syscalls and structs 13:27:28 porting rust from the freebsd 11 syscall interface to the freebsd 12 syscall interface wasn't hard 13:27:56 but expanding rustc's concept of a platform to allow code reuse between them was a long debate 13:36:30 back 13:37:40 do you want to touch up your swdcom pull request to include (just) what's still missing from my swdcom repo? 13:38:03 I'm making a few changes right now to eliminate things like the definition of b+! 13:38:14 which is now going into the zeptoforth kernel 13:38:39 i just wanted to keep you up do date 13:39:43 because i know how annoying it is to get ignored by opensource projects/developers 13:39:59 is there any way you can drop the pull request and I can submit a new one with *just* my bootstrap_zepto.fs? I don't really know how to change pull requests after the fact 13:40:45 afaik the pull request is the diff between the two branches 13:40:53 so you could rebase your branch 13:41:03 or just add new commits 13:41:25 or abandon your original pull request and start a new one 13:41:37 i wouldn't mind given the current state of swdcom 13:42:51 the next two features i want to add are simple file uploads and stopping at string match in the output 13:43:46 afterward i want to split swdcom into a daemon and clients 13:45:29 how do you with github merge changes from an original branch under one user into a forked branch in another repository? 13:45:51 i have no idea 13:46:00 just start a new pull request if it's easier for you 13:47:23 --- quit: jedb (Ping timeout: 264 seconds) 13:54:16 --- join: TCZ joined #forth 13:57:25 and i ordered two stm32l476 disco boards as well 13:59:49 kback 13:59:55 I updated my branhc 14:00:17 I had to make a change to the Makefile as it otherwise wasn't going to commit on my debian 14:00:32 namely I had to add -I/usr/include/libusb-1.0 14:00:54 --- join: dys joined #forth 14:01:08 i added $(shell pkg-config --cflags libusb-1.0) to deal with that to the GNUmakefile 14:02:23 --- quit: gravicappa (Ping timeout: 264 seconds) 14:04:39 --- join: Zarutian_HTC joined #forth 14:08:36 back 14:09:06 please leave the Makefile for BSD make variants and make your changes to the GNUmakefile 14:09:13 okay, I accidentally deleted GNUmakefile and was unable to get it back for some reason, so I copied it directly from the checkout of your code 14:12:12 --- quit: xek_ (Ping timeout: 260 seconds) 14:13:10 if i squash all your changes into a single commit it doesn't matter how we got there 14:14:16 please respond to the comment on the pull request when you're satisified with your changes 14:15:37 don't merge the code yet 14:15:43 I rean into a bug 14:15:46 *ran 14:33:32 back 14:33:34 crest 14:33:44 should I have closed the pull request or not? 14:36:51 okay, I reopened it 14:38:13 does zeptoforth support keeping the base address in r11? 14:39:20 yes 14:40:19 swdcom works with swd2 and bootstrap_zepto.fs without any hitches now 14:40:25 *zeptofort works with 14:40:31 *zeptoforth 14:42:09 my stm32l476 discovery boards are in the mail 14:42:16 cool 14:42:35 i'll give zeptoforth a spin on one of them 14:43:31 I assume the other is for mecrisp-stellaris? 14:43:52 they aren't dedicated to one forth system or the other 14:44:32 i just wanted two to have identical hardware for experiments e.g. if I get the CAN controller working 14:44:46 ah 14:44:50 (and as backup if i fry one) 14:45:23 i already ripped of a solder pad on one of the nucleo boards 14:45:42 egad 14:45:58 i was fixable 14:46:02 *it 14:46:30 the damn pad came of while adding some solder to it 14:47:16 either the board as a lot more thermal capacity than i thought or it's a low quality pcb 14:47:50 the fix isn't pretty but it works 14:49:26 * tabemann can't solder, as he discovered at a tech camp in high school (I soldered together a radio - it actually worked, but the soldering wasn't pretty) 14:49:39 if it works... 14:51:36 i squashed all your changes into a single commit to hide the long-winded path you took 15:03:01 --- quit: andrei-n (Quit: Leaving) 15:03:04 --- join: dave0 joined #forth 15:30:36 --- quit: dddddd (Ping timeout: 240 seconds) 15:43:51 thanks 15:45:15 --- quit: TCZ (Quit: Leaving) 15:50:01 what features would you like to see in swdcom? 15:55:37 crest: I would like e4thcom-style #include and #require, including with nested source files 15:56:20 I would also like to see a proper line editor 15:56:25 with history and like 15:56:58 note that these should not go in the swdcom core, but rather in a client application 15:57:32 if anything, this functionality should not even know about swdcom 15:58:02 but rather swdcom should expose itself as a device file 15:59:13 exposing a device is hard to do cross platform 15:59:55 is there even a linux userspace device driver kernel module? 16:00:10 i do know that freebsd has cuse4bsd 16:00:56 well there's gotta be a way, since things like xterm are crossplatform 16:01:13 what does xterm have to with this? 16:01:41 oh you don't want a general purpose device 16:01:44 just a ptty 16:01:49 yes 16:01:57 good idea 16:02:17 but how would you attach to it? 16:02:50 donno, I don't know enough about pttys 16:03:28 it's a nasty api but posix does say enough on it 16:05:34 but you'd also want to keep a "raw" interface as well where you can just transfer arbitrary bytes to and from the MCU 16:06:17 i overlooked the pseudo ttys 16:06:23 and wanted to start from scratch 16:07:12 but actually my idea for the daemon was to use unix domain sockets 16:08:17 for the core layer, yeah, that's a good idea - where one is just dealing with bytes alone 16:09:05 unix stream sockets are fast and reliable 16:09:24 but file descriptor passing over them is a pain in the ass 16:09:56 because the stream abstraction breaks down 16:10:21 yeeeah 16:10:29 and each unix has its own intersting interpretation of what should happen in corner cases 16:10:55 for decades freebsd had a really, really nasty bug 16:11:26 if the sender passed more file descriptors than the receiver could receive all file descriptors got passed 16:11:40 there was just no way to learn their file descriptor number 16:12:32 --- join: dddddd joined #forth 16:13:26 okay, I'm gonna have dinner now - bbl 16:13:38 i should go to bed 16:44:03 back 16:44:06 g'night 17:30:23 --- quit: _whitelogger (Remote host closed the connection) 17:33:24 --- join: _whitelogger joined #forth 17:35:09 --- join: remexre joined #forth 17:35:33 hm, is there a way to do DODOES without needing to be able to write machine code to the dictionary? 17:36:27 I'm writing an ITC forth in C, and I'd like it to work across all Linux 64-bit little-endian arches without having to have a separate version of "write a jmp dodoes to the dictionary" for each arch 18:05:19 if it's ITC, you put a primary code pointer and a secondary code pointer in the dictionary; then, when calling a word, you call the function pointed to by the primary code pointer 18:05:52 remexre: make your pointer a union or cast it to function pointer 18:05:52 and if that word is a colon or does> word, that in turn initiates execution of the forth code poined to by the secondary code pointer 18:07:09 tabemann: oh, that's elegant; right now I just have DOCOLON continuing execution immediately after the code pointer 18:07:46 the real purpose of the secondary code pointer is to enable does> to work 18:09:18 note that this all gets harder in the context of a forth like the forth I've been working on, zeptoforth, which operates on an MCU where it has to compile into both RAM and flash 18:09:35 of course zeptoforth is an SRT/NCI forth, not an ITC forth 18:10:15 yeah, I'm glad I don't have to work on "weird" arches lol 18:10:36 Cortex-M is not a "weird" arch - lol 18:11:35 I think ulrich drepper once called arm weird, but I guess "systems one wouldn't interact with using a mouse" might be a better expansion :) 18:12:05 ulrich drepper is an idiot 18:12:21 he closed a bug report for glibc on arch with "works on my i386 laptop" 18:12:52 because single threaded x86 code doesn't care about about alignment 18:13:21 ugh 18:13:24 while armv5 just hands you a sigbus/sigsegv if you attempt to load aligned words 18:13:51 ulrich drepper is most of the reason that eglibc was forked 18:14:26 to collect all the fixes for problems he refused to acklowledge 18:14:26 back 18:14:29 yeah, that was kinda darkly hilarious 18:14:58 I was reading back a bit, and ulrich drepper seems like both an idiot and an asshole 18:15:19 i agree 18:15:30 he was a smug idiot 18:15:43 at least with zeptoforth I don't have to deal with any of his crap! 18:16:02 gecause aside from gas and ld I answer to no one aside from STMicroelectronics and ARM 18:16:07 tabemann: if zeptoforth runs into the same problem you have only yourself to blame :-P 18:16:18 yeah, my bare-metal project is inspired by similar ideals 18:16:24 wrt "only myself to blame" 18:16:56 if I only have myself to blame then I can fix my own problem rather than hoping that someone else fixes it for me! 18:17:24 unless it's a problem with the MCU or board themselves, where then I am fucked 18:18:46 https://sourceware.org/legacy-ml/libc-alpha/2000-08/msg00053.html 18:20:33 https://sourceware.org/bugzilla/show_bug.cgi?id=10134 18:20:42 ROFL 18:21:21 looking back at least a decade flame wars can be entertaining 18:23:14 FIXED lol 18:25:52 crest 18:25:55 pong 18:25:59 I have a little suggestion 18:26:12 why don't you put a magic value in your control data for swdcom 18:26:23 magic value? 18:26:36 so that if it's not there, swdcom can know that it's not been initialized on the MCU side 18:27:14 it can now because r11 will be zero 18:27:16 *know 18:27:36 i want to add a small polling loop to deal with that 18:27:56 hmm maybe it's not zero, because I've been running into issues where swd2 spews out garbage if it's not properly connected 18:28:03 if you set all indicies to zero before writing to r11 there is no race condition on connect 18:28:56 I'll do some initalization then of r11 in the code on bootup 18:31:30 --- join: jedb joined #forth 18:33:41 yes 18:33:48 it now doesn't spew garbage 18:35:31 okay, it works much more smoothly right now 18:36:28 (echo "quit forgetram" && cat file1 file2 file3) | swd2 && swd2 18:39:25 I'm happy I got swd2 to really work with zeptoforth 18:42:13 I should go and implement forget-ram 18:46:32 --- join: boru` joined #forth 18:46:35 --- quit: boru (Disconnected by services) 18:46:37 --- nick: boru` -> boru 19:01:56 --- quit: Zarutian_HTC (Remote host closed the connection) 19:56:55 --- quit: cp- (Ping timeout: 240 seconds) 19:59:44 --- join: cp- joined #forth 20:13:11 --- quit: dys (Ping timeout: 264 seconds) 21:00:23 --- quit: _whitelogger (Remote host closed the connection) 21:03:24 --- join: _whitelogger joined #forth 21:24:24 --- quit: _whitelogger (Remote host closed the connection) 21:27:25 --- join: _whitelogger joined #forth 21:37:09 --- join: jsoft joined #forth 22:41:12 --- quit: proteus-guy (Ping timeout: 258 seconds) 22:47:08 --- quit: dave0 (Ping timeout: 246 seconds) 22:48:52 --- join: dave0 joined #forth 22:53:55 --- quit: dave0 (Quit: dave's not here) 23:13:03 --- join: gravicappa joined #forth 23:31:11 --- quit: jsoft (Ping timeout: 264 seconds) 23:59:59 --- log: ended forth/20.06.21