00:00:00 --- log: started forth/19.02.22 00:05:55 --- quit: spestov (Ping timeout: 246 seconds) 00:35:31 --- quit: proteusguy (Remote host closed the connection) 01:09:23 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 01:34:26 --- quit: cantstanya (Remote host closed the connection) 01:36:47 --- join: cantstanya (~chatting@gateway/tor-sasl/cantstanya) joined #forth 01:42:13 --- quit: spestov (Ping timeout: 250 seconds) 01:53:15 bluekelp, corecode, the repo https://github.com/matematikaadit/JombloFort . Not much, mostly 1-to-1 translation of jonesforth to x64. 02:02:32 presiden: were there any riscv version? 02:04:00 --- quit: ashirase (Ping timeout: 268 seconds) 02:06:59 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:07:39 yunfan, not that I'm aware of 02:15:28 --- quit: djinni (Quit: Leaving) 02:22:13 --- join: djinni (~djinni@68.ip-149-56-14.net) joined #forth 03:39:27 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 04:08:29 --- quit: mtsd (Quit: WeeChat 1.6) 04:09:36 --- quit: pierpal (Quit: Poof) 04:09:54 --- join: pierpal (~pierpal@host105-222-dynamic.3-87-r.retail.telecomitalia.it) joined #forth 04:13:20 --- quit: spestov (Ping timeout: 245 seconds) 05:30:42 --- quit: pierpal (Quit: Poof) 05:30:59 --- join: pierpal (~pierpal@host105-222-dynamic.3-87-r.retail.telecomitalia.it) joined #forth 05:43:38 --- quit: pierpal (Quit: Poof) 05:43:58 --- join: pierpal (~pierpal@host105-222-dynamic.3-87-r.retail.telecomitalia.it) joined #forth 06:09:47 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 06:16:07 --- quit: dave0 (Quit: dave's not here) 06:42:30 --- quit: spestov (Ping timeout: 245 seconds) 07:20:52 --- quit: tabemann (Ping timeout: 268 seconds) 07:46:09 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 08:40:25 woot - multiuser rpany socket server working 08:49:46 --- quit: spestov (Ping timeout: 255 seconds) 09:22:53 --- quit: KipIngram (Ping timeout: 244 seconds) 09:30:37 --- join: proteusguy (~proteusgu@203.160.190.58) joined #forth 09:30:37 --- mode: ChanServ set +v proteusguy 09:35:14 --- join: KipIngram (~kipingram@185.149.90.58) joined #forth 09:35:14 --- mode: ChanServ set +v KipIngram 09:48:09 --- quit: nighty- (Quit: Disappears in a puff of smoke) 09:52:17 --- quit: pointfree (Excess Flood) 09:52:55 --- join: pointfree (sid204397@gateway/web/irccloud.com/x-winrqbmljgljqxst) joined #forth 09:53:40 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth 10:33:34 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 10:55:29 --- quit: gravicappa (Ping timeout: 240 seconds) 11:00:44 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth 11:33:06 proteusguy: I've been playing with mecrisp-stellaris on an stm32f0 board 11:33:20 https://gitlab.com/lilo_booter/rpany-comms/blob/master/README.md <- embrionic and crappy code - spent most of the time fighting cmake and boost::asio (sadly, it's an older asio too - boost 1.58 in use - current boost has a different api) - think the mixin idea should allow for interest extensions to be added though 11:33:40 though, not sure if anyone remembers, I think I _finally_ may have a lead on the bug that haunted me for years on the stm32f4 (NB - 4 vs 0) arm forth I was working on 11:36:06 --- quit: mtsd (Quit: WeeChat 1.6) 11:36:25 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth 11:36:44 I really like stellaris so far. the comments and internal variable names are mostly in German and it's a whopping 19k so... I might be tempted to fork it 12:28:07 --- quit: mtsd (Quit: WeeChat 1.6) 12:41:11 i feel bad for Factor 12:41:34 It should've ended up a Python competitor but I think they made certain stuff just a bit weird 12:42:17 i should try one of those fancy wizbang newage forths before i give up on the language entirely 12:45:17 Why would you "give up" on it? 12:47:44 just not that enthused about it 12:47:57 has too many shortcomings that i find unacceptable 12:48:34 what kind of stuff doesn't vibe with you 12:50:14 there are things that directly conflict with the fundamental nature of it. for example, i appreciate the simplicity of how it works, including the typelessness, but without typing you lose operator overloads, so when you @ or ! you have to know the size of the field you're fetching or storing 12:50:41 well, the size is a cell 12:50:45 not always 12:52:00 Well any field is always a cell 12:52:09 unless you use c@ 12:52:25 when do @ or ! operate on anything but a cell sized thing? are you maybe thinking of something like c@, etc? 12:53:08 : type-@ dup @ swap 1+ dup @ swap 1+ @ ; ( overloaded) 12:54:04 bluekelp, yes. so you have to know when to use c@ or @ or q@ if such a thing exists 12:55:01 I find it hard to imagine fetching a bunch of fields for a data structure you're not sure about 12:55:26 but I do that all the time 12:55:50 I read and write to structure fields every day that are in APIs that I didn't write, or that I wrote so long ago there's no way I remember what the field sizes are 12:56:19 I guess if you're writing a dynamic language that's true 12:56:45 "dynamic language?" 12:56:49 like 12:56:52 Python or something 12:56:55 dynamically typed 12:57:02 no, I'm thinking of c 12:57:30 stat(filename, &buf); // do you know how many bytes to read from buf.st_size? 12:58:36 just define a data structure in Forth?... 12:59:02 I think gforth actually provides C-style structs in the core language 12:59:17 i've never seen a good explanation of how to do that. instead i usually see "stop trying to write c in forth. cm says the solution to struct is to don't do that" 12:59:38 i don't use gforth 13:00:02 the biggest appeal of forth to me is that i /don't/ have to use some gnu trash 13:00:45 and on a similar subject: there appears to be no good way to write reentrant functions in forth 13:00:55 another one that i usually see dismissed as unimportant 13:01:45 in my experience, functions have a way of getting reentered (???) in ways you don't expect 13:02:11 can you give a more concrete example of how and when this happens? 13:02:33 any time you invoke a callback you risk being reentered 13:03:09 So when you say reentrant you mean "can be called mid-execution of itself" 13:03:12 so back to my earlier example: stat(filename, &buf); <-- there's no good way in forth to do that 13:03:12 my re-entered you mean called without your code itself explicitly doing it? 13:03:29 ? 13:03:32 bluekelp, i mean your function appearing on the call stack more than once at a time 13:03:47 yes, what WilhelmVonWeiner said 13:04:18 there is nothing inherently wrong with that - the stacks can manage that as long as an infinite recursion does not occur 13:04:32 That shouldn't be a problem with Forth as long as you follow the same constraints as other langauges: avoid globals and self modifying code 13:04:49 no, it can't, because buf isn't a cell 13:05:19 I can try and get to that one in a second 13:06:27 But I don't imagine reentrancy problems to be much of an issue with a function written to be reentrant 13:06:33 are you interfacing C and forth or using C just to illustrate concepts you are more comfortable explaining in C? 13:06:40 the latter 13:07:21 He wants to know the Forth equivalent of finding the size of a file using the `stat` system call 13:07:52 as in, accessing that field of the structure returned into buf 13:08:17 and how `buf` would even become that structure in the first place, since you want to access the field st_size 13:09:17 zy]x[yz: do I have this right 13:10:56 structs are just base pointers and offsets, no? knowing a cell is a pointer to a struct allows you to add that offset to get the pointer to the field you want, yes? 13:13:48 yes 13:17:39 zy]x[yz: This resource might give you enough information to help you get how structs could be implemented in forth and probably enough to implement them yourself, even if it is gforth http://www.complang.tuwien.ac.at/forth/objects/structs.html 13:24:36 I'd just define words to access the fields I cared about. E.g., http://forth.works/9f5215bbdb6553a370f9e18aac967930 13:26:19 same lol. 13:26:43 but some people like C-style structures because they're easier to visualise 13:27:01 I think the fact the field names are translated to offsets is lost in the abstraction 13:29:40 I agree about using words for the structure field abstraction. reading Thinking Forth has been great - putting names like "component" and "lexicon" on things is helping me clarify the process of forthing 13:39:54 writing accessors like these is a littile annoying, but it's not like it needs to be done often, and once done, it's easy to pull out for future projects that need them 13:58:58 sorry, work got exciting there for a few minutes 13:59:38 crc, offsets are not my problem. statbuf stat.st_gid ( what do I write now to read the st_gid field? ) 14:00:39 @ if the cells are 32bit, not sure on 64-bit 14:03:09 or @ 64-bits, shift and mask 14:03:43 and if you want stat.st_ino then you need to know to read two cells 14:04:41 yes 14:04:52 well, data structures are well-defined else they're not really structures 14:05:15 this is what i meant when i said earlier that i'm told it's not a problem 14:05:16 I'd likely end up writing a dedicated word to access each field specifically in this case 14:06:01 I don't know if you're explaning the problem in a way that frames it as a problem then?... 14:06:25 i'm just telling you one of the things that turns me off to forth 14:06:37 : stat.st_ino n CELLS + dup @ swap 1+ @ ; 14:06:44 this is a shortcoming that i find unacceptable 14:07:14 and as i originally explained, i understand that there is no good fix for it without introducing a typing system, which breaks the fundamental simplicity of forth 14:07:21 you aren't really complaining the shortcoming properly 14:07:42 and i have to agree - it's why my approach is about objects rather than bytes and pointers 14:07:44 i'm not complaining, this is just my observation that has led me to conclude that forth is not for me 14:07:52 the simplicity is maintained with defining words to access fields 14:07:57 you literally do that in C 14:08:03 it's just obscured by the syntax 14:09:04 it's not the same in c. the type is attached to the symbol, not to the operator 14:10:05 hmm - but the overloading on symbols in c is pretty simplistic 14:10:09 what operator, it's a struct field containing a value 14:10:29 the accessing operator - fetch or store 14:11:03 C doesn't do fetch or store operators 14:11:10 not like Forths 14:11:22 it's like you're being intentionally obtuse 14:11:30 c has an assignment operator which fetches and stores 14:11:42 when i use the assignment operator, i don't have to tell it the size of what i'm fetching or storing 14:11:53 Okay, now I see 14:11:55 the size is attached to the symbols i'm fetching from or storing to 14:13:32 pretty simple, just have a field start with the size of the field and have your field fetch operator handle it appropriately 14:14:09 you're saying to encode metadata into the data structure memory itself 14:15:10 this isn't a problem you have to solve for me. this was just one example in response to "what kind of stuff doesn't vibe with you" 14:15:10 hmm - that would effectively double the size of an int and make a char way larger 14:15:29 I wouldn't do it like that at all because it's a ridiculous question 14:15:35 You know what the fields are 14:15:54 you know what sizes of field you have to access 14:15:59 this is an edit-time problem 14:16:10 i'm still in #forth, which means forth is still of some interest to me. but it's become more of a peripheral interest and not actually something i intend to use any time soon 14:18:20 Maybe if you used it for some small stuff 14:18:37 you'd get why the question always gets the same response 14:18:49 i do get it 14:19:00 i'm not telling you that you can't use forth 14:19:05 i'm telling you it's not for me 14:19:49 if you got it you wouldn't be asking how to do this C-style struct field size accessor thing 14:19:59 i don't have anything on my radar at the momoent where forth is a good candidate 14:20:16 i'm not asking 14:20:19 jfc 14:20:20 not surprised, the world has mostly moved past it 14:20:23 i don't think that's a fair comment WilhelmVonWeiner - it's possible to understand and still dislike 14:20:58 and that is all zy]x[yz is saying - i also think he makes a fair point (though i still love forth for other reasons) 14:22:05 --- join: yrm (~yrm@KD106130204082.au-net.ne.jp) joined #forth 14:24:11 I can totally understand why Chuck opposed ANS and C-style Forth 14:26:56 forth and it's many, many implementations are a mine of information - from low level implementation insight and detail to high level approaches - all of which you can borrow, re-implement and mess around with - after all, that's what we're all doing anyway - taking a basic idea and running with it, but still retaining enough common ground to parse the work of others 14:30:54 having thought about it for a few minutes, i don't think a c-style forth aims high enough 14:31:06 "high enough"? 14:32:52 yeah - there are a million and one ways to play with the bits and bytes and offset and shifts... but putting all those operations together to create something complex.... like, say, a modern video player with every supported codec... that's not something you want to do at any level, let alone rpn 14:33:52 you can build up abstraction pretty quickly 14:34:34 I don't know if I'd want to on the kind of operating systems we use now, though. 14:35:03 you definitely can - especially when the components already exist and all you need to do is put them together - and you can do this in a platform agnostic manner 14:35:45 sounds like I need some kind of.. C++ header file based solution to my FFI-related woes 14:35:58 :D 14:36:57 quite serious though - it's trivial to put stuff together on a stack and use the stack manipulations to arrange things as you want them for each operation 14:38:46 esp when the objects in question can vary in complexity from numbers, strings, bools, json docs/objects (or indeed xml), images, video, audio and so on 14:39:31 hence what i said - a c style forth does not aim high enough 14:40:19 --- quit: spestov (Ping timeout: 255 seconds) 14:41:20 I mean, you can write ways to handle all your "types" with or without designing tagged types or not, and it's something you would deal with at design not compile time 14:41:54 but I can see your point with "higher level" objects on the stack 14:42:13 nah - you ultimately want flexibility - the end user could drop in x265 and on it goes 14:42:42 thanks :) - i really believe it is the right thing to do :) 14:43:07 I would see that as an API on some video related words, because your typed objects and that on the stack are really just addresses 14:43:20 you're just shuffling addresses knowing that which is stored at the address 14:43:57 but if you're designing the program, you can really follow what's where at the point it's there, if you get what I'm saying 14:44:43 indeed - the user needs to know what they're doing... 14:46:09 and there, well... i see the stack again - the user sees what they have - they add to it, move things around - play this, convert that to a different format, grab frames and make a composite... output to a png, post on youtube... 14:46:12 i dunno 14:46:37 but that's the point - they have things in front of them - they look at them 14:47:26 they have a stack 14:48:28 https://twitter.com/lowfatcomputing/status/1099073956500238336 <--- "gelForth - place & route by hyperstatic scope" ( this Saturday at SVFIG if Kevin can insert me in the agenda) 14:48:37 I would probably write an interface for a user. 14:49:09 pointfree: will this be streaming? I need to use my PSoC before it starts rusting or bubbling or something 14:52:34 WilhelmVonWeiner: yes the talks will be streaming https://www.youtube.com/channel/UC2v6b9814uIA5egk5-yHAVw 14:52:34 ...but the psoc bitstream will be random access 14:53:48 as long as the Forth lets me route pin x to pin y through some Forthy forth I don't mind how random it is 14:54:17 I'll post slides and some (portable) forth code tested on mecrisp for psoc5lp with the talk 15:01:16 --- quit: yrm (Quit: yrm) 15:05:55 WilhelmVonWeiner: This is what it currently looks like to use it http://ix.io/1BNt ( copied from my test examples)...but instead of an explicit forth-Boolean algebra wordset (like in the first talk), the Boolean algebra will now be implicit and hidden in the forth control flow. This mixes with existing arm codewords, etc, etc. 15:07:21 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 15:07:59 I must've missed this first talk 15:18:01 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth 15:18:53 hi 15:23:55 hi dave0 15:24:01 hi WilhelmVonWeiner 15:24:05 what's up 15:28:07 nuffing much, just thinking 15:28:12 you? 15:28:25 trying to nicely write a reduce in Forth 15:28:42 th parsing kind of reduce? 15:28:50 like Python's `reduce(operator.sum, [1, 2, 3, 4, 5])` 15:29:02 maybe it's operator.add 15:29:13 ar i don't know python, i'll have to google it 15:29:21 usually you would list comp so I don't know the operator you lift 15:30:23 ah i get reduce 15:31:26 so in forth you push 5 4 3 2 1 then you push 5 for the length then you push an xt for operator.add then you reduce? 15:31:37 something like that. 15:32:01 I'm reading it from an address because that would be my use case. 15:32:25 ah 15:32:27 in fact I'm manually unrolling the loop because I like moving things out of interpret time, but it's a fun exercise 15:33:15 i once learned APL it has a slash operator / that does reduce 15:33:26 that's cool as hell 15:33:38 i think it worked like + / 1 2 3 4 5 which does 1+2+3+4+5 15:34:23 the only trouble is i'm hopeless at math! lol 15:34:30 and APL is longobsolete 15:35:04 I too am hopeless with maths but I long to improve 15:35:15 once I finish this book on 4.4BSD I plan to read only maths books 15:35:23 even baby beginner books 15:35:40 unix is meh 15:37:25 I'm finding the design of 4.4BSD very interesting 15:37:58 crc mark4 Sorry guys - I'm having trouble remembering which one of you has the nifty "stack of stacks" approach to managing vocabularies and contexts... 15:38:29 hi KipIngram 15:38:38 Hi dave0. How goes? 15:38:43 IT'S FRIDAY! 15:38:47 no shit 15:38:49 For me at least. 15:38:54 I thought it was thirsday 15:38:58 *thursday 15:39:07 Friday is without a doubt my favorite day of the week. 15:39:16 thank god 15:39:18 Work just isn't that thrilling anymore. 15:39:33 But it was for a while when I was younger, so I guess it's ok. 15:39:43 I had my day. :-) 15:40:43 json is the most boring thing to ever grace my vision 15:40:51 but it works I guess 15:41:08 Anyway, I'm interested in "refreshing" on the details of that vocabulary management approach. What is the word that pushes a new "full context" into place, that you can modify at will? And what exactly does it push? Does that leave you with just the FORTH (or system or whatever you call it) vocabulary active? 15:41:08 KipIngram: not me; I have only a single global dictionary. 15:41:21 Hi crc. 15:41:39 I seem to recall from past discussions that that operation inherits whatever is in place at the time. 15:41:45 But that feels a little off to me. 15:41:59 I want to think that it should produce a fixed "starting point" every time. 15:42:20 I guess I can see an argument for either way. 15:42:24 Lol. learn something stupidly obvious you've missed every day 15:42:31 look at this stonker 15:42:51 : looping-word ( n --) 0 tuck do ... loop ; LOL 15:42:54 I was toying with the idea of <<< for that word, and >>> to pop back to the previously existing context. 15:43:06 I can put a 0 in without weirdness 15:43:10 so obvious now 15:43:48 :-) yeah, tuck is sort of perfect for that, isn't it? 15:44:04 You know, caching TOS in a register sure does make nip and tuck easy. 15:44:15 Oh, well, nip at least. 15:44:25 tuck is a bit more involved. 16:47:29 --- quit: spestov (Ping timeout: 245 seconds) 17:02:00 --- quit: john_cephalopoda (Ping timeout: 258 seconds) 17:03:53 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 17:05:35 --- quit: proteusguy (Ping timeout: 246 seconds) 17:26:38 --- join: travisb (~travisb@rrcs-162-155-170-75.central.biz.rr.com) joined #forth 17:41:21 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth 17:42:17 --- nick: travisb -> tabemann 17:42:31 hey rdrop-exit 17:44:02 Hi tabemann 17:44:49 c[_] 17:45:08 coffee cup :-) 17:45:37 Yup :) Waking up on a lazy Saturday morning. Hi dave0 17:46:10 hey dave0 17:46:20 hi rdrop-exit, tabemann, KipIngram :-) 17:47:16 [_]b 17:47:39 I like it that I'll be off the next two days, I don't like it that it's supposed to freezing rain tomorrow 17:47:42 hey john_cephalopoda 17:47:53 Hi john_ 17:48:55 hopefully it's not the type of freezing rain that literally freezes onto your windshield - had that happen once this winter 17:49:06 while you're driving that is 17:49:27 I haven't been cold in decades, except when the aircon's too high 17:50:22 damn that Global Warming! 17:51:14 you would say that we could benefit from global warming here in WI, but globally the negative effects would far outweigh the local positive ones 17:51:57 * PoppaVic rotfls 17:52:22 global warming is why california and australia are always on fire 17:52:51 The politically correct term is "lit". 17:52:51 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 17:53:18 I went to a con in Milwaukee once, it was freezing 17:53:33 I've never seen "lit" used to describe a wildfire 17:53:53 Something or somebody lit a wildfire. Thus the wildfire is lit. 17:54:00 qed. 17:54:28 the cold we can deal with, even though there were two days this winter which were like -25 F, which people even here are not used to 17:54:41 everything was canceled or closed those two days 17:55:14 When it's cold you can always wear more clothes. When it's too hot there are limits to what you can get away with. 17:55:46 I'm amazed when I hear how hot AU gets 17:55:47 I'm in shorts all year around 17:55:51 like 45 F 17:56:11 like how do people survive at 45 F 17:56:37 45 C* 17:57:07 thats 113 F 17:57:41 tabemann: I am sure that they are glad about 45°C in AU because then the spiders stay in the shadows and don't kill your whole family ;þ 17:58:14 no, your whole family just dies of heatstroke instead 17:58:22 Ok, I change my mind about the voc stuff. 17:58:26 wow, a whole 113? sheesh.. Visit MI in august; visit TX or AZ 3 seasons of the year 17:58:32 Inheriting the outside environment is the right way to go. 17:59:11 I was in Santiago, Chile in Chilean summer. So hot and they don't isolate their windows. 17:59:16 Well, parts of TX. 17:59:23 Inside was just as warm as outside, it was hell. 17:59:24 It never gets THAT hot in Houston. Too humid. 17:59:36 Austin - that's another story. 18:00:50 okay, gonna head home - bbl 18:02:45 It 81 F here, should get to around 90 by lunch 18:05:24 --- quit: tabemann (Ping timeout: 245 seconds) 18:08:59 --- join: proteusguy (~proteusgu@116.50.237.242) joined #forth 18:08:59 --- mode: ChanServ set +v proteusguy 18:25:36 Just happened upon an old book on UI design I forgot I had, "The Elements of Friendly Software Design" 18:26:23 It has a tangential connection to Forth, in one of the chapters the 18:26:55 author describes Zoomracks, which was a Forth-based product 18:27:16 that he designed 18:28:10 https://en.wikipedia.org/wiki/Zoomracks 18:30:35 IIRC Tom Zimmer was the programmer 18:35:03 http://www.drdobbs.com/the-real-deal/184410352 18:36:50 https://www.atarimagazines.com/startv2n3/hypercard.html 18:37:34 --- join: mark4 (~mark4@12.41.103.244) joined #forth 18:37:56 http://www.page6.org/archive/issue_23/page_20.htm 18:38:18 Anyway, that was my stroll down memory lane for today :) 18:49:35 --- quit: proteusguy (Ping timeout: 245 seconds) 18:59:25 Where'd everybody go? :) 19:03:30 * crc is lurking quietly in the background 19:03:48 spooky :) 19:04:18 0 shadow Outer Interpreter - Number Input - Preliminaries 19:04:19 1 19:04:19 2 rebase Convert an ASCII digit character of up to base 40 19:04:19 3 (i.e 0..9, a..~) to an integer. 19:04:19 4 19:04:43 2 : rebase ( c -- u ) 19:04:43 3 dup ascii 9 > ascii 0 ascii a 10 - \mux - ;inline 19:04:43 4 19:07:55 (assumes constant folding) 19:09:09 --- join: tabemann (~travisb@2600:1700:7990:24e0:a106:f1e:e4eb:7e2d) joined #forth 19:12:29 --- quit: spestov (Ping timeout: 245 seconds) 19:17:12 Someone mentioned number bases the other day. 19:18:23 --- join: gravicappa (~gravicapp@h109-187-233-79.dyn.bashtel.ru) joined #forth 19:29:42 --- join: proteusguy (~proteusgu@203.177.88.178) joined #forth 19:29:42 --- mode: ChanServ set +v proteusguy 19:30:19 opinion 19:30:31 should BASE be task-local? 19:31:37 yes 19:31:59 as much state as possible should be task-local, IMHO. 19:32:14 * tabemann is wondering what the best way to make task-local variables in an extensible fashion 19:32:44 * tabemann made attoforth have good support for task-locals, but that required lots of heap allocation and like 19:32:58 that's a good question in forth which doesn't encourage such things so easily. 19:33:19 OTOH hashforth has task-locals hardcoded into it 19:33:49 the problem is that it is hard to support adding new task-locals after the fact in a forthy way 19:34:44 attoforth got away with it by putting task-locals for each task in heap-allocated blocks of memory which were dynamically resized 19:34:49 one low granularity method is just to have the base forth system be global and then any task/process you kick off gets its own dictionary and everything becomes local to it. 19:34:56 Usually BASE is a user variable for user terminal tasks, for background tasks that don't have a user terminal it's not necessary. 19:36:01 Another option is to not have BASE at all 19:37:04 I'm using BASE for general number parsing and formatting, so just because a task isn't a terminal task doesn't mean that it doesn't need BASE 19:37:33 also, in hashforth any task really can commandeer standard input and standard output 19:39:31 You're assuming POSIX, there might be no such thing as standard input and output 19:40:20 well yes, on other systems someone might intercept the READ and WRITE services and do something else with them, like read from and write to a serial port 19:41:37 or they may not exist at all 19:41:54 could you create a variable that points to the task-local varaibles, and swap that variable on a task-switch? 19:42:36 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 19:42:51 dave0, that's definitely a design option, and a good one if the number of task-local variables is of any size 19:43:00 the problem is extensibility 19:43:03 Typically a multitasking Forth system can have two types of tasks, terminal tasks for interacting with a user or operator, and background tasks which are mainly for controlling stuff. The Task Control Block of the former takes more space has it has more user variables. 19:43:35 The TCB of a background task is kept to a minimum. 19:45:03 I currently have two user-accessible task-locals - BASE and HANDLER 19:45:17 HANDLER isn't user accessible, actually 19:45:33 well, the user can read it if they really want to, but they probably shouldn't 19:46:01 Forth Inc.'s Forth Application Techniques booklet has a pretty good chapter on Forth multitasking. 19:47:04 --- quit: spestov (Ping timeout: 245 seconds) 19:47:06 yes 19:47:15 I just thought of how to make user-defined task-locals 19:47:22 assign an index to each task 19:47:34 What do you mean by user-accessible? Are you hiding some of them? 19:47:37 and use that index into an array for each task-local 19:48:42 The important thing is not to have background tasks require as much overhead as foreground tasks. 19:49:08 rdrop-exit, I mean as opposed to things like waiting state informatiton that isn't really meant to be touched by the user (even though of course the user could access them directly if they really wanted to) 19:50:10 thanks for the explanation 19:50:44 currently I have little need to distinguish foreground and background tasks - they both have task-local BASE and HANDLER, both have waiting state info (used for waiting for IO and sleeping), and share the same dictionary and wordlists 19:50:55 and of course they all have their own stacks 19:52:09 and their own private task-local space (like HERE, but task-local) 19:55:19 That's what the TCB is, task-local stuff. 20:03:30 I thought of a way to have user-definable task local variables - have a fixed-sized task-local block associated with each TCB, and if that is used up, the last entry in that block is a pointer to the next block, and so forth 20:04:12 the idea of course being that by default the first block would be large enough for all conceivable uses, but it case it was not, additional blocks would be allocated 20:06:11 That would waster space, the size(s) should be specified when the task is defined. 20:06:40 * waste (not waster) 20:07:11 that would make it impossible to define arbitrary numbers of new task-local variables after the fact 20:08:13 and of course one could guess ahead of time as to how many task-local variables would be needed; the only difference is that if one guessed wrong, more space would be allocated 20:08:44 Usually there's no guessing involved 20:09:55 These are design-time/compile-time decisions 20:10:49 one would have to build into the image how many task-local variables one wanted 20:11:26 --- quit: nighty- (Remote host closed the connection) 20:11:32 For a background task, you specify the size of the stacks and user memory 20:12:48 when you define the task 20:13:29 These don't change at runtime 20:13:49 yes 20:13:54 ok 20:14:54 the thing is I envision something where someone can execute at runtime something like LOCAL-VARIABLE FOO, where FOO is a new task-local variable, and it is added to all existing tasks after the fact 20:15:54 Why add it to all tasks, only add it to the tasks that need it. 20:16:32 and normally not at runtime. 20:17:14 because making it selective would make the design more complex, by making it some kind of lookup table rather than just an index into an array 20:17:53 Systems that control things don't normally get new variables at runtime. 20:20:16 Their needs are designed into them at design time. 20:21:21 from that perspective, one would need to rebuild the image to add new task-local variables to things like the main task and the sleep task 20:22:12 (of course, currently rebuilding the image is necessary to change the memory space size or the return stack size) 20:22:28 (or the maximum number of words or wordlists allowed) 20:23:28 I'm not sure I understand all that you just said. As far as maximum number of 20:23:51 words and wordlists those limits are implicit not explicit. 20:25:10 You can have as many words as you want until you run out of dictionary space. 20:28:39 Here's the glossary entry of BACKGROUND from the F.A.T. booklet: 20:28:47 BACKGROUND 20:29:07 ( nu ns nr -- ) 20:30:49 Defined the background task -- with bytes of user area, bytees of data stack, and bytes of return stack -- and sets up its task control block based on these parameters. Use of returns the address of its TCB. 20:31:05 * Defines ... 20:33:28 The point of all that is so that the overhead can be finely controlled, just what you need, no unecessary overhead. 20:36:43 back 20:37:10 that's essentially what I have in my implementation 20:37:19 Cool 20:37:32 the only difference being that I don't define a name but rather I return a pointer to the TCB 20:37:48 which the user can bind to a name using CONSTANT or otherwise do as they see fit 20:39:36 It just lays down a definition like any other defining word. 20:42:26 about task-local variables one option would be to have a global variable like LOCAL-COUNT which is incremented each time a task-local variable is defined, and that when new tasks are created a space of this number of cells is alloted and set to zero, and the count is stored in the TCB itself (so that if one attempts to use a task-local variable not defined for a given task, it can fail cleanly) 20:50:13 The traditional name of the user pointer register is UP. USER variables just add a fixed offset to UP. 20:51:29 There's no need to store a count in the TCB. 21:00:39 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth 21:01:32 --- join: spestov (~spestov@cpe-67-245-201-127.nyc.res.rr.com) joined #forth 21:01:32 --- quit: spestov (Client Quit) 21:11:35 I'm slightly confused - do you mean the base of the user area, rather than the current user pointer? 21:14:54 The variable that tracks the number of bytes of user variables is usually named #USER. 21:16:27 When you define a user variable for a terminal task, you are adding to #USER. 21:16:56 is that task-local or not? 21:17:49 Normally it applies to all terminal tasks. 21:19:26 I assume this happens when the main task has not been created yet 21:19:42 and there are no tasks in existence 21:20:16 It doesn't matter. 21:21:25 but in this scheme of things, how do you define user variables after a task has already been created - unless that task is using none of its user space? 21:21:34 A USER variable just stores an offset at compile-time. 21:22:48 At runtime it adds that offset to the contents of a "register" to get produce the actual address. 21:23:53 is this "register" the base of the user area or the current HERE pointer? 21:24:24 The base of the user area of the current task 21:25:08 so let's say data has been added to the user area ot the current task 21:25:25 how do you add a user variable, because the space for it has already been used? 21:26:15 A USER variable is just a way to name an offset, and add it at runtime to a base register. That's all. 21:26:39 --- quit: proteusguy (Ping timeout: 245 seconds) 21:27:02 I'm saying practically speaking - sure, you can define a USER variable, but how do you actually make use of it given these circumstances 21:28:18 #USER is your "HERE" for all terminal tasks. 21:29:22 If all your terminal tasks have BASE, then the offset of BASE is presumably the same for all your terminal tasks. 21:29:35 --- join: proteusguy (~proteusgu@203.177.88.178) joined #forth 21:29:35 --- mode: ChanServ set +v proteusguy 21:30:37 my point is that you spoke as if you can define user variables after the fact for terminal tasks 21:30:54 and I was questioning the practical feasability of doing this 21:35:02 As long as I have spare bytes in a tasks user area, I can decide later what to call them. 21:35:40 If I don't have any spare bytes, then I'm screwed and will have to recompile. 21:35:56 okay, so we are allocating extra space ahead of time, and determining what it is later 21:36:19 You decide how much space to give a task when you define the task. 21:37:09 You can give it spare capacity if you choose. 21:39:03 I'm going from memory on all this, I use a different approach in my Forths. I'm sure there are other approaches out there. 21:42:25 If you had 10 user variables defined, you could still make a task with only the first 5 and it would still work as long as you don't need the other 5. 21:45:20 This is one way to do background tasks. 21:45:26 back 21:45:43 I have to walk the dogs, catch you all later. 21:45:51 see ya 21:45:59 :) 21:46:07 --- quit: rdrop-exit (Quit: Lost terminal) 21:51:38 --- join: yrm (~yrm@KD182251078191.au-net.ne.jp) joined #forth 21:55:58 --- quit: yrm (Ping timeout: 246 seconds) 22:00:50 --- join: yrm (~yrm@KD182251078191.au-net.ne.jp) joined #forth 22:02:12 --- quit: pierpal (Quit: Poof) 22:02:14 --- quit: yrm (Client Quit) 22:02:28 --- join: pierpal (~pierpal@host105-222-dynamic.3-87-r.retail.telecomitalia.it) joined #forth 22:13:51 --- join: nighty-- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth 22:15:04 --- join: yrm (~yrm@KD182251078191.au-net.ne.jp) joined #forth 22:15:14 --- quit: nighty-- (Remote host closed the connection) 22:29:03 --- quit: yrm (Quit: yrm) 22:40:01 --- quit: proteusguy (Ping timeout: 255 seconds) 22:47:28 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 22:50:09 --- quit: MrMobius (Ping timeout: 250 seconds) 22:50:09 --- nick: [1]MrMobius -> MrMobius 23:27:00 --- join: jedb_ (~jedb@176.113.74.187) joined #forth 23:38:42 --- join: djinni_ (~djinni@68.ip-149-56-14.net) joined #forth 23:40:58 --- quit: nighty- (Excess Flood) 23:40:59 --- quit: djinni (Quit: Leaving) 23:40:59 --- quit: jedb (Remote host closed the connection) 23:40:59 --- quit: reepca (Remote host closed the connection) 23:41:30 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth 23:48:13 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 23:59:59 --- log: ended forth/19.02.22