#forth on 2021-03-21 — irc logs at freenode.irclog.whitequark.org

00:30 <crc> mark4: at home, so connection is more troublesome, but I get a segfault with the latest code from github. GDB shows: http://forth.works/share/2639635ccb8f28f36284994b9058bf2e

00:31 <mark4> console or virtual terminal?

00:31 <crc> SSH to remote server (prompt, on iOS), I can try a different ssh client

00:32 <mark4> ya

00:32 <mark4> i know im not handling all terminal types well

00:32 <crc> Ok, it works under the Blink ssh client

00:33 <mark4> phew lol

00:33 <mark4> ssh back in with the other and tell me what TERM is set to?

00:33 <mark4> also see with this one

00:33 <mark4> what is TERM set to on the working terminal

00:34 <mark4> export TERM=workking-term in the broken one

00:34 <crc> Term is xterm-256color on both

00:34 <mark4> hrm

00:34 <mark4> weird

00:35 <mark4> then its not a terminfo problem

00:35 <mark4> so that makes it more onfuzing :)

00:35 <mark4> i found a bug in GCC's static analysis tool :)

00:35 <mark4> have to file a bug report. tho its probably one they caught and fixed already

00:35 <crc> Not a big problem; it's part of why I have multiple ssh clients :)

00:36 <mark4> you know of other apps that break depending on ssh client used?

00:36 <crc> Not off the top of my head, but I've run into others occasionally over the years

00:36 <mark4> kk

00:39 <mark4> escape should quit you now

00:40 <mark4> and f10 should activate the meny bar if i checked that code in yet

00:40 <mark4> i ferget

00:40 <mark4> cursor left and right should move the selected pulldown menu (that does not yet pull down)

00:40 <mark4> and any disabled menu items (in gray) should be skipped

00:40 <mark4> when you do this the moving windows seem to occasionally bleed characters

00:40 <mark4> or put them where they dont belong

00:40 <mark4> need to investigate that

00:44 <crc> Esc does work, f10 pauses the moving windows; hitting left or right resumes the windows moving. (This may be due to the fact that I'm using a virtual keyboard as my physical one is currently not usable)

00:45 <mark4> aha

00:45 <mark4> you brokeded it? :)

00:47 <crc> I need to flash a new firmware; the old layout is faulty (was working on some experimental stuff, but it's now unusable and I can't flash a new firmware until I get to work Monday)

00:48 <mark4> aha

00:49 <mark4> what keyboard is it that you can flash fw to it?

00:49 <crc> Ergodox EZ

00:49 <mark4> i have the MX keys

00:49 <mark4> but i dont use it because its over there wth my desktop collecting dust lol

00:50 <mark4> it goes with me when i go on a contract

00:51 <crc> It's nice, but has too many keys and the thumb clusters aren't quite right (I only use one of them to minimize stretching my thumbs outward)

00:56 <mark4> learn to move your hand instead of stretching your thumb out

00:56 <mark4> not easy to UNlearn lol

00:56 <mark4> start typing with one finger on each hand :p

00:56 <mark4> dont use thumbs :)

00:57 <mark4> so i added -Wextra to my CFLAGS and that uncovered a couple more problems in my code but nits really

00:57 <mark4> i now have -Wall -Wextra -Werror :)

01:01 <mark4> 45864 file size when compiling with gcc.

01:01 <mark4> 37440 file size when compiling with clang

01:02 <mark4> gcc sux :P

01:04 <MrMobius> mark4, are you sure that ratio holds as the program grows?

01:05 <mark4> pretty much yes

01:05 <mark4> its held so far at least

01:05 <mark4> and i really should not be growing too much more yet

01:05 <mark4> i have some snafu;s to fix, glitches that im not one with at the moment

01:06 <mark4> and then i need to implement the PULLDOWN part of the pulldown menus lol

01:11 <crc> mark4: better to just remap keys to comfortable positions; I can ignore keys locations that are uncomfortable to reach

01:11 <mark4> :)

01:11 <mark4> if i ever win that w846523658432 billion dollar lottery ill help you get taht fixed :/

01:13 <crc> :)

17:02 <nihilazo> is there a non-awkward way to encode multiline strings in a forth program?

17:02 <nihilazo> using \n in an S" adds a literal \n

17:03 <f-a> mhhh

17:03 <f-a> I mean

17:03 <f-a> I thought it was possible

17:04 <f-a> but apparently it is not

17:04 <f-a> (to just go to a newline)

17:07 <nihilazo> I'm not going to be storing these strings, just priting them. maybe I could just define words with ." and cr

17:10 <nihilazo> s/storing/operating on/, whatever

17:22 <inode> S\" this line\nthat line\n"

17:22 <inode> non-standard/gforth-specific probably

17:23 <mark4> in x4 you can do string concat of sub strings

17:23 <mark4> not sure about ans forth

18:09 <tabemann> hey guys

18:15 <mark4> hi

18:17 <tabemann> for some reason I'm surprised eLua doesn't support the newer STM32 MCU's

18:18 <tabemann> only more reason to use Forth!

18:19 <mark4> heh

22:44 <veltas> tabemann: I'd try it out if I had that CPU

22:46 <veltas> inode: S\" is standard

22:46 <tabemann> yeah, zeptoforth currently only supports the STM32F407 DISCO, the STM32L476 DISCO, and the STM32F746 DISCO

22:46 <tabemann> but I am open to ports from users!

22:47 <veltas> If you port it to x86 32 or 64-bit I will try it

22:47 <tabemann> it's specifically for Cortex-M

22:49 <tabemann> and it will never support Cortex-M0 or Cortex-M0+ because those require using Thumb-1, which would require at least a partial rewrite

22:52 <mark4> M0 is not thumb2?

22:52 <mark4> then its no better than arm 9

22:52 <mark4> or arm 7 tdmi

22:53 <tabemann> the problem with Thumb-1 is that it's very hard to define numeric constants inline

22:53 <tabemann> either you have to do complex or and shift chains

22:54 <mark4> or use literal pools blech

22:54 <tabemann> or you have to allocate space ahead of time to store constants in

22:54 <mark4> =0x12345678 will work in thumb 1 because the assembler will generate a literal pool

22:55 <tabemann> I don't even know how Mecrisp-Stellaris does it, since it targets Thumb-1, which is just too much trouble for me

22:55 <mark4> and assemble the actual constant after your ret

22:55 <mark4> the assembler will generate a PC relative ldm for the immediate

22:55 <tabemann> the problem with literal pools in Forth is that you have no way of knowing ahead of time how long your word is or how many constants it will need

22:55 <tabemann> so you have to guess

22:56 <mark4> is your forth sub threaded?

22:56 <mark4> indirect or direct?

22:56 <tabemann> mine is SRT/NCI

22:56 <mark4> then call (lit) and have (lit) pull its return address of the stack, fetch the contents of that cell and push an updated return address back onto the stack

22:56 <mark4> look at how t4 does it on my github

22:57 <mark4> tho i use thumb2 code

22:57 <mark4> thumb1 is dead

22:58 <tabemann> I'm targeting more capable Cortex-M processors anyways, like the M4 and M7, anyways

22:59 <mark4> t4 is sub threaded too

22:59 <tabemann> a standard install of zeptoforth takes up 128K, which is more than what many M0 processors have

23:00 <tabemann> in internal flash

23:00 <mark4> thats huge!

23:00 <mark4> -rwxr-xr-x 1 mark4 mark4 73K Aug 2 2020 t4

23:00 <tabemann> well that also includes a multitasker, an event scheduler, a disassembler, numeric routines, and like

23:00 <mark4> thats the extended forth

23:00 <mark4> oh i dont have a disassembler or a tasker :)

23:01 <mark4> but it does have my memory manager and my curses lib stuff

23:03 <tabemann> a big install is even bigger, but it includes things like a heap allocator, a pool allocator, task pools, various multitasking support functionalities such as locks and channels, basic support for ANSI terminals, a line editor - and on the F7 it includes a QSPI interface, a block interface, and a block editor

23:04 <tabemann> I think that zeptoforth code tends to be larger because it inlines a lot, and a lot of the inlined code is bigger than if it were purely subroutine threaded

23:04 <tabemann> but it is probably faster

23:06 <veltas> "probably faster" maybe you should test that!

23:07 <tabemann> well, it's simple - for each inlined word, a bl instruction, an push instruction, and a pop instruction is not executed

23:07 <veltas> Personally I think raw performance is not my first concern, I just require it's not dogshit slow

23:07 <veltas> So don't be Python

23:08 <mark4> and dont USE it either :)

23:08 <mark4> lol

23:08 <veltas> To be fair I have no idea how fast micropython is

23:08 <mark4> i would rather have the old HP rpn calc

23:08 <veltas> I'm assuming it's significantly better performance than full python

23:08 <tabemann> veltas: let's just say you don't use MicroPython if you care about realtime performance

23:09 <tabemann> because of its garbage collector

23:13 <tabemann> one thing to note is that IIRC the base MicroPython takes up ~256K, whereas the big installs of zeptoforth do too... except most of that space is wasted in order to align the image with an erase sector boundary

23:14 <tabemann> and that is a big zeptoforth installation

23:15 <tabemann> (the zeptoforth kernel takes up 27K)

23:17 <mark4> t4's kernel takes up 18k so thats pretty close

23:17 <mark4> not that much in it

23:17 <tabemann> the zeptoforth kernel lacks important things like VARIABLE

23:18 <mark4> i assume it has the do part of that yes?

23:18 <mark4> and the extensions add the ability to create them?

23:18 <mark4> : variable create ;

23:18 <tabemann> it does have CONSTANT

23:18 <tabemann> it doesn't have CREATE even though

23:18 <mark4> i have variable, constant, var and const

23:19 <mark4> how can the kernel NOT have create?

23:19 <tabemann> mark4: CREATE is implemented in Forth

23:19 <mark4> using what primitves?

23:20 <tabemann> : create ( "name" -- )

23:20 <tabemann> token

23:20 <tabemann> compiling-to-flash? if

23:20 <tabemann> dup 0= triggers token-expected

23:20 <tabemann> start-compile-no-push

23:20 <tabemann> compiling-to-flash? if

23:20 <tabemann> token

23:20 <tabemann> start-compile-no-push

23:20 <tabemann> here 28 + ( 28 bytes ) flash-block-size align

23:20 <tabemann> else

23:20 <tabemann> here 16 + ( 16 bytes ) 4 align

23:20 <tabemann> then

23:20 <tabemann> tos push,

23:20 <tabemann> dup tos literal,

23:20 <tabemann> 14 bx,

23:21 <tabemann> $003F h,

23:21 <tabemann> visible

23:21 <tabemann> inlined

23:21 <tabemann> finalize-no-align,

23:21 <tabemann> advance-here

23:21 <tabemann> ;

23:21 <mark4> advance-here is "allot" ?

23:21 <tabemann> \ Fill memory with zeros up until a given address

23:21 <tabemann> : advance-here ( a -- )

23:21 <tabemann> begin

23:21 <tabemann> while

23:21 <tabemann> dup here >

23:21 <tabemann> begin

23:21 <tabemann> while

23:21 <tabemann> dup here >

23:21 <tabemann> : advance-here ( a -- )

23:21 <tabemann> 0 b,

23:21 <tabemann> repeat

23:22 <tabemann> drop

23:22 <tabemann> ;

23:22 <mark4> ok not allot :)

23:24 <tabemann> it's necessary because on the L4 flash has write blocks of 16 bytes

23:24 <tabemann> that's to fill up the remainder of the write blocks

23:25 <tabemann> filling them with zero's ensures that the flash is written to, because there's code that assumes that sequences of $FF are unwritten flash

23:34 <tabemann> one thing about my MicroPython-running calculator is that it takes a (short) while to generate a Mandelbrot set

23:54 <veltas> nihilazo: It is possible to define something like this https://pastebin.com/raw/Yyrpv8Dz

23:55 <veltas> But yes, if you are just printing then I personally use ." blah" CR

23:56 <veltas> The reason I use S\" \n" there is because as far as I know that's the only way to get a new-line string in standard forth

23:58 <veltas> I don't think the standard would let you create a normal inline compiled string, it's trivial to do so on Forths where R@ is the saved IP

23:58 <veltas> Left as an exercise to the reader

23:59 <veltas> "saved IP" I mean the *return IP*