00:00:00 --- log: started forth/19.02.03 00:45:16 --- quit: dddddd (Read error: Connection reset by peer) 02:03:47 --- quit: ashirase (Ping timeout: 246 seconds) 02:06:57 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:58:11 --- join: h4shc4t (~androirc@182.181.71.95) joined #forth 02:58:39 --- part: h4shc4t left #forth 03:28:15 --- join: xek (~xek@apn-37-248-138-82.dynamic.gprs.plus.pl) joined #forth 03:40:40 --- join: gravicappa (~gravicapp@h37-122-120-86.dyn.bashtel.ru) joined #forth 03:42:28 --- join: lucasb (uid333435@gateway/web/irccloud.com/x-gwszysfcwgdfdpfr) joined #forth 03:54:43 --- quit: xek (Ping timeout: 244 seconds) 05:06:20 --- part: lucasb left #forth 05:55:22 --- quit: dave0 (Quit: dave's not here) 05:56:14 Good day Forth team 05:57:51 gforth is mega compilcated with these definitions IMO 05:58:11 but it has that C library interface so *shrug* 05:58:21 * WilhelmVonWeiner mega shrugs 06:02:15 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 06:07:36 maga shrug 06:13:34 <`presiden> platinum shrug 06:15:18 never seen why people want C library FFI so badly in many programming languages. Source to source translators are a thing and the result is probably better fit. 06:19:50 A lot of stuff just isn't implemented in a desktop Forth 06:20:27 I don't use that stuff really, but it makes me less weirded out by the whole interpret/compile: thing 06:21:10 also the fact gforth seems to call random undocumented hardcoded addresses 06:25:09 I get the impression that gforth was someones uni schoolwork or some such 06:29:49 from one topic to another: I have never seen the point of splitting the usual spawn syscall into fork and exec syscalls 06:37:56 I don't know much about syscalls 06:38:32 from what I just googled fork and exec are just older 06:45:07 in Unix sure, but not in its predecisor Multics 06:46:34 Is Multics really a "predecessor"? They had two completely different development ideologies and the end goals were pretty different 06:47:42 sometimes i want to fork without execing, or exec without forking 06:47:50 how is that hard to imagine? 06:48:08 imagine there's no forking... 06:48:13 it's easy if you try 06:48:14 --- quit: Zarutian (Read error: Connection reset by peer) 06:48:33 but as a forth person shouldn't you appreciate the factoring? 06:48:35 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 06:48:46 no exec below us 06:49:07 above us only... spawn? 06:49:07 ... 06:49:09 nevermind 06:49:45 unix is c with a separate kernel space and user space. this is where fork and exec were invented. in that context, it makes sense 07:13:51 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 07:16:40 --- quit: MrMobius (Ping timeout: 245 seconds) 07:16:40 --- nick: [1]MrMobius -> MrMobius 08:03:37 --- quit: pierpal (Quit: Poof) 08:03:53 --- join: pierpal (~pierpal@host132-240-dynamic.52-79-r.retail.telecomitalia.it) joined #forth 08:45:48 --- quit: gravicappa (Ping timeout: 240 seconds) 08:47:40 --- join: gravicappa (~gravicapp@h109-187-17-233.dyn.bashtel.ru) joined #forth 08:57:19 --- quit: pierpal (Quit: Poof) 08:57:39 --- join: pierpal (~pierpal@host132-240-dynamic.52-79-r.retail.telecomitalia.it) joined #forth 09:41:21 hey guys 09:43:01 multics was less a predecessor of unix than unix was a reaction to multics 09:57:38 --- quit: nighty- (Quit: Disappears in a puff of smoke) 10:07:42 Oooh, fork() and exec() in Forth... 10:08:20 --- quit: rdrop-exit (Ping timeout: 245 seconds) 10:10:46 --- join: xek (~xek@apn-37-248-138-81.dynamic.gprs.plus.pl) joined #forth 10:15:10 hashforth just has spawn, as does attoforth 10:15:12 my forth has fork and exec available as part of the optional `unix:` i/o extension 10:15:35 as for the system calls 10:15:44 I have not implemented them 10:16:46 --- quit: pierpal (Quit: Poof) 10:17:04 --- join: pierpal (~pierpal@host132-240-dynamic.52-79-r.retail.telecomitalia.it) joined #forth 10:18:43 I don't see spawn() listed on my freebsd or openbsd boxes 10:19:14 spawn() isn't a Unix thing 10:19:51 ok, makes sense as to why I don't see it then :) 10:19:54 (by hashforth and attoforth having spawn I mean that their tasks are spawned, not that it has any support for a system call named spawn()) 10:22:42 I dont have tasks in my system 10:23:36 hashforth is cooperative multitasking and attoforth is preemptive multitasking 10:26:37 I think I'd make some VM changes if I needed multitasking. (Probably simulate a multicore approach, with separate stacks and IP for each, sharing a common memory pool) 10:28:22 --- quit: gravicappa (Ping timeout: 246 seconds) 10:28:33 both of mine kept separate stacks and like for each task; attoforth had this baked into the VM, whereas hashforth has task switching implemented in VM instructions 10:30:46 hashforth does not keep a separate IP, because the IP gets saved on the return stack which is then called when PAUSE calls EXIT 11:07:49 --- join: Slith (~sean@123-243-231-67.tpgi.com.au) joined #forth 12:07:05 --- quit: Slith (Ping timeout: 245 seconds) 12:24:22 --- join: Slith (~sean@123-243-231-67.tpgi.com.au) joined #forth 13:11:14 --- quit: Slith (Ping timeout: 246 seconds) 13:29:10 --- quit: xek (Ping timeout: 250 seconds) 14:19:47 hi 14:24:04 crc, if you did that, would variables be thread-local by default? 14:45:59 zy]x[yz: I haven't considered that yet 14:46:12 if they shared memory they wouldn't, right? 14:47:15 Multitasking support is very low on my list of possible projects 14:49:21 WilhelmVonWeiner, the problem is that any forth word that accesses variables isn't reentrant, so that seems to me the best way to do it 14:49:44 then maybe have some word to mark variables or memory as shared 14:50:09 so sort of the inverse of how most languages handle it, because most languages make writing reentrant functions very natural 15:01:00 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth 15:01:41 --- quit: dave0 (Read error: Connection reset by peer) 15:03:25 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth 15:03:38 hi 15:03:43 hi 15:04:51 hi john_cephalopoda 15:12:19 reentrant funcs are the Debil... Your only reason for doing so is doing too much during an interrupt. Humbug. 15:17:30 or recursion or multithreading 15:18:16 i don't see why reentrancy would be something to avoid 15:18:59 because RAM, (let alone stacks), are a limited, precious resource. 15:19:00 i see it as a fundamental feature of structured programming, like using ifs and loop constructs instead of goto 15:19:17 if's and loops are gotos ;-) 15:19:42 they're controlled gotos 15:20:02 go.to. goto. polish it all you like. goto town ;-) 15:20:48 if you're working in an environment that's so limited you can't write your code to be reentrant, you're probably not talking about supporting mulithreading 15:34:35 --- quit: tabemann (Ping timeout: 245 seconds) 15:58:11 --- quit: dave9 (Ping timeout: 272 seconds) 15:58:39 --- join: rdrop-exit (~markwilli@112.201.168.172) joined #forth 15:59:53 --- join: dave9 (~dave@193.060.dsl.syd.iprimus.net.au) joined #forth 16:14:08 Good morning Forthists 16:16:30 lo 16:17:12 Hi PoppaVic 16:19:48 c|_| 16:22:08 Had to jam the last sloppy. half-assed taco in and wash hands ;-) 16:25:18 so, apparently, nothing missed today.. often a good thing 16:28:31 Can't think about tacos this early in the morning. :) 16:29:21 my morning died hours ago. 16:33:55 Just starting my morning routine 16:35:35 Catching up on the intertubes with some coffee before I walk the dogs 16:38:38 fiddling with code. 16:46:02 Fiddle-on Garth 16:48:23 --- join: tabemann (~travisb@rrcs-162-155-170-75.central.biz.rr.com) joined #forth 16:51:48 --- quit: Croran (Ping timeout: 240 seconds) 16:53:39 --- join: Croran (~quassel@2601:601:1801:6dde::4276) joined #forth 16:59:02 --- quit: john_cephalopoda (Ping timeout: 268 seconds) 17:00:19 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 17:24:55 hey 17:26:55 Hi tabemann :) 17:28:15 * tabemann just figured out why for a bounded channel with 100 spaces he was getting only 16 sends per pause 17:29:01 it's because I've got four processes, and for each time the sender or receiver either fills up the channel or empties the channel, three pauses occur 17:29:39 and 100 / 6 = 16 (in floating point 16.666...) 17:30:27 those four tasks being the main task, the sleep task, the sender task, and the receiver task 17:31:01 I had forgotten about the sleep task 17:31:16 Why do you need all this? 17:31:27 the main task is for handling user input 17:31:43 And? 17:31:51 the sleep task if for if all other tasks are waiting on input, it invokes poll() 17:32:05 --- quit: proteusguy (Remote host closed the connection) 17:32:05 the sender task sends values over the bounded channel 17:32:16 the receiver task receives values from the bounded channel 17:33:27 in theory I could deactivate both the main task and the sleep task 17:33:53 --- join: proteusguy (~proteusgu@cm-58-10-154-147.revip7.asianet.co.th) joined #forth 17:33:53 --- mode: ChanServ set +v proteusguy 17:34:04 But all this machinery is above the level of the VM, are you done with the VM already? 17:35:23 aside from adding double cell support to the VM, yes 17:35:57 and maybe adding a few other services, which I so far have found non-essential (e.g. support for the realtime clock) 17:36:55 Cool, so I guess the next step would be to publish the preliminary VM spec. 17:37:31 See if people have any problems implementing it. 17:38:00 And test some images across the different implementations. 17:38:51 one thing I might do is make it self-hosting, so people can build it without requiring attoforth to do so 17:39:15 oh and one thing - I changed it to use a fixed memory map 17:39:22 Cool 17:40:06 Attoforth has nothing to with it, people can implement the spec in C, python, FPGA, assembly, whatever. 17:40:18 rdrop-exit, I mean for building the images 17:41:05 You can build a test image that excercises the VM, that should be enough for a preliminary spec. 17:41:35 Anyome implementing the spec, can try it out on their implementation. 17:41:45 It's still early days. 17:41:48 I include a premade image in with the hashforth git repository 17:42:53 Keep the test image simple at first, just testing the various opcodes, reading and writing, etc... 17:43:39 the current image is a full multitasking system, so yeah, for test purposes, creating a much smaller image would be advisable 17:44:27 The image is just to test conformance to the spec, and excersise the system. 17:44:40 yes 17:45:00 No need to invest too much in it, as the spec is preliminary at this point. 17:46:17 Initially the main feedback will be questions about the what the spec really means, removing any vagueness in the specification. 17:47:03 it will require some infrastructure, for instance I got rid of TYPE, KEY, and ACCEPT in the services and rather replaced them with READ, WRITE, SET-NONBLOCKING, GET-NONBLOCKING, and POLL 17:48:24 Which of your four bitwidth variants are you spec'ing first, 64, 32-large, 32-small, 16? 17:48:27 TYPE, KEY, and ACCEPT seemed rather high level to be services 17:49:00 definitely 17:49:59 I've implemented for 64 bit - with 16/32-bit tokens - and 32-large will also use 16/32 tokens - because for most purposes one probably won't need more than 32767 tokens anyways so it'd be a waste of memory to just use 32-bit tokens 17:50:26 So 64 bit will be your first spec? 17:50:31 yes 17:50:39 Cool 17:52:00 this is mostly because everyone has desktop/laptop/tower machines with 64-bit processors these days, and even on smaller systems there's now 64-bit raspberry pis and like 17:52:15 ok 17:52:22 --- join: nighty- (~nighty@b157153.ppp.asahi-net.or.jp) joined #forth 17:52:56 It doesn't really matter which you start with, since all four will have to be done at some point. 17:54:15 my implementation should probably easily port to 32-large systems 17:55:19 The main challenge now is to see whether someone other than yourself can understand the spec enough to implement it and pass the initial image test. 17:55:39 32-small and 16 bit systems would probably require a reimplementation, not the least that the IO architecture would probably be completely different from the POSIX-style architecture supported for my implementation 17:55:47 Preferably without looking at your implementation. 17:57:07 before I bother to specify an architecture, should I add double cells, since they'll be very helpful on 32-bit and 16-bit systems (and I have mostly gotten away with not implementing them so far because I've been implementing for 64-bit)? 17:58:31 I wouldn't bother on the 64-bit variant, the reason you have four variants is that some things won't be equally applicable on all four. 17:59:56 I see the biggest differences between variants really being IO architecture 18:00:23 Besides it's a preliminary spec, feedback can be incorporated later. 18:01:00 Why? 18:01:03 64 and 32-large assume something roughly POSIX-like, whereas 32-small and 16 would probably have nothing POSIX-like and rather would allow direct access to IO registers and interrutps 18:03:14 (note that Win32 counts as roughly POSIX-like, as one can create a layer over it which is essentially POSIX, as shown by Cygwin) 18:04:50 Why do you need to assume an OS? 18:05:57 the way I designed my services architecture is that if a service is not implemented it can easily be intercepted and implemented in Forth 18:07:23 Yes, the sys calls are mostly for optional things. 18:07:42 so one could implement OPEN, CLOSE, READ, WRITE, SET-NONBLOCKING, GET-NONBLOCKING, and POLL in Forth if one sees fit 18:08:59 We're still far from the optional additions, the spec is the minimum implementation of the VM. 18:09:12 yes 18:09:18 Optional stuff will come much later. 18:10:06 The basics need to be pinned down first. 18:11:50 The basics should not rely on POSIX or any particular underlying OS. 18:11:51 the basics are pretty much in place, but a lot of them are implemented in VM assembly rather than as part of the VM itself - the VM itself doesn't do a whole lot 18:12:28 right now I'm assuming something POSIX-like as I need to be able to do IO somehow 18:12:30 The stuff implemented in VM assembly is optional. 18:13:03 (by definition) 18:13:17 It is above the VM. 18:13:53 without the portions in VM assembly, it can't compile or interpret Forth code 18:14:08 the compiler/interpreter are not part of the VM 18:14:50 Yes. The VM's job is to run valid image files. 18:15:44 What magic one does the produce the image file, is not the concern of the VM. 18:16:23 currently image files are created with the VM assembler 18:16:54 Ok, but someone else can produce them any way they like. 18:16:58 which of course assembles VM assembly that is suspiciously Forth-resembling, yet is not actually Forth 18:17:37 Yes, Chuck would call it a "machine Forth". 18:18:02 I.e. the assembly level of a stack machine. 18:21:25 (whether the stack machine is real or virtual) 18:21:30 it's really the macro assembly level of a stack machine, because it has words like +IF/+ELSE/+THEN, +BEGIN/+UNTIL, +BEGIN/+WHILE/+REPEAT, and +BEGIN/+AGAIN which allow structured programming 18:23:10 Your assembler happens to be that way, but that's your assembler, it's not an aspect of the VM. 18:23:19 yes 18:23:28 the VM only knows about BRANCH and 0BRANCH 18:23:37 ok 18:24:48 --- quit: Zarutian (Ping timeout: 240 seconds) 18:25:00 So the next steps are to make sure the spec is implementable by anyone, and to get feedback on the architecture. 18:25:15 yes 18:25:26 Cool, exciting stuff. 18:25:32 I should probably start writing up documentation on my github 18:27:19 I would keep it all separate from the specifics of your implementation, the spec has to be imdependently understandable and implementable without knowledge of your specific implementation. 18:27:32 yes 18:28:42 be back in a sec 18:30:53 Your test group should be as varied as possible, little endian, big endian, different OSes, the more varied the better. 18:34:18 bbiab 18:36:21 back 19:09:35 --- quit: dave0 (Quit: dave's not here) 20:05:50 --- quit: tabemann (Ping timeout: 245 seconds) 20:18:01 --- join: gravicappa (~gravicapp@h109-187-17-233.dyn.bashtel.ru) joined #forth 20:27:40 --- join: tabemann (~travisb@172-13-49-137.lightspeed.milwwi.sbcglobal.net) joined #forth 20:31:47 --- quit: dddddd (Remote host closed the connection) 20:37:12 --- quit: pierpal (Quit: Poof) 20:37:29 --- join: pierpal (~pierpal@host132-240-dynamic.52-79-r.retail.telecomitalia.it) joined #forth 21:45:40 --- join: dave0 (~dave0@193.060.dsl.syd.iprimus.net.au) joined #forth 23:46:18 --- quit: proteus-guy (Ping timeout: 240 seconds) 23:53:16 --- quit: john_metcalf (Quit: http://corewar.co.uk) 23:59:59 --- log: ended forth/19.02.03