00:00:00 --- log: started forth/04.05.13
00:57:58 --- join: Callidus (austin@68.224.170.60) joined #forth
02:47:21 --- join: crc (~Charles_C@0-1pool176-9.nas6.philadelphia1.pa.us.da.qwest.net) joined #forth
03:59:23 --- join: qFox (C00K13S@cp12172-a.roose1.nb.home.nl) joined #forth
04:14:59 --- part: gl left #forth
04:15:01 --- join: gl (~foo@risc.opcode.org) joined #forth
04:15:04 --- quit: gl (Remote closed the connection)
04:16:44 --- join: gl (~foo@opcode.org) joined #forth
04:41:21 --- quit: crc ("ChatZilla 0.9.61 [Mozilla rv:1.7b/20040316]")
05:40:56 --- join: Serg (~z@212.34.52.140) joined #forth
06:58:37 --- quit: Serg ()
08:21:47 --- join: fridge (~Jim@CommSecureAustPtyLtd.sb1.optus.net.au) joined #forth
08:36:01 <Herkamire> everybody should read this: http://moglen.law.columbia.edu/publications/anarchism.html
08:42:32 <lucifer> too bad its too late to patent the turing machine and ban every implementation or derived work :P
08:48:00 --- join: proteusguy (~proteusgu@69.79.24.31) joined #forth
09:35:47 <SDO> anyone here familiar with PROM burning, and in particular the Sailer 8 burner?
09:36:22 <SDO> I have one, and don't have software for it, or know how to use it.  My unit powers up, and I want to try and use it with either PC, Mac, Apple ][ hardware to send a PROM image to the device, and then burn some PROMs.
09:37:14 <SDO> btw, that is Sailor
09:37:15 <SDO> :)
11:32:13 <SDO> ok, this is forth related.
11:32:15 --- part: SDO left #forth
11:32:21 --- join: SDO (~SDO@co-trinidad1a-156.clspco.adelphia.net) joined #forth
11:32:28 <SDO> ok, this is forth related...
11:32:28 <SDO> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=4129590724
11:32:35 <SDO> wow, 240 USD for a forth computer :0
12:00:58 <Herkamire> interesting :) I've never heard of the Jupiter Ace
12:44:27 <warpzero> speaking of which
12:44:38 <warpzero> do we have any estimation on how big kestrel is going to be?
12:56:03 --- quit: AldoBrasil (Read error: 104 (Connection reset by peer))
13:03:24 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth
13:45:07 <fridge> almost my weekend
13:45:09 <fridge> yay
14:00:02 <qFox> Herkamire> is that about what i said a few days back? about how math formula's are free for anyone to use, where-as software isnt, even though they are basicly the same thing
14:00:59 * qFox thinks that website is probably more text then its worth reading
14:01:06 --- quit: proteusguy ("Leaving")
14:02:55 <qFox> sdo> that thing looks cool. i wished i was this age when those things were affordable :p
14:03:14 <qFox> (i'm guessing they are no longer in production... ;)
14:10:33 --- quit: warpzero (Remote closed the connection)
14:13:36 --- join: rsync (~pavel@CPE000c41aac435-CM000a73a75acb.cpe.net.cable.rogers.com) joined #forth
14:15:56 <Robert> Hi
14:19:00 <qFox> Hi
14:19:29 --- quit: lalalim_ (Read error: 60 (Operation timed out))
14:21:18 --- join: lalalim (~lalalim@p508AB108.dip.t-dialin.net) joined #forth
14:24:35 <qFox> hm
14:24:49 <qFox> i downloaded this emulator of that jupiter ace thing
14:25:05 <qFox> and ran it on my laptop (appearantly its anti-XP and my laptop runs 98 ;)
14:25:19 <qFox> but i wonder how hard it is to run forth if your emulator does not accept @ as such... or !
14:25:39 <qFox> ! wipes the screen, @ puts the cursor into a blinking C
14:25:45 <qFox> not quite sure what that means
14:34:06 <rsync> zen!
14:36:08 <qFox> not quite what i had in mind... :p
15:03:44 --- join: blockhead (default@dialin-662-tnt.nyc.bestweb.net) joined #forth
15:07:10 --- quit: fridge ("Leaving")
15:26:02 --- join: Sonarman (~matt@adsl-64-160-165-182.dsl.snfc21.pacbell.net) joined #forth
15:26:29 <blockhead> hi Sonarman
15:26:48 <Sonarman> hey blocky
15:27:28 <blockhead> wass up?
15:28:02 <Sonarman> ah. nothing
15:28:29 <blockhead> nothing here either
15:46:42 <SDO> qFox, yah that forth PC is kinda cool, wish I could afford or find one cheap.
15:46:51 <SDO> would be neat to turn on a computer and have a prompt for forth programming.
15:47:06 <SDO> Now I just script Linux to bring an xterm up and start forth for me :)  hehehe, but not quite the same.
15:54:31 --- quit: blockhead (Remote closed the connection)
15:58:52 --- join: fridge (~fridge@dsl-203-113-230-80.NSW.netspace.net.au) joined #forth
16:16:23 <qFox> :)
16:18:30 <futhin> j00 f00z!
16:18:54 <futhin> WH3R3 IZ KC5TJA!
16:22:55 <Sonarman> UP YORS N00B
16:28:41 <futhin> WH4T! S0M30N3 D4R3Z CH4LL3NG3 M3!?
16:29:40 <Sonarman> sorry forgive me oh great one please
16:29:42 <futhin> J00 H4V3 N07 S33N D4 P0W4RZ 0F D4 L33T3ZT SCR1P7 K1DD13 J00LL 3V4H S33
16:29:57 <Sonarman> omg hax?!? GIBB ME SUM PLZ!111`1111
16:30:03 <futhin> H3H3H3H3H
16:31:17 <futhin> N0W 3Y3 G0 H4V3 4 P00!
16:31:22 <fridge> futhin, I'd imagine he's working really hard at his new job
16:31:45 <futhin> ph33333333r
16:32:50 --- join: blockhead (default@dialin-622-tnt.nyc.bestweb.net) joined #forth
16:37:44 <futhin> fridge: whats the new job
16:42:26 <fridge> 2http://www.falvotech.com/weblog/pivot/entry.php?id=14
16:43:00 <fridge> not sure what he's actually doing
16:46:51 <qFox> futhin> you wouldnt actually be Ting, would you? :\
16:47:54 <qFox> and um, how do you use things like CONSTANT when defining words (so in compilingmode) ?
16:48:18 <qFox> because its always complaining it needs a NAME to create, when trying to define such a word
17:24:52 <futhin> i'm not ting
17:27:12 <qFox> kay :)
17:51:03 <madgarden_> qFox, huh?
17:51:08 <madgarden_> I don't understand the question.
17:51:39 <qFox> : init.values 
17:51:43 <qFox> 5 constant hi
17:51:46 <qFox> 6 constant there
17:51:48 <qFox> ;
17:52:01 <qFox> wont work like that... how can i get it working?
17:54:56 <blockhead> qFox: I'm not a forth expert but ...
17:55:28 <blockhead> I've always thought of constant as sort of compiling word, like ":" except it compiles a number rather than code.
17:55:51 <blockhead> so why not just put the "5 constant hi" near the top of your program, not inside a ":"?
17:55:59 <qFox> hm, but i must be able to define a variable inside a word?
17:56:15 <blockhead> wait: you said variable
17:56:20 <blockhead> different than constant
17:56:36 <qFox> well in this case i need the constant, but same goes for variable
17:56:37 <blockhead> constant is deisgned to not change
17:56:45 <qFox> create <name> 5 allot
17:56:49 <qFox> will not work either, same error
17:57:05 <qFox> it kinda clashes with the input checker i believe
17:57:14 <qFox> like getting the name for the variable/constant to create
17:58:40 <blockhead> I think you are getting into "CREATE" & "DOES>" territory.  I have trouble with those so I can't really say any more
17:59:20 <qFox> heh ok
17:59:27 <qFox> anyone else? :)
17:59:53 <qFox> i find it kind of hard to believe you cant define variables/constants inside words
18:00:35 <blockhead> you can, but it's beyond my forth skills :/
18:00:48 <qFox> i would add [ ] around it, but that kind of defies the purpose, because it would init the vars when compiling
18:00:59 <qFox> mine too... for now
18:01:01 <qFox> :)
18:10:44 <qFox> nite
18:10:46 --- quit: qFox ("this is mirc's last attempt of communication...")
18:21:34 <madgarden_> OK, qFox...
18:22:00 <madgarden_> Defining a constant inside of a word is the same as defining a word inside of a word. It's a bit of a no-no.
18:22:27 <madgarden_> Mainly because there is only one currently compiling word.
18:22:38 <madgarden_> Gah.
18:22:53 <madgarden_> I ALWAYS frickin' talk to qFox after he leaves, for some reason.
18:23:12 <blockhead> madgarden_: that's what I thought ... but I wasn't sure
18:23:29 <blockhead> :)
18:23:58 <blockhead> I htink you have to do BULD DOES or CREAT DOES to make a defining word, but I get hazy at this part
18:24:10 <madgarden_> And really, there's no reason to nest word definitions, at all.
18:24:31 <madgarden_> Well yea, you call CREATE from your definition... ie.
18:24:42 <madgarden_> : CONSTANT CREATE , DOES> @ ;
18:24:55 <madgarden_> ...is how you'd define CONSTANT that way.
18:25:11 <madgarden_> But, if I was to do...
18:25:30 <madgarden_> : BLAH [ CREATE FOO ] ... ;
18:25:49 <madgarden_> Then the call to CREATE should probably cause an exception, or an ambiguous condition.
18:26:37 <madgarden_> Or at least, you need to know what the hell you're doing in such a case, because it won't work as you expect a nested definition to work.
18:26:53 <madgarden_> I'm sure it quite depends on the Forth. I don't allow nested definitions in mine.
19:41:13 --- join: warpzero (~warpzero@199.104.115.142) joined #forth
19:49:51 --- join: kc5tja (~kc5tja@66-74-218-202.san.rr.com) joined #forth
19:50:00 --- mode: ChanServ set +o kc5tja
19:50:14 <blockhead> yo kc5tja
19:50:16 <blockhead> wassup?
19:50:28 <kc5tja> Nothing much.
19:51:08 <kc5tja> I am thinking of backing out of that software development project I took on.
19:51:13 <kc5tja> It's not fun for me anymore.
19:51:24 <blockhead> kestral?
19:51:27 <kc5tja> And I feel that I'm not making sufficient progress on it to justify his continued payments to me.
19:51:31 <kc5tja> No.
19:51:38 <kc5tja> Since when is Kestrel someone *else's* project?  :)
19:51:41 <blockhead> oh
19:51:56 <kc5tja> And besides, it's not a software project.  It's hardware.
19:52:01 <blockhead> hey kc5tja, what the fjck do I know?
19:52:05 <blockhead> :D
19:52:08 <kc5tja> Hehe
19:52:22 <kc5tja> Which is why Kestrel is so much more fun.  Hardware is tangible and hackable.
19:52:36 <blockhead> forget "fun": this is income.  can you force yourself and finish it?
19:52:44 <kc5tja> Not even.
19:52:51 <kc5tja> The project scope is WAY beyond my current set of skills.
19:52:56 <kc5tja> I can with outside help.
19:52:57 <kc5tja> But that's it.
19:53:11 <blockhead> subcontact.  worthwhile
19:53:11 <blockhead> ?
19:53:16 <blockhead> contract, I mean
19:53:17 <kc5tja> Too expensive.
19:53:22 <kc5tja> I'm *only* paid $16/hr for the work.
19:53:42 <blockhead> bummage
19:53:51 <kc5tja> And with me taking on a full-time position in the coming week or so, there'll be absolutely no time what-so-ever to work on his project.
19:54:16 <blockhead> ah!  you have a tangible good reason for backing out
19:54:28 <blockhead> ixnay on the unfay when you talk to your client, ok  ;)
19:54:38 <kc5tja> What?
19:54:51 <blockhead> let me restate
19:55:22 <blockhead> when you talk to your client.  don't tell him the project is no longer fun.  tell him that due to your new full time employment, you can no longer find time to finsih it.
19:55:42 <blockhead> or am I just belaboring the obvious?  :D
19:56:42 <blockhead> the idea here is when you back out of a project now, you don't piss them off.  cause you might want to do a differeent project for them a few years down the road
19:57:43 <blockhead> ("them", being the client who comissioned the project, BTW)
19:57:59 <blockhead> or am I just belaboring the obvious more?  :D  I'll stop now  :D  really
19:58:42 <kc5tja> No, frankly, I don't think I want to work with this guy any more.
19:58:46 <kc5tja> He's cool and all, and really fun.
19:59:05 <kc5tja> But, he's a hard-noser.
19:59:15 <kc5tja> And a conniver too.
19:59:22 * kc5tja wants to put my energy into Kestrel, not his project.
19:59:52 <kc5tja> At least with the Kestrel, I don't have a set schedule looming over my head, and since I work at home, I'm constantly distracted there anyway.
20:01:01 <blockhead> 'k
20:01:55 <kc5tja> I'm also researching things called "object capabilites" and cache kernels too.
20:02:17 * kc5tja previously stated that the FTS/Forth implementation for the PC would likely sit on an exokernel (or, at least, FTS/Forth would be used to implement such).
20:02:36 <kc5tja> Now, however, I'm thinking a cache kernel should be used, one which relies on capabilities to enforce system security.
20:03:31 <kc5tja> A quick summary of what an object capability is: a capability is a reference to an object that is combined with an authority to do something with it.
20:03:50 <kc5tja> Imagine a simple pointer to a File object (e.g., in C, this might be a FILE *).
20:04:24 <kc5tja> This is, being a pointer, a real "capability" in the sense that you have access to a file (e.g., you can name it) and you have the authority to do whatever you want with it (read, write, seek, close it, etc).
20:05:18 <kc5tja> However, object capabilities bundle only one authority per capability.  So if I have a file "foo", and you want to read and write to it, you would need *two* capabilities: one which points to foo AND provides the read interface, and one which points to foo AND which provides the write interface.
20:06:10 <blockhead> so you could have a user that only has read access to a file? (for example)
20:06:32 <kc5tja> It turns out that, as long as the actual guts of the capabilities are kept in kernel-space (or, more generally, somewhere away from untrusted code in general), this is all that is necessary to implement a secure computing environment, without need for users, without need for access control lists, and without need for a dedicated "system administrator" account.
20:06:48 <blockhead> cool!
20:06:52 <kc5tja> Yes.  Very.  :D
20:06:54 * blockhead likes simplicity
20:06:59 <blockhead> I can't do it, but I like it  :D
20:07:12 <kc5tja> And capabilites are *SO* much simpler to implement at the kernel level than traditional Unix-style ACLs too.
20:07:44 <blockhead> feh on unix: that is a relic from the days when computers used tape drives and filled a room  :D
20:07:46 <kc5tja> The best place to learn about capabilities and their implications is http://www.erights.org
20:07:58 <kc5tja> Yeah, well, so are object capabilities!!
20:08:10 <blockhead> kc5tja: I trust there are no nasty patens on capabilties?  :)
20:08:14 <blockhead> patents
20:08:15 <kc5tja> Capabilities came directly from the inadequacies of ACL-based security.
20:08:20 <kc5tja> Nope.
20:08:21 <kc5tja> None.
20:08:31 <blockhead> good.  patents can be a pain
20:08:41 <kc5tja> Especially since the E language, which relies extensively on object capabilities, is an open source project.
20:08:53 <kc5tja> If patents did exist, they have since expired.
20:09:04 <blockhead> dang: I wonder if that is the same "e" language they used to have on the amiga
20:09:13 <kc5tja> No.
20:09:25 <blockhead> sure :)
20:09:33 <blockhead> could be the same guy, porting it
20:09:44 <kc5tja> E (the capability-based, distributed scripting language) is built on top of the Java virtual machine (but NOT on top of Java itself, though it can invoke Java libraries).
20:09:48 <kc5tja> nope.
20:09:52 <blockhead> ok.
20:09:52 <kc5tja> Totally different people.
20:10:01 * blockhead gets it, finally  :/
20:10:03 <kc5tja> I would have recognized Wouter's name instantly if he was involved.  :)
20:10:21 <blockhead> didn't know if you knew about wouter or not  :D
20:10:31 <kc5tja> Wouter has an interesting language of his own, for the new Amiga platform, but I'm not sure where it's going or how far it's gone so far.
20:10:38 <blockhead> he wrote the False language.  That was a fun language
20:10:41 <kc5tja> Yes, I worked with him when I worked for Amiga, Inc.
20:10:48 <blockhead> DUDE!
20:10:55 <blockhead> you worked for Amiga inc?
20:11:00 <kc5tja> Yeah.  :)
20:11:05 <blockhead> dang
20:11:24 <kc5tja> This is why Dolphin can't have an Amiga-like UI.  :/  That's OK, though -- GEM *rocks* Intuition left and right, but it needs some serious face lifting.
20:11:36 <kc5tja> (and some serious performance enhancements inside the AES)
20:12:38 <blockhead> so you probably know more about the miggy than I do even though I owned one for years  :D
20:12:47 <kc5tja> Heh, I still have my 500.  :)
20:12:57 <kc5tja> My monitor has a busted power switch though.  :(
20:13:00 <warpzero> kc5tja: my language uses a /strict/ object heirarchy :) for exactly the reasons stated above
20:13:15 <blockhead> that tends to happen (power switch)
20:13:25 <blockhead> my old 1084 has the same problem
20:13:35 <kc5tja> Oh, and the expansion port is flakey.  It'll spuriously Guru if I even touch the computer in certain spots.  Amy is "sensitive."  :D
20:13:45 <blockhead> no: wait, it's the rgb/composite mode switch on mine.  :)
20:13:46 <kc5tja> blockhead: 1084S for me.
20:14:01 <kc5tja> warpzero: Strict hierarchies are inadequate.
20:14:04 <blockhead> not the power swtich - my mistake
20:14:39 <warpzero> kc5tja: well the objects above the untrusted ones have to be sane
20:14:52 <kc5tja> I've been thinking of taking my monitor apart and replacing the switch with a cheap, simple 250V toggle switch monster from Radio Shack.
20:15:42 <kc5tja> warpzero: Strict encapsulation is inadequate for describing complex inter-object relationships.  For example, a list of Book objects ought not to know anything about Books.  In fact, it shouldn't even care.
20:16:03 <warpzero> kc5tja: explain
20:16:10 <kc5tja> It needs no further explanation.
20:16:11 <kc5tja> A list is a list.
20:16:13 <kc5tja> Nothing more.
20:16:40 <warpzero> yeah, so?
20:16:42 <kc5tja> There is no reason for me to have to sub-class List to create a BookList, a CDList, a ...
20:16:54 --- quit: tathi ("leaving")
20:17:04 <warpzero> i don't see what this has to do iwth strict encapsulation
20:17:19 <kc5tja> You said your objects exist in a strict hierarchy.
20:17:27 <warpzero> yeah
20:17:29 <warpzero> they do
20:17:30 <kc5tja> That superceding objects have to be trusted (somehow).
20:17:39 <kc5tja> i claim that is not sufficient.
20:17:52 <warpzero> i guess i just don't understand your agument
20:18:12 <kc5tja> A List is a collection of anythings -- it isn't dependent (it is neither superceding nor subceding) to the objects it stores.
20:18:27 <kc5tja> It therefore breaks the strict hierarchy requirement.
20:18:42 <warpzero> hmmm maybe you misunderstand me?
20:18:51 <kc5tja> Perhaps.
20:19:01 <warpzero> in my language that is fine
20:19:39 <warpzero> its just that if a book is in a list its in the list
20:20:11 <kc5tja> I do want to point out, however, that my system is not language dependent.  Capability-based security can be implemented with proper OS infrastructure such that raw, untrusted assembly language (such as what is found in most Forth systems, for example) can be used without performance loss, in a very secure manner.
20:20:31 <warpzero> huh
20:20:38 <warpzero> i don't belive you
20:21:06 <kc5tja> http://www.erights.org -- read it and weep.
20:21:19 <warpzero> or at the very least it forces us to rely on the cpu's VM system for security
20:21:30 <kc5tja> KeyKOS, EROS, and many other operating systems designed to run in mission critical applications are long-standing evidence of the viability of capabilities.
20:21:55 <kc5tja> What?  Are you objecting to two totally different things?
20:22:04 <kc5tja> The E language does not make any such reliance.
20:22:08 <warpzero> i'm misunderstanding probably
20:22:10 <kc5tja> It is a language-based solution to capabilities.
20:22:18 <kc5tja> *MY* solution *DOES* require an MMU.
20:22:22 <kc5tja> But that doesn't mean it's the ONLY way.
20:22:41 <kc5tja> Moreover, there is nothing inherently bad about using an MMU -- just don't *abuse* it.
20:22:53 <warpzero> if you're in a flat memory space i don't see how you do this with assembly
20:23:19 <kc5tja> Ummmmmmmm............I did very, very, very clearly state that in *MY* system it *DOES* require MMU assistance.  :-)
20:23:32 <kc5tja> Because in *MY* system, I do *NOT* rely on a language-based solution.
20:23:32 <warpzero> okay well thats fine then i guess
20:23:36 <kc5tja> :-)
20:23:45 <warpzero> i think my solution is languaged based
20:24:11 <kc5tja> Yes, it sounds like it.
20:24:37 * kc5tja prefers not to rely on language-based environments whenever possible.  I mean, it's nice to have, but I try to avoid a dependency.
20:25:18 <kc5tja> Anyway, that's what I've been researching of late, and I'm thinking of re-engineering Dolphin 0.5 around the use of object capabilities.
20:25:24 <kc5tja> Oh, and a cache kernel instead of an exokernel.
20:25:37 <warpzero> hmm my language looks like its quite like E
20:26:39 <warpzero> in the security aspect i mean
20:28:53 * kc5tja is thinking of building some sample capability environments based on GCOM (my freeware component object model clone).
20:29:14 <warpzero> so hey whats the status on kestrel?
20:29:14 <kc5tja> Which reminds me, I need to get GCOM compiling again so I can post it on my site.
20:29:34 <kc5tja> Current status is the instruction set for the new CPU is solidified, and documented on the website.
20:29:44 <warpzero> cool
20:29:52 * warpzero is sick to his stomach
20:29:58 <kc5tja> I have yet to investigate the implications it has on Kestrel's system architecture though.
20:29:58 <warpzero> and i am now going to bed
20:30:07 <kc5tja> I took the block diagram off the site because it's no longer valid.
20:30:21 <kc5tja> The new CPU replaces both the old CPU and the FTS1002 K-Bus bridge.
20:30:26 <kc5tja> Ewww...
20:30:28 <kc5tja> good luck.  :(
20:30:32 <kc5tja> I hates nausea.
20:30:48 <blockhead> who *likes* it?  :D
20:30:58 <kc5tja> blockhead: Bolemics and anemics.  :)
20:31:15 <blockhead> ewwwwwwwwww.  you got a point there.  :o
20:35:48 <kc5tja> The idea of creating a completely COM-based, totally secured desktop environment under Linux is very intriguing to me.
20:36:25 <kc5tja> Of course, none of my secure-GCOM-ideas are restricted to COM; they are just as applicable to CORBA or XML-RPC or ...
20:36:57 * kc5tja has been thinking of maintaining amiwm for Linux though.
20:37:08 <kc5tja> Just as an as-time-permits thing though.
20:37:26 <kc5tja> Maybe I can integrate an object capability system in that.  :D
21:01:03 <blockhead> 'night
21:01:11 <kc5tja> Goodnight.
21:01:17 --- quit: blockhead ("laugha while you can, monkey boy")
22:18:43 --- quit: Sonarman ("leaving")
23:31:15 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK")
23:59:59 --- log: ended forth/04.05.13