00:00:00 --- log: started forth/18.12.02 00:15:52 okay, I'm headed off to bed 00:15:53 g'night 00:20:38 nite tabemann 00:32:41 dave0: I don't mean to be explicitly critical of linking with libc. It's a perfectly fine way to bring a system up. I've just "done that one," and wanted to try something different. 00:33:41 I think linking with libc, and using C in general (gcc in particular, since it has features more Forth engine conducive) has advantages in terms of portability, and probably also speed of development, etc. 00:34:07 KipIngram: i just meant you did it differently :-) 00:34:28 libc is a huge overhead 00:34:37 I think a non-libc approach is more "general" (you don't need C and libc to exist on the platform of choice) and also avoids forcing your architecture to conform with the requirements that libc leans you toward. 00:34:56 So good points on both sides. :-) 00:35:39 I think that last point is part of why I'm liking my current approach - I feel completely free to make the system operate any way I please, on all fronts. 00:35:46 It's "liberating," so to speak. 00:48:29 I don't mind C so much for a POSIX hosted desktop Forth, although I avoid anything GCC specific. 02:04:00 --- quit: ashirase (Ping timeout: 250 seconds) 02:13:12 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 03:12:24 --- quit: wa5qjh (Remote host closed the connection) 03:14:52 --- quit: rdrop-exit (Quit: Lost terminal) 03:58:54 --- quit: pierpal (Ping timeout: 244 seconds) 04:01:38 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 04:13:38 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 04:35:04 Reading through Thinking Forth has been enlightening. 04:37:48 Section three (the text editor) is particularly relevant to me 05:16:45 --- join: ncv (~neceve@host165-120-104-98.range165-120.btcentralplus.com) joined #forth 05:16:45 --- quit: ncv (Changing host) 05:16:45 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth 05:47:08 --- quit: Zarutian (Read error: Connection reset by peer) 05:47:14 --- join: Zarutian_2 (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 05:47:48 --- nick: Zarutian_2 -> Zarutian 06:19:44 --- quit: dave0 (Quit: dave's not here) 07:11:41 --- quit: Zarutian (Read error: Connection reset by peer) 07:12:08 --- join: Zarutian (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 08:57:26 --- quit: ncv (Remote host closed the connection) 10:30:00 --- join: ncv (~neceve@2a00:23c5:341b:d800:e144:9e2b:a867:7791) joined #forth 10:30:00 --- quit: ncv (Changing host) 10:30:00 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth 11:16:52 --- quit: ncv (Remote host closed the connection) 11:18:20 --- join: ncv (~neceve@2a00:23c5:341b:d800:e144:9e2b:a867:7791) joined #forth 11:18:20 --- quit: ncv (Changing host) 11:18:20 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth 12:42:08 --- quit: ncv (Remote host closed the connection) 13:22:14 --- join: wa5qjh (~quassel@175.158.225.202) joined #forth 13:22:15 --- quit: wa5qjh (Changing host) 13:22:15 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 13:33:52 --- quit: wa5qjh (Remote host closed the connection) 13:34:00 --- quit: tabemann (Ping timeout: 268 seconds) 13:36:06 --- join: ncv (~neceve@2a00:23c5:341b:d800:e144:9e2b:a867:7791) joined #forth 13:36:06 --- quit: ncv (Changing host) 13:36:06 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth 13:41:05 --- quit: ncv (Remote host closed the connection) 13:44:28 --- join: tabemann (~tabemann@24.196.100.126) joined #forth 15:01:40 --- quit: tabemann (Ping timeout: 245 seconds) 15:39:50 --- quit: dddddd (Read error: Connection reset by peer) 16:04:17 --- join: TheCephalopod (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 16:07:55 --- quit: john_cephalopoda (Ping timeout: 244 seconds) 16:10:20 --- nick: TheCephalopod -> john_cephalopoda 16:13:59 --- join: tabemann (~tabemann@2602:30a:c0d3:1890:e076:b2ce:d7a5:84d9) joined #forth 16:25:59 --- quit: john_cephalopoda (Quit: Trees can see into your soul.) 17:08:47 --- join: rdrop-exit (~markwilli@112.201.164.82) joined #forth 17:11:26 --- join: dave0 (~dave0@47.44-27-211.dynamic.dsl.syd.iprimus.net.au) joined #forth 17:13:10 hi 17:18:19 Good morning Dave :) 17:19:10 hi rdrop-exit :-) 17:19:54 On my first cup 17:20:34 i just finished :-) brb need a refill 17:27:31 hey guys 17:27:47 Hi tabemann 17:28:08 I've got some more extensive docs for attoforth up 17:30:25 where? 17:33:00 on github 17:33:20 search for attoforth in google, you'll find it (I took care to make sure nothing else anywhere had the same name) 17:33:30 it's in the doc directory 17:35:37 where does one start? 17:36:27 The readme doesn't give much of an overview 17:36:48 I'd say look at task.md first 17:36:56 ok 17:37:25 it is an overview of the multitasking API 17:40:22 This seems more like a glossary, do you have any documentation on the overall architecture and purpose of attoforth? 17:41:15 no I do not yet have such 17:44:59 the architecture is pretty simple, two pthreads, one for forth execution and one for IO, with round-robin preemptive multitasking 17:45:16 with separate IO setups for each task and so on 17:45:52 the purpose, well, it's that I wanted to implement a programming language environment for the hell of it, and Forth, which I had played around with ages ago, seemed like the best choice 17:50:13 I had thought of implementing Scheme, but while in theory the core of Scheme is simple, in reality modern standards are far more complex, whereas Forth is something that one can create a full working Forth realistically (not that attoforth is a "full working Forth", as there are parts that are missing simply for lack of interest in implementing them) 17:50:37 s/something that/something where 17:50:52 shown by how it seems like every person in here has implemented their own forth 17:51:38 on a total unrelated note 17:51:56 is it a bit much that I made it so ACCEPT gives the user access to a full line editor, with history and everything? 17:53:08 that's the way it should be! 17:54:06 good editing is a sign of quality implementation! 17:54:25 I spent quite a while implementing a line editor in pure Forth, originally for just interpretation, but I figured that as long as I had it I should make it available with ACCEPT too 17:54:54 the line editor is not complete per se, it doesn't do everything that Readline does, but it does most things one actually needs 17:56:02 It's pretty common to have command line history, at least on a PC forth. 17:56:47 this has that and also killing/yanking 17:57:57 dammit 17:58:07 I just noticed a regression in my killing/yanking 17:59:09 Again not unusual, in a OS hosted Forth the sky's the limit. 18:00:20 whereas in an embedded one one might not be able to have such niceities 18:02:13 You can have them on a PC hosted Forth that talks to the embedded one over a serial line. 18:03:01 yes 18:03:19 See the Forth Inc. and MPE tethered cross-compiling Forths. 18:04:35 On my Forth, if the cursor is on a word in the history, I can execute it by pressing enter. 18:06:26 my line editor doesn't really do anything exotic like 18:07:31 I don't use a line editor, my Forth interprets a word at a time, somewhat similar to LaForth. 18:08:07 oh yeah, you told me tha 18:08:10 *that 18:08:20 I have a block editor though 18:08:41 my forth just reads code from text files 18:09:23 My Forth's source is stored in the Forth itself. 18:09:58 (the PC hosted Forth that is) 18:11:22 No source files. 18:11:55 I like GNU EMACS too much to not use it for my editor 18:12:46 Different strokes 18:13:20 If you've seen one Forth, you've seen one Forth 18:15:56 yeah 18:16:12 I should try to implement a bare metal forth at some point 18:17:15 You'll enjoy it I'm sure 18:19:19 With today's FPGAs it's pretty simple to implement one's own Forth chip even. 18:19:32 yeah 18:20:13 I'm not sure if a FPGA is more efficient than just implementing Forth on stock hardware though 18:20:24 a native code Forth that is 18:25:01 It's the combination that's more efficient, a Forth Chip + application specific circuitry on the FPGA together. 18:25:55 Similar to how you have both a shell programs and C programs on a Unix box. 18:26:21 yes 18:27:34 if one has no need for application specific circuitry, though, I'm not sure if it'd have that much of an advantage, since processors implemented with FPGAs tend to be slower than processors implemented as ASICs 18:31:07 It's the economics, FPGAs are replacing ASICs in many cases 18:31:43 Plus FPGAs will become more dynmically reconfigurable, Just-in-time chips so to speak 18:32:00 --- join: MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 18:33:30 In the near future PCs will use integrated CPU+FPGA as their cores 18:34:13 Intel already has an integrated x86+FPGA 18:34:46 https://www.extremetech.com/extreme/184828-intel-unveils-new-xeon-chip-with-integrated-fpga-touts-20x-performance-boost 18:35:10 That's from 2014 18:39:18 back 18:39:36 well, yes, ASICs are obscenely expensive 18:39:54 so unless you're doing something like bitcoin mining you better have a good reason to create a new ASIC for something 18:40:05 rdrop-exit, tabemann: FPGAs suffer from FPGA manufacturers having kindergartener levels of understanding of issues like "sharing". 18:40:34 Because of this the tooling for their chips tends to be god-awful. 18:41:27 what I've heard is that so much surrounding FPGAs is kept secret by manufacturers, like the binary formats of the data uploaded to the chips 18:41:59 whereas with conventional CPUs essentially everything is open 18:42:40 That'll change in the long run 18:46:29 okay, that bug is now fixed 18:46:43 even though I don't know how it got broken, because I swear that code worked properly before 18:46:53 gremlins 18:47:11 Need more coffee, brb 18:47:12 from looking at it now, though, I can't see how it every could have worked in the first place 18:47:37 tabemann: That's the issue exactly. 18:48:27 It's almost impossible to write tooling for FPGAs because the vital information necessary to do it properly is hidden. So electrical engineers write the tooling. And...not to put too fine a point on this...they absolutely blow chunks at UX. 18:49:02 EVERY attempt I've made at breaking into the FPGA world was stymied by tooling so bad it makes MCU vendor firmware look like it was written by the greatest minds of this or any generation by comparison. 18:49:14 (And MCU vendor firmware tends to be god-awful.) 18:50:45 just why are FPGA manufacturuers so bad in this regard, when being open hasn't stopped conventional processor manufacturers from making piles of money? 18:52:05 Exactly, being bad in this regard hasn't stopped FPGA manufactures from making piles of money. 18:52:42 Commoditization takes time. 18:54:55 By the time it's easy the next big jump in technology will be in its infancy, and the cycle will start over again. 18:55:40 I bet that hybrid CPU-FPGA chips will make things better in this regard, because it will expose more programmers to FPGA technology, and thus increase demand for better tooling and documentation 18:56:48 It will make the little guy more commercially significant, because of the volume. 18:59:37 But if you have a business idea based around FPGA technology, you can't wait around until it's all served on a silver platter. 19:00:10 It's always the case in tech. 19:00:50 if you wait for things to become available, someone else will already have done what you want to do without them 19:01:14 Exactly 19:01:47 They don't call it the bleeding edge for nothin' ;-) 19:03:12 --- join: pierpal (~pierpal@95.239.223.85) joined #forth 19:15:54 Have to walk the dogs, chat again soon. 19:16:06 --- quit: rdrop-exit (Quit: Lost terminal) 19:22:43 --- quit: dave0 (Quit: dave's not here) 21:15:09 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 21:17:49 --- quit: MrMobius (Ping timeout: 240 seconds) 21:17:49 --- nick: [1]MrMobius -> MrMobius 23:14:30 --- quit: dys (Ping timeout: 246 seconds) 23:59:59 --- log: ended forth/18.12.02