00:00:00 --- log: started forth/19.03.13
00:34:10 --- quit: PoppaVic (Ping timeout: 252 seconds)
01:01:32 <the_cuckoo> corecode: watched the rest of the AP/L vid - that's awesome :) 
01:05:25 <presiden> AP/L?
01:07:43 <the_cuckoo> corecode was comparing my case statement with it - i didn't know of it either - https://www.youtube.com/watch?v=a9xAKttWgP4
01:10:13 <the_cuckoo> i think it takes symbolic coding to an extreme which makes me laugh - and i consider it a fair criticism, although mine does go anywhere near that extreme :)
01:12:12 <the_cuckoo> my case statement over multiple lines has this form (here i expect a keypress as input):
01:12:18 <the_cuckoo> : handle &{
01:12:21 <the_cuckoo>     +> 27 == { leave }
01:12:23 <the_cuckoo>     +> 32 == { toggle }
01:12:25 <the_cuckoo> } ;
01:13:56 <the_cuckoo> i originally posted the full/condensed form:
01:14:00 <the_cuckoo> : handle &{ +> 32 == { toggle } +> 27 == { leave } +> 106 == { back } +> 107 == { toggle } +> 108 == { play } } ;
01:14:28 <the_cuckoo> (which introduces j, k, l for basic transport controls for video playout
01:15:21 <the_cuckoo> i agree that the code would be clear if it were textual - like +> becoming case for example
01:17:47 --- join: PoppaVic (~PoppaVic@unaffiliated/poppavic) joined #forth
01:18:00 <the_cuckoo> other suggestions were to use the 0; thing to short circuit a word (it's not a construct i am familar with - haven't investigated further, but from what i saw it looked kinda nice)
01:22:04 --- join: dave0 (~dave0@223.072.dsl.syd.iprimus.net.au) joined #forth
01:50:47 --- join: xek (~xek@apn-37-248-138-83.dynamic.gprs.plus.pl) joined #forth
02:17:01 <KipIngram> Well, I can't seem to get my Forth to accept re-directed input.  It partially works, but not well.  I guess my dickering around with the termios has made that not work well.
02:17:26 <KipIngram> Looks like I'll have to generate my code generator test code into the blocks.dat file and LOAD it.
02:17:48 <KipIngram> Redirected output works, but with a mess of escape codes in it which I will have to filter out.
02:17:54 <the_cuckoo> you should be able to tell if stdin is a tty
02:18:29 <the_cuckoo> only if it's a tty would you mess with termios kinda thing
02:19:06 <KipIngram> That makes sense.  So my program would have to explicitly check for that?
02:19:23 <KipIngram> And skip the termios stuff in that case?
02:19:28 <the_cuckoo> tty = isatty( fileno( stdin ) );
02:19:37 <the_cuckoo> is what i used
02:19:47 <KipIngram> I'm working exclusively in nasm.  I'll have to figure out the system call for it.
02:19:48 <the_cuckoo> can't recall the c headers - checking
02:19:52 <the_cuckoo> ah
02:20:09 <the_cuckoo> the c headers may lead you to an implementation though
02:20:13 <KipIngram> But I need to figure that out and do it.
02:20:14 <KipIngram> Yes.
02:20:30 <the_cuckoo> #include <unistd.h>
02:20:39 <KipIngram> I guess I could just comment out the termios stuff for a trial run.
02:20:46 <the_cuckoo> yeah
02:20:53 <KipIngram> Trying that now.
02:23:23 <the_cuckoo> https://linux.die.net/man/4/tty_ioctl <- isatty apparently uses this - specifically the TCGETS ioctl
02:23:48 <the_cuckoo> guessing that ioctl should be in your available stuff?
02:25:58 <the_cuckoo> heh - in fact, i need to use that in a couple of other cases now i come to think of it (to determine applicability of the kbhit and readline stuff for example)
02:26:14 <WilhelmVonWeiner> the_cuckoo: is rpany typed?
02:29:27 <the_cuckoo> loosely - there's a coercion system which allows conversions of primitive types (numerics, bools, strings) on request
02:30:16 <the_cuckoo> otherwise, it just comes down to the implementation requesting specific types from the data stack - mismatch, exception thrown
02:31:00 <the_cuckoo> execution, not parsing (or what i loosely call compilation)
02:31:36 <KipIngram> Yes, I'm doing a couple of ioctls currently.
02:31:42 <the_cuckoo> figures
02:31:49 <the_cuckoo> should be easy then
02:31:57 <KipIngram> It's devilishly hard to chase down the right code numbers for MacOS.
02:32:06 <the_cuckoo> :)
02:32:09 <KipIngram> I usually have to research and then write a C program that prints out values.
02:32:24 <KipIngram> The research being to figure out what the hell the names are in MacOS.
02:32:38 <KipIngram> Because they're not the same as mainstream Linux - they're more generally BSD values.
02:39:28 <the_cuckoo> KipIngram: you should be able to implement shebang quite trivially too - just #!/usr/bin/env your-asm in chmod +x'd file - results in the execution of 'your-asm filename' - easy to parse if you ignore lines beginning with a #
02:41:24 <the_cuckoo> that way, stdin is a tty when you run ./filename iyswim
02:47:20 <the_cuckoo> the only annoyance is that you can't specify additional switches/args on the shebang line with that (since env would swallow them) - in which case hardcoding the path or shebanging a shell script which invokes your-asm (kipasm?) with the additional args would work (and prefix the line which it invokes it with exec to replace the created shell)
02:49:01 <WilhelmVonWeiner> you can pass cmd line args with env
02:49:50 <the_cuckoo> that too
02:57:20 <the_cuckoo> hmm - actually, env should pass them on, but i guess you're at the mercy of the parsing of shebang in your preferred shell - logically, it would seem sensible for it to run /usr/bin/env kipasm [switches-specified] filename - but i'm fairly sure than bash at least doesn't do that
02:57:46 <the_cuckoo> than = that
02:58:12 <KipIngram> Aha, we have a bug.
02:58:45 <KipIngram> I found a path for this; I can just paste my input in - that works fine.
02:58:51 <KipIngram> Then copy the output out of the scrollback.
02:58:54 <KipIngram> But...
02:59:13 <KipIngram> When I paste a large number of lines it runs great for a while, and then something breaks.
02:59:19 <KipIngram> And it recognizes nothing after that.
02:59:28 <KipIngram> I suspect it's where my command history buffer is wrapping.
02:59:46 <KipIngram> I've thought a couple of times that there's bits there that are not really tested.
03:05:56 <KipIngram> Hmmm.  Not really sure how to go about chasing that down other than just inspecting the code.  I can put some diagnostics in there and run it t the breaking point and see what I learn.
03:06:15 <KipIngram> But at any rate, I have a way to get big swaths of code generator output now.
03:07:07 <KipIngram> I could also add some information re: my command history buffer to my prompt.
03:26:30 <KipIngram> Ok, it seems to be as it's approaching the *second* wrap.
03:26:48 <KipIngram> Maybe the first wrap lays down a problem and then the second wrap triggers it.
03:31:57 <KipIngram> Hmmmm.  But the *symptom* of the problem is that it's not recognizing any words.
03:32:08 <KipIngram> it's not crashing - it's still taking text from the console.
03:32:16 <KipIngram> It's just failing to find anything, including the null.
03:32:42 <KipIngram> Which implies that the dictionary linkages or the symbol table stuff has become corrupted.
03:33:00 <KipIngram> There's only two ways in this system to fail to recognize a word.
03:33:14 <KipIngram> Either it's not found in the symbol table or its symbol table index isn't in the dictionary.
03:34:53 <KipIngram> LATEST isn't changing.
03:37:12 <the_cuckoo> do you have a valgrind type tool to check this with?
03:37:42 <KipIngram> Oh, maybe the command history is overwriting the symbol table.
03:38:21 <the_cuckoo> don't know if valgrind can be used directly, but it's very nice - it basically runs assembly under emulation and checks *everything* :) - slow as hell, but can identify down to the c/c++ line where out of bounds accesses occur
03:38:42 <the_cuckoo> way better than a debugger
03:38:54 <KipIngram> That was it.
03:39:03 <KipIngram> The symbol table followed the history buffer in RAM.
03:39:08 <the_cuckoo> heh
03:39:09 <KipIngram> I reversed them and now it's not breaking.
03:39:19 <KipIngram> But that means the history buffer isn't staying in bounds.
03:39:24 <the_cuckoo> indeed
03:39:35 <KipIngram> So that shouldn't be too hard to figure out, now that I know what I'm looking for.
03:39:46 <KipIngram> Then to test it I can put the symbol table back after the history.
03:39:50 <KipIngram> coolio
03:41:26 --- quit: gravicappa (Ping timeout: 272 seconds)
03:46:49 <the_cuckoo> KipIngram: actually, valgrind might help you - it does seem to support assembly only projects
03:47:23 <KipIngram> I'll take a look at it.
03:47:36 <the_cuckoo> but your dialect might throw it when it comes to line number mapping (at least - may fail before of course)
03:49:17 <the_cuckoo> ah - your core is nasm of course
03:49:26 <the_cuckoo> so that should be fine
03:50:20 <KipIngram> Ok, this is interesting.  I've got a word that's related to this history navigation that simply has no definition.  In the comment above it I have a Forth definition, but in the assembly it just immediately does dosem.
03:50:35 <KipIngram> Evidently something I overlooked in finishing that part out.
03:50:56 <KipIngram> A quick translation of the Forth above did not work, but that doesn't really mean anything - just means that Forth was bogus.
03:51:17 <KipIngram> And this looks very definitively pertinent to navigating the buffer.
03:51:29 <KipIngram> So I'm betting I just have to recall exactly what I was doing there and actually do it correctly.
03:57:04 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
03:57:07 <KipIngram> Ok, that actually was it.
03:57:27 <KipIngram> And the Forth definition was correct - it's 6am here and I must have mis-entered it a few minutes ago.
03:57:34 <KipIngram> I did it again, very carefully, and now it won't crash.
03:58:42 <the_cuckoo> :) - haven't pulled an all nighter for many years - too old for that now :)
03:58:57 <KipIngram> Oh I didn't do that.
03:59:01 <KipIngram> Just woke up really early.
03:59:16 <the_cuckoo> ah :)
04:11:25 <the_cuckoo> funny - every now and then, i get an urge to use a notepad and pen while i'm working - and i create lists of things todo, tick em off, provided detailed notes - all fine for a few weeks and i'm like "i should always do this" - after that the notepad just gets filled with doodles and rubbish :) - and i'm like "oh - that's why i don't..."
04:13:38 <the_cuckoo> does give me some inspiration for 3d print designs though
04:15:00 <WilhelmVonWeiner> using a pen and paper before you start programming always seems to lead to better code in my experience
04:15:48 <the_cuckoo> yeah - can do - the doodling is a distraction though :)
04:16:54 <the_cuckoo> i tend to use my whiteboard while i'm designing stuff
04:29:26 * KipIngram loves whiteboarding
04:36:39 <corecode> hard to archive
04:36:44 <corecode> need to take pictures etc
04:37:24 <corecode> the_cuckoo: did you watch the apl video?
04:41:47 <the_cuckoo> yup - mentioned it again this morning :) - fun stuff :D
04:42:17 <WilhelmVonWeiner> APL and Forth will rise from the ashes
04:43:59 <dave0> heh apl
04:44:06 <dave0> i used to know how to code in it
04:44:31 <dave0> iota 10 gives 1,2,3,4,5,6,7,9,10
04:44:44 <dave0> and if you did /+ it would all them all up
04:45:14 <dave0> but that's all i remember, and i'm not even sure of this code :-)
04:48:17 <the_cuckoo> new one for me - curious stuff :)
04:49:26 <the_cuckoo> off topic here, but found this very interesting too - http://www.cs.brandeis.edu//~dcc/Programs/Program2018InvitedPresentation.pdf
05:07:54 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
05:18:03 <KipIngram> Heh.
05:18:19 <KipIngram> Ok, just got myself a text file with all 109,440 instruction encodings this thing can make.
05:18:43 <KipIngram> Now to run them through nasm...
05:41:01 --- join: gravicappa (~gravicapp@h109-187-192-183.dyn.bashtel.ru) joined #forth
05:53:35 --- quit: gravicappa (Ping timeout: 246 seconds)
05:54:09 --- join: gravicappa (~gravicapp@h109-187-202-26.dyn.bashtel.ru) joined #forth
06:04:58 <corecode> dave0: i think if it wouldn't use symbols, but verbs instead, it would be more usable
06:16:09 <KipIngram> Ok, got a file with the nasm-generated code in it too.
06:16:24 <KipIngram> Now it's just a matter of doing the comparison and printing a discrepancy report.
06:17:15 <KipIngram> For all variations I did offsets of -129 -128, 127, and 128 and immediate values of the same four numbers.
06:18:40 <yunfan> did nasm has plan to support none-x86 arch? KipIngram 
06:24:12 --- quit: Zarutian (Read error: Connection reset by peer)
06:24:18 --- join: Zarutian_2 (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
06:33:46 <KipIngram> I wasn't able to find anything - I had to look at gas for ARM support.
07:36:01 --- quit: tabemann (Ping timeout: 252 seconds)
07:56:40 --- quit: dave0 (Quit: dave's not here)
08:10:45 --- nick: Zarutian_2 -> Zarutian
08:14:23 <Zarutian> h'lo folks
08:15:03 <Zarutian> talking about assemblers, I saw one that was in a way in reverse order
08:15:36 <Zarutian> that is, operands selectors and destination selectors first then followed by the operation
08:17:12 <Zarutian> the neat thing with that is using two diffrent vocabularies one could either emulate directly what some assembler code did or assemble them into native instructions
08:24:30 <zy]x[yz> isn't that the convention for a forth assembler?
08:25:38 <the_cuckoo> Zarutian: that is the approach that KipIngram has taken anyway
08:25:50 <the_cuckoo> dunno about the emulation part though
08:25:55 <zy]x[yz> my shitty-and-never-completed one had a syntax that looked something like att, but backwards, e.g.  %rax %rbx add,
08:26:28 <Zarutian> zy]x[yz: not all of the Forth assemblers I have seen take that approach. Some try to keep the original assemblers conventions.
08:27:05 <zy]x[yz> and indirect addressing is built out of several words:  8 (%rax, %rdx, 4) dptr  %ebx  xor,
08:28:49 --- quit: nighty- (Quit: Disappears in a puff of smoke)
08:30:25 <zy]x[yz> hadn't thought of emulation though
08:30:47 <zy]x[yz> that would actually be really cool for a cross-compiling forth
08:31:16 <zy]x[yz> you could still support compile time execution of code words
08:35:44 <the_cuckoo> my university thesis was emulating the instruction set of a motorola risc chip - don't think i did it very well, but i did pass :)
08:41:07 <zy]x[yz> nice
08:56:05 <the_cuckoo> didn't really enjoy the academic part of academia - loved being a student though :)
08:56:42 <the_cuckoo> i continued acting like one for years - then i met the wife
09:31:02 <KipIngram> Ok, after chasing down a couple of encoding problems and a couple of problems with my Python scripts, I have it to were only 128 out of 109,440 possible instructions mismatch.
09:31:53 <KipIngram> They consist of two distinct sets:  1) immediate moves, and 2) immediate operations of any type to eax or rax.  I haven't checked rigorouly yet, but I believe in all 128 cases either encoding is allowed - nasm uses the shorter one, whereas my "pattern consistent" encoder chose the longer one.
09:32:03 <KipIngram> I believe it to be completely correct now.
09:59:29 <the_cuckoo> cool :)
10:55:01 --- join: mark4 (~mark4@148.80.255.161) joined #forth
11:08:49 --- join: xek_ (~xek@apn-37-248-138-80.dynamic.gprs.plus.pl) joined #forth
11:11:16 --- quit: xek (Ping timeout: 246 seconds)
11:27:45 --- quit: nonlinear (Quit: The Lounge - https://thelounge.github.io)
11:31:08 --- join: nonlinear (~nonlinear@unaffiliated/discrttm) joined #forth
11:33:08 --- quit: nonlinear (Client Quit)
11:44:13 --- join: nonlinear (~nonlinear@unaffiliated/discrttm) joined #forth
11:50:01 --- quit: nonlinear (Quit: The Lounge - https://thelounge.github.io)
11:50:22 --- join: nonlinear (~nonlinear@unaffiliated/discrttm) joined #forth
12:02:49 --- quit: gravicappa (Ping timeout: 252 seconds)
12:05:49 <KipIngram> Ok, I've caught on now.
12:05:55 <KipIngram> This multiple encoding.
12:06:02 <KipIngram> Particularly for immediate moves.
12:06:32 <KipIngram> If you move a negative number to rax, nasm encodes it like this:
12:06:44 <KipIngram> Kips-Air:nasmForth kipingram$ grep "mov rax, qword -129" nasm_code
12:06:46 <KipIngram>  99963 00087EE8 48C7C07FFFFFFF          mov rax, qword -129
12:07:07 <KipIngram> That instruction stores the immediate as a 32-bit value, but sign-extends it into the upper 32 bits.
12:07:29 <KipIngram> For performance reasons, the x86 clears the upper half of a 64-bit register if you operate on the low 32 bits.
12:07:34 <KipIngram> Prevents stalls somehow.
12:08:06 <KipIngram> So when you move a positive number to rax, it could use that same instruction above, just with a positive 32-bit literal, and sign extend it into the upper 32 bits.
12:08:20 <KipIngram> But you get the same result by moving your 32-bit literal to eax, the low half.
12:08:30 <KipIngram> Beause that clears the upper half, which is the same as sign extending zeroes.
12:08:33 <KipIngram> Nasm CHEATS.
12:08:54 <KipIngram> It looks at your value, and if it's positive it encodes a move to eax, which consumes fewer bytes and may be faster too for all I know.
12:09:07 <KipIngram> So fine and good, but it's sure caused me some confusion.
12:09:53 <zy]x[yz> weird.  i don't think gas does that
12:10:19 <zy]x[yz> if you write mov $123, %rax it'll unoptimally assemble exactly that
12:12:17 <KipIngram> I don't know how I feel about it.  In a way it bothers me, but iis "more efficient" in some sense.
12:12:34 <KipIngram> It's just that I didn't need sneaky the last few days - I needed CLEAR.
12:12:47 <KipIngram> But there's not doubt about it - I've tested it.
12:12:58 <zy]x[yz> it would bother me.  i'd expect an assembler to assemble exactly what i write.  maybe there's some weird reason why i want the long form (e.g., i'm trying to generate a test case)
12:14:29 --- quit: mark4 (Read error: Connection reset by peer)
12:38:51 --- quit: nonlinear (Quit: The Lounge - https://thelounge.github.io)
12:39:14 --- join: nonlinear (~nonlinear@unaffiliated/discrttm) joined #forth
13:35:20 <KipIngram> zy]x[yz: I think the part of it that would be most likely to bother me is I might be doing something clever that required that instruction to consume the same amount of space regardless of what value I gave it.
13:35:38 <zy]x[yz> yeah
13:36:09 <zy]x[yz> otherwise you'd have to use an explicit align after every instruction
13:36:30 <KipIngram> Yes.
14:29:44 --- join: pierpal (~pierpal@host161-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
14:37:46 <MrMobius> can you turn that off so it does exactly what you want?
14:56:24 <KipIngram> Maybe.
14:56:28 <KipIngram> I haven't studied the options.
14:56:49 <KipIngram> I just wrote my comparison program to print a list of mismatching encodings at the bottom, ready to paste into this disassembler:
14:56:53 <KipIngram> https://defuse.ca/online-x86-assembler.htm#disassembly2
14:57:12 <KipIngram> I got 32; plugged htem in and they disassembled into exactly what I'd asked for.
14:57:17 <KipIngram> So I declare all 109,440 correct.
14:57:43 <KipIngram> Need to tidy the code up some - I can envision a clean little set of "code word editing" definitions.
14:58:14 <KipIngram> All 32 of these mismatches are 32-bit immediate moves to 64-bit registers.
14:58:20 <KipIngram> For positive numbers.
14:58:30 <KipIngram> nasm converts them to 32-bit register moves.
14:59:11 <KipIngram> Let me man nasm.
15:00:34 <KipIngram> nothing promising in man, but it may not be complete.
15:01:10 <KipIngram> I assume the behavior is what I'd want most of the time, but I still think I'd prefer to have it something I turned on rather than off.
15:01:26 <KipIngram> A friend in another channel speculated that maybe they were gunning to win some code size contest at some point.
15:01:31 <KipIngram> And were squeezing the lemon.
15:31:36 <crc> KipIngram: nasm does size optimizations by default
15:31:44 <crc> see https://www.nasm.us/xdoc/2.14.02/html/nasmdoc2.html#section-2.1.23
15:33:33 <KipIngram> :-)  I think I'd prefer "translate my instructions, EXACTLY" by default.  Let me turn the optimizations ON.
15:33:41 <KipIngram> It's ASSEMBLER.
15:34:36 <KipIngram> The idea of optimization in assembler is a little weird to start with.  :-)
15:35:03 <KipIngram> Anyway - I figured it out fast enough.
15:35:15 <crc> use -O0 and it should be better for that
15:36:55 * crc doesn't miss x86 assembly much
15:45:24 --- quit: Zarutian (Ping timeout: 245 seconds)
15:49:30 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth
16:13:44 --- join: dave0 (~dave0@223.072.dsl.syd.iprimus.net.au) joined #forth
16:23:22 --- quit: dave0 (Quit: dave's not here)
16:24:01 --- join: dave0 (~dave0@223.072.dsl.syd.iprimus.net.au) joined #forth
16:24:09 <dave0> re
16:33:58 --- quit: xek_ (Ping timeout: 246 seconds)
16:38:01 <KipIngram> Hi dave0.
16:38:12 <dave0> hi KipIngram 
16:38:19 <dave0> sup?
16:40:56 <KipIngram> Got the code generator all validated.
16:41:17 <KipIngram> Ran every single permutation through the process - over 100k of them.  :-)
16:42:22 <dave0> ehehe
16:42:59 <dave0> so now your forth can assemble things?
16:43:40 <KipIngram> Well, this is just small set of instructions.
16:43:44 <KipIngram> There's more to do.
16:44:02 <KipIngram> But they're major ones - add, or, adc, sbb, and, xor, cmp, and mov.
16:44:18 <KipIngram> But yes, it's working in that direction.
16:44:23 <dave0> cool!
16:45:02 <dave0> i did xor in forth instead of primitive
16:45:35 <KipIngram> That's cool.
16:45:42 <dave0> for no reason.. cos the assembly code is like 2 instructions and the forth code is 7 words :-)
16:45:49 <KipIngram> I'm leaning toward primitives for performance, but that's not the only goal one can have.
16:45:58 <KipIngram> Well, that's how I looked at it too.
16:46:08 <KipIngram> If something is short and efficient as a primitive, I make it a primitive.
16:46:54 <dave0> i looked through the standard for words that work on double-words
16:47:06 <dave0> double-numbers
16:47:32 <KipIngram> I still don't have double numbers.  Just haven't seen yet that I'll need them, with singles being 64 bits.
16:48:57 <dave0> at the moment i've diddled it down to 3 words that use double-numbers..  um* (u u - ud) um+ (u u - ud) um/mod (ud u - u u)
16:49:13 <dave0> um* and um/mod are standard, um+ came from jonesforth
16:51:07 <dave0> they are good enough to do  : */mod   >r um* r> um/mod ;   (with some code to fix the sign)
16:51:41 <dave0> and i haven't written >number yet, but um* and um+ should let me detect overflow
16:53:09 <dave0> i like the arithmetic words that use double-numbers as the intermediate result so they don't overflow... c doesn't have that
16:53:18 <KipIngram> I'm more interested in floating point.  :-)
16:53:42 <dave0> pfft
16:54:00 <dave0> i've never coded with floats in assembler
16:54:00 <PoppaVic>  kip likes to do math that creates swear-words ;-)
16:54:09 <KipIngram> Heh heh.
16:54:11 <dave0> 80085 !
17:18:23 --- join: Croran (~quassel@2601:601:1801:6dde:a024:a39a:633c:7ee8) joined #forth
17:24:13 --- join: xek (~xek@apn-31-0-23-82.dynamic.gprs.plus.pl) joined #forth
17:40:29 --- quit: john_cephalopoda (Ping timeout: 240 seconds)
17:54:12 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
18:30:31 --- quit: Croran (Ping timeout: 252 seconds)
18:32:01 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth
18:34:41 --- join: Croran (~quassel@2601:601:1801:6dde:a024:a39a:633c:7ee8) joined #forth
19:43:07 --- quit: PoppaVic (Ping timeout: 252 seconds)
19:50:55 <chunkypuffs> does anybody have some fun forth code to run on acornsoft forth?
20:39:51 --- join: gravicappa (~gravicapp@h109-187-202-26.dyn.bashtel.ru) joined #forth
20:39:56 --- quit: dave0 (Quit: dave's not here)
20:43:02 --- quit: dddddd (Remote host closed the connection)
21:08:08 --- quit: pierpal (Quit: Poof)
21:08:28 --- join: pierpal (~pierpal@host161-197-dynamic.245-95-r.retail.telecomitalia.it) joined #forth
21:43:08 <siraben> I plan to implement the IEEE 754 sometime
21:43:13 <siraben> it's a good challenge, why not
21:51:41 --- quit: reepca (Remote host closed the connection)
22:10:33 --- quit: nonlinear (Quit: The Lounge - https://thelounge.github.io)
22:11:02 --- join: nonlinear (~nonlinear@unaffiliated/discrttm) joined #forth
22:30:26 --- join: PoppaVic (~PoppaVic@unaffiliated/poppavic) joined #forth
23:26:55 --- join: dave0 (~dave0@223.072.dsl.syd.iprimus.net.au) joined #forth
23:28:30 --- quit: dave0 (Client Quit)
23:30:54 --- join: dave0 (~dave0@223.072.dsl.syd.iprimus.net.au) joined #forth
23:59:59 --- log: ended forth/19.03.13