00:01:49 <zzo38> Sorry, that was wrong, this is correct: \def\R{\redmanalayer\rlap\manasymcircle\textlayer\manasymred}
00:03:33 <alise> Starting program: /home/ehird/jonesforth/jonesforth
00:03:34 <alise> During startup program terminated with signal SIGKILL, Killed.
00:03:49 <zzo38> alise: I don't know why?
00:04:02 <alise> Hmm, seems the -Wl,-Ttext,0
00:05:21 <zzo38> Yap will not render a page with unknown specials.
00:06:52 <zzo38> (Which is OK, since I will write a DVI driver for this purpose, so you won't need other ones.)
00:07:33 <zzo38> One problem I still have is how I should implement text that is stretched only horizontally, and not vertically, in TeX and DVI.
00:09:23 <alise> cpressey: how long the red dot you just got will last
00:09:44 <alise> the red dot stops the electric fences (what everyone thinks they are; I however belong to the "lava that keeps its shape" school of thought) from killing you
00:12:42 <cpressey> Well, Eightebed 1.0 has been released. http://catseye.tc/projects/eightebed/
00:13:52 <cpressey> Meaning, I get to think about something else for a while.
00:15:19 <cpressey> Gregor: It occurs to me that you may care about the above announcement!
00:16:11 <alise> cpressey: But you DEFINED IT WRONG!
00:16:12 -!- GreaseMonkey has joined.
00:16:42 <alise> "There are no functions in Eightebed." XD
00:17:04 <alise> (I know, it's not a complexity problem.)
00:17:06 <cpressey> alise: Functions would change nothing... I explain that.
00:17:11 <alise> It's just amusing.
00:17:23 <cpressey> I suppose it is somewhat that.
00:17:33 <alise> consists only of the expression ifvalid x
00:17:41 <alise> WHOO BOY TIME FOR EIGHTEBED 1.1
00:18:30 <cpressey> Oh drat. I just found a tiny bug in the implementation too (in the -t option) so I will probably upload a bugfix. But, uh. Not today.
00:19:18 <Gregor> Bahahahahah @ "runtime support"
00:19:36 <alise> cpressey: Legal Issues is my favourite section
00:19:38 <Gregor> We implement this without a GC by stuffing most of a GC into the free function, thereby making it just as slow as a GC'd language with none of the advantages!
00:20:17 <Gregor> And when are you allowed to free? Only in an if valid block?
00:20:19 <alise> Aww, cpressey/Gregor is such a fun antagonistic relationship with obvious closeted underlying homosexuality.
00:20:24 <alise> Uh, I said nothing.
00:20:32 <cpressey> You strange, strange people with your caring about "slow" and your "advantages".
00:21:19 <cpressey> Gregor: You can only dereference in the "safe start" of an if valid block, i.e. before you make any assignments. You can free anytime, but if it's already free, nothing happens./
00:21:41 <cpressey> Could have made free follow the same rules as dereferencing. Didn't.
00:21:48 <Gregor> cpressey: And if you have an alias that's in an if-valid block?
00:22:24 <cpressey> Gregor: I don't follow, but if I do, the answer is: you need another if valid.
00:23:24 <Gregor> var ptr to int a; var ptr to int b; ... a = b = malloc int; if valid a { free(b); /* exception thrown? What? */ }
00:23:49 <cpressey> The block is freed and both a and b are invalidated.
00:24:04 <Gregor> But you're in an "if valid a" block.
00:24:25 <cpressey> Hm, good point. That could be a hole requiring redefinition of what a "safe start" is.
00:24:33 <cpressey> Up to the first assignment *or free*.
00:25:29 <Gregor> So yes, although you have managed to fit my requirements, I am wildly underwhelmed :P
00:27:10 -!- Sgeo has joined.
00:27:29 <alise> Gregor: "You win! But, whatever ;;("
00:27:39 <olsner> overwhelmingly underwhelmed?
00:28:05 <Gregor> alise: Just my inner homosexual tendencies towards cpressey preventing me from being too antagonistic, right? X-P
00:28:31 <alise> You don't want to seem like you care too much! :'(
00:29:29 <cpressey> Of course. The next time a dispute like this comes up, it will instead be settled by match of Greco-Roman wrestling.
00:30:33 -!- tombom has quit (Quit: Leaving).
00:30:37 <cpressey> Anyway. I realize how little it proves. But it was fun to do.
00:31:00 <cpressey> And, unfortunately I must be off now. Evening, all.
00:31:09 <olsner> oh, were you discussing the memory-safe language again?
00:31:25 -!- cpressey has quit (Quit: Leaving.).
00:31:48 <alise> although it's broken :P
00:32:09 <Sgeo> What language?
00:32:55 <Sgeo> Really annoying thing about Factor: There are no tutorials for a lot of stuff. The object-oriented stuff seems awesome, but it may be inaccessible to many due to having to dig through reference stuff
00:32:59 <Sgeo> Someone should write a tutorial on it
00:33:28 <alise> the reference stuff has tutorials
00:33:50 <Sgeo> alise, um, well, the class stuff
00:34:03 <alise> Sgeo: seriously, go to the reference; go up the directory to the topic (it has breadcrumbs)
00:34:08 <alise> there will be a link to documentation
00:34:42 <Sgeo> I thought tuples were the things with slots
00:34:47 <Sgeo> >>someslot someslot>>
00:35:08 <alise> there are no classes
00:35:30 <alise> but there's tuple and union classes
00:35:34 <alise> and tuples are what you are thinking of
00:35:53 <olsner> heh," If complications persist, another, less contentious name (such as "Microsoft Windows 7") may need to be chosen for this language."
00:50:03 <Sgeo> alise, linky? Doesn't seem to be in wiki
00:50:10 <Sgeo> And Google's useless
00:50:12 <zzo38> I am looking at the Kitsilano oscillator. It says it is sensitive to your hands?
00:50:17 <alise> Sgeo: See very recent messagse.
00:50:32 <alise> <Sgeo> Wait, cpressey is the Cat's Eye guy?
00:50:58 <Sgeo> alise, ty for not making me look through logs
00:52:29 <Sgeo> And I head straight for the esoteric programming category instead of seeing the news
00:53:15 <zzo38> alise: Yes that is what it says, but after adding one resistor it worked
00:53:25 <zzo38> http://catseye.tc/projects/kitsilano/kitsilano.html
00:53:44 <alise> Sgeo: the discussion in the logs is quite important though
00:54:29 <zzo38> Now, how well will it work, if you put a speaker instead of LED, and make all capacitors and resistors vary?
00:55:20 <zzo38> There is a circuit at the top that only works with old-style headphones. Is it possible to make a circuit that only works with red LEDs? (And if you put a green LED it won't work?)
00:59:39 -!- Gregor-CP has joined.
01:01:06 <Sgeo> Why would you spend any money on that?
01:01:15 * Sgeo decides that Gregor-CP is made out of money
01:02:09 <alise> Multiple Sclerosis eRotica
01:02:58 <Gregor-CP> Plus, I bought this off a friend for half its already low price :
01:03:17 <Sgeo> Make the next Microsoft Allegiance!
01:03:54 <Gregor-CP> It runs Android, albeit on a hilariously slow processor.
01:05:14 <olsner> however slow it is, I doubt it's hilarious... it's probably not even funny
01:05:16 -!- wareya_ has quit (Read error: Connection reset by peer).
01:05:41 -!- wareya has joined.
01:06:25 <Sgeo> alise, um, that game
01:06:34 <alise> Sgeo: IS HORRIBLE AAARGH IM ON STAGE 32 OISJFOIDFGSOFIG
01:06:48 <alise> Sgeo: what about it
01:06:51 <Sgeo> I'm stuck on the first part of level 1
01:07:03 <Sgeo> Are you sure the construction version is the best place to start?
01:07:08 <Sgeo> I want to avoid the fatal electric stuff
01:07:13 <Sgeo> But can't jump high enough
01:07:32 <alise> The construction version sucks
01:07:35 <alise> http://dotaction.fizzlebot.com/
01:07:41 <alise> (This mirror is much faster)
01:08:57 <Sgeo> Should I bother Google Translating?
01:09:19 <Sgeo> Oh, what's the construction version?
01:09:21 <Sgeo> This level is not it
01:09:40 <alise> http://dotaction.fizzlebot.com/
01:10:17 <Sgeo> But what was that contstruction version thing all about?
01:11:47 <alise> I think it lets you make your own levels
01:12:18 <Sgeo> Oh wait, let me make a guess
01:12:36 <Sgeo> Guess is correct :D
01:12:59 <Sgeo> And armed with that knowledge, I go to attempt the construction version again
01:13:25 <alise> It only has one level
01:13:28 <alise> Play the proper one
01:15:29 <Sgeo> Stage 5 was fun
01:16:46 <Sgeo> I screwed myself over on stage 6
01:16:53 <Sgeo> (With multiple upside-down dots
01:21:57 * Sgeo likes how sections of levels can be timed
01:23:20 <alise> I HATE LEVEL 32 SO MUCH
01:24:15 * Sgeo ran out of time grr
01:27:22 * Sgeo growls at level 10
01:27:27 <Sgeo> I know exactly how to solve it
01:28:10 <Sgeo> With 1 second left, I got it!
01:29:42 * Sgeo can't figure out level 12
01:29:51 <Sgeo> THe jump is just a LITTLE too big
01:32:50 <Sgeo> Stage 14 was fun
01:35:08 <Sgeo> stage 16 requires some intellect
01:38:31 <Gregor-CP> Chinese iPad ripoff: still workin'!
01:40:15 <pikhq> Gregor-CP: Awesome.
01:41:37 <pikhq> Y'know, now that I actually have to drive regularly, I have developed *quite* an appreciation for classical radio stations.
01:41:51 <Gregor> ORLY? Do you have a not-terrible one?
01:42:13 <pikhq> I *think* it's not-terrible. It *certainly* sucks less than all other radio stations in the area!
01:42:16 <Gregor> The Portland one is great, the Purdue one is OK. Neither of them have any great ability to stick to themes, they just sort of wander aimlessly over all music.
01:42:51 <Sgeo> Classical music has themes?
01:42:59 <pikhq> Sgeo: Very much so.
01:43:17 <zzo38> CBC sometimes plays classical music. They play other music too sometimes, and also news, and other things.
01:43:21 <zzo38> I also like classical music
01:43:21 * Gregor disappears for fifteen minutes.
01:43:46 <pikhq> Gregor: The one here (Colorado Springs) pretty much goes "Okay, we're just going to go with $theme for the next little bit."
01:44:45 <alise> FUCKING FUCKING FUCKING PIECE OF
01:45:05 <pikhq> And it's nice & non-profit.
01:49:42 <pikhq> Gregor: Just FYI: I'm presuming it's a damned good thing I have yet to hear on there something I'm actually familiar with. :P
01:54:29 -!- augur has joined.
01:54:34 -!- augur has quit (Remote host closed the connection).
01:54:53 -!- augur has joined.
01:57:30 <alise> STAGE 38 IS PURE PAIN
01:59:06 <zzo38> I have one idea, that you could make processor instruction set with no direct jump command, only a indirect jump command where the value of a register is the address of the next address
01:59:33 <ais523> zzo38: quite a few esolangs work like that
02:01:13 <zzo38> ais523: Yes, although what I mean is something like this: if 02AA is the destination address and 02 is the instruction and FF is the instruction pointer register: 02FF02AA
02:02:00 <ais523> that's how an indirect jump is done on PICs (you assign to the program counter, which is memory-mapped), but it has a direct jump instruction too
02:11:03 -!- zzo38 has quit (Remote host closed the connection).
02:17:32 -!- Gregor-CP has quit (Remote host closed the connection).
02:23:15 * Sgeo has troubles with stage 18
02:31:04 <alise> 42 is oidsjfodisjgoitjhnog
02:35:29 -!- Zuu has quit (Read error: Connection reset by peer).
02:37:59 -!- Gregor-CP has joined.
02:39:26 -!- Zuu has joined.
02:39:27 -!- Zuu has quit (Changing host).
02:39:27 -!- Zuu has joined.
02:46:18 -!- Zuu has quit (Read error: Connection reset by peer).
02:46:22 -!- ais523 has quit (Remote host closed the connection).
02:52:01 -!- Zuu has joined.
02:52:01 -!- Zuu has quit (Changing host).
02:52:01 -!- Zuu has joined.
03:16:31 <alise> Sgeo: : postpone r> dup , >r ;
03:16:33 <alise> i think this is right
03:16:41 <alise> works in jonesforth at least
03:17:13 <alise> no, it isn't, of course
03:33:51 -!- cal153 has quit.
03:37:30 -!- Gregor-CP has quit (Ping timeout: 265 seconds).
03:38:14 -!- Gregor-CP has joined.
03:45:49 -!- oerjan has joined.
03:46:32 -!- augur has quit (Remote host closed the connection).
03:46:41 -!- augur has joined.
03:55:23 -!- Zuu has quit (Read error: Connection reset by peer).
03:56:35 -!- Gregor-CP has quit (Read error: No route to host).
03:58:05 -!- GreaseMonkey has quit (Remote host closed the connection).
03:59:30 -!- Zuu has joined.
03:59:30 -!- Zuu has quit (Changing host).
03:59:30 -!- Zuu has joined.
04:05:57 <alise> "A+B - in programming contests, classic problem, which is given so contestants can gain familiarity with online judging system being used.
04:05:58 <alise> A+B is one of few problems on contests, which traditionally lacks fabula."
04:06:08 <alise> i guess traditionally lacks score or whatever
04:06:36 <pikhq> I'd be quite worried if it were worth points.
04:07:53 * Sgeo growls at Math being under "Arts & Sciences" at his school
04:07:53 <alise> Sgeo: this is an interesting look at forth philosophy, btw: http://www.jwdt.com/~paysan/httpd-en.html
04:07:56 <alise> if not utterly robust
04:08:04 <alise> mathematics is sort of a science
04:11:28 -!- Zuu has quit (Read error: Connection reset by peer).
04:11:40 <pikhq> alise: A New Kind of Science, if you will.
04:12:04 * pikhq leaves to avoid lynching
04:12:16 * Sgeo doesn't get it
04:12:35 <pikhq> Or: The Source of All Ego.
04:13:56 -!- GreaseMonkey has joined.
04:17:11 -!- Zuu has joined.
04:17:11 -!- Zuu has quit (Changing host).
04:17:11 -!- Zuu has joined.
04:24:03 <Gregor> lol @ "The Source of All Ego"
04:48:52 <alise> oerjan: cat compiler /does/ do type checking; evidence: http://lambda-the-ultimate.org/node/2319#comment-34783
04:48:57 <alise> he mentions things producing type errors
04:50:00 <Sgeo> Found a flame war regarding concatenative languages from 2005
04:50:11 <Sgeo> Apparently, stack effects weren't automatically checked back then
04:50:26 <alise> It's a new thing, with the optimising compiler.
04:53:06 <Sgeo> http://lambda-the-ultimate.org/node/900
04:53:47 <alise> pronunciation is a bit too close to cunt for comfort :)
04:57:22 <alise> fizzie: whoever: I discovered how colorForth does interpreted code.
04:57:27 <alise> It's just a different, non-green colour.
04:57:33 <alise> So there's no real stop-defining delimiter thing.
04:57:35 <alise> I think fizzie asked.
04:57:38 <alise> Or was it cpressey?
05:07:31 <alise> Sgeo: : fact 1- if dup fact 1+ * else 1+ then ;
05:07:34 -!- Zuu has quit (Ping timeout: 276 seconds).
05:08:11 <alise> if you have a colorForth-style-; and an if that doesn't drop like the i21:
05:08:12 <alise> : fact 1- if fact 1+ * ; then 1+ ;
05:08:48 <Sgeo> That doesn't look like Factor
05:09:31 <alise> it's Forth, of a sort
05:09:43 <alise> the latter would work on the i21 and nothing else :-)
05:09:54 <alise> http://www.ultratechnology.com/1xforth.htm is a very good read btw
05:09:57 -!- alise has quit (Quit: Leaving).
05:16:42 -!- Zuu has joined.
05:25:46 -!- oerjan has quit (Quit: Lost terminal).
05:37:06 -!- augur has quit (Remote host closed the connection).
05:37:18 -!- augur has joined.
05:51:17 -!- cheater00 has joined.
05:54:34 -!- cheater99 has quit (Ping timeout: 252 seconds).
06:58:41 -!- zzo38 has joined.
06:58:48 <zzo38> Please read this Article III: http://www.fftw.org/y2k.html
07:13:38 -!- cheater- has joined.
07:13:38 -!- cheater00 has quit (Ping timeout: 240 seconds).
07:24:20 -!- relet has quit (Quit: Leaving.).
07:29:26 -!- zzo38 has quit (Remote host closed the connection).
07:41:01 -!- relet has joined.
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
08:00:46 -!- FireFly has joined.
08:36:55 -!- FireFly has quit (Quit: swatted to death).
09:25:18 -!- Flonk has joined.
10:41:25 -!- tombom has joined.
11:06:47 -!- GreaseMonkey has quit (Remote host closed the connection).
11:21:02 -!- augur has quit (Remote host closed the connection).
11:26:22 -!- Flonk has quit (Remote host closed the connection).
12:16:49 -!- tombom has quit (Ping timeout: 272 seconds).
13:06:39 -!- Phantom_Hoover has joined.
13:17:33 <Phantom_Hoover> http://en.wikipedia.org/wiki/Wikipedia:Terminal_Event_Management_Policy
13:24:56 <fizzie> I like the level 1 warning template.
13:25:18 -!- sftp has joined.
13:25:28 -!- distant_figure has quit (Ping timeout: 260 seconds).
13:28:36 -!- Phantom_Hoover has quit (Ping timeout: 265 seconds).
13:54:34 -!- distant_figure has joined.
14:38:19 -!- alise has joined.
14:44:41 -!- relet has quit (Quit: Leaving.).
15:01:01 -!- derdon has joined.
15:03:00 -!- Phantom_Hoover has joined.
15:06:25 -!- Phantom_Hoover_ has joined.
15:08:10 -!- Phantom_Hoover has quit (Ping timeout: 265 seconds).
15:09:53 -!- FireFly has joined.
15:17:56 <alise> Phantom_Hoover_: because ghci executes in a do block
15:18:03 <alise> same reason you have to proceed functions with "let"
15:18:49 <alise> Phantom_Hoover_: ??
15:18:53 <alise> what has forall got to do with it?
15:19:05 <alise> (all function arrows A->B are really just "forall (_:A), B" but you know that)
15:19:18 <fizzie> BRÖDROST sounds somehow heavy-metallish. (Also I'm reminded of a nice absurdist comic, but it's very Finnish-only, so the point might be lost.)
15:20:25 <alise> Phantom_Hoover_: you didn't know that?
15:20:33 <alise> Phantom_Hoover_: cleverly.
15:20:42 <alise> fizzie: It means "toaster".
15:21:04 <fizzie> alise: I know, but it *ought* to mean church-burning or something.
15:21:09 <alise> Phantom_Hoover_: an implicit parameter is filled in when its value is obvious from the types of the others, or something approximating that anyway
15:21:33 <alise> you can use an implicit parameter on the argument specifying a type or component of a type of another argument, usually
15:21:46 <alise> Phantom_Hoover_: well, in declarations you can do {x:...} to make it implicit
15:21:53 <alise> normally it just sort of tries to make everything it can implicit, yes
15:22:02 <alise> Set Implicit Arguments functionOrDataType [arg arg arg].
15:22:15 <alise> ({x:...} rather than (x:...))
15:41:28 -!- cpressey has joined.
15:44:22 -!- MigoMipo has joined.
15:51:05 -!- mr45 has joined.
15:54:20 <Vorpal> alise, what about brödrost?
15:54:52 <Vorpal> alise, I mean, it seems completely non-sequitur...
15:55:51 <Vorpal> alise, or did you ask me for a translation? In that case it means "toaster" (literal translation: bread toaster)
15:56:40 -!- Phantom_Hoover_ has changed nick to Phantom_Brodrost.
15:56:58 <Vorpal> brod is not a Swedish word afaik
16:01:05 <cpressey> `swedish Mighty Morphin' Power Rangers
16:01:07 <HackEgo> Meeghty Murpheen' Pooer Rungers
16:01:28 <EgoBot> Meeghty Murpheen' Pooer Rungers
16:11:29 <fizzie> Vorpal: He already said it means toaster, so I doubt it was about translation.
16:11:56 <fizzie> (Don't have any clue what it *was* about.)
16:16:42 -!- cpressey has left (?).
16:17:32 -!- MigoMipo has quit (Remote host closed the connection).
16:18:03 -!- MigoMipo has joined.
16:20:08 -!- cpressey has joined.
16:23:27 -!- Phantom_Brodrost has quit (Ping timeout: 245 seconds).
16:23:54 -!- Phantom_Brodrost has joined.
16:26:30 <Phantom_Brodrost> I seriously want to murder whoever pulled the plug on Geocities.
16:29:51 <Phantom_Brodrost> I would murder cpressey for playing hopscotch with Cat's Eye, but he's too lovable.
16:37:06 -!- comex has quit (Ping timeout: 265 seconds).
16:38:32 <cpressey> Oh, I have a theory. While terminals display block letters, files contain cursive. I say this because it's always "print" to put stuff on the screen and "write" to put stuff in a file.
16:56:45 -!- comex has joined.
17:10:42 -!- derdon has quit (Remote host closed the connection).
17:27:07 -!- augur has joined.
17:28:16 <alise> <Phantom_Brodrost> I would murder cpressey for playing hopscotch with Cat's Eye, but he's too lovable.
17:28:19 <alise> we actually have a template for your site
17:28:34 <alise> because it moves so much
17:29:04 <alise> Phantom_Brodrost: try s/g/r/ in the url, btw
17:29:45 <alise> yes, but iirc there were a bunch of broken links to the old site on the wiki
17:29:53 <alise> so we just replaced every catseye link with a template
17:29:55 <alise> and set it to catseye.tc
17:30:08 <alise> http://esolangs.org/wiki/Template:Catseye
17:30:14 <alise> http://esolangs.org/w/index.php?title=Template:Catseye&action=edit
17:31:56 <alise> cpressey: have you seen PicoLisp? it's an interesting very-small, very-fast Lisp dialect interpreter
17:32:00 <alise> http://picolisp.com/5000/-2.html
17:32:20 <alise> some interesting choices, like 'a -> (quote . a), '(a b) -> (quote a b)
17:32:22 <alise> (explained in http://picolisp.com/5000/-2-3.html)
17:32:45 <alise> they base more or less everything on the cell
17:32:55 <alise> which is basically a cons with a few predefined car/cdr types
17:33:13 <alise> cell := ((int | symbol | cell), (int | symbol | cell))
17:33:24 <alise> the 32-bit one is written in C, 64-bit in asm
17:33:38 <alise> (except it seems to be some assembler written in PicoLisp; it appears to have if/then/else
17:33:50 <alise> interesting representation of NIL: http://picolisp.com/5000/-2-M.html
17:33:54 <alise> "This structure has great advantages. Any proper list (ending with 'NIL') becomes sort of "infinite", allowing to take the CDR as often as possible and still obtain 'NIL' again and again.
17:33:54 <alise> Therefore, a function doesn't need to check whether it actually received an argument or not. It can simply take the next argument with CDR from the argument list, and doesn't see any difference between '(foo NIL)' and '(foo)'. This makes interpretation both simpler and faster."
17:33:59 <alise> they make it both a symbol and a cons
17:35:01 <cpressey> i wanted to do that with... something
17:35:06 <alise> it gets linked a bit (PicoLisp)
17:35:17 <alise> but yeah, the language itself is interesting! reading the wiki is fun
17:36:05 <alise> cpressey: they have no lambda
17:36:30 <alise> I think this probably means they use dynamic scope, but I don't care, it's fun
17:36:39 <alise> "Why do you use dynamic variable binding?"
17:36:43 <alise> http://software-lab.de/doc/faq.html#dynamic
17:37:44 <alise> "You mean the funarg problem, or problems that arise when a variable might be bound to itself? For that reason we have a convention in PicoLisp to use transient symbols (instead of internal symbols) ..."
17:37:51 <alise> well, it's certainly interesting
17:42:09 <cpressey> Quylthylg has an extra argument to car and cdr which specifies what to return if you try to use them on a nil. Passing nil as that argument would be similar to that behaviour.
17:42:16 <cpressey> Well, would be that behaviour, actually.
17:43:02 <cpressey> But yes, PicoLisp looks quite interesting in its way.
17:43:09 <alise> heh, they have no strings, they just use transient symbols
17:43:16 <alise> Because PicoLisp has something better: Transient symbols. They look and behave like strings in any respect, but are nevertheless true symbols, with a value cell and a property list.
17:43:16 <alise> This leads to interesting opportunities. The value cell, for example, can point to other data that represent the string's the translation. This is used extensively for localization. When a program calls
17:43:16 <alise> (prinl "Good morning!")
17:43:16 <alise> then changing the value of the symbol "Good morning!" to its translation will change the program's output at runtime.
17:43:40 <alise> [[Transient symbols are also quite memory-conservative. As they are stored in normal heap cells, no additional overhead for memory management is induced. The cell holds the symbol's value in its CDR, and the tail in its CAR. If the string is not longer than 7 bytes, it fits (on the 64-bit version) completely into the tail, and a single cell suffices. Up to 15 bytes take up two cells, 23 bytes three etc., so that long strings are not very efficient (needing
17:43:40 <alise> twice the memory on the avarage), but this disadvantage is made up by simplicity and uniformity. And lots of extremely long strings are not the common case, as they are split up anyway during processing, and stored as plain byte sequences in external files and databases.]]
17:43:51 <alise> <alise> then changing the value of the symbol "Good morning!" to its translation will change the program's output at runtime. ;; this is just the greatest, most insane thing i've heard today
17:44:23 <alise> [[In an interactive environment (console), transient symbols should appear as an underlined sequence of characters. Where this is not possible (e.g. for representation in files), or inconvenient (while editing), double quotes '"' are used instead of underlining.]] ;; huh
17:46:06 <Vorpal> alise, PicoLisp? Hm? What makes it stand out from other LISPs?
17:46:21 <alise> Vorpal: *Lisps; and read everything I've said (plus the wiki).
17:46:42 <alise> Well, that is not my problem.
17:50:53 <alise> cpressey: Their symbols appear to be constructed as '(value . name)/
17:51:06 <alise> Well, with some property list stuff on the side, I guess.
17:52:21 <alise> [[For the third rule, however, things get a bit more involved. First - as a special case - if the CAR of the list is a number, the whole list is returned as it is:]] That is a bit gross though.
17:52:48 <alise> "When a number is used as a function, it is simply taken as a pointer to executable code that will be called with the list of (unevaluated) arguments as its single parameter. It is up to that code to evaluate the arguments, or not. Some functions do not evaluate their arguments (e.g. quote) or evaluate only some of their arguments (e.g. setq)."
17:53:05 <alise> It's like Forth! Except LISP!
17:53:15 <alise> (That was shouting Lisp, not miscapitalising it.)
17:53:38 <alise> Inspecting the VAL of *, however, gives
17:53:38 <alise> : * # Get the VAL of the symbol '*'
17:53:41 <alise> That's actually quite cool.
17:54:23 <cpressey> Now you are shouting for Val, but she's not here!
17:55:36 <alise> That was a quote :P
17:55:59 <alise> Besides, as a typographical matter, Lisp function names may be capitalised (when you can't distinguish them in some other way, e.g. monospaced text).
17:56:02 <cpressey> And mine was a joke. I unfortunately don't have the time to read about and play with PicoLisp either.
17:56:12 <alise> Which leads to fun things like saying CALL-WITH-CURRENT-CONTINUATION.
17:56:20 <alise> CALL WITH IT, DAMMIT!!
17:56:48 <alise> Cool, the REPL actually matches parens and does the "foo" -> underline{foo} thing as you type.
17:57:02 <alise> : sdgkopegjser09jt
17:58:43 <alise> * -- List expected
17:58:58 <alise> I guess they only typecheck when they really have to :)
18:01:12 <alise> cpressey: Do you know anything about the performance of x86 instructions?
18:02:32 <fizzie> I don't know much about that, but what little I know leads me to suggest that you can't say anything (or at least not much) about "x86 instructions" in a general sense, without talking about a single specific processor model.
18:02:35 <Vorpal> alise, I can help a bit
18:03:43 <fizzie> Gone are the days you could cycle-count anything, anyway. It's all about what sort of units happen to be free for scheduling, and memory-access times are pretty much random.
18:04:00 <Vorpal> alise, AMD and Intel both have tables over number of cycles per instructions in their modern architectures. As downloadable PDFs. However that is of course not the whole story, there is cache, wb/wc/uc, TLB misses and so on
18:04:08 <alise> Well, my question is: are the push-and-popping stack instructions faster than Just Doing It Yourself?
18:04:19 <Vorpal> alise, the AMD docs indicate which ones are done in microcode iirc
18:04:27 <Vorpal> and also how it stalls stuff
18:04:43 <Vorpal> not sure if intel docs do
18:04:50 <Vorpal> alise, that depends on which CPU
18:05:08 <alise> Vorpal: They could be slower? Or merely equal?
18:05:10 <Vorpal> alise, on many CPUs just setting the stack pointer at the start of a function and then using mov is faster
18:05:19 <Vorpal> many modern ones that is
18:05:35 <Vorpal> alise, due to instruction dependencies iirc
18:05:44 <fizzie> Push and pop at least save in code size, and it would be a bit surprising if they were much slower than the equivalent manual "decrement and store/load and increment" pair.
18:05:58 <alise> Vorpal: well, I'd be setting the stack pointer to something manifestly not the usual stack in this case
18:06:11 <Vorpal> alise, hm? How do you mean
18:06:13 <alise> hmm, are there variants of push and pop which also take the stack? i suppose not
18:06:32 <alise> I guess saving the stack pointer, setting the stack pointer, doing push (or pop), then restoring the stack pointer is slower than the manual way, though.
18:06:38 <alise> (Just one operation.)
18:06:46 <alise> So it may be a good idea to use it for the main stack but manually handle the return stack.
18:07:37 <Vorpal> alise, anyway for the usual "common C function not using alloca or VLA" it is on modern cpus generally faster to increment %rsp by whatever amount you need, then use mov to put things on the stack relative that pointer
18:07:51 -!- relet has joined.
18:07:53 <Vorpal> alise, well, this could apply to other languages too
18:08:07 <Vorpal> alise, any compiled ones where you know the size of your stack frame at entry
18:08:12 <alise> Vorpal: basically, this thing is going to execute a ludicrous amounts of pushes and pops per second.
18:08:34 <Vorpal> alise, hm... You could probably optimise the code?
18:09:01 <alise> Forth is a stack language. Its whole operation is based on pushing and popping.
18:09:02 <Vorpal> alise, an optimising forth compiler. Yes I know this is not the usual way to do it
18:09:09 <alise> I am merely asking whether these are faster than using mov manually.
18:09:16 <alise> I don't need implementation tips...
18:09:16 <Vorpal> but you could make one that tries to convert it to using registers and such
18:09:30 <alise> an optimising Forth compiler goes against the spirit of Forth, anyway
18:09:35 <alise> your code shouldn't be wasting time in the first place
18:09:36 <Vorpal> alise, anyway: several pushes after each other will all update %rsp/%esp.
18:09:46 <Vorpal> alise, that means they can't be executed out of order
18:10:00 <alise> well, it won't be several pushes immediately
18:10:03 <Vorpal> and mixed series of push/pop
18:10:13 <alise> it'll be push, push, ..., pop, push, push, ...
18:10:21 <alise> ... being e.g. a jmp or two
18:10:25 <alise> a jmp and incrementing something
18:10:44 <Vorpal> alise, better to, if possible, update %rsp once when entering the function, then use mov using %rsp for indirection
18:11:52 <alise> the mass migration of Digg users to reddit started a few days before September began in the incorrect (post-09/1993) calendar
18:11:55 <alise> coincidence? I think not.
18:12:07 <Vorpal> alise, this applies to modern CPUs. Not sure where exactly it becomes more efficient. But it push/pop would most likely be better on a i486. And update-once-and-mov would definitely be better on P4 and later.
18:12:14 <Vorpal> in between... I don't know
18:12:35 <alise> Vorpal: this is between mov, inc, mov, inc and push
18:13:04 <alise> Vorpal: ok, what about "save stack pointer, set the stack pointer to something else, (1 push or pop), restore the stack pointer"?
18:13:09 <Vorpal> alise, hm, why could you not merge does movs into an add, then do relative addressing
18:13:09 <fizzie> If you're going to do exactly the pushing operation ("decrement a register, move a word to where it points"), my guess is it'll be better to push than sub 4 + mov, if you can keep the thing in rsp; but possibly not if it's in some other register. (Though I'm not completely certain about that: it's possible register-renaming trickery could make xchg+push+xchg pretty fast.)
18:13:11 <alise> that's gotta be slower than a mov-based incantation right?
18:13:30 <Vorpal> alise, like >+>>++> would be optimised in any decent BF compiler
18:13:43 <alise> Vorpal: as i said, the fight is between precisely those options i listed
18:13:44 <Vorpal> and then using an offset to the current position as needed
18:14:06 <Vorpal> alise, then I suspect push/pop is somewhat less bad.
18:14:12 <alise> fizzie: Specifically, the swap-the-stack-for-one-instruction thing would be when running r> and >r, which pop or push one value from/to the return stack from/to the main stack.
18:14:12 <Vorpal> alise, but try both and profile!
18:14:33 <alise> fizzie: So it would be "pop, xchg, push, xchg" or "xchg, pop, xchg, push"
18:15:48 <fizzie> Well, that sounds somewhat reasonable.
18:16:06 <Vorpal> alise, what exactly is wrong with combining several updates to the stack pointer and then use offsets relative where it points?
18:16:28 <alise> fizzie: That is, vs "pop, inc, mov" or "mov, dec, push".
18:16:52 <Vorpal> alise, remember on x86_64 you may put temp data in a 128 byte region beyond the stack pointer. Any signal handler or such won't overwrite that. Specified in the ABI
18:17:03 <Vorpal> useful for leaf functions to avoid updating stack pointer at all
18:18:11 <fizzie> alise: "push" is not "inc, mov", it grows the other direction. But anyway. Really, you *could* consider benchmarking this stuff; after you get it working, it's a small snippet to change and run your benchmarks.
18:18:43 <Vorpal> fizzie, but he refused to do proper measurements above: "<alise> Vorpal: no."
18:18:54 <alise> Vorpal: That was just to upset you, though.
18:19:10 <Vorpal> alise, no, it was just stupidity on your side. I'm sure of it.
18:19:13 <alise> fizzie: Er, right, you know what I mean with the alternative.
18:19:34 <alise> Vorpal: You /do/ realise that I've only been actually listening and talking to fizzie this whole time?
18:20:04 <Vorpal> alise, strange you highlighted me several times then.
18:20:21 <Vorpal> alise, but sure. Be a jerk if that is what you like
18:20:23 <alise> Vorpal: Yes; to annoy you.
18:21:08 <alise> Indeed. Perhaps you'll ignore me now?
18:21:43 <Vorpal> alise, no. That would be what you want.
18:22:31 <Vorpal> alise, however I will remember to never try to be helpful when you ask a question again.
18:23:40 <fizzie> As far as code size is concerned, it's a very slight win. "pop, xchg, push, xchg" is 2+1+2+1=6 bytes (or 1+1+1+1=4 if your other stack is in rax, but that doesn't sound feasible) while "pop, sub 4, mov [rx]" is 1+3+3=7 bytes, or 1+3+4=8 if your other stack is in rbp.
18:24:15 <alise> fizzie: Yeah; I think I will go with the xchg.
18:24:19 <alise> Especially since there's operations like rswap.
18:24:41 <alise> Actually, you can swap the top two values of a stack without popping them.
18:24:44 <alise> So that will not actually be any longer.
18:25:13 <fizzie> If your other stack is in rsi and you keep the direction flag set properly, you can use lodsq as a single-byte-instruction pop (but push will still be longer).
18:25:45 <alise> I think I'll stick to regular stacks.
18:26:15 <alise> xchging the top two values of a stack will be faster than popping and pushing twice, I assume :P
18:26:54 <fizzie> I'm not sure about that, because xchg against memory will do LOCK automatically even if you don't put the LOCK prefix in.
18:27:32 <fizzie> But of course you don't need to pop, pop, push, push since the stack pointer won't move, just mov things around, possibly with some offsets.
18:28:00 <fizzie> (Oh, and the lodsq fake-"pop" can only pop into rax.)
18:28:37 <alise> True, it's just moving.
18:28:52 <fizzie> (On something like ARM, all your stack pointers would be general-purpose registers and you'd have pre/post-increment/decrement addressing with any register you want.)
18:30:01 <fizzie> (And on a more austere RISC, you'd just have load/store and separate add/sub, and no nonsense about one-register-only pushing.)
18:32:37 -!- Phantom_Brodrost has quit (Ping timeout: 265 seconds).
18:34:47 -!- choochter has quit (Ping timeout: 258 seconds).
18:36:14 <fizzie> Gads, x86 instructions are ridiculous. XLATB: does "mov al, [rbx+al]" (hypothetical, since you could normally only [rbx+rax], but anyway) -- "This instruction is often used to translate data from one format (such as ASCII) to another (such as EBCDIC)." Yeah, I do asm-optimized ascii-ebcdic translation all the time. (I wonder if gcc can generate xlat for "unsigned char x, i, *p; x = p[i];" sort of code.)
18:39:36 -!- Phantom_Brodrost has joined.
18:40:09 <fizzie> Anyway, guesstimating performance with a speculative-execution register-renaming superscalar thing is probably something that makes any statemets very context-sensitive ("if you have A, B, C and D, option 1 will be faster; ..."). I couldn't find out late numbers, but apparently already the P4 had 128 general-purpose registers it could use for register-renaming, and my guess is that a reg-reg xchg would be done by that machinery.
18:41:52 <alise> Silly name for a Lisp: Lips
18:42:47 <fizzie> Lots of punny names possible for related paraphernalia, I guess.
18:44:22 <alise> Does anyone know if there are any well-written single-file bignum things?
18:44:26 <alise> GMP is just a bit too big for me to be happy
18:46:26 <fizzie> I have the worst bignum implementation ever. but it's single-file! (I got sidetracked on a C programming course "calculate character histogram" home exercise, and wrote one with a bignum lib and multibyte character support.)
18:47:22 <fizzie> I'm trying to find it, but you really don't want to use it. :p
18:47:32 <alise> fizzie: No, but I might want to modify it and use it.
18:47:41 <alise> Hmm, maybe I can store every number just as a pair of bignums and call it a rational.
18:47:52 <alise> (That is, a not-necessarily-reduced rational.)
18:47:58 -!- derdon has joined.
18:49:15 <fizzie> I'm not so sure you even want to use that as a base; it's pretty simple to make a integer bignum thing which uses an array of unsigned ints as the storage format.
18:49:30 <fizzie> I can't recall what the course code was, or what year I did it.
18:50:47 <fizzie> Someone's eaten my bignums.
18:51:17 <alise> fizzie: But exponentation and the like!
18:51:34 <alise> Is... impossible! Or,
18:51:48 <alise> Say, I wonder what algorithms people use to approximate sqrt() on rationals.
18:52:06 <fizzie> Yes, well, I doubt I have any non-trivial algorithms in the file, if I can find it. No FFT-based multiplications for me there.
18:52:23 <alise> Meh. Who needs bignums rihgt now?
18:52:40 <alise> Why do property lists exist?
18:53:17 <alise> Phantom_Brodrost: ...For sqrt()?
18:54:18 <alise> Phantom_Brodrost: I'm asking what algorithm people use to calculate approximate_sqrt : Q -> Q.
18:55:01 <Phantom_Brodrost> Well, ignoring complexes, approx_sqrt : N → Q on numerator and denominator...
18:55:23 <alise> And what of that algorithm?
18:56:45 <alise> That is my question! Sheesh.
18:56:53 <cpressey> alise, fizzie: re performance of x86 instructions: omg yes, with pipelines and prefetching and the cache hierarchy, you just kind of ... guess.
18:57:55 <alise> Let's see, a symbol is a name and a value.
18:57:58 <fizzie> Paul Zimmermann, “Karatsuba Square Root”, INRIA Research Report 3805, November 1999, http://hal.inria.fr/docs/00/07/28/54/PDF/RR-3805.pdf
18:58:07 <alise> I'm basically writing PicoLisp: The Ripoff here.
18:58:13 <fizzie> (It's yet another of those FFT-based algorithms.)
18:58:51 <fizzie> Or maybe not, actually.
18:59:25 <Vorpal> <fizzie> Anyway, guesstimating performance with a speculative-execution register-renaming superscalar thing is probably something that makes any statemets very context-sensitive ("if you have A, B, C and D, option 1 will be faster; ..."). I couldn't find out late numbers, but apparently already the P4 had 128 general-purpose registers it could use for register-renaming, and my guess is that a reg-reg xc
18:59:25 <Vorpal> hg would be done by that machinery. <-- Hm... And still the AMD64 instruction set doesn't expose nearly as many
18:59:28 <alise> Phantom_Brodrost: Yes.
18:59:29 <cpressey> The thing that gets me about optimizing generated machine code in the modern world is, really, how do you *know* your code is faster? A benchmark? Yeah, those're realistic. :/
18:59:29 <Phantom_Brodrost> http://en.wikipedia.org/wiki/Methods_of_computing_square_roots
19:00:27 <Vorpal> fizzie, I suspect having 64 out of 128 programmer visible GPR would be a way better trade-off than the small number that x86_64 has
19:00:51 <alise> Oho, that's clever. In PicoLisp, a symbol's address is actually one after its name.
19:01:01 <alise> (So **sym dereferences it.)
19:01:09 <alise> (Since the value comes after the name.)
19:03:10 <Vorpal> cpressey, hm yes... higher level optimisations are probably more useful in general for a compiler. Still there are some things you can do at that low level. And both AMD and Intel have optimisation guides aimed at compiler writers.
19:03:28 <fizzie> There's the very famous and very clever Quake "1/sqrt(x)" approximation, but that's decidedly floating-point: float invsqrt(float x) { float xh = 0.5f * x; int i = *(int*)&x; i = 0x5f3759d5 - (i >> 1); x = *(float*)&i; return x*(1.5f - xhalf*x*x); }
19:03:41 <fizzie> It's also a bit on the non-obvious side.
19:04:16 <alise> fizzie: Yes, I sort of don't want floating point.
19:04:32 -!- choochter has joined.
19:05:51 <Vorpal> fizzie, I think SSEn for some n>=2 has some instruction for inverse of square root
19:06:16 <Vorpal> that was mixing up Swedish name for the operation
19:07:44 <Vorpal> reciprocal is the English word, invers is used in Swedish.
19:07:53 <alise> inverse square root is also used in English
19:07:58 <alise> see, e.g. what fizzie just quoted
19:08:05 <fizzie> RSQRT[PS]S; reciprocal square root packed/scalar single-precision floating-point.
19:08:44 <fizzie> SSE dropped the trigonometrics, though; I wonder how they do sin(x) nowadays.
19:08:46 <Vorpal> alise, yes but inverse makes me think of f⁻¹
19:09:03 <alise> Then "inverse square root" would be stupid.
19:09:06 <alise> It being "square".
19:09:22 <alise> But that isn't what it is used to mean.
19:10:01 <Vorpal> alise, well "inverse function" for most other things mean that
19:10:24 <alise> I don't think anyone actually says "inverse f" for f^-1.
19:10:27 <alise> f's inverse, maybe.
19:10:27 <Vorpal> alise, so it is kind of ambiguous
19:10:37 <alise> does anybody say "inverse cos" :)
19:10:46 <Vorpal> alise, no you say arccos
19:10:52 <Vorpal> but only because it has a damn silly name
19:11:12 <fizzie> "inverse *of* square root" does sound a bit like ^2 though.
19:11:16 <alise> arccos sounds pretty hard to pronounce; I'd go with acos.
19:11:24 <alise> If you're expanding, might as well say "arc cosine".
19:11:30 <alise> fizzie: But not inverse square root.
19:11:45 <Vorpal> alise, arc expands to arcus or something like that iirc
19:11:59 <Vorpal> alise, so arcus cosine probably?
19:13:39 <fizzie> Finnish way to read arcsin and arccos out loud is as compound words, "arkussini" and "arkuskosini".
19:14:24 <alise> So we can store 4 bytes of a name per word on x86, 8 bytes on x86-64.
19:14:24 <fizzie> And the Finnish name for reciprocal is again very elegant and beatiful: "käänteisluku". (Lit. "inverse number", compare "käänteisfunktio" -- "inverse function" for the other sort of inverse.)
19:14:27 <Vorpal> fizzie, similar for Swedish
19:14:32 <alise> I wonder how PicoLisp handles longer names.
19:14:43 <Vorpal> alise, what is a word on x86-64 then?
19:14:46 <alise> fizzie: Are you being sarcastic? Because Finnish /is/ awesome.
19:14:56 <Vorpal> alise, AMD and Intel disagrees
19:15:07 <alise> Yes, well, they're stupid and should die.
19:15:29 <Vorpal> alise, great, then we would all run ARM, PPC or SPARC I guess
19:15:39 <alise> Sure, I would go for that.
19:16:09 <Vorpal> and I'm not sure Cell and similar makes such a good general purpose *desktop* CPU
19:16:09 <alise> Gah; is there a variation on Emacs' SERVER-START that doesn't start if there's already a server running?
19:16:16 <alise> A SERVER-IS-RUNNING-P, or the like.
19:16:19 <Vorpal> sure, awesome at the stuff it is meant for
19:16:24 <alise> Vorpal: PPC wouldn't be dead if AMD and Intel were dead.
19:16:38 <alise> Besides, nothing wrong with SPARC.
19:16:39 <Vorpal> alise, well, true, but it is a bit too late now
19:16:48 <Vorpal> alise, did I say there was something wrong with SPARC?
19:16:56 <alise> Just saying that we could use SPARC.
19:16:58 <Vorpal> the register window stuff is cool
19:17:08 <Vorpal> alise, ALPHA if it wasn't dead
19:17:10 <alise> There are open-source implementations, too.
19:17:18 <Vorpal> alise, yeah that is cool
19:17:32 <fizzie> ARM's Cortex-A9 does quad-core 2GHz thing; it sounds like it might even be reasonable amount of power in a desktoppy environment.
19:17:59 <alise> fizzie: Perhaps...
19:18:16 <alise> Apple's (not actually Apple's; I forget who designed it) A4 isn't too shabby either.
19:18:26 <Vorpal> fizzie, GHz isn't everything
19:18:33 <alise> That's 1 GHz and single-core, but still.
19:18:42 <Vorpal> fizzie, pipeline? out of order? super scalar? and so on...
19:18:48 <alise> Vorpal: Smarter code.
19:18:52 <Vorpal> and efficient ISA of course
19:19:03 <alise> Vorpal: ...is the programmer's job.
19:19:17 <alise> Besides, most CPU power goes unused these days.
19:19:46 <Vorpal> alise, but I mean, a 10 GHz bf CPU would probably be way less efficient than a 2 GHz x86-64 for almost everything
19:20:01 <alise> But way cooler, too.
19:20:16 <Vorpal> alise, well yes, but that isn't what most people buying a CPU wants
19:20:26 <alise> Are you absolutely sure about that?
19:20:37 <fizzie> It is superscalar, I don't know very much of the other details. ARM's specs page has a DMIPS ("Dhrystone MIPS") performance value, but I don't know how those compare to intels.
19:20:51 <Vorpal> alise, either that or they define cool definitely than we in this channel do
19:21:04 <Vorpal> s/definitely/differently/
19:21:15 <alise> fizzie: Let's just compare BogoMIPS!
19:21:28 <fizzie> Anyway, at 10000 DMIPS and 2 GHz, it consumes a whopping 1.9 watts of power.
19:21:59 <alise> ByteByteJump is so cool.
19:21:59 <alise> uint8_t mem[MEMSIZE];
19:22:00 <alise> uint32_t *pc = (uint32_t *)mem;
19:22:00 <alise> mem[pc[1]] = mem[pc[0]];
19:22:00 <alise> pc = (uint32_t *)(mem + pc[2]);
19:22:16 <alise> (Needs memory-mapped IO and a way to halt, but still, sweet.)
19:22:20 <Vorpal> fizzie, that is still way less than a P4. Probably way less than a core 2 duo too
19:22:23 <alise> fizzie: Just slap two of them together then.
19:22:57 <alise> Vorpal: Really? Are you sure?
19:23:02 <alise> Have you RUN Dhrystone on them?
19:23:06 <Vorpal> alise, no. It's a guesstimate
19:23:11 <Vorpal> alise, about those 1.9 W
19:23:17 <alise> Oh, the temperature.
19:23:24 <Vorpal> alise, err not temp. Power usage
19:23:25 <alise> About the wattage.
19:23:29 <alise> Yes, they're closer to 60-100W.
19:23:58 <fizzie> Vorpal: On the other hand, you can't use it to multitask as your sauna stove.
19:24:01 <alise> "Avoid using brk() and sbrk(): the malloc(3) memory allocation package
19:24:01 <alise> is the portable and comfortable way of allocating memory."
19:24:22 <fizzie> Core i7 Gulftown models have a TDP of 130W.
19:24:25 <Vorpal> alise, well. My thinkpad when both cores are fully loaded (with SSE heavy code) uses like 25-27 W iirc.
19:24:27 -!- Wamanuz2 has joined.
19:24:29 <alise> fizzie: I meant the reasonable CPUs. :P
19:24:35 <Vorpal> alise, still quite a bit
19:24:51 <alise> fizzie: How much does one of those lovely ARMs cost?
19:24:53 <Vorpal> alise, though that includes stuff like monitor and memory and so on
19:24:58 <Vorpal> alise, not just the CPU
19:25:01 <alise> You could have 100 of them and use the same power. :)
19:25:05 <cpressey> alise: malloc is "comfortable".
19:25:06 <Vorpal> alise, when idle it is way less
19:25:10 -!- kar8nga has joined.
19:25:14 <alise> fizzie: Actually, isn't there some big ARM computer that consists of a fuckton of them?
19:25:22 <Vorpal> alise, on half-bright screen
19:25:37 <Vorpal> alise, still it of course includes more than just CPU,
19:25:38 -!- Wamanuz has quit (Ping timeout: 276 seconds).
19:25:46 <alise> sbrk() doesn't work well when there's memory in the way, right?
19:25:51 <alise> i.e. it won't do realloc's move-shop stuff.
19:26:26 <cpressey> Phantom_Brodrost: first thing that came to mind today, honestly, was "octalthorpe"
19:26:45 <Vorpal> alise, sbrk is quite similar in many ways to adding/subtracting a value from the stack pointer. But for the heap
19:26:51 -!- BeholdMyGlory has joined.
19:27:07 <fizzie> Incidentally, let's check consumer power supplies; last I looked (some years ago) they were hovering in the one kW range, now... "SilverStone Strider ST1500 1500W"; well, 1.5 kW, then.
19:27:19 <Vorpal> alise, so it is useless for any memory management on it's own if you will ever free anything except the most recently allocated element
19:27:32 <alise> Vorpal: I'm maintaining my own heap.
19:27:53 <alise> Vorpal: modern OSes will do it in virtual memory, yeah, instead of allocating real memory for it?
19:28:01 <Vorpal> alise, just saying you need to do so with more than sbrk. Or you will get horrible memory fragmentation.
19:28:04 <alise> fizzie: there are 2 kW ones iirc.
19:28:11 <alise> fizzie: of course, you rarely need more than 600 W.
19:28:13 <Vorpal> alise, hm? well it is of course backed by virtual memory
19:28:17 <fizzie> Soon the gamer-class computers will start to come with three-phase electric power connectors.
19:28:33 <alise> Vorpal: I don't particularly want to write a compacting GC, either, so my options are pretty limited as far as freeing memory goes.
19:28:37 <alise> As in, "it probably won't happen".
19:28:45 <alise> So I'll just be relying on the OS to manage virtual memory well.
19:28:54 <Phantom_Brodrost> Soon the gamer-class computers are going to have the souls of 10 children in them for AI.
19:28:54 <Vorpal> alise, um. maybe back it by mmap then
19:29:10 <alise> http://esolangs.org/wiki/BytePusher this is awesome
19:29:17 <alise> Vorpal: yeah, I'm considering that too
19:29:28 <alise> Vorpal: although not in the way SBCL does since I want to work when overcommit is off
19:29:32 <cpressey> alise: You're writing a PicoLisp, right? You can take the marvelous GC advantage of having all your memory cells be the same size, then.
19:29:41 <alise> is there a way to increase the size of an mmapping?
19:29:53 <alise> cpressey: I'm writing Slip, which is like PicoLisp except MINE and BETTER.
19:29:54 <Vorpal> alise, it won't do anything if your heap looks like (@ = allocated, . = unallocated): @@@...@.@@.@@@@......@@........@.@...@@@....@@...@@
19:29:57 <cpressey> Unless there's some variable-length stuff you want to do, of course. I should have said "Lisp".
19:30:10 <alise> cpressey: Also, I'm not sure it will be.
19:30:19 <Vorpal> alise, which is what you will get if you only ever use sbrk and then never fill in the freed up holes
19:30:21 <alise> cpressey: Since what about symbols with names >4 or 8 bytes (depending on 32/64-bit)?
19:30:33 <alise> There needs to be a remmap.
19:30:46 <alise> cpressey: Where do the rest of their names go? I am trying to figure out how PicoLisp does this.
19:30:48 <Vorpal> alise, there is a mremap. Linux specific.
19:31:07 <alise> Phantom_Brodrost: Most likely just an interpreter.
19:31:11 <alise> "I am lazy and my CPU is fast."
19:31:12 <Vorpal> alise, while the OS won't actually allocate your pages until you try to access them, it won't automagically unallocate zeroed out pages.
19:31:21 <cpressey> alise: I dunno. Maybe they do the ol' BASIC thing where only the first 4 characters of the identifier count :)
19:31:24 <Vorpal> alise, for most apps the overhead of detecting that wouldn't be worth oit
19:31:26 <alise> I might just use a fixed-size heap.
19:31:32 <fizzie> The Scheme interpreter I wrote for our "let's do SICP one last time" special commemorative Scheme course has a copying, compacting (well, of course, since it's copying) GC, and that's "just" 550 lines of x86-64 asm. (It's also probably incredibly buggy, since I wrote it in the last night or two before the deadline.)
19:31:43 <Vorpal> alise, why not use libgc?
19:31:52 <Vorpal> alise, that is the lazy solution
19:32:02 <alise> fizzie: Copying GCs are so yeargh, though.
19:32:10 <alise> Vorpal: I'm maintaining my own heap; GCs are like a 30-line thing.
19:32:17 <alise> I owe it to my users not to use a conservative collector.
19:32:34 <fizzie> alise: It's a good choice when you have a deadline measured in hours and are writing manual assembly, though. :p
19:32:38 <alise> Phantom_Brodrost: What the hell could HE do?
19:32:54 <alise> Phantom_Brodrost: He can't.
19:32:58 <alise> Phantom_Brodrost: Name a project written by esr.
19:33:06 <alise> Yes, which ais523 has spent years cleaning up.
19:33:06 <Vorpal> alise, the way you described your GC so far sounds worse than a conservative gc though.
19:33:16 <cpressey> alise: If you use linked cells to hold long id's (bear with me) then you get fixed-sized cells and that makes GC easy. Need to allocate a new cell? Just take the next one off the free list. Free a cell? Add it to the free list. Free list empty? sbrk().
19:33:22 <fizzie> GC snippet of the day:
19:33:22 <alise> Vorpal: it will be good within the heap
19:33:23 <fizzie> .fail: ;; TODO: remove when failure is not an option
19:33:24 <alise> just not good for the OS
19:33:31 <alise> Failure is NOT AN OPTION
19:33:46 <alise> cpressey: I can't use linked cells, though, because the CDR already contains a pointer to a cell (the value of the pointer).
19:34:01 <alise> fizzie: UNREADABLE
19:34:03 <alise> HOW DOES THAT WORK
19:34:16 <Vorpal> alise, most programs will not free up resources in the same order they allocated them. So you need to try to reduce fragmentation in some way
19:34:20 <fizzie> Let's not go into the Intel syntax wars again.
19:34:29 <fizzie> It's just that one "mov", anyway.
19:34:39 <alise> fizzie: I was being sarcastic.
19:34:46 <Vorpal> alise, using a bunch of pools to keep the objects similar sized in a given area might work
19:35:00 <cpressey> Vorpal: Do you realize that with fixed-size cells, fragmentation is basically a non-problem?
19:35:02 <alise> I have a lot of memory.
19:35:07 <alise> And what cpressey said.
19:35:08 <Vorpal> alise, I think the freebsd malloc uses pools like that
19:35:13 <alise> Hopefully everything will be the same size.
19:35:14 <Vorpal> cpressey, ah, he has that?
19:35:18 <Vorpal> I must have missed that
19:35:28 <Vorpal> indeed that is like a single pool
19:36:01 <alise> cpressey: Still not sure how to do symbol names, though. Oh, I know.
19:36:26 <alise> ('HELL', ptr), ('OWOR', 'LD!\0\0')
19:36:36 <alise> i.e., you just keep looking ahead until you get a \0.
19:36:38 <Vorpal> alise, you still need some way to store allocation metadata. Like a freelist
19:36:52 <alise> Vorpal: Well, I'm GCing. So there will be a mark field.
19:37:15 <alise> I might even do the wonderful multithreaded mark-and-sweep I keep talking about.
19:37:18 <alise> No more GC delays!
19:37:38 <Vorpal> alise, just saying scanning for free on allocation would be rather slow
19:38:06 <Vorpal> maybe having a map of pages containing at least one free spot would work
19:38:07 <alise> Vorpal: Maybe I could use a bitmask.
19:38:23 <alise> 1101110 means that cells [0], [1], [3], [4] and [5] are available.
19:38:25 <Vorpal> that way you need to scan only a small chunk
19:38:29 <alise> (An array of integers, that is.)
19:38:42 <Vorpal> rather, keep a count of free cells for each page
19:38:47 <Vorpal> that makes updating it easier
19:38:51 <alise> Vorpal: I don't need to worry about pages this way.
19:39:11 <Vorpal> alise, well, you don't need your blocks to be page-sized. Just seemed a reasonable chunk size
19:39:27 <alise> Eh. Divide by however many bits are in a long, & ...0... it, where the 0 is at the position of the remainder.
19:39:35 <alise> Sounds complicated but really just one or two lines of code to update it.
19:39:50 <alise> And let's see, if we assume 32-bit we have 4 bytes in each.
19:39:51 <Vorpal> alise, anyway lets say each chunk start with a bitmask. And you have a global mask of full/non-full pages. Where each page is a bit
19:40:06 <cpressey> Vorpal: You can store the freelist inside the cells themselves. In a sense, it's just another Lisp list.
19:40:11 <alise> So for 4 megabytes, we can store a million cells.
19:40:15 <alise> 4 megabytes of metadata, that is.
19:40:16 <Vorpal> alise, then after allocating you just test if your bitmask for the page is all 1, and if so set the global table as it
19:40:20 <Vorpal> cpressey, that works too
19:40:21 <alise> A cell is a cons, or a symbol, or whatever.
19:40:33 <alise> cpressey: Ah, good idea.
19:40:47 <alise> So every N cells has a count of how many free cells there are in the next N cells?
19:40:56 <cpressey> You do need a mark bit somewhere, though, yes.
19:41:37 <cpressey> LSB of the pointer is traditionally a good choice, since cells are two bytes long. You probably know that much...
19:41:52 <Vorpal> why are cells 2 bytes only?
19:42:06 <alise> cpressey: LSB of which pointer?
19:42:13 <cpressey> I mean, at least 2 *addresses*.
19:42:28 <Vorpal> on x86-64 they would be... 16 bytes each?
19:43:31 <cpressey> alise: The tail pointer. If you're storing "improper" lists I can see how that might pose a problem.
19:43:32 <Vorpal> alise, I seem to remember some lisp(s) did some trick by being able to store lists so that the next element's car was in the previous cdr
19:43:39 <Vorpal> as a space optimisation
19:43:44 <fizzie> Ooh, haha: homework exercise 6 of that "course with the bignums in it": "Make a program that reads a file and encrypts/decrypts it into another file. You can invent the encryption algorithm by yourself. If you don't want, you can use this: [description of rot-N, where N is the key, and the description itself even manages to be wrong; it "encrypts" letters A..Z, but does modulo 25 instead of 26.]"
19:43:47 <Vorpal> setting some control bit to indicate this was being done
19:43:48 <alise> cpressey: Of course I am.
19:44:09 <alise> Vorpal: cdr coding
19:44:12 <cpressey> alise: Then you need to find some other place for it :)
19:44:22 <Vorpal> alise, going to do that?
19:44:28 <alise> Vorpal: it's a bitch
19:44:37 <Vorpal> alise, yes it messes up allocation
19:44:42 <cpressey> heh. I was just going to say, "cdr coding is a bitch!"
19:44:44 <alise> (cdr cdr-coded-list)
19:44:55 <alise> Unrolled linked lists are simpler and often higher-performance than CDR coding (no "tagged pointers"; typically less fragmentation). For short lists, CDR coding uses the least amount of space.
19:44:59 <Vorpal> alise, well messing up allocation is partly a side effect of messing up alignment
19:45:04 <cpressey> Maybe for serialization it's OK.
19:45:49 <Vorpal> cpressey, back when memory was a much more limited resource it probably made sense
19:46:07 <cpressey> Merf. I should probably implement a lisp at some point. I mean, in something other than another lisp.
19:46:38 <cpressey> Uhhhh not what I was thinking.
19:46:45 <Vorpal> cpressey, it would be cool however
19:47:18 <cpressey> Are there any Befunge interpreters out there that implement GC of the playfield? (implement it, not rely on their implementation langauge for it)
19:47:27 <alise> cpressey is like Rupert Holmes, unable to escape from his song with Piña Coladas.
19:47:31 <cpressey> 'Cos FBBI sure as hell doesn't.
19:47:47 <Vorpal> cpressey, how can you GC the funge-space?
19:47:50 <cpressey> alise: Or that other guy, and "Werewolves of London".
19:48:00 <Vorpal> cpressey, you can't possibly know if some funge code references it
19:48:03 <alise> cpressey: Or Chris Pressey, and Befunge!
19:48:36 <Vorpal> cpressey, or do you mean freeing up memory used by spaces?
19:48:38 <cpressey> Vorpal: Uh. If a range of space is empty -- free the memory for it?
19:48:56 <alise> cpressey: Do you think that a-bunch-of-adjacent-cells representation for symbol names is a good idea?
19:49:16 <Vorpal> cpressey, cfunge will free the cell in the hash array backed area if it is set to space
19:49:20 <cpressey> alise: Not for GC-friendliness, no. not so much.
19:49:29 <Vorpal> cpressey, it does that by returning it to a pool
19:49:34 <Vorpal> rather than calling free()
19:49:54 <cpressey> Vorpal: does it ever call free() on them?
19:49:55 <alise> I'm reading PicoLisp's source and then making sure to forget the exact code so I don't violate the GPL.
19:50:02 <Vorpal> cpressey, well it allocates the hash cells from some internal pools. It just returns those to it
19:50:21 <Vorpal> cpressey, and no it doesn't free up pools if an entire pool would ever become empty
19:50:28 -!- mr45 has quit (Ping timeout: 276 seconds).
19:50:43 <cpressey> Vorpal: So if I have a Befunge program which p's a # into (0,0), then erases it and p's # into (0,1), etc, etc, will cfunge eventually run out of memory? From what you say it sounds like the answer is "yes".
19:50:44 <Vorpal> cpressey, still, many programs fit neatly inside the static backed area around 0,0
19:51:11 <Vorpal> cpressey, because it will put the freed up hash entry into the free list
19:51:19 <Vorpal> cpressey, and it will use that before allocating new pools :P
19:51:24 <alise> typedef enum {NO,YES} bool;
19:51:42 <alise> typedef struct cell { // PicoLisp primary data type
19:51:50 <alise> So it really is just two bytes.
19:51:51 <alise> How does that work?
19:52:02 <fizzie> Vorpal: But if you make a Befunge program that uses four gigabytes of space for a while, then erases almost everything, you won't return the uselessly allocated gigabytes to the system, right?
19:52:32 <alise> *(word*)&cdr(p) &= ~1;
19:53:09 <Vorpal> typedef union memory_block {
19:53:09 <Vorpal> struct s_fspace_hash_entry data;
19:53:09 <Vorpal> union memory_block *next_free;
19:53:13 <alise> cpressey: I am not sure that makes sense.
19:53:20 <alise> cpressey: Although, wait.
19:53:26 <alise> cpressey: It does if you just use 31-bit integers.
19:53:32 <Vorpal> cpressey, chunks of those are used. And a free list
19:53:49 <alise> typedef struct heap {
19:53:49 -!- choochter has quit (Ping timeout: 265 seconds).
19:53:49 <alise> cell cells[CELLS];
19:53:49 <alise> struct heap *next;
19:53:50 <Vorpal> <fizzie> Vorpal: But if you make a Befunge program that uses four gigabytes of space for a while, then erases almost everything, you won't return the uselessly allocated gigabytes to the system, right? <-- no, but I have yet to see such a program in practise
19:54:07 <Vorpal> fizzie, in practise here means "not specifically made as a benchmark"
19:54:18 <alise> There are no Befunge programs in practice.
19:54:23 <alise> Apart from fungot.
19:54:24 <fungot> alise: those who did see it a workman, a servant, and the moon is above and the clouds of the sky and fnord itself in the birth of my grandmother and fnord uncle might be sheer fancy on my part proposed, for his eyes were irresistibly drawn. and then my fancy reverted to the locale as i reflected that the excitant folklore was undoubtedly more universal in the past.
19:54:24 <fungot> http://git.zem.fi/fungot/blob/HEAD:/fungot.b98
19:54:28 <alise> Apart from fungot.
19:54:28 <fungot> alise: sometimes heard today, fnord by extensive scientific interests and aided by large numbers of fishing boats from gloucester, made a thorough and really significant digest. average people
19:55:29 <fungot> Available: agora alice c64 ct darwin discworld europarl ff7 fisher ic irc jargon lovecraft* nethack pa speeches ss wp youtube
19:55:38 <fizzie> Vorpal: fungot in some sense; it would be "nice" if when an evil IRC user makes a space-wasting Underload program, it'd return the wasted space to the system after the program's been finished. (Not that it's a problem in practice, since there's a size limit for the Underload stack.)
19:55:39 <fungot> fizzie: the lovecraft library wishes to extend its gratitude to eulogio garca recalde for transcribing this text. he had to fnord had to get me in a thin envelope of fnord metal. he had counted about thirty when a sound reached him very fnord and
19:55:57 <Vorpal> fizzie, yeah and probably some user will do it again
19:56:05 <Vorpal> fizzie, and then it will already have it allocated
19:56:35 <Vorpal> fizzie, anyway it is tricky, since the used cells might be spread out
19:56:55 <Vorpal> fizzie, in fact, I would say it is rather likely
19:57:32 <fizzie> Yes, though if you allocate in pages, you could opportunistically free pages that contain only free'd pointers, if ever such occur. (It'd be a bit annoying to go through the free-list removing those, though.)
19:57:50 <fizzie> 6824k VSZ, 5328k resident; it's not a very memory-intensive process there.
19:57:58 <Vorpal> fizzie, yes, and checking for that condition would incur some overhead
19:58:13 <Vorpal> fizzie, which for the majority of the cases would be non-useful
19:58:43 <Vorpal> fizzie, anyway, let me check how much I allocate at once
19:58:44 <alise> For something even smaller, download miniPicoLisp.tgz. It is a minimal version, without support for databases, UTF-8, bignums, IPC, networking and other system-dependent functions. A kind of "pure" PicoLisp (not "pure Lisp"!). It supports the full PicoLisp language, but runs faster, and uses even less memory space. It should also not be restricted to Unix. In addition, it compiles and runs also on 64-bit systems.
19:59:01 <fizzie> 7952k virtual, 6408k resident now.
19:59:26 <alise> #define WORD ((int)sizeof(long))
19:59:26 <alise> #define BITS (8*WORD)
19:59:33 <fizzie> (I can't recall my underload stack limits.)
19:59:49 <fizzie> Ooh, not using CHAR_BIT, how dreary!
19:59:57 <Vorpal> fizzie, more than a page at a time I think
20:00:20 <fizzie> A conceptual "page", anyway; a biggish blob.
20:00:58 <fizzie> (I wasn't expecting you to sysconf(_SC_PAGESIZE) the allocation size.)
20:02:04 <Vorpal> fizzie, I think each hash entry is 4*8 bytes or something like that (x,y,value,next-in-same-bucket)
20:02:09 <Vorpal> fizzie, possibly a bit more
20:02:29 <alise> #define val(x) ((x)->car) ;; huh
20:02:32 <Vorpal> each chunck is 4096 hash entries
20:02:36 <Vorpal> fizzie, so yeah more than a page
20:02:56 <alise> #define EVAL(x) (isNum(x)? x : isSym(x)? val(x) : evList(x))
20:03:37 <Vorpal> fizzie, that is of course assuming a 64-bit funge
20:03:46 <Vorpal> fizzie, x,y,value would be smaller otherwise
20:04:15 <Vorpal> while next-in-same-bucket would depend on pointer size
20:04:35 <Vorpal> alise, where is that code from?
20:04:43 <alise> Vorpal: miniPicoLisp
20:04:54 <Vorpal> alise, that's an absurd name
20:05:03 <alise> it's a smaller version of PicoLisp. :P
20:05:13 <Vorpal> alise, yeah but pico already implies it is small...
20:05:23 <Vorpal> alise, it should be FemtoLisp or something
20:06:28 <fizzie> Speaking of which, CHAR_BIT is indeed 8 in the TI C64xx. I guess they fake byte-addressing, then, since the hardware is definitely unable to do it. (Though it admittedly does use byte-indexed pointers, so that for all pointer values the LSB is 0.)
20:06:47 <fizzie> Maybe there was in fact some special unaligned-read op in there.
20:10:37 <fizzie> Oh, yes, LDNW/LDB and such. (Whose idea it was to make the instruction set reference PDF not include the actual instructions in the PDF table-of-contents metadata? There's just chapter 3.11, "Instruction Descriptions", page 87, and the next thing in the TOC is chapter 4, "Pipeline", page 509.)
20:13:24 <fizzie> (There's also lots of hyperlinks, but no single instruction index. There's six separate "list of instructions executing in the [foo] functional unit" lists (with links to descriptions), but between each list there's ten pages of opcode encoding tables. It's like it's designed to be as difficult as possible to look up opcodes by name.)
20:14:24 <fizzie> (I'm wondering if TI's expensive and sucky -- well, it *was* sucky last I saw it -- IDE has some sort of instruction lookup feature, and therefore they've left it out of these freely downloadable PDFs, so that it's not competing with the IDE docs.)
20:36:22 -!- Phantom_Brodrost has quit (Ping timeout: 245 seconds).
20:38:23 -!- Phantom_Brodrost has joined.
20:43:40 -!- Behold has joined.
20:45:23 -!- sshc_ has joined.
20:45:30 -!- iGO has joined.
20:46:36 -!- iGO has quit (Client Quit).
20:46:45 -!- iGO has joined.
20:47:40 -!- BeholdMyGlory has quit (Remote host closed the connection).
20:47:41 -!- sshc has quit (Remote host closed the connection).
20:47:49 -!- cheater- has quit (Excess Flood).
20:47:57 -!- Quadrescence has quit (Ping timeout: 265 seconds).
20:48:01 -!- Behold has changed nick to BeholdMyGlory.
20:48:26 -!- cheater- has joined.
20:50:02 -!- iGO has quit (Client Quit).
20:50:31 -!- iGO has joined.
21:01:20 -!- Quadrescence has joined.
21:17:14 -!- augur has quit (Ping timeout: 264 seconds).
21:39:41 -!- Phantom_Brodrost has changed nick to Vonlebio.
21:41:20 -!- MigoMipo has quit (Read error: Connection reset by peer).
21:45:37 -!- tombom has joined.
21:45:41 -!- tombom has quit (Read error: Connection reset by peer).
21:46:07 -!- augur has joined.
21:46:47 -!- Mathnerd314 has quit (Ping timeout: 245 seconds).
21:50:04 -!- Phantom_Hoover_ has joined.
21:50:18 -!- Vonlebio has quit (Ping timeout: 265 seconds).
21:50:20 -!- derdon has quit (Ping timeout: 240 seconds).
21:53:50 -!- iGO has quit (Quit: Leaving).
21:58:17 -!- Mathnerd314 has joined.
22:04:39 -!- olsner has quit (Quit: Leaving).
22:10:09 -!- augur has quit (Ping timeout: 240 seconds).
22:15:16 -!- olsner has joined.
22:20:06 -!- kar8nga has quit (Remote host closed the connection).
22:23:39 -!- Phantom_Hoover_ has quit (Ping timeout: 265 seconds).
22:27:04 -!- Phantom_Hoover_ has joined.
22:32:33 -!- zzo38 has joined.
22:34:23 <zzo38> Maybe I should allow Enhanced CWEB to ignore a shebang line at the top of a file, so that it can be used on Hackiki
22:36:53 <zzo38> Do you think it is good idea?
22:37:31 <zzo38> You should make a Hackiki on the esolang, such as /hackiki/ directory instead of /wiki/ to tell differerence
22:37:50 <zzo38> And also allow Hackiki files and MediaWiki files to be able to read each-other (but not write)
22:38:25 <zzo38> And put a field in the MediaWiki account to associate them with a OpenID, to be used with Hackiki.
22:38:38 <zzo38> Phantom_Hoover_: I was thinking about the same idea in the past.
22:39:00 <Phantom_Hoover_> Well... it would need UI capabilities, to keep to BANCStar's spirit.
22:41:40 <zzo38> Phantom_Hoover_: Yes I think you might be correct, and you would do it in the strange way that BANCStar does it.
22:45:38 -!- oerjan has joined.
22:45:46 <Vorpal> Phantom_Hoover_, BANCStar-oid. <-- it had oids?
22:46:16 <Vorpal> Phantom_Hoover_, do you mean oids as in SNMP?
22:46:49 <zzo38> So just guess and see if the example program is sensible in the way that you guessed.
22:46:56 <Phantom_Hoover_> No, I mean as in something similar enough that you could confuse them without close inspection.
22:47:29 <Vorpal> Phantom_Hoover_, why oids though? There are a lot of other stuff you could think of putting in a bankstar context
22:47:34 <Vorpal> Phantom_Hoover_, so why oids
22:47:59 <zzo38> If it is done in a way that the example program is still a sensible program (even if it does not do the same thing as before), then it can be confuse them even with close inspection.
22:48:14 <Phantom_Hoover_> Vorpal, "-oid"? Prefix I use to indicate close similarity, per the English prefix?
22:48:58 <Vorpal> Phantom_Hoover_, to me oid = http://en.wikipedia.org/wiki/Object_identifier
22:49:05 <Vorpal> Phantom_Hoover_, thus the confusion
22:49:29 <Vorpal> oerjan, that pun was so terrible
22:49:54 <Vorpal> oerjan, btw what does the c stand for? care?
22:50:26 <Vorpal> Phantom_Hoover_, well SNMP is to me the very epitome of excessive software engineering!
22:50:41 <Vorpal> Phantom_Hoover_, should be ois :/
22:50:56 <Vorpal> Phantom_Hoover_, yeah, I don't like that
22:51:10 -!- FireFly has quit (Quit: swatted to death).
22:51:44 <Phantom_Hoover_> Vorpal, the whole acronym is phonetic that way, which is rather neat.
22:51:46 <Vorpal> Phantom_Hoover_, OIDs are used in X.509 certs too
22:51:54 <Vorpal> again too much software engineering
22:54:03 <Phantom_Hoover_> So anyway, http://reocities.com/ResearchTriangle/station/2266/tarpit/bancstar.html is the sum total of all accessible information on BANCStar.
22:56:58 <zzo38> I made a backup of that HTML page.
22:59:18 <Phantom_Hoover_> If there was any consistency in the instructions, that would help...
23:01:19 <zzo38> 3001 is a block conditional, so maybe 3001,,, is the end of the block
23:02:34 <zzo38> Ther are only 3 other numbers?
23:03:10 <zzo38> Maybe there is the number of the constant/variable, the number indicating the comparison type, and the value to compare it with
23:04:01 * Phantom_Hoover_ keeps viewing this from too much of an assembly perspective
23:07:02 -!- Phantom_Hoover_ has quit (Quit: Leaving).
23:13:39 -!- BeholdMyGlory has quit (Remote host closed the connection).
23:14:37 -!- alise has quit (Ping timeout: 258 seconds).
23:31:28 -!- Mathnerd314 has quit (Ping timeout: 276 seconds).
23:34:53 -!- Mathnerd314 has joined.
23:59:19 <zzo38> http://sprunge.us/BCVI