←2006-12-30 2006-12-31 2007-01-01→ ↑2006 ↑all
00:00:07 <CakeProphet> It's easy to parse, being stack-based... and is pretty capable of doing things despite its erm... verbosity.
00:00:13 <CakeProphet> Speed has never really been a concern of mine.
00:00:37 <oklopol> sure, just the (System)-class to access memory management etc and it would be a nice language for the core
00:01:12 <CakeProphet> !glass {M[m(_o)O!"wheee"(_o)o.?]}
00:01:15 <EgoBot> wheee
00:01:20 <CakeProphet> I'd like to try some orthogonal persistency.
00:01:36 <CakeProphet> plus it looks cool when you do output... like a bunch of confused faces.
00:02:29 <CakeProphet> It's definetely one of the more structure esoteric languages.
00:02:35 <CakeProphet> d
00:04:22 <oklopol> !glass {M[m(_o)0O!"wheee"o.?]}
00:04:32 <oklopol> whoops :D
00:04:38 <oklopol> !glass {M[m(_o)0O!"wheee"1o.?]}
00:04:41 <EgoBot> wheee
00:05:01 <CakeProphet> It seems kind of redundent to do it that way.
00:05:41 <CakeProphet> the ! operation itself saves the object to _o... no use retrieving it from the stack when you have it as a variable.
00:06:09 <oklopol> it was smaller yay \o/
00:08:20 <CakeProphet> hehe... I'd do the kernel in Python myself. :D
00:08:25 <CakeProphet> but that's not very esoteric.
00:09:07 <oklopol> i still don't know what will be the goal for the OS
00:09:18 <CakeProphet> to be esoteric... and try out shit.
00:09:23 <CakeProphet> no real super-huge goal in mind.
00:09:33 <oklopol> to be written in esoteric langs, to run esoteric langs, or both
00:09:50 <CakeProphet> both would be nice.
00:09:52 <oklopol> the middle one is the one i'd use :)
00:09:56 <oklopol> and that
00:10:06 <CakeProphet> Any computer can run esoteric langs.
00:10:16 <CakeProphet> but we want our computer to consist of esolangs. :D
00:10:29 <oklopol> that's what i meant by that
00:11:27 <CakeProphet> we could try out some new OS design concepts... I like what uuu is doing currently.
00:12:01 <oklopol> i read that, basically just realizing no need to separate files and variables
00:12:09 <oklopol> *have
00:12:35 <CakeProphet> I like the functional (and/or object oriented) approach to looking at it.
00:12:36 <oklopol> have i been hit in the head a few times recently? every goddamn sentence is incomplete...
00:13:02 <oklopol> ye, on the other hand, i'd like this one to be the Bf-thing
00:13:28 <CakeProphet> If you treat programs as components that can all be used interchangeably with each other... you have quite a powerful library to work off of.
00:13:49 <oklopol> a-ha?
00:14:07 <CakeProphet> the other goal is to make esolangs into something useful. :D
00:15:24 <oklopol> i'd like to have the Def-BF running OS on my computer
00:15:45 <oklopol> i mean, it exclusively
00:15:48 <oklopol> this one sucks
00:15:52 <CakeProphet> I dunno... I'm starting to reconsider Def-BF :/
00:16:05 <oklopol> okay
00:16:12 <CakeProphet> It's definetely a useful estension to BF... but should it be the entire kernel?
00:16:53 <oklopol> i have an entire system in my mind already, i'd say no
00:17:06 <oklopol> entire kernel written on it or?
00:17:13 <CakeProphet> >.> I kinda don't like the idea of Def-BF using Absolute addresses.
00:17:15 <CakeProphet> Why does it need to do that?
00:17:27 <oklopol> how else would you do functions?
00:17:39 <CakeProphet> ....names?
00:17:58 <oklopol> that would be absolute addressing
00:18:06 <CakeProphet> give them symbolic names that lead to memory addresses.
00:18:16 <oklopol> == absolute addressing
00:18:39 <oklopol> my idea was the names
00:18:39 <CakeProphet> ...by "absolute addressing" I meant requiring the entire numeric memory address to call a function.
00:19:04 <CakeProphet> the names was the original concept... RodgerTheGreat surprised me with memory addresses.
00:19:12 <oklopol> huh? same thing
00:19:18 <CakeProphet> ...
00:19:24 <CakeProphet> It's very different.
00:19:30 <oklopol> except memory addressing keeps the bf
00:19:43 <oklopol> names, and it's only bf by algorithmic slowness
00:19:43 <CakeProphet> "add" is much easier to remember than "0344534"
00:20:03 <oklopol> yes, and i proposed an OS function to ease that up
00:20:29 <CakeProphet> so now you have to remember the Os functions memory address... which changes each use.
00:20:34 <CakeProphet> what's the difference?
00:20:58 <oklopol> you can have names for OS functions
00:21:10 <CakeProphet> If the language requires memory addresses at some point... you will have to use memory addresses at some point.
00:21:16 <oklopol> which are just changed into right function numbers
00:21:44 <oklopol> but, you cannot have names for other than OS functions with the same lookup method
00:21:46 <CakeProphet> How will you call the OS function from within the program without specifying its memory address?
00:22:39 <oklopol> <NAME> can be changed to the address when compiling (compiling as in writing the final program to where it will be used at)
00:22:53 <oklopol> as OS functions can have static addresses
00:23:06 <CakeProphet> what will do this compiling?
00:23:19 <oklopol> programmer
00:23:34 <oklopol> or the compiler if the programmer does a few macros
00:23:47 <CakeProphet> and if you're going to augment the syntax to do that... why not augment the syntax entirely so that it accepts any symbol name.
00:23:55 <oklopol> because
00:23:57 <RodgerTheGreat_> back
00:24:02 <oklopol> it's a totally different thing
00:24:09 <CakeProphet> what I'm saying is... why even bother with detouring around a maleable language spec?
00:24:21 <CakeProphet> when you can just change the language spec?
00:24:38 <oklopol> then why use bf?
00:24:54 <CakeProphet> We're not... we're using functional bf.
00:25:04 <CakeProphet> with callable functions...
00:26:01 <oklopol> don't see why add them, would take away the whole small-set-of-char-that-make-up-a-language idea of brainfuck
00:26:13 <CakeProphet> we want to use bf... but we want some modularity. Having to fiddle with absolute addresses is just more confusing than manuially copy and pasting the code... it doesn't extend the language to have modularity.
00:26:18 <oklopol> when you can easily simulate that with a few OS functions
00:27:01 <oklopol> so... should i use a module at 15 from 189384, i should put 189369 <'s together?
00:27:29 <oklopol> oh
00:27:34 <oklopol> memory jumps okay?
00:27:49 <CakeProphet> that makes it even harder... you have to write a program to spell out the functions string name...and then get the memory address of the OS, call it with those characters... and then call the resulting function... it would be easier to just add the contents of the function manually.
00:27:53 <CakeProphet> there's no point.
00:28:17 <oklopol> eh, now when executing the program
00:28:34 <oklopol> would there be "function insertion" in the codestring or smth?
00:29:00 <CakeProphet> hmmm?
00:29:20 <oklopol> hmm
00:29:23 <oklopol> forget that
00:30:04 <oklopol> but, would the uuu's no files -system be used?
00:30:20 <CakeProphet> The entire point of the functional extension to BF was to make it easier to use for constructing something like an operating system.
00:30:31 <CakeProphet> when you require all the extra work to call a function... it's not really worth it.
00:30:44 <oklopol> but, are you talking about function calls inside one program?
00:30:48 <CakeProphet> we wouldn't use the typical file system... it would be a different model.
00:31:05 <CakeProphet> I'm just talking about function calls.
00:31:10 <oklopol> okay
00:31:21 <oklopol> a program being a normal function?
00:31:35 <CakeProphet> Sure.
00:32:48 <oklopol> but no absolute addresses?
00:32:58 <CakeProphet> Why not just have symbolic names as an embedded functionality to the language... with the underlying compiler handling all the finding-the-absolute-memory-address?
00:33:12 <CakeProphet> there could be a registry of names to absolute addresses built-in to the OS.
00:33:47 <CakeProphet> or is that what you were saying we do?
00:34:11 <CakeProphet> to me it sounded like we should build it over the top of the base language like a weird abstraction... that would require quite a bit of work on the programmers behalf.
00:34:27 <CakeProphet> "to me it sounded like you said we should build..."
00:34:46 <oklopol> (name to look up) <<< would be a sensible syntax for looking up the address of a function to exec
00:35:14 <oklopol> but i guess i'll see the point of making bf more functional at some point
00:35:30 <CakeProphet> RodgerTheGreat_, oh... and hey.
00:35:42 * RodgerTheGreat_ waves
00:35:57 <CakeProphet> we were just busy being confused by each others explainations.
00:36:03 <oklopol> :D
00:36:05 <oklopol> ye
00:36:06 <oklopol> hi, RodgerTheGreat_
00:37:24 <CakeProphet> There should be no difference between a function and a program.
00:37:35 <oklopol> true
00:37:54 <CakeProphet> no need to stuff applications in huge directory paths.
00:38:21 <CakeProphet> just stuff them in a single os-level function (let's call them a blob for distinction)
00:38:41 <oklopol> or, a dictionary :D
00:38:45 <CakeProphet> >.>
00:38:51 <CakeProphet> a dictionary is like a hash table.
00:38:57 <CakeProphet> doesn't describe a program too well.
00:39:04 <oklopol> isn't that what we want?
00:39:10 <oklopol> hmm
00:39:18 <CakeProphet> programs as hash tables?
00:39:21 <oklopol> i mean, isn't it basically a name to address?
00:39:25 <oklopol> nje
00:39:32 <CakeProphet> oh... that's for name-to-address stuff... that's different.
00:39:33 <oklopol> yeah
00:39:48 <CakeProphet> I'm talking about what we're going to do for our new "file system".
00:40:24 <CakeProphet> The name-to-address would just be an orthogonally persistent hash table.
00:40:31 <oklopol> but, wouldn't that make everything use just global variables?
00:40:41 <oklopol> the no-sub-thingies
00:40:54 <GregorR> And what language will you write all this in?
00:41:05 <CakeProphet> Each program would have a scope.
00:41:09 <GregorR> (You'll excuse me if I'm dripping with scepticism)
00:41:13 * RodgerTheGreat_ waves the Def-BF flag
00:41:14 <oklopol> :D
00:41:17 <GregorR> Err, skepticism
00:41:20 <CakeProphet> Get a towel!
00:41:36 <CakeProphet> Possibly def-BF if we don't change our mind.
00:41:42 <RodgerTheGreat_> and I'm somehow unsurprised that gregor is being pessimistic about the project.
00:42:07 <oklopol> it seems it's an OS written in Def-BF running only Def-BF
00:42:10 <CakeProphet> RodgerTheGreat_, Do we have to use absolute memory address in def-bf?
00:42:27 <RodgerTheGreat_> It's going to be a really long haul if we actually want to produce a useable OS in the end
00:42:37 <CakeProphet> I think we might want to reconsider the kernel language though...
00:42:48 <CakeProphet> as ok said... bf isn't terribly efficient.
00:42:56 <CakeProphet> it can be if you do it right.
00:43:57 <RodgerTheGreat_> CakeProphet: it's the best way to do it. In modern operating systems, executables contain absolute addresses which are patched to appropriate values based on where they're loaded as they're loaded into memory
00:44:57 <CakeProphet> Can't we use symbolic names and map them through some kind of startup-generated hash table?
00:45:21 <CakeProphet> why not both?
00:46:29 <RodgerTheGreat_> that's really no different than a runtime patch. There's no need to store data in a clumsy way (strings) when we can do it in an efficient way (addresses). Absolute addresses are more complex to code with, but that's the *entire* point of having a compiler in the first place.
00:46:30 <CakeProphet> If all else fails and we decide BF isn't a good kernel language... we can just make a new more assembly-friendly esolang. :D
00:46:37 <RodgerTheGreat_> heh
00:47:40 <CakeProphet> I wanted the BF extension to be uncumbersome to use on its own instead of a super low-level language... maybe we should split it up into different languages?
00:49:07 <RodgerTheGreat_> that's the point of defining Def-BF as a series of high-level variants and a core low-level standard.
00:50:54 -!- jix_ has quit ("Bitte waehlen Sie eine Beerdigungnachricht").
00:51:33 <CakeProphet> RodgerTheGreat_, But is def-BF doing to be an efficient core langauge?
00:51:56 <RodgerTheGreat_> it ultimately depends on the level of complexity we build into the compiler
00:52:23 <CakeProphet> Maybe we should use an Esoteric Assembly Candy Wrapper Language
00:52:25 <oklopol> but, my example from before, there is no way to even make the compiler understand a simple division
00:52:45 <oklopol> and compile it into efficient machine code
00:53:18 <RodgerTheGreat_> I figured that at the very least, using Def-BF as a singular standard means we can work on optimizing the compiler together and all abstractions of the low-level language will benefit
00:54:39 <CakeProphet> Glass could be an efficient base language.
00:54:42 <RodgerTheGreat_> oklopol: it's true that a simple language like BF is more difficult to compile efficiently than a language with more symbols and keywords. It doesn't make it impossible to compile efficiently, it just requires that your compiler analyzes your code more deeply, resulting in a more complex compiler. It's harder, but possible.
00:55:34 <CakeProphet> It has most of the high-level constructs needed to translate directly to machine code.. and it's easy to extend onto...
00:55:52 <oklopol> well, that's way out of my league, and at that point i naturally say it's impossible :)
00:56:27 <RodgerTheGreat_> heh
00:56:36 <oklopol> "<CakeProphet> It has most of the high-level constructs needed to translate directly to machine code." i don't quite follow
00:56:40 <RodgerTheGreat_> just my suggestion- never claim something
00:56:48 <RodgerTheGreat_> is impossible on #Esoteric. :)
00:56:48 <oklopol> :D
00:57:17 <CakeProphet> well it has a division operator... for example... which could translate directly to the DIV instruction.
00:57:30 <CakeProphet> few esolangs have a division operator. ;)
00:57:41 <oklopol> "<CakeProphet> Glass could be an efficient base language." missed this line
00:57:44 <oklopol> sorry
00:58:16 <CakeProphet> It seems just similar enough to assembly to make a nice translation... while still being freaky as crap.
00:58:21 <CakeProphet> Not to mention it's easy to parse.
00:58:33 <GregorR> Trivial to parse, even ;)
00:58:47 <GregorR> I still don't know what the bork is with A.a X_X
00:59:18 <oklopol> how can it even get bugs without a rebuild?
00:59:30 <oklopol> i mean, worked fine before
00:59:31 <CakeProphet> and the OO gives us a nice organizational structure to easily create higher-level stuff.
01:00:07 <CakeProphet> It's probably the most useful esolang I know. :P
01:00:12 <GregorR> Hah :P
01:00:26 <CakeProphet> the postfix is just a minor setback until you get used to it.
01:00:30 <CakeProphet> then it's strangely intuitive.
01:00:31 <GregorR> Yeah, it's a miserable failure in that sense ;)
01:01:16 <CakeProphet> After a few hours or so I adapted to it.
01:01:52 <RodgerTheGreat_> so, we're veering towards a glass-based kernel, using Def-BF for less critical parts of the system?
01:02:09 <CakeProphet> that's where I'm veering... dunno if it's the consensus.
01:02:24 <CakeProphet> if we have problems with that... we can always just try something different.
01:02:27 <GregorR> If I knew what Def-BF was :P
01:02:38 <oklopol> http://nonlogic.org/dump/text/1167512946.html
01:02:42 <CakeProphet> fortunately we have no deadline to actually finish this thing.
01:02:56 <GregorR> If I got off my lazy bum and finished C2BF, that'd help ;)
01:03:04 <CakeProphet> GregorR, To avoid cringing... you can ignore most of the high-level part... it's not important to the actual language.
01:03:18 <RodgerTheGreat_> pfft
01:03:37 <RodgerTheGreat_> everybody's hating on HLDFBF
01:03:37 <CakeProphet> It's like CBrainfuck! :o
01:03:52 <GregorR> HLDFBF?
01:03:59 <CakeProphet> high-level variant of def-bf
01:04:03 <RodgerTheGreat_> High-Level Def-BF
01:04:18 <GregorR> That's only a sensible shortform if it's High-Level DeF-BF
01:04:29 <CakeProphet> jeje
01:04:55 <RodgerTheGreat_> a 6-letter acronym isn't really a sensible shortform in *any* instance...
01:04:57 <CakeProphet> Out of all the esolangs, Glass seems like one of the better choices for such a crucial role.
01:05:12 <GregorR> Without the high-level stuff, it's sort of like BF + setjmp
01:05:30 <CakeProphet> yeah... it's BF with subroutines.
01:06:27 <RodgerTheGreat_> esentially
01:06:33 <CakeProphet> Plus I'm much much more capable in an OO language than in an impertivive semi-subroutine-al language like def-bf.
01:06:52 <RodgerTheGreat_> I thought it was the simplest addition I could make to BF that would allow functions without too much trouble
01:07:01 <CakeProphet> OO and (real) functional languages are my cup of tea.
01:07:10 * GregorR hands CakeProphet Plof.
01:07:18 <RodgerTheGreat_> heh
01:07:21 <CakeProphet> link?
01:07:29 <GregorR> http://www.codu.org/plof/
01:07:39 <RodgerTheGreat_> hell, we could go with another famous gregor language and write the kernel in ORK.
01:07:51 <GregorR> There is such a thing as a kernel.
01:08:00 <GregorR> A kernel can execute a function.
01:08:05 <GregorR> A kernel can execute a syscall.
01:08:39 <RodgerTheGreat_> lol
01:08:45 <CakeProphet> hahahaha
01:08:46 <CakeProphet> yes... ORK
01:08:59 <CakeProphet> Glass is funkier though... and less tiring to type. :D
01:09:09 <CakeProphet> Plof basically looks like... C.
01:09:12 <RodgerTheGreat_> if ORK can meet the I/O requirements, I'm all for using it to write the kernel.
01:09:19 <GregorR> CakeProphet: Plof isn't esoteric by nature :P
01:09:30 <RodgerTheGreat_> talk about self-documenting code.
01:09:39 <CakeProphet> hahahaha
01:10:00 <CakeProphet> Both maybe?
01:10:18 <CakeProphet> Or do we need a kernel before we can do the inter-language data stuff?
01:10:49 <CakeProphet> I think Ork classes and objects could translates almost trivially into Glass. :D
01:10:56 <oerjan> hmmm...
01:11:18 <GregorR> Glass' classes are a superset of ORK's classes I believe.
01:11:31 <CakeProphet> hahaha... Glass was written in Ork?
01:11:36 <oerjan> !glass {M[m(_o)O!<2><2>~A.a~(_o)o.?]}
01:11:50 <GregorR> I just had a thought about why A.a isn't working ...
01:11:51 <CakeProphet> What's the ~ for?
01:11:59 <oerjan> !glass {M[m(_o)O!<2><2>~A.s~(_o)o.?]}
01:12:03 <GregorR> CakeProphet: It's the secret way of getting builtin functions :P
01:12:07 <GregorR> CakeProphet: You're not supposed to use it X_X
01:12:09 <oerjan> !glass {M[m(_o)O!<2><2>~A.a~(_o)(on).?]}
01:12:13 <EgoBot> 4
01:12:15 <oerjan> hah!
01:12:16 <CakeProphet> ....
01:12:17 <GregorR> ZOMG
01:12:23 * CakeProphet dies.
01:12:38 <CakeProphet> GregorR, You didn't tell me there was a secret!!!
01:12:53 <CakeProphet> ....guess that's why it's a secret?
01:13:02 <GregorR> ARGH
01:13:06 -!- CakeProphet has changed nick to SevenInchBread.
01:13:09 <GregorR> My suspicion was right!
01:13:15 * GregorR bangs his head into a wall
01:13:23 <GregorR> Somebody overwrote the A class in EgoBot, and it cached the borken one :)
01:13:59 <oerjan> aha!
01:14:24 <GregorR> !glass {A[a~A.a~][s~A.s~][m~A.m~][d~A.d~][(mod)~A.mod~][f~A.f~][e~A.e~][(ne)~A.ne~][(lt)~A.lt~][(le)~A.le~][(gt)~A.gt~][(ge)~A.ge~]}{S[l~S.l~][i~S.i~][(si)~S.si~][a~S.a~][d~S.d~][e~S.e~][(ns)~S.ns~][(sn)~S.sn~]}{V[n~V.n~][d~V.d~]}{O[o~O.o~][(on)~O.on~]}{I[l~I.l~][c~I.c~][e~I.e~][n~I.n~]}{(Debug)[(cl)~Debug.cl~][(fl)~Debug.fl~][(fc)~Debug.fc~][s~Debug.s~]}
01:14:27 <EgoBot> OK
01:14:33 <SevenInchBread> ...
01:14:43 <GregorR> !glass {M[m(_o)O!(_a)A!<2><2>(_a)a.?(_o)(on).?]}
01:14:47 <EgoBot> 4
01:14:50 * GregorR takes a bow.
01:15:15 <SevenInchBread> The good thing about esolangs is that they're so simple... translating data from one language into another via some universal OS-centric importing mechanism is easy.
01:15:24 <oklopol> i was that someone! :DDDD
01:15:31 <oklopol> i mean, sorry, very sorry
01:15:35 * GregorR shakes his fist :P
01:15:52 <GregorR> In the future, if any of the builtin classes are broken, grab the standard definition out of builtins.cc (or from what I just pasted)
01:16:31 -!- tgwizard has quit (Remote closed the connection).
01:16:39 <oerjan> this is weird - you mean EgoBot has just one eternally running Glass interpreter? :)
01:16:46 <oklopol> errr.... it's a part of the language to be able to rewrite standard classes? :D
01:17:28 <GregorR> oerjan: No, it reruns it, but the standard interpreter can cache classes if you'd like.
01:17:32 <GregorR> oklopol: Yes.
01:17:51 <oklopol> i mean if i did !glass {A}{S}{M[m]}, my interpretor should no longer have them?
01:17:52 <SevenInchBread> ORK would be awesome... as well as Glass. :D
01:18:00 <GregorR> oklopol: Correct.
01:18:10 <GregorR> oklopol: However, it would only /permanently/ remove them if you used a cache.
01:18:37 <oklopol> what do you mean?
01:18:40 <oklopol> by cache
01:19:00 <GregorR> oklopol: Whenever EgoBot is given a Glass program, it saves all of the classes it was given and reuses them the next time.
01:19:13 <GregorR> So I can use the BF class on EgoBot, since I entered it once a long long time ago.
01:19:21 <oklopol> wow
01:19:24 <oklopol> show it
01:19:46 <GregorR> ... the cache, the BF class, or the BF class in action?
01:20:13 <GregorR> !glass {M{m(_b)(BF)!">+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.>>>++++++++[<++++>-]<.>>>++++++++++[<+++++++++>-]<---.<<<<.+++.------.--------.>>+."(_b)(bf).?]}
01:20:15 <EgoBot> OK
01:20:20 <oklopol> !glass {M["+++."m(_bf)0BF!(run).?]}
01:20:21 <GregorR> Errrm, that was borken a bit :)
01:20:25 <EgoBot> OK
01:20:30 <GregorR> !glass {M[m(_b)(BF)!">+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.>>>++++++++[<++++>-]<.>>>++++++++++[<+++++++++>-]<---.<<<<.+++.------.--------.>>+."(_b)(bf).?]}
01:20:35 <EgoBot> Hello World!
01:20:59 <oklopol> wow cool
01:21:06 <oklopol> can i see the codE?
01:21:44 <GregorR> One sec.
01:22:39 <GregorR> Hm :P
01:22:47 <GregorR> Pastebin! :P
01:25:01 <SevenInchBread> GregorR, Do you have a list constructor?
01:25:04 <SevenInchBread> I was making one myself.
01:25:24 <SevenInchBread> lemme see if egobot still has it.
01:25:28 <GregorR> http://pastebin.ca/297373
01:25:41 <GregorR> I have Arr, which is really a LLL despite being called an Arr[ay] :P
01:26:56 <oklopol> LLL?
01:27:22 <SevenInchBread> !glass {M[m(_o)O!(_c)(Con)! <2><3>(_c)(build).?(cdr).?(_o)o.?]}
01:27:29 <GregorR> oklopol: Linear Linked List
01:27:33 <oklopol> ah
01:28:02 <GregorR> I am apparently the only person on the planet that shortens it to LLL ;)
01:28:18 <SevenInchBread> The syntax for a singleton class in ORK should be "There can be only one <class>"
01:28:24 <SevenInchBread> which would sound cool for building a kernal.
01:28:29 <SevenInchBread> There can be only one kernal...
01:28:42 <GregorR> ORK's compiler is OSS, have at it ;)
01:29:09 <SevenInchBread> What's it written in?
01:29:34 <GregorR> Either C or C++ I'm sure.
01:29:40 <SevenInchBread> Bleh.
01:29:41 <GregorR> (It's been a while since I wrote it ;) )
01:29:47 <GregorR> Glass is in C++ :P
01:29:51 <GregorR> EgoBF is in C ...
01:29:56 <GregorR> EgoBot is in C++
01:29:59 <SevenInchBread> Glass would more readily translate to assembly, methinks.
01:30:07 <SevenInchBread> as far as parsing... and some other things.
01:32:12 <RodgerTheGreat_> bbiab
01:32:20 <SevenInchBread> lol k
01:32:27 <GregorR> Incidentally, who the bork is SevenInchBread?
01:32:35 -!- SevenInchBread has changed nick to CakeProphet.
01:32:39 <GregorR> Ahhhhhhhhhhh
01:32:46 <CakeProphet> My true form is revealed.
01:32:48 <GregorR> You prophesized bread instead of cake then?
01:32:49 <CakeProphet> I have countless nicknames.
01:32:56 <CakeProphet> no no... I'm just... bread.
01:33:01 <CakeProphet> it's not meant to be taken literally.
01:33:05 <CakeProphet> it's very surreal, you see.
01:33:09 -!- CakeProphet has changed nick to GrandmotherChaos.
01:33:23 <GregorR> I don't understand such nicks, given that mine is as uninteresting as they come.
01:33:25 <oerjan> The Mother of a Thousand Crumbs...
01:33:40 <GrandmotherChaos> SevenInchBread just sounded bizzare...
01:33:43 <GrandmotherChaos> it's my favorite.
01:33:52 <GrandmotherChaos> in fact...
01:33:56 -!- GrandmotherChaos has changed nick to SevenInchBread.
01:33:59 <SevenInchBread> ah... there we go.
01:36:26 <SevenInchBread> GregorR, GREGOR
01:36:31 <SevenInchBread> WILL YOU HELP US?
01:36:35 <SevenInchBread> WILL YOU SAVE THE DAY?
01:37:11 <SevenInchBread> ?.?
01:37:36 <SevenInchBread> !bf >.<
01:38:00 <SevenInchBread> !ps
01:38:03 <EgoBot> 2 SevenInchBread: ps
01:38:12 <SevenInchBread> !bf >.<
01:38:16 <SevenInchBread> !bf >.<
01:38:21 <SevenInchBread> !bf >+.<
01:38:24 <EgoBot> <CTCP>
01:38:27 <SevenInchBread> Yay
01:38:54 <GregorR> Wha?
01:38:58 <SevenInchBread> !bf +[.+]
01:39:02 <EgoBot> <CTCP>
01:39:17 <SevenInchBread> !kill 1
01:39:19 <SevenInchBread> !ps
01:39:24 <GregorR> !bf +[>+]
01:39:28 <EgoBot> Process 1 killed.
01:39:30 <EgoBot> 1 SevenInchBread: ps
01:39:31 <GregorR> WEEEEEEEEEEEEEEEEEEEEEEH
01:39:31 <oerjan> :D
01:39:32 <EgoBot> realloc: Cannot allocate memory
01:39:53 <SevenInchBread> We killed it?
01:40:00 <GregorR> Nah
01:40:04 <GregorR> That was just EgoBF dying ;)
01:40:16 <SevenInchBread> Ah... it's fault taulerant. :D
01:40:33 <SevenInchBread> Is it like... a bunch of subprocesses basically?
01:40:45 <GregorR> It is like a bunch of subprocesses literally.
01:41:25 <SevenInchBread> Python has really nifty subprocess handling...
01:41:32 -!- cmeme has quit ("Client terminated by server").
01:41:36 <SevenInchBread> hip-hip hurray for OO and functional.
01:41:43 -!- cmeme has joined.
01:42:00 <SevenInchBread> GREGORR
01:42:04 <SevenInchBread> WILL YOU HELP US?
01:42:07 <GregorR> EgoBot is nothing more than a collection of different interpreters written in all sorts of different languages.
01:42:14 <GregorR> Plus a runtime environment for them.
01:42:22 <SevenInchBread> BUILD THE PERFECT OS?
01:42:22 <GregorR> I might.
01:42:27 <GregorR> I'm just skeptical is all.
01:42:41 <SevenInchBread> Confidence goes a long way. :D
01:47:59 -!- Sukoshi has left (?).
01:48:09 -!- Sukoshi has joined.
01:52:43 <SevenInchBread> !glass {(Con) [(c__)a2=b1=] [(car)a*] [(cdr)b*]} {M[m(_o)O!(_er)(Con)!(_e)<1><2>(_er)(build).? (_e)(car).?(_o)o.?(_e)(cdr).?(_o)o.?]}
01:53:24 <SevenInchBread> !glass {(Con) [(c__)a2=b1=] [(car)a*] [(cdr)b*]} {M[m(_o)O!(_er)(Con)!(_e)<1><2>(_er)(build).?= (_e)(car).?(_o)o.?(_e)(cdr).?(_o)o.?]}
01:53:39 <oerjan> (on)
01:54:23 <SevenInchBread> !glass {(Con) [(c__)a2=b1=] [(car)a*] [(cdr)b*]} {M[m(_o)O!(_er)(Con)!(_e)<1><2>(_er)(build).?= (_e)(car).?(_o)on.?(_e)(cdr).?(_o)on.?]}
01:54:37 <oerjan> the parentheses are mandatory
01:54:41 <SevenInchBread> ...
01:54:45 <SevenInchBread> forgot
01:54:57 <SevenInchBread> !glass {(Con) [(c__)a2=b1=] [(car)a*] [(cdr)b*]} {M[m(_o)O!(_er)(Con)!(_e)<1><2>(_er)(build).?= (_e)(car).?(_o)(on).?(_e)(cdr).?(_o)(on).?]}
01:56:06 <SevenInchBread> !glass {(Con) [(c__)a2=b1=] [(car)a*] [(cdr)b*]} {M[m(_o)O!<1><2>(_er)(Con)! (_e)(car).?(_o)(on).?(_e)(cdr).?(_o)(on).?]}
01:56:13 <SevenInchBread> forgot Con didn't have the build method like List.
01:56:26 <SevenInchBread> !glass {(Con) [(c__)a2=b1=] [(car)a*] [(cdr)b*]} {M[m(_o)O!<1><2>(_e)(Con)! (_e)(car).?(_o)(on).?(_e)(cdr).?(_o)(on).?]}
01:56:30 <EgoBot> 12
01:56:33 <SevenInchBread> whooo
01:56:40 <SevenInchBread> exciting.
01:57:11 <oerjan> i still suggest you add ,, to the constructor.
01:57:23 <SevenInchBread> Where?
01:57:30 <SevenInchBread> and why?
01:58:22 <SevenInchBread> !glass {(Con) [(c__)a2=b1=,,] [(car)a*] [(cdr)b*]} {M[m(_o)O!<1><2>(_e)(Con)! (_e)(car).?(_o)(on).?(_e)(cdr).?(_o)(on).?]}
01:58:23 <oerjan> just before the ], to remove the arguments.
01:58:26 <EgoBot> 12
01:58:33 <SevenInchBread> But it works the same doesn't it?
01:59:45 <oerjan> only if you don't need to use anything below it in the stack
02:00:29 <SevenInchBread> Hey GregorR
02:00:38 <SevenInchBread> You should add some more special methods. :D
02:00:40 <SevenInchBread> to Glass.
02:00:47 <SevenInchBread> Like maybe an output method.
02:01:09 <SevenInchBread> So objects can have customized output with just one universal call.
02:01:39 <oklopol> like in... python?
02:01:44 <oklopol> off to sleep ->
02:01:49 <SevenInchBread> well... it's a good idea.
02:02:06 <oklopol> i ain't saying it ain't
02:02:07 <oklopol> ->
02:02:15 <GregorR> Technically speaking, you can implement a o and on method in any class and pass that in instead of an O class *shrugs*
02:02:51 <SevenInchBread> but then you have to determine type.
02:03:08 <SevenInchBread> like in the cons constructor... how would we know what type of elements we're dealing with?
02:03:16 <SevenInchBread> if they all have different ways to be outputted.
02:03:41 <GregorR> OH
02:03:49 <GregorR> Never mind, I didn't understand what you meant ;)
02:04:30 <oerjan> hm, that's true. it means the methods need to be added to numbers and strings as well.
02:04:39 <SevenInchBread> !glass {(Con) [(c__)a2=b1=,,] [(car)a*] [(cdr)b*] [(ols)(_o)O! a*(_o)o.? b*(_o)o.?} {M[m(_o)O!"Hello " "World!"(_e)(Con)! (_e)(car).?(_o)(on).?(_e)(cdr).?(_o)(on).?]}
02:04:42 <EgoBot> 00
02:04:49 <SevenInchBread> the (ols) method I just added would only work for strings...
02:04:54 <SevenInchBread> if... it wasn't bugged...
02:05:03 <SevenInchBread> one moment.
02:05:29 <SevenInchBread> !glass {(Con) [(c__)a2=b1=,,] [(car)a*] [(cdr)b*] [(ols)(_o)O! a*(_o)o.? b*(_o)o.?} {M[m(_o)O!"Hello " "World!"(_e)(Con)! (_e)(ols).?]}
02:06:02 <oerjan> of course you _can_ wrap them in classes.
02:06:42 <SevenInchBread> How does that solve the problem of segmented outputting functions?
02:07:00 <SevenInchBread> It's not really... a problem..
02:07:08 <SevenInchBread> just, would be nifty. :D
02:07:34 <SevenInchBread> damn type-based operators. >.<
02:07:35 <oerjan> it means you can wrap any object which doesn't have an o method in another object which does the translation.
02:08:14 <SevenInchBread> I'm not found of excess wrapping paper. :P
02:08:52 <SevenInchBread> hmmm... a wrapper paper language.
02:09:19 <SevenInchBread> "Well... before you can output a string in WrapLang you have to wrap it in a string-output-wrapper class... and then call the subsequence output method"
02:09:30 <SevenInchBread> to give it output functionality.
02:11:18 <SevenInchBread> Having a crapload of special methods is one of the coolest things about OO :D
02:11:46 <oerjan> we could define classes corresponding to each of the non-object datatypes, allowing methods to be defined for them.
02:12:41 <SevenInchBread> sounds too complicated.
02:13:29 <oerjan> i mean, so you could define your own methods that worked on every value, if you wanted.
02:15:32 <SevenInchBread> !glass {M[m(_lol)V! "whee"(_lol)n.? (_o)O! (whee)(_o)o.?]}
02:15:34 <EgoBot> whee
02:15:54 <SevenInchBread> !glass {M[m (_o)O! (whee)(_o)o.?]}
02:15:56 <EgoBot> whee
02:15:59 <SevenInchBread> !glass {M[m (_o)O! (whee)(_o)o.?]}
02:16:00 <EgoBot> whee
02:16:03 <SevenInchBread> !glass {M[m (_o)O! (wheewwwwwwwwwwwwwwwwwwwwwww)(_o)o.?]}
02:16:06 <EgoBot> wheewwwwwwwwwwwwwwwwwwwwwww
02:16:12 <SevenInchBread> !glass {M[m (_o)O! (wheewwwwwwwwwwwwwwwwwwwpeniswwww)(_o)o.?]}
02:16:14 <EgoBot> wheewwwwwwwwwwwwwwwwwwwpeniswwww
02:16:29 <GregorR> Yes, yes, Glass will let you treat variable references as strings X_X
02:16:37 <SevenInchBread> BRILLIANT
02:16:39 <SevenInchBread> ...
02:17:00 <SevenInchBread> !glass {M[m (_o)O!(1)(_o)o.?]}
02:17:11 <SevenInchBread> Did Glass explode?
02:17:27 <SevenInchBread> !glass {M[m (_o)O! (_o)(_o)o.?]}
02:17:30 <EgoBot> _o
02:17:45 <SevenInchBread> ah... yeah _o is just a reference name.
02:17:46 <oerjan> hmm...
02:17:57 <SevenInchBread> !glass {M[m (_o)O! (_o)o.(_o)o.?]}
02:18:17 <oerjan> !glass {M[m (_o)O! "Test" (_o) "o".?]}
02:18:33 <oerjan> alas :)
02:18:57 <SevenInchBread> !glass {M[m (_o)O! (_o)o.?(_o)o.?]}
02:19:11 <SevenInchBread> !glass {M[m (_o)O!"lol" (_o)o.?(_o)o.?]}
02:19:12 <EgoBot> lol
02:19:31 <oerjan> you have some serious stack underflow there.
02:20:07 <SevenInchBread> stack underflow?
02:20:39 <oerjan> trying to get values from an empty stack
02:21:35 <oerjan> hm...
02:21:52 <oerjan> !glass {M[m(_o)O!(_o)(on).]}
02:22:26 <SevenInchBread> !glass {M[m (_o)(BF)! "+[+.]"(_o)(bf).?]}
02:22:28 <EgoBot>
02:22:37 <SevenInchBread> !ps
02:22:40 <EgoBot> 1 SevenInchBread: glass
02:22:42 <EgoBot> 2 SevenInchBread: ps
02:22:43 <SevenInchBread> !kill 1
02:22:44 <EgoBot> Process 1 killed.
02:23:23 <SevenInchBread> Well... if we use Glass for the core language... we already have the problem of implementing a bf interpreter solved. :D
02:23:40 <SevenInchBread> Just not a functional bf :D
02:29:09 <GregorR> For some reason, I find this error message infinitely hilarious:
02:29:11 <GregorR> /usr/lib/libc.a(init-first.o):(.data+0x0): multiple definition of `__libc_multiple_libcs'
02:31:13 -!- SevenInchBread has changed nick to CakeProphet.
02:33:57 <CakeProphet> hehe
02:34:11 * CakeProphet is making a Vampire the Masquerade character.
02:34:24 <CakeProphet> Designing an OS -and- playing tabletop.... I'm such a nerd.
02:35:47 <GregorR> Oh noes, I'm going to have to start putting "2007" in the copyright lines soon 8-X
02:39:31 <oerjan> !glass {M[m(_a)A!(_o)O!<1.2><3>(_a)m.?(_o)(on).]}
02:39:51 <oerjan> !glass {M[m(_a)A!(_o)O!<1.2><3>(_a)m.?(_o)(on).?]}
02:39:55 <EgoBot> 3.6
02:40:20 <oerjan> !glass {M[m(_a)A!(_o)O!<4.0><3>(_a)d.?(_o)(on).?]}
02:40:23 <EgoBot> 1.33333
02:40:27 <oerjan> !glass {M[m(_a)A!(_o)O!<4><3>(_a)d.?(_o)(on).?]}
02:40:31 <EgoBot> 1.33333
02:40:52 <oerjan> !glass {M[m(_a)A!(_o)O!<4.0><3>(_a)a.?(_o)(on).?]}
02:40:55 <EgoBot> 7
02:41:56 <oerjan> Well, good night.
02:41:59 -!- oerjan has quit ("Leaving").
02:44:22 <CakeProphet> GregorR, I do public domain myself.
02:44:29 -!- ihope_ has joined.
02:44:38 <CakeProphet> Yay! My clumsily built BF interpreter works.
02:44:41 <GregorR> CakeProphet: I have no clue what that's in response to.
02:44:47 -!- ihope_ has changed nick to ihope.
02:44:53 <CakeProphet> GregorR, Changing copyrights.
02:45:06 <CakeProphet> ihope, Wanna built an Esoteric Operating System?
02:45:23 <GregorR> CakeProphet: I have no clue when I said anything regarding that :P
02:46:43 <CakeProphet> ">Oh noes, I'm going to have to start putting "2007" in the copyright lines soon 8-X"
02:47:36 <GregorR> OH
02:47:49 <GregorR> Well, public domain is just plain bad, so *shrugs*
02:48:24 <CakeProphet> Why's that?
02:48:31 <CakeProphet> http://deadbeefbabe.org/paste/3088 <--crappy BF interpreter.
02:48:48 <GregorR> With public domain, you can't add a warantee disclaimer.
02:49:13 <GregorR> However, you're still liable.
02:49:16 <CakeProphet> but... if it's public domain... you don't "own" it.
02:49:22 <GregorR> But you're still liable.
02:49:30 <CakeProphet> ....well that's a crock of shit
02:49:30 <GregorR> That's the f***'d-up-ness of copyright.
02:49:49 <GregorR> I prefer MIT minus attributionl
02:49:51 <GregorR> -l
02:49:55 <ihope> CakeProphet: I'm sort of in the habit of immediately closing all server tabs and clicking on everything red, so I didn't notice your thing about an esoteric operating system.
02:50:03 <ihope> GregorR: where's it say that?
02:50:20 <GregorR> ihope: ?
02:50:33 <CakeProphet> hmmm... I do like that I had a chance to use a coroutine in my BF interpreter.
02:50:34 <ihope> About the public domain.
02:50:37 <CakeProphet> It's an interesting way to do.
02:50:55 <ihope> So, as for the operating system... well, I'd rather build a less esoteric one.
02:51:03 <ihope> Just what is an esoteric operating system?
02:51:14 <CakeProphet> The goal is to eventually make it a useful OS.
02:51:19 <CakeProphet> fun, but still useful.
02:51:29 <CakeProphet> it's an OS built from esolangs. :D
02:51:45 <GregorR> ihope: IANAL, this is just what I've been told.
02:52:02 <CakeProphet> hehe... "I anal"
02:54:06 <ihope> CakeProphet: yes, he is.
02:54:08 <ihope> :-P
02:54:18 <CakeProphet> :o
02:54:30 <ihope> My knowledge of copyright law is probably built entirely from gists and FAQs.
02:54:48 <GregorR> Mine is based on FAQs and Bart Massey.
02:54:52 <ihope> I always think I know more about things than I really do, maybe.
02:55:07 <ihope> I know exactly how exercise works, for example.
02:55:31 <ihope> And I know that starchy foods are best.
02:56:02 <CakeProphet> ihope, At the moment... it looks like we're going to be using Glass to build the kernel... it'll have no filesystem, and all programs will work like "universal functions".
02:56:15 <ihope> No filesystem?
02:56:19 <CakeProphet> nope.
02:56:24 <ihope> What platform are we going to build this on, exactly?
02:56:25 <CakeProphet> universally continguous memory.
02:56:34 <CakeProphet> *shrugs* dunno.
02:56:41 <ihope> Not x86, I take it.
02:56:52 <CakeProphet> I don't know a lot about the specifics.
02:57:00 <GregorR> It would probably run /on/ x86
02:57:05 <GregorR> But would not /run/ x86 code.
02:57:11 <ihope> Under emulation?
02:57:31 <ihope> Let's call the platform SOAP.
02:57:34 <CakeProphet> Glass would be the closest thing to the assembly language.
02:57:41 <CakeProphet> I like it.
02:57:43 <CakeProphet> the name.
02:57:45 <ihope> For eSOAteric Platform.
02:58:02 <CakeProphet> ....questionable acroynmical roots. :P
02:58:09 <CakeProphet> but... oh well.
02:58:16 <ihope> Misspellings always make wonderful acronyms.
02:58:29 <ihope> I mean, it's no worse than Get Rid Of Slimy girlS, is it?
02:59:03 <ihope> So Glass is our platform?
02:59:08 <GregorR> Apparently.
02:59:13 <GregorR> I certainly agree with that :P
02:59:15 <ihope> Wonderful.
02:59:28 <ihope> We just need a hardware interface.
02:59:46 <ihope> If I'm not mistaken, hardware interfacing on the x86 is done with memory mapping.
02:59:57 <ihope> And I may well be mistaken.
03:00:21 <GregorR> I don't even have the slightest bit of a clue.
03:01:06 <GregorR> Must ... find ... something like OSKit ... but more up-to-date.
03:01:15 <ihope> ...
03:04:39 <ihope> Anyway, Glass doesn't exactly have reading and writing to specific addresses, does it?
03:04:49 <ihope> Objects have variables, though, right?
03:05:02 <GregorR> No and yes, respectively.
03:05:35 <ihope> So you could say something of class 1000 has 1000 values in it, and if each one happens to contain a 1000, then you have 1000000 values?
03:06:00 <ihope> (1000 isn't a valid class name, is it?)
03:06:16 <GregorR> No, it isn't ;)
03:09:28 <CakeProphet> We can change the implementation.
03:09:40 <CakeProphet> to allow memory addressses. ;)
03:09:59 <GregorR> Sure
03:10:08 <GregorR> So long as you call it chaning the /language/
03:10:10 <CakeProphet> it would be trivial... if we're going to be working so close to the machine code.
03:10:23 <CakeProphet> nah... just adding a new class. :D
03:10:38 <CakeProphet> same language... new builtin class. It's a "feature request" :P
03:10:40 <GregorR> Oh
03:10:42 <GregorR> OK
03:10:42 <CakeProphet> not cheating.
03:10:45 <CakeProphet> hehehe
03:11:01 <GregorR> Vote #1:
03:11:15 <GregorR> Write the kernel entirely from scratch, or use something like OSKit?
03:11:25 <ihope> I dunno. Some wacko extension to BF might be better.
03:11:30 <CakeProphet> hmmm... should update the OS page...
03:11:39 <CakeProphet> ihope, we tried that. :D
03:11:51 <ihope> (We|You) did?
03:11:55 <CakeProphet> Def-BF.... a version of BF with memory addressing for subroutines.
03:12:00 <ihope> (And which, for that matter?)
03:12:07 <ihope> Def-BF had what?
03:12:14 <CakeProphet> We (Me, Richard, et al)
03:12:29 <CakeProphet> you can call subroutines by absolute address.
03:12:34 <ihope> I take it I'm not part of the "we".
03:12:39 <ihope> Subroutines, pah.
03:12:40 <CakeProphet> it's BF with a crude subroutine call.
03:13:17 <CakeProphet> but.... Glass would be far better... plus it's not "cheating", and it'll be more efficient.
03:13:21 <ihope> We need self-modifying BF with RAM instead of SAM.
03:13:41 <ihope> Glass is not an assembly-like thingy! We must be absolutely traditional!
03:13:45 <CakeProphet> ihope, other ideas that were tossed around include othogonal persistency.
03:13:59 <CakeProphet> huh?
03:14:02 <ihope> Actually, self-modifying BF is a little hackish as well.
03:14:36 <CakeProphet> I had an idea for such a BF in my head at one point.
03:14:37 <ihope> Well, such a BF thing might be cool.
03:14:48 <CakeProphet> but... really... Glass works much much better than BF of any sort.
03:15:04 * CakeProphet should name his self-modifying BF such-a-BF
03:15:06 <ihope> Let's make a new language that has a system mode and a user mode, and traps.
03:15:10 <CakeProphet> since that's what we're calling it.
03:15:13 <ihope> And nothing else.
03:16:10 <ihope> We could have "enter user mode" be the only instruction... then again, that gives no control whatsoever.
03:16:20 <CakeProphet> ....
03:16:26 <CakeProphet> I vote Glass...
03:16:28 <CakeProphet> :P
03:16:33 <ihope> "Enter user mode" and "fudge trap registers"?
03:16:35 <CakeProphet> fuck your userless usermode switching language.
03:16:43 <ihope> Bhm.
03:17:31 <ihope> How, exactly, does one load a program and run it with Glass?
03:17:43 <CakeProphet> hmmm?
03:18:00 <ihope> How does a Glass program load a program and run it?
03:18:04 <ihope> A Glass kernel, rather.
03:18:14 <CakeProphet> We haven't really touched the specifics yet.
03:18:16 <CakeProphet> so... dunno.
03:18:41 <GregorR> It could have interpreters written in Glass (or as object files)
03:18:57 <ihope> Interpreters?
03:19:00 <ihope> You mean emulation?
03:19:15 <CakeProphet> no... interpreters :P
03:19:24 <ihope> Portable Executable files contain x86 assembly, don't they?
03:19:38 <ihope> And whatever ELF stands for, too?
03:19:59 <GregorR> Uh, yeah ...
03:20:15 <CakeProphet> Glass could use some facelifting...
03:20:17 <ihope> Interpreters are a little slow, you know.
03:20:20 <CakeProphet> some nifty special methods.
03:20:25 <ihope> Especially when you're running the interpreter under emulation.
03:20:52 <CakeProphet> it would make it easy to universalize data from different languages... to do the whole all-programs-can-call-each-other thing.
03:21:01 <GregorR> WE'RE TALKING ABOUT AN ESOTERIC OS
03:21:06 <CakeProphet> YES
03:21:06 <GregorR> Slow is the last of our problems.
03:21:11 <ihope> Oh.
03:21:15 <CakeProphet> LOL
03:21:17 <CakeProphet> CAPS LOCK
03:21:18 <CakeProphet> NOOB
03:21:23 <ihope> yAY, CAPS LOCK.
03:21:41 <ihope> sO WE DON'T CARE ABOUT SPEED, THEN?
03:21:52 <CakeProphet> Optimization can come later.
03:21:57 <GregorR> Not that much, no.
03:22:04 <CakeProphet> but... speed is still up there in the "to think about" list.
03:22:06 <ihope> I guess we can emulate, then.
03:22:11 <CakeProphet> just... less important than it normally would be.
03:22:36 <GregorR> The kernel should have interpreters (perhaps JIT) for Glass, BF, etc)
03:22:57 <GregorR> GTG, BBIAW
03:22:59 * GregorR disappears.
03:23:47 <ihope> Be back in a while?
03:23:50 <ihope> ...Yeah, I guess.
03:24:05 <ihope> Anyway... Glass. How are we going to do the hardware interfacing?
03:24:57 <CakeProphet> how do you normally do hardware interfacing?
03:25:16 <ihope> Memory mapping or special commands.
03:25:30 <ihope> As in I don't know which, not you can choose which.
03:25:49 <CakeProphet> well... we can just build it into the implementation of Glass.
03:25:50 <ihope> Though maybe both are commonly used.
03:25:53 <CakeProphet> as more classes :D
03:26:06 <ihope> I guess memory mapping would use special things anyway.
03:26:12 <CakeProphet> that map to whatever underlying interface is required.
03:26:34 <ihope> So add a special Hardware class and whatever methods you need.
03:27:06 <ihope> Now, I'm about to rush upstairs, so anything you may hear from me may well be my little cousin.
03:28:17 * CakeProphet is on guard.
03:29:10 -!- Asztal has joined.
03:30:39 <CakeProphet> Asztal, rawr
03:31:51 <Asztal> why hello
03:34:55 <CakeProphet> Asztal, Wanna build an esoteric OS? :D:D
03:36:37 <bsmntbombdood> heh
03:50:56 -!- Asztal has quit (Nick collision from services.).
03:51:01 -!- Azstal has joined.
03:51:03 -!- Azstal has changed nick to Asztal.
03:52:02 <CakeProphet> HEY AZSTAL
03:52:09 <CakeProphet> WANNA BUILD AN ESOTERIC OS WITH US?
03:52:15 -!- CakeProphet has changed nick to SevenInchBread.
03:53:26 <Asztal> sounds excellent
03:56:11 -!- SevenInchBread has changed nick to CakeProphet.
04:09:00 <GregorR> HEY CAKEPROPHET, time to stop using capslock :P
04:09:16 <CakeProphet> LOL FUCK U
04:09:18 <GregorR> As per hardware interfacing, builtin classes is the obvious solution.
04:09:34 <CakeProphet> builtin classes seems to be the solution for most anything.
04:09:49 <CakeProphet> "How do we do that?" "Pop in another built-in class"
04:10:15 <GregorR> OR we could just make assembly a supported language.
04:11:28 <CakeProphet> lol.
04:11:34 <CakeProphet> That would be the noob way to do it.
04:11:47 <CakeProphet> Everything must be in Glass.
04:12:03 <CakeProphet> "SOAP... made entirely of Glass"
04:12:14 <GregorR> Um, at some level there has to be a glass interpreter.
04:12:15 <GregorR> So no.
04:12:16 <CakeProphet> I surely wouldn't want to bathe with glassy soap.
04:12:31 <CakeProphet> GregorR, Yeah I know... I'm just playing.
04:12:46 * GregorR tries to roll his own multiboot kernel.
04:12:51 <CakeProphet> We should mos def use Glass instead of boring Assembly language.
04:18:04 -!- ivan` has quit (" Want to be different? HydraIRC -> http://www.hydrairc.com <-").
04:19:52 <RodgerTheGreat_> back
04:20:53 <RodgerTheGreat_> ihope: http://nonlogic.org/dump/text/1167538452.html
04:21:00 <RodgerTheGreat_> ^ the Def-BF spec
04:22:48 <RodgerTheGreat_> looks like my poor little language has already fallen from vogue, based on the logs
04:22:54 <RodgerTheGreat_> sigh
04:23:02 <RodgerTheGreat_> such is the fate of most esolangs
04:23:16 <GregorR> Specification minus implementation equals zero.
04:23:33 <RodgerTheGreat_> well, of course
04:23:33 <CakeProphet> Under that logic...
04:23:39 <CakeProphet> Specification = implementation
04:23:57 <GregorR> With esolangs, that's usually true :)
04:24:22 <RodgerTheGreat_> I wouldn't say a spec is nothing, but it's less than %10 of the work of creating an esolang.
04:24:32 <Asztal> If it's going to be esoteric, are you going to do away with unfashionable and outmoded concepts such as files and processes and invent more quirky ones?
04:24:38 <CakeProphet> Specification - inplementation + inplemntation = 0 + inplementation
04:24:40 <CakeProphet> :D
04:24:51 <CakeProphet> Asztal, Pretty much.
04:24:58 <RodgerTheGreat_> Asztal: well, we've already decided to get rid of files.
04:25:08 <RodgerTheGreat_> not sure what we're doing about processes just yet
04:25:11 <Asztal> Good. I hated them anyway
04:25:18 <CakeProphet> yeah..
04:25:36 <Asztal> Living beings with hit points, armour ratings etc?
04:25:48 <CakeProphet> I'm thinking we can hardwire most programs to be like OS-level functions that can be called with input and return an output...
04:25:55 <RodgerTheGreat_> and I think that even if we code the kernel in glass, Def-BF will be a powerful tool for writing utilities and applications
04:26:02 <CakeProphet> programs could communicate with the OS to call up other programs and retrieve their output.
04:26:19 <CakeProphet> RodgerTheGreat_, Without the memory addressing thing. :P
04:26:30 <CakeProphet> RodgerTheGreat_, But yeah... it's definetely a step up from BF/
04:27:01 <RodgerTheGreat_> just because you fear pointers doesn't make them useful or useable, CakeProphet. ;)
04:27:16 <CakeProphet> I know.
04:27:19 <CakeProphet> They're not. :P
04:27:44 <CakeProphet> I never made claims to pointers being usable.
04:27:53 <CakeProphet> :D
04:28:20 <RodgerTheGreat_> it doesn't prove the inverse either
04:29:54 <RodgerTheGreat_> regardless, pikhq seemed interested in the language, so the two of us will likely build a development package for it in short order
04:30:30 <RodgerTheGreat_> once we get a codebase together, I reckon it'll look pretty attractive
04:33:54 -!- digital_me has joined.
04:34:04 <RodgerTheGreat_> howdy, digital_me
04:34:30 <digital_me> Hello
04:43:36 <Asztal> so the idea is to not only run esoteric languages on a platform written in almost entirely esoteric languages, but also to allow some sort of magic interop between them? or have I misread "The current plan is that programs should act like modular components that can be imported and called by other programs via underlying OS magic"?
04:44:51 <CakeProphet> That's about right.
04:45:22 <CakeProphet> It sounds simple to do... just treat programs as input-output units (akin to a file... but not shoved into long-winded pathnames)
04:45:39 <RodgerTheGreat_> my original concept was that you'd have a basic kernel providing memory management, tasking, basic I/O, etc, and it could load esolang interpreters as "modules". You'd then use these interpreters to run all your utilities and applications that make up a useable system.
04:46:33 <RodgerTheGreat_> all you need is a good standardized I/O system that all the interpreters conform to, and you have yourself the ultimate esoteric OS
04:46:59 <CakeProphet> all programs deal with numbers in the end... that's the universal output stream.
04:47:08 <RodgerTheGreat_> ideally, the kernel and it's modules would also be coded as much in esolangs as possible
04:47:45 <CakeProphet> but there will probably be some API to specify output as a string or something.
04:48:10 <CakeProphet> It's up to the language to choose how to handle the data though.
04:48:16 <RodgerTheGreat_> so far, Glass and Def-BF appear extremely promising languages for the task, with glass likely better for a kernel (better I/O), and Def-BF well suited to building modular libraries and large applications
04:48:30 <Asztal> gotta go, 4:40am. I'll read the logs though :)
04:48:36 -!- calamari has quit ("Leaving").
04:48:38 <RodgerTheGreat_> cya
04:48:38 <CakeProphet> Glass is pretty well suited for that task too... being OO.
04:48:42 -!- Asztal has quit ("Chatzilla 0.9.75 [IceWeasel 1.0.1b2] (kidding!)").
04:48:43 <CakeProphet> alrighty
04:49:08 <RodgerTheGreat_> OO doesn't necessarily mean it's easy to make into machinecode.
04:49:37 <CakeProphet> hmmm... but Glass is pretty machine-codish.
04:49:58 <CakeProphet> but so if BF :D
04:50:05 <CakeProphet> BF just isn't quite as efficient.
04:50:14 <RodgerTheGreat_> it's powerful, but I don't think glass is much like machinecode
04:50:20 <CakeProphet> so... something like a kernel... might not prove too effective.
04:50:42 <GregorR> BF is more machine-code-ish, but I can't realistically see people writing a kernel in it.
04:51:15 <CakeProphet> In the meantime, I'ma work on my self-modifying MUD codebase. :D
04:51:49 <RodgerTheGreat_> the main advantage I see with Def-BF is the fact that we can take advantage of all existing BF code and tools like pikhq's BFM- that's why I think it's a good way to provide some libraries for the OS
04:52:07 <CakeProphet> Definetely.
04:52:32 <CakeProphet> and since we plan on having all languages capable of communicating I/O to each other... that'll give us a nice backbone.
04:53:07 <RodgerTheGreat_> I'm not sure it can take the place of C as a primary coding language, but I think it'd make a nice equivalent of perl or TCL as a primary scripting and utility language
04:54:31 <CakeProphet> so... Glass, ORK, Def-BF, Befunge...
04:54:37 <RodgerTheGreat_> it'd probably be possible to use it to build a kernel, but it ultimately depends on what has the support of the coding team
04:54:49 <CakeProphet> Really you could use BF as a stand-alone... since programs are themselves functions of a sort.
04:54:59 <RodgerTheGreat_> I'm not really sure how Befunge will fit into the mix
04:55:33 <RodgerTheGreat_> Def-BF makes it easier to fit loose BF programs into a framework for controlling them as a group
04:55:51 <CakeProphet> Righto.
04:56:09 <CakeProphet> It'd be a mess to do in regular BF.
04:56:13 <RodgerTheGreat_> yeah
04:56:30 <RodgerTheGreat_> it wouldn't be impossible, but it'd make it a bitch to add and remove things
04:57:00 <CakeProphet> Befunge is... hmmm...
04:57:10 <CakeProphet> It's kind of a "wiring" language..
04:57:12 <CakeProphet> it's spatial.
04:57:34 <RodgerTheGreat_> hm
04:57:50 <CakeProphet> Ork and Glass have obvious uses with OO.
04:58:13 <RodgerTheGreat_> I think they'd both be useful for applications programming
04:58:33 <CakeProphet> The OS API for interchanging data might include a way to import individual objects and functions from the less basic esolangs.
04:58:41 <RodgerTheGreat_> can you think of any other esolangs with some fashion of usefulness to them?
04:59:01 <CakeProphet> hmmm... there's plenty I'm sure.
04:59:20 <CakeProphet> We don't need just the useful ones... we can implement a ton just for the hell of it. :D
04:59:21 <RodgerTheGreat_> I'll probably build a SYNTHESYS port, but I'm not sure self-modifying code is all that important for OS work.
04:59:30 <CakeProphet> INTERCAL?
04:59:42 <RodgerTheGreat_> well, yeah, but we need a handful of useful ones to build the core OS with
05:00:04 <CakeProphet> hehe... malboldge.
05:00:14 <RodgerTheGreat_> I don't like the idea of having my choices for writing a shell limited to BF, malbolge or turkeybomb.
05:00:45 <RodgerTheGreat_> can you think of any graphically-oriented languages that could be used for coding a window manager or something?
05:01:16 <CakeProphet> hmmm... yeah I've been wondering how the GUI will look with no filesystem.
05:01:24 <CakeProphet> not to mention... how we'll do no filesystem.
05:02:30 <RodgerTheGreat_> I have a few good ideas for designing a new GUI paradigm- leave that to me.
05:02:40 <RodgerTheGreat_> all I need is a good language to build with
05:02:55 <RodgerTheGreat_> some form of OISC could be useful for something...
05:03:27 <RodgerTheGreat_> OISC is pretty weird, but has real-world applications
05:03:54 -!- digital_me has quit ("holy lol!").
05:04:00 <CakeProphet> lol... fuck the real world.
05:04:05 <CakeProphet> We don't need it
05:04:19 <CakeProphet> I think it would be cool to have like... a scrollable "plain".
05:04:53 <CakeProphet> but... that's kind of weird.
05:04:57 <CakeProphet> for a GUI.
05:05:39 <GregorR> Here's the problem with every EsoOS ever: Nobody can make up their F'ing mind on anything.
05:06:01 <RodgerTheGreat_> well, so far we've made a little progress.
05:06:14 <RodgerTheGreat_> deciding on a core language is the first step.
05:06:38 <CakeProphet> heh... there's no deadline.
05:06:48 <CakeProphet> we can take eternity goign back and forth if we want.
05:06:50 <CakeProphet> no rush. :D
05:06:54 <RodgerTheGreat_> now we need an elegant system for allowing the languages to collaborate
05:07:07 <RodgerTheGreat_> CakeProphet: the only deadline is "before we all get bored and quit"
05:07:16 <CakeProphet> Yup.
05:07:23 <GregorR> No, what we need is an actual design for a kernel. How the languages correspond is fluff.
05:07:47 * RodgerTheGreat_ cracks his knuckles.
05:08:03 <RodgerTheGreat_> sounds like I'm going to hammer out another specification
05:08:13 <CakeProphet> :( Some more pessimistic and you're going to morph into a grumpy coder...
05:08:40 <CakeProphet> grumpy coders are absolutely the most annoying creature I've ever encountered... but I don't know why.
05:08:58 <RodgerTheGreat_> he already *is* a grumpy coder. His role in the project is grounding our overflowing enthusiasm with realism.
05:09:19 <RodgerTheGreat_> all in all, not necessarily a bad thing
05:09:33 <CakeProphet> ....fuck realism
05:09:38 <CakeProphet> it's like the real world
05:09:41 <CakeProphet> we don't need it.
05:11:40 <CakeProphet> well.... I really have NO clue how to do a kernel.
05:11:44 <CakeProphet> so.... you've got me there.
05:12:18 <GregorR> I can write a kernel, but I don't know what anybody actually wants.
05:12:32 <RodgerTheGreat_> I have some ideas as to how to design one
05:12:36 <CakeProphet> yeah... there's a lot of details you can specify in a kernel.
05:12:53 <RodgerTheGreat_> ok, so what are the most basic things we need in the kernel?
05:13:30 <RodgerTheGreat_> 1) a memory manager that can take available RAM and disk space and address it as a contiguous region, handling swapping, etc, transparently
05:13:33 <GregorR> I think the kernel proper should be an interpreter for a superset of some language (say, Glass) which will provide interface to the hardware.
05:13:42 <RodgerTheGreat_> yeah
05:13:53 <CakeProphet> disk control, hardware I/O (a superset of disk control), memory management.
05:14:05 <CakeProphet> oh... have the kernel be the Glass interpreter... brilliant.
05:14:15 <RodgerTheGreat_> that language will in turn be used to write the interpreters for other languages
05:14:19 <RodgerTheGreat_> sounds solid
05:14:21 <GregorR> With a good hardware layer, all of that can be hypothetically written in the language of choice.
05:14:30 <RodgerTheGreat_> yeah
05:14:32 <CakeProphet> That like... puts all the OO-ness of Glass directly atop the kernel... sounds good.
05:14:47 <GregorR> It's fine if that's hypothetical, so long as we can actually write things like simple shells et cetera :P
05:15:56 <RodgerTheGreat_> so the task boils down essentially to extending the built-in library for Glass and getting an interpreter for it running on bare metal
05:16:15 <CakeProphet> How will we do disk writing? I mean... do we really want hard disk totally independent from virtual memory?
05:16:27 <CakeProphet> It's kind of annoying to have to save everything to a file explicitly.
05:16:29 <RodgerTheGreat_> do we want the kernel to run a single language, or several "core" languages?
05:16:47 <CakeProphet> hehe... glass on metal.
05:16:52 <RodgerTheGreat_> lol
05:17:15 <RodgerTheGreat_> then we just need to call the API "plastic"
05:17:23 <CakeProphet> hehe
05:17:31 <RodgerTheGreat_> and the library "wood"
05:17:37 <CakeProphet> hahahaha
05:17:49 <CakeProphet> and the whole OS SOAP.
05:18:05 <RodgerTheGreat_> which has the added benefit of an infinite supply of "my kernel's got wood" jokes
05:18:18 * CakeProphet DIES
05:18:18 <GregorR> Actually, just one.
05:18:24 <GregorR> Namely, "my kernel's got wood"
05:18:47 <RodgerTheGreat_> I'm sure I can think of another given time
05:19:29 <CakeProphet> mmm... the whole save-to-disk-explicitly thing seems kind of outdated.
05:19:34 <CakeProphet> surely we can do better than that? :D
05:22:36 <RodgerTheGreat_> just do it like Uuu- make EVERYTHING virtual memory. As things get paged to disk, they're "auto-saved"
05:23:01 <CakeProphet> I think they do some other stuff too... for efficiency.
05:23:23 <CakeProphet> and... sometimes you don't want everything on hard disk. :D
05:23:34 <RodgerTheGreat_> well, yeah. Everything is more complex in practice than in theory
05:23:44 <CakeProphet> *nods*
05:23:49 <CakeProphet> That's just the basic idea.
05:29:34 <CakeProphet> GregorR, You've been involved in other esoos projects that failed? :D
05:47:52 <RodgerTheGreat_> good night- I'll return sometime tomorrow
05:48:12 -!- RodgerTheGreat_ has quit.
06:11:37 <GregorR> CakeProphet: More like I've watched other such projects fail :P
06:35:44 -!- ivan` has joined.
06:44:11 <GregorR> OK, somebody link me to the simplest C BF interpreter on earth :P
06:46:07 -!- ivan` has quit (" HydraIRC -> http://www.hydrairc.com <- The future of IRC").
06:54:04 <GregorR> OK, well, I can write a BF interpreter as a kernel now :P
07:03:28 -!- ihope has quit (Connection timed out).
07:54:24 -!- Arrogant has joined.
07:58:59 -!- Arrogant has quit (Client Quit).
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
09:00:57 <CakeProphet> hmmm?
09:01:19 <CakeProphet> GregorR, chomp
09:02:44 <CakeProphet> I'm doinh yo sleep.
09:02:52 -!- CakeProphet has quit ("fuck you").
09:52:24 -!- oerjan has joined.
10:13:35 <oklopol> "<GregorR> OK, well, I can write a BF interpreter as a kernel now :P" << wow i'm beginning to think it's gonna happen :D
10:13:41 <oklopol> the os i mean
10:24:19 -!- ivan` has joined.
11:00:58 -!- tgwizard has joined.
11:25:12 <oerjan> !glass {M[m(_o)O!(_t)(_o)=/(_t)"test"(_o)o.?(_t)<0>=\" ho"(_o)o.?]}
11:25:14 <EgoBot> ho
11:26:00 <oerjan> !glass {M[m(_o)O!(_t)(_o)*=/(_t)"test"(_o)o.?(_t)<0>=\" ho"(_o)o.?]}
11:26:03 <EgoBot> ho
11:26:14 <oerjan> !glass {M[m(_o)O!(_t)(_o)o.=/(_t)"test"(_o)o.?(_t)<0>=\" ho"(_o)o.?]}
11:26:17 <EgoBot> ho
11:26:27 <oerjan> !glass {M[m(_o)O!(_t)<1>=/(_t)"test"(_o)o.?(_t)<0>=\" ho"(_o)o.?]}
11:26:30 <EgoBot> test ho
11:26:41 <oerjan> !glass {M[m(_o)O!(_t)"hi"=/(_t)"test"(_o)o.?(_t)<0>=\" ho"(_o)o.?]}
11:26:43 <EgoBot> test ho
11:27:49 <oerjan> !glass {M[m(_o)O!(_t)O*=/(_t)"test"(_o)o.?(_t)<0>=\" ho"(_o)o.?]}
11:27:52 <EgoBot> ho
11:33:00 <oerjan> !glass {M[m(_o)O!(_t)<-1>=/(_t)"test"(_o)o.?(_t)<0>=\" ho"(_o)o.?]}
11:33:03 <EgoBot> test ho
11:33:29 <oerjan> {M[m(_o)O!<-1>(_o)(on).?]}
11:33:48 <oerjan> {M[m(_o)O!<-1>(_o)o.?]}
11:33:57 <oerjan> gah!
11:34:03 <oerjan> !glass {M[m(_o)O!<-1>(_o)o.?]}
11:34:17 <oerjan> !glass {M[m(_o)O!<-1>(_o)(on).?]}
11:34:19 <EgoBot> -1
11:41:09 -!- oklopol has quit (Read error: 60 (Operation timed out)).
12:04:20 -!- Sph1nx has joined.
12:30:36 -!- Sukoshi has quit (Read error: 110 (Connection timed out)).
12:34:50 -!- oerjan has quit ("Later").
13:56:48 -!- ivan` has quit (" HydraIRC -> http://www.hydrairc.com <- The future of IRC").
13:57:09 -!- Asztal has joined.
13:57:56 <SimonRC> "And remember: you can't spell manslaughter without laughter."
14:09:01 -!- Sph1nx has quit (" !").
14:17:26 * SimonRC thinks a F98-based OS would be good. You could put everything in one 4gig * 4gig funge-space. It would have to be sparse of course, but wouldn't be too bad on the speed side, and would be a good way to do orthogonal persistance. F98 already has a module system too.
14:19:12 <SimonRC> OST, why am I assuming Befunge-98? We could use Trefunge-98!
14:19:33 <SimonRC> Though Bef-98 allows addresses to fit nicely into a 64-bit word
14:19:46 <Asztal> I actually have a sparse trefunge-98 implementation here, but it needs more work.
14:22:01 <SimonRC> I am suddenly reminded that the only decent Tref98 editor isin fact written in Tref98
14:22:32 <SimonRC> actually, the i and o commands would need to be fiddled.
14:22:45 <SimonRC> o would be great for "OS Call"
14:22:47 <SimonRC> dunno about i
14:24:52 -!- ivan` has joined.
14:24:56 <SimonRC> yo
14:25:14 <Asztal> fingerprints?
14:25:14 <SimonRC> now I come to think of it, there would need to be some form of 2D malloc.
14:25:22 <SimonRC> Fingerprints are a bit slow.
14:26:18 <SimonRC> F98 is not afraid of having several ways to do something
14:35:14 -!- jix_ has joined.
14:55:24 -!- nooga has joined.
14:55:32 <nooga> ehhehe helllo
15:06:55 <SimonRC> I don't suppose any of you where the Tertium Quid webcomic is, do you?
15:56:15 -!- nooga has quit (Read error: 110 (Connection timed out)).
16:35:30 -!- man-X has joined.
16:41:14 -!- Asztal has quit (Read error: 54 (Connection reset by peer)).
16:41:44 -!- man-X has quit (Client Quit).
16:51:56 -!- RodgerTheGreat has joined.
17:04:22 -!- oerjan has joined.
17:36:51 * SimonRC goes
17:37:41 * bsmntbombdood comes
17:59:18 -!- jix_ has quit ("Bitte waehlen Sie eine Beerdigungnachricht").
18:02:40 <pikhq> GregorR: RE: EsoOS. I think it should just be a PESOIX-compliant interpreter running on bare metal, with the ability to load language modules.
18:03:03 <pikhq> (add a few PESOIX namespaces, so that one can access more than what bare PESOIX provides)
18:03:09 <bsmntbombdood> PESOIX?
18:03:32 <pikhq> It's an additional API for esolangs, which is talked to via stdio.
18:22:59 -!- CakeProphet has joined.
18:38:50 <RodgerTheGreat> so, pikhq- what's your opinion on Def-BF vs Glass as a core language?
18:39:52 <pikhq> The core PESOIX system should be in either ASM or C. . .
18:40:02 <pikhq> Glass and Def-BF can coexist peacefully on top of this. ;)
18:41:15 <RodgerTheGreat> there's no debate on either of their inclusion- they're both powerful languages. However, we were interested in trying to build the core of the system itself in an esoteric language
18:42:11 <pikhq> The PESOIX system should be core. . . And it can't be written in Glass or Def-BF.
18:42:19 <pikhq> They just don't give us enough hardware access.
18:42:55 <RodgerTheGreat> the idea behind using glass was to extend it's builtins to provide those capabilities
18:43:19 <pikhq> Um. . . That'd be called "PESOIX".
18:43:45 <RodgerTheGreat> and hardware access in Def-BF is rather implicit when you map all of a machine's memory to the tape.
18:44:30 <pikhq> If you *really* want to implement other languages in Def-BF or Glass, well, more power to you.
18:44:48 * RodgerTheGreat shrugs
19:18:22 <CakeProphet> From what I've seen of glass... it wouldn't be too hard.
19:18:37 <CakeProphet> The great thing about abstraction is that... well... given enough block-building, you can do just about anything.
19:19:06 <pikhq> CakeProphet: Thus why I like BFM. . .
19:19:26 <pikhq> (just one issue with BFM: I'm betting complex datastructures would take lots of Brainfuck code to do right)
19:20:21 <CakeProphet> hmmm I got a cons-like list constructor for Glass... and Gregor already has a full-blown list constructor (although he calls it "Arr" for array... it's actually like a linked list)
19:20:57 <CakeProphet> I suppose the nest step after that would be hash tables.
19:21:37 <pikhq> Nah. Standard template library. :p
19:21:48 <CakeProphet> Wassat?
19:21:58 <pikhq> The C++ STL.
19:22:39 <CakeProphet> That wouldn't be cool. :P
19:23:00 <pikhq> You've got linked lists. . .
19:23:05 <pikhq> That's one component.
19:23:13 <pikhq> Hash tables are another.
19:23:22 <CakeProphet> I want to steal from C as little as possible. :D
19:24:08 <pikhq> But the C++ STL is probably the only good thing from C-oids!
19:25:36 <CakeProphet> Some other changes to Glass might include some more special methods... to make data structures a little less precarious to work with.
19:26:50 <CakeProphet> Paticularly... a o__ and on__ method, which should "return" a string and a number respectively.... so we can output data structures via the universal O.o method.
19:27:22 <pikhq> That'd be nice.
19:27:39 <CakeProphet> It'd be a pain in the ass to call a unique output method for each class...
19:28:29 <pikhq> And presumably, for lists and arrays, there'd be methods to output specific elements.
19:29:11 <CakeProphet> indexing, probably.
19:29:23 <CakeProphet> call the index method with an integer argument.
19:30:29 <CakeProphet> There will be an iterator to... it would work something like the map() function in other languages.
19:30:35 <CakeProphet> take a method and call it on each element.
19:43:06 <CakeProphet> !glass {M[m(_o)O!0(_o)o.? (_he)<1>=0(_o)o.?]}
19:43:34 <CakeProphet> !glass {M[m(_o)O! (_he)<1>=0(_o)o.?]}
19:43:55 <CakeProphet> !glass {M[m(_o)O! (_he)<1>=(_o)o.?]}
19:44:06 <CakeProphet> aleifhrt.
19:44:16 <CakeProphet> variable assignments don't push to the stack, neato.
19:44:46 <pikhq> Reading the spec could've told you that. . .
19:44:48 <CakeProphet> ....
19:45:00 <CakeProphet> Yes well... specifcations are for nerds.
19:45:15 <CakeProphet> Testing is the real man's measuring tape.
19:46:05 <CakeProphet> !glass {M[m <1><2>(_o)O!0(_o)o.?0(_o)o.?]}
19:46:16 <CakeProphet> !glass {M[m <1><2>(_o)O!0(_o)o.?1(_o)o.?]}
19:46:26 <CakeProphet> !ps
19:46:30 <EgoBot> 1 CakeProphet: ps
19:46:34 <CakeProphet> !glass {M[m <1><2>(_o)O!0(_o)o.?2(_o)o.?]}
19:46:51 <CakeProphet> !glass {M[m <1><2>(_o)O!1(_o)o.?2(_o)o.?]}
19:47:02 <CakeProphet> !glass {M[m <1><2>(_o)O!1(_o)o.?]}
19:47:07 <pikhq> The spec is a description of how the real interpreter behaves. ;)
19:47:14 <CakeProphet> !glass {M[m <1><2>(_o)O!0(_o)o.?]}
19:47:24 <CakeProphet> The real interpreter is a description of how the real interpreter behaves. :P
19:47:45 <pikhq> As it just so happens, the spec and the real interpreter are in perfect agreement.
19:47:54 <CakeProphet> lol ya rite.
19:48:10 <CakeProphet> !glass {M[m<1>~O.o~.?]}
19:48:18 <CakeProphet> !glass {M[m<1>~O.o~?]}
19:48:20 <CakeProphet> *ahems*
19:48:21 <pikhq> !glass {M[m<1>(_o)O!(_o)(on).?]}
19:48:23 <pikhq> ;)
19:48:24 <EgoBot> 1
19:48:36 <CakeProphet> ...damnit
19:48:39 <CakeProphet> I always forget that one.
19:48:44 <pikhq> !glass {M[m<32>(_o)O!(_o)(o).?]}
19:48:55 <CakeProphet> !glass {M[m <1><2>(_o)O!0(_o)(on).?]}
19:48:58 <EgoBot> 2
19:49:06 <pikhq> I don't think O.o outputs numbers.
19:49:28 <CakeProphet> It doesn't (...reading the spec would have told you that...)
19:49:47 <CakeProphet> !glass {M[m <1><2>(_o)O!0(_o)(on).?0(_o)(on).?]}
19:49:50 <EgoBot> 22
19:49:54 <CakeProphet> !glass {M[m <1><2>(_o)O!0(_o)(on).?1(_o)(on).?]}
19:49:56 <EgoBot> 21
19:50:04 <CakeProphet> Yay... stack behavior.
19:50:15 <CakeProphet> !glass {M[m <1><2>(_o)O!1(_o)(on).?0(_o)(on).?]}
19:50:16 <pikhq> Heheh.
19:50:18 <EgoBot> 12
19:50:50 <CakeProphet> So... it seems that stack indexing doesn't append that value permanently to the stack.
19:51:24 <pikhq> I think O.o pops it's argument off the stack.
19:51:31 <CakeProphet> or... the method calls are eating up... yeah
19:51:33 <CakeProphet> what you said.
19:51:46 <CakeProphet> !glass {M[m <1><2>(_o)O!11(_o)(on).?0(_o)(on).?]}
19:51:50 <EgoBot> 21
19:52:11 <pikhq> !glass {M[m <1><2>(_o)O!(_o)(on).?(_o)(on).?]}
19:52:14 <EgoBot> 21
19:52:29 <pikhq> That clinches it.
19:52:34 <CakeProphet> hehe
19:54:44 <CakeProphet> hmmm...
19:55:00 <CakeProphet> I'm wondering how I should denote when the list constructor should stop.
19:55:42 <CakeProphet> "" wouldn't work... because you might want a "" in your list.
19:56:04 <CakeProphet> You could specify the length as a number... but that wouldn't work if you don't explicitly know the link.
20:00:04 <CakeProphet> ...the linked list was a grand idea.
20:00:31 <oerjan> The specification is now slightly more in sync with the interpreter.
20:01:07 <CakeProphet> Never trust your specification.... but it does give some good advice now and then. :D
20:02:29 <CakeProphet> hehe... if Glass had some kind of error handling... I could easily use the (Nil) class to specify when to stop.
20:02:48 <GregorR> Feel free to extend glass as necessary :P
20:03:16 <bsmntbombdood> dodod
20:03:41 * CakeProphet loves Python's exception handling.
20:03:56 <oerjan> but then you couldn't have empty lists as elements of lists?
20:03:59 <bsmntbombdood> what's special about it?
20:04:18 <CakeProphet> Dunno enough about other languages exception handling to tell you what's unique about it. :)
20:04:34 <bsmntbombdood> GregorR: Fix Plof
20:04:41 <bsmntbombdood> 's fors yet?
20:05:32 <oerjan> i think possibly the only values that can be safely tested for are string "" and number 0.
20:05:37 <pikhq> bsmntbombdood: The patch is in; he just needs to make a new tarball.
20:05:47 <CakeProphet> ...yeah.
20:05:59 <GregorR> bsmntbombdood: Yeah ... in the darcs repo :P
20:06:13 <CakeProphet> "" makes more sense than 0
20:06:34 <bsmntbombdood> cool
20:06:42 * bsmntbombdood goes
20:06:52 <bsmntbombdood> (vacation)
20:07:25 <oerjan> because every inquisitive operation other than pure true/false testing probably gives an error on something.
20:07:48 <CakeProphet> yup
20:07:53 <oerjan> although...
20:08:04 <CakeProphet> unless you're using all objects that follow a universal protocol.
20:08:14 <CakeProphet> which... isn't the case with the base string and integer types.
20:08:49 <oerjan> !glass {M[m(_a)A!(_o)O!<1>"hi"(_a)e.?(_o)(on).?]}
20:08:53 <EgoBot> 0
20:08:56 <oerjan> ah.
20:09:25 <oerjan> !glass {M[m(_a)A!(_o)O!<1>(_o)(_a)e.?(_o)(on).?]}
20:09:29 <EgoBot> 0
20:09:57 <oerjan> ok i may be wrong, A.e seems not to crash when given non-numbers.
20:10:19 -!- Sukoshi has joined.
20:10:25 <oerjan> !glass {M[m(_a)S!(_o)O!<1>(_o)(_a)e.?(_o)(on).?]}
20:10:28 <EgoBot> 0
20:10:50 <oerjan> neither does S.e on non-strings.
20:10:59 <oerjan> !glass {M[m(_a)S!(_o)O!(_o)(_o)(_a)e.?(_o)(on).?]}
20:11:02 <EgoBot> 1
20:11:12 <oerjan> !glass {M[m(_a)S!(_o)O!(_a)(_o)(_a)e.?(_o)(on).?]}
20:11:16 <EgoBot> 0
20:11:34 <oerjan> !glass {M[m(_a)A!(_o)O!(_o)(_o)(_a)e.?(_o)(on).?]}
20:11:38 <EgoBot> 1
20:12:12 <oerjan> ok you apparently _can_ check equality of pretty arbitrary things.
20:13:10 <CakeProphet> !glass {(Nil)[(iter),][(null?)1]} {(Con) [(c__)a2=b1=,,] [(car)a*] [(cdr)b*] [(null?)0] [(iter)(_fun)1=,(car)*?(_fun)*?(cdr)*?(iter).?]} {(List)[(build)(_a)A!(_tmp)<1>= (_list)(Nil)!/(_tmp)(_list)*(_list)(Con)!,(_tmp)1""(_s)e.?=\(_list)] } {M[m(_o)O! (_l)(List)! """H" "e" "l" "l" "o" " " "W" "o" "r" "l" "d" "!"(_l)(build).?(MyList)0= (_o)o.(MyList)(iter).?]}
20:13:28 <oerjan> !glass {M[m(_a)A!(_o)O!(_o)o.(_o)o.(_a)e.?(_o)(on).?]}
20:13:30 <EgoBot> 1
20:13:43 <oerjan> !glass {M[m(_a)A!(_o)O!(_o)o.(_o)(on).(_a)e.?(_o)(on).?]}
20:13:47 <EgoBot> 1
20:13:56 <oerjan> whoops!
20:14:07 <CakeProphet> !glass {M[m(_o)O!
20:14:09 <CakeProphet> er...
20:14:09 <RodgerTheGreat> hi, Sukoshi
20:14:10 <EgoBot> OK
20:14:13 <oerjan> !glass {M[m(_a)S!(_o)O!(_o)o.(_o)(on).(_a)e.?(_o)(on).?]}
20:14:16 <EgoBot> 1
20:14:44 <oerjan> ok it doesn't work so well with functions, it seems.
20:15:04 <GregorR> OK, new Plof tarball available.
20:15:11 <CakeProphet> !glass {M[m(_o)O! (_o)(lolbug).?(_o)(on).?]}
20:15:33 <CakeProphet> Was seeing the behavior for undefined methods. :D
20:16:02 <oerjan> that undefined methods crash on lookup should be pretty clear from our recent A class problem.
20:16:32 <oerjan> you don't even need the ?
20:17:10 <GregorR> The action when you try to use an undefined method is "undefined" :P
20:17:12 <Sukoshi> Heya RodgerTheGreat.
20:17:53 <CakeProphet> hmmm.... a language without error handling gains more flexibility if it returns data on weird fuckups... whereas a language that has error handling benefits from having all sorts of "error trips" that can happen.
20:17:58 <RodgerTheGreat> GregorR: are we talking "crash" undefined, or DS9K undefined?
20:18:23 <Sukoshi> Alternatively, you could have the best of both worlds by using error handlers, CakeProphet ;)
20:18:32 <GregorR> RodgerTheGreat: Depends on the implementation ... it's undefined ;)
20:18:44 <RodgerTheGreat> mmm. Java-ey error handling.
20:18:55 <Sukoshi> I like Lispy error handling.
20:19:12 <CakeProphet> I'm pretty sure Python's error handling resembles Java's.
20:19:14 <RodgerTheGreat> how does lisp do error handling?
20:19:16 <Sukoshi> (Heck, you can arbitrarily unwind the call stack with it. How is that not cool?)
20:19:23 <CakeProphet> OO-ish with some sort of try-except-else-finally statement?
20:19:23 <RodgerTheGreat> ooh, nice
20:19:41 <Sukoshi> No no. A *lot* more flexible than a try-except-else thinger.
20:20:10 <GregorR> You mean try-catch-finally? :P
20:20:17 <Sukoshi> Whatever.
20:20:20 <CakeProphet> eh, probably.
20:20:26 <Sukoshi> Errors in Lisp resemble calls to GOTO in many ways.
20:20:29 <CakeProphet> I was wondering how Java did errors.
20:20:29 * RodgerTheGreat throws Exception
20:20:35 <Sukoshi> Without the code hell GOTO breeds.
20:20:59 <GregorR> Java's exception system is a fairly standard try-catch-finally, and you can only throw Objects.
20:21:03 <RodgerTheGreat> GOTOs only create horrible code in the hands of people who don't know what they're doing
20:21:03 <Sukoshi> Of course, you could generalize it to things like try/catch/finally blocks or exception throwing or assertion.
20:21:26 <Sukoshi> s/generalize/specifize/
20:21:29 <GregorR> How about exceptions in Brainfuck?
20:21:44 <pikhq> No such thing.
20:21:45 <CakeProphet> depends on the implementing language.
20:21:47 <Sukoshi> Similar to exceptions in Forth.
20:21:51 <Sukoshi> None.
20:22:07 <RodgerTheGreat> it's called a Try-Fail-OhShit error handling system
20:22:20 <CakeProphet> If BF does something weird... it either A. trips an exception in the implementing language or B. goes off on freaky undefined behavior or C. crashes
20:22:26 <CakeProphet> whatever the underlying language would do...
20:22:36 <pikhq> Or D. goes into an infinite loop.
20:23:05 <pikhq> divvar, when it performs a divide by 0, does an infinite loop. . .
20:23:05 <Sukoshi> It's against the spirit of a compiler/interpreter to error-handle transparently to the underlying language.
20:23:14 <CakeProphet> you could pretty much just call all of it "undefined behavior" since it's.... not... defined.
20:23:26 <RodgerTheGreat> Sukoshi: have you been reading the logs about the esoteric OS discussion?
20:23:33 <Sukoshi> RodgerTheGreat: Nope.
20:23:42 <Sukoshi> My ISP decided to have its first downtime in a few months.
20:24:40 <RodgerTheGreat> long story short, cakeprophet, gregor, pikhq and I have been thinking about writing an estoeric operating system built with glass and a modified form of BF that has pointers.
20:24:58 <Sukoshi> Why no pointers?
20:25:03 <Sukoshi> How will we bootstrap it?
20:25:15 <RodgerTheGreat> no, no, we *added* pointers to BF
20:25:19 <pikhq> In Def-BF.
20:25:23 <Sukoshi> Oh, yeah, yeah.
20:25:35 <Sukoshi> Which one of us is will be the ASM guinea pig?
20:25:36 <RodgerTheGreat> does anyone still have the link to that spec I wrote?
20:25:45 <RodgerTheGreat> not sure just yet.
20:25:52 <RodgerTheGreat> we're still discussing kernel design
20:25:59 <RodgerTheGreat> and what the API needs.
20:26:12 <Sukoshi> Well, who is going to write the BF->ASM compiler?
20:26:26 <CakeProphet> Probably -not- me. :D
20:26:43 <pikhq> Already got one. . . Heard of awib? :p
20:26:44 <CakeProphet> Since I'm not familiar with any assembly... or compiler design.
20:26:45 <Sukoshi> I could try. My experience in ASM lies only in the realm of POSIX-based systems, though.
20:27:00 <Sukoshi> pikhq: But it can't be dependant on any kernel, remember?
20:27:10 <Sukoshi> Which means we'll be using interrupts and happy stuff like that.
20:27:29 <Sukoshi> We need to be able to wrap interrupts in BF too, and devices, and stuff. Suggestions would be nice :)
20:27:52 <oerjan>
20:28:06 <Sukoshi> Happy null to you too.
20:28:35 <RodgerTheGreat> in a nutshell, Def-BF adds the ability to push and pop code and data locations in the form of pointers.
20:28:52 <RodgerTheGreat> four new commands, endless possibilities
20:28:59 <Sukoshi> What are the commands?
20:29:40 <RodgerTheGreat> @- set the program counter to an absolute address, pushing the current location onto a stack
20:29:57 <RodgerTheGreat> :- pop the previous location off the stack, and return to it
20:30:14 <RodgerTheGreat> #- set the pointer to an absolute address, pushing the current location onto a stack
20:30:34 <RodgerTheGreat> ;- pop the previous pointer location off the stack, and return to it
20:30:53 <Sukoshi> Oooh. Now BF has a stack.
20:31:04 <RodgerTheGreat> yeah, I really like it
20:31:33 <Sukoshi> This is going to be hell to develop :P
20:31:34 <RodgerTheGreat> and it's easy to see how you could abstract it a little to build a high-level language
20:31:53 <Sukoshi> Heh. Forth in Def-BF.
20:32:02 <RodgerTheGreat> that'd be fun
20:32:14 <Sukoshi> Are we going to build Glass on top of BF? Ouch.
20:32:23 <GregorR> Easy with C2BF ;)
20:32:24 <CakeProphet> Other way around.
20:32:27 <CakeProphet> I think.
20:32:27 <RodgerTheGreat> I think the consensus is to go the other way
20:32:43 <GregorR> Since it's already done ;)
20:32:52 <CakeProphet> Glass is a much better build-block language.... and yeah...
20:32:59 <CakeProphet> it's already done... just without the new commands.
20:33:00 <RodgerTheGreat> I like Def-BF myself, but Glass is easier to extend to allow low-level hardware access
20:33:12 <Sukoshi> One request!
20:33:17 <Sukoshi> Add in structs!
20:33:17 <CakeProphet> What!?
20:33:21 <CakeProphet> Nope.
20:33:22 <RodgerTheGreat> hm
20:33:29 <CakeProphet> Sounds too much like C...
20:33:35 <Sukoshi> Seriously. How can you build data structures without structs?
20:33:37 <CakeProphet> I don't know what they do... but... oh well.
20:33:42 <CakeProphet> Glass has a classes.
20:33:43 <RodgerTheGreat> can't glass simulate that already?
20:33:45 <CakeProphet> classes
20:33:48 <CakeProphet> Yup.
20:33:54 <Sukoshi> But y'all are forgetting the very point of structs!
20:33:58 <pikhq> I prefer exposing low-level stuff via PESOIX so that all the languages can get low-level stuff. :p
20:33:59 <Sukoshi> A struct is contiguous in memory!
20:34:13 * CakeProphet points to his linked list constructor, and Gregor's array class.
20:34:31 <Sukoshi> But how can you name subsets of the arrays?
20:34:33 <CakeProphet> pikhq, If Glass has all the low level stuff built-in... we can just use glass to give all of them that.
20:34:49 <CakeProphet> Sukoshi, Hmmm?
20:34:50 <pikhq> CakeProphet: That'll work.
20:34:53 <Sukoshi> I really don't want to have to set up methods per-class that simulate assignment to a subset. It's painful.
20:34:56 <GregorR> Raar
20:35:04 <RodgerTheGreat> Def-BF can effectively have structs, and you can compile a higher level language that incorporates them *into* Def-BF
20:35:25 <Sukoshi> I was talking about Glass.
20:35:25 <pikhq> You could even make C2BF support structs!
20:35:39 <CakeProphet> I think what we're going to do is make the kernel an interpreter for Glass. :D
20:35:50 <RodgerTheGreat> pikhq: my thoughts exactly
20:35:52 <CakeProphet> so Glass is... like... -the- kernel.
20:35:56 * Sukoshi suddenly got a vision of a Lisp machine and drools.
20:36:06 <RodgerTheGreat> yeah, there we go
20:36:19 <CakeProphet> oooh... lisp.
20:36:34 <CakeProphet> Lisp would be a great starter language to do all this in. :D
20:36:52 <Sukoshi> There's already a similar project for CL --> Movitz.
20:37:13 <RodgerTheGreat> it would only be esoteric if we used a minimal lisp implementation as the base
20:37:27 <CakeProphet> I just think it would be more amazing that we actually built an operating system out of languages like Glass and modified-BFs :D
20:38:04 <CakeProphet> Scheme is pretty minimal.
20:38:19 <GregorR> Plof is pretty minimal (ha-HAH)
20:38:29 <RodgerTheGreat> when I say minimal, I mean tarpit
20:38:32 <Sukoshi> NOT SCHEME.
20:38:47 <CakeProphet> LOL WHY?
20:38:49 <Sukoshi> Scheme has almost *no* programmer metaphors for pointers.
20:39:01 <CakeProphet> ....damn pointers.
20:39:09 <RodgerTheGreat> embrace pointers
20:39:19 <Sukoshi> Why do you resist pointers?
20:39:28 * CakeProphet immediately conjures up images of an evil C monster stabbing him with sharp pointers.
20:39:33 <RodgerTheGreat> they're insanely useful when you're working at a low level
20:39:55 <CakeProphet> Because of my lack of knowledge and irrational disdain for anything that reminds me of C?
20:39:59 <CakeProphet> Crapp reason I know...
20:40:02 * GregorR huggles C
20:40:03 <RodgerTheGreat> pointers have nothing to do with C, C coders just overuse them for bizarre hacks
20:40:18 <GregorR> No, C coders overuse them because C doesn't give us much else ;)
20:40:34 <RodgerTheGreat> yeah, I guess that's true as well
20:40:42 <CakeProphet> If I knew more about them... and how to use them... I would probably like them more.
20:40:55 <GregorR> Anybody want my BF-interpreting kernel? :)
20:40:59 <Sukoshi> How hard is it to imagine memory contents and a memory address?
20:41:11 <Sukoshi> GregorR: Like I said, who's the ASM guinea pig?
20:41:18 <RodgerTheGreat> GregorR: did you code it just now, or has this been sitting around?
20:41:32 <CakeProphet> Sukoshi, I know -what- they are... I just have no earthly idea why they'd be useful.
20:41:42 <CakeProphet> for
20:41:43 <GregorR> I coded it yesterday - too lazy to get Glass working yet and I'm having problems with IRQs that need to be resolved first anyway :P
20:41:47 * RodgerTheGreat suffers a small aneurism
20:41:53 <Sukoshi> GregorR: Aha!
20:42:06 <Sukoshi> GregorR: Intepreter or compiler?
20:42:12 <GregorR> Interpreter.
20:42:12 <Sukoshi> CakeProphet: How do you implement a linked list?
20:42:20 <RodgerTheGreat> GregorR: think you could add the Def-BF command set?
20:42:24 <Sukoshi> GregorR: Errr, interactive?
20:42:31 <GregorR> RodgerTheGreat: I think /you/ could add the Def-BF command set ;)
20:42:39 <CakeProphet> Sukoshi, with cons pairs?
20:42:42 <GregorR> Sukoshi: Not yet, I don't have IRQs working (necessary for keyboard input)
20:42:52 <Sukoshi> CakeProphet: Does ASM magically give you cons pains?
20:43:03 <CakeProphet> Sukoshi, ...probably not.
20:43:21 <RodgerTheGreat> GregorR: I guess I could take a stab at it- can I see the code?
20:43:52 <CakeProphet> Sukoshi, I've never ventured into low level stuff. Abstraction -hides- this shit from me....
20:44:08 <CakeProphet> Sukoshi, Do go on. :D
20:44:21 <GregorR> Anybody have a SVN repo sittin' around for me to toss it in? :P
20:44:41 <CakeProphet> GregorR, You made a.... kernel?
20:45:53 <GregorR> Yeah - it's a multiboot kernel sans anything fancy with a BF interpreter bolted in :P
20:46:08 <GregorR> It has no memory management, it has no IRQ support, it has no support for processes.
20:46:42 <CakeProphet> We can make it fancier later, I guess.
20:46:56 <CakeProphet> and bolt a Glass interpreter in... what's it written in?
20:47:03 <pikhq> C, I bet.
20:47:33 <GregorR> Of course it's written in C ya' bloody idjits :P
20:47:36 <CakeProphet> oh... correction: -You- can make it fancier later...
20:47:42 <GregorR> C is the only language to write kernels in.
20:48:02 <CakeProphet> GregorR, Bullshit. :P
20:48:34 <GregorR> Well, with a bit of work, C++ could work too.
20:48:37 -!- RodgerTheGreat_ has joined.
20:48:39 <GregorR> And ASM of course.
20:48:55 <RodgerTheGreat_> arrgh
20:48:57 <RodgerTheGreat_> friggin' wifi
20:49:00 <GregorR> But there you have the complete list of every language that any pseudo-mainstream kernel has ever been written in ;)
20:49:18 <CakeProphet> GregorR, There are languages that don't exist yet... and those that people haven't tried.
20:50:08 <CakeProphet> GregorR, A kernel written in the most common kernel-writing language ever isn't really a very positive claim for an esoteric operating system... but it'll do. :P
20:50:38 <RodgerTheGreat_> the main reason people write kernels in C is... wait for it... wait for it... because other people have written kernels in C before.
20:50:49 <CakeProphet> zomg
20:50:51 <CakeProphet> :o
20:50:53 <RodgerTheGreat_> it doesn't really have anything to do with the language
20:51:15 <CakeProphet> It's like how people use qwerty because everyone knows qwerty and that's what they're taught to use.
20:51:15 <GregorR> No, the primary reason that people write kernels in C is that C is high-level enough to be sane to write in, but low-level enough that you can F*** around with the hardware.
20:51:21 <GregorR> Unlike whatever language you were about to mention.
20:51:46 <RodgerTheGreat_> FORTH is equally valid a language for writing a kernel
20:52:04 <RodgerTheGreat_> and that's just what pops into my head
20:52:29 <CakeProphet> hehe... so is Glass With Hardware Shit Bolted On. :D
20:52:30 <RodgerTheGreat_> in some senses, FORTH *is* a kernel
20:52:55 * CakeProphet likes FORTH himself.
20:55:44 <CakeProphet> Of course... we can always draft up a new esolang with lots and lots of hardware support that's just ALMOST sane to write in... and name it The Esoteric Language For Writing Kernels In.... it'll be like C.
20:56:07 <CakeProphet> If it grows in popularity... people will start using TELFWKI forpretty much everything.
20:56:14 <RodgerTheGreat_> if you recall, that's what Def-BF was originally supposed to be
20:56:44 <CakeProphet> RodgerTheGreat But... Def-BF wouldn't work well for that... now that I think about it.
20:59:19 <Sukoshi> I thought we weren't writing it in C.
20:59:30 <Sukoshi> But if it's in C, then we can bootstrap it pretty easily.
20:59:49 <CakeProphet> We weren't... and might not.
21:00:25 <Sukoshi> A flat memory model Forth is incredibly easy to work with to develop hardware.
21:01:11 -!- RodgerTheGreat has quit (Read error: 110 (Connection timed out)).
21:01:49 <CakeProphet> I say we do it in true esolang fashion... make a new language for doing the job. (Def-BF would work... but not well.)
21:03:38 -!- RodgerTheGreat_ has changed nick to RodgerTheGreat.
21:06:27 <CakeProphet> hmmm... FORTH does sound good though. It would work great for definiing new grammar (such as for writing an interpreter over the kernel)
21:06:45 <CakeProphet> and it's reverse polish notation.... which makes it fun. :D
21:07:37 <CakeProphet> heh... implementing Glass over FORTH wouldn't even require much of a parser.
21:10:51 <GregorR> Am I the only person who thinks it's irrelevent if the very core interpreter is written in C? :P
21:12:45 <CakeProphet> I think it's very relevant. :o
21:12:49 <RodgerTheGreat> I don't see it as a huge issue, but I detest coding in C. If the kernel is C, I'm not writing it
21:13:02 <oerjan> no. of course we will bootstrap a Glass compiler in Glass later.
21:13:09 <CakeProphet> Yeah... that too.
21:13:35 <CakeProphet> Why not Forth though? :D
21:13:38 <GregorR> Hey, if you can compile Glass to metal plus have proper hardware abstraction in there, more power too ya'.
21:13:45 <GregorR> s/too /to /
21:14:35 <CakeProphet> FORTH is like Glass minus classes plus tons of low-level hardware support.
21:15:02 <CakeProphet> ...delimited by whitespace. :D
21:15:39 <GregorR> Pffffffff
21:15:42 <GregorR> Whitespace is for pansies.
21:15:48 <GregorR> Except in the language Whitespace.
21:16:15 <CakeProphet> hell, FORTH can fucking compile itself. :D
21:17:37 <CakeProphet> hmmm... it's kind of weird that the class and function syntax of Glass is the only part that's not RPN
21:17:51 <CakeProphet> Unless... } is the actual begin-class command. :D
21:19:01 <pikhq> GregorR: You're not the only one who thinks that.
21:20:26 <GregorR> pikhq: Thank you X_X
21:22:04 * pikhq wants to see the core interpreter in C, with various interpreter modules. . .
21:22:41 <CakeProphet> forth forth forth!!!
21:22:43 <CakeProphet> :P
21:22:56 <CakeProphet> Yeah... whatever you wanna do.
21:22:59 <GregorR> svn co https://brainfuck.svn.sourceforge.net/svnroot/brainfuck/esokern/trunk
21:23:26 <CakeProphet> I'm not the one doing the coding... plus it's a minor consideration.
21:23:48 <CakeProphet> Except.. I can't read or code in C very well... so I can't do much with the kernel, not that I would normally want to muck with the kernel.
21:24:04 * pikhq does C decently
21:24:09 <pikhq> I do Tcl natively. . .
21:24:14 <pikhq> :)
21:28:05 <GregorR> Developers, developers everywhere, and not a drop of C X_X
21:28:25 <RodgerTheGreat> woo
21:41:31 <CakeProphet> Fuck C.
21:41:44 <CakeProphet> :) (smileys make things sound nicer)
21:41:56 -!- RodgerTheGreat_ has joined.
21:42:12 * CakeProphet waves.
21:42:20 <RodgerTheGreat_> hi again
21:42:31 <RodgerTheGreat_> curse this unreliable connection
21:46:10 <CakeProphet> I've developed a liking to postfix notation. :)
21:48:04 <bsmntbombdood> RPN is great
21:48:37 * RodgerTheGreat_ strokes his Hp-12C lovingly
21:49:11 <CakeProphet> I'd like to do a confusing infix notation language. :D
21:49:13 -!- RodgerTheGreat has quit (Read error: 110 (Connection timed out)).
21:53:35 * bsmntbombdood wants an HP calc
21:53:52 * bsmntbombdood laughs reading the scrollback of you guys arguing
21:58:32 * Sukoshi is amused as she reads above.
21:58:38 <Sukoshi> I'm fine coding in either C or Forth.
21:59:16 <Sukoshi> Just, the nature of low-level code tends to favor Forth a bit more, IMO.
21:59:33 <Sukoshi> (Because it's easier to build up (much like Lisp))
22:02:40 * bsmntbombdood sees "she"
22:02:45 * bsmntbombdood drools
22:03:07 <Sukoshi> The main plus is that Forth is interactive.
22:04:48 <GregorR> lol
22:04:58 <GregorR> bsmntbombdood: Hands off ya' blimey pervert!
22:25:00 <bsmntbombdood> heh
22:25:08 <bsmntbombdood> I keep getting disconnected
23:13:40 <oerjan> Why, happy new year!
23:20:18 -!- RodgerTheGreat has joined.
23:23:18 -!- RodgerTheGreat has quit (Client Quit).
23:37:26 -!- RodgerTheGreat_ has quit (Read error: 110 (Connection timed out)).
23:56:01 -!- cmeme has quit (Remote closed the connection).
23:57:22 -!- cmeme has joined.
←2006-12-30 2006-12-31 2007-01-01→ ↑2006 ↑all