00:00:00 --- log: started retro/10.08.10 01:08:47 --- quit: dennisj01 (Quit: Page closed) 01:26:44 --- quit: crc (Ping timeout: 265 seconds) 01:28:26 --- join: crc (~charlesch@184.77.185.20) joined #retro 07:25:40 --- join: docl (~luke@97-120-241-117.ptld.qwest.net) joined #retro 07:28:01 hi docl 07:58:52 I added some stuff to sqlite.rx to allow access to columns within a row. 08:05:01 cool 08:06:25 crcx: why's it so complicated that you need to code a whole bunch of sqlite stuff? 08:06:43 if it was mysql you'd only need to use a socks connection and you're done 08:07:06 or you're just adding sql forth words? 08:53:38 foucist: forth words 08:54:20 ~226 lines of c to provide an socket layer to sqlite, then the rest is just forth code 09:22:16 supporting mysql would actually be more work than this 14:10:52 I wonder if it is possible to write a language that makes it inherently difficult to make mistakes 14:11:31 for example, if you were writing an AI and you wanted to make sure it would not enslave the human race 14:13:16 you'd need to not only keep from putting the wrong values in, but make sure it never self-modifies in a way that makes it have the wrong values 14:13:27 I'm not sure that can be solved on a language level 14:14:17 if it is self modifying, perhaps it could have a form of error-checking that projects the consequences of the modification 14:15:00 I guess it would basically be a revision control issue. 15:29:47 foucist: not quite; mysql has its own binary format for sending data; my sqlite wrapper uses plain text 15:30:52 docl: what if you have a random hardware issue that mutates a value in an unexpected way? 16:04:46 crc: that's a good question. can you write the software in a way that it defensively accounts for that kind of thing, I wonder? 16:06:14 you can build a layered defense, but it'll never be 100% foolproof 16:13:54 true 16:14:17 but 100% in any endeavor isn't necessarily possible to start with. 16:15:08 what we want is to make sure any existential risks we can think of stay as improbable as possible 16:15:29 so whatever the limits of foolproofness are, we should attempt to approach them 16:16:23 minimizing complexity is a good idea (at least, as a forther that is a philosophy I relate to) :) 16:17:40 the big danger is that as computing power increases, the chance someone builds an artificial general intelligence in their basement goes up. 16:18:08 so if something goes wrong in that case, it has potential to go very wrong 16:18:48 the sooner we can introduce safeguards of whatever kind, the better 16:20:00 a safer programming language might be one thing that helps the probability of catastrophic failure stay low 16:23:32 or safer data storage 16:23:32 I like the amount of testing they put into sqlite... 16:23:32 http://sqlite.org/testing.html 16:28:00 sqlite is impressive in terms of testing 16:58:12 I think the basic sqlite functionality is stable enough for use now 17:32:30 * docl is reading the tests.rx file 17:33:14 the code there isn't cleaned up, but does serve to provide basic tests/examples of the sqlite bindings 17:39:32 I've dabbled with it using a larger database (~1200 rows; a copy of the db I've built of metadata for my original ebook library); it seems to work fine with that 17:40:17 excellent :) 18:49:13 --- join: sixforty (~sixforty@pdpc/supporter/active/sixforty) joined #retro 18:56:49 --- join: daj01 (4b06f22f@gateway/web/freenode/ip.75.6.242.47) joined #retro 18:57:49 hi crc. are you there? 18:57:53 yes 18:58:07 this is dennisj01 from yesterday 18:58:17 welcome back 18:59:30 been trying to understand how the new system starts after 10.2.1. Is there a .retro file that the new retro reads to init it that i a missing? 19:02:55 might this be about the core language being moved to the image itself? 19:03:24 yes, that may be it 19:03:51 in 10.2.1, there's just cross.toka and retro.forth used to build the initial image 19:04:02 right 19:04:23 10.3 builds an initial image, using meta.retro and core.retro 19:04:35 yeah 19:04:36 then extends it with stage2.retro and stage3.retro 19:05:37 are the new nested namespaces in 10.6 19:06:14 there are nested vocabularies in 10.6, but I'm replacing them with a completely new system at present 19:06:33 cool 19:07:03 so, for something more "stable" we might again look at 10.5? 19:07:04 see http://rx-core.org/dev/rx.fossil/home 19:07:32 sixforty: 10.5 is stable; 10.6 is mostly transitionary to the new core code I've been working on 19:07:44 * sixforty nods. thanks 19:08:26 the new retro based init system is in 10.5 19:08:30 ? 19:08:53 10.6 would be the first version built using the newer core 19:09:42 10.5 mostly added files, sockets, improved threading model, and nestable vocabularies 19:09:48 does it use the core built with 10.3 - 10.5 19:10:43 it's an evolution of the old core 19:11:13 is that "evolution" in a file somewhere? 19:11:39 or a directory? that i am missing? 19:12:11 in 10.6, it's in the rx-core directory 19:12:19 as core.retro 19:14:40 but there are words assumed there already. the tokenizer, vocabularies, etc. 19:15:00 those are in the image file 19:15:28 right. and how this is generated? 19:15:47 a new image is created by loading core.retro into an existing image 19:16:35 is that original existing image is from the work 10.3-10.5? 19:17:14 yes 19:17:24 oh, ok! 19:17:47 specifically I've built each new release using the previous released image as a base 19:18:05 10.3 was metacompiled using a 10.2.1 image originally, 10.4 using 10.3, and so on 19:19:25 i was thinking you could just make a primitive of some ot the basic stuff and put it in with the vm_opcode's 19:20:19 just i half baked thought, that is :) 19:20:23 I prefer to keep the vm small; it makes it easier to implement in new languages and platforms :) 19:20:43 (I have explored larger vm's with toka, but was never quite happy with the results) 19:21:03 it's a cool system a real evolution of forth in general in my opinion! 19:23:02 so the new retro image is not a closed idea, just a little hard to explain, right? 19:23:16 yes 19:23:53 ok. thanks, i'll take a closer look at it 19:24:43 are you funded by a larger project or is it just for the love of it? 19:25:13 I work on this purely for fun 19:25:23 me too 19:25:59 great! it's so nice to meet a kindred spirit! 20:26:20 i've been trying to build upto 10.6 as you described. at 10.4 it doesn't work. i use the 10.3.1 vm and retroImage to build the new image but it seg faults 20:28:10 though i did not use an extended image at any point 20:33:56 * docl just uses the fossil repos 20:35:58 but retro 10.6 seems to compile fine for me 20:36:52 hmm. you're trying to compile each version from the prior version's image file? 20:37:14 they all compile fine for me too, independently. i'm just trying to reconstruct the evolution of retroImage. :) 20:37:22 ahhh :) 20:37:43 as crc described above 20:39:16 i did use 10.3.1 to try to compile 10.4 not 10.3, though 20:40:11 daj01: what system are you on? 20:40:45 kubuntu 10.10 20:42:08 i used the previous vm and retroImage to try to make the next retroImage in the image/Makefile directory 20:42:37 starting with 10.2.1 20:44:27 don't suppose it'd be the vm.mmap_min_addr thing? 20:44:30 i used the previous vm and retroImage to try to make the next retroImage in the image directory with the image/Makefile 20:44:52 (version may add new ports/hardware access to vm) 20:45:12 haven't checked 20:46:12 10.3 didn't seem quite right either 20:46:25 but it worked apparently 20:56:07 crc are you still with us? 21:03:44 there's alot of possible combinations of vm & retroImage. crc's description may be a simplification 21:22:12 --- quit: probonono (Read error: Connection reset by peer) 21:36:40 --- quit: crc (Ping timeout: 265 seconds) 21:37:10 --- join: crc (~charlesch@184.77.185.20) joined #retro 21:40:51 --- quit: sixforty (Quit: Leaving.) 22:14:22 --- quit: docl (Ping timeout: 260 seconds) 23:30:36 --- join: probonono (~User@unaffiliated/probonono) joined #retro 23:35:58 got 10.4 to build from 10.3.1 after rearranging image/Makefile a little but now 10.5 will only build with pristine -- the included image 23:59:59 --- log: ended retro/10.08.10