00:00:00 --- log: started forth/18.06.04 00:05:00 forth is awesome 00:11:11 jeez it's tiny, too 00:18:11 Forth Fundamentals, volume 1 - you can still buy used on amazon or other used books web platforms 00:21:51 --- join: mtsd (~mtsd@77.110.61.100) joined #forth 00:22:49 --- quit: smokeink (Ping timeout: 265 seconds) 00:39:42 WilhelmVonWeiner: I don't know about gavino, but I made some CGI in forth 00:55:03 --- join: smokeink (~smokeink@59-125-28-152.HINET-IP.hinet.net) joined #forth 00:55:14 --- join: proteusguy (~proteus-g@182.253.63.55) joined #forth 00:55:14 --- mode: ChanServ set +v proteusguy 01:01:47 but so many people use their own forth just like everyone were trying to lift a rock by themselves in different times 01:02:29 because that's the Way of Forth! 01:02:44 a lot of people use Forth in embedded devices 01:02:48 or they build their own 01:03:44 are Forths highlanders? there will be only one in end? :-D 01:03:53 no 01:04:10 there will be infinite number of Forths in the end 01:06:45 so my predictions is true :-D AI will be hive mind of russian and chinese speaking forth erlangs 01:16:54 --- quit: smokeink (Remote host closed the connection) 01:30:26 --- nick: jedb_ -> jedb 02:04:27 i'm having some success with making NEXT be the x86 ret instruction, so far it's all in assembly, but i've been able to get some output and define words 02:05:00 i've been mimiking jonesforth: http://annexia.org/forth 02:05:49 it's crazy how much i can already do with this tiny code 02:26:41 --- quit: nighty- (Quit: Disappears in a puff of smoke) 02:31:19 Dave, what sort of a system are you going to have where you're able to turn off interrupts? 02:31:36 If you're using sp as ip then as soon as you get an interrupt it's going to bork your code. 02:39:49 oh i'm running it as a normal program under linux 02:40:30 it doesn't touch the user stack 02:40:49 linux that is 02:41:44 I'm not familar with that aspect of Linux. Is there a privileged stack that handles the interrupts that has a second stack pointer? 02:42:02 yep 02:42:10 interrupts use the kernel stack 02:42:12 Ok, fair enough then. Cool. 02:42:15 Makes sense. 02:42:28 I've never been a direct threading fan myself, but good luck with it. 02:42:42 thanks! 02:43:44 it's unreal how quickly you can get some feedback 03:07:59 does it matter if the stack grows upwards towards higher address instead of the other way? 03:15:09 --- join: malyn_ (~malyn@unaffiliated/malyn) joined #forth 03:15:43 --- join: rprimus_ (~micro@a9.lence.net) joined #forth 03:15:51 --- join: koisoke_ (xef4@epilogue.org) joined #forth 03:16:01 --- join: WilhelmV1nWeiner (dch@ny1.hashbang.sh) joined #forth 03:19:31 --- join: nerfur` (~nerfur@mail.freeside.ru) joined #forth 03:19:34 --- join: sigjuice_ (~sigjuice@107.170.193.86) joined #forth 03:20:03 --- join: FatalNIX_ (~FatalNIX@caligula.lobsternetworks.com) joined #forth 03:20:54 --- quit: FatalNIX (*.net *.split) 03:20:55 --- quit: WilhelmVonWeiner (*.net *.split) 03:20:55 --- quit: koisoke (*.net *.split) 03:20:55 --- quit: rprimus (*.net *.split) 03:20:55 --- quit: sigjuice (*.net *.split) 03:20:55 --- quit: malyn (*.net *.split) 03:20:55 --- quit: nerfur (*.net *.split) 03:20:55 --- nick: FatalNIX_ -> FatalNIX 03:20:57 --- nick: malyn_ -> malyn 03:21:18 --- nick: rprimus_ -> rprimus 03:37:49 --- quit: pierpal (Read error: Connection reset by peer) 03:46:00 No, it doesn't matter as long as you handle it right everywhere. 03:47:12 Are your cells 32 bits or 64? 03:48:10 Your stack cells, I mean. 03:49:22 --- join: johnmark (~johnmark@64.53.247.121) joined #forth 03:52:37 --- quit: FatalNIX (Changing host) 03:52:37 --- join: FatalNIX (~FatalNIX@unaffiliated/fatalnix) joined #forth 04:08:18 So here is why I ask. Let's say you've got a 32-bit stack, but your underlying processor supports 64-bit operations. 04:08:55 And say your processor is little endian. That means when it regards two 32-bit stack items as a 64-bit thing, it's going to expect the least significant half of it at the lower address. 04:09:25 So if your stack grows down in memory, that means the most significant half will be deeper in the stack, but if it grows up the most significant half will be closer to the top of the stack. 04:09:39 So getting all that right is part of "being consistent" to your choice. 04:10:34 If you've got 64-bit stack cells you may not even need to worry about double precisions on the stack, so it won't matter. 04:13:40 dave0> i'm having some success with making NEXT be the x86 ret instruction 04:14:19 the problem with doing that on x86 is that ths stack grows in the wrong direction 04:14:47 you ret and sp advances back a cell, not forward 04:16:33 Well, you could orient your system that way if you chose. 04:16:41 But wow - I'd be getting confused all the time. :-) 04:17:21 And primitives would be obtuse, because the machine code MUST proceed toward higher addresses. 04:17:41 So there would be a lot of juggling. 04:19:37 But I actually thought the x86 stack grew downward. 04:22:03 This site seems to agree: 04:22:05 https://eli.thegreenplace.net/2011/02/04/where-the-top-of-the-stack-is-on-x86/ 04:22:36 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 04:22:37 The second illustration clearly shows the stack growing from high addresses to low addresses, so return would in fact move you from low to high. 04:24:59 --- quit: mnemnion (Remote host closed the connection) 04:25:20 dave0: How are you going to implement nested definitions? Are you going to have the code preceeding the new word (the code that you ret to) be a jump instruction, or a full docol? 04:25:39 If you include a full docol there then you could probably use a pc-relative lea instruction to re-load sp. 04:26:16 A jump would be more compact, but without anything else you'd then have lost the location of the new word. 04:27:18 I guess you're looking at something like , , , ? 04:28:28 If you use si as your return stack pointer then you could probably arrange to to have your dosem be lodsX, mov sp ax. 04:29:34 Or you could use di as return stack pointer and use stosX in your docol, which might be better since a lot of your dosems might get tail-optimized out. 04:30:19 So your docol could be mov ax, sp, stosX, lea sp, . 04:30:30 And that's if you include the whole docol before each definition. 04:31:16 With that implementation I think your return stack pointer won't point to the last item pushed - it will point to the next location to be pushed into. 04:31:27 And you can choose the direction that stack grows with your direction flag. 04:32:22 I'm going a slightly more traditional route - I'm using rsi as the instruction pointer and have lodsX in my NEXT. 04:33:19 the stack does grow down 04:33:29 ret pop, so sp advances up 04:33:35 pips* 04:33:36 Right. 04:33:39 ugh 04:33:42 :-) 04:33:48 touchscreen phond 04:33:49 It's early yet - have some coffee. 04:34:10 My next looks like this: 04:34:14 45 nxt: lodsd 04:34:16 46 mov r12d, [rax+r15] 04:34:18 47 add r12, r13 04:34:20 48 jmp r12 04:34:45 r15, r14, and r13 are initialized at startup to base addresses for the various regions, and what I actually store in the cells are offsets, not addresses. 04:35:02 That gets me around the MacOS position independent code mess. 04:35:29 The stored offsets are in 32-bit cells. 04:35:40 I actually found (at least on my processor) that mov (%rsi), %eax add $4, %rax is faster than lodsd 04:36:01 That's 11 bytes, so I opt to jmp nxt as my actual NEXT. 04:36:03 er, add $4, %rsi 04:36:14 yes, I need to investigate that. 04:36:56 And could use any register. 04:37:22 The other nice thing about your way is that it leaves rsi and rdi free if you want to have address registers in your design. 04:39:17 I do want A and B addr regs in this, and I've had some thoughts about regular expression support that that would dovetail into pretty nicely. 04:40:14 yeah, it doesn't have to use rsi. it only is in mine because I started with a lods 04:41:05 --- quit: pierpal (Read error: Connection reset by peer) 04:50:59 sorry i had to leave in a hurry 04:52:25 so far it's written in i386 assembly, so i don't think it will work on amd64 04:53:50 because that's what jonesforth is written in 05:02:53 What about it would stop working? As far as I know ret is pretty standard. 05:03:28 KipIngram: after a ret i use mov esp,dword ptr [esp-4] to get the address of where i 'ret'ted to 05:03:50 Ok. 05:04:01 are you on i386 ? wanna try it? 05:04:11 No, I've got my own thing in progress. 05:04:23 And I'm not on a 386. 05:04:56 no worries 05:06:12 But I like seeing people tinker with different ideas. :-) 05:06:46 So re-using sp again to get that info means you could have your code snip before each word be a jmp. 05:06:57 yep 05:07:21 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 05:07:28 i put the address of DOCOL in %edi and do a jmp %edi which is 2 byte instruction 05:08:00 so it fits nicely into a cell 05:08:23 Mine's indirect threaded, and I have the CFAs in a separate region from the definitions. So instead of a word's parameter zone immediately following the code pointer at the CFA, I have a second pointer. So each word has a pointer pair in that region - one that points to machine code and one that points to the parameter zone, which lives elsewhere. 05:08:42 Ah, so you have di permanently dedicated to that. 05:08:59 I have some registers pre-loaded with important things like that too. 05:09:23 oh it looks like your on amd64 there's more registers 05:09:29 Right. 05:09:51 I wanted the definitions to be in their own region without anything else mixed in so that I can easily support multiple entry points to words. 05:10:13 The cells of definition N+1 begin immediately after the cells of definition N, with nothing else "stuck in there." 05:10:13 oh cool 05:10:58 So I've got a machine code region, a pointer table region, and a definition/data region. 05:10:58 i need to read more i sort of dived right into it with no full understanding 05:11:09 And headers will go somewhere else that I haven't started working on yet. 05:11:35 I store the base addresses of those three regions in registers (r15, r14, r13), and then all the stuff stored IN the regions are offsets. 05:11:53 KipIngram: it's cool how little code there is before you can do something useful 05:12:04 Yes, that's true. 05:12:23 i'm a C guy, forth is weird heh 05:12:33 I only have four instructions (loading those base address registers and pointing rsi to my first word), and I can start the inner interpreter. 05:12:39 :-) 05:12:56 Well, the first programming I ever did was in freshman year of college, and it was programming my HP-41CV calculator. 05:13:00 RPN, stack-based. 05:13:18 Small memory, so compact coding is important if you want to pack a lot in. 05:13:26 I programmed the hell out of that thing, and got really good at it. 05:13:35 haha 05:13:36 So I was "stack-machined" right out the chute. 05:14:03 Then when I discovered Forth, well - that just seemed like the greatest thing in the world. 05:14:05 :-) 05:14:09 Feels very natural to me. 05:14:14 i grew up with 8-bit with microsoft basic :-( 05:14:40 I learned assembly shortly after the aforementioned time on a 6809 (TRS-80 Color Computer). 05:14:54 i've been using C as a hobby for more than 10 years... i want to expand myself 05:15:01 Great little processor - very orthogonal instruction set. 05:15:07 yep i had a trs-80 haha 05:15:19 it has 2 stacks, it'd be perfect for forth 05:15:49 Mine was one of the old original grey ones, had 16k of RAM. 05:16:09 I upgraded it to 64k myself - I remember how scared I was I was going to brick it. 05:16:15 did you have a disk drive? 05:16:20 haha 05:16:27 Yeah, I bought a dual floppy drive for it. 05:16:39 i remember tape recorders to load programs :-) 05:17:17 I remember how loooooooooong I was waiting to load game on my soviet clone of zx 05:17:55 Yes, I started out with the cassette deck. 05:47:25 amd6r is backward compatible with x86 fyi 05:47:32 amd64 05:48:09 as long as your kernel has implemented the x86 system call interface 05:48:17 which linux does on amd64 05:55:03 and I assume windows and mac do too if they can execute programs compiled for x86 06:10:06 --- quit: epony (Read error: Connection reset by peer) 06:15:14 Yes, I think Apple plans to drop that at some point, but it hasn't yet. 06:15:46 The 32-bit attempt didn't give me any of the position independent code grief - it pretty much just instantly worked. 06:16:07 I didn't want to settle for that though, since at some point that support will be pulled. 06:17:58 --- join: epony (~nym@77-85-143-102.ip.btc-net.bg) joined #forth 06:28:19 Plus I do want the 64-bit data item capability. 06:29:48 32 bit support will likely be deprecated in the next macOS and fully removed 1-2 years after that (assuming Apple follows the path they took w/iOS) 06:30:35 weird 06:32:49 --- join: nighty- (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 06:53:16 --- join: karswell_ (~user@cust125-dsl91-135-5.idnet.net) joined #forth 06:58:43 --- quit: mtsd (Quit: Leaving) 06:58:57 --- nick: karswell_ -> karswell 07:06:17 --- quit: pierpal (Read error: Connection reset by peer) 07:11:19 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 07:13:07 --- quit: pierpal (Read error: Connection reset by peer) 07:15:44 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 07:23:03 dave0: So, you have a two-byte jump before each definition to get you to docol. But you are indirecting through your instruction cell twice (once with the return, and then again in docol with the [esp-4] reference.) If you did use edi as your return stack pointer, I think you could have a docol that looked something like this: mov eax, esp; stosd; lea esp, ; ret. 07:23:21 That might only be five, six, maybe seven bytes - I haven't worked it out. 07:23:29 And you'd put that inline before each definition. 07:23:46 dave0, http://annexia.org/forth doesn't load for me. Something wrong with the site? 07:23:49 So you'd have 5-ish more bytes in each definition, but I suspect it might be noticeably faster. 07:24:30 the program counter relative load would eliminate you having to indirect through the instruction cell a second time. 07:25:12 In AT&T syntax that would be something like lea [$+], %esp. 07:25:36 Here - I'll peck that into my file and see how many bytes it is. 07:27:22 Hmmm, actually it's 10 bytes. More than I thought. The lea esp, [$+] is a whopping six byte instruction. :-( 07:28:10 is just 1, though since the program counter is pointint at the ret for that operation. 07:35:32 Actually, I'd already decided to use a jmp next vs. an inline next in my own code, on the basis that I could profile and unroll words to eliminate the performance overhead in critical sections. 07:35:50 --- quit: proteusguy (Ping timeout: 276 seconds) 07:36:00 That applies totally to you as well - so maybe "design for compactness; unwind critical sections for performance" really is the right path. 07:50:43 KipIngram: http://termbin.com/wmw5 07:52:14 proteus-guy: http://git.annexia.org/?p=jonesforth.git;a=tree 07:54:54 i'm on i386 linux.. rename 'wmw5' to 'whatever.S' and do cc whatever.S 07:59:30 KipIngram: my docol does: push IP onto RSP with 2 instructions, fetch the address that last ret jumped to with mov esp,[esp-4] (IP=esp) , add esp,4 to skip the jmp, then NEXT check the code 07:59:50 it's 4 instructions + NEXT 08:00:38 Yes, I decided that none of the stuff I was tossing around really made as much sense as I first thought. 08:01:48 i managed to keep NEXT as simply ret which is a huge win 08:02:32 at least in code size 08:20:41 Yes, once you pointed out that it's not that stack that handles interrupts that started looking like a quite nice appraoch for direct threading. 08:21:21 Kind of cool - when you're running a string of primitives you just ret from one primitive diretly to the next. :-) 08:22:46 KipIngram: i was reading about gforth and it was talking about NEXT being (pseudo-c) jmp *ip++ 08:23:13 oh i think it used goto *ip++ 08:23:45 Yes, I've written a fairly complete indirect threaded Forth in C, and it basically does that. 08:23:56 ah! 08:24:03 With the extra level of indirection, of course. 08:24:37 So something like w = *ip++; goto *w 08:25:26 Actually it's this: 08:25:28 #define NEXT { pfa=(intptr_t *)(*(ip++)); goto *((void *)(*pfa)); } 08:25:40 c is awful haha 08:25:52 :-) 08:26:24 I decided that it was getting too messy and too hard to modify it in the ways I wanted to - that's what motivated me to start this nasm implementation. 08:26:38 oh that's the assembler you're using 08:26:53 i'm using gas 08:27:38 pretty much because jonesforth used gas 08:28:34 Well, I'm more familiar with intel style syntax than AT&T, and I just found information and example source and instructions for nasm before I did for gas. 08:28:39 Pretty arbitrary choice, really. 08:29:08 i learned them both at the same time for x86 08:30:18 because my machine was linux and it used gas at&t, but pretty much everything else tutorials etc. used intel 08:31:31 So I'm planning to have two versions each of docol and dosem. One the "production version" and the other also gathering and archiving profiling data. 08:31:51 I'll be able to replace the first few bytes of the stock routines with jumps to the profiling versions when I want profiling information. 08:32:03 oh nice 08:32:17 I think from those places I'll be able to collect very thorough information - just need to decide how to store it. 08:32:37 If I just needed at it from Linux I'd toss it into a MySQL database, but I'd like to be able to use those tools within the Forth itself. 08:35:25 i called 'docol' and 'dosem': 'enter' and 'exit' cos i don't know better 08:35:52 Those aren't "requirements" - just oft-used names. 08:36:11 In the dictionary I'll name them (:) and (;). 08:36:27 oh! 08:36:40 That's something I love about Forth - pretty much NOTHING is a "requirement." 08:36:45 You write what you want and like. 08:36:48 after coming from C, the freedom with the name of forth words is odd 08:36:55 Yes. 08:37:05 : 2 1 ; 08:37:12 Watch people stew... 08:37:21 haha 08:38:05 I've often considered putting the number conversion attempt first to avoid that sort of thing, but then again it's not something you're going to do by accident. 08:38:33 And swapping those things would slow down everything. 08:41:55 it is late 08:42:14 i must sleep... cya tomorrow KipIngram 08:44:24 Laterz. Where are you? 08:44:33 australia 08:44:44 Oh wow - cool. Ok - have a good rest. 08:44:57 l8r 09:06:05 --- quit: karswell (Read error: Connection reset by peer) 09:15:52 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:81ce:6056:3841:efac) joined #forth 09:18:56 --- quit: nighty- (Ping timeout: 240 seconds) 10:12:26 --- join: dys (~dys@tmo-109-37.customers.d1-online.com) joined #forth 11:20:51 --- quit: pierpal (Quit: Poof) 11:21:15 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 11:25:41 --- quit: pierpal (Read error: Connection reset by peer) 11:27:20 --- join: Labu (~Labu@labu.pck.nerim.net) joined #forth 11:29:10 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 12:12:44 --- quit: Keshl (Quit: Konversation terminated!) 12:45:54 --- join: karswell (~user@cust125-dsl91-135-5.idnet.net) joined #forth 13:21:04 --- quit: pierpal (Quit: Poof) 13:21:21 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 14:17:40 --- join: ThirtyOne32nds (~rtmanpage@80.sub-174-204-11.myvzw.com) joined #forth 14:30:16 --- join: pierpa (57100917@gateway/web/freenode/ip.87.16.9.23) joined #forth 14:32:19 --- quit: epony (Quit: QUIT) 14:35:02 --- join: TCZ (~Johnny@ip-91.189.219.200.skyware.pl) joined #forth 14:36:48 --- quit: TCZ (Read error: Connection reset by peer) 15:15:54 KipIngram: There are situations where I have redefined numbers and digits. 15:16:09 I might want to use some gray codes, morse codes, etc. Instead of >gray or >morse everytime, I just temporarily redefine the digits 0 >gray constant 0 1 >gray constant 1 2 >gray constant 2 ( etc) 15:16:58 It's also useful if you want act on inputted data without any extra noise from words like >send. ( example) : 0 0 > send ; : 1 1 >send ; 0 1 15:17:41 There is something to be said for using number conversion as the asm core. I makes it possible to bootstrap the forth from machine code through high level. Although I'd probably just use binary for bootstrapping through machine code in high level forth - just toggle a pin. 15:19:02 --- join: TCZ (~Johnny@ip-91.189.219.200.skyware.pl) joined #forth 15:21:53 --- quit: dys (Ping timeout: 260 seconds) 15:22:20 pointfree: Excellent points. 15:22:31 --- join: dys (~dys@tmo-101-51.customers.d1-online.com) joined #forth 15:29:45 Anyway, while the thought did cross my my mind a time or two, I never actually rolled up my sleeves to do it. :-) 15:29:56 And it would have been a quick and easy thing to do. 15:37:10 --- quit: TCZ (Quit: Leaving) 15:38:11 --- quit: mnemnion (Remote host closed the connection) 15:38:19 --- quit: pierpal (Quit: Poof) 15:38:34 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 15:40:19 --- quit: Zarutian (Ping timeout: 240 seconds) 15:43:40 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:bc51:5376:bb52:521f) joined #forth 15:49:06 hi 15:50:37 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 15:53:14 --- quit: mnemnion (Ping timeout: 265 seconds) 15:54:01 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:bc51:5376:bb52:521f) joined #forth 15:58:56 --- quit: mnemnion (Ping timeout: 245 seconds) 15:59:23 compile 0 to machine code? that's crazy! 16:08:21 Actually something like xor-ing a register with itself might be faster and more compact than storing a literal zero in RAM. 16:09:45 KipIngram: depends. Some architectures have an psuedo register that ignores stores and gives you zero on loads 16:10:54 hmm but seriously would it be worthwhile to have a special case for LIT 0 ? 16:11:03 Sure - it would depend on the system. That's interesting, though. Some data storage systems will also detect blocks full of zero being written and will just set a bit in the logical page (actually it's usually clearing a bit) rather than store any real physical data. 16:11:43 The Forth documented in "Forth Fundamentals" actually has words for 0, 1, 2, and 3, if I recall correctly. 16:11:54 aha 16:12:03 A generic literal takes two cells when compiled - (LIT) and the literal itself. 16:12:10 One that has a word just takes one cell. 16:12:18 So if you use it enough, you win by having an extra word. 16:12:27 is 0 that common in real code? 16:12:28 You know, if you're really splitting hairs. :-) 16:13:34 Zarutian: When those storage systems are formatted, all logical pages are marked as "unwritten." 16:13:58 If you read an unwritten page, the system detects that and doesn't actually send the read on down to the flash memory - it shortcuts and immediately generates a page of zero. 16:14:07 sorry, meant when that register is used as operand or destination in a instruction. 16:14:08 That might take 50-60 microseconds instead of 150-200. 16:14:30 So if you WRITE a page of zeros that process can be reversed - you can just restore that logical page to "unwritten." 16:14:47 Then you can free up the page that was used for its data previously, without consuming a new page. 16:15:19 I work in IBM's FlashSystem division - that sort of stuff is what we do. 16:15:22 * Zarutian is still holding out for growable WORM media drives. 16:15:52 KipIngram: oh, what do you think of the MRAM stuff? (The magnieto resistive random access memory) 16:16:03 I've been recently testing a 2.5" form factor NVMe SSD that has 19.2 TB physical capacity. 16:16:15 And compression - it announces itself as a 43 TB storage volume. 16:16:34 Freaks me out to hold that thing in my palm and realize I'm holding nigh on 20 TB. 16:17:20 KipIngram: so you havent seen an DNA sequence printer then. ;-Þ 16:17:30 :-) No, not yet. 16:17:50 But that sounds like it would have... "slightly" more density. 16:18:12 I worry about genetics - I figure at some point we're going to get ourselves in real trouble on that front. 16:18:15 sure. but the dna-origami stuff is too interesting. 16:18:22 knowledge > wisdom, etc. 16:18:43 I bet. 16:18:51 Do you work in that area? 16:18:51 KipIngram: have you heard about the japanese swords maker dilemma? 16:18:58 No. 16:19:25 But it sounds potentially interesting. 16:19:28 nope, just too much into Drexlarian nano tech and reading nanodot.foresight.org 16:19:32 I like swords - especially Japanese ones. 16:19:38 Big Highlander fan here... 16:20:03 the japanese swords maker dilemma is thus: any sword you make could be used against you and or any thing or one you hold dear. 16:20:20 Ah. Right. 16:20:40 I think the way out of that dilemma is to note "better to be first than last." 16:20:48 and like any koans it is to get you thinking. 16:20:51 If it can be done, SOMEONE will do it, sooner or later. 16:22:09 In an old FORML proceeding I saw words that fetch characters from their own names -- effectively word names with wildcard characters and partially specified patterns that can be acted upon. 16:22:17 This would be good for redefined numbers and other situations where you want some functionality beyond literal text but you don't necessarily want spaces. 16:22:34 THAT sounds very interesting. 16:22:46 yeah about genetics. There are some debate regarding that. One point I saw is that everyone wants to eliminate rare and nasty inheritable deseases if possible. 16:22:48 I did a good bit of regular expression study a few weeks / couple months ago. 16:22:52 Sounds somewhat related. 16:23:14 Yes, there are tons and tons of good reasons to understand that stuff. 16:23:24 and I mean deseases you dont want even your worst enemy to suffer from. 16:23:29 I didn't mean to say I'm opposed to it - just that I worry. 16:25:32 pointfree: So the idea behind those words is that part of the word would drive the match, and the flexible part of the word would be available as data during the execution of the word? 16:27:00 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth 16:27:22 one issue that got pointed out where I live is the non-forced eugenics of eliminating embryeos with Downs. It works like this: a pregnant woman goes into early enough sonogram that can tell if the embryeo has Downs, she then has the option of doing an abortion. 16:27:23 That really does seem close to REs - for a general block of text you could say "find the RE that matches this text, and run certain code based on which one that is." 16:27:38 And the code would have the input text available, so could process any parts of it it wanted to. 16:28:01 Yes. 16:28:18 I had a friend growing up who's baby sister had Downs. Just major sadness all the way around for everyone. 16:32:12 another potential non-forced eugenics: There is an app available here that allows people that just met to check if they are too related. You need to have access credential to the genelogy database. 16:32:50 but that is just to minimize islanding and in-breeding though 16:34:05 KipIngram: Something like that. The word fetches characters from the name field and does stuff with them. In this FORML proceedings paper the wildcard was at the end of the word and afaik the forth only looked for a matching prefix. 16:37:24 Zarutian: Prenatal IQ tests are here. 16:37:37 pointfree: wut? 16:37:51 Seriously? 16:46:59 Afaik it's been developed but I don't know if it's available yet. I think CVS pharmacy had something to do with it. Soon mothers could view their baby's IQ score on a 7-segment display from a CVS pharmacy pregnancy test. IQ testing can now be done with just a saliva sample. It is a bit unsettling isn't it? 16:47:34 sounds snake-oiled 16:52:02 Zarutian: http://archive.is/ElzNe 16:58:51 --- quit: ncv (Ping timeout: 260 seconds) 16:58:54 did these people never see wrath of kahn?? eugenics is not the way to go!! 17:06:19 I'm thinking I'll want to match word scope rather than just individual word names in my forth. That would give me polymorphism without explicit use of dlyund's BIND word ( https://hub.darcs.net/pointfree/forth-bind ). Search the dictionary for the next word *not* from LATEST, but from the last matched word. Make the dictionary circular. For example, use the name + for both number addition and string concatenation: 17:06:27 + 17:06:33 s" 17:06:39 + 17:06:41 number 17:18:30 --- quit: pierpal (Ping timeout: 256 seconds) 17:25:52 pointfree: never understood the fetishism of using + as string concatination operation. I prefer Luas .. for that. 17:32:28 Zarutian: The easiest way to write a hello world program is to type "hello world" with a keyboard. I think the best way to concatenate strings should be to place them next to each other, especially in a concatenative language such as forth. Concatentation and addition was just the first example that came to mind. 17:37:11 Hmmm. If typing two string names next to each other causes concatenation, that means the second string produces a different effect from the first one. 17:37:18 That doesn't feel very Forthy to me. 17:37:50 What if my real goal is to search the first string for the second string? 17:37:58 + for combination of two things is why 17:38:00 In that case I'm wanting two strings on the stack. 17:38:21 Yes, if my system had an awareness of what was actually on the stack, then + could indeed concatenate two strings. 17:38:31 As well as add two ints, or add two floats, or two matrices... 17:38:55 But I think writing a literal should *always* place that literal value on the stack in some way. 17:39:05 Perhaps via a pointer, depending on your system implementation. 17:39:25 I wouldn't want the way a literal is interpreted to depend on what was already on the stack or not. 17:41:05 pointfree: With "putting them next to each other" you're talking about like in bash? 17:41:17 $1$2 concatenates the two arguments? 17:45:49 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:bc51:5376:bb52:521f) joined #forth 17:49:37 --- quit: mnemnion (Remote host closed the connection) 17:49:53 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:bc51:5376:bb52:521f) joined #forth 17:51:05 --- join: nighty- (~nighty@kyotolabs.asahinet.com) joined #forth 17:52:36 --- join: karswell_ (~user@cust125-dsl91-135-5.idnet.net) joined #forth 17:52:36 --- quit: karswell (Remote host closed the connection) 17:56:18 KipIngram: If the name is interpreted with respect to the hyperstatic scoping, and thus you're effectively matching the scoping not just individual words, then your names for a particular definition can have multiple words in them. That is, the names can have spaces in them. 17:56:34 I don't distinguish between strings and inert sequences of words. It's a choice I made and work with because I want the output of the forth cli to also be runnable forth. http://www.0xff.in/bin/AndreasWagner-parse-time-execution.pdf#page=7 17:58:10 yeah, I was just sitting here thinking that we were sliding over into different types of basic operation. Earlier, when you were telling me about the partial match words and I was thinking of RE's I saw some of the same sort of stuff floating around. 17:58:11 --- quit: ThirtyOne32nds (Read error: Connection reset by peer) 17:58:44 I've thought at times about wanting more sophisticated literals, like say this from python: 17:59:08 [ 1 2 ['a', 7] "alphabeta"] 17:59:27 sussing that out requires a more global assessment. 17:59:39 But if you could do that, you could store that thing in a heap and leave a pointer to it on the stack. 18:00:22 Sorry for the comma inconsistency there. 18:08:31 just don't let it happen again and there won't be any trouble 18:10:46 --- join: smokeink (~smokeink@59-125-75-78.HINET-IP.hinet.net) joined #forth 18:11:39 --- join: Teckla (sid172075@gateway/web/irccloud.com/x-fwmbtzxpoaruoprn) joined #forth 18:18:03 --- join: TCZ (~Johnny@ip-91.189.219.200.skyware.pl) joined #forth 18:25:09 --- mode: crc set +o koisoke_ 18:27:42 :-) 18:39:11 --- quit: mnemnion (Remote host closed the connection) 18:39:22 --- quit: TCZ (Quit: Leaving) 18:40:01 --- join: mnemnion (~mnemnion@2601:643:8102:7c95:bc51:5376:bb52:521f) joined #forth 19:24:41 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 19:29:17 --- quit: pierpal (Ping timeout: 265 seconds) 19:42:30 --- join: epony (~nym@77-85-143-102.ip.btc-net.bg) joined #forth 19:45:44 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 19:47:53 --- quit: epony (Quit: QUIT) 20:08:31 --- join: ThirtyOne32nds (~rtmanpage@111.sub-174-204-3.myvzw.com) joined #forth 20:14:47 --- join: tadni- (~tadni@71-11-142-172.dhcp.stls.mo.charter.com) joined #forth 20:23:35 --- quit: tadni- (Quit: ZNC 1.7.0 - https://znc.in) 20:29:26 --- join: tadni- (~tadni@71-11-142-172.dhcp.stls.mo.charter.com) joined #forth 20:36:59 --- quit: pierpa (Quit: Page closed) 20:47:19 --- quit: pierpal (Ping timeout: 240 seconds) 20:48:21 --- quit: tadni- (Remote host closed the connection) 20:49:37 --- join: tadni- (~tadni@71-11-142-172.dhcp.stls.mo.charter.com) joined #forth 20:51:42 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 20:52:47 --- join: epony (~nym@77-85-143-102.ip.btc-net.bg) joined #forth 20:52:51 --- quit: epony (Remote host closed the connection) 20:53:09 --- join: epony (~nym@77-85-143-102.ip.btc-net.bg) joined #forth 20:59:29 --- quit: pierpal (Quit: Poof) 20:59:47 --- join: pierpal (~pierpal@host23-9-dynamic.16-87-r.retail.telecomitalia.it) joined #forth 21:43:46 --- join: tadni_ (~tadni@71-11-142-172.dhcp.stls.mo.charter.com) joined #forth 21:53:20 --- quit: smokeink (Ping timeout: 256 seconds) 21:56:22 --- quit: tadni_ (Quit: Konversation terminated!) 21:56:46 --- join: tadni_ (~tadni@71-11-142-172.dhcp.stls.mo.charter.com) joined #forth 21:59:03 --- quit: tadni_ (Client Quit) 21:59:38 --- join: tadni_ (~tadni@71-11-142-172.dhcp.stls.mo.charter.com) joined #forth 22:44:15 --- quit: Labu (Quit: WeeChat 2.0.1) 22:52:48 --- quit: johnmark (Ping timeout: 260 seconds) 22:55:16 --- join: johnmark (~johnmark@64.53.247.121) joined #forth 23:52:13 --- quit: dys (Ping timeout: 265 seconds) 23:52:49 --- nick: nerfur` -> nerfur 23:59:59 --- log: ended forth/18.06.04