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: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:04:22 <oklopol> !glass {M[m(_o)0O!"wheee"o.?]}
00:04:38 <oklopol> !glass {M[m(_o)0O!"wheee"1o.?]}
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:08:20 <CakeProphet> hehe... I'd do the kernel in Python myself. :D
00:09:07 <oklopol> i still don't know what will be the goal for the OS
00:09:33 <oklopol> to be written in esoteric langs, to run esoteric langs, or both
00:09:52 <oklopol> the middle one is the one i'd use :)
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: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: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:52 <CakeProphet> I dunno... I'm starting to reconsider Def-BF :/
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:27 <oklopol> how else would you do functions?
00:17:58 <oklopol> that would be absolute addressing
00:18:06 <CakeProphet> give them symbolic names that lead to memory addresses.
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: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: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: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: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: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: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:28:17 <oklopol> eh, now when executing the program
00:28:34 <oklopol> would there be "function insertion" in the codestring or smth?
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:21 <oklopol> a program being a normal function?
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: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:57 <CakeProphet> we were just busy being confused by each others explainations.
00:37:24 <CakeProphet> There should be no difference between a function and a program.
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:39:21 <oklopol> i mean, isn't it basically a name to address?
00:39:32 <CakeProphet> oh... that's for name-to-address stuff... that's different.
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:54 <GregorR> And what language will you write all this in?
00:41:09 <GregorR> (You'll excuse me if I'm dripping with scepticism)
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: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: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: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:36 <oklopol> "<CakeProphet> It has most of the high-level constructs needed to translate directly to machine code." i don't quite follow
00:57:17 <CakeProphet> well it has a division operator... for example... which could translate directly to the DIV instruction.
00:57:41 <oklopol> "<CakeProphet> Glass could be an efficient base language." missed this line
00:58:16 <CakeProphet> It seems just similar enough to assembly to make a nice translation... while still being freaky as crap.
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:26 <CakeProphet> the postfix is just a minor setback until you get used to it.
01:00:31 <GregorR> Yeah, it's a miserable failure in that sense ;)
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:04:18 <GregorR> That's only a sensible shortform if it's High-Level DeF-BF
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: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: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:59 <CakeProphet> Glass is funkier though... and less tiring to type. :D
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: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:11:18 <GregorR> Glass' classes are a superset of ORK's classes I believe.
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: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:38 <CakeProphet> GregorR, You didn't tell me there was a secret!!!
01:13:06 -!- CakeProphet has changed nick to SevenInchBread.
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: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:43 <GregorR> !glass {M[m(_o)O!(_a)A!<2><2>(_a)a.?(_o)(on).?]}
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: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:51 <oklopol> i mean if i did !glass {A}{S}{M[m]}, my interpretor should no longer have them?
01:18:10 <GregorR> oklopol: However, it would only /permanently/ remove them if you used a 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: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:20 <oklopol> !glass {M["+++."m(_bf)0BF!(run).?]}
01:20:21 <GregorR> Errrm, that was borken a bit :)
01:20:30 <GregorR> !glass {M[m(_b)(BF)!">+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.>>>++++++++[<++++>-]<.>>>++++++++++[<+++++++++>-]<---.<<<<.+++.------.--------.>>+."(_b)(bf).?]}
01:25:41 <GregorR> I have Arr, which is really a LLL despite being called an Arr[ay] :P
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: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:42 <GregorR> ORK's compiler is OSS, have at it ;)
01:29:41 <GregorR> (It's been a while since I wrote it ;) )
01:29:59 <SevenInchBread> Glass would more readily translate to assembly, methinks.
01:32:27 <GregorR> Incidentally, who the bork is SevenInchBread?
01:32:35 -!- SevenInchBread has changed nick to CakeProphet.
01:32:48 <GregorR> You prophesized bread instead of cake then?
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:56 -!- GrandmotherChaos has changed nick to SevenInchBread.
01:39:32 <EgoBot> realloc: Cannot allocate memory
01:40:04 <GregorR> That was just EgoBF dying ;)
01:40:45 <GregorR> It is like a bunch of subprocesses literally.
01:41:32 -!- cmeme has quit ("Client terminated by server").
01:41:43 -!- cmeme has joined.
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:27 <GregorR> I'm just skeptical is all.
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: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: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: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:57:11 <oerjan> i still suggest you add ,, to the constructor.
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:59:45 <oerjan> only if you don't need to use anything below it in the stack
02:01:09 <SevenInchBread> So objects can have customized output with just one universal call.
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:03:08 <SevenInchBread> like in the cons constructor... how would we know what type of elements we're dealing with?
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:49 <SevenInchBread> the (ols) method I just added would only work for strings...
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:35 <oerjan> it means you can wrap any object which doesn't have an o method in another object which does the translation.
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: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: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: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:18:17 <oerjan> !glass {M[m (_o)O! "Test" (_o) "o".?]}
02:19:31 <oerjan> you have some serious stack underflow there.
02:20:39 <oerjan> trying to get values from an empty stack
02:21:52 <oerjan> !glass {M[m(_o)O!(_o)(on).]}
02:22:40 <EgoBot> 1 SevenInchBread: glass
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: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: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:40:20 <oerjan> !glass {M[m(_a)A!(_o)O!<4.0><3>(_a)d.?(_o)(on).?]}
02:40:27 <oerjan> !glass {M[m(_a)A!(_o)O!<4><3>(_a)d.?(_o)(on).?]}
02:40:52 <oerjan> !glass {M[m(_a)A!(_o)O!<4.0><3>(_a)a.?(_o)(on).?]}
02:41:59 -!- oerjan has quit ("Leaving").
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: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:49 <GregorR> Well, public domain is just plain bad, so *shrugs*
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:30 <GregorR> That's the f***'d-up-ness of copyright.
02:49:49 <GregorR> I prefer MIT minus attributionl
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: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: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:45 <GregorR> ihope: IANAL, this is just what I've been told.
02:54:06 <ihope> CakeProphet: yes, he is.
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:24 <ihope> What platform are we going to build this on, exactly?
02:56:41 <ihope> Not x86, I take it.
02:57:00 <GregorR> It would probably run /on/ x86
02:57:05 <GregorR> But would not /run/ x86 code.
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:45 <ihope> For eSOAteric Platform.
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:13 <GregorR> I certainly agree with that :P
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: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: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: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:38 <CakeProphet> same language... new builtin class. It's a "feature request" :P
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:55 <CakeProphet> Def-BF.... a version of BF with memory addressing for subroutines.
03:12:00 <ihope> (And which, for that matter?)
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: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: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:16:10 <ihope> We could have "enter user mode" be the only instruction... then again, that gives no control whatsoever.
03:16:33 <ihope> "Enter user mode" and "fudge trap registers"?
03:16:35 <CakeProphet> fuck your userless usermode switching language.
03:17:31 <ihope> How, exactly, does one load a program and run it with Glass?
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:41 <GregorR> It could have interpreters written in Glass (or as object files)
03:19:00 <ihope> You mean emulation?
03:19:24 <ihope> Portable Executable files contain x86 assembly, don't they?
03:19:38 <ihope> And whatever ELF stands for, too?
03:20:17 <ihope> Interpreters are a little slow, you know.
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 <GregorR> Slow is the last of our problems.
03:21:41 <ihope> sO WE DON'T CARE ABOUT SPEED, THEN?
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:23:47 <ihope> Be back in a while?
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: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:29:10 -!- Asztal has joined.
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:15 -!- CakeProphet has changed nick to SevenInchBread.
03:56:11 -!- SevenInchBread has changed nick to CakeProphet.
04:09:00 <GregorR> HEY CAKEPROPHET, time to stop using capslock :P
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:12:14 <GregorR> Um, at some level there has to be a glass interpreter.
04:12:16 <CakeProphet> I surely wouldn't want to bathe with glassy soap.
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:22:48 <RodgerTheGreat_> looks like my poor little language has already fallen from vogue, based on the logs
04:23:16 <GregorR> Specification minus implementation equals zero.
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:25:11 <Asztal> Good. I hated them anyway
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:44 <CakeProphet> I never made claims to pointers being usable.
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: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: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 <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: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: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: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: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:55:33 <RodgerTheGreat_> Def-BF makes it easier to fit loose BF programs into a framework for controlling them as a group
04:56:30 <RodgerTheGreat_> it wouldn't be impossible, but it'd make it a bitch to add and remove things
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: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:42 <RodgerTheGreat_> well, yeah, but we need a handful of useful ones to build the core OS with
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:03:54 -!- digital_me has quit ("holy lol!").
05:04:19 <CakeProphet> I think it would be cool to have like... a scrollable "plain".
05:05:39 <GregorR> Here's the problem with every EsoOS ever: Nobody can make up their F'ing mind on anything.
05:06:48 <CakeProphet> we can take eternity goign back and forth if we want.
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:23 <GregorR> No, what we need is an actual design for a kernel. How the languages correspond is fluff.
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:11:40 <CakeProphet> well.... I really have NO clue how to do a kernel.
05:12:18 <GregorR> I can write a kernel, but I don't know what anybody actually wants.
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: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:21 <GregorR> With a good hardware layer, all of that can be hypothetically written in the language of choice.
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:18:05 <RodgerTheGreat_> which has the added benefit of an infinite supply of "my kernel's got wood" jokes
05:18:24 <GregorR> Namely, "my kernel's got wood"
05:19:29 <CakeProphet> mmm... the whole save-to-disk-explicitly thing seems kind of outdated.
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:29:34 <CakeProphet> GregorR, You've been involved in other esoos projects that failed? :D
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: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: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:26:00 <oerjan> !glass {M[m(_o)O!(_t)(_o)*=/(_t)"test"(_o)o.?(_t)<0>=\" ho"(_o)o.?]}
11:26:14 <oerjan> !glass {M[m(_o)O!(_t)(_o)o.=/(_t)"test"(_o)o.?(_t)<0>=\" ho"(_o)o.?]}
11:26:27 <oerjan> !glass {M[m(_o)O!(_t)<1>=/(_t)"test"(_o)o.?(_t)<0>=\" ho"(_o)o.?]}
11:26:41 <oerjan> !glass {M[m(_o)O!(_t)"hi"=/(_t)"test"(_o)o.?(_t)<0>=\" ho"(_o)o.?]}
11:27:49 <oerjan> !glass {M[m(_o)O!(_t)O*=/(_t)"test"(_o)o.?(_t)<0>=\" ho"(_o)o.?]}
11:33:00 <oerjan> !glass {M[m(_o)O!(_t)<-1>=/(_t)"test"(_o)o.?(_t)<0>=\" ho"(_o)o.?]}
11:33:29 <oerjan> {M[m(_o)O!<-1>(_o)(on).?]}
11:33:48 <oerjan> {M[m(_o)O!<-1>(_o)o.?]}
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: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:24:52 -!- ivan` has joined.
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.
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: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: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.
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: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: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: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: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: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: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:07 <pikhq> The spec is a description of how the real interpreter behaves. ;)
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:48:21 <pikhq> !glass {M[m<1>(_o)O!(_o)(on).?]}
19:48:44 <pikhq> !glass {M[m<32>(_o)O!(_o)(o).?]}
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:54 <CakeProphet> !glass {M[m <1><2>(_o)O!0(_o)(on).?1(_o)(on).?]}
19:50:15 <CakeProphet> !glass {M[m <1><2>(_o)O!1(_o)(on).?0(_o)(on).?]}
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:46 <CakeProphet> !glass {M[m <1><2>(_o)O!11(_o)(on).?0(_o)(on).?]}
19:52:11 <pikhq> !glass {M[m <1><2>(_o)O!(_o)(on).?(_o)(on).?]}
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: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:56 <oerjan> but then you couldn't have empty lists as elements of lists?
20:04:18 <CakeProphet> Dunno enough about other languages exception handling to tell you what's unique about it. :)
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:59 <GregorR> bsmntbombdood: Yeah ... in the darcs repo :P
20:07:25 <oerjan> because every inquisitive operation other than pure true/false testing probably gives an error on something.
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:09:25 <oerjan> !glass {M[m(_a)A!(_o)O!<1>(_o)(_a)e.?(_o)(on).?]}
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: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:12 <oerjan> !glass {M[m(_a)S!(_o)O!(_a)(_o)(_a)e.?(_o)(on).?]}
20:11:34 <oerjan> !glass {M[m(_a)A!(_o)O!(_o)(_o)(_a)e.?(_o)(on).?]}
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:43 <oerjan> !glass {M[m(_a)A!(_o)O!(_o)o.(_o)(on).(_a)e.?(_o)(on).?]}
20:14:13 <oerjan> !glass {M[m(_a)S!(_o)O!(_o)o.(_o)(on).(_a)e.?(_o)(on).?]}
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: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:55 <Sukoshi> I like Lispy error handling.
20:19:12 <CakeProphet> I'm pretty sure Python's error handling resembles Java's.
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: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:26 <Sukoshi> Errors in Lisp resemble calls to GOTO in many ways.
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:29 <GregorR> How about exceptions in Brainfuck?
20:21:47 <Sukoshi> Similar to exceptions in Forth.
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: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:25:35 <Sukoshi> Which one of us is will be the ASM guinea pig?
20:26:12 <Sukoshi> Well, who is going to write the BF->ASM compiler?
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: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: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: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:32:14 <Sukoshi> Are we going to build Glass on top of BF? Ouch.
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: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: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: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: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:56 * Sukoshi suddenly got a vision of a Lisp machine and drools.
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:19 <GregorR> Plof is pretty minimal (ha-HAH)
20:38:49 <Sukoshi> Scheme has almost *no* programmer metaphors for 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: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: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: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:42:06 <Sukoshi> GregorR: Intepreter or compiler?
20:42:12 <Sukoshi> CakeProphet: How do you implement a linked list?
20:42:24 <Sukoshi> GregorR: Errr, interactive?
20:42:31 <GregorR> RodgerTheGreat: I think /you/ could add the Def-BF command set ;)
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: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:21 <GregorR> Anybody have a SVN repo sittin' around for me to toss it in? :P
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:56 <CakeProphet> and bolt a Glass interpreter in... what's it written in?
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:34 <GregorR> Well, with a bit of work, C++ could work too.
20:48:37 -!- RodgerTheGreat_ has joined.
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: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:52:29 <CakeProphet> hehe... so is Glass With Hardware Shit Bolted On. :D
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.
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: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:38 <GregorR> Hey, if you can compile Glass to metal plus have proper hardware abstraction in there, more power too ya'.
21:14:35 <CakeProphet> FORTH is like Glass minus classes plus tons of low-level hardware support.
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:22:04 * pikhq wants to see the core interpreter in C, with various interpreter modules. . .
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:09 <pikhq> I do Tcl natively. . .
21:28:05 <GregorR> Developers, developers everywhere, and not a drop of C X_X
21:41:56 -!- RodgerTheGreat_ has joined.
21:46:10 <CakeProphet> I've developed a liking to postfix notation. :)
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: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:03:07 <Sukoshi> The main plus is that Forth is interactive.
22:04:58 <GregorR> bsmntbombdood: Hands off ya' blimey pervert!
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.