00:00:07 It's easy to parse, being stack-based... and is pretty capable of doing things despite its erm... verbosity. 00:00:13 Speed has never really been a concern of mine. 00:00:37 sure, just the (System)-class to access memory management etc and it would be a nice language for the core 00:01:12 !glass {M[m(_o)O!"wheee"(_o)o.?]} 00:01:15 wheee 00:01:20 I'd like to try some orthogonal persistency. 00:01:36 plus it looks cool when you do output... like a bunch of confused faces. 00:02:29 It's definetely one of the more structure esoteric languages. 00:02:35 d 00:04:22 !glass {M[m(_o)0O!"wheee"o.?]} 00:04:32 whoops :D 00:04:38 !glass {M[m(_o)0O!"wheee"1o.?]} 00:04:41 wheee 00:05:01 It seems kind of redundent to do it that way. 00:05:41 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 it was smaller yay \o/ 00:08:20 hehe... I'd do the kernel in Python myself. :D 00:08:25 but that's not very esoteric. 00:09:07 i still don't know what will be the goal for the OS 00:09:18 to be esoteric... and try out shit. 00:09:23 no real super-huge goal in mind. 00:09:33 to be written in esoteric langs, to run esoteric langs, or both 00:09:50 both would be nice. 00:09:52 the middle one is the one i'd use :) 00:09:56 and that 00:10:06 Any computer can run esoteric langs. 00:10:16 but we want our computer to consist of esolangs. :D 00:10:29 that's what i meant by that 00:11:27 we could try out some new OS design concepts... I like what uuu is doing currently. 00:12:01 i read that, basically just realizing no need to separate files and variables 00:12:09 *have 00:12:35 I like the functional (and/or object oriented) approach to looking at it. 00:12:36 have i been hit in the head a few times recently? every goddamn sentence is incomplete... 00:13:02 ye, on the other hand, i'd like this one to be the Bf-thing 00:13:28 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 a-ha? 00:14:07 the other goal is to make esolangs into something useful. :D 00:15:24 i'd like to have the Def-BF running OS on my computer 00:15:45 i mean, it exclusively 00:15:48 this one sucks 00:15:52 I dunno... I'm starting to reconsider Def-BF :/ 00:16:05 okay 00:16:12 It's definetely a useful estension to BF... but should it be the entire kernel? 00:16:53 i have an entire system in my mind already, i'd say no 00:17:06 entire kernel written on it or? 00:17:13 >.> I kinda don't like the idea of Def-BF using Absolute addresses. 00:17:15 Why does it need to do that? 00:17:27 how else would you do functions? 00:17:39 ....names? 00:17:58 that would be absolute addressing 00:18:06 give them symbolic names that lead to memory addresses. 00:18:16 == absolute addressing 00:18:39 my idea was the names 00:18:39 ...by "absolute addressing" I meant requiring the entire numeric memory address to call a function. 00:19:04 the names was the original concept... RodgerTheGreat surprised me with memory addresses. 00:19:12 huh? same thing 00:19:18 ... 00:19:24 It's very different. 00:19:30 except memory addressing keeps the bf 00:19:43 names, and it's only bf by algorithmic slowness 00:19:43 "add" is much easier to remember than "0344534" 00:20:03 yes, and i proposed an OS function to ease that up 00:20:29 so now you have to remember the Os functions memory address... which changes each use. 00:20:34 what's the difference? 00:20:58 you can have names for OS functions 00:21:10 If the language requires memory addresses at some point... you will have to use memory addresses at some point. 00:21:16 which are just changed into right function numbers 00:21:44 but, you cannot have names for other than OS functions with the same lookup method 00:21:46 How will you call the OS function from within the program without specifying its memory address? 00:22:39 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 as OS functions can have static addresses 00:23:06 what will do this compiling? 00:23:19 programmer 00:23:34 or the compiler if the programmer does a few macros 00:23:47 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 because 00:23:57 back 00:24:02 it's a totally different thing 00:24:09 what I'm saying is... why even bother with detouring around a maleable language spec? 00:24:21 when you can just change the language spec? 00:24:38 then why use bf? 00:24:54 We're not... we're using functional bf. 00:25:04 with callable functions... 00:26:01 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 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 when you can easily simulate that with a few OS functions 00:27:01 so... should i use a module at 15 from 189384, i should put 189369 <'s together? 00:27:29 oh 00:27:34 memory jumps okay? 00:27:49 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 there's no point. 00:28:17 eh, now when executing the program 00:28:34 would there be "function insertion" in the codestring or smth? 00:29:00 hmmm? 00:29:20 hmm 00:29:23 forget that 00:30:04 but, would the uuu's no files -system be used? 00:30:20 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 when you require all the extra work to call a function... it's not really worth it. 00:30:44 but, are you talking about function calls inside one program? 00:30:48 we wouldn't use the typical file system... it would be a different model. 00:31:05 I'm just talking about function calls. 00:31:10 okay 00:31:21 a program being a normal function? 00:31:35 Sure. 00:32:48 but no absolute addresses? 00:32:58 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 there could be a registry of names to absolute addresses built-in to the OS. 00:33:47 or is that what you were saying we do? 00:34:11 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 "to me it sounded like you said we should build..." 00:34:46 (name to look up) <<< would be a sensible syntax for looking up the address of a function to exec 00:35:14 but i guess i'll see the point of making bf more functional at some point 00:35:30 RodgerTheGreat_, oh... and hey. 00:35:42 * RodgerTheGreat_ waves 00:35:57 we were just busy being confused by each others explainations. 00:36:03 :D 00:36:05 ye 00:36:06 hi, RodgerTheGreat_ 00:37:24 There should be no difference between a function and a program. 00:37:35 true 00:37:54 no need to stuff applications in huge directory paths. 00:38:21 just stuff them in a single os-level function (let's call them a blob for distinction) 00:38:41 or, a dictionary :D 00:38:45 >.> 00:38:51 a dictionary is like a hash table. 00:38:57 doesn't describe a program too well. 00:39:04 isn't that what we want? 00:39:10 hmm 00:39:18 programs as hash tables? 00:39:21 i mean, isn't it basically a name to address? 00:39:25 nje 00:39:32 oh... that's for name-to-address stuff... that's different. 00:39:33 yeah 00:39:48 I'm talking about what we're going to do for our new "file system". 00:40:24 The name-to-address would just be an orthogonally persistent hash table. 00:40:31 but, wouldn't that make everything use just global variables? 00:40:41 the no-sub-thingies 00:40:54 And what language will you write all this in? 00:41:05 Each program would have a scope. 00:41:09 (You'll excuse me if I'm dripping with scepticism) 00:41:13 * RodgerTheGreat_ waves the Def-BF flag 00:41:14 :D 00:41:17 Err, skepticism 00:41:20 Get a towel! 00:41:36 Possibly def-BF if we don't change our mind. 00:41:42 and I'm somehow unsurprised that gregor is being pessimistic about the project. 00:42:07 it seems it's an OS written in Def-BF running only Def-BF 00:42:10 RodgerTheGreat_, Do we have to use absolute memory address in def-bf? 00:42:27 It's going to be a really long haul if we actually want to produce a useable OS in the end 00:42:37 I think we might want to reconsider the kernel language though... 00:42:48 as ok said... bf isn't terribly efficient. 00:42:56 it can be if you do it right. 00:43:57 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 Can't we use symbolic names and map them through some kind of startup-generated hash table? 00:45:21 why not both? 00:46:29 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 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 heh 00:47:40 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 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 RodgerTheGreat_, But is def-BF doing to be an efficient core langauge? 00:51:56 it ultimately depends on the level of complexity we build into the compiler 00:52:23 Maybe we should use an Esoteric Assembly Candy Wrapper Language 00:52:25 but, my example from before, there is no way to even make the compiler understand a simple division 00:52:45 and compile it into efficient machine code 00:53:18 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 Glass could be an efficient base language. 00:54:42 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 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 well, that's way out of my league, and at that point i naturally say it's impossible :) 00:56:27 heh 00:56:36 " It has most of the high-level constructs needed to translate directly to machine code." i don't quite follow 00:56:40 just my suggestion- never claim something 00:56:48 is impossible on #Esoteric. :) 00:56:48 :D 00:57:17 well it has a division operator... for example... which could translate directly to the DIV instruction. 00:57:30 few esolangs have a division operator. ;) 00:57:41 " Glass could be an efficient base language." missed this line 00:57:44 sorry 00:58:16 It seems just similar enough to assembly to make a nice translation... while still being freaky as crap. 00:58:21 Not to mention it's easy to parse. 00:58:33 Trivial to parse, even ;) 00:58:47 I still don't know what the bork is with A.a X_X 00:59:18 how can it even get bugs without a rebuild? 00:59:30 i mean, worked fine before 00:59:31 and the OO gives us a nice organizational structure to easily create higher-level stuff. 01:00:07 It's probably the most useful esolang I know. :P 01:00:12 Hah :P 01:00:26 the postfix is just a minor setback until you get used to it. 01:00:30 then it's strangely intuitive. 01:00:31 Yeah, it's a miserable failure in that sense ;) 01:01:16 After a few hours or so I adapted to it. 01:01:52 so, we're veering towards a glass-based kernel, using Def-BF for less critical parts of the system? 01:02:09 that's where I'm veering... dunno if it's the consensus. 01:02:24 if we have problems with that... we can always just try something different. 01:02:27 If I knew what Def-BF was :P 01:02:38 http://nonlogic.org/dump/text/1167512946.html 01:02:42 fortunately we have no deadline to actually finish this thing. 01:02:56 If I got off my lazy bum and finished C2BF, that'd help ;) 01:03:04 GregorR, To avoid cringing... you can ignore most of the high-level part... it's not important to the actual language. 01:03:18 pfft 01:03:37 everybody's hating on HLDFBF 01:03:37 It's like CBrainfuck! :o 01:03:52 HLDFBF? 01:03:59 high-level variant of def-bf 01:04:03 High-Level Def-BF 01:04:18 That's only a sensible shortform if it's High-Level DeF-BF 01:04:29 jeje 01:04:55 a 6-letter acronym isn't really a sensible shortform in *any* instance... 01:04:57 Out of all the esolangs, Glass seems like one of the better choices for such a crucial role. 01:05:12 Without the high-level stuff, it's sort of like BF + setjmp 01:05:30 yeah... it's BF with subroutines. 01:06:27 esentially 01:06:33 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 I thought it was the simplest addition I could make to BF that would allow functions without too much trouble 01:07:01 OO and (real) functional languages are my cup of tea. 01:07:10 * GregorR hands CakeProphet Plof. 01:07:18 heh 01:07:21 link? 01:07:29 http://www.codu.org/plof/ 01:07:39 hell, we could go with another famous gregor language and write the kernel in ORK. 01:07:51 There is such a thing as a kernel. 01:08:00 A kernel can execute a function. 01:08:05 A kernel can execute a syscall. 01:08:39 lol 01:08:45 hahahaha 01:08:46 yes... ORK 01:08:59 Glass is funkier though... and less tiring to type. :D 01:09:09 Plof basically looks like... C. 01:09:12 if ORK can meet the I/O requirements, I'm all for using it to write the kernel. 01:09:19 CakeProphet: Plof isn't esoteric by nature :P 01:09:30 talk about self-documenting code. 01:09:39 hahahaha 01:10:00 Both maybe? 01:10:18 Or do we need a kernel before we can do the inter-language data stuff? 01:10:49 I think Ork classes and objects could translates almost trivially into Glass. :D 01:10:56 hmmm... 01:11:18 Glass' classes are a superset of ORK's classes I believe. 01:11:31 hahaha... Glass was written in Ork? 01:11:36 !glass {M[m(_o)O!<2><2>~A.a~(_o)o.?]} 01:11:50 I just had a thought about why A.a isn't working ... 01:11:51 What's the ~ for? 01:11:59 !glass {M[m(_o)O!<2><2>~A.s~(_o)o.?]} 01:12:03 CakeProphet: It's the secret way of getting builtin functions :P 01:12:07 CakeProphet: You're not supposed to use it X_X 01:12:09 !glass {M[m(_o)O!<2><2>~A.a~(_o)(on).?]} 01:12:13 4 01:12:15 hah! 01:12:16 .... 01:12:17 ZOMG 01:12:23 * CakeProphet dies. 01:12:38 GregorR, You didn't tell me there was a secret!!! 01:12:53 ....guess that's why it's a secret? 01:13:02 ARGH 01:13:06 -!- CakeProphet has changed nick to SevenInchBread. 01:13:09 My suspicion was right! 01:13:15 * GregorR bangs his head into a wall 01:13:23 Somebody overwrote the A class in EgoBot, and it cached the borken one :) 01:13:59 aha! 01:14:24 !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 OK 01:14:33 ... 01:14:43 !glass {M[m(_o)O!(_a)A!<2><2>(_a)a.?(_o)(on).?]} 01:14:47 4 01:14:50 * GregorR takes a bow. 01:15:15 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 i was that someone! :DDDD 01:15:31 i mean, sorry, very sorry 01:15:35 * GregorR shakes his fist :P 01:15:52 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 this is weird - you mean EgoBot has just one eternally running Glass interpreter? :) 01:16:46 errr.... it's a part of the language to be able to rewrite standard classes? :D 01:17:28 oerjan: No, it reruns it, but the standard interpreter can cache classes if you'd like. 01:17:32 oklopol: Yes. 01:17:51 i mean if i did !glass {A}{S}{M[m]}, my interpretor should no longer have them? 01:17:52 ORK would be awesome... as well as Glass. :D 01:18:00 oklopol: Correct. 01:18:10 oklopol: However, it would only /permanently/ remove them if you used a cache. 01:18:37 what do you mean? 01:18:40 by cache 01:19:00 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 So I can use the BF class on EgoBot, since I entered it once a long long time ago. 01:19:21 wow 01:19:24 show it 01:19:46 ... the cache, the BF class, or the BF class in action? 01:20:13 !glass {M{m(_b)(BF)!">+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.>>>++++++++[<++++>-]<.>>>++++++++++[<+++++++++>-]<---.<<<<.+++.------.--------.>>+."(_b)(bf).?]} 01:20:15 OK 01:20:20 !glass {M["+++."m(_bf)0BF!(run).?]} 01:20:21 Errrm, that was borken a bit :) 01:20:25 OK 01:20:30 !glass {M[m(_b)(BF)!">+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.>>>++++++++[<++++>-]<.>>>++++++++++[<+++++++++>-]<---.<<<<.+++.------.--------.>>+."(_b)(bf).?]} 01:20:35 Hello World! 01:20:59 wow cool 01:21:06 can i see the codE? 01:21:44 One sec. 01:22:39 Hm :P 01:22:47 Pastebin! :P 01:25:01 GregorR, Do you have a list constructor? 01:25:04 I was making one myself. 01:25:24 lemme see if egobot still has it. 01:25:28 http://pastebin.ca/297373 01:25:41 I have Arr, which is really a LLL despite being called an Arr[ay] :P 01:26:56 LLL? 01:27:22 !glass {M[m(_o)O!(_c)(Con)! <2><3>(_c)(build).?(cdr).?(_o)o.?]} 01:27:29 oklopol: Linear Linked List 01:27:33 ah 01:28:02 I am apparently the only person on the planet that shortens it to LLL ;) 01:28:18 The syntax for a singleton class in ORK should be "There can be only one " 01:28:24 which would sound cool for building a kernal. 01:28:29 There can be only one kernal... 01:28:42 ORK's compiler is OSS, have at it ;) 01:29:09 What's it written in? 01:29:34 Either C or C++ I'm sure. 01:29:40 Bleh. 01:29:41 (It's been a while since I wrote it ;) ) 01:29:47 Glass is in C++ :P 01:29:51 EgoBF is in C ... 01:29:56 EgoBot is in C++ 01:29:59 Glass would more readily translate to assembly, methinks. 01:30:07 as far as parsing... and some other things. 01:32:12 bbiab 01:32:20 lol k 01:32:27 Incidentally, who the bork is SevenInchBread? 01:32:35 -!- SevenInchBread has changed nick to CakeProphet. 01:32:39 Ahhhhhhhhhhh 01:32:46 My true form is revealed. 01:32:48 You prophesized bread instead of cake then? 01:32:49 I have countless nicknames. 01:32:56 no no... I'm just... bread. 01:33:01 it's not meant to be taken literally. 01:33:05 it's very surreal, you see. 01:33:09 -!- CakeProphet has changed nick to GrandmotherChaos. 01:33:23 I don't understand such nicks, given that mine is as uninteresting as they come. 01:33:25 The Mother of a Thousand Crumbs... 01:33:40 SevenInchBread just sounded bizzare... 01:33:43 it's my favorite. 01:33:52 in fact... 01:33:56 -!- GrandmotherChaos has changed nick to SevenInchBread. 01:33:59 ah... there we go. 01:36:26 GregorR, GREGOR 01:36:31 WILL YOU HELP US? 01:36:35 WILL YOU SAVE THE DAY? 01:37:11 ?.? 01:37:36 !bf >.< 01:38:00 !ps 01:38:03 2 SevenInchBread: ps 01:38:12 !bf >.< 01:38:16 !bf >.< 01:38:21 !bf >+.< 01:38:24 01:38:27 Yay 01:38:54 Wha? 01:38:58 !bf +[.+] 01:39:02 01:39:17 !kill 1 01:39:19 !ps 01:39:24 !bf +[>+] 01:39:28 Process 1 killed. 01:39:30 1 SevenInchBread: ps 01:39:31 WEEEEEEEEEEEEEEEEEEEEEEH 01:39:31 :D 01:39:32 realloc: Cannot allocate memory 01:39:53 We killed it? 01:40:00 Nah 01:40:04 That was just EgoBF dying ;) 01:40:16 Ah... it's fault taulerant. :D 01:40:33 Is it like... a bunch of subprocesses basically? 01:40:45 It is like a bunch of subprocesses literally. 01:41:25 Python has really nifty subprocess handling... 01:41:32 -!- cmeme has quit ("Client terminated by server"). 01:41:36 hip-hip hurray for OO and functional. 01:41:43 -!- cmeme has joined. 01:42:00 GREGORR 01:42:04 WILL YOU HELP US? 01:42:07 EgoBot is nothing more than a collection of different interpreters written in all sorts of different languages. 01:42:14 Plus a runtime environment for them. 01:42:22 BUILD THE PERFECT OS? 01:42:22 I might. 01:42:27 I'm just skeptical is all. 01:42:41 Confidence goes a long way. :D 01:47:59 -!- Sukoshi has left (?). 01:48:09 -!- Sukoshi has joined. 01:52:43 !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 !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 (on) 01:54:23 !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 the parentheses are mandatory 01:54:41 ... 01:54:45 forgot 01:54:57 !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 !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 forgot Con didn't have the build method like List. 01:56:26 !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 12 01:56:33 whooo 01:56:40 exciting. 01:57:11 i still suggest you add ,, to the constructor. 01:57:23 Where? 01:57:30 and why? 01:58:22 !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 just before the ], to remove the arguments. 01:58:26 12 01:58:33 But it works the same doesn't it? 01:59:45 only if you don't need to use anything below it in the stack 02:00:29 Hey GregorR 02:00:38 You should add some more special methods. :D 02:00:40 to Glass. 02:00:47 Like maybe an output method. 02:01:09