00:00:00 --- log: started forth/20.05.06
01:14:54 --- quit: reepca` (Remote host closed the connection)
01:15:07 --- join: reepca` joined #forth
01:20:31 --- quit: mtsd (Quit: Leaving)
01:40:19 --- join: xek joined #forth
03:32:12 --- join: dddddd joined #forth
03:50:50 --- join: iyzsong joined #forth
04:41:36 --- quit: veltas (Quit: Reboot)
04:49:21 --- join: veltas joined #forth
04:51:59 --- nick: deesix_ -> deesix
05:04:18 --- join: TCZ joined #forth
05:25:40 --- quit: merkc0 (Ping timeout: 260 seconds)
06:02:10 --- join: cp- joined #forth
06:27:58 --- quit: Kumool (Quit: FreeZNC - Visit us! Server: chat.freenode.net Channel: ##bnc4you)
06:36:16 --- join: Kumool joined #forth
06:39:52 --- quit: Zarutian_HTC (Read error: Connection reset by peer)
06:39:55 --- join: Zarutian_HTC| joined #forth
06:52:49 --- quit: iyzsong (Read error: Connection reset by peer)
07:01:50 --- quit: TCZ (Quit: Leaving)
07:09:32 --- quit: reepca` (Read error: Connection reset by peer)
07:17:18 --- join: reepca` joined #forth
08:45:37 --- quit: Zarutian_HTC| (Ping timeout: 260 seconds)
09:08:59 --- join: kori joined #forth
09:08:59 --- quit: kori (Changing host)
09:08:59 --- join: kori joined #forth
09:32:20 --- join: Zarutian_HTC joined #forth
10:15:52 --- join: merkc0 joined #forth
10:18:23 --- join: WickedShell joined #forth
10:32:07 <veltas> I'm after a conventional name or recommendation for VARIABLE that takes an initial value
10:35:39 <veltas> i.e. you'd do  0 INIT-VARIABLE COUNTER  instead of  CREATE COUNTER 0 ,  or  VARIABLE COUNTER  0 COUNTER !
10:43:53 --- quit: jsoft (Ping timeout: 272 seconds)
10:57:45 --- quit: merkc0 (Ping timeout: 246 seconds)
11:04:01 --- join: rdrop-exit joined #forth
11:05:42 <rdrop-exit> veltas, FigForth's VARIABLE took an initialization parameter, so you'd do 0 VARIABLE myvar
11:06:41 <rdrop-exit> Some Forths initialize their VARIABLEs to 0 
11:15:30 <rdrop-exit> I can't recall another common name for a variable that takes a initialization parameter, I think most people just use CREATE
11:15:42 <veltas> Hmm I think CREATE is the way to go
11:16:33 <rdrop-exit> My variables take a parameter, but it's for size and alignment, e.g.
11:16:43 <rdrop-exit> 32-bit variable myvar
11:17:04 <rdrop-exit> cell variable my-other-var
11:18:12 <rdrop-exit> for initialization I use a non-standard ALIGNED ( alignment <name> -- )
11:18:36 <rdrop-exit> 32-bit aligned myvar $ 12345678 32,
11:19:13 <rdrop-exit> as my alternative to CREATE
11:20:04 <rdrop-exit> it's past 2am, must sleep, goodnight :)
11:20:09 --- quit: rdrop-exit (Quit: Lost terminal)
11:21:38 --- join: antaoiseach joined #forth
11:21:44 <antaoiseach> hello folks!
11:21:50 <veltas> Hello
11:53:24 --- quit: antaoiseach (Quit: leaving)
13:28:12 --- quit: xek (Ping timeout: 264 seconds)
13:40:30 --- join: dave0 joined #forth
13:42:53 --- join: TCZ joined #forth
13:45:07 --- quit: dave0 (Read error: Connection reset by peer)
13:45:45 --- join: dave0 joined #forth
13:58:28 <crest> tp: have you tried to use can bus instead of usb or rs232 for faster code upload?
13:59:30 <tp> crest, no, usart is fast enough because the slowdown is in the compiling
14:00:33 <tp> crest, my aim isnt the highest speed, it's the most useful IDE first, speed second
14:01:29 <crest> but you stated repeatedly how important speed is to your workflow
14:02:44 <tp> true, but thats after my IDE is dine
14:02:47 <tp> done
14:03:13 <tp> Ive always had access to ethernet on a M4
14:03:43 <tp> and thats pretty fast, but I couldnt integrate it into my system
14:03:49 <crest> ok ethernet is an order of magnitude faster again if you send in transmit large enough messages
14:03:54 <tp> sure
14:04:13 <tp> but it would be tons faster than the compiler
14:04:44 <crest> unless your cpu is busy handling tcp/ip with one byte per packet
14:04:49 <tp> so the speed of compiling is the limit on upload speed in my observation
14:04:53 <tp> yeah
14:05:11 <tp> overall, speed is vital to me
14:05:22 <crest> even one line (at < 200) per packet isn't optimal for ethernet but one line per tcp packet should yield reasonable throughput
14:05:31 <tp> but thats second in priority to a useful IDE
14:05:37 <crest> after?
14:05:51 <tp> so I get the IDE doing what I want, then maxamise the upload speed
14:48:35 --- quit: kori (Ping timeout: 260 seconds)
14:55:27 --- quit: gravicappa (Ping timeout: 258 seconds)
14:56:00 <veltas> White-on-black or black-on-white
14:56:13 <veltas> The eternal question
15:02:52 <tp> the permanantly eternal question
15:04:01 <veltas> I have a habit of switching fonts, sizes, strength and colours
15:05:05 <veltas> But the most I've used is probably: Deja Vu Sans Mono, size 10, regular, white-on-black.
15:18:56 --- quit: TCZ (Quit: Leaving)
15:32:07 <veltas> Actually I've got a real Forth question
15:34:57 <tp> it's the unreal Forth questions I have problems with
15:35:30 <veltas> What's a good way of handling structures with multiple cells without putting them in the dictionary or using ALLOCATE ?
15:36:06 <tp> eww, way outside my pay grade
15:39:40 <veltas> I have considered, for instance, trying to wrangle them on the data or return stacks and potentially passing around address to them *in the stack*
15:40:25 <veltas> Having a separate stack somewhere to simplify handling them in words
15:40:45 <veltas> Using the end of dictionary temporarily, similar to how the pad area works
15:41:23 <veltas> ALLOCATE seems totally overkill/inefficient, but would greatly simplify usage
16:13:29 <crest> veltas: just because the cells form structures doesn't make them less painful to manage on the stack unless everything is the same size
16:14:02 <crest> if you use *just* such structures and normal cells you could reimplement all the stack jugglers
16:14:20 <crest> but at that point what are you doing with the structs?
16:14:57 <veltas> Nah you'd have to use ROLL PICK etc
16:15:12 <crest> do you have to dynamically allocate them or could you just use allot instead of allocate?
16:15:58 <veltas> Assume dynamic
16:16:08 <crest> could you use here as a scratchpad without moving it?
16:16:22 <crest> is their lifetime limited?
16:16:58 <crest> because if you have variable sized structs with unknown lifetimes you just described the reason for malloc/allocate and free
16:17:23 <veltas> Limited within the execution of a word
16:18:13 <crest> in that case you could (ab-)use here as a pool allocator
16:18:52 <veltas> I might be thinking too much like a C programmer, but in C you'd just put this on the stack. Using the heap or a pool allocator would be considered highly unnecessary
16:19:15 <veltas> So I am wondering what kind of analogues we have in forth to give us that same amount of control, and not resort to a complicated allocator
16:19:29 <veltas> I'm sure there is an answer, probably more than one answer
16:20:41 <crest> in some forth systems you can pass negative numbers to allot
16:21:20 <veltas> That would work sometimes, but if you're writing a word used as an immediate or within an immediate....
16:21:39 <crest> it will explode in your face and result in a use after free
16:21:55 <veltas> I already have ideas about how to implement this, anyway. But I also know I am not going to get the 'best' version of this down first time around
16:22:30 <crest> how does your memory map look?
16:22:59 <veltas> Well there are a lot of bytes
16:23:12 <crest> oh really? :-P
16:23:19 <veltas> What specifically are you asking about? Whether there's room for another special 'stack'?
16:23:25 <crest> yes
16:23:47 <crest> how large is your data stack anyway? could it even store all your structs?
16:24:12 <veltas> Well I could fit that inside the dictionary, in a space preceding the words that would provide this feature
16:24:13 <crest> would there be space on the return stack?
16:24:47 <veltas> Currently both stacks are 120 cells or something like that
16:25:06 <crest> and how many structs should your code be able to handle?
16:25:23 <veltas> But structures don't need to be big, don't worry too much about that
16:25:32 <crest> where's your free ram?
16:26:01 <crest> is there any that's not reserved for the dictionary?
16:27:20 <veltas> Yes there is a bit but don't worry too much where I find space, if there is a solution using space somewhere I will consider it
16:27:33 <veltas> It's no difference where it is, unless it's near HERE
16:40:40 <crest> if all your objects a similar sized use a slab allocator
16:41:13 <crest> if you want to deallocate them all at once use a pool
16:41:59 <crest> unless you have to append anything else to the dictionary you can use its free space
16:42:37 <crest> to do this save the here value (on the data or return stack)
16:42:44 <crest> allot your structs
16:43:21 <crest> substract the new value from the old value to get the negative argument to allot
16:43:43 <crest> unless your forth doesn't support negative allot
16:45:08 <veltas> I am trying to keep option of supporting Forth 2012
16:45:18 <veltas> So it does support negative ALLOT specifically
16:47:57 <crest> in that case there is your stack big stack
16:48:39 <crest> an other crazy idea is to do what the old macos classic did
16:48:56 <crest> move objects to defragment the memory
16:49:13 <veltas> Old Windows did that as well
16:49:25 <veltas> Anyway no I am avoiding ALLOCATE, I will certainly avoid that lol
16:49:25 <crest> and return double indidirect pointers instead of normal pointers
16:49:46 <veltas> I tried this once on the spectrum and it had diminishing returns
16:52:29 <crest> it didn't recommend it
16:53:38 <crest> dealing with double indirect pointers and locking objects while there are direct pointers to them is fragile and infuriating
16:54:00 <crest> and you had to guess the maximum number of allocations
16:54:33 <veltas> Yep
16:54:37 --- join: rdrop-exit joined #forth
16:55:45 <veltas> rdrop-exit if you are willing I would be interested in your input on my question
16:56:02 <veltas> It's in the log
16:56:32 <rdrop-exit> hi veltas, sure but I'm half asleep not very coherent yet.
16:56:38 <rdrop-exit> ok, I'll check the logs
16:57:04 <veltas> But basically I want to know how to temporarily allocate structures during the execution of a word
16:57:29 <rdrop-exit> use a scratch block
16:57:30 <veltas> I am avoiding using ALLOCATE etc because it seems overkill, and e.g. in C you could just put it on the stack
16:58:48 <veltas> What is a scratch block?
17:00:17 <rdrop-exit> just a regular block that you reserve for temporary scratchpad use
17:00:34 <rdrop-exit> with all the caveats that come with that
17:01:03 <veltas> Hmmm, that's a new answer for sure
17:01:17 <veltas> Anyway as rdrop-exit arises I sleep, nn
17:02:07 <rdrop-exit> if you need true stack like allocation, you can have use the far end of memory
17:02:36 <rdrop-exit> chunks of 256 bytes or so
17:03:52 <rdrop-exit> instead of a regular pad, you have +pad -pad
17:04:05 <rdrop-exit> each pad is 250 bytes for example
17:04:13 <rdrop-exit> 256 bytes for example
17:04:33 <rdrop-exit> +pad ... do stuff ... -pad
17:07:58 <rdrop-exit> if you need nesting, growing something from the other end of the dictionary is the simplest
17:08:35 <rdrop-exit> using a stack discipline
17:11:15 <rdrop-exit> +pad ... +pad .... -pad ... -pad
17:14:16 <rdrop-exit> have pad return the address of the top chunk
17:15:47 --- quit: reepca` (Read error: Connection reset by peer)
17:16:00 <rdrop-exit> (top in the stacking sense)
17:16:04 --- join: reepca` joined #forth
17:19:06 <rdrop-exit> "The catch is that if storage is used as if it were boundless,
17:19:06 <rdrop-exit> the time taken to run programs will equally be boundless"
17:19:06 <rdrop-exit> -- Peter John Brown
17:31:07 <rdrop-exit>  x+pad Scratchpad Overflow fallback exception handler.
17:31:07 <rdrop-exit>  +pad  Allocate a scratchpad buffer. Raises |x+pad| if the
17:31:07 <rdrop-exit>        scratchpad would start less than |CUSHION| bytes above
17:31:07 <rdrop-exit>        |here|.
17:31:07 <rdrop-exit>  x-pad Scratchpad Underflow fallback exception handler.
17:31:09 <rdrop-exit>  -pad  Deallocate the most recently allocated scratchpad. Raises
17:31:12 <rdrop-exit>        |x-pad| if deallocating the last scratchpad.
17:32:16 <rdrop-exit>  cushion Safety margin between |here| and the scratchpads.
17:32:16 <rdrop-exit>  #pad    Number of bytes per scratchpad.
17:32:16 <rdrop-exit>  sap     Scratchpad allocation pointer.
17:32:16 <rdrop-exit>  pad     Address of the most recently allocated scratchpad.
17:32:16 <rdrop-exit>  sap0    Reset the scratchpad allocation pointer, deallocating
17:32:18 <rdrop-exit>          all scratchpads but one.
17:34:16 <rdrop-exit> (the above is from the docs of one of my old Forths)
17:36:53 <rdrop-exit> (note that in the above I'm not using the term "allocate" in the ANS-Forth sense of course)
17:39:17 <rdrop-exit> (note also that there's always one pad available, that never gets dealllocated)
17:41:14 <rdrop-exit> (that one is used a true volatile scratchpad, just like the traditional PAD)
17:41:26 <rdrop-exit> * used as a...
17:45:44 <rdrop-exit> Anyway, hope that helps with your brainstorming of options
17:45:46 <tabemann> hey guys
17:45:58 <rdrop-exit> hi tabemann :)
17:47:05 <tabemann> note that in zeptoforth using the stack for scratch space is a bad idea, since once you have two tasks, the main tasks stack space is limited
17:47:44 <tabemann> and anyways, I put a check where it raise an exception if a stack overflows its allocated space
17:48:15 <tabemann> (task space grows from the top of RAM)
17:50:03 <rdrop-exit> On my PC Forth I use circular stacks
17:51:04 <rdrop-exit> you can't accidently spill over into RAM
17:58:35 <rdrop-exit> or to put it another way, the stack is always full
18:04:59 <rdrop-exit> off to breakfast, catch you all later
18:05:03 --- quit: rdrop-exit (Quit: Lost terminal)
18:08:11 --- join: jsoft joined #forth
18:14:29 --- join: boru` joined #forth
18:14:32 --- quit: boru (Disconnected by services)
18:14:34 --- nick: boru` -> boru
18:16:12 --- join: Guest22296 joined #forth
18:16:17 --- quit: dddddd (Remote host closed the connection)
18:16:29 <Guest22296> What's up forth fiends
18:17:34 --- quit: Guest22296 (Quit: Lost terminal)
18:18:20 --- join: crab1 joined #forth
18:18:28 <crab1> what's up forth fiends
18:27:15 <tabemann> back
18:35:02 <crab1> how are ya
18:42:06 <tabemann> working on my disassembler, slowly
19:14:48 <crab1> oh fun
19:16:26 <crab1> I've been given 14 days off work because I used the same equipment as someone who's tested positive for covid, so that's interesting
19:22:49 <MrMobius> hope youre getting paid
19:35:14 <tabemann> someone should make a song based off my sharona titled my corona
19:54:28 <tp> my stackona ...
19:54:44 <tp> hey tabemann 
19:55:23 <tp> MrMobius, tabemann is getting paid ... just not for zeptoforth
20:01:02 <tabemann> unfortunately my job seems to expect me to work on every weekend
20:02:44 <tp> hmm
20:03:34 <tp> life of a serf ?
20:06:27 <tabemann> unlike a serf I am paid quite well...
20:07:07 <tabemann> my work though seems to have no concept of scheduling things realistically
20:08:02 <tabemann> they always say "well, we put off N tickets until the next release"... when the number of tickets they didn't put off in itself is unrealistic
20:08:19 <tabemann> and then there's the testers
20:08:45 <tabemann> they always produce tickets faster than we developers can fix them
20:09:10 <tabemann> and sometimes they seem to act as if they were designers rather than just testers
20:10:37 <tp> serfs spent the daylight hours working the land, but it sounds like you're spending your daylight hours coding ?
20:11:03 <tp> tabemann, it's great to be well paid especially in these Coronavirus times :_
20:11:09 <tp> :)
20:11:55 <tp> especially when millions are out of work
20:12:02 <tabemann> exactly
20:12:51 <tp> so work hard and keep that job, wait to be headhunted for more money and better conditions by a boss who is a pleasure to work for ?
20:13:18 <tabemann> the other problem is that, for me, this job is really convenient location-wise
20:13:28 <tp> yes, I recall that
20:13:52 <tabemann> it's almost certain that any other job would be further from where I like, further from where my daughter lives, and further from where my daughter goes to school
20:14:01 <tp> but 7 days a week working has to interfere with your Forth writing time ?
20:14:20 <tabemann> that is true
20:14:38 <tp> yes, and travel is time consuming, expensive and risky
20:15:10 <tp> I once travelled 8 hrs a day for a specific job, was crazy
20:15:32 <tabemann> part of me hopes I can work from home indefinitely, because it's really convenient for me to not have to leave the house to work
20:16:03 <tabemann> but I know that when they lift the "safer at home" order they'll make us come into work
20:16:30 <tp> so I started staying overnight in a 'overnight' travellers hotel but that was no good because crazy women would wake me up at all hours inviting me to 'party'
20:16:58 <tp> but all I wanted to do was sleep
20:17:14 <tabemann> oh kaay...
20:17:30 <tp> ah well, at least when that happens you wont have to work weekends ?
20:17:56 <tp> I was working on submarines back then
20:18:51 <tabemann> nah, whether I have to work weekends or not depends on whether the testers let off with constantly spewing out more and more tickets
20:19:07 <tp> oh oh
20:19:47 <crab1> I am getting paid, yes
20:20:04 <tabemann> that's good to hear
20:20:26 <tp> that was 25 years ago about
20:21:07 <tp> i was quite fit back then and able to fit into the tiny spaces on subs to fix things
20:21:16 <crab1> yeah if I wasn't getting paid I would have to take a significant dent out of my savings
20:21:48 <tp> at times they would have to lower me by by feet into tiny spaces just to get at sensors etc
20:21:48 <crab1> it seems like @tp has had a large variety of different jobs
20:22:23 <tp> not a lot of spare space on a sub, theyre a mass of pipework and electrics everywhere
20:24:11 * tabemann wouldn't want to be a submariner
20:25:53 <tp> my masks finally arrived, I bought a box of 50 of the lighter flat wrap around face masks ... from china naturally
20:26:19 <tp> took 2 weeks, I bought then to go shopping with
20:27:47 <tp> I had to start a 'to do list' for my Forth dev system as so many ideas were popping up
20:27:59 <crab1> I just have about 5 masks that are simple cloth cutouts, two sets of ear holes and such
20:28:11 <tp> #forth is a great source of ideas
20:28:56 <crab1> what's your forth dev system comprised of?
20:53:08 --- join: [1]MrMobius joined #forth
20:53:49 --- quit: MrMobius (Ping timeout: 256 seconds)
20:53:49 --- nick: [1]MrMobius -> MrMobius
21:09:03 --- quit: dave0 (Quit: dave's not here)
21:41:33 --- quit: reepca` (Ping timeout: 260 seconds)
21:44:30 --- join: merkc0 joined #forth
21:53:04 --- join: reepca joined #forth
22:07:51 --- join: merkc1 joined #forth
22:07:51 --- quit: merkc0 (Read error: Connection reset by peer)
22:14:09 <tp> ping crest 
22:35:44 --- join: gravicappa joined #forth
22:50:31 --- quit: jedb (Read error: Connection reset by peer)
23:00:55 --- quit: merkc1 (Ping timeout: 260 seconds)
23:28:12 --- join: mtsd joined #forth
23:35:08 --- join: jedb joined #forth
23:43:31 --- quit: jsoft (Ping timeout: 272 seconds)
23:59:59 --- log: ended forth/20.05.06