00:00:00 --- log: started forth/19.06.25 00:00:13 --- join: Keshl__ (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth 00:00:22 --- quit: Keshl_ (Read error: Connection reset by peer) 00:02:28 --- nick: Keshl__ -> Keshl 00:23:18 --- join: xek (~xek@apn-31-0-23-201.dynamic.gprs.plus.pl) joined #forth 01:24:42 --- quit: Blue_flame (Quit: Blue_flame) 02:01:57 --- quit: reepca (Read error: Connection reset by peer) 02:44:43 --- join: gravicappa (~gravicapp@h109-187-231-103.dyn.bashtel.ru) joined #forth 03:50:10 --- quit: gaze___ (Quit: ZNC 1.7.1 - https://znc.in) 03:51:27 --- join: gaze__ (~gaze__@45.32.221.179) joined #forth 04:48:59 h'lo folks 05:07:30 --- quit: Zarutian (Read error: Connection reset by peer) 05:07:36 --- join: Zarutian_2 (~zarutian@173-133-17-89.fiber.hringdu.is) joined #forth 05:10:37 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 05:16:30 --- nick: Zarutian_2 -> Zarutian 05:16:40 --- quit: jn__ (Ping timeout: 245 seconds) 05:20:10 --- quit: jedb (Ping timeout: 244 seconds) 05:23:50 --- join: jn__ (~nope@aftr-109-90-233-87.unity-media.net) joined #forth 05:24:32 hello brother 05:25:08 --- join: jedb (~jedb@147.10.27.133) joined #forth 05:26:17 --- join: jedb_ (~jedb@103.254.153.113) joined #forth 05:29:35 --- quit: jedb (Ping timeout: 245 seconds) 06:04:36 --- quit: proteusguy (Ping timeout: 244 seconds) 06:38:00 tp: What is the schematic capture tool you are using? 06:51:08 --- quit: rdrop-exit (Quit: Lost terminal) 06:53:11 --- quit: jedb_ (Ping timeout: 246 seconds) 07:02:50 --- join: jedb (~jedb@185.128.24.51) joined #forth 07:16:26 --- quit: jedb (Ping timeout: 268 seconds) 07:17:40 --- join: jedb (~jedb@185.128.24.51) joined #forth 07:29:22 --- quit: jedb (Ping timeout: 258 seconds) 07:31:49 --- join: jedb_ (~jedb@185.128.24.51) joined #forth 07:36:40 --- quit: tabemann (Ping timeout: 252 seconds) 07:49:56 --- join: john_metcalf (~digital_w@host86-170-8-235.range86-170.btcentralplus.com) joined #forth 08:16:13 --- join: proteusguy (~proteusgu@cm-58-10-209-120.revip7.asianet.co.th) joined #forth 08:16:13 --- mode: ChanServ set +v proteusguy 08:26:40 --- quit: xek (Ping timeout: 245 seconds) 08:34:52 --- join: xek (~xek@apn-31-0-23-201.dynamic.gprs.plus.pl) joined #forth 08:35:00 --- join: dys (~dys@tmo-108-147.customers.d1-online.com) joined #forth 08:43:47 --- quit: xek (Ping timeout: 246 seconds) 10:38:31 --- join: the_cuckoo (~charlie@94-227-147-7.access.telenet.be) joined #forth 10:50:56 --- join: reepca (~user@208.89.170.37) joined #forth 10:51:42 --- quit: dddddd (Remote host closed the connection) 10:53:23 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 11:50:02 --- quit: gravicappa (Ping timeout: 252 seconds) 12:36:15 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth 12:42:24 --- quit: dys (Ping timeout: 272 seconds) 12:42:35 --- join: dys (~dys@tmo-102-170.customers.d1-online.com) joined #forth 12:52:45 --- quit: mtsd (Quit: Leaving) 13:58:39 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 13:59:35 hi 15:11:08 DKordic, gSchem, part of gEDA 15:11:13 hi dave0 15:13:08 hi tp 15:15:03 cool and dry today for dave0 ? 15:15:20 it's been raining most of yesterday and 14c here 15:27:36 it looks nice outside... sunny with some clouds over the ocean 15:28:15 i'm execting my friend to come over at 10am (it's 8:30am now) 15:28:57 more sun here today but tons of serious looking clouds here, 8:30 also :) 16:28:22 --- quit: john_cephalopoda (Ping timeout: 252 seconds) 16:32:18 --- quit: dave0 (Quit: dave's not here) 16:32:21 --- quit: ashirase (Ping timeout: 244 seconds) 16:34:25 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 16:41:32 --- quit: ashirase (Ping timeout: 252 seconds) 16:41:46 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 16:44:08 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 17:24:32 --- join: rdrop-exit (~markwilli@112.201.174.189) joined #forth 17:25:37 c[_] Good morning Forthwrights 17:51:42 --- join: tabemann (~tabemann@h193.235.138.40.static.ip.windstream.net) joined #forth 17:54:39 about BBSes written in BASIC... somehow I imagine BASIC, from my recollection of it, as being too limited to implement a large, non-trivial piece of software in 17:56:05 Hi tabemann 17:56:24 hey rdrop-exit 17:56:49 (I of course mean the likes of Applesoft BASIC - later BASIC's like QuickBasic were more capable) 17:57:31 Most Basics had peek and poke 17:58:00 yeah, you poke your machine language into memory, and then you CALL it 17:59:00 I'm surprised more microcomputers didn't come with Forth 17:59:02 I did some research last night trying to remember the name of the BBS SW, I'm pretty sure it was this one: 17:59:10 https://en.wikipedia.org/wiki/RBBS-PC 18:01:07 Basic was everywhere 18:02:26 Basic was everywhere, Id made up a kit with a Intel 8049 or 8051 that came with Basic in ROM in the mid 80's yet I'd never heard of Forth 18:02:37 I remember checking books out from the local library full of programs written in BASIC and tapping the code into my Apple //e at home 18:02:37 hi rdrop-exit and tabemann 18:02:43 hey tp 18:02:49 Hi tp 18:03:15 I used that basic board to repair a Dynapert pick and place machine on site 18:03:39 my first exposure to Forth was later, when I was on a Mac and the Mac's previous owner was a programmer, and one thing that they'd gotten was a copy of a version of Forth from Yerkes observatory (here in WI actually) 18:04:11 but Basic was my first HLL after machine code and assembler and it really screwed my programming, for instance I just couldnt grok C after basic 18:04:19 but I couldn't figure out how to program in that; my first serious use of Forth was when I was exposed to Ficl thanks to Dr. Dobb's Journal 18:05:03 so I spent 12 months unlearning Basic and then learnt Pascal, after that I easily transitioned to C 18:05:32 I have ficl here, but 99,99% of the time I run Forth on real hardware 18:05:49 small real embedded hardware 18:06:05 I always felt so limited by BASIC, because I read books from the local library on stuff like C and Lisp and even Prolog, and even the Logo I was exposed with had real procedures, unlike BASIC 18:06:27 I think the whole idea of 'GOTO's was what messed up my admittedly poor programming skills 18:06:33 I hated GOTO 18:07:04 as soon as I was exposed to structured programming I knew it was the Right Thing 18:07:23 if the World Court had seen my Basic code from those days they would have put me to death for crimes against humanity 18:08:02 I loved C for years, now Im not attracted to it at all on small embedded, Forth is all I want and need for that 18:08:17 Id use C or Lisp on a PC tho 18:09:58 On PCs dbase II replaced Basic as a first language for many office automation type programmers 18:10:22 to me C is like portable assembly (or as close to such as is reasonably possible), while on large systems I'm attracted on one hand to functional programming languages like Haskell and Erlang, and on the other hand, to Forth, because I like building things of my own, and Forth allows me to build my own programming environment 18:11:22 I'm not really interested in programming in other people's Forths these days on larger systems, because the whole attraction is that I made it myself from the ground up 18:12:00 tabemann: I know exactly what you mean. 18:12:27 It's the exact opposite of most software "engineers," though, who seek to write as little original code as possible. 18:12:47 And 90% of what they do write is just to line a set of libraries up in a straight line. 18:12:50 Where's the fun in that? 18:13:08 I share your outlook completely - ideally I'd like to build the hardware myself too. 18:13:35 I at one point was trying to write my own Scheme, but it was too hard implementing anything beyond a mere toy (no macros or anything), whereas with Forth, it is fully practical to build your own fully-functional Forth from the ground up 18:14:08 Yes, completely. You can go well beyond the normal Forth boundaries all on your own if you want to. 18:14:21 Forth just *makes sense* in a way that very few things do. 18:15:24 lately I have just been sticking new features onto hashforth just because I like making things just because I can 18:15:33 I've been auto-generating a lot of LaTeX lately. My first really significant dive into LaTex. I've decided it's not a language at all. 18:15:37 It's a toolbox. 18:15:55 A toolbox with like 10 million tools in it that don't necessarily follow a common paradigm. 18:15:59 So you can't really "learn it." 18:16:15 You just have to search around for a tool that will do what you want, and copy and paste someone's code. 18:16:27 I always found it interesting that Knuth implemented TeX as a macro language 18:16:34 Contrast that with Forth, where there are basically one or two things to learn and you've got the whole thing. 18:16:51 with Forth if it's not there, you can always build it 18:16:57 Sure. 18:18:09 Forth is a way to make your own bespoke technology and tools stack, probably the only practical way to do that. 18:19:34 Forth is technology you can build all by yourself without needing anything beyond a text editor and either an assembler or a C compiler to build the initial Forth core 18:20:01 I've almost got mine to the point where it will metacompile. 18:20:07 Then I won't need any other tools. 18:20:12 It'll be completely self-contained. 18:20:59 I'm ashamed to say I haven't worked on it in several months, though. :-( 18:21:04 Just got busy with other stuff. 18:21:15 I would do that except I want mine to be portable, and if I write an assembler and then generate asm for it it won't be portable 18:21:39 I have a bottom layer I call "portable instructions," or PI's. 18:22:04 Lower level even that most Forth primitives. Like "increment SP," and "store TOS to SP," and so on. 18:22:09 Basic VM operations. 18:22:22 There are a few dozen of them - that should be all I'd need to port to move it to a new platform. 18:22:43 I could have done it with many fewer, but I don't want that layer to cost any performance. 18:24:02 So PI's get implemented in assembly (or binary), primitives get implemented with PI's, and then definitions as usual. 18:29:07 but how much hardware abstraction can you do, e.g., just considering small systems, reconciling the architecture of the ARM with that of the Z80 is not going to be trivial 18:30:28 I don't care about portability on targets, only on the host side of the tether. 18:31:13 I agree - I've convinced myself I can do x64 and ARM and have what I would consider "optimum" primitives. The PI's don't get "executed" - they're basically compile time macros that add code to the primitive definition. 18:31:29 I do think that stretching to a processor as different as the Z80 would be very hard to do. 18:31:36 It's not a "universal" approach. 18:31:50 My host Forth runs on a VM coded in C for POSIX platforms. I use the host side to deposit machine code on the target. 18:31:55 But I suspect that any processor with a relatively rich register set would wind up similar to x64 or ARM. 18:32:31 rdrop-exit: I think what you've built is right along the lines of what PoppaVic is interested in. 18:32:46 I worry about portability on targets only if the final product requires it. 18:32:49 I'm more interested in systems where the ultimate target will be able to host a full Forth. 18:32:58 my Forth is written in straight C 18:32:59 Seems sensible. 18:33:09 I do think some people get obsessed with portability. 18:33:35 and my main targets are really x86-64, x86, ARM, and ARM64 18:34:04 I could make my Forth run on a smaller system if I cut down the image severely 18:34:07 Well, my system requires more registers than are readily available on 32-bit x86. At least to run with full efficiency. 18:34:17 But x64 and the ARMs should all work well. 18:34:22 because the core runtime is actually pretty small, but the image is large 18:34:26 But ask me again after I've RUN IT on an ARM. 18:34:53 With separate host and target systems, you can put whatever you want on the target, from a few bytes of machine code to another full blown Forth. But your host development environment can be used for all your projects regardless of target. 18:35:00 * tabemann should get a Raspberry Pi just to play around with it 18:35:05 Z80 is very register starved - I'd have a hard time there. 18:35:10 I'd wind up having to re-architect it. 18:35:34 Maybe register-starved isn't the right phrase - more like "register capability starved." 18:36:16 It's like someone had in mind what you were going to do with the registers beforehand, and that's more or less all each one will do. 18:36:42 The host side of tethered Forth is basically your multi-target IDE, you can have assemblers for all your different targets on it, and host the headers for headerless target systems too. 18:37:26 Your host can be rich even though your targets are starved. 18:38:12 Right. But that's just not the sort of gadgets I expect to build. 18:38:21 It's a perfectly nice target set, though. 18:38:55 Not every project requires a full blown Forth on the target, often just a target monitor is enough. 18:39:28 But your host can always be a full blown Forth. 18:39:31 * tabemann just executed latestxt . on a fresh instance of hashforth and it outputted 1150 (mind you that hashforth is TTC, so that means that that is the last token compiled, incrementing up from zero) 18:40:24 Of course nothing precludes you putting a full blown Forth on the target if you want one. 18:41:17 with hashforth I could run the hashforth runtime on both the host and the target, albeit with all the POSIX stuff removed from the target runtime, and then run two different images, one being for the plain Forth runtime and one being for just interfacing with the host 18:43:12 For some targets your minimum monitor should be only a few hundred bytes. 18:45:17 You can also have it as a bootloader option if you want. 18:48:01 Tethered Forths give you the best of both worlds as far as I'm concerned, a universal development environment on the host that you can use for all your projects, and as much or as little on the target as you need for each particular project. 18:50:48 If you work with multiple targets, you can have assembler vocabularies on the host for all of them. 18:53:09 for something like the Raspberry Pi I wouldn't use a tethered arrangement, since it is much bigger than the kind of systems where that becomes attractive, but if I were working with, say, one of those STM32 systems I would definitely consider it 18:55:41 ^ That's why I mentioned PoppaVic - he's interested in those itty bitty little processors. 18:55:53 I don't see why not, regardless of the target you can maintain one development environment on your host, and optimize speed/size tradeoffs on the target for the application. 18:57:09 I assume if your target is large and powerful, it's because your application needs all that power and size. 18:57:39 Forth is not an end in itself. 18:57:59 :-) Sure it is. 18:58:07 I'm joking, but only somewhat. 18:58:11 ;-) 18:58:59 what's that processor that comes with the builtin wifi? 18:59:35 it's a small processor, it's like ESP 19:00:05 What Forth gives you is interactivity and incrementalism, or at least the ability to take advantage of as much as the target is capable of. 19:02:24 You needn't use tons of the target's resources to achieve that interactivity and incrementalism. 19:03:01 (or else the incrementalism just went out the window). 19:03:51 hashforth e.g. does not need nearly as much resources to just run hashforth VM code as to actually compile Forth code to VM code 19:04:29 tabemann: esp8266 ? 19:04:30 Can the headers reside on your host? 19:04:33 especially once things such as all the POSIX interface code is diked out 19:04:40 crc: that's it 19:06:09 rdrop-exit: in the current implementation the token table has to be on the target, but that's it 19:06:38 The first step to minimizing your target footprint not being forced to have the headers on the target. 19:06:51 * is not... 19:08:04 except doing so requires changing it to use CALL opcodes, which on a small system would likely be larger than hashforth tokens 19:08:32 because on a small system a token would be either 8 bits or 16 bits 19:09:14 whereas with a CALL opcode the opcode would be 8 bits itself, and the operand would likely be 16 bits (if one can ensure that all code resides < 64 K) 19:09:30 which may not be true on small 32 bit systems like many ARM systems 19:11:43 bbiab 19:25:57 --- quit: tabemann (Ping timeout: 244 seconds) 19:40:24 --- join: tabemann (~tabemann@2600:1700:7990:24e0:1ce2:9bd6:6ee:b28e) joined #forth 20:07:52 --- join: Blue_flame (~cdadr@2409:4042:2311:7565:112c:1ba4:26e5:9441) joined #forth 20:20:49 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 20:21:18 --- join: Green_flame (~cdadr@157.33.173.110) joined #forth 20:21:31 re 20:22:16 --- quit: Blue_flame (Ping timeout: 252 seconds) 20:31:12 --- quit: Green_flame (Quit: Green_flame) 20:31:40 --- join: Blue_flame (~cdadr@157.33.173.110) joined #forth 21:08:45 --- quit: proteusguy (Ping timeout: 245 seconds) 21:17:40 --- join: gravicappa (~gravicapp@h109-187-231-103.dyn.bashtel.ru) joined #forth 21:22:17 --- quit: dddddd (Remote host closed the connection) 21:48:48 --- quit: dave0 (Quit: dave's not here) 22:25:39 --- join: proteusguy (~proteusgu@mx-ll-180.183.97-198.dynamic.3bb.co.th) joined #forth 22:25:39 --- mode: ChanServ set +v proteusguy 22:26:45 --- quit: dys (Ping timeout: 258 seconds) 22:43:01 --- quit: Blue_flame (Quit: Blue_flame) 23:59:59 --- log: ended forth/19.06.25