00:00:00 --- log: started retro/08.11.09
03:06:37 --- join: neceve (n=ncv@dyn-89.136.41.150.tm.upcnet.ro) joined #retro
08:30:04 <lukeparrish> hi neceve, nighty^, virl
08:30:49 <lukeparrish> anyone awake?
08:40:13 --- join: sixforty (n=sixforty@204.110.227.11) joined #retro
09:16:36 <lukeparrish> hi sixforty
09:24:10 <lukeparrish> anyone awake now? :P
09:33:59 <sixforty> I'm here, but asking for 'awake' just isn't right.
09:37:18 <lukeparrish> :P
09:37:29 <lukeparrish> seems this room has been pretty empty lately
09:38:30 <lukeparrish> what do you think of retro 10, sixforty?
09:38:35 <sixforty> Was raystm2 usually in here prior to September?
09:38:51 <sixforty> I've only glanced at it.
09:39:26 <sixforty> Mebbe if it would stand still, I could get a decent look :D
09:39:37 <lukeparrish> yeah he used to be here all the time
09:39:44 <lukeparrish> :P
09:40:06 <lukeparrish> the weirdest thing about it now is that it no longer waits for you to press return
09:40:43 <sixforty> I've pointed colorforth.info to colorforthray.info. I'm asking everyone if they think Ray'd mind. He's not online to ask, unfortunately.
09:41:32 <sixforty> His absence may explain some of the silence.
09:41:40 <lukeparrish> hehe
09:41:54 <sixforty> Never chatted with him personally.
09:42:05 <lukeparrish> he probably won't mind... if he does, it's his own fault for being absent
09:42:37 <sixforty> He's absent because he doesn't have a net connection. I've been there and really feel for him.
09:42:44 <lukeparrish> :(
09:42:54 <lukeparrish> that's so sad!
09:43:13 <sixforty> That's why I registered colorforth.info when it became available. I'll hand it to Ray when he can accept it.
09:43:21 <lukeparrish> cool
09:43:41 <lukeparrish> I'm sure he'll appreciate it.
09:43:51 <sixforty> Ray explains his absence: http://colorforth.net
09:44:36 <sixforty> I appreciate Ray. Good info on c4th and forth in general
09:47:09 <lukeparrish> Yeah, he's cool.
09:47:47 <sixforty> I'm looking for bases for my personal OS. Almost used colorforth, but I'm concerned about conflicts with Chuck's proprietary projects. Might still adapt Ngaro, will have to study it more.
09:48:08 <lukeparrish> Nice.
09:48:57 <sixforty> Will be VM-based, don't mind if someone's done some of the work for me. :)
09:49:23 <sixforty> Will probably go with Andy Turley's blank, tho.
09:52:24 <sixforty> On the hardware side, each component will probably be its own machine. For example, the keyboard might be a 'node' in a 'network'.
09:53:42 <sixforty> Allows for easy drivers as soon as hw info becomes available, and also for detachable processes allowing distributed computing.
09:55:05 <lukeparrish> Cool. I've always thought the driver installation process is way too messy.
09:56:23 <sixforty> Dunno how I'd use Ngaro and still do that, thought I'm gonna study it further. "further"="some"
09:57:31 <lukeparrish> I haven't examined Ngaro closely yet.
09:58:23 <sixforty> If I use retro, I'll just adapt Ngaro. If I stay compatible, retro will of course just bolt on.
10:03:53 <lukeparrish> Reading the Ngaro docs... Pretty nifty.
10:04:34 <sixforty> I'm thinking I'll have to use blank, instead.
10:05:05 <lukeparrish> What does the blank do?
10:05:27 <sixforty> http://unefunge.republika.pl/
10:05:59 <sixforty> It's just a tiny programming language. I'll need tiny.
10:07:12 <sixforty> I will include a small forth, perhaps retro, as a higher level language after the machines are built.
10:09:26 <lukeparrish> It can be easy to lose track of what you're doing in a small language like Blank or BF.
10:10:37 <sixforty> If I use blank, I'll add the ability to define words.
10:10:46 <sixforty> That'll make it more 'trackable'.
10:11:04 <sixforty> So, really, I'll just end up with a smaller forth.
10:15:33 <virl> when you need a forth for bootstrapping there is bootforth! (just being a bit funny)
10:16:10 <lukeparrish> :P
10:16:40 <sixforty> bootforth?
10:17:36 <lukeparrish> Kinda of neat how Ngaro has only 31 instructions and 13 ports to remember.
10:18:15 <sixforty> I'll have to look deeper into the ports. They may provide a way to do what I intend.
10:18:45 <sixforty> 31's a lot of instructions to load by dipswitch, tho :P
10:22:28 <lukeparrish> Hmm, not sure how that would work. Perhaps you could start with a subset of them, and load the rest from a storage medium.
10:23:58 <sixforty> Heh. Of course, that's the way it works, In order to KISS, I just try to stay within what could be done dipswitch-pushbutton, or maybe copy con.
10:25:07 <sixforty> The idea is for new hardware bootstrap to be extremely easy, attractive, and fun.
10:26:05 <sixforty> Though I'm doing this for my own use, it wouldn't be bad coming up with a public domain driver interface that hw manufacturers would be drawn to.
10:26:48 <lukeparrish> Well, we all want to be attractive :P
10:27:08 <sixforty> I've given up, myself.
10:28:32 <sixforty> When I got this comp, I wanted to just load Ubuntu and use the comp, not worrying about what I don't like.
10:28:53 <sixforty> Apparently, I'm missing the acceptance gene. :)
10:29:31 <lukeparrish> well the standard approach is to use lilo or grub to load the linux kernel, then use that to load your ubuntu stuff...
10:30:14 <lukeparrish> All of which is probably tremendously bloated and sub-ideal, but which actually works to do what you want :P
10:30:25 <sixforty> Ubuntu is running; quite well, if one likes linux.
10:30:41 * sixforty points back to the 'acceptance' thing.
10:30:51 <lukeparrish> yeah
10:32:01 <sixforty> I really wanna let 'the Ubuntu community' take care of me and just get on with life, but I just can't.
10:32:13 <lukeparrish> it would be interesting to see a linux architecture built on top of something as simple as ngaro
10:32:32 <sixforty> Kudos to 'em for a better system than I thought possible given their conditions, tho.
10:35:14 <lukeparrish> C isn't as bad as it looks...
10:35:21 <sixforty> I'd like to compile a linux using retro/ngaro, but splicing them together seems a waste.
10:35:39 <sixforty> "C"? Correct. C++ is another matter.
10:35:56 <lukeparrish> C++ is as bad as it looks?
10:36:30 <sixforty> or at least as bad as C looks
10:36:38 <lukeparrish> hehe
10:37:12 <lukeparrish> yet a lot gets done in C++
10:39:46 <lukeparrish> well, linux is still largely C
10:40:29 <sixforty> looks like there's not really a linux anymore. It's all gnu and deb.
10:43:16 <lukeparrish> I like the layered approach of the latest retro...
10:43:29 <lukeparrish> ( retro ( ngaro ) )
10:43:49 <lukeparrish> you could put another layer around it for kernel-like functions
10:44:12 <sixforty> It's moving too fast for me to learn it. I like active, but jeesh . . .
10:44:17 <lukeparrish> ( kernel ( retro ( ngaro ) ) )
10:44:34 <sixforty> 'layered' is attractive for my purposes, tho
10:44:49 <lukeparrish> the retro of last year or so was made all in fasm
10:45:14 <lukeparrish> ngaro is basically a factoring out of some of the lower-level stuff 
10:45:22 <sixforty> and I was pretty much decided on blank. Thanks soooo-ooo much for diverting me :P
10:46:40 <sixforty> choices, choices
10:47:33 <lukeparrish> :)
10:49:22 <sixforty> 'The Ngaro driver framework for linux' (*.bsd,plan9,win32 . . .). Hmmm.....
10:50:19 <sixforty> Many manufacturers looked at a forth for a long time. Some of the win drivers may indeed be forth-based.
10:52:27 <sixforty> Comparitively, one couldn't spot ngaro in a linux kernel with both hands, hunting dogs, and an electron microscope. If you didn't want it, you wouldn't notice it anyway :)
10:53:03 <lukeparrish> Yup :)
10:54:02 <sixforty> Linuxpeople would insist on getting drivers onto ngaro, thus retro would have access to most any new hardware.
10:56:48 <lukeparrish> I wonder if writing a bootloader in ngaro/retro would be a good way to get it started into the linux mainstream.
10:57:29 <lukeparrish> A bootloader is comparatively small, but very important.
10:58:16 <sixforty> Don't think so. And my only reason for wanting to get into linux is to make hardware available.
10:58:51 <sixforty> I'd like to see linux continue, and also to have truly separate, viable alternatives.
10:59:49 <sixforty> I don't think another bootloader would be accepted because deb is married to their own rules for such things, as it should be.
11:02:33 <lukeparrish> Perhaps.
11:02:34 <sixforty> On the other hand, nifty, unique userspace retro apps that appeal to linux users would be a good thing. It was wise to make retro available inside linux.
11:03:26 <sixforty> There is a desire to replace gnome, KDE, etc, with something lighter. Retro can run inside and outside X.
11:04:02 <lukeparrish> Yeah. You can wrap your applications with an image of retro if you want them to be stand-alone... I've used this approach with Tcl/Tk (freewrap)
11:05:27 <sixforty> Right, but because of mobile devices, maybe the program should detect if a valid retro wrapper has already been loaded. You could load one wrapper instead of three or four.
11:06:26 <sixforty> Over time, the PC will fade because of physical size, if nothing else.
11:06:28 <lukeparrish> True. But that can lead to issues.
11:06:52 <lukeparrish> Well, computing power is still increasing per unit size.
11:06:55 <sixforty> Yes, it can lead to issues. 
11:07:38 <sixforty> But the user's computing power remains stable, due to software bloat.
11:08:05 <lukeparrish> If you distribute an app that depends on something outside what you distribute it with, it creates a dependency. If the next version of whatever that is is a little bit different, it might break it (even if attempting to be backwards-compatable).
11:08:16 <sixforty> Compare boot times of a 50mhz pentium and its original OS with that of a new machine. Similar, no?
11:08:38 <lukeparrish> Also, in the long run you have a lot of bloat caused by attempts to maintain backwards-compatibility
11:08:53 <lukeparrish> too true
11:09:08 <sixforty> yep. Strong considerations to be sure. I'd like to look into it anyway, tho.
11:10:44 <lukeparrish> Static vs. dynamic linking of libraries is not a new issue, of course... There's advantages and disadvantages to both approaches.
11:17:53 <lukeparrish> Maybe a system where the version of the wrapper can be easily set by the user would be ideal. When the same version is being in use by two programs, the extra copy can be deleted.
11:19:20 <sixforty> I was thinking of new versions being more forward-looking and having a longer development cycle . . .
11:20:12 <sixforty> New versions would take a long time, so backward compatibility would only need to be for one additional version.
11:20:57 <sixforty> Only major versions considered, not minors.
11:21:02 <lukeparrish> Probably a good idea
11:21:29 <sixforty> But then if that were the case, that would argue for an installed interpreter or library rather than a wrapper.
11:22:35 <lukeparrish> You could have a wrapper that is deleted if the main installed interpreter/library is identical.
11:23:04 <sixforty> "Depends on mylib 2 or mylib3 (suggested)" is not so bad if mylib 2 has been stable for 3 years and mylib 3 will go for 3 more.
11:23:54 <lukeparrish> Of course, an iron-clad, consistent versioning system is desirable if you're going to automate anything to do with dependencies..
11:25:47 <sixforty> An iron-clad long-term version obviates a versioning system and automated dependencies.
11:26:17 <sixforty> Which, right now, rules out Retro.
11:26:31 <sixforty> Retro's nothing if not active right now.
11:27:06 <lukeparrish> If my old text editor hasn't been updated in 10 years, but my new web browser is cutting-edge, I might want to use different interpreters for the two...
11:27:36 <sixforty> The big problem with my idea is the constantly moving target of file, hardware, and protocol specifications.
11:28:36 <sixforty> A long-term interpreter or library would have to be capable of new, yet-unknown protocols.
11:29:41 <sixforty> Applications themselves would carry more of the burden of adaptation; many adaptations would be duplicated by several apps.
11:29:47 <sixforty> There's the cost of my approach.
11:30:42 --- nick: sixforty -> sixforty_
11:31:16 <sixforty_> Truly interesting conversation, but I've also been trying to shave for the past hour and a half :D
11:31:40 <lukeparrish> :P
11:45:36 <sixforty_> know what tool I need to read .epub on PC linux?
11:49:33 <lukeparrish> I have no idea
11:53:26 <lukeparrish> http://www.fbreader.org/ maybe
11:53:38 <sixforty_> now testing same
12:00:28 <sixforty_> Ubuntu has fbreader in synaptic. Almost ready for prime time, but not quite. On the other hand, once I finish shaving (next year, I think) I'll look through retro sw for a reader.
12:00:54 <sixforty_> Charles published the manual in epub, so just maybe he's writing a reader.
12:01:10 <lukeparrish> isn't there a pdf of the same thing?
12:01:38 <sixforty_> Yeah. I'm not fond of my pdf reader, but right now it beats fbreader.
12:11:04 <sixforty_> hmm . . . the domain thisforth.com is in its redemption period
12:11:23 <sixforty_> thisforth.*others are not registered
12:12:29 <sixforty_> myforth.* are available, but I wouldn't want to get confused with the actual forth 'myforth'
12:15:39 <sixforty_> There's also a 1995 'thisforth', but it's inactive and is a bad name for a forth, IMO.
12:27:19 <lukeparrish> hmm
12:27:31 <lukeparrish> looking to start a site for your new forth-os?
12:29:34 <sixforty_> Heh. Don't want the headache of actual users just yet! It'd just be good to keep this domain available to forth implementers, especially of the non-standard variety, thus 'thisforth'.
12:32:51 <lukeparrish> probably a good idea
12:35:10 <sixforty_> What's that? Didn't I just hear lukeparrish volunteer to be webmaster?
12:35:38 <lukeparrish> ummmmm
12:38:44 <sixforty_> you said a mouthful
12:40:32 <lukeparrish> what did I say?
12:43:01 <sixforty_> I believe it was 'I don't think so', but I could be wrong :P
12:55:00 <lukeparrish> could be :P
12:58:57 <lukeparrish> a while back I was working with thinfu on the idea of a mud in retroforth
12:59:53 <lukeparrish> we had a set of linux syscalls that would do some of the basic socket interactions
13:00:20 <lukeparrish> of course, that is potentially useful for a variety of things, not just MUD servers
13:00:43 <sixforty_> Interesting. Please continue without prompting, as I'm still busy elsewhere; I will read it.
13:00:46 <lukeparrish> I wonder how to get networking to work in Retro 10
13:00:54 <lukeparrish> 'sok
13:01:49 <lukeparrish> for one thing, I'd like to see it generalized to be more cross-platform
13:02:17 <lukeparrish> for another, the select function that was being used appeared to be really ugly to me
13:04:20 <lukeparrish> your suggestion that there be a network-node style of drivers is interesting. I'm not really as up on the complexities of how networks are implemented... I tend to think it could be simpler than it currently is.
13:17:42 --- quit: lukeparrish (Read error: 104 (Connection reset by peer))
13:20:57 --- join: lukeparrish (n=opera@74-36-0-167.dr01.hmdl.id.frontiernet.net) joined #retro
13:34:52 <sixforty_> Rather than pseudo-network hardware, why not define ngaro's port 31 to 'attach new port'? Newly attached ports would be numbered starting at 100 or 1000 and are user- or API-definable.
13:35:39 <sixforty_> Outputting a given opcode to 31 would attach, another would detach.
13:36:54 <sixforty_> comms of various types (ip,ppp,tcp,myproto . . . ) would be added this way
13:38:41 <sixforty_> ip written in retro would be attached via 31 to port 1234, to be used by retro
13:39:44 <sixforty_> thus hardware and protocols could remain basically external and interchangeable, leaving the base system alone.
13:40:09 <sixforty_> s/interchangeable/replaceable
13:41:26 <sixforty_> for faster ip use, a machine-specific version could be implemented as time permits
13:42:23 <lukeparrish> cool
13:43:13 <sixforty_> there are drawbacks, but right now I don't see an option nearly as good
13:47:08 <sixforty_> if you want something like ip>http>html>decode>'call' addons(java)>render>present and, of course, its reverse, the ports would have to have ports
13:47:53 <sixforty_> Well, not have to, but otherwise the core would have to mediate, prioritize, and process.
13:55:09 <lukeparrish> hmm
14:00:44 <lukeparrish> I'm still not sure I understand how all this works.
14:01:04 <lukeparrish> Sockets are a way of transferring data from one system to another, basically
14:01:14 <sixforty_> surely you haven't assumed I know!
14:01:38 <lukeparrish> They use "file descriptors" to tell where the stuff goes...
14:01:54 * lukeparrish thinks really hard.
14:02:27 <sixforty_> right, and remember that I'm looking for keyboard=system, mouse=system, and for that matter, thisfile=system
14:02:28 <lukeparrish> Also there's something to do with pipes... I guess those are a form of socket.
14:02:47 <lukeparrish> Ok.
14:03:08 <sixforty_> one 'system' drops out, another can take its place. distributed to the nth.
14:03:17 <lukeparrish> Pipes are sockets from one program to another, I guess.
14:04:02 <lukeparrish> Right.
14:05:12 <sixforty_> there is a large cost to this, but larger systems can combine several of the 'systems' in a more permanent way
14:06:16 <lukeparrish> aka devices
14:07:28 <sixforty_> come to think of it, they'd be combined naturally, with no intervention. They'd simply not detach due to such matters as low resources on larger systems.
14:08:11 <sixforty_> a machine running out of resources would look for another to handle some load. If it's not running out, it doesn't go looking.
14:08:31 <lukeparrish> The systems are essentially nested within larger systems?
14:08:49 <lukeparrish> ( bigsys ( smallsys1 smallsys2 )
14:09:21 <sixforty_> Yes, but once attached, it's all bigsys until something happens to change that.
14:09:49 <lukeparrish> ftp, telnet, and web are all subsets of tcp/ip
14:10:20 <lukeparrish> tcp/ip just opens a pipe from one computer on a network to another
14:10:34 <lukeparrish> what is done with that is up to the server/client programs
14:11:10 <sixforty_> in this model, as far as the client is concerned, the server is part of the client
14:12:21 <sixforty_> the same as plugging in a new piece of hardware
14:13:24 <lukeparrish> not sure I follow you
14:14:00 <sixforty_> the host system sees the server simply as another attachment
14:14:29 <sixforty_> somewhat like plan 9's 'everything is a file', but different
14:14:47 <lukeparrish> ok
14:17:03 <sixforty_> but rather than file=subdir/subdir/subdir/file, it's file=subdir+subdir+subdir+file or even file0=file1+file2 . . ., can even include an original file0
14:18:51 <sixforty_> it's actually a simple process, but requires complicated editor/IDE
14:19:48 <lukeparrish> hmm
14:19:57 <lukeparrish> is this your file storage system?
14:20:12 <sixforty_> nope. that's another matter entirely
14:20:15 <lukeparrish> ok
14:21:45 <lukeparrish> we're basically trying to create a simple interface for data transfer, right?
14:21:49 <sixforty_> the IDE will have to emulate possiblities while the code is being written. Tall order, but otherwise humans couldn't code for it
14:22:07 <lukeparrish> hmm
14:22:53 <lukeparrish> you want all the various steps happening out in the open, as you type?
14:23:00 <sixforty_> right
14:23:09 <lukeparrish> ok, gotcha
14:23:29 <lukeparrish> that's an intriguing possibility, particularly from an educational perspective
14:23:47 <lukeparrish> there's so much that happens in a computer that people never see, and thus don't understand
14:24:09 <sixforty_> though I wouldn't be looking at all the possibilities, only the ones the IDE determined might be problematic or otherwise interesting
14:25:12 <sixforty_> '. . . IDE determined . . .': a 'thinking' IDE. Hmmmm
14:25:16 <lukeparrish> Well, forth is basically it's own IDE
14:25:59 <sixforty_> gotta go for a few, bbs
14:26:11 --- quit: sixforty_ ("Leaving.")
14:26:12 <lukeparrish> ok
14:38:42 --- quit: neceve (Read error: 104 (Connection reset by peer))
17:36:43 --- join: nighty__ (n=nighty@210.188.173.245) joined #retro
23:59:59 --- log: ended retro/08.11.09