00:00:00 --- log: started retro/11.01.20 02:40:15 --- join: cfa (~cfa@unaffiliated/cfa) joined #retro 07:05:08 --- join: aisa (~aisa@173-10-243-253-Albuquerque.hfc.comcastbusiness.net) joined #retro 07:45:16 --- join: Mat2 (4dbc4598@gateway/web/freenode/ip.77.188.69.152) joined #retro 07:45:28 hello 07:57:51 --- quit: Mat2 (Quit: Page closed) 14:37:46 --- quit: aisa (Quit: aisa) 18:44:04 --- join: aisa (~aisa@c-68-35-167-179.hsd1.nm.comcast.net) joined #retro 19:04:10 --- quit: aisa (Read error: Connection reset by peer) 19:04:12 --- join: aisa_ (~aisa@c-68-35-167-179.hsd1.nm.comcast.net) joined #retro 20:08:14 --- join: roarde (~roarde@pdpc/supporter/active/sixforty) joined #retro 20:10:03 --- quit: roarde (Client Quit) 20:10:18 --- join: roarde (~roarde@pdpc/supporter/active/sixforty) joined #retro 20:40:15 --- join: qbject (~qb@8.sub-174-253-225.myvzw.com) joined #retro 20:41:27 Hi all. 20:42:03 hi, qbject 20:42:36 Hi roarde 20:44:13 What do you (personally) do with Retro? 20:44:48 it's the first forth I've had a decent look at 20:45:47 Any particular reason? 20:45:50 I'm trying to set up a very small "guest OS" that could also be native on unusual hardware 20:46:36 Sounds similar to what I have in mind. 20:47:30 at this time, Retro lacks libs for cross-dev, but building them looks more sensible than in other langs 20:48:19 Wait, what about all the various ngaro implementations? 20:48:24 also lacking is a solid basis for graphical; several concepts will be explained graphically rather than having to translate 20:48:56 I'm speaking only of "new" processors, etc., which don't yet have those languages. 20:50:20 Ahh. Do you mean a theoretical processor designed for retro? 20:50:42 the vm for the new processors would be written entirely in retro+processor's retro libs 20:51:13 no. actual processors in development not intended originally for retro 20:52:27 Gotcha. Slightly different, but similar. 20:53:05 I'll start with a simple F18 emulator and work up to ga4, then 32 . . . 20:53:35 I'm interested in building a minicomputer which runs forth (likely Retro) without a vm. 20:53:50 I have to emulate. I'm not an insider, and can afford these inexpensive chips but not the boards to run them. 20:54:32 Being an old hardware hack, I'll probably have at least a cursory look at physically building Ngaro? at some point. 20:56:17 Certainly seems like a worthwhile exercise. 20:56:22 build the vm for the hardware if the chosen forth uses one 20:56:52 then choose the lowest level of forth words and implement them directly 20:57:35 if and as it becomes beneficial, work up level by level 20:58:03 this way you always have a forth, and a path back to the original as shared code changes form 20:58:40 in other words, keep the original with the vm updated while coding another version closer to metal 20:59:16 I think I understand. 21:01:22 for retro, you'd only need to code ngaro to get started -- theoretically, anyway 21:01:42 And it sounds like a great project. 21:02:20 And I'll have a good start on it by the time the great-great-grandkids retire. 21:03:30 I have very little time. Almost get my teeth into something, then have to stop for sleep. 21:03:34 I hear that. I keep trying to keep my goals reasonable, and keep suspecting that they never will be. 21:03:38 Hard to continue next time. 21:04:17 Really, it's the work and the process that might be of benefit, rather than the "product" itself. 21:05:54 Noted. And I am trying to document so that my process could possibly benefit others, even if I don't "finish" 21:06:49 Number one project is trying to conceive then implement a tool that makes that easier and much more commonly done. 21:07:09 Trouble is, I really, really need the tool so I can make the tool. 21:08:20 Are you familiar with Distributed Proofreaders, the project that creates most of the Gutenberg texts? 21:09:10 Hah! I know the feeling. Before I realized that forth was a better fit for my goals I was working on a text editor written in lua using cat. 21:09:48 Nope. That's new to me, though I am familiar with Gutenberg. 21:10:36 The texts are scanned, then OCR'd. Naturally OCR isn't perfect and needs proofing. 21:11:11 Proofing is done by volunteers who can and often do proof one page each, each day. 21:11:36 Or most days, or quite irregularly. And it all works. 21:12:20 Problem is, concepts and ideas being developed don't break down into pages so easily. 21:12:42 Agreed... 21:14:23 But it's worth going after. Imagine if anyone who wished could develop, write, review, or test for as little as 10 minutes at a time, and it actually helped. 21:14:59 Oh wow. 21:16:06 That seems like a tasking problem more than anything. 21:16:07 Difficult task to implement. Given limited time and the difficulty and importance, I can't spend time learning anything more involved than the concepts of Retro before beginning. 21:17:14 yep. tasking. But one person or a small group can't arrange the tasking. It has to be systematic and once started, natural. 21:19:06 But I speak of tasking many, and can't task myself. Ask crc how long I've been working on a Retro highlight file for a text editor. 21:19:49 Agreed, especially when you could easily spend over ten minutes planing a ten minute task. 21:20:32 Which version of retro have you looked at? 21:21:02 Current stable. 21:22:01 I was working with a couple of versions earlier - 10.7.2. Now I'm restarting with stable, and adding unstable at the same time. 21:22:28 Retro changes a lot very fast. Makes it hard to catch up with. 21:22:36 I don't know enough yet to discern what I'd need from other versions. 21:23:17 crc's onto this now, finally. If you learn stable, you can use it for quite some time. 21:23:56 More will be added and changed, but one needn't use it. Old code will break much more slowly. 21:24:03 Ah. Good to know, especially where I would like to create something I can burn to a rom. 21:26:42 The retro image used to metacompile new retro versions can be fairly old now and work fine. 21:27:42 So, retro image in rom, new version in storage. If you wish, recompile at boot would be trivial. 21:29:32 On unix, some install retro binary and image to /usr/libexec or so, but "save" puts the new image in the current directory. No reason something similar wouldn't work when retro is in rom. 21:30:51 perfect. Because my ideal is a well-tested minimal image in immutable rom, and a user image running on top of it. If the user image ever got borked, there would be a hardware override to boot reverted to the hard rom image. 21:31:56 As I understand, that's the default for a system install of retro. Haven't tried it, as I've been busy changing and changing my user installed versions. 21:33:34 You're talking about the pre-v10 versions that could run standalone? 21:34:15 No. I plan to look at mid-9 and up at some point, but haven't yet. I came in about 10.2 or so. 21:35:43 10+ should be even easier for someone to compile standalone, but crc and friends are spending time developing the language rather than fussing with hardware now. 21:36:05 Good choice for them, IMO. Myself, I still like to fiddle. 21:36:50 Do you know if they're pursuing a specific goal? 21:37:36 No, I don't. I still like the results, tho. 21:38:36 High portablility is very high on the list, it's obvious. 21:40:31 The current approach does make it easier to write applications you can use while still having access to everything that's in your current OS. 21:41:21 Right, it ends up being an interpreted tool like Lua or Python. 21:41:24 So, you can code what you will for your new system, and be able to use it and still have access to a browser and such until you write your own browser and such. 21:42:49 It wouldn't be hard to assemble it natively for current OS, but there's not much of a point. 21:44:14 Counter to my goals as well. 21:45:29 I really appreciate all that you've told me. I've got to sleep now but I will be back again. 21:45:56 I was about to pardon myself, as well. Nite. 21:46:47 Night. 21:47:04 --- quit: qbject (Quit: Bye) 22:16:58 --- quit: roarde (Quit: Leaving.) 22:30:27 --- quit: aisa_ (Quit: aisa_) 23:59:59 --- log: ended retro/11.01.20