00:00:00 --- log: started forth/19.11.23
00:40:38 <ryke> good job tp!
00:41:09 <tp> and it works nicely so far
00:41:12 <jsoft> here here, well done that man
00:41:22 <tp> I dont know why I didnt think of it years ago
00:42:22 <tp> jsoft, I'll eb putting the two Words needed on my site tonight
00:42:38 <tp> thenb anyone using Mecrisp-Stellaris can have a stack sensitive prompt :)
00:46:57 <jsoft> Weeee
00:47:15 <jsoft> So do you upload it into your own image or whatver the correct term is, do you ?
00:49:21 <tp> I sure can, but you can easily upload the small program into your device
00:49:36 <tp> and have a stack sensitive prompt
01:15:26 --- quit: mstevens (Ping timeout: 264 seconds)
01:15:36 --- join: mstevens joined #forth
01:18:24 --- quit: gravicappa (Ping timeout: 250 seconds)
01:42:53 --- quit: dddddd (Remote host closed the connection)
01:46:18 --- join: smokeink joined #forth
01:51:30 <jsoft> Can someone have a peek at this please: https://pastebin.com/giYHSPz9
01:51:49 <jsoft> Is that horrific, what can I do more betterer, etc
01:53:40 <tp> Pastebin.com is under heavy load right now :(
01:55:04 <jsoft> Gargh
01:55:06 <tp> jsoft, you're a natural kid .... how do Kiwis get that smart just by fornicating with sheep ?
01:55:15 <jsoft> :P
01:56:04 <jsoft> Nah I read too many juggles is bad, are there too many juggles in there?
01:56:08 <tp> it looks fine to me, especially as youre a week old baby forthling
01:56:54 <tp> hahahah you think THAT is too many juggles ??? bwahahahahaha
01:57:46 <tp> jsoft, the cool thing about Forth is that you will wake up tomorrow, look at the code and immediately see ways to simplify or improve it
01:58:06 <tp> while you are making Forth, Forth is making you!
01:58:53 <jsoft> Hmm :)
01:59:51 <tp> or if youre like me .. it may take a little longer ;-)
02:22:33 --- join: rdrop-exit joined #forth
02:23:15 <rdrop-exit> c[]
02:24:15 <rdrop-exit> good evening Forthwrights :)
02:35:08 <jsoft> Hello there
02:35:15 <jsoft> Come across an odd bug
02:35:18 <rdrop-exit> Hi jsoft!
02:35:26 <rdrop-exit> just read your code
02:36:13 <jsoft> lol
02:36:21 <rdrop-exit> If you had a lot of leds and didn't want to use a cell for each you could do something like this:
02:36:28 <jsoft> https://pastebin.com/L1cHmVQD
02:36:31 <rdrop-exit> 3  constant b/led
02:36:38 <rdrop-exit> 100  constant #leds
02:36:46 <rdrop-exit> b/led #leds *  constant b/leds
02:36:52 <rdrop-exit> create leds  b/leds allot
02:36:59 <rdrop-exit> : led ( led# -- a ) b/led * leds + ;
02:37:09 <rdrop-exit> : led-green ( led# -- a ) led ;
02:37:16 <rdrop-exit> : led-red   ( led# -- a ) led 1+ ;
02:37:23 <rdrop-exit> : led-blue  ( led# -- a ) led 2 + ;
02:37:29 <rdrop-exit> : leds0 ( -- ) leds b/leds erase ;
02:37:36 <rdrop-exit> \ examples
02:37:42 <rdrop-exit> 5 3 led-green b!  \ store 5 to the green of the led #3
02:37:48 <rdrop-exit> 1 led-red b@      \ get the red of led #1
02:38:07 <tp> evening Zen Forth Master!
02:38:27 <rdrop-exit> good evening Master Technician (tm)
02:38:33 <rdrop-exit> :)
02:38:39 <tp> heheh
02:39:33 <tp> I'm a technician with a stack sensitive color prompt
02:40:01 <rdrop-exit> cool!
02:40:04 <jsoft> rdrop-exit, hmm
02:40:15 <tp> if the stack >0 then the "ok." prompt is red
02:40:29 <tp> otherwise the usual colour
02:40:39 <rdrop-exit> nice
02:40:52 <tp> it's for beginners .... like me
02:40:56 <rdrop-exit> I have no prompt, and my stacks are always both full and empty
02:41:10 <jsoft> rdrop-exit, Well atm I am using cells, and I cannot figure out why when i go 123 0 green! it sets it into blue, then if I run it again, it then stores it correctly. 
02:41:30 <tp> Zen Forth Masters keep the stack up to 10 levels in their heads so dont need it
02:41:41 <rdrop-exit> My stacks are circular
02:41:59 <tp> I'm at peace with my inner stack
02:42:06 <rdrop-exit> brb I'll take a look at your code
02:45:53 <rdrop-exit> that won't work
02:46:07 <jsoft> hmm
02:46:09 <rdrop-exit> you don't need to fetch to store
02:47:04 <rdrop-exit> unless you want it to work for both endianess
02:47:27 <jsoft> I am not sure what you mean
02:48:01 <jsoft> are you talking about the stores in rgb! ?
02:48:48 <rdrop-exit> try this : green! ( green led# -- ) 16 lshift  tuck rgb@ or  swap rgb! ;
02:49:03 <rdrop-exit> oops wrong
02:49:27 <rdrop-exit> I did it for the wrong stack picture
02:49:58 --- join: dys joined #forth
02:51:36 <rdrop-exit> : green! ( green led# -- ) tuck rgb@  swap 16 lshift or  swap rgb! ;
02:53:20 <rdrop-exit> yikes screwed up again
02:53:35 <rdrop-exit> I'm not used to not having my operators
02:54:15 <rdrop-exit> forgot the $00FFFF and
02:55:11 <rdrop-exit> I prefer the way I posted in the example above
02:55:46 <jsoft> So what is it that I am doing wrong here ?
02:57:25 <rdrop-exit> your not shifting the green back into place
02:57:46 <rdrop-exit> * you're
02:58:13 <rdrop-exit> i.e. 16 lshift
02:59:34 <rdrop-exit> you're way would be:
02:59:41 <jsoft> ahh
03:00:56 <jsoft> im not swapping before the 16 lshift
03:01:12 <rdrop-exit> anyway, if you're updating colors individually, I think 
03:01:13 <rdrop-exit> 5 3 led-green b!
03:01:16 <rdrop-exit> is simpler
03:01:46 <rdrop-exit> i.e. store 5 into led# 3's green
03:02:28 <rdrop-exit> another way would be
03:02:44 <rdrop-exit> 5 3 led >green b!
03:03:17 <rdrop-exit> 3 17 led >red b!
03:03:42 <rdrop-exit> 3 17 led >blue b!
03:04:02 <jsoft> Hmm
03:04:27 <rdrop-exit> where >blue is defined as : >blue ( a -- a' ) 2 + ;
03:05:35 <rdrop-exit> >green would do nothing
03:05:50 <rdrop-exit> >red would be : >red ( a -- a' ) 1+ ;
03:06:45 <jsoft> Interesting
03:06:52 <rdrop-exit> there are lots of other ways, which is best depends on the access pattern of your application
03:07:19 <rdrop-exit> does it usually store the colors individually or as a single combined value
03:07:29 <rdrop-exit> same question for loads
03:08:05 <jsoft> Its going to alter them individually 
03:08:20 <jsoft> but needs to access them ideally as a whole cell
03:09:14 <jsoft> its looking at 24 bits and and it has to send them out pretty quickly
03:09:30 <rdrop-exit> do you want the code to be endian independent or are you ok with leveraging the endianness of your platform
03:09:46 <jsoft> its not going anywhere else
03:10:21 <jsoft> So yeah I am happy with the current endianness
03:10:31 <jsoft> It is working now though, thanks for spotting that
03:11:20 <rdrop-exit> is your target little-endian?
03:12:59 <rdrop-exit> sorry, I may have misunderstood, will you be updating each color individually, or the combined RGB value?
03:13:13 <jsoft> updating individually
03:13:40 <rdrop-exit> ok 
03:14:08 <rdrop-exit> fetching colors individually, or as a combined RGB value?
03:14:13 <jsoft> but when I go to actually read the values to actually write to the leds, I want to access each led's bits as the whole 24 bits of RGB 
03:14:21 <rdrop-exit> ok
03:14:51 <rdrop-exit> is your target little-endian, 32-bit?
03:15:39 <jsoft> https://imgur.com/a/9dRw8EE
03:15:41 <jsoft> :)
03:16:13 <jsoft> little endian
03:16:20 <jsoft> 32 bit
03:16:29 <rdrop-exit> Xmas lights! :)
03:17:47 <rdrop-exit> so if you're willing to waste a byte per led, use a cell for each led, fetch them as a cell, but store individual bytes using b! (or c! as the case may be)
03:18:17 <rdrop-exit> that seems to fit your scenario, unless you have tons of leds and don't want to waste the extra byte per led
03:18:18 <jsoft> rdrop-exit, hmm ok, interesting
03:18:30 <jsoft> rdrop-exit, currently using cells for each led
03:18:41 <jsoft> 1 cell per led I mean
03:19:09 <rdrop-exit> so you're wasting a byte per led for convenience sake
03:19:39 <rdrop-exit> which is cool
03:20:01 <jsoft> Well, I am not sure how I would iterate over 24 bits of a byte which crosses a cell's address limits
03:20:07 <jsoft> or whatever the correct term is
03:20:33 <tp> i think jsoft has plenty of spare memory for this project
03:20:36 <jsoft> I would need to or them together and what not into the stack first I guess
03:21:02 <jsoft> sorry, 24 bits of of the RGB I mean, not of a byte
03:21:07 <tp> 64K flash goes a long way with Forth
03:21:38 <jsoft> I am compiling to ram atm, and have 4k left
03:21:51 <rdrop-exit> you just iterate over the cells, since you're actually using 32-bits to store each 24, and just ignoring the high byte
03:22:14 <jsoft> rdrop-exit, yeah I meant for the case for where no bytes are wasted
03:23:48 <rdrop-exit> you advance byte by byte shift or-ing in 3 bytes for each led
03:24:03 <jsoft> yeah which I don't want to do in this case
03:24:39 <rdrop-exit> there are other ways but I doubt you're leds need high performance code
03:24:40 <jsoft> I mean it might be fast enough to still meet the timing requirements
03:24:51 <rdrop-exit> * your leds
03:24:53 <jsoft> rdrop-exit, they actually kind of do 
03:24:59 <rdrop-exit> aha
03:25:23 <jsoft> like 350 ns, a few too many instructions between each bit toggling about and it goes over that timing
03:25:43 <rdrop-exit> then you're better off wasting the extra byte
03:25:54 <jsoft> that's what I reckon too, glad to hear it :)
03:26:09 <rdrop-exit> another alternative is a 16-bit load, followed by a byte load, then shift-or
03:28:09 <jsoft> would that work all the time? Like say if the 16 bits were across two cells ?
03:28:38 <rdrop-exit> I don't know ARM, so that would depend on ARM's alignment restrictions
03:30:37 <rdrop-exit> paging Master ARM Technician (tm)
03:31:06 <jsoft> Yeah I don't know it super well either :)
03:32:37 <jsoft> This has been quite an interesting experience all this forth shenanigans
03:32:54 <tp> present!
03:32:57 <rdrop-exit> Why do you need to store them, and read them back again?
03:33:01 <jsoft> surprisingly productive despite my absolute virginity to it
03:33:13 <jsoft> rdrop-exit, how do you mean
03:33:40 <tp> rdrop-exit, cortex-M0 is anal about alignment
03:34:09 <rdrop-exit> ok, there you go
03:34:22 <tp> "forth shenanigans" ?? BURN THE HERETIC!
03:35:34 <rdrop-exit> jsoft, you fetch each led's RGB value, then what...
03:35:51 <tp> jsoft, youre a Forth natural, by this time many are wondering why their Windows version of TerrorTerm is locking up when uploading to the Forth MCU
03:36:33 <jsoft> rdrop-exit, bit bang them out
03:36:53 <rdrop-exit> ah, ok
03:37:34 <tp> jsoft, cant you do that critical LED timing using a SPI or I2C peripheral ?
03:37:50 <jsoft> tp, its a spastic protocol
03:37:55 <tp> bit banging is very arduino
03:38:09 <tp> only Kiwis bit-bang :P
03:38:09 <jsoft> tp, yeah its not a standard protocol 
03:38:36 <tp> oh, I'm sure some people use them for it tho
03:38:46 <tp> but I admit utter ignorance
03:39:18 <jsoft> use what for it
03:39:29 <tp> jsoft, if youre a bit short on time, you can DOUBLE your clock without harm to the chip
03:39:41 <rdrop-exit> dinner's ready, catch you later, have fun with your new toys :)
03:39:42 <jsoft> Nah its all working nice atm
03:39:43 <tp> ie jump to 98Mhz
03:39:49 <jsoft> cheers for the help rdrop-exit 
03:39:52 <tp> er 96 Mhz
03:40:00 <tp> cya Zen Forth MAster
03:40:08 <rdrop-exit> ciao :)
03:40:11 --- quit: rdrop-exit (Quit: Lost terminal)
03:40:40 <jsoft> so yes. Things and stuff.
03:41:05 <tp> jsoft, thats a complex proj for a Forth beginner!
03:41:25 <jsoft> Nah bugger it, gotta get into it some how :)
03:41:45 <tp> I mean, couldnt you just be happy blinking the blue led on the Disco ?
03:41:56 <jsoft> Yeah done that first
03:41:57 <tp> like all the other beginners ?
03:42:13 <jsoft> Then interrupts with the button
03:42:22 <tp> cool
03:42:43 <tp> and I've already passed on the secret about interrupts >32
03:42:55 <jsoft> Next project I will try out an L0 and super low power stuff.
03:43:03 <tp> holy cow!
03:43:09 <jsoft> And replace my current PIC stuff with L0's 
03:43:10 <tp> the LO's are not simple!
03:43:38 <tp> youve definitely outgrown pics
03:43:48 <tp> have you tried FlashForth on the Pics ?
03:43:55 <jsoft> why are the L0's not simple ?
03:44:02 <jsoft> In comparison to an F0 ?
03:44:03 <tp> it's damn good, but doesnt run from ram like Mecrisp-Stellaris 
03:44:14 <jsoft> Nah not tried it
03:44:17 <tp> the low power additions affest everything
03:44:21 <tp> affect
03:44:36 <tp> the registers are ALL totally different
03:44:51 <jsoft> Yeah I remember fighting with one ages ago in C
03:44:57 <tp> the clocking is very confusing
03:45:06 <tp> a L0 ?
03:45:25 <jsoft> Yeah prolly an L0, they seem to have the lowest power consumption on paper at least
03:45:36 <tp> I guess the L0 (M0+) is what the Fo should have been
03:45:52 <tp> and they probably do
03:46:29 <tp> tho for lowest power, a MSP430 is hard to beat, and by a stroke of luck, Mecrisp runs on them
03:46:42 <tp> in fact the MSP430 was first
03:46:42 <jsoft> Hmm
03:47:11 <tp> if youre after the lowest power, probably MSP430, after all it's only 16 bt
03:47:13 <tp> bit
03:47:45 <tp> plus the low power modes of the L0 will drive you postal
03:48:37 <tp> I know einsteins who have literally spent weeks on the LO power getting it down to Nanoamps
03:48:53 <tp> so lo that they have to especially clean and seal the pcbs
03:49:30 <tp> but apparently it's a overall process, the software config is only one part of it
03:50:23 <jsoft> Hmm
03:50:44 <jsoft> I got pic boards running at ~400 nA 
03:51:14 <tp> wow
03:51:19 <tp> thats impressive
03:52:03 <jsoft> Yeah I used a yuppy buck regulator
03:52:08 <tp> not much point going lower ?
03:52:21 <jsoft> when doing work it would be @ 3.3v, then go to 2.0V and go to sleep
03:52:30 <tp> battery self discharge is sim ?
03:52:35 <jsoft> nah not much point of 400nA either
03:52:42 <tp> yeah
03:52:45 <tp> it's so low
03:52:58 <jsoft> I don't know what the self discharge was
03:53:09 <jsoft> I was just using crusty aaa's
03:53:19 <tp> what kind of pics ?
03:53:25 <jsoft> PIC16LF18877
03:53:39 <tp> wow 16 series!
03:53:54 <jsoft> I love the 18877's
03:54:11 <tp> I like pics and have a couple of hundred 18 and 24 series in stock
03:54:33 <jsoft> Their.. erm
03:54:44 <tp> but the cortex-m0 and my forth dev env is just so awesome nothing compares
03:54:51 <jsoft> What's it called.. remappable perfipherlaerlaerl shenanigans is very very handy for pcb layout
03:55:03 <tp> I know what you mean
03:55:16 <tp> the gpio matrix
03:55:23 <jsoft> or something
03:55:28 <tp> I've never used it
03:55:34 <jsoft> Its super handy 
03:55:48 <tp> my stuff is so simple I can easily change the pcb layout
03:55:57 <tp> none of it's a problem
03:56:07 <tp> what pcb cad do you use ?
03:56:07 <jsoft> Cant be bothered routing past all that crap? Just move it to another pin
03:56:13 <jsoft> kicad
03:56:26 <tp> youre sounding a bit professional ...
03:56:27 <jsoft> done altium too, but kinda like kicad 
03:56:34 <tp> alitum so sucks
03:56:44 <tp> Id rather eat ground glass
03:57:03 <tp> I used to have to use it in a past life when it was protel
03:57:10 <jsoft> I kinda got used to it after a while, but I am a lot quicker with kicad 
03:57:20 <tp> fresh from the apple orchards in tasie
03:57:35 <tp> I'm a gEDA long termer
03:57:53 <jsoft> never used that
03:58:25 <tp> but I last professionally used PADS and ORCAD under dos at a SMT assembly factory I worked at
03:58:43 <jsoft> ahh ok
03:58:48 <tp> we used to die bond and wire bond etc
03:58:55 <tp> and I was the tech mgr there
03:58:55 <jsoft> im actually supposed to be working on some boards atm :D
03:59:06 <tp> on a saturday ?
03:59:18 <jsoft> yeah well, its not for 'work work', but for a startup 
03:59:38 <tp> you realise that now youve really tasted Forth, life as you know it is over ?
03:59:43 <jsoft> lol
03:59:54 <jsoft> Nah I want to use it in future projects
04:00:00 <jsoft> especially on ARM
04:00:18 <tp> youd flip if you could see my Forth system
04:00:32 <jsoft> because I actually got annoyed with the dev environment / framework / clusterfuck based on C/C++ 
04:01:17 <tp> I had a Arduino user over here a few weeks ago and he saw it running, ... Im not kidding, Ive never seen a person with a month python 'blank' look on their face like that before
04:01:34 <tp> monty python
04:01:45 <jsoft> lol
04:01:58 <tp> what C/C++ system were you using ?
04:02:09 <tp> are ...
04:02:40 <jsoft> tp, I tried the normal cubemx stuff with HAL, LL, CMSIS, tried no ST stuff at all and straight GCC + Makefiles, etc
04:02:42 <tp> generally a nice editor and Gcc plus a Makefile isnt described that way
04:02:51 <jsoft> tp, but thought 'bugger this, i will just use pic'
04:03:05 <tp> the PIC crap stuff ?
04:03:13 <tp> java based >
04:03:15 <tp> ?
04:03:16 --- quit: dave0 (Quit: dave's not here)
04:03:16 <jsoft> mplabx yeah
04:03:23 <jsoft> it does actually work for me though
04:03:24 <tp> a bit meh
04:03:56 <tp> but not as bad as cubemx stuff with HAL, LL, etc
04:04:12 <jsoft> Not at all. That was a nightmare.
04:04:15 <tp> that stuff is insanely complex
04:04:27 <jsoft> It is outrageous 
04:04:40 <tp> Im fine with straight GCC + Makefiles, etc but I never use C any more
04:04:51 <tp> there is actually zero point for me
04:05:36 <tp> it takes me 0.1 second to create a brand new Forth project complete with all the CMSIS-SVD, schematic templates, advanced IDE
04:05:57 <tp> I'm coding in a second and connected to the hardware
04:06:01 <jsoft> What is that CMSIS-SVD thing
04:06:21 <tp> you know how you have to configure your GPIOS etc
04:06:26 <jsoft> yeah
04:06:45 <tp> do you use a memory address or a reference ?
04:06:59 <tp> loke #20000xxx or GPIOA
04:07:07 <jsoft> GPIOA kinda stuff
04:07:19 <jsoft> like consts defined somewhere
04:07:26 <tp> ok so you have a list of memory maps somewhere
04:07:30 <tp> of constants
04:07:34 <jsoft> Yeah.
04:07:38 <tp> how do you get them ?
04:08:01 <tp> make by hand ?
04:08:02 <jsoft> I copied them from existing projects, and the ones which were missing I just looked them up in the datasheet
04:08:08 <tp> ok
04:08:14 <tp> thats what a lot of people do
04:08:18 <tp> I dont
04:08:52 <jsoft> What a rebel :P
04:08:59 <tp> I wrote a CMSIS-SVD parser that generates every single memory mapped register for Forth all automatically
04:09:08 <jsoft> parses it from what
04:09:20 <tp> from the ARM CMSIS-SVD
04:09:27 --- join: gravicappa joined #forth
04:09:37 <tp> it's a XML file thats free and details every register
04:09:39 <jsoft> I cant even remember what the SVD is 
04:09:41 <jsoft> oh ok
04:10:06 <tp> it's a system V description
04:10:11 <tp> or something like that
04:11:09 <tp> I also generate a template file that provides a default * bis! for every single Bitfield
04:11:13 <tp> hahah
04:11:31 <tp> there are 20,000 bitfields on some of the stmn32F7xx
04:12:01 <tp> there are 3300 bitfields on the old stm32f051 alone
04:12:11 <tp> along with 33 peripherals!
04:12:34 <jsoft> its almost like its complicated
04:13:10 <tp> my older stuff is here https://mecrisp-stellaris-folkdoc.sourceforge.io/register-generator.html#svd2forth
04:13:25 <tp> haha, nah, not to the likes of you and I
04:13:31 <tp> to us it's chickenfeed
04:14:09 <tp> so my project manager also generates every peripheral register memory map word for the MCU in use
04:14:56 <tp> and I can just paste them into my code, or if I have enough memory, load them all, but thats stupid because no STM32 can run all it's peripherals at onec
04:15:22 <tp> jsoft, whats your terminal baudrate ?
04:15:27 <jsoft> 115200
04:15:36 <tp> I run at 460800
04:15:46 <tp> and I have hardware handshaking
04:16:07 <jsoft> Yeah I have read about those options
04:16:07 <tp> i dont need to wait for the "ok" like e4thcom does
04:16:23 <tp> my uploads are too fast to see
04:16:53 <tp> so errors or warnings ring the bell and are coulored
04:17:14 <jsoft> Yeah that would be cool
04:17:32 <tp> I write my code in Vim, but I upload it by clicking the Vim "make" icon
04:17:43 <tp> I dont do anything at the terminal
04:18:35 <tp> it's the best IDE Ive ever had but I designed it for me, OSS and Forth make that possible
04:19:07 <tp> jsoft, oh and whats last ?
04:19:28 <tp> I enter a command and my MCU spews iHex up the screen
04:20:06 <tp> that's collected by the terminal log and turned into a CLONE of the project with a binary bootable file as the result
04:20:39 <tp> I can flash that into another mcu and it's identical in every way to the project thats running and was just cloned
04:20:49 <jsoft> Sounds like you need a 5gb of ram java application in there somewhere
04:21:27 <tp> hahahah
04:22:13 <tp> nah, this machine only has 8 cores, 12TB hard drives in ZFS raid with 32 GB ram, it cant handle java!
04:22:25 <tp> the water cooler would boil
04:23:00 --- quit: smokeink (Ping timeout: 265 seconds)
04:23:14 <tp> it's a old machine I built in 2012, it's geriatric almost
04:23:20 <tp> has to be treated gently
04:25:26 <jsoft> yeah ive got some xeon thingy with the stuff
04:25:38 <jsoft> ZFS? You on fbsd ?
04:25:49 <tp> yeah
04:26:06 <tp> 11.1 but about to upgrade
04:26:12 <tp> Xeon!
04:26:17 <tp> kickarse
04:26:23 <tp> mines a old i7
04:26:25 <jsoft> Yeah it calculates the things I guess
04:26:26 <tp> haswell
04:26:57 <tp> the xeons have a rep for being good calculators ...
04:27:09 <jsoft> I dunno, is there any real point in getting new 'top end' stuff now days
04:27:11 <tp> they count sheep really fast
04:27:29 <tp> i couldnt use one, this is faster than I'll ever need
04:28:20 <tp> this is dead silent, fast, has snapshots every 15 mins the last couple of years
04:28:34 <tp> jsoft, what SCM do you use ?
04:29:17 <jsoft> git
04:29:57 <tp> fossil here
04:30:04 <jsoft> cvs ?
04:30:11 <tp> fossil
04:30:17 <jsoft> oh thats a cvs ?
04:30:17 <jsoft> lol
04:30:29 <tp> it's a *everything*
04:31:00 <tp> a ssn, cvs, wiki, bug tracker
04:31:18 <tp> a scm, cvs, wiki, bug tracker
04:31:37 <tp> distributed, web baded interface plus cli
04:31:41 <tp> erk
04:31:45 <tp> distributed, web based interface plus cli
04:35:34 <jsoft> Well I suppose I should get ready to inspect my eyelids
04:35:54 <tp> same here
04:36:00 <tp> youve done well!
04:36:16 <jsoft> Cheers :)
04:36:20 <tp> 25,50 C 
04:36:20 <tp> 78,01 F
04:36:24 <tp> nighto!
04:36:32 <jsoft> Catchya laters on
04:53:20 --- quit: dys (Ping timeout: 250 seconds)
05:04:12 --- join: dys joined #forth
05:05:37 --- quit: pierpal (Ping timeout: 240 seconds)
05:05:39 --- quit: jsoft (Ping timeout: 240 seconds)
05:09:26 --- join: pierpal joined #forth
05:54:26 --- quit: MrMobius (Ping timeout: 250 seconds)
06:12:06 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in)
06:43:48 --- join: inode joined #forth
07:46:09 --- join: dddddd joined #forth
08:09:50 --- quit: heredoc (Quit: ZNC 1.6.5+deb1+deb9u2 - http://znc.in)
08:09:58 --- join: heredoc joined #forth
09:03:22 --- quit: gravicappa (Ping timeout: 276 seconds)
09:54:04 --- quit: X-Scale (Ping timeout: 250 seconds)
09:54:47 --- join: X-Scale` joined #forth
09:55:22 --- nick: X-Scale` -> X-Scale
10:00:39 --- quit: pierpal (Ping timeout: 240 seconds)
10:20:28 --- join: gravicappa joined #forth
11:08:49 --- quit: gravicappa (Ping timeout: 276 seconds)
11:26:00 --- join: pierpal joined #forth
12:21:13 --- quit: ryke (Ping timeout: 240 seconds)
12:46:19 --- quit: dys (Ping timeout: 276 seconds)
13:15:18 <tp> Morning Forthlings!
13:16:32 <tp> you can take the red prompt, or you can take the blue prompt, but once you go down the stack sensitive route, there is no turning back!
13:17:17 <tp> https://mecrisp-stellaris-folkdoc.sourceforge.io/stack-sensitive-prompt.html#ssp
13:44:04 --- quit: inode (Quit: )
13:48:21 --- quit: pierpal (Read error: Connection reset by peer)
13:58:16 --- join: jsoft joined #forth
14:00:38 --- quit: tabemann (Ping timeout: 250 seconds)
14:19:42 --- join: tabemann joined #forth
14:20:49 <jsoft> Morning
14:41:17 <tabemann> hey
14:41:30 <tabemann> it's almost dark here
14:41:59 <tabemann> what's with so many forthers here living in the southern hemisphere?
14:43:49 <jsoft> Unsure
14:43:57 <tabemann> someone just cam into the coffee shop wearing a string of christmas lights
14:44:26 <tabemann> or if not in the southern hemisphere, living close to it
14:44:56 <tabemann> like you, tp, rdrop-exit, and proteus-guy
14:45:55 <tabemann> christmas light-lady just walked by again
14:46:34 --- join: dave0 joined #forth
14:46:39 <tabemann> and dave0 too
14:46:48 <dave0> hi tabemann 
14:46:54 <tabemann> hey dave0
14:47:22 --- join: MrMobius joined #forth
14:47:28 <tabemann> hey MrMobius
14:47:57 <tabemann> for some reason I initially read that as MrMorphius
14:50:09 <MrMobius> hey MrTabemann
14:51:24 <tabemann> oh god this commercial for this local lawyer on the TV in this coffee shop has a bunch of little kids in it
14:55:20 <tabemann> okay, I'm gonna head out - gotta oil change my car
14:55:51 <MrMobius> I have a kind of strange question. how often in practice do you create a word that uses a variable amount of stack space or leaves on the stack a variable number items?
14:55:59 <MrMobius> variable as in not determinable at compile time
14:57:50 --- join: dys joined #forth
14:59:21 <MrMobius> Im thinking about how you could keep some stack items in registers or a limited amount of fast memory
15:00:39 --- quit: tabemann (Ping timeout: 240 seconds)
15:01:36 <dave0> i have a couple of words that pops the values on error
15:01:55 <dave0> i'll try and find it
15:03:18 <MrMobius> but other than that do most of your words leave the stack the same size every time they run or does stack size often depend on the input to the word?
15:04:38 <dave0> most of the time i pop the arguments and push the results... do you mean like + that takes two arguments and resturns one result?
15:05:05 <dave0> 2 2 +     pops 2 2 and pushes 4
15:06:23 <MrMobius> in that case + consumes two arguments and pushes one result so the stack is always exactly one element smaller when you execute +
15:06:49 <MrMobius> what I mean is a case where the stack could be for example one element smaller or it may be two elements smaller depending on the input
15:07:04 <dave0> yeah most of my words are like that... the nmber of arguments and results is fixed
15:07:25 <MrMobius> some calculators have DROPN where it drops the number of items specified by TOS for example. in that case you couldnt make any assumptions about stack usage
15:08:17 <dave0> : >digit ( char -- n true | false) dup [char] 0 58 within IF 48 - true exit THEN drop false ;
15:08:50 <dave0> that converts an ascii char to a number and returns true... except if the char is not a digit it pops the char and returns false
15:09:08 <dave0> i don't know if it's good style, it was convenient for me
15:10:56 <MrMobius> makes sense
15:12:05 <MrMobius> it seems like if you were trying to translate as many stack ops to registers ops as you could, DROP might not actually emit any code
15:12:30 <MrMobius> it would just be a sign to the optimizer that whatever register was holding TOS is now free and can be assigned elsewhere
15:14:54 <dave0> i heard of optimizing compilers for forth, but never seen one
15:17:19 <dave0> https://www.reddit.com/r/Forth/comments/6enzbq/are_forth_compilers_generally_optimizing/
15:17:23 <dave0> just from google
15:26:30 <tp> MrMobius, I'm still a beginner but I think that the stack shouldnt be used that way
15:27:27 <tp> MrMobius, perhaps a array should be set aside for such data ?
15:29:02 <tp> dave0, the Forth I use is optimising it even has a Word for maximum optimisation which Ive never tried  
15:37:48 --- join: tabemann joined #forth
15:39:21 --- join: smokeink joined #forth
15:42:09 <tabemann> hey
15:47:18 <tp> hey tabemann :)
15:47:37 <tp> tabemann, the reason why there are so many forthers down under is simple
15:47:50 <dave0> ehehe aussie forthers
15:49:58 <tp> were were sent down here to stop the the Earth from precession due to the imbalance caused by all the Mexicans flooding into the North America ...
15:55:49 <MrMobius> tp, so if I created a forth where words had to leave the same number of arguments on the stack no matter what, I wouldnt be handicapping myself too badly?
15:55:55 <MrMobius> dave0, ty
15:57:40 <tp> MrMobius, I don't follow, you normally have a finite stack and can use it until it's full without problems, tho I think Moore said that the max depth should be limited to 3 items ?
15:58:54 <dave0> tp: he means a word that might return a different number of results, like it might return 2 results for an input and 1 result for a different input
15:58:56 <tabemann> forcing the in stack size to be the same as the out stack size seems severely limiting
15:59:22 <tabemann> oh yeah
16:00:01 <tp> I went thru that question when I wrote a ADC handler that had to be fast. I was trying to process each byte as it was received and the ADC would complain, so I started using the stack as a buffer which made me uneasy. Using an array worked fine tho
16:00:10 <dave0> it kinda makes sense to me if there was an error... you might normally return a value, but if there was an error you return a flag and error code
16:01:03 <tp> dave0, but that kind of operation happens all the time ?
16:01:06 <tabemann> tp: I have a question you might know the answer to - I want to package an image in with the uhashforth, but I don't have any way of telling the runtime what address the image is at except if I arbitrarily specify an address, but that might waste space
16:01:37 <tp> tabemann, i was that question last night and went to reply but toud logged off :)
16:01:43 <tp> youd
16:02:28 <tp> tabemann, thats unusual to me, with Mecrisp-Stellaris one new binary image replaces the old
16:02:52 <dave0> tp: yep, but is it better to always return the same number of results (eg. always return a value and error=0) or return a different number (don't return an error number if it succeeded)
16:03:01 <tabemann> no, what I mean is I want to package together the runtime and VM image
16:03:22 <tabemann> I an write a program that combines the two (e.g. using Intel HEX format files)
16:03:32 <tabemann> *can
16:03:35 <tp> tabeok
16:03:39 <tp> ok
16:04:07 <tabemann> but the problem is I have no way of telling the runtime where in memory the VM image is
16:04:27 <tabemann> aside from basically just picking an address, wasting space
16:04:47 <tp> tabemann, I dont understand your system
16:04:56 <tp> what 'the vm runtime' ?
16:05:06 <tp> oops
16:05:13 <tp> the 'vm image' ?
16:05:30 <tabemann> I'm loading both a runtime writen in C and a VM image written in VM tokens
16:05:53 <tp> OH!!! (like that makes any sense to me)
16:06:15 <tabemann> I want to flash both onto the device at once
16:07:11 <tp> Im familiar with the process used by Mecrisp-Stellaris or a C program to produce a bootable binary image, but I have no clue what your system is
16:07:30 <tabemann> how does mecrisp-stellaris do it?
16:08:09 <tp> Mecrisp-Stellaris is compiled with gnu arn utils
16:08:12 <tp> arm'
16:08:29 <tabemann> I figured; I'd be doing the same
16:08:44 <tp> it uses a 'map' file which gives the ram and flash sizes
16:09:10 <tp> and assembler takes options specifying the ARCH etc
16:09:14 <tabemann> gotcha
16:09:37 <tabemann> whereas I presume the C compiler would do the same
16:09:52 <tp> the assembly code file has the reset memory address
16:10:07 <tp> yes, it would definitely have all the same stuff
16:10:31 <tabemann> I'm not sure how the reset address would work in C
16:10:49 <tp> basically a cortex-m can start running anywhere it's told, but is usually at the start of flash 
16:11:17 <tp> that would be specified in the C guff instructions to the asseembler I'm sure
16:11:36 <tabemann> guff?
16:11:55 <tp> whatever the official name is for the configs to pass to the assembler
16:12:32 <tabemann> are these like compiler directives or like command-like options to gcc?
16:12:44 <tabemann> *line
16:12:55 <tp> lemme find mine
16:14:07 <tp> i think it's in the linker_script.ld
16:14:14 <tp> ill paste mine
16:15:33 <tp> tabemann, http://dpaste.com/1DMW3T2
16:16:01 <tp> thats all I have for my first cortex-m Gcc blinky of years ago
16:16:41 <tabemann> thank you
16:19:18 <tabemann> bbs
16:21:27 <tp> tabemann, here is the whole thing: http://s000.tinyupload.com/index.php?file_id=15648368833803889249
16:21:55 <tp> it's not much, just a minimum cortex-m0 Gcc blinky
16:22:39 <tp> stm32f0-C-blinky.tar.gz
16:22:40 <tp> Filesize: 0.016 MB
16:29:01 <tabemann> you don't know how much help this is
16:30:13 <tp> I'm happy to hear it
16:31:33 <tabemann> I just realized something though
16:31:41 <tabemann> I'm using a full cell to store the interrupt mask
16:31:56 <tabemann> I'm going to have to use a double cell
16:33:34 <tp> interrupts are disabled by default on a newly booted cortex-m
16:33:51 <tp> in fact, everything is disabled
16:34:28 <tabemann> not surprising
16:34:58 <tp> no, it's a sensible thing to do
16:35:20 <tp> and all the peripherals Ive used have sensible defaults
16:39:11 <tabemann> know what - I'm first gonna try to port your blinky to the M4
16:40:36 <tabemann> because it's been ages since I've programmed an embedded system, and even then it already came with a big API and was used with a commercial RTOS (embOS)
16:41:30 --- quit: smokeink (Remote host closed the connection)
16:42:42 --- join: smokeink joined #forth
16:43:49 <tp> a good idea
16:44:01 <tp> tho the LED may be on a different GPIO pin ?
16:44:12 <tabemann> well yes
16:44:22 <tabemann> I will probably have to make some modifications
16:44:33 <tabemann> like even where flash and RAM begin and how big they are
16:44:58 <tp> yah, I think that has a .gdbinit file also so you can run GDB on it via SWD if you want
16:45:31 <tabemann> I will need to get a GNU toolchain to begin with
16:45:58 <tp> I know Matthias used GDB on Mecrisp-Stellaris when he has problems
16:46:13 <tp> and you can do the same I imagine
16:46:23 <tabemann> yeah
16:46:29 <tp> it's damn handy
16:46:49 <tabemann> I've used gdb with hashforth locally too
16:46:50 <tp> plus have you seen "cutter" ?
16:46:58 <tabemann> no
16:47:16 <tp> it's pretty cool, it's a cortex-m emulator with a nice gui front end
16:47:28 <tp> oss
16:47:32 <tabemann> free software, and for linux?
16:47:33 <tabemann> cool
16:47:36 <tp> yeah
16:47:43 <tp> runs on FreeBSD as well
16:48:05 <tp> you can step thru code etc
16:48:09 <tp> view all registers
16:48:19 --- quit: smokeink (Ping timeout: 240 seconds)
16:48:30 <tabemann> link?
16:48:34 <tp> if you dont think it's damn cool Id want to know why
16:49:29 <tp> Cutter/radare2
16:49:57 <tp> https://github.com/radareorg/cutter
16:50:10 <tp> plus will be in your Linux package mgr I expect
16:50:19 <tabemann> thank you
16:50:40 <tabemann> also, do you know offhand where I could find a cortex M4 toolchain?
16:51:26 <tp> binutils ?
16:51:41 <tp> that will be arm-none-eabi in your Linux repo
16:52:07 <tp> it does all the cortex stuff
16:53:53 <tabemann> everything
16:56:47 <tp> yeah, just specify the --mcu
16:57:47 --- join: smokeink joined #forth
16:57:53 --- quit: smokeink (Remote host closed the connection)
17:00:42 <tp> tabemann, Cutter single stepping thru one of my small cortex-m0 blinkies: http://s000.tinyupload.com/index.php?file_id=76780114888487883297
17:03:51 <tabemann> I just built your blinky successfully
17:08:36 <tp> of course :)
17:08:58 <tp> the gcc blinky is really easy if you have the .ld file etc
17:13:17 <tabemann> I'm having trouble executing your code
17:13:25 <tabemann> it keeps on running into invalid instructions
17:18:50 <tabemann> I swear it's treating the code as x86-64
17:19:00 <tabemann> because I stuff like "rax" in the disassembly
17:21:12 <tp> are you usung the arm stuff ?
17:21:58 <tp> you need gcc-arm whatever I think if you recompile my C code
17:23:37 <tabemann> oh I downloaded that
17:23:47 <tabemann> the problem I'm having is with cutter
17:23:54 <tp> # Specify the compiler to use
17:23:55 <tp> CC=arm-none-eabi-gcc
17:23:55 <tp> # Specify the assembler to use
17:23:55 <tp> AS=arm-none-eabi-as
17:23:55 <tp> # Specity the linker to use
17:23:56 <tp> LD=arm-none-eabi-ld
17:23:58 <tp> OBJ=arm-none-eabi-objcopy
17:24:00 <tp> ahh
17:24:09 <tabemann> yeah I saw that in your Makefile
17:24:10 <tp> you have to select the arch 
17:24:24 <tabemann> how do you select an arch with cutter?
17:24:27 <tp> of course, apologies, I wasn't on the same page
17:24:45 <tp> when you first start cutter there is a options menu
17:25:01 <tp> before the gui opens
17:25:11 <tp> thats the only painful part so far
17:25:21 <tp> you have to select the arch
17:25:38 <tp> the default is probably x86 as you have surmised
17:25:56 <tabemann> I don't see an options menu
17:26:47 <tp> lemme look, it's ben ages since I used it
17:28:28 <tp> click advanced options
17:28:37 <tabemann> okay, I managed to select the arch and like
17:28:38 <tp> after you select the file to open
17:29:50 <tp> you may have to select the endianess etc, just to be sure
17:30:13 <tp> there are a lot of options and display choices
17:30:32 <tabemann> got it
17:30:34 <tp> it will take a while to get the hang of it
17:30:59 <tp> (especially for technicians like myself)
17:35:19 <tabemann> lol
17:36:04 <tabemann> you're a master technician
17:36:38 <tp> heheh, that only means I can use a soldering iron and have the steady hands of a brain surgeon, but the brains of a hand surgeon
17:37:22 <tp> I can however make the Forth prompt RED when the Stack has >0 items :)
17:37:30 --- join: rdrop-exit joined #forth
17:39:08 <tp> today I glue the tiny TFT dislay back on the Longan-nano, increase the baud rate to 460800 and give it hardware handshaking
17:39:45 <tabemann> what should load bin offset and map offset be?
17:39:47 <tp> after that I can release useful bootable binary Forth images for it go RISC-V !!
17:40:01 <tp> they dont really matter, it's only a sim
17:40:39 <tp> it will work ok regardless in my (limited) experience
17:41:03 <tp> it only affects the addresses as you step thru the sim
17:41:04 <rdrop-exit> c[] good morning (-_-)zzz
17:41:25 <tp> Good morning Zen Master Forthling
17:41:38 <rdrop-exit> hi tp!
17:41:44 <tabemann> hey rdrop-exit
17:41:53 <rdrop-exit> hi tabemann!
17:42:07 <tp> rdrop-exit, my subconscious was working on your comment yesterday " I don't have a cursor"
17:42:47 <tp> and it told me that thats because you just have a full screen editor thats 'connected' to your target
17:42:49 <rdrop-exit> Did I say that, I thought I said I don't have an ok prompt
17:43:26 <tp> youre right of course, thats what you said, my subconscious cant remember tings for shit ;-)
17:43:47 <rdrop-exit> my Forth isn't line oriented
17:43:50 <tp> same result applies tho ?
17:44:13 <rdrop-exit> what do you mean?
17:44:24 <tp> ok, it's unencumbered by lines
17:45:04 <rdrop-exit> I'm also using circular stacks, so your color coding on stack height wouldn't apply
17:45:16 <tp> I mean you dont have a prompt because you dont use a terminal to upload, you have a 'something' that doesnt use lines
17:46:16 <tp> thats isnt a editor, uses circular stacks and is programmed by thought using a EEG band you wear on your head ?
17:47:47 <tp> this advanced tech however has it's drawbacks, for instance you're unable to program by thought after a hot girl walks past your window to the street
17:49:19 * tabemann does not want the machine to be able to read his thoughts
17:49:41 <rdrop-exit> I'm not sure I understand the question, perhaps I need more coffee
17:50:13 <rdrop-exit> My Forth isn't line oriented, I interpret words one at a time as I type them
17:50:28 <tp> rdrop-exit, there is no question, the spoon does not really bend ...
17:51:14 <tp> rdrop-exit, like at a terminal prompt ? ;-)
17:51:25 <tabemann> I don't see how that's an advantage - that means you have no way of taking back words after you enter them - whereas in line editing you have to actually commit to each line before it applies
17:52:15 <tp> tabemann, why would you want to take words back ?
17:52:33 <tabemann> because maybe you made a mistake entering them
17:52:42 <tp> ah
17:53:08 <tp> because I use a editor I often type dozens of lines before uploading them to the Forth machine
17:53:20 <rdrop-exit> I also have an editor pane
17:53:44 <tabemann> I've thought of adding an editor to hashforth
17:53:50 <rdrop-exit> My Forth isn't a command line Forth, it's a full screen Forth
17:54:01 <rdrop-exit> just a sec, I'll get a diagram
17:54:26 <tp> clicking on the Gvim Make button uploads everything at 460800 bps, I'd go faster but Gnu Screen has a 460800 bps limit with it's serial facility
17:55:24 <tp> if Ive made a error, typo or Forth just doesnt like me, I reedit the editor ecreen I just sent and click make again. That resets the mcu and reuploads everything
17:55:57 <rdrop-exit>   +------------------------+-------+
17:55:57 <tp> all my tests run out of ram, so I can do that again and again all day long
17:55:58 <rdrop-exit>   |                        |       |
17:55:58 <rdrop-exit>   |     Viewport Pane      | Panel |
17:55:58 <rdrop-exit>   |         64x16          | Pane  |
17:55:58 <rdrop-exit>   |                        | 16x24 |
17:56:00 <rdrop-exit>   +------------------------+       |
17:56:02 <rdrop-exit>   |      Console Pane      |       |
17:56:05 <rdrop-exit>   |         64x8           |       |
17:56:07 <rdrop-exit>   +------------------------+-------+
17:56:20 <tp> old skool!
17:56:32 <rdrop-exit> it's a terminal program, but it's not a command line program
17:56:43 <tp> oh!
17:57:17 <rdrop-exit> The viewport pane always displays a block
17:57:43 <rdrop-exit> I can switch the cursor from the console pane to the viewport pane to edit that block
17:58:02 <tp> thge panel pane displays registers ?
17:58:27 <tp> or a happy pic of a bearded guru meditating on a mountain top ?
17:58:34 <tabemann> lol
17:58:46 <tabemann> okay, I've gotta get going for dinner, bbl
17:58:55 <tp> no problemo cya tabemann 
17:58:57 <rdrop-exit> Depends on what I'm doing, it can display editor info, or target info, or whatever
17:59:10 <tp> nice
17:59:21 <tp> tab between windows ?
17:59:30 <rdrop-exit> The console pane is where I interactively type forth
18:00:42 <rdrop-exit> ctrl-P to go to the viewport, Escape to go back to the console
18:00:58 <rdrop-exit> I'm using keymaps, so that's all changeable
18:01:41 --- join: Nick1 joined #forth
18:01:49 <rdrop-exit> brb, have to take care of something
18:01:51 --- nick: Nick1 -> Guest21373
18:02:59 --- quit: tabemann (Ping timeout: 240 seconds)
18:07:34 <tp> no problemo 
18:24:24 <rdrop-exit> back
18:26:22 <rdrop-exit> BTW tabemann, I'm in the Northern hemisphere
18:33:33 <rdrop-exit> done with my coffee, kids are coming over for sunday lunch, have a full day ahead, catch you tomorrow. :)
18:33:41 --- quit: rdrop-exit (Quit: Lost terminal)
18:40:18 --- join: smokeink joined #forth
18:49:21 --- join: iyzsong joined #forth
19:02:09 --- quit: Guest21373 (Read error: Connection reset by peer)
19:34:23 --- quit: smokeink (Remote host closed the connection)
19:34:44 --- join: smokeink joined #forth
20:01:02 --- join: tabemann joined #forth
20:07:35 --- quit: cp (Quit: Disappeared in a puff of smoke)
20:08:12 --- join: cp joined #forth
20:08:59 --- quit: cp (Client Quit)
20:09:40 --- join: cp joined #forth
20:27:34 --- quit: dave0 (Quit: dave's not here)
22:00:44 --- join: WickedShell joined #forth
22:39:47 --- quit: dddddd (Remote host closed the connection)
22:54:22 --- join: gravicappa joined #forth
23:59:59 --- log: ended forth/19.11.23