2023-05-16 03:28:34 <veltas      > crc: The easiest thing is probably to break on the syscalls and see which registers are cleared or otherwise mangled, and then just push/pop them
2023-05-16 03:28:41 <veltas      > if they're relevant
2023-05-16 03:29:14 <veltas      > And only do that on freeBSD, because all the other kernels seem to preserve the same registers
2023-05-16 03:29:49 <veltas      > Make sure you don't mix up the function call ABI with syscall ABI, they're not the same, SysV doesn't define a syscall ABI apart from for Linux
2023-05-16 03:30:06 <veltas      > An Appendix of SysV's supplemental for AMD64 defines Linux system calls
2023-05-16 03:30:35 <veltas      > But it doesn't claim to be supported by other OS's, it looks like OpenBSD supports the same style voluntarily
2023-05-16 03:30:40 <veltas      > But FreeBSD seems to use its own
2023-05-16 03:30:49 <veltas      > Which I think might be more based on the actual function call ABI
2023-05-16 03:34:17 <veltas      > i.e. it clears registers that are not preserved by function calls
2023-05-16 09:05:36 <crc         > it's quite odd. Under FreeBSD, with no command line arguments, it tries to use the ilo binary as the block file. Passing the block file name as an argument has it load the blocks correctly.
2023-05-16 09:05:56 <crc         > but, it only seems to actually work if I run it under truss(1) to trace the syscalls.
2023-05-16 09:06:43 <crc         > running directly just exits immediately
2023-05-16 09:07:11 <crc         > http://forth.works/temp/log.txt has traces w/o arguments & with a block file specified
2023-05-16 09:17:20 <veltas      > crc: Looks like truss is breaking it to me, it's opening ./i and ilo.rom, suggesting that truss has left 'truss' in argv[0], './i' in argv[1], and 0 in argv[2]
2023-05-16 09:17:41 <veltas      > I'm assuming it's something to do with an assumption it makes that it can pass argv++ to main()
2023-05-16 09:17:53 <veltas      > But my program just loads arguments from the stack directly
2023-05-16 09:19:59 <veltas      > Or maybe FreeBSD doesn't put the arguments in the correct place?
2023-05-16 09:22:38 <veltas      > According to SysV, argc is at (%rsp), and argv[0] at 8(%rsp). This is the one thing I'd expect to be correct between the different SysV kernels
2023-05-16 09:23:14 <veltas      > And likewise the last argv entry should be zero, which is how I check for presense of arguments
2023-05-16 09:24:53 <veltas      > I wonder if FreeBSD leaves zero at the end, might be worth using the count in (%rsp) instead to see if arguments are passed (i.e. argc > 1, argv[0] is the program name -- or NULL if someone's trying to hack a setuid program)
2023-05-16 09:37:14 <KipIngram   > Well, I think I am going to need to make Forth function as a "proper" vocabulary.  When I write this meta compiler, I will be needing to write words that have the common names, but I don't want those words to be run until later.
2023-05-16 09:37:26 <KipIngram   > For example, I'll need to define metacompiler :
2023-05-16 09:37:45 <KipIngram   > But I only want to RUN that when meta compiling, not when compiling later parts of the metacompiler.
2023-05-16 09:38:02 <KipIngram   > So I will want my search path to have Forth on top of Meta.
2023-05-16 09:38:12 <KipIngram   > With Meta CURRENT.
2023-05-16 09:38:15 <drakonis    > meta?
2023-05-16 09:38:29 <KipIngram   > I'm about to write up some stuff that will let me recompile my system.
2023-05-16 09:38:37 <KipIngram   > I'm going to house it in a vocabulary called meta.
2023-05-16 09:38:43 <drakonis    > ah i see
2023-05-16 09:39:18 <KipIngram   > So if Forth is sooner in the search path that meta, it will find the normal : when : appears in the source code, even after I have added a definition for : to meta.
2023-05-16 09:40:06 <KipIngram   > The (small) problem is that forth the vocabulary exists in the native system, but I don't actually have vocabulary functionality until after I start up and load some source for it.
2023-05-16 09:40:18 <KipIngram   > So the word forth just behaves like a variable.
2023-05-16 09:40:45 <KipIngram   > I need to ajust it a little so that I can "poke it" after the fact and promote it to full vocabulary functionality.
2023-05-16 09:40:53 <KipIngram   > Once that functionality exists.
2023-05-16 09:41:17 <KipIngram   > Basically just means I need to get that extra pfa field that vocabulary words need into the word forth.
2023-05-16 09:41:28 <KipIngram   > Then I can set it to the right thing later.
2023-05-16 09:41:45 <KipIngram   > I can allocate that manually in my nasm source.
2023-05-16 09:41:55 <FUZxxl      > which Forth system is this about?
2023-05-16 09:42:09 <KipIngram   > One I've written personally - I don't have it online anywhere.
2023-05-16 09:42:13 <FUZxxl      > ok
2023-05-16 09:42:29 <FUZxxl      > I kind of missed the beginning of the conversation
2023-05-16 09:42:40 <FUZxxl      > someone said you're working on porting a Forth to FreeBSD or something
2023-05-16 09:42:40 <KipIngram   > Though I may be getting close to being ready to put it up somewhere.
2023-05-16 09:43:29 <KipIngram   > Yeah, over the past week or two we've had a few chats about meta compilation, and I've pulled together an approach for that I'm about to try to implement.
2023-05-16 09:43:51 <KipIngram   > I want to re-write this system using it itself instead of using an external tool.
2023-05-16 09:44:02 <FUZxxl      > cool
2023-05-16 09:44:09 <FUZxxl      > I've previously ported Mecrisp Stellaris to FreeBSD
2023-05-16 09:44:15 <KipIngram   > Well, not this exact system - I'm going to change the architecture to some degree.
2023-05-16 09:44:19 <FUZxxl      > so let me know if you have any questions
2023-05-16 09:45:47 <KipIngram   > Will do.  I think I know mostly what I'm about to do here, but over the last few days I've had some fuzzy spots around a couple of the more esoteric points of Forth (like how CREATE DOES> should work) that folks here have helped me recover my old memories of.
2023-05-16 09:46:04 <FUZxxl      > oh yeah
2023-05-16 09:46:08 <FUZxxl      > mecrisp struggles with that, too
2023-05-16 09:46:11 <KipIngram   > I was off on an overly complex path, but Zarutian_iPad bugged me until I got it straightened out.  :-)
2023-05-16 09:46:15 <FUZxxl      > it has <BUILDS DOES> instead
2023-05-16 09:46:22 <FUZxxl      > which is slightly different but much saner to implement
2023-05-16 09:46:25 <KipIngram   > Yeah, I call mine builds> does>
2023-05-16 09:46:36 <veltas      > FUZxxl: I think crc's the one who might have some questions
2023-05-16 09:46:46 <veltas      > Because he's currently porting a program to FreeBSD and is having some issues
2023-05-16 09:46:49 <FUZxxl      > cool thing about the mecrisp port is that it supports dumping itself
2023-05-16 09:46:58 <FUZxxl      > you run save" foo"
2023-05-16 09:47:11 <FUZxxl      > and it creates a binary foo that is the forth with all definitions you just typed
2023-05-16 09:47:18 <veltas      > Does FreeBSD obey the SysV rules for how arguments are passed onto stack at program entry?
2023-05-16 09:47:21 <FUZxxl      > (as long as you compiled them to "flash" within the forth)
2023-05-16 09:47:25 <FUZxxl      > veltas: it should
2023-05-16 09:47:35 <veltas      > I'm not sure if it puts a zero at end of arguments
2023-05-16 09:47:44 <veltas      > because crc's seeing weird behavior without arguments
2023-05-16 09:47:56 <veltas      > but if he specifies arguments it works (?)
2023-05-16 09:48:12 <veltas      > And the same code for reading arguments works on Linux and OpenBSD
2023-05-16 09:48:20 <veltas      > It should be the same on all of them, they're all SysV
2023-05-16 09:50:04 <KipIngram   > Once I've got that extra field into forth's header, then (does) find forth h! find <some vocabulary> pfa 4- h@ find forth pfa 4- h! should convert it.
2023-05-16 09:50:09 <FUZxxl      > veltas: it should
2023-05-16 09:50:24 <FUZxxl      > let me dig up the code
2023-05-16 09:50:45 <veltas      > Nah honestly it might be because FreeBSD handles registers differently for syscalls
2023-05-16 09:51:02 <veltas      > Could be a total red herring that the wrong file is being loaded
2023-05-16 09:51:16 <FUZxxl      > it should do the registers the same way, too
2023-05-16 09:51:29 <FUZxxl      > however, syscalls may have different numbers
2023-05-16 09:51:33 <veltas      > Yes
2023-05-16 09:51:34 <FUZxxl      > and on i386 it's all different
2023-05-16 09:51:40 <veltas      > Does it preserve the same registers as Linux? AMD64
2023-05-16 09:51:50 <FUZxxl      > it should though I have not checked
2023-05-16 09:51:55 <FUZxxl      > easy to check though
2023-05-16 09:51:58 <veltas      > Linux preserves literally all the registers except ... rcx,r10 or something like that
2023-05-16 09:52:05 <FUZxxl      > yes
2023-05-16 09:52:10 <FUZxxl      > this is an architectural limitation
2023-05-16 09:52:22 <veltas      > But FreeBSD is acting like it clobbers more registers
2023-05-16 09:52:46 <crc         > the only syscall I use that's different from OpenBSD numbering is lseek; I expected everything else to work the same as under OpenBSD
2023-05-16 09:53:08 <veltas      > It could be we've got wrong syscall numbers or wrong register assignments order?
2023-05-16 09:53:15 <veltas      > Maybe some of the parameters are in a different order?
2023-05-16 09:54:09 <FUZxxl      > veltas: is the truss output suspicious?
2023-05-16 09:54:18 <FUZxxl      > Have you perhaps tried to single-step through the code?
2023-05-16 09:55:40 <veltas      > crc: 166 and 199?
2023-05-16 09:55:43 <veltas      > For lseeks?
2023-05-16 09:56:43 <FUZxxl      > you want 478
2023-05-16 09:56:49 <crc         > 478 (0x1DE)
2023-05-16 09:56:50 <FUZxxl      > 199 is from freebsd6
2023-05-16 09:56:56 <FUZxxl      > and 19 is ... very old
2023-05-16 09:56:56 <veltas      > I stand corrected
2023-05-16 09:57:08 <veltas      > Good thing I'm not the one writing this lol
2023-05-16 09:57:39 <crc         > I've verified the syscall numbers are correct
2023-05-16 09:57:52 <veltas      > It looks to me like the new lseek has very different paramters
2023-05-16 09:58:00 <veltas      > https://cgit.freebsd.org/src/tree/sys/kern/vfs_syscalls.c
2023-05-16 09:58:12 <veltas      > If sys_lseek is the one
2023-05-16 09:59:14 <FUZxxl      > no
2023-05-16 09:59:33 <FUZxxl      > or let me check
2023-05-16 09:59:50 <veltas      > Why else would the syscall number change, if they don't change the paramters?
2023-05-16 10:00:38 <FUZxxl      > it changed from long to off_t
2023-05-16 10:00:47 <FUZxxl      > and freebsd6 had different padding on 32 bit systems
2023-05-16 10:00:58 <KipIngram   > FUZxxl: You are clearly nice to have around.
2023-05-16 10:01:09 <veltas      > So the parameters are still the same?
2023-05-16 10:01:14 <FUZxxl      > yes should
2023-05-16 10:01:22 <veltas      > Yeah apparently lol, onsite FreeBSD support callout
2023-05-16 10:01:23 <FUZxxl      > for 64 bit systems I think there was never a difference
2023-05-16 10:01:31 <veltas      > Fair enough
2023-05-16 10:01:37 <FUZxxl      > at least I think so
2023-05-16 10:01:45 <FUZxxl      > there isn't any special handling for this one in the libc
2023-05-16 10:01:55 <FUZxxl      > so I don't see how it should have non-standard argument order
2023-05-16 10:02:44 <veltas      > I'm not convinced lseek is the issue
2023-05-16 10:02:53 <FUZxxl      > I don't think so either
2023-05-16 10:03:00 <veltas      > I'll leave this with you and crc since I don't have FreeBSD :)
2023-05-16 10:03:04 <veltas      > 
ACTION shuts up in corner

2023-05-16 10:03:43 <FUZxxl      > best solution is probably to single step this
2023-05-16 10:04:11 <FUZxxl      > I know Forth people are often not a fan of debuggers
2023-05-16 10:04:15 <FUZxxl      > but I promise it's worth it
2023-05-16 10:04:26 <veltas      > I'm a fan of debuggers
2023-05-16 10:04:33 <veltas      > Especially gdb + tui enable + layout asm
2023-05-16 10:04:46 <FUZxxl      > yeah
2023-05-16 10:04:48 <thrig       > gdb likes to crash too much, and then I put in printfs
2023-05-16 10:04:51 <FUZxxl      > though the register output sucks for simd
2023-05-16 10:05:37 <veltas      > In Forth you want to add your own debugger really
2023-05-16 10:05:50 <veltas      > But before we have our own debugger we'll use gdb or whatever external debugger
2023-05-16 10:06:33 <KipIngram   > Or just old school it like me and stick in debug .'s or emits.
2023-05-16 10:06:48 <FUZxxl      > yeah
2023-05-16 10:06:55 <FUZxxl      > doesn't help you in this early stage of things though
2023-05-16 10:06:56 <crc         > gdb is broken:
2023-05-16 10:07:00 <crc         > ld-elf.so.1: Undefined symbol "rl_eof_found" referenced from COPY relocation in /usr/local/bin/gdb
2023-05-16 10:07:07 <FUZxxl      > rebuild
2023-05-16 10:07:11 <FUZxxl      > or update your packages
2023-05-16 10:07:24 <KipIngram   > Sometimes when I'm looking for a stack imbalance I put in a word that writes the stack pointer up in one corner of the screen.
2023-05-16 10:07:30 <thrig       > (there are points you might need to single-step but for me that's like way last resort)
2023-05-16 10:08:24 <crc         > FUZxxl: I updated the packages yesterday before installing gdb
2023-05-16 10:08:25 <MrMobius    > I dont understand the hesitation. single stepping is the first step for me
2023-05-16 10:08:44 <MrMobius    > a lot of beginners ask for help then stop responding when you ask them to use the debugger
2023-05-16 10:08:52 <FUZxxl      > crc: hm that doesn't sound good
2023-05-16 10:09:06 <FUZxxl      > MrMobius: I noticed that many beginners don't know how to use debuggers
2023-05-16 10:09:25 <FUZxxl      > once I had a beginner who I prompted for three days to look up how to use a debugger and he was really dismissive
2023-05-16 10:09:30 <FUZxxl      > then one day he decided to give it a shot
2023-05-16 10:09:34 <FUZxxl      > and was an instant fan
2023-05-16 10:09:40 <thrig       > why are you single stepping if you have no idea what or where the problem is?
2023-05-16 10:09:44 <KipIngram   > I don't know how to use the modern ones.
2023-05-16 10:09:51 <MrMobius    > right and they dont want to know either. a lot of them explain how they want to do it in some other way that usually doesnt work
2023-05-16 10:09:53 <crc         > I'm not good with gdb, but I've used it in the past; was disappointed to have this not be working
2023-05-16 10:09:59 <KipIngram   > I got along fine with debug, but things have gotten a lot more complex since then.
2023-05-16 10:10:35 <MrMobius    > gdb is just fine or whatever your simulator has if that's what you're using
2023-05-16 10:10:51 <veltas      > FUZxxl: Trust me, crc is no beginner
2023-05-16 10:11:10 <FUZxxl      > thrig: so you can find out when the programs behaviour diverges from your expectation
2023-05-16 10:11:26 <veltas      > Yeah that's why I do it
2023-05-16 10:11:34 <thrig       > six hours later, still single stepping... no, that's dumb
2023-05-16 10:11:46 <veltas      > When nothing makes sense and I can't figure it out more intelligently I'll start going through code I want to prove to myself works
2023-05-16 10:11:46 <FUZxxl      > veltas: I'm sorry if that came over as me suggesting he was
2023-05-16 10:12:00 <veltas      > No I don't think you did imply that but I just wanted to say
2023-05-16 10:12:02 <thrig       > (maybe you stepped over the problem because you lost concentration, or you're barking up the wrong tree, or ...)
2023-05-16 10:12:12 <veltas      > Yeah it's not a magic bullet
2023-05-16 10:12:22 <veltas      > Debugging requires all your knowledge and faculties
2023-05-16 10:12:50 <veltas      > It's hard to know when to printf, when to break, when to watch, etc
2023-05-16 10:12:58 <veltas      > When to step
2023-05-16 10:13:10 <KipIngram   > Yeah, there really no telling where the key clue will come from.
2023-05-16 10:13:35 <MrMobius    > thrig: you dont have to start single stepping from the first instruction. you can start where you think the problem is probably starting
2023-05-16 10:13:36 <KipIngram   > It's usually just the case that once you "see it" it all makes total sense all of a sudden.
2023-05-16 10:14:20 <veltas      > I step to dummy check stuff
2023-05-16 10:14:29 <thrig       > I can also stick printfs around where I think the problem is.
2023-05-16 10:14:46 <veltas      > True that, it works the same
2023-05-16 10:14:51 <veltas      > hard to printf assembly though lol
2023-05-16 10:15:02 <MrMobius    > hehe
2023-05-16 10:15:35 <FUZxxl      > veltas: the trick is to write a dumping function
2023-05-16 10:15:35 <veltas      > truss is our assembly printf
2023-05-16 10:15:42 <veltas      > Yeah that too
2023-05-16 10:15:44 <FUZxxl      > that saves all the state, dumps it on the console, and then restores it
2023-05-16 10:15:46 <veltas      > i.e. use Forth
2023-05-16 10:15:57 <veltas      > It's easy to do this stuff in Forth
2023-05-16 10:16:48 <FUZxxl      > sure once your Forth runs
2023-05-16 10:19:22 <FUZxxl      > man I should write a Forth some day
2023-05-16 10:32:24 <KipIngram   > You should - it's fun.  I suppose it's one of my main hobbies.
2023-05-16 10:32:48 <KipIngram   > Sometimes I go long periods without working on it, but I always eventually "come back home."
2023-05-16 10:35:55 <FUZxxl      > I've worked on mecrisp
2023-05-16 10:35:59 <FUZxxl      > but not written my own
2023-05-16 10:36:12 <veltas      > Working on mecrisp is worthy, one of the best forths IMO
2023-05-16 10:38:12 <FUZxxl      > it is!
2023-05-16 10:38:17 <FUZxxl      > the optimizer is pretty crazy
2023-05-16 10:55:20 <KipIngram   > I like the looks of mecrisp across.
2023-05-16 10:55:26 <KipIngram   > Looks really well thought out.
2023-05-16 10:55:36 <KipIngram   > I bought the little gadgets just so I could play with it sometime.
2023-05-16 10:57:15 <KipIngram   > Also, I replaced my ereader not long ago, because my dog chewed on my old one.  But it still works - I'm thinking of looking into other things I can do with it.
2023-05-16 10:57:29 <KipIngram   > I think a Forth on an eink gadget might be fun.
2023-05-16 10:59:08 <KipIngram   > I'm quite along way from that, though.
2023-05-16 11:00:17 <KipIngram   > I think I may want a primitive version of "over over."
2023-05-16 11:00:40 <KipIngram   > I guess that would be 2dup or dup2 from the old double precision integer wordsets.
2023-05-16 11:00:59 <KipIngram   > I noticed, though, that I have over over lying around in enough places to perhaps justify that.
2023-05-16 11:01:05 <thrig       > RODGER WILCO NOVEMBER NINER
2023-05-16 11:03:45 <FUZxxl      > KipIngram: the current hot thing is mecrisp quintus
2023-05-16 11:03:51 <FUZxxl      > matthias is basically only working on that
2023-05-16 11:06:56 <KipIngram   > What does it bring to the table?
2023-05-16 11:07:44 <veltas      > RISC-V
2023-05-16 11:09:37 <FUZxxl      > it's a port of mecrisp to risc-v and mips
2023-05-16 11:09:51 <FUZxxl      > the main cool innovation is that the register allocation code has been rewritten in Forth
2023-05-16 11:09:55 <FUZxxl      > so it's more maintainable
2023-05-16 11:14:44 <KipIngram   > Ah, nice.
2023-05-16 15:23:08 <lispmacs[work]> just got Zeptoforth installed on my RP2040
2023-05-16 15:23:53 <lispmacs[work]> 1 1 + . 2  ok
2023-05-16 15:23:57 <lispmacs[work]> guess it works
2023-05-16 15:25:09 <thrig       > ship it
2023-05-16 15:25:29 <MrMobius    > paging tabemann
2023-05-16 15:32:46 <KipIngram   > That's definitely a ship it result.
2023-05-16 15:34:34 <KipIngram   > RP2040 - that's one of the little USB ARM Cortex dongle thingies, right?
2023-05-16 15:35:17 <KipIngram   > I've got one of those in a drawer in the bedroom.  I think mines an M4.
2023-05-16 15:36:21 <KipIngram   > What does here . say?
2023-05-16 15:36:56 <KipIngram   > Just wondering where it's got Forth situated in the address space.
2023-05-16 15:37:16 <KipIngram   > Linux puts mine way up high.
2023-05-16 15:37:33 <KipIngram   > dp.b @ . 140221655440296  ok
2023-05-16 15:38:05 <KipIngram   > dp.h @ . 140221655474424  ok
2023-05-16 15:38:19 <KipIngram   > I've got the body and header regions in one 64k chunk.
2023-05-16 15:47:04 <KipIngram   > And for the current size of my system:
2023-05-16 15:47:08 <KipIngram   > dp.h @ base.h @ - dp.b @ base.b @ - + . 21348  ok
2023-05-16 15:49:23 <KipIngram   > I'm averaging 53 bytes per word at the moment.
2023-05-16 15:51:37 <KipIngram   > But that's after I've .wiped all the temporary words - average DEFINITIONS are somewhat shorter.
2023-05-16 15:53:24 <KipIngram   > 37 bytes a word if I include those.
2023-05-16 15:53:32 <MrMobius    > KipIngram: RP2040 is the microcontroller in the Raspberry pi pico. They're all M0
2023-05-16 15:53:49 <KipIngram   > Yeah, mine's some different gadget.
2023-05-16 15:54:02 <KipIngram   > I just meant it was also a little USB-based ARM Cortex dongle.
2023-05-16 15:54:12 <KipIngram   > Except it doesn't plug straight in - it uses a cable.
2023-05-16 15:54:35 <KipIngram   > I'd  have to look at it to refresh my memory of exactly what it's called.
2023-05-16 15:54:45 <KipIngram   > I'll go look and see if it's written on it.
2023-05-16 15:55:51 <KipIngram   > https://www.adafruit.com/product/3800
2023-05-16 15:57:01 <MrMobius    > Neat
2023-05-16 15:57:03 <KipIngram   > It is an M4.
2023-05-16 15:57:15 <KipIngram   > Yeah, it's kind of cute, and comes with Python ready to run.
2023-05-16 15:57:21 <KipIngram   > I want to replace that of course.
2023-05-16 15:57:54 <MrMobius    > Right. I think they put such a beefy MCU on the rpi thing specifically for Python
2023-05-16 15:58:05 <MrMobius    > Probably pretty lackluster on a normal speed mcu
2023-05-16 15:58:23 <KipIngram   > Yeah, that Python was one of their main marketing plugs.
2023-05-16 15:58:33 <thrig       > someone was saying vim was a bit pokey to startup on their rpi. on the plus side, they were learning ed
2023-05-16 15:58:54 <KipIngram   > Hmmm.  vim seems fine on the pi I just set up last weekend.
2023-05-16 15:59:33 <KipIngram   > I had to install it though - onlyl vi was there initially.
2023-05-16 15:59:48 <KipIngram   > I haven't really done anything "big" with it, though.
2023-05-16 16:00:14 <thrig       > maybe they had a billion plugins?
2023-05-16 16:00:18 <MrMobius    > I did wonder about replacing my old Linux box with an rpi for vim/Python/assembly console stuff over ssh
2023-05-16 16:00:41 <MrMobius    > Seems like it might be a bit slow though from what people say
2023-05-16 16:01:50 <MrMobius    > Kind of irrelevant now though. I looked at buying a $35 pi for my 3d printer yesterday and they're like $140 if you can find them
2023-05-16 16:02:26 <KipIngram   > Sooner or later I'm going to have to get a 3D printer.
2023-05-16 16:02:29 <unjust      > time to look at other SBCs then
2023-05-16 16:03:23 <MrMobius    > Ya I saw QDROID or whatever but haven't found a comparison and there are tons of them
2023-05-16 16:06:28 <KipIngram   > Once I make forth behave as a proper vocabulary, I think I want to adjust vdrop so that it won't drop forth from the search list.  That would be a quick way to brick my run.
2023-05-16 16:07:55 <unjust      > i got two of these (http://www.hlktech.net/index.php?id=436) for a project recently, they seem ok for the price
2023-05-16 16:09:14 <KipIngram   > That does look pretty neat.
2023-05-16 16:17:09 <KipIngram   > What my new rPi is doing that's odd is that my mosh connection to it from my notebook is intermittently freezing up for 40 seconds - a minute or so.  The rest of the time it's just fine, but every few minutes it'll lock up for a while.
2023-05-16 16:17:26 <KipIngram   > It is on a separate network inside the house - that may be somehow related.
2023-05-16 16:17:41 <KipIngram   > And it doesn't seem that the pi itself freezes up during this time - it's just the mosh connection.
2023-05-16 16:18:21 <unjust      > does a connection to the sshd work during that period of mosh inactivity?
2023-05-16 16:18:45 <KipIngram   > I'd have to check.
2023-05-16 16:18:57 <KipIngram   > You  mean locally, from the pi itself, right?
2023-05-16 16:19:03 <KipIngram   > localhost?
2023-05-16 16:19:34 <unjust      > from the notebook
2023-05-16 16:19:56 <KipIngram   > I'm not running sshd on the notebook.  sshd is running on the pi.
2023-05-16 16:20:19 <KipIngram   > Are you just suggesting I try a separate connection during that period?
2023-05-16 16:20:23 <unjust      > yes
2023-05-16 16:20:30 <unjust      > a standard ssh connection to the pi's sshd
2023-05-16 16:20:31 <KipIngram   > Ok.  I haven't tried that yet.
2023-05-16 16:20:44 <KipIngram   > Oh, you mean without using mosh.
2023-05-16 16:21:04 <KipIngram   > That's definitely worth a try - I will keep an eye on it and try it next time I see it happen.
2023-05-16 16:21:13 <unjust      > i'd guess that should rule out whether mosh is to blame or not
2023-05-16 16:21:30 <KipIngram   > Yes.  I've never had ANY problem with mosh in all the years I've used it, but you never know.
2023-05-16 16:23:37 <unjust      > otherwise, any sort of filtering or lessened QoS for UDP at the hops between your notebook and the pi could be messing with connection
2023-05-16 16:24:59 <KipIngram   > Yeah, I've also thought about trying the notebook on the same network as the pi, but I'm usually downstairs and the connection with that one isn't as good.
2023-05-16 16:25:29 <KipIngram   > It's the actual network that my provider's equipment (AT&T uverse) creates.  Downstairs we have another access point that connects to it.
2023-05-16 16:25:35 <KipIngram   > So that's the extra hop.
2023-05-16 16:54:45 <KipIngram   > Now of course it's not going to do it again.  :-)
2023-05-16 17:04:24 <KipIngram   > Oh, cool.  That pi has an assembler already installed.
2023-05-16 17:04:38 <KipIngram   > Just built and ran this:
2023-05-16 17:04:41 <KipIngram   > .global main  /* Entry point for the program */
2023-05-16 17:04:43 <KipIngram   > main:
2023-05-16 17:04:45 <KipIngram   >   mov r0, #42 /* Move value 42 to register r0 */
2023-05-16 17:04:47 <KipIngram   >   bx lr       /* Return to calling program */
2023-05-16 17:05:18 <Zarutian_iPad> this is ARMv7 or ARMv9 assembly?
2023-05-16 17:05:24 <KipIngram   > v7
2023-05-16 17:05:58 <KipIngram   > processor       : 0
2023-05-16 17:06:00 <KipIngram   > model name      : ARMv7 Processor rev 3 (v7l)
2023-05-16 17:06:02 <KipIngram   > BogoMIPS        : 108.00
2023-05-16 17:06:04 <KipIngram   > Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
2023-05-16 17:06:06 <KipIngram   > CPU implementer : 0x41
2023-05-16 17:06:08 <KipIngram   > CPU architecture: 7
2023-05-16 17:06:10 <KipIngram   > CPU variant     : 0x0
2023-05-16 17:06:12 <KipIngram   > CPU part        : 0xd08
2023-05-16 17:06:14 <KipIngram   > CPU revision    : 3
2023-05-16 17:06:16 <KipIngram   > y
2023-05-16 17:06:18 <KipIngram   > four cores
2023-05-16 17:06:51 <Zarutian_iPad> does anything use the thumb or crc32 nowdays?
2023-05-16 17:07:11 <Zarutian_iPad> the features that is of ARMv7
2023-05-16 17:08:01 <KipIngram   > Well, I see a Forth coming for this guy.
2023-05-16 17:08:18 <Zarutian_iPad> if it hasnt one already
2023-05-16 17:08:24 <KipIngram   > As I tackle this "meta" re-write, I want to try to implement that "portability" layer I've talked about.
2023-05-16 17:08:29 <KipIngram   > Oh, I've installed gforth.
2023-05-16 17:08:36 <KipIngram   > I meant one I write.
2023-05-16 17:08:49 <Zarutian_iPad> olrighty!
2023-05-16 17:09:11 <KipIngram   > So what I'll be trying to accomplish is to be able to re-write that portability layer for arm7 and have it give me something that will work.
2023-05-16 17:09:23 <MrMobius    > a worthy goal!
2023-05-16 17:09:36 <MrMobius    > especially if youre porting to other 32 bit arches
2023-05-16 17:09:37 <KipIngram   > Yeah, but I'm probably biting off more than I realize.
2023-05-16 17:09:39 <KipIngram   > We'll see.
2023-05-16 17:10:04 <MrMobius    > other people who have gone down this route have tried to keep the primitive count extrememly low then implement other primitives out of the minimal set
2023-05-16 17:10:13 <MrMobius    > so relatively little to rewrite when porting
2023-05-16 17:10:15 <Zarutian_iPad> how many essential primitives do you have in your forth, KipIngram?
2023-05-16 17:18:19 <thrig       > watch out for the ones with blowguns
2023-05-16 17:18:54 <KipIngram   > Oh, well...
2023-05-16 17:19:00 <KipIngram   > "essential"?
2023-05-16 17:19:14 <KipIngram   > I don't know - I have a lot of primitives though, many of which would be non-essential.
2023-05-16 17:19:23 <KipIngram   > I haven't gone through and sorted them that way yet.
2023-05-16 17:20:06 <KipIngram   > Like, for conditional returns I have a lot - all the variants of condition, signed/unsigned, etc.
2023-05-16 17:20:18 <KipIngram   > I generate the source for all those with Python.
2023-05-16 17:21:41 <KipIngram   > There's over two hundred primitives all told.
2023-05-16 17:22:03 <KipIngram   > But that's why I want this portability layer.
2023-05-16 17:22:14 <KipIngram   > I want to WRITE the primitives using "portability macros."
2023-05-16 17:22:30 <KipIngram   > that will emit short code sequences into the primitive being built.
2023-05-16 17:22:49 <KipIngram   > I would hope to have just a few dozen of those.
2023-05-16 19:43:33 <KipIngram   > Aha!  I always thought that positioning the cursor to row 999, col 999 and then requesting cursor position with ansi sequence was a crap way to determine the console window size.
2023-05-16 19:43:43 <KipIngram   > Turns out there is an ioctl for that.  Much better.
2023-05-16 19:45:41 <KipIngram   > BTW, I caught the mosh session to the pi freezing again and tried a separate ssh connection.  Didn't work - it hung too.  So looks like mosh is off the hook.
2023-05-16 19:45:57 <KipIngram   > I would have been surprised.
2023-05-16 19:48:13 <thrig       > how often does it happen? can you run tcpdump to capture?
2023-05-16 19:53:54 <crc         > (update from earlier; the freebsd assembly is now working; I had to add code to save/restore r8, r9, r10, and rdx when doing syscalls)
2023-05-16 19:54:01 <unjust      > KipIngram: TIOCGWINSZ?
2023-05-16 20:00:25 <KipIngram   > Yeah.
2023-05-16 20:00:45 <KipIngram   > Hands back a 32-bit value - rows in the low 16 bits and cols in the high.
2023-05-16 20:01:08 <KipIngram   > thrig: I am running tcpdump | grep raspberry now, and see the traffic moving back and forth.
2023-05-16 20:01:18 <KipIngram   > UDP, so it is the mosh connection (it uses udp).
2023-05-16 20:01:26 <KipIngram   > Every few seconds.
2023-05-16 20:01:35 <KipIngram   > Hasn't frozen yet.
2023-05-16 20:01:38 <thrig       > if you write it to a file you could look at it in wireshark after it derps again
2023-05-16 20:01:41 <KipIngram   > Since I started that.
2023-05-16 20:02:00 <KipIngram   > Ok.  I'll watch it like this for a bit, then restart it with a tee
2023-05-16 20:02:07 <thrig       > no, binary write
2023-05-16 20:02:15 <KipIngram   > Oh.
2023-05-16 20:02:16 <thrig       > -w or something, maybe with a filter for just that host
2023-05-16 20:16:20 <unjust      > if possible, also start a capture on the pi itself (in tmux, screen, nohup, whatever you can get to detach from the tty/pty)
2023-05-16 20:17:20 <unjust      > you might notice events, or a lack of events, on that network that could point you in the right direction
2023-05-16 21:12:13 <tabemann    > lispmacs[work]: good to hear!
2023-05-16 21:58:27 <KipIngram   > So that "forth promotion" worked fine.
2023-05-16 21:58:38 <KipIngram   > After I plugged the fields it worked as a proper vocab.