10:13:10
##forth
<user51>
another forth attempt -- this time i'm shaking things up and using lots of globals, gotos, and some hacks just because. so far, it's surprisingly not too bad.
11:41:31
##forth
<pgimeno>
not bad at all, although the Extract loop could have been written without the goto
11:42:21
##forth
<user51>
pgimeno: the extract section will probably be moved to a function, as some words do look ahead like :, SEE, etc.
11:43:53
##forth
<pgimeno>
I'm all for gotos where they make the code clearer and less bloated, but it's rare that these cases involve a backward jump
11:45:25
##forth
<pgimeno>
as for the globals, you could use the Global Political Correctness transformation trick: switch to C++ and make the globals be members of a class instead ^.^
11:46:05
##forth
<pgimeno>
that usually silences complainers
11:46:27
##forth
<user51>
not really concerned about the code at this point -- i plan to just write stuff and see what can be improved. currently i'm happy with how easy the code is to navigate and change.
11:46:46
##forth
<pgimeno>
yeah, I was surprised by its simplicity
11:46:48
##forth
<pgimeno>
very nice
11:47:08
##forth
<pgimeno>
and it made me wonder, is it unusual for Forth to use hash tables for word lookup?
11:47:47
##forth
<user51>
hash tables can work but they still need to be changed, because you can redefine words. e.g : x ; : x x ;
11:49:33
##forth
<pgimeno>
yeah absolutely, I'm thinking dynamic hashes like python dictionaries, c++ unordered_maps, lua tables etc.
11:50:53
##forth
<pgimeno>
it's just that wherever I see a sequential search loop I tend to cringe
11:51:12
##forth
<GeDaMo>
Traditionally, Forth uses a linked list for the dictionary
11:57:43
##forth
<pgimeno>
yes, a tradition that arose from the lack of resources of the computes where it originated - dynamic hash tables waste memory (and probably weren't very well known back then, if at all)
11:57:51
##forth
<pgimeno>
computers*
12:02:03
##forth
<GeDaMo>
Partly, it's because word definitions are ordered
12:02:30
##forth
<GeDaMo>
ColorForth uses an array of "hashed" names but searches it linearly
12:06:43
##forth
<GeDaMo>
Of course, they don't have to be ordered, it's just tradition again :P
12:16:20
##forth
<pgimeno>
I suppose words are rarely looked up in performance-critical sections anyway
13:31:34
##forth
<veltas>
pgimeno: C++ core guidelines calls out that 'one simple trick doctors hate', by outlawing singletons that are there to achieve that specifically
13:32:07
##forth
<veltas>
Globals aren't that optimised in modern relocatable ABIs anyway, so quite often it's probably faster and less code to not use globals
18:02:03
##forth
<xentrac>
instruction sets are another culprit
18:02:47
##forth
<xentrac>
like, on a PDP-10, the right half of your 36-bit instruction word could contain an 18-bit address that pointed to any global variable in your program
18:03:58
##forth
<xentrac>
but on RISC machines, data addresses are 32- or 64-bit, and instruction words are 32-bit or even 16-bit, so there isn't space for a full-sized global address as an immediate field
18:05:15
##forth
<xentrac>
however, you can index off a base register with a 16-bit or (on RISC-V) 12-bit offset; the time for the extra addition to compute the absolute address is hidden by the instruction pipeline
18:07:19
##forth
<user51>
crc: channel logs are missing for today and yesterday
18:08:13
##forth
<xentrac>
pgimeno: Forth, Inc.'s Forth systems used hash tables for word lookup since the 01970s, but with only 8 hash buckets, which only "wastes" 16 bytes of memory, except that it also required an additional pointer field in each word. GForth uses a hash table, I think a largish one. But most other Forths do just use sequential search, which makes forget and/or marker easy to implement
18:08:47
##forth
<xentrac>
dynamically resized hash tables have been a thing since the 60s, but their advantages are indeed more compelling on computers with more memory
18:14:30
##forth
<crc>
user51: fixed, thanks for letting me know!
18:15:37
##forth
<user51>
crc: thanks for hosting logs :)
18:24:45
##forth
<xentrac>
yes, thank you!
19:33:10
##forth
<pgimeno>
veltas: Not singletons, mere classes you happen to instantiate once because you don't need more than that. Like I suppose happens with Java's "everything's a class" philosophy. You move all your globals to a class, and then you can boast that your code is reusable ^.^
19:35:34
##forth
<pgimeno>
xentrac: that's interesting to know, and yes I see how forget/marker are easier to implement without them, as Forth design assumes a sequential dictionary in these regards.
19:38:45
##forth
<xentrac>
pgimeno: it's not that big a difference though
19:40:25
##forth
<user51>
thinking about that, i've imagined a.. discrete? forth occasionally. as in, compared to dumping everything in the dictionary space, everything is on it's "own". don't really know.
19:40:32
##forth
<xentrac>
Firefox amusingly displays the ^B as [00 02] in a box
19:40:53
##forth
<user51>
crc: none of the utf files are found on my end,
19:41:25
##forth
<veltas>
pgimeno: That's what they called them, singletons. I agree though, they're not talking about singletons, just globals in a class disguise
19:44:05
##forth
<veltas>
I hate all this pattern nonsense anyway
19:44:21
##forth
<crc>
user51: can you check now?
19:45:41
##forth
<pgimeno>
xentrac: yeah, I imagine it isn't, it's very uncommon to look up words apart from loading and typing, where lookup time is barely critical
19:46:08
##forth
<pgimeno>
veltas: anyway it was a tongue-in-cheek comment :)
19:49:55
##forth
<veltas>
My tongue was firmly planted in its normal location when I said that patterns are nonsense
19:50:51
##forth
<veltas>
Also Herb Sutter loves the word 'crisp' too much
19:50:51
##forth
<user51>
crc: yeah, they work now
19:51:06
##forth
<xentrac>
indexing off the this pointer is generally the same as indexing off any other register on a RISC machine
19:51:15
##forth
<crc>
good; hopefully that fixes everything
19:51:31
##forth
<xentrac>
crc: thanks!
19:52:19
##forth
<xentrac>
pgimeno: compiling Forth was usually fast enough that people didn't bother to store compiled bytecode; they just recompiled everything at boot time. the ACE is really unusual there
19:52:55
##forth
<xentrac>
even in the 70s
19:53:27
##forth
<veltas>
Like the PDP-11 fig forth
19:53:51
##forth
<user51>
crc: speaking of logs, is there a way to download all of them at once?
19:53:52
##forth
<veltas>
Unusual for Forths but really normal for boot ROMs
19:54:21
##forth
<user51>
crc: wouldn't be hard to do a simple wget for it, but i dunno about that kinda netiquette
19:58:20
##forth
<crc>
user51: it's not linked at the top level, but forth.chat/all.tar.gz is updated every 30-60 minutes
19:59:04
##forth
<user51>
speaking of compiling, one thing that's been in my head for a while is an evolving forth, that might border on biology or at least something close to computer virus. i'm feeling like i'm talking nonsense, tho.
19:59:06
##forth
<veltas>
You'll have to spare another block though lol
19:59:34
##forth
<crc>
veltas: I'll probably do that sometime this week
20:00:40
##forth
<xentrac>
user51: sounds pretty normal to me
20:01:31
##forth
<xentrac>
user51: usually people try to evolve their computer systems by recompiling them from modified source code, which serves as its DNA. Moore tried for a while to get by without source code but he eventually gave it up
20:02:13
##forth
<xentrac>
he could still keep his machine code factored into tiny subroutines, but you lose compile-time macros that way (immediate words)
20:03:15
##forth
<user51>
i remember reading about tht, but i'm not sure what 'get by without source code' actually means.
20:03:15
##forth
<veltas>
That's a very pertinent view of Forth
20:03:35
##forth
<veltas>
Writing out machine code with some comments probably
20:04:11
##forth
<xentrac>
oh, well, you just generate machine code as you type in Forth, and then keep the machine code and not what you typed in
20:04:32
##forth
<xentrac>
presumably there was a symbol table as well as the executable machine code
20:04:46
##forth
<xentrac>
and then if you wanted to edit a definition you would decompile it with the symbol table
20:04:56
##forth
<user51>
that would still be tied to a specific instruction set, no?
20:05:04
##forth
<xentrac>
I don't really know the details of his sourceless-programming experiment
20:05:08
##forth
<xentrac>
yes
20:05:42
##forth
<veltas>
Linus Torvalds used to write machine code by hand
20:05:53
##forth
<veltas>
I think a lot of people did in the 80's, without an assembler
20:05:57
##forth
<veltas>
And a reference for their arch
20:05:59
##forth
<xentrac>
we've all done it from time to time
20:06:48
##forth
<user51>
i was thinking that such a system could evolve from one instruction set to another, but it's probably not very simple
20:06:52
##forth
<xentrac>
PC Magazine IIRC published TSRs as hexadecimal you could type into DEBUG.COM
20:06:59
##forth
<xentrac>
not very big TSRs, dozens of bytes at most
20:07:22
##forth
<xentrac>
one I remember would turn off Caps Lock whenever you pressed Shift; I liked that one
20:08:58
##forth
<xentrac>
my friend Dave wrote an octal keyboard loader in machine code that was entirely printable ASCII
20:09:15
##forth
<xentrac>
so that you could bootstrap from ECHO instead of bootstrapping from COPY CON
20:09:19
##forth
* crc used to use inline machine code in retroforth definitions, back when it was written for x86 architecture
20:09:51
##forth
<nmz->
I don't write a lot of forth code, but I thought factoring was a key part of it, I'm seeing a lot of forth code in rosettacode that is just C code translated to forth (big hulking functions, no idea of what the stack is even doing)
20:10:51
##forth
<user51>
nmz-: give us some links, i'll give my opinions
20:10:51
##forth
<xentrac>
but of course both the PC Magazine columnists and Dave had access to assemblers
20:11:19
##forth
<KipIngram>
nmz - I see that all the time too and roll my eyes. I really try to embrace the factoring thing - most of my Forth definitions wind up 40-50 characters long. That may not be as short as you think, because I highly favor very short names, like to use single character symbols, and so on.
20:11:28
##forth
<KipIngram>
Maybe 7-9 word definitions?
20:12:15
##forth
<KipIngram>
The last week or week and a half or so I've been back on the Forth processor in an FPGA thing, and because of my style I'm really bending over backward to minimize call/return overhead.
20:13:10
##forth
<KipIngram>
My design makes the pending code stream very visible, so I'm trying to do some "smart as possible" pre-fetching.
20:15:41
##forth
<KipIngram>
At any rate, I have exactly the same feeling you had about a lot of Forth code we run across. Although, I guess it's not surprising when someone who's experienced in C first starts learning Forth. I know it took me a while to start producing those nice tight definitions.
20:15:59
##forth
<KipIngram>
Maybe it's something you just grow into.
20:19:30
##forth
<crc>
nmz-: as a data point, due to programming style differences as part of my system, my words tend to be longer than those from someone like KipIngram, but I factor frequently, and don't mind having a bunch of smaller definitions if it makes the definitions easier to read.
20:22:44
##forth
<crc>
in konilo, I have a lot of definitions under 20 words, and many could be made much shorter if I moved code from quotations into separate words.
20:23:31
##forth
<nmz->
but I see that there's some good ones here as well
20:23:37
##forth
<nmz->
I retract my statement
20:23:44
##forth
<nmz->
looking around, most of the code here sucks
20:24:28
##forth
<crc>
my lines are on the longer side though, since I have fairly verbose word names. averaging 8 characters with namespace, 5 w/o, and longest at 24.
20:25:06
##forth
<nmz->
I've seen retro code crc, you're a sane person :)
20:25:45
##forth
<crc>
nmz-: in my experience a lot of published forth code is terribly long & poorly formatted :(
20:26:07
##forth
<nmz->
sad
20:26:20
##forth
<nmz->
its literally the first section of starting forth
20:28:04
##forth
<nmz->
I'm a big believer in small functions and lots of comments. Hell I don't even write code nowadays, I start a design document and write pseudocode and this or that, then I implement it in a real language
20:28:09
##forth
<user51>
nmz-: well, i'd first try factoring the string one.
20:28:27
##forth
* nmz- nods
20:28:30
##forth
<nmz->
its really terrible
20:28:59
##forth
* nmz- goes to cook
20:30:53
##forth
<KipIngram>
I fail pretty badly on commenting. As in, most of the time I don't do it. I've tried, but I always wind up feeling like it's ugly. What I'm really hoping to do someday is have an editing environment that lets me toggle inline comments on and off, and also lets me link to comments and documentation stored remotely. Because I actually like writing documentary stuff. It's just the appearance it
20:30:53
##forth
<KipIngram>
lends my code that puts me off.
20:31:44
##forth
<KipIngram>
Yes. I'm hoping to be able to structure all kind of wiki style, so each level of link takes me steadily from comments to design documentation.
20:32:00
##forth
<KipIngram>
I think I see a good way to do that with a b* tree.
20:32:24
##forth
<KipIngram>
It will just need a fairly smart editor.
20:33:01
##forth
<KipIngram>
At the moment though this FPGA stuff has my attention.
20:33:47
##forth
<nmz->
hmm well at least its legible
20:34:23
##forth
<nmz->
user51: you can make an account and change the code, its mediawiki
20:35:03
##forth
<crc>
user51: that doesn't match the requirements of the rosetta code challenge though
20:35:49
##forth
<user51>
crc: tell that to chuck :P
20:36:10
##forth
<user51>
crc: i'll adjust the code, gimme a sec
20:36:50
##forth
<crc>
user51: I'd probably end up writing a set of functions for each part, and then use them for the final word
20:37:34
##forth
<user51>
crc: can i get a rough idea how it'll look like?
20:42:30
##forth
<ryoshu>
is there a regression test for forth to check whether an implementation is ANSI compliant?
20:44:45
##forth
<xentrac>
not ANSI, but I think there are a lot of tests on forth-standard.org
20:45:07
##forth
<xentrac>
not sure if they're conveniently packaged into a test suite you can just run, but I think that's the idea
21:07:43
##forth
<ryoshu>
John Hayes's ANS compiler validation program (27 Nov 95 version) (two files), tester.fr V1.1 and core.fr V1.2
21:07:46
##forth
<ryoshu>
this one?
21:08:08
##forth
<crc>
yes
21:08:20
##forth
<ryoshu>
ok, thank you!
21:09:00
##forth
<ryoshu>
is pforth generally considered to be compliant?
21:11:01
##forth
<crc>
no
21:11:08
##forth
<ryoshu>
ouch
21:11:08
##forth
<crc>
"PForth is based on ANSI-Forth but is not 100% compatible."
21:11:38
##forth
<ryoshu>
I saw this, I just hope it is still Forth.
21:12:22
##forth
<xentrac>
lots of things that aren't anywhere close to ANSI Forth are still Forth!
21:12:41
##forth
<crc>
forth encompasses a lot; and most systems don't fully comply with ANSI or ISO
21:13:16
##forth
<xentrac>
lots don't even try
21:14:34
##forth
<GeDaMo>
"It's more a set o' guidelines than actual rules" :P
21:15:29
##forth
<GreaseMonkey>
pforth is somewhat decent
21:15:48
##forth
<GreaseMonkey>
it's the one i tend to use anyway
21:17:03
##forth
<GreaseMonkey>
just a caveat, the memory pool you get to play with is quite small
21:17:25
##forth
<ryoshu>
that malloc() replacement?
21:17:53
##forth
<GreaseMonkey>
it's forth, it's less malloc() and more sbrk()
21:17:59
##forth
<user51>
ugly code, kinda pretty output
21:18:25
##forth
<GreaseMonkey>
the actual implementation at least *can* malloc() its memory pool(s), but it's a static allocation
21:18:31
##forth
<GreaseMonkey>
erm, static size
21:19:24
##forth
<GreaseMonkey>
huh, i didn't realise "value" was a word
21:19:35
##forth
<GreaseMonkey>
i tend to use "variable" and then explicitly use "@" and "!"
21:20:58
##forth
<GreaseMonkey>
i'm still fairly new to forth though, but i did get through maybe a bit more than half of advent of code last year using pforth
21:21:49
##forth
<xentrac>
I like value better than variable mostly
21:22:27
##forth
<xentrac>
the standard messed up the definition of to though
21:46:18
##forth
<veltas>
Hey look, "C-style Forth" is better than no Forth
21:46:29
##forth
<veltas>
I don't judge
21:47:11
##forth
<veltas>
I wrote C-style Forth initially and just stopped doing this as I read and worked with more old Forth
21:48:10
##forth
<veltas>
GreaseMonkey: I like variable/@/!
21:49:20
##forth
<veltas>
Also I don't like complicated stack usage, if I can't simplify the stack usage I just break out variables
21:49:34
##forth
<GreaseMonkey>
yeah, once you get used to variables it becomes a lot nicer
21:49:36
##forth
<veltas>
I'm not against using return stack when it is easy to keep track of
21:50:00
##forth
<veltas>
I want my code to be readable and understandable by dumb people like me
21:50:51
##forth
<GreaseMonkey>
my main use of the return stack tends to be potentially implicitly as per do/loop(/exit)
21:51:36
##forth
<xentrac>
I commonly find it useful for a "local variable"
21:51:53
##forth
<xentrac>
>r stuff stuff r@ stuff stuff r@ stuf stuff r> stuff stuff ;
21:52:22
##forth
<xentrac>
less useful when do loop comes into play obviously :)
21:53:22
##forth
<veltas>
I just rewrite without DO LOOP if I want return stack
21:53:30
##forth
<veltas>
Or use J
21:54:00
##forth
<xentrac>
how many return stack items does J skip?
21:54:07
##forth
<veltas>
Depends
21:54:12
##forth
<xentrac>
:)
21:55:44
##forth
<veltas>
!gforth : TEST 123 >R 5 0 DO J . LOOP R> DROP ; TEST
21:55:45
##forth
<gforth_eval_bot>
123 123 123 123 123
21:56:10
##forth
<veltas>
I mean regardless of how many it skips, J should always be the top of return stack before loop is entered
21:56:18
##forth
<veltas>
Logically
21:56:32
##forth
<veltas>
I don't know if the standard guarantees it, but I'd consider it a bug if it wasn't true
21:56:34
##forth
<GreaseMonkey>
"Depends" is correct, pforth gives me 5 0s
21:56:48
##forth
<GreaseMonkey>
...although i have no idea why
21:57:11
##forth
<GreaseMonkey>
maybe I and J are internal variables in pforth
21:58:01
##forth
<veltas>
Well if the counter isn't top, i.e. if I isn't R@ , then it won't work
21:58:02
##forth
<xentrac>
no, they're the loop counters
21:58:14
##forth
<xentrac>
not internal variables
21:58:24
##forth
<xentrac>
you could try this:
21:58:56
##forth
<xentrac>
!gforth : test 111 222 333 444 555 >r >r >r >r >r do j . loop rdrop rdrop rdrop rdrop rdrop ; test
21:59:17
##forth
<xentrac>
except correctly:
21:59:22
##forth
<xentrac>
!gforth : test 111 222 333 444 555 >r >r >r >r >r 5 0 do j . loop rdrop rdrop rdrop rdrop rdrop ; test
21:59:23
##forth
<gforth_eval_bot>
111 111 111 111 111
21:59:46
##forth
<xentrac>
I guess that's not the ideal test vector
21:59:51
##forth
<veltas>
Not sure what you're trying to prove
22:00:03
##forth
<xentrac>
just suggesting how GreaseMonkey could test pForth
22:00:20
##forth
<xentrac>
F83 implements i as the *difference* of the top two elements on the return stack
22:00:50
##forth
<xentrac>
so that it can implement loop termination by testing the overflow flag (or carry flag, I forget)
22:01:04
##forth
<GreaseMonkey>
222 222 222 222 222
22:01:29
##forth
<veltas>
Try J'
22:01:56
##forth
<GreaseMonkey>
j' is unrecognised
22:02:17
##forth
<veltas>
I guess just put something on top
22:02:44
##forth
<veltas>
Or DUP 2>R
22:02:57
##forth
<veltas>
And that will work on gforth and pforth then
22:03:10
##forth
<GreaseMonkey>
fforth also seems to emit 222 x5
22:03:11
##forth
<veltas>
Because that's what we want, portable return stack hackery :)
22:03:23
##forth
<GreaseMonkey>
oh yeah dup 2>r would work lol
22:03:59
##forth
<veltas>
!gforth : TEST 123 2DUP 2>R 5 0 DO J . LOOP 2R> 2DROP ; TEST
22:04:17
##forth
<veltas>
!gforth : TEST 123 DUP 2>R 5 0 DO J . LOOP 2R> 2DROP ; TEST
22:04:17
##forth
<gforth_eval_bot>
123 123 123 123 123
22:04:43
##forth
<GreaseMonkey>
works perfectly in pforth
22:04:50
##forth
<veltas>
solvd
22:05:53
##forth
<GreaseMonkey>
fforth lacks 2>R and 2R> but also fforth is quite incomplete... and the solution is fairly easy, >R >R and R> R>
22:06:36
##forth
<GreaseMonkey>
...or of course one could implement 2>R and 2R>
22:13:01
##forth
<xentrac>
haha, one could
22:13:13
##forth
<xentrac>
I suggest you try it; it's a highly educational experience!
22:13:49
##forth
<GreaseMonkey>
it's the sort of thing that would show up as an exercise in a Forth 101 cours
22:13:50
##forth
<GreaseMonkey>
e
22:14:08
##forth
<GreaseMonkey>
i'm not sure which of the two is the one that needs the SWAP
22:17:01
##forth
<veltas>
2>R is SWAP >R >R
22:17:09
##forth
<veltas>
!gforth 36 BASE ! 6DSZO45G PAD TUCK ! COUNT TYPE
22:17:09
##forth
<gforth_eval_bot>
next
22:17:28
##forth
<xentrac>
yes, but if you try to define : 2>R swap >r >r ; it will not work
22:18:05
##forth
<veltas>
Unless you can specify it to be inlined
22:21:18
##forth
<xentrac>
true!
22:21:51
##forth
<xentrac>
: 2>r postpone swap postpone >r postpone >r ; immediate perhaps?
22:23:36
##forth
<veltas>
Yeah
22:25:39
##forth
<veltas>
!gforth WARNINGS OFF : 2>R ]] SWAP >R >R [[ ; IMMEDIATE : TEST 2>R 2R> ; 1 2 TEST .S
22:25:40
##forth
<gforth_eval_bot>
<2> 1 2
22:26:01
##forth
<veltas>
]] in gforth just means "start postponing everything"
22:26:31
##forth
<veltas>
!gforth 1 2 .S
22:26:32
##forth
<gforth_eval_bot>
<2> 1 2
22:36:49
##forth
<veltas>
!gforth S" /usr/share/gforth/0.7.3/blocked.fb" OPEN-BLOCKS 0 LIST
22:36:50
##forth
<gforth_eval_bot>
Screen 0 not modified
22:39:32
##forth
<veltas>
!gforth S" /usr/share/gforth/0.7.3/blocked.fb" OPEN-BLOCKS : X 4. DO I LIST LOOP ; X
22:39:32
##forth
<gforth_eval_bot>
Screen 0 not modified
22:40:04
##forth
<xentrac>
wow, last modified 30 years ago
22:41:03
##forth
<veltas>
Unfortunately that's the only block program that comes with gforth, as far as I know
22:41:24
##forth
<xentrac>
oh, the only one stored in a block fiel?
22:41:27
##forth
<xentrac>
*file
22:41:39
##forth
<veltas>
Makes konilo look bloated
22:42:31
##forth
<xentrac>
29aug95 is before GForth itself, I think? maybe this is from bigForth
22:44:02
##forth
<xentrac>
I didn't know bigForth supported the $ hex prefix that's recently been added to Forth 200x
22:46:47
##forth
<veltas>
Yes this code is very uncharacteristic of gforth
22:48:08
##forth
<veltas>
But yes there is a block editor included with gforth
22:48:15
##forth
<veltas>
It's not terrible either
22:51:38
##forth
<veltas>
!gforth S" ls /usr/share" SYSTEM
22:51:38
##forth
<gforth_eval_bot>
aclocal
22:52:44
##forth
<veltas>
!gforth S" gcc" SYSTEM
22:52:45
##forth
<gforth_eval_bot>
gcc: fatal error: no input files
22:53:06
##forth
<veltas>
I guess gcc is a dependency of gforth
22:53:19
##forth
<veltas>
Finally, a real programming language :P
22:53:31
##forth
<xentrac>
aha
22:53:52
##forth
<xentrac>
GForth's FFI invokes it
22:56:47
##forth
<veltas>
!gforth S" ls /bin; ls /usr/bin" SYSTEM
22:56:47
##forth
<gforth_eval_bot>
bash
23:01:45
##forth
<veltas>
!gforth S" factor 50" SYSTEM
23:01:45
##forth
<gforth_eval_bot>
50: 2 5 5
23:01:51
##forth
<veltas>
amazin
23:01:56
##forth
<xentrac>
what package is factor in?
23:02:09
##forth
<xentrac>
coreutils
23:02:17
##forth
<xentrac>
I guess coreutils is probably a dependency of gcc
23:03:05
##forth
<veltas>
I'm not moaning, just exploring all the cool apps ghodawalaaman is hosting for me
23:30:54
##forth
<xentrac>
haha
23:43:25
##forth
<pgimeno>
!gforth : XYZ 101 >R 102 >R 103 >R 104 >R 105 >R 1 0 DO R> R> R> DUP . >R >R >R LOOP RDROP RDROP RDROP RDROP RDROP ; XYZ
23:43:26
##forth
<gforth_eval_bot>
105
23:44:07
##forth
<pgimeno>
!gforth : XYZ 101 >R 102 >R 103 >R 104 >R 105 >R 1 0 DO R> R> R> J . >R >R >R LOOP RDROP RDROP RDROP RDROP RDROP ; XYZ
23:44:08
##forth
<gforth_eval_bot>
102
23:45:08
##forth
<pgimeno>
!gforth : XYZ 101 >R 102 >R 103 >R 104 >R 105 >R 1 0 DO R> R> R> I' . >R >R >R LOOP RDROP RDROP RDROP RDROP RDROP ; XYZ
23:45:09
##forth
<gforth_eval_bot>
103
23:45:14
##forth
<pgimeno>
!gforth : XYZ 101 >R 102 >R 103 >R 104 >R 105 >R 1 0 DO R> R> R> I . >R >R >R LOOP RDROP RDROP RDROP RDROP RDROP ; XYZ
23:45:15
##forth
<gforth_eval_bot>
104
23:45:39
##forth
<pgimeno>
I think pforth inverts i and i' (although it doesn't actually support i')
23:50:51
##forth
<pgimeno>
the first statement returns 105 on both, which means that they both allocate 2 cells in the return stack for a DO LOOP
23:51:01
##forth
<pgimeno>
fourth*