00:00:00 --- log: started forth/01.11.21 08:30:32 --- join: MrReach (~mrreach@209.181.43.190) joined #forth 08:30:51 --- mode: ChanServ set mode: +o MrReach 08:59:38 --- join: edrx (edrx@200.240.18.68) joined #forth 09:01:01 --- join: Speuler (speuler@birne.icafe.spacenet.de) joined #forth 09:01:06 --- mode: MrReach set mode: +oo edrx Speuler 09:01:06 g'day 09:01:10 hihi 09:01:17 how goes? 09:01:21 goes well 09:01:23 quite so 09:01:26 self ? 09:01:39 pretty good, gearing up for the holidays 09:01:48 skiing ? 09:01:57 outdooring ? 09:02:02 naw, eating, friends visiting, etc 09:02:16 ha! 09:02:21 eating is quite a good thing to do too 09:02:34 catching your own food ? 09:02:36 nope, I go indoors about November, and seldom come out until March or so 09:03:06 stocking fridge from store 09:03:16 no, not catching own food 09:03:25 not this year, anyway 09:03:48 how's your various Forth projects coming along? 09:04:25 i was wondering: there are vegetarians, also vegans. shouldn't there be a group of people who don't eat what has been alive, i.e. no plants too ? purely artificial nourishment 09:04:48 (not made from mineral oil neither) 09:04:49 I'm considering writing an auto-doc package for Win32Forth ... I notice that my sources are starting to get out of sync with my docs 09:04:54 rock food 09:05:02 words works 09:05:08 haha! 09:05:17 Speuler: I know people like that, but they don't form a movement 09:05:23 and i have put a cute udot in 09:05:33 or debugging of course 09:05:39 recursive, asm, 20 lines 09:05:41 not sure there is anough of them, yet, to warrant a new word 09:06:04 at least they don't eat anything that looks even remotely natural 09:06:06 silicans 09:06:27 what can one eat that was not once a plant or animal? 09:06:52 process it. carbon based something 09:07:02 I can think of things that don't SEEM to have once been living ... soy flour comes to mind 09:07:28 vegans refrain from drinking beer, becauseof the yeast 09:08:12 are you saying that your U. is a primitive? 09:08:17 yes. 09:08:22 actually asm coded 09:08:28 ok 09:08:41 but hilevel would be quite similar 09:08:58 respect base, of course 09:09:13 ans conform (>=36) 09:09:19 heh, I would not have picked that one to be primitive, with the availability of <# # #S and #> 09:09:27 don't have those 09:09:35 my u. works purely on stack 09:09:38 no buffer 09:09:42 * MrReach nods. 09:09:57 nice in early stage 09:10:03 ah! I've seen that before somewhere 09:10:17 recursive 09:10:23 heh, you have an STYPE ? 09:10:36 for "stack type" 09:10:45 nope 09:10:55 plain cell size untyped elements 09:11:20 but i'd like to consider stype 09:11:45 on a shadow stack 09:11:53 I've never puts string on the stack, so I've never had a need 09:11:56 to not mess up index into stack 09:12:14 uhm, we're talking different things 09:12:16 no 09:12:27 my u. emits in the unfolding recursive part 09:12:36 oh, ok 09:13:17 i thought you meant protocolling the type of stack elements on a 2nd stack, or an extension of the stack 09:13:29 no 09:13:47 my u. doen't call anythging else 09:13:51 I was thinking of character storage, because you end up with the least significant digits first 09:13:55 you could assemble it as stand-alone app 09:14:02 the stack 09:14:12 first char gets on stack first 09:14:17 (last char,that is) 09:14:24 yes, I realised that, later 09:14:28 and leftmost digit ends up on top 09:14:39 then the recursion unfolds, and emits all 09:14:51 isolate the least sig char, then recurse ... on return from recurse, print the char 09:14:59 yes 09:15:15 very clean demonstration of recursion 09:15:22 and useful too in this case 09:15:26 vs. storing chars by "... swap 1+" 09:15:42 no need to count 09:15:50 or to pick them later on 09:15:52 unless want to return on stack 09:16:05 do you intend to keep U. as a primitive? 09:16:27 no idea 09:16:34 it is small enough 09:16:45 and can be coded in hilevel too that way 09:16:47 heh, a nuisance to port, though 09:17:12 do you not like the <# ... #> methodology? 09:17:29 even the trailing space is emitted by the same emit which outputs digits 09:17:33 I kinda messes up tasking 09:17:44 doesn't conflict 09:18:08 I know it doesn't, was wondering why you chose not to use it for this part 09:18:12 i have implemented <# # #s #>type #> once before, purely using stack 09:18:23 <# and friends are VERY simple words 09:18:43 the #>type because it would save me from copying digits from stack to buffer, as expected by #> 09:19:19 but doing stack manipulation within <# #> doesn't work as expected 09:19:41 oh! hey! I implemented an SALLOCATE for win32Forth ... arbitrary sized memory frames on the return stack that are automatically cleaned up on exit from a word 09:19:44 but #> just copied stack to mem 09:20:00 * MrReach nods. 09:20:04 thats nifty 09:20:15 good for locals 09:20:32 i think i like that 09:20:39 I was starting to have concerns about memory fragmentation 09:20:54 i did a defragmenter before 09:21:02 locals work as expected, alongside the stack frames 09:21:02 for wy windowing system 09:21:15 (text mode windows) 09:21:28 (canbe used in graphics mode by emulating text mode) 09:21:52 nice to overlay graphics with text menus 09:22:07 * MrReach nods 09:22:16 used it in orbic 09:22:23 sirius/victor program 09:22:29 many years ago 09:22:46 reputetly the first program to make use of sirius graphics 09:23:00 (actually wrote it as demo for a number cruncher card) 09:23:11 I discovered that my progs tend to use lots and lots of rather small memory bocks (<20 bytes) for short periods of time 09:23:39 but larger than cells, so stack is awkward 09:24:07 SALLOCATE doesn't require the overhead of ALLOCATE 09:24:34 my defragmenter orgranizes data so that frequently accessed items end up at low addresses 09:24:35 also, on x86 arch, ALLOCATE tends to commit a new 4K mem page 09:24:55 that is, memory holes tend to gather at the end of mem 09:25:03 * MrReach nods. 09:25:16 but how do you dynamically move memory regions? 09:25:30 i use a pointer table to memory addresses 09:25:39 or do you allocate with "best fit"? 09:25:45 and refer to mem by index into pointer table 09:25:57 a table, called MEM 09:26:05 no 09:26:10 oh, so @ has to be guarded in the application? 09:26:24 i use what is available at end, and when it runs short of mem, i compact 09:26:58 ok, that's like the old M$ string block 09:27:15 requires discipline: don't keep memory pointer. instead, use MEM to refer to mem 09:27:24 * MrReach nods. 09:27:51 simplifies matters a lot, from viewpoint of memory management implementation 09:27:57 interested in contributing some thought to an auto-doc system? 09:28:16 yes, it does ... unless you have access to system code 09:28:18 if you think i could be of some help 09:28:50 you must have given some thought to it before now ... what have you come up with? 09:29:19 put a leading prefix left of comments 09:29:27 example? 09:29:50 : foo \ @@ this comment i want to export 09:29:54 ; 09:30:07 ok 09:30:31 I was thinking of something a bit larger, at the paragraph level 09:30:33 one could reimplement ( and \ etc too 09:31:18 most important (it seems to me) are glossary entries and explanatory introductions 09:31:23 but i'd prefer to have some control on what comments to export 09:31:56 of course 09:32:15 important is that source location can be located 09:32:20 from comment 09:32:28 also, the docs shouldn't bork a standard system, so *MUST* be embedded into \ and ( somehow 09:32:29 from exported comment 09:32:51 oh? an example?? 09:32:58 prefix could be immediate 09:33:39 i'd like to be able to browse the doc, and jump to source the comment is referring to 09:33:47 how would one locate source location from within the docs? 09:34:03 put index into file list, and line numbers into doc 09:34:29 heh, 09:34:34 have the editor, custom build, or macro support, use this info to open file and position cursor 09:35:05 and snchronized browsing: 09:35:27 walk down the doc, and the source window updates on the fly 09:35:32 ok 09:35:42 that is far more complex than I had been thinking 09:35:55 it doesn't appear to 09:36:02 or do i overlook something ? 09:36:32 I was thinking of auto-producing either text, html, tex, ps, or pdf files from the source 09:36:37 source view is very similar 09:36:42 same information 09:36:53 but in headers, not in doc file 09:37:01 linking BACK to the source from those would be difficult 09:37:45 although a line# reference would not be too hard 09:37:51 have an ascii master, convert it to other formats, loosing the source link option 09:38:14 the browser has to cooperate 09:38:19 right 09:38:22 that's easier with an ascii browser 09:38:24 most don't 09:38:42 actually, that wouldn't be ascii, either, but another markup type 09:38:57 i don't want to rewrite a pdf viewer, only to be able to jump to source from the pdf file 09:39:30 ok, as for source syntax, I had been thinking ... 09:39:30 true, but the markup part could be well concentrated, or hidden, so it appears as ascii 09:39:49 top or bottom x lines, commented out 09:39:51 that \ would be overloaded, but it would act exactly as normal, until ... 09:40:09 (commented out that the editor/viewer ignores those lines) 09:40:31 it is the first character on the line, followed by the token "adoc " 09:40:41 i'd like to write a folding editor 09:40:48 again, similar principle 09:40:48 * MrReach nods 09:41:11 consider combining autodoc view and program editor 09:41:29 also, once a doc section is started as above, it automatically continues onto lines where the first chars are "\ " 09:41:38 there are far too few folding editors around 09:41:49 i don't know an nice one on pc 09:42:04 what is a nice one on Unix? 09:42:15 if you say EMACS I'm gonna kick you 09:42:25 i had a nice one on atari 09:42:30 heh 09:42:52 never seen anything equivalent since 09:43:15 folder info should be put into another file 09:43:25 pairing ascii and folder info 09:43:36 I was thinking that any number of "sections" could be defined in source ... the glossary being the default 09:43:38 foilder info not embedded into ascii file 09:43:53 more portable that way 09:44:13 no complaints by non-folder aware programs if they have to process such a file 09:44:15 \ adoc sec Introduction 09:44:19 \ some text 09:44:23 \ more text 09:44:25 \ 09:44:32 \ new paragraph 09:44:56 [end example] 09:44:59 \ @@Header this tells you how to feed a duck 09:45:16 \ @@Body take some bread 09:46:02 \crumble it 09:46:11 \ toss it 09:46:18 \ watch duck eat 09:46:35 \@@End 09:46:47 @@Section 09:46:52 @@Font 09:47:08 @@SeeAlso 09:47:18 --- quit: edrx ("[x]chat") 09:48:00 @@Keywords 09:48:32 it is much better to avoid rendering commands 09:48:48 i.e. @@Font 09:48:55 we got "wordlist" to help us 09:49:35 also, @@End is redundant ... can parse until find a line that doesn't begin with "\ " 09:49:51 but the comment words need to be smarter, to take advantage of that 09:50:17 @@End could be overloaded 09:50:28 to several ending purposes 09:50:32 also ... each section is accumulated into a memory buffer until file is finished ... so any section can be continued later 09:50:55 i thought of @@Section as some output control word 09:51:02 tell the comment where to go to 09:51:10 to what file, or index, or whatever 09:51:15 yes, which leads to section order command ... 09:51:44 \ adoc secorder Intro Usage Caveats Glossary 09:52:02 @@Section primitive 09:52:12 @@Section control-flow 09:52:14 etc 09:52:38 you're saying that sections should be output in the order they are defined? 09:52:49 and then initially defined near the beginning of the file? 09:53:07 rephrase please 09:53:16 ok, hmm 09:53:31 that we define mutiple sections is a given 09:54:01 that a given section might be split up into several parts within the source file is a valuable feature 09:54:34 then, it is a matter of specifying which order the sections are placed into the final document 09:54:46 maybe my @@Section would be clearer if i call it @@Index 09:54:57 I had considered a seperate secorder command 09:55:35 but you gave me the idea that it would be better if secs were output in the same order they were created in 09:55:51 in which case, they should all be defined near beg of source file 09:56:16 there are two "orders": one, as the sections are written, and one, as you reference them 09:56:30 those may differ 09:56:37 correct, source order and target order 09:56:57 so, sections could be put in any order which is convenient 09:57:03 one behind the other 09:57:05 fine 09:57:25 with the index, you can change the order as sections are presented to you 09:57:31 also, sections in the target should have multi-word names 09:57:55 although they *may* require single word identifiers 09:58:02 quotes ? 09:58:14 brackets ? 09:58:32 non-space delimiters ? 09:58:35 \ adoc sec The text that appears in TOC 09:58:50 how does that look? 10:00:02 what id would you use to put the reference into the toc ? 10:00:19 just a short abbreviation 10:00:26 like TOC ? 10:00:46 for example ... "Memory Usage" section might have id "mem" 10:00:56 yes, like toc 10:00:56 makes sense 10:01:20 then, at any time later in the file, the section can be continued with ... 10:01:30 \ adoc sec 10:01:33 \ more text 10:01:39 \ to add to section 10:01:42 [end] 10:02:18 if that section command had something after the , then the original text would be discarded and replaced 10:02:36 all lines of one doc item should be able to recognize the belonging-togetherness 10:02:48 yes 10:03:27 by creating unique tokens per doc item 10:03:30 I was thinking that any adoc section can be continued by putting a \ at the beginning of next line 10:03:38 and tagging all lines with it 10:03:51 I wouldn't tag ALL lines 10:04:16 maybe a link to the top item, and a linked list through the items, starting at top 10:04:30 say again? 10:04:45 line three of one doc items points to line 1 of doc item 10:04:48 so does line 5 10:04:51 and line 10 10:05:06 oh, ok 10:05:07 line one pointsto line 2, 2 to 3 and so on 10:05:15 as for implementation ... 10:05:29 I'd use a linked list of nodes, each node a section 10:06:00 each node has pointers to id text, TOC text, text of verbiage 10:06:07 makes it more hypertext-capable 10:06:13 hyperlink 10:06:37 verbiage continually gets appended to 10:06:46 TOC text always gets overwritten 10:06:51 id is unchangable 10:07:11 is there a need for subsecs? 10:07:22 probably 10:07:23 I'm thinking not 10:07:49 because that opens a pandora's box of stuff like tables 10:07:58 linked list can easily refer to another list 10:08:06 a sub-list 10:08:12 yes, from list to tree 10:08:14 which in turn ... 10:08:30 good 10:08:37 fun 10:08:38 how would one specify a subsection? 10:08:59 @@SECTIONLEVEL n 10:09:06 @@SECTION foo 10:09:11 \ adoc subsec text for TOC 10:09:13 @@SECTION bar 10:09:21 or 10:09:34 I like mine better @:^> 10:10:19 do you disagree with the "adoc" prefix? 10:10:41 @@parentsection subsection new subsectionname 10:10:50 :) 10:11:15 @@subsectionname subsection new subsubsection 10:11:19 @@subsec par-id id Descriptive Text 10:11:40 we're drifting into an oo autodoc 10:11:47 this would rewrite the descriptive text ... 10:11:56 @@sec id new text 10:12:04 but wouldn't change the parent section 10:12:11 blah 10:12:54 there will be champions league on tv tonight 10:12:57 do you disagree with the "adoc" prefix? 10:13:35 i don't disagree but would like something like @@ better 10:13:57 but we can alias that easily i guess 10:14:05 to cause discrimination? 10:14:25 it jumps right into your eye 10:14:37 whereagainst adoc doesn't 10:14:51 \ @@DOC@@ sec descriptive text 10:15:04 \ @@DOC sec descriptive text 10:15:39 \ >>>> sec descriptive text 10:15:50 \ * sec descriptive text 10:15:59 I like the single star 10:16:54 could be preceded by "\ *****************" ... which would not be recognised as adoc command 10:19:42 \ ***************** 10:20:01 \ * sec intro Intruction to Blah 10:20:24 \ * This package provides functionality 10:20:36 \ * The functionality is useful. 10:20:41 \ * 10:20:55 \ * This is a second paragraph describing functionality 10:21:03 What do you think? 10:27:00 sorry, was distracted 10:27:06 np 10:27:14 @@DOC looks good 10:28:18 yoiu don't like the single star? 10:28:20 i move to another place. soccer starts in a minute 10:28:34 I should be going 10:28:38 it is juventus turin against leverkusen 10:28:45 european cup 10:28:50 I've got to finish the cooling system in wife's pickup 10:28:54 italy against germany 10:29:04 and fill propane tanks in 5th wheel 10:29:13 I'll return later 10:29:20 ok, be well 10:29:21 as i'll be around for a while 10:29:27 god luck 10:29:29 good 10:29:32 heh 10:29:36 --- nick: MrReach -> MrGone 10:29:40 don't explode 10:29:53 heh, messy 10:31:34 --- quit: Speuler ("Leaving") 12:59:49 --- mode: ChanServ set mode: -o MrGone 15:12:25 --- join: fanta7 (icafe@banane.icafe.spacenet.de) joined #forth 15:12:32 --- part: fanta7 left #forth 15:26:09 --- join: speuler (l@passionsfrucht.icafe.spacenet.de) joined #forth 15:26:19 --- part: speuler left #forth 17:32:48 --- join: qless (~qless@clgr000977.hs.telusplanet.net) joined #forth 17:37:17 --- quit: qless ("changing dimensions") 18:40:48 --- join: tcn (tcn@65.170.209.40) joined #forth 18:40:59 --- part: tcn left #forth 20:52:54 --- join: futhin (thin@h24-66-209-114.cg.shawcable.net) joined #forth 20:52:59 hi 21:12:15 mrreach 21:12:17 you there? 21:15:39 oh well, gonna go to bed 21:15:43 --- quit: futhin ("bed") 22:23:24 --- quit: MrGone (sagan.openprojects.net irc.openprojects.net) 22:27:57 --- join: MrGone (~mrreach@209.181.43.190) joined #forth 22:36:48 --- quit: MrGone (sagan.openprojects.net irc.openprojects.net) 22:36:55 --- log: started forth/01.11.21 22:36:55 --- join: clog (nef@bespin.org) joined #forth 22:36:55 --- mode: sagan.openprojects.net set mode: +n 22:36:55 --- names: list (clog) 22:38:51 --- mode: ChanServ set mode: +nt 22:38:58 --- join: MrReach (~mrreach@209.181.43.190) joined #forth 22:40:44 --- quit: MrReach (sagan.openprojects.net irc.openprojects.net) 22:41:53 --- join: MrReach (~mrreach@209.181.43.190) joined #forth 23:59:59 --- log: ended forth/01.11.21