00:05:15 -!- tombom has quit (Quit: Leaving).
00:10:07 <Sgeo_> Which is worse, T-Mobile, or AT&T
00:12:12 <alise> T-Mobile has not-so-good 3G coverage; AT&T hates its customers and blames them using its service for its extremely subpar performance.
00:13:15 <Sgeo_> Looking at the maps
00:13:16 <oerjan> hey, it's not AT&T's fault it gets all the hoarders
00:13:30 <Sgeo_> I looked at AT&T map the other day, my area had 3G coverage
00:14:07 <Sgeo_> T-Mobile has "Fast Mobile Web" [as opposed to Very Fast Mobile Web, or Mobile Web] in most, but not all, of my area
00:16:13 <alise> Well, let me tell you that as someone who doesn't have a 3G phone -- only EDGE -- I don't really miss it.
00:16:19 <alise> Maybe if you wanted to watch YouTube a lot when nowhere near WiFi.
00:19:13 -!- Gracenotes has joined.
00:19:48 <Sgeo_> Also, my dad wants me to hide this from my step-mother and her mother
00:20:01 <Sgeo_> Meaning no nice free calls with Google Voice to/from them
00:20:16 <Sgeo_> Among other annoyances
00:36:12 <alise> Your family sounds nice and well-adjusted. :)
00:58:08 -!- alise_ has joined.
00:59:07 -!- alise has quit (Ping timeout: 258 seconds).
01:03:32 -!- augur has quit (Remote host closed the connection).
01:06:16 <alise_> Make sure you're on .com.
01:06:27 <alise_> The logo /is/ redesigned, and the UI /is/ significantly different.
01:06:38 <pikhq> Yup, still the normal Google.
01:06:48 <pikhq> Got the text-fadein-thing of a few months ago and everything.
01:07:15 <alise_> Yes, but http://www.google.com/intl/en_ALL/images/srpr/logo1w.png is definitely new.
01:07:26 <alise_> As is the redesigned sidebar on a search results page.
01:07:33 <pikhq> Yeah, that's not what I'm seeing.
01:07:37 -!- augur has joined.
01:07:45 -!- BeholdMyGlory has quit (Remote host closed the connection).
01:07:49 <alise_> Want some screenshots?
01:07:51 <pikhq> http://www.google.com/intl/en_ALL/images/logo.gif <-- This is what I get.
01:08:02 <alise_> Are you on google.com? Clear cache, mayhaps.
01:08:02 -!- FireFly has quit (Quit: Leaving).
01:09:19 <alise_> Okay, uploading images now
01:10:35 <alise_> pikhq: http://imgur.com/5k9XF.png, http://imgur.com/ymPSq.png, http://imgur.com/FaxDX.png
01:11:20 <alise_> It's an improvement, mind you; looks cleaner. But still, Google changing their logo? That's only happened onfce.
01:11:23 -!- Asztal has quit (Ping timeout: 276 seconds).
01:11:38 <pikhq> alise_: Holy fudgsicles
01:12:09 <alise_> My path to Google is less cached than yo-ou, my path to Google is less cached than yo-ou!
01:12:14 <alise_> Na na na na na, na na na na na!#
01:15:31 <Gregor> Naaaaaaaaaaa na na na na na naa naa na naa naa nana naaaaaaaa
01:15:47 <pikhq> Erm, sorry. 塊民主主義.
01:17:02 <pikhq> "Katamari minshushugi" just sounds less awesome than "Katamari damashii". XD
01:17:50 <pikhq> Not to mention a bizarre concept.
01:17:54 <pikhq> "Clump democracy"?
01:21:47 <pikhq> "Naaaaaaaaaaaa na na na na na na katamari minshushugi...."
01:24:22 <oerjan> the political system you feel attached to
01:24:35 -!- fhoahf38771 has joined.
01:24:35 -!- fhoahf38771 has left (?).
01:32:19 -!- jcp has joined.
01:33:29 -!- MizardX has quit (Ping timeout: 276 seconds).
01:35:36 -!- MizardX has joined.
01:40:44 <Sgeo_> WHY IS ECLIPSE SO DAMN SLOW?
01:41:32 <alise_> Use Emacs or something.
01:41:52 <Sgeo_> Emacs doesn't have an Android Developer Tools plugin
01:42:05 <Sgeo_> ADT even has a Glade-like thing
01:42:47 <Sgeo_> Write out boring XML by hand, or use Eclipse.. hm
01:43:52 <oerjan> lava or liquid helium, that's the question
01:43:54 <Sgeo_> *waits 5 minutes to switch to the xml file for the layout
01:44:53 <alise_> algorithms are the best things ever
01:45:53 <alise_> if you disagree consider that i just replaced your mother with an algorithm
01:46:01 <alise_> er that wasn't intended specifically at either of the two people talking
01:47:37 <alise_> algae rhythms is a nice term
01:49:16 -!- zzo38 has joined.
01:50:07 <alise_> got my algorithm yet :P
01:51:16 <alise_> i'll have you fired for this :P
01:51:17 <zzo38> Have you ever used pointer to pointer to pointer, in C programming? How many level of pointers have you used
01:52:03 <alise_> zzo38: three-star programmer!
01:52:23 <alise_> http://c2.com/cgi-bin/wiki?ThreeStarProgrammer
01:52:47 <zzo38> I have that page already open in my browser, before you posted it
01:52:52 <alise_> zzo38: I'm an n-star programmer, my code is so abstract that the depth of nested pointers depends fundamentally on the subtle properties of the algorithm I'm metaimplementing
01:53:27 <Gregor> If I ever get beyond 2, I add more types.
01:53:37 <zzo38> I have used three stars at most, I think.
01:53:37 <Gregor> Even a struct with only one member will clear things up extraordinarily.
01:53:54 <alise_> A struct with only one member? Jesus weeps.
01:53:59 <alise_> If I ever get beyond 2, I rethink my design.
01:54:10 <zzo38> And I wrote the three star code today, in fact, as part of a command-line argument parsing program
01:54:37 <zzo38> I have created structs that are completely unused, in fact. And there is a reason for that.
01:54:40 <alise_> Generally I just try and avoid using languages that have the anti-abstraction of pointers.
01:54:45 <pikhq> alise_: A struct with only one member is a way of forcing C to have more types. :)
01:54:58 <pikhq> Also. Pointers, an abstraction?
01:55:08 <alise_> I said antiabstraction.
01:55:10 <pikhq> If they are, they're the thinnest possible abstractions.
01:55:21 <alise_> They deabstract memory; they make it more concrete than it needs be.
01:55:55 <zzo38> alise_: I disagree. I think they need to deabstract a bit more things to make C useful in some ways, too
01:56:11 <alise_> zzo38: I'm just a mathematical weenie, though.
01:56:12 <pikhq> They *do* make things like "moving objects" a royal pain. And lord help you if you want a compacting GC.
01:56:31 <alise_> I don't really care about stupid machines. Everything's graph reduction, or high-school algebra. :)
01:56:45 <pikhq> (it's possible... If you force all dereferencing through your GC.)
01:57:09 <zzo38> If you want a lot of abstraction in that kind of way, perhaps you can use a different program language for your project
01:57:35 <pikhq> alise loves his abstractions.
01:57:48 <alise_> Get the confusing pronouns correct!
01:57:49 <pikhq> C allows precious few.
01:57:54 <alise_> I /will/ demolish English!
01:58:16 <pikhq> Unless you want me to start using Japanese pronouns.
01:58:26 <zzo38> http://c2.com/cgi-bin/wiki?YouMightBeaThreeStarProgrammer
01:58:52 <alise_> zzo38: Technically I'm in favour of low-level programming: just low-level programming on a decent machine; something like the Reduceron that does symbolic reduction, not a silly peeking-and-poking 70s BASIC machine like we all use today.
01:58:56 <pikhq> Actually. Kochira know what? Ware think ware'm going to. :P
01:59:01 <alise_> Throw it all out and start again; then everything will be perfect.
02:00:19 <pikhq> (note: all pronouns in use are completely and utterly *bizzare* to use in normal Japanese, if valid. Koretachi are somewhat difficult to map into English otherwise. :P)
02:01:19 <alise_> 2b \/ ~2b, obviously multiplication on the booleans is just mod-2, so this is 0*b = false, so we have false \/ ~false, i.e. false \/ true
02:01:25 <alise_> shakespeare, it's true.
02:01:29 <alise_> thought you might like to know.
02:01:54 <pikhq> Hah. Nanji wouldst do such a thing.
02:02:05 <zzo38> Some of the things listed in the YouMightBeaThreeStarProgrammer are I have used, but some I don't.
02:02:12 <alise_> pikhq: Who, what, where, why, when?
02:03:13 <zzo38> I don't write code which intentionally depends on undefined/unspecified behavior when writing in C, because C is supposed to be cross-platform. But I sometimes *do* intentionally undefined/unspecified behavior when writing in a lower-level program language such as plain machine-codes, but not always. It depends on circumstances.
02:03:24 <pikhq> Dare, nani, doko, naze, nan no toki?
02:04:15 <pikhq> ("nanji" not used for where to avoid confusion with "nanji" for thou)
02:04:39 <zzo38> "You have ever wished you could set a breakpoint within an expression." Yes, I have wanted this. In C, but also in other programming languages too
02:05:04 <pikhq> zzo38: The difference between expressions and statements is just silly.
02:05:21 <pikhq> Erm. Distinction, is nani ware meant.
02:06:30 <zzo38> pikhq: Yes, it is a bit. In Forth there is no difference between expressions and statements. But in C some statement must be used not inside of a expression
02:06:45 <zzo38> (Although GNU C allows code-blocks inside of expressions)
02:07:12 <pikhq> alise_: So, nani anata are saying is that ware should use kore for Fungespace?
02:07:25 <alise_> pikhq: It may be an idea.
02:07:26 -!- augur has quit (Remote host closed the connection).
02:07:31 -!- augur has joined.
02:07:32 <alise_> pikhq: Either that, or quadtrees.
02:07:49 <pikhq> And I'm going to stop the silliness with pronouns.
02:07:54 <alise_> But, you know, http://judy.sourceforge.net/ is all pre-made and well-engineered for you.
02:07:59 <pikhq> Except for 君, alise_.
02:08:19 <alise_> And it has a nice API.
02:09:10 <alise_> pikhq: You might also, if you care about performance, want to add a static array of maybe a megabyte in size somewhere near (0,0) to handle "most" accesses.
02:09:35 <zzo38> "You have bitshifted the result of a boolean expression and used it as an array index..." Yes, I have, both in C and in BASIC and others. I have done this to fix a bug in MegaZeux so that the spiders can travel on their proper kind of web
02:10:06 <zzo38> (Or even outside of a web, as the case may be)
02:11:49 <alise_> Multiple times I day I get very pissed off at how immature software engineering is.
02:12:07 <alise_> We've been doing this gig since about the 50s, and we still haven't figured out how to code properly.
02:13:13 <zzo38> It is true, some people can't program neatly at all. Many examples on http://thedailywtf.com/Series/CodeSOD.aspx
02:14:40 <pikhq> alise_: I was actually thinking of doing something like precomputing the ray of execution into a single thread, and just interpreting from that. And cacing precomputed threads.
02:14:51 <alise_> pikhq: Not sure what you mean by that.
02:14:55 <alise_> zzo38: Indeed, but even good programmers are bad.
02:14:58 <pikhq> (thread in the "threaded programming" since)
02:15:10 <alise_> pikhq: That makes p/g harder.
02:15:20 <alise_> pikhq: Also, remember to test Mycology regularly. Also, exact bounds.
02:15:22 <alise_> You need exact bounds.
02:15:32 <zzo38> Yes, I have written codes that later I thought was TRWTF (but some of the codes that other people don't like that I wrote, I find to be perfectly OK, but not always)
02:15:37 <alise_> For y, you need to be able to determine the exact maximum and minimum (x,y) coordinates of inhabited fungespace.
02:16:00 <pikhq> Yes, it requires that I *either* keep track of the cells in each thread so I can invalidate them on modification, or just chuck out the entire cache upon modification.
02:16:32 <pikhq> And yes, I have every intent of keeping track of exact bounds.
02:17:03 <Sgeo_> How is pikhq storing Fungespace?
02:17:09 <alise_> Well, I'd say you are, in all likelihood (I haven't seen a piece of complex code by you), a very competent software engineer. And I can't think of any problems with your scheme.
02:17:12 <pikhq> Judy array, it seems.
02:17:16 <alise_> Sgeo_: Well, I've suggested Judy arrays.
02:17:34 <pikhq> alise_: I shall after this weekend.
02:17:36 <alise_> pikhq: You'll want to lightly spec some sort of abstract fungespace interface so you can swap it out later, of course; in case, say, quadtrees are significantly faster.
02:17:50 <alise_> Language is plain C, I assume? Maybe GNU C.
02:18:31 <pikhq> I make a lot of use of C99 features by habit, and my "compiling into threads" bit requires computed goto.
02:18:40 <alise_> I look forward to seeing your progress over the coming weekends; and hopefully soon enough weekdays too.
02:18:54 <pikhq> Which, amusingly, clang handles much more efficiently than GCC.
02:19:08 <Sgeo_> I guess in AndFunge-98, I'd use the NDK to access the Judy array stuff?
02:19:21 <alise_> Stop calling it AndFunge; just makes me think of Avid NorlanDer.
02:19:31 <alise_> And I'd just implement it all in Java.
02:19:58 <Sgeo_> It's still a long way off, ofc
02:20:12 <uorygl> I keep feeling an urge to do some object-oriented programming in a language like Java.
02:20:29 <alise_> uorygl: You're just longing for the platonic realisation of the hype.
02:20:32 <zzo38> I have another question: Have you ever used __attribute__((unused)) in GNU C?
02:20:37 <alise_> A brief session coding in such a language should dispel any illusion.
02:20:43 <uorygl> I never feel like doing anything in particular; I keep just wanting to use it.
02:20:46 <pikhq> zzo38: No, I haven't.
02:21:03 <alise_> I avoid __attribute__ because I like to let the compiler think about optimisations rather than making half of my program instructions to the optimiser. :P
02:21:05 <zzo38> Have you ever used *any* __attribute__ in GNU C? And if so, which ones?
02:21:17 <alise_> I've used noreturn, when doing fiddly Scheme compilation stuff.
02:21:21 <Sgeo_> I'm only using Java because Android uses, well, not the JVM, but something that JVM bytecode gets compiled into
02:21:29 <alise_> And probably printf-checking attributes, for error reporting functions that do printf-formatting.
02:21:49 <alise_> Sgeo_: Considered Jython/JRuby/Scala/etc?
02:22:10 <Sgeo_> alise_, I want to get up-to-speed with the basics of Android dev first
02:22:11 <alise_> You could still use the GUI APIs that way; or if there's some actually-Java-specific thing, write the GUI in Java and interface to the actual interp.
02:22:36 <zzo38> alise_: I like to tune optimizations myself and stuff, but I just do more of that "RealProgrammer" stuff that is generally not preferred in modern programming, sometimes
02:22:58 <zzo38> I have used __attribute__((hot)) and even __attribute__((unused)) and more
02:23:34 <Sgeo_> Currently, Eclipse is getting in my way more than Java is
02:24:03 <zzo38> Why is there a "Do Not Click" button?
02:24:15 <uorygl> I tried Android extremely briefly today.
02:24:26 <uorygl> It seemed to have more features, less well implemented, than the iPhone.
02:25:42 <alise_> uorygl: Did you try Android 2?
02:25:47 <alise_> Android 1 was very unpolished.
02:25:56 <alise_> Also, Android really suffered on slower CPUs.
02:26:03 <uorygl> I have no idea what I tried. It was in a store.
02:26:23 <alise_> Well, there are quite a few not-so-good Android phones out there.
02:26:38 <alise_> But the Nexus One and the HTC Desire, say, are almost certainly as good as the iPhone, or at least very near it.
02:26:57 <alise_> And, you know, they're unlike the iPhone in that they don't completely disallow any non-Objective-C language to be used, even pre-compiled, in their legal documents.
02:27:05 <alise_> Which is sort of a big deal.
02:28:24 <zzo38> while(pc) (***++pc)();
02:28:42 <zzo38> Is it possible to make a coprocessor for ARM which adds an instruction to quickly execute that?
02:28:57 <zzo38> I would find such an instruction useful directly in machine code
02:29:11 <uorygl> What does that do? I don't speak C.
02:29:19 <zzo38> Or, actually I mean just: (***+pc)();
02:29:22 <uorygl> At least, not C with ***++ in it.
02:29:35 <zzo38> The while(pc) part would be a separate instruction
02:29:41 <zzo38> Sorry, I meant (***++pc)();
02:29:45 <zzo38> (I forgot a plus sign)
02:29:54 <alise_> uorygl: Copy the value of pc to pc1. Increment pc. Dereference pc1 into pc1*. Dereference pc1* into pc1**. Dereference pc1** into pc1***.
02:30:03 <alise_> pc1*** is some code; execute it.
02:30:08 <alise_> Repeat while pc is not zero.
02:30:34 <Sgeo_> that would be ***pc++
02:30:50 <zzo38> There could be one register (or the command could work with multiple registers) that would be the "pc" in this example and it would execute (***++pc)()
02:30:59 <alise_> uorygl: Increment pc. Dereference pc into pc*. Dereference pc* into pc**. Dereference pc** into pc***.
02:31:03 <alise_> pc*** is some code; execute it.
02:31:07 <alise_> Repeat while pc is not zero.
02:31:11 <Sgeo_> When would this be useful?
02:31:18 <alise_> uorygl: So, basically, pc is a pointer-to-a-pointer-to-a-function-pointer.
02:31:34 <alise_> So a function-pointer is basically a passable-'round bit of mutable executable code.
02:31:34 <uorygl> When you have indirection.
02:31:42 <alise_> So pointer-to-pointer-to-koed.
02:31:55 <pikhq> zzo38: I've used __attribute__((malloc)), because it sometimes lets the compiler generate better code.
02:32:17 <pikhq> (all that that does is state that any non-NULL pointers returned don't alias anything else)
02:33:29 <zzo38> I haven't use all the __attribute__ but I have read all of them and might use all of them if I have the use for them. What I would also like is the ability to use __attribute__ for blocks inside of a function instead of only for the entire function
02:35:48 <alise_> pikhq: http://mazonka.com/subleq/hsq.html A compiler from a reasonably competent C-esque language into Subleq.
02:35:56 <alise_> It can also do bignums.
02:36:02 <alise_> Mazonka is as crazy as he is cool.
02:36:05 <zzo38> I have written ARGOPT today and I used three stars so that is why I tried to comment it
02:36:47 <alise_> pikhq: Subleq, in case you've had a case of amnesia, is "subtract and branch if less than or equal to 0".
02:36:59 <pikhq> alise_: Fun language.
02:36:59 <zzo38> I plan to use ARGOPT when I write a new GNU/Linux distribution (although with a lot of differences in both GNU and in Linux)
02:36:59 <alise_> So compiling that... into that... yowzers.
02:37:13 <pikhq> Fairly impressive that he did that, though.
02:37:25 <alise_> http://esoteric.voxelperfect.net/wiki/Higher_Subleq It even compiles to a sort of twisted assembly beforehand.
02:37:46 -!- zzo38 has left (?).
02:38:06 <alise_> pikhq: He even implemented printf.
02:38:11 <Sgeo_> My dad doesn't want me carrying a charger nor a spare battery around
02:38:11 <uorygl> Is Esolang's User:Oleg the same Oleg as the famous Haskell Oleg?
02:38:25 <alise_> uorygl: No; I don't believe so.
02:39:06 <pikhq> I applaud this guy.
02:39:08 <Sgeo_> Personally, I'd rather not, but willing too if battery life is too short
02:39:54 <uorygl> I know alise already asked, and you already responded, but why not?
02:40:45 <alise_> uorygl: I gather, from recent things he's said, that his father is rather apprehensive about chipping money into a new phone and seems to be dictating things purely for the sake of it.
02:41:03 <alise_> He was reportedly earlier making baseless assertions about the quality of PDFs on phones, so... who knows.
02:41:12 <alise_> THE WAYS OF ADULTS ARE NOT TO BE KNOWN
02:42:03 <alise_> I feel like making my own OISC now.
02:42:32 <pikhq> alise_: Do it in Funge!
02:42:34 <alise_> hmm; with a bignum machine we only need one parameter to the instruction because we have N^n -> N mapping
02:42:43 <alise_> but can we have a fixed-bit-size OISC that only has one operand?
02:43:17 <Sgeo_> alise_, if you want to give up TC, yes
02:43:29 <uorygl> Take A, subtract B, divide by C, NAND with D, if greater than E, branch to F.
02:43:39 <Sgeo_> [Note that I make no statement about whether it's possible to do it and still be TC]
02:43:40 <alise_> Sgeo_: No shit, sherlock. :P
02:43:54 <alise_> uorygl: Note: That is actually six-operand.
02:44:10 <uorygl> I was just making my own OISC.
02:44:24 <alise_> uorygl: Now prove it touring-complete.
02:46:26 <uorygl> Anyway, how about RSSB?
02:46:58 <alise_> Quite Easily Demonstrated, I think uorygl meant.
02:47:03 <alise_> He was leaving it as an exercise to the hearer.
02:49:03 <alise_> http://www.facebook.com/group.php?gid=2410064537 o_O
02:49:04 <oerjan> i sense a slight annoyance in your phrasing
02:49:48 <alise_> Oh, no, topologists are awesome.
02:49:54 <alise_> uorygl: Oh, yeah, RSSB works.
02:50:10 <alise_> Hmm, can the two registers in RSSB be moved into memory?
02:50:28 <uorygl> I think the spec says they are.
02:50:48 <uorygl> Location 0 is IP, 1 is accumulator, 2 is always 0, 3 is input, 4 is output.
02:51:22 <uorygl> It might be better if those were locations -1 through -5, but oh well.
02:51:37 <alise_> I wonder if there are other, simpler single-operand OISCs.
02:51:46 <alise_> Reverse-subtract-and-skip-if-borrow is not the simplest semantics.
02:51:56 <alise_> Compare, e.g. subtract-and-branch-if-negative.
02:52:24 <uorygl> I'd say they're approximately equally simple.
02:53:02 <alise_> I'd just like something ridiculously simple. :-)
02:53:24 <alise_> It'd nice to have the core of the assembly code just be a list of names (defined to memory locations) and literals.
02:53:29 <alise_> (Plus sugar on top for more complex things).
03:01:42 <alise_> Sgeo_: when starting the emulator i just see
03:01:51 <alise_> on a bios-style text field
03:01:53 <Sgeo_> alise_, be patient
03:01:54 <alise_> am i meant to do something?
03:02:23 <Sgeo_> Note: If you had to restart the emulator every time you compiled an app, there would be no 3rd-party Android apps
03:02:32 <Sgeo_> *compiled and wanted to test
03:03:49 <alise_> i'm not missing much by not having sound am I :P
03:03:57 <alise_> like are there amazing WHOOSH sounds!!
03:04:12 <alise_> this thing is a bit sluggish
03:04:46 <Sgeo_> I still have yet to get sound working on the emulator to the PC, although it might be just me
03:05:21 <Sgeo_> Although maybe I simply haven't tried any apps that use sound
03:05:34 <alise_> how do you do multitasking?
03:06:11 <alise_> and why does it think i'm japanese?
03:06:29 <Sgeo_> alise_, press the Home button
03:06:33 * alise_ dials 999. let's hope this doesn't actually work
03:06:48 <alise_> is it always this sluggish?
03:06:50 <Sgeo_> Then when you go back into the app, it should be where you left off
03:07:56 -!- oerjan has quit (Quit: Good night).
03:08:16 <alise_> no but seriously why is it trying to compose kanji
03:09:31 <Sgeo_> There's some setting you can change to fix that
03:09:36 <Sgeo_> I'm not sure why it does that
03:09:54 <alise_> this interface is pretty damn polished
03:10:06 <Sgeo_> It's not quite the Nexus One interface
03:11:04 <alise_> nexus one = stock google stuff
03:11:06 <alise_> it's from google after all
03:11:25 <Sgeo_> That thing containing all the apps works differently on the Nexus One
03:11:35 <Sgeo_> The Nexus One has that pretty Live Wallpaper
03:11:48 <Sgeo_> The Nexus One has the Android Market, but that's not a UI thing
03:11:56 <alise_> pretty & battery-consuming
03:13:26 <alise_> Wow, the Droid (and the Nexus One although slightly less so) has really ridiculously high resolution.
03:13:34 <alise_> Although with the Nexus One it's PenTile so it's not reaaally the resolution.
03:13:41 <alise_> But bah, Droid sucks in other ways.
03:14:17 <pikhq> Oh how I *love* segfaults that make no sense.
03:14:35 <alise_> pikhq: Maybe you shouldn't use C.
03:14:51 <pikhq> alise_: But but lowlevel tricks and also pain and agony!
03:15:16 <pikhq> *Much* pain and agony!
03:15:28 <alise_> pikhq: Sometimes I consider using C++ and restricting myself to only using namespaces and references of the C++ features.
03:15:39 <alise_> And no pointers, or at least as few as possible.
03:17:42 <alise_> Sgeo_: Make a device with skin WVGA854.
03:17:45 <alise_> Gawp at the resolution.
03:18:02 <alise_> That's actually what Droid has. But, again, the Droid has numerous flaws; the Nexus One is far better.
03:18:06 <alise_> And the Nexus One is pretty darn close anyhoo.
03:18:24 <Sgeo_> The default is nicer for me than the real Nexus One, since I can display the whole thing without the "real size" gimmick
03:19:13 <alise_> I wonder if anyone's done a sparse array by having all arrays be of length two, and using the bitstring representation.
03:19:19 <alise_> (with a fixed size for the bitstrings)
03:19:30 <alise_> of course, that requires 5 billion dereferences for even small indices
03:20:31 <Sgeo_> alise_, anohter multitasking thing [try it with the phone]: Some apps put things in the notification area
03:20:37 <Sgeo_> That you can use to switch to them
03:20:49 <Sgeo_> Use the notification area by dragging the top bar down
03:28:20 * Sgeo_ lols at setText(getText(...))
03:29:55 <Sgeo_> Apparently, that doesn't quite work either
03:30:06 * Sgeo_ decides that the right way is too difficult
03:31:32 <Sgeo_> Actually, Eclipse makes it easy to turn the wrong way into the right way
03:31:36 <Sgeo_> It's actually very, very nice
03:31:49 <Sgeo_> Well, not Eclipse, but the Android Development Tools for Eclipse
03:34:06 <Sgeo_> ADT is really, really, really nice
03:34:19 <Sgeo_> It's more than worth dealing with Eclipse
03:37:51 <Sgeo_> My trivial app finally worked!
03:43:21 <alise_> 3:42 am; sleep soon I probably should.
03:44:55 <uorygl> I wonder whether it's actually a good idea to take out my anger on pens.
03:45:15 <uorygl> Sometimes, when I'm angry, I'll grab one and snap it in two.
03:45:28 <uorygl> I would rathest I just not be angry.
03:53:59 -!- jcp has quit (Quit: I will do anything (almost) for a new router.).
03:55:07 -!- jcp has joined.
04:02:44 <alise_> i love algorithms so much :|
04:03:34 <uorygl> Hmm, it turns out that when you snap a pen in just the right way, it will send ink flying everywhere.
04:03:40 <uorygl> Like onto our hardwood floor.
04:03:52 <uorygl> And since that's a porous surface, it now has ink stains.
04:14:29 <alise_> 4:14 am; I really should sleep soon.
04:15:18 <Sgeo_> Who owns this channel?
04:15:38 <alise_> But, uh, andreou is the founder.
04:15:47 <alise_> fizzie, lament and oerjan are the active ops.
04:15:48 <uorygl> It's owned by lament, if the portion of this sentence before the comma is true.
04:15:53 <alise_> They effectively run the place.
04:16:02 <alise_> Well, oerjan doesn't do anything; and lament just does things to troll us.
04:16:07 <alise_> And fizzie only does things with extreme hesitance.
04:16:10 <Sgeo_> Because one of them needs to kickban alise_ so e'll go to sleep
04:16:12 <alise_> So we're very close to total anarchy here.
04:16:23 <alise_> I don't need to be up at a certain time until Monday.
04:16:35 <alise_> And this is more enjoyable.
04:16:51 <alise_> Eh? Staying up late isn't going to damage my health.
04:16:52 <uorygl> I suppose health is a good reason for anything.
04:16:53 <Sgeo_> And to make it easier to wake up at that point
04:17:03 <uorygl> It does kind of seem to damage health.
04:17:16 <alise_> I have a rather nasty infection, not a huge requirement for sleep.
04:17:24 <alise_> uorygl: It makes me dumber, sure, and it makes me more tired if I don't sleep enough.
04:17:31 <alise_> But I'm happy enough right now, and I'll sleep in.
04:20:57 <Sgeo_> #ZodiacFacts The stars that make up the constellation #Taurus are, for the most part, undergoing nuclear fusion.
04:21:16 <alise_> That's ... nice to know.
04:21:34 <Sgeo_> At least it's accurate, unlike most of the stuff in #ZodiacFacts
04:21:41 <Sgeo_> BadAstronomer's are funnier though
04:22:38 -!- mycroftiv has quit (Read error: Operation timed out).
05:01:21 -!- alise_ has quit (Remote host closed the connection).
05:06:24 -!- mycroftiv has joined.
05:13:55 -!- Oranjer has left (?).
05:15:00 -!- Alex3012_ has joined.
05:16:42 -!- Alex3012 has quit (Ping timeout: 265 seconds).
05:16:50 -!- Alex3012_ has changed nick to Alex3012.
07:30:55 -!- lament has joined.
07:53:33 -!- lament has quit (Quit: lament).
07:57:13 -!- coppro has quit (Ping timeout: 276 seconds).
07:58:22 -!- coppro has joined.
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
08:45:04 -!- kar8nga has joined.
08:52:32 -!- augur has quit (Remote host closed the connection).
08:52:40 -!- augur has joined.
09:28:16 -!- augur has quit (Remote host closed the connection).
09:28:21 -!- augur has joined.
10:12:36 -!- tombom has joined.
10:46:45 -!- MigoMipo has joined.
10:53:04 -!- FireFly has joined.
11:22:14 -!- oerjan has joined.
11:28:20 <oerjan> <uorygl> Hmm, it turns out that when you snap a pen in just the right way, it will send ink flying everywhere.
11:28:30 <oerjan> i guess that answer your previous question, then
12:09:01 -!- kar8nga has quit (Remote host closed the connection).
12:17:15 -!- BeholdMyGlory has joined.
12:18:41 -!- Alex3012_ has joined.
12:22:10 -!- Alex3012 has quit (Ping timeout: 245 seconds).
12:22:15 -!- Alex3012_ has changed nick to Alex3012.
12:24:14 -!- oerjan has quit (Quit: leaving).
12:37:08 -!- ENKI-][ has quit (Ping timeout: 276 seconds).
12:43:24 -!- tombom has quit (Quit: Leaving).
12:44:51 <AnMaster> <oerjan> i guess that answer your previous question, then <-- what was that question?
13:06:12 -!- ENKI-][ has joined.
13:17:58 -!- Asztal has joined.
13:38:40 -!- kar8nga has joined.
13:44:34 -!- BeholdMyGlory has quit (Remote host closed the connection).
13:45:37 -!- mycroftiv has quit (Ping timeout: 240 seconds).
13:48:04 -!- alise has joined.
13:55:16 <alise> An illegality of jazz.
14:04:01 <alise> http://retroforth.org/ Are the Forthers trying to be post-hip-modernist-minimalist?
14:04:39 <alise> What, they've implemented their VM in Javascript.
14:05:20 <alise> http://retroforth.org/demos/demos/listener/index.html
14:07:07 <alise> In RSSB, does the subtraction /have/ to be reverse?
14:07:16 <alise> Or would SSB work fine?
14:09:19 <alise> Hmm, and http://esolangs.org/wiki/TOGA_computer's using of bits is interesting.
14:09:45 <alise> I wonder if TSZ (toggle and skip next instruction if result is 0) would be TC?
14:10:23 -!- mycroftiv has joined.
14:13:04 -!- mycroftiv has quit (Read error: Operation timed out).
14:16:01 <alise> Of course a toggle-style instruction set makes IO harder.
14:25:00 <alise> I wish http://eigenratios.blogspot.com/ still posted.
14:26:32 <alise> ok, [[User:Oleg]] is mazonka.com
14:34:11 <alise> "8. Why in the mirror the left swaps with the right, but the top does not swap with the bottom?"
14:34:13 <alise> "# 8. This is very difficult question. I do not know its answer."
14:34:19 <alise> --Oleg Mazonka on his "mathematical puzzles" page
14:36:09 <alise> It's obviously a joke.
14:36:28 <alise> (The simple answer, of course, is that mirrors rotate in the fourth dimension.*)
14:36:31 <alise> *I find this fact extremely awesome
14:38:15 <alise> I mean, obviously they don't literally pop into the fourth dimension for some rotating action... but that's the transformation they do to what you see.
14:39:09 <alise> So, I'm still trying to figure out a simpler one-operand OISC than RSSB.
14:41:15 <alise> Hmm, I feel like making a fast Brainfuck interpreter. Like a snack, only programming.
14:43:49 <alise> Gregor: Do you know if malloc( sizeof somestruct - sizeof int ) is valid, where the last member of somestruct is an int?
14:44:07 -!- kar8nga has quit (Read error: Connection reset by peer).
14:45:04 <Gregor> alise: Depends on your definition of "valid" and the particulars of the system. It won't give wonky results unless the only member is an int. In most but not all cases the int will be inaccessible of course.
14:45:43 <alise> Right; I was just checking it wasn't U.B.
14:45:46 <alise> Not that I care much.
14:46:16 <alise> Gregor: And I'm gonna go out on a limb here and guess that putting computed goto &&pointers into a static array for use later, when the function has been exited and re-entered, is not such a guaranteed-to-work idea.
14:46:20 <alise> Undefined behaviour.
14:46:36 <alise> Actually this is irritating, since computed gotos are just right for what I want.
14:46:47 <alise> A switch with defined values will likely be faster than dereferencing the goto pointer, won't it?
14:46:52 <Gregor> Actually that has perfectly well-defined semantics and people (including me) use it all the time.
14:46:59 <alise> I was going to use this:
14:47:01 <Gregor> alise: Could go either way.
14:47:01 <alise> void *kind; /* computed-goto pointer to a blueprint */
14:47:04 <alise> for a BF instruction
14:47:08 <alise> and have kind be one of the elements of this:
14:47:11 <alise> static void *blueprints[6]; /* move, change, output, input, [, ] */
14:47:20 <alise> but it'll be quicker just to switch over a char, won't it?
14:47:23 <alise> since the range is predefined
14:47:28 <alise> and it doesn't involve dereferencing a pointer
14:47:29 <Gregor> It could be, but not likely.
14:48:14 <alise> So the computed goto is better?
14:48:22 <Gregor> Probably, but not always :P
14:48:42 <Gregor> That's called a threaded interpreter. Look it up. And don't get confused with the meaning of "threading" that real people use.
14:49:09 <alise> Yeah, I know that.
14:49:12 <alise> I've read JonesForth, you know. :P
14:49:20 <alise> I was just thinking that in this case the number of instructions is very small.
14:49:23 <alise> void interp(char setup) {
14:49:23 <alise> blueprints = {&&move, &&change, &&output, &&input, &&loop, &&next};
14:49:23 <alise> if (setup) return;
14:50:05 <alise> #define MOVE blueprints[0]
14:50:06 <alise> #define CHANGE blueprints[1]
14:50:10 <Gregor> You're still going to have while (1) { switch (foo) { a: break; b: break; c: break; } }
14:50:26 <Gregor> I mean if you use a switch and not computed gotos.
14:50:44 <alise> Hmm, I wonder which is better:
14:51:02 <alise> while (1) { goto *ins->kind; foo: ...; continue; bar: ...; continue; ... }
14:51:20 <alise> LOOP: goto *ins->kind; next ins
14:51:23 <alise> foo: ...; goto LOOP;
14:51:26 <alise> bar: ...; goto LOOP;
14:51:31 <alise> I guess they will be compiled into much the same code.
14:51:39 <Gregor> Probably. Both are pretty awful :P
14:52:04 <alise> Gregor: Got any better suggestions?
14:52:18 <Gregor> #define NEXT ins++; goto *ins->kind;
14:52:25 <Gregor> Then put NEXT at the end of every instruction.
14:52:36 <alise> I really should re-read JonesForth.
14:52:41 * alise renames the NEXT instruction to avoid clashing
14:54:23 <alise> Hmm, if I want to beat http://mozaika.com.au/oleg/brainf/bff4.c fairly, I need a dynamically-allocated tape.
14:54:29 <alise> Eh, I'll do that later.
14:55:23 <AnMaster> Gregor, you mean he doesn't know this?
14:55:38 <alise> Just because I haven't written a threaded interpreter in a while...
14:55:52 <alise> I left C and ages for months to mess around with mathematical languages.
14:56:00 <Gregor> Whereas I've been TAing a class in which half the class are writing them :P
14:56:14 <alise> Gregor: He won't get the context; he has me on ignore.
14:56:19 <Gregor> AnMaster: Teaching Assistant
14:56:21 <alise> It's not like many people outside of Forth write threaded interps in practice anyhow.
14:56:35 <Gregor> alise: That's not true at all.
14:56:47 <alise> Well, okay, but it certainly isn't the most common method of implementation.
14:56:49 <Gregor> alise: Most half-decent bytecode interpreters are threaded nowadays.
14:56:57 <alise> Python wasn't until recently.
14:56:57 <Gregor> alise: (Before JITing of course)
14:57:05 <alise> Then again, GvR is a retard.
14:57:11 <Gregor> alise: Nowadays = this year, basically, it's all the rage :P
14:57:31 <AnMaster> <Gregor> alise: Most half-decent bytecode interpreters are threaded nowadays. <-- yes, I'm surprised if he didn't know that...
14:57:44 <alise> input: if ((c = getchar()) == EOF) *tape = 0; else *tape = c;
14:57:45 <alise> input: if ((*tape = getchar()) == EOF) *tape = 0;
14:57:48 <alise> is more micro-efficient
14:57:50 <alise> I suspect the latter
14:57:51 <Gregor> Being the intermediary in a half-blocked conversation is amusing :P
14:57:52 <alise> since EOF is an edge-case
14:58:12 <Gregor> alise: I would guess the latter as well.
14:58:17 <alise> Gregor: I like how you're mostly half-agreeing with me when I clarify things and AnMaster thinks him and you are dissing me into Retard Hell :P
14:59:07 <alise> I think I'm finally managing to think like AnMaster. "Hey, I have a lot of ->s in this code. I could pre-dereference the struct beforehand..."
15:01:04 * alise realises he has a potential "goto NULL" situation
15:01:10 <alise> No problem; one more blueprint entry for STOP.
15:01:14 <alise> The most famous of all brainfuck instructions.
15:01:19 <Gregor> The program will definitely exit :P
15:01:28 <alise> But it also stops!
15:02:42 <AnMaster> Gregor, any new music recently?
15:03:07 <alise> I wonder if gcc will be happy with a 10485760-length static array.
15:03:08 <Gregor> AnMaster: No, I'm currently in wrist splints for carpal tunnel :(
15:03:15 <alise> For all those ten-megabyte brainfuck programs.
15:03:25 <alise> gcc usually has an internal error when you allocate a static array big enough.
15:03:29 -!- mycroftiv has joined.
15:04:18 <alise> I think I've realised that most of my C coding is designed around avoiding to have to use malloc at all.
15:04:22 <alise> Or, especially realloc.
15:05:17 <alise> op ip[5242880]; /* do not make a program longer than five megabytes i will be sad */
15:05:22 <alise> Truer words have never been spoken.
15:05:37 <Gregor> alise: Use my buffer.h :P
15:06:05 <alise> If it does anything to slow down the main interpreter loop, no way :P
15:06:21 <Gregor> http://codu.org/projects/stuff/hg/index.cgi/file/tip/buffer.h
15:06:27 <Gregor> You would just use it to easily load in the file.
15:06:38 <alise> Not expanding the tape?
15:06:45 <alise> char tape[65536] = {0}; /* I wonder if I should just rely on this working */
15:06:47 <Gregor> Oh, you could do that too if you wanted to use it for the tape.
15:06:57 <Gregor> But you'd have to do bounds-checking for that.
15:06:59 <alise> Gregor: Hmm, not for the tape; too much overhead.
15:07:03 <Gregor> I was just thinking loading in files :P
15:07:13 <alise> I was just going to embed the program source at first...
15:07:22 <alise> This is just bf1.c, there is plenty of time for polish in bf137 :P
15:07:23 <Gregor> INIT_BUFFER(buf); fopen etc; READ_FILE_BUFFER(buf, filehandle); /* hooray */
15:07:29 <AnMaster> Gregor, idea: use stat() to figure out in advance how large that buffer needs to be
15:07:45 <Gregor> AnMaster: That would be a sensible thing for me to do >_>
15:07:58 <AnMaster> Gregor, yeah, is that a bad thing?
15:08:20 <Gregor> AnMaster: Except that buffer.h works on "all" C systems, not just Unix. IIRC there's no very good stdio equivalent, but maybe I just don't recall it.
15:08:38 <AnMaster> Gregor, well true, so do #ifdef PURE_C or some such
15:08:49 <Gregor> alise: It would just be for guessing the initial buffer size.
15:08:57 <alise> It turns out that intensive use of #ifdefs is not the way to write correct code.
15:08:57 <Gregor> alise: Just preallocation.
15:09:10 <alise> Unless you like reading half a page of preprocessor directives for every actual meaty line of code.
15:09:23 <alise> Gregor: consider trigging pathological behaviour by making a 0-length file then immediately overwriting it with a 5gb one
15:09:28 <AnMaster> it would certainly readuce reallocation, and also mean you would know at initial allocation if you had enough memory
15:09:49 <AnMaster> Gregor, why macros and not inline functions?
15:10:25 <alise> You can rely on a macro being inlined perfectly.
15:10:31 <alise> Also, you don't need to write a separate .c file.
15:10:40 <AnMaster> Gregor, or do you with "all C" mean C90 too? Not just C99?
15:11:03 <Gregor> AnMaster: I mean I can compile it for 16-bit DOS with outdated Watcom compilers :P
15:11:33 <AnMaster> Gregor, still some #ifdef to for *nix might be a good idea
15:11:43 <Gregor> alise: Your pathological behavior is an edge case that could be detected. a 1-length file would be a nonissue.
15:12:13 <alise> Gregor: Fair enough.
15:12:48 <alise> Also, I'd just like to throw out a strong vote against #ifdef fuckery. If you really want uber-ridiculous-speed, make them actual separate .c files compiled differently depending on the OS (in e.g. your build system)
15:13:02 <alise> #include "ricer_speed_buf.h"
15:13:06 <alise> #include "i_am_sane.h"
15:13:20 <Gregor> I haven't changed buffer.h in significant ways (except for adding totally new macros) basically since its inception :P
15:13:32 <AnMaster> I once met a programmer who didn't know you could put function bodies in headers... After all it is just included. static inline in a header works fine.
15:13:48 <Gregor> AnMaster: So long as your compiler supports static ;)
15:14:05 <alise> You know, sometimes there is a good reason for .h and .c to be separate.
15:14:26 -!- mycroftiv has quit (Ping timeout: 276 seconds).
15:14:34 <Gregor> You can always #define inline away, but if you #define static away you'll get multiply-defined errors.
15:14:45 <alise> op *stk[65536]; /* also if you use more than 65536 nested loops i will be sad too */
15:14:54 <alise> AnMaster: consider separate compilation.
15:14:59 <Gregor> AnMaster: That's ... the whole idea of static X_X
15:15:01 <alise> multiple definitions in separate objects
15:15:07 <alise> WOW ANMASTER DIDN'T KNOW THAT?
15:15:10 <alise> MUST BE PRETTY DUMB HUH
15:15:19 <AnMaster> Gregor, but it will work on some platforms anyway iirc
15:15:26 <Gregor> AnMaster: Sure, depends on the linker.
15:15:29 <AnMaster> Gregor, anyway I don't know of a compiler that lacks static
15:15:36 <alise> char tape[65536] = {0}; <-- Please tell me that some compiler, somewhere, supports this :-)
15:15:42 <Gregor> AnMaster: I'll go dig up a pre-ANSI one for PDP-11 ;)
15:15:52 <AnMaster> Gregor, I don't care about pre-ANSI
15:16:51 <AnMaster> static for file-local is rather strange btw
15:17:32 <Gregor> AnMaster: C's use of "static" is a bit schizophrenic :P
15:17:46 <alise> Gregor: also I'm not sure buffer would work so well as I want to "compile"/parse as I go
15:17:50 <alise> maybe I should read just a bit at a time
15:17:53 <alise> or maybe not, maybe this is better
15:17:55 <AnMaster> Gregor, it makes a whole lot of sense for the "persists between calls
15:18:13 <alise> That's the most confusing sense
15:18:19 <AnMaster> possibly they were out of keywords and didn't want to mess up with anyone who had a variable called "local"
15:18:19 <Gregor> alise: Up to you, I've just found I always like my buffers :P
15:18:42 <alise> Gregor: Well if I were optimising for happiness and laughter I would use some language other than C but I'm going for mega performancebucks here :P
15:21:08 <alise> with intptr_t -- which I've never used before; I'm a radical kind of freewheeling fellow as far as integers and pointers go -- do you need to cast when assigning pointers to it, or when assigning integers?
15:21:48 <alise> Right, well, clearly you know best; bye-bye intptr_t.
15:23:27 <alise> Gregor: Hmm, I'm not sure doing what I said I'd do -- and what you said would work -- with computed gotos /will/ work.
15:23:32 <alise> I just have to preinitialise the array
15:24:12 <alise> er, or rather, just not assign it as a literal
15:27:08 -!- mycroftiv has joined.
15:27:12 <alise> bf1.c:41: warning: cast from pointer to integer of different size
15:27:13 <alise> bf1.c:42: warning: cast from pointer to integer of different size
15:28:30 <alise> $ echo abc | ./bf1
15:28:47 <alise> it appears to read one character in, then exit
15:28:53 <pineapple> 15:15:12 <alise> char tape[65536] = {0}; <-- Please tell me that some compiler, somewhere, supports this :-)
15:29:24 <alise> yeah, i know it does work
15:29:29 <alise> but still, it's such a weird feature
15:29:44 <pineapple> i _think_ that arrays are 0-inited by default, if specified outside of a fucntion
15:29:54 <alise> yeah i think so too
15:30:01 <pineapple> so char tape[65536]; should do it as well
15:30:15 <alise> yeah, i just get twitches whenever i see a decl without initialiser in c
15:30:18 <alise> for obvious reasons
15:30:18 <pineapple> it's only if you have to malloc() the array that it's random
15:30:34 <Gregor> On MOST systems arrays outside a function are in BSS, but that's NOT guaranteed by C.
15:30:47 <alise> fuck yeah, standards fight
15:31:02 <pineapple> Gregor: i'm going by memory of K&R
15:31:43 <Gregor> I'm going by memory of your FACE.
15:32:06 <pineapple> sorry honey, i don't recognise you
15:32:08 <AnMaster> Gregor, static ones are going to be zero at start
15:32:21 <AnMaster> not sure about non-static ones
15:32:48 <alise> your MOM are going to be zero at start
15:33:03 * alise declares a bunch of stuff static for moar speed
15:33:11 <alise> moar speed in my broken program
15:33:35 <alise> move: tape += (int)p.val; NEXT;
15:33:35 <alise> change: *tape += (int)p.val; NEXT;
15:33:36 <alise> output: putchar(*tape); NEXT;
15:33:36 <alise> input: if ((*tape = getchar()) == EOF) *tape = 0;
15:33:36 <alise> loop: if (!*tape) ip = p.val;
15:33:36 <alise> end: if (*tape) ip = p.val;
15:34:03 <alise> sweet, EOF generates a segfault
15:34:13 <alise> even normal progam termination does
15:34:19 <alise> I forgot to add the stop instruction
15:34:44 * alise tries mandelbrot.b
15:35:42 <pineapple> 15:03:54 <alise> I think I've realised that most of my C coding is designed around avoiding to have to use malloc at all. - any reason why?
15:35:52 <alise> pineapple: Well, malloc's not so bad.
15:35:55 <alise> But realloc is tedium personified
15:36:17 <alise> (and I'm not just some shitty PHP coder who doesn't "get" C -- I've used lower level languages than it, and loved C for ages, and I've used languages all the way up the spectrum too)
15:36:24 <pineapple> shouldn't it be unsigned char for bf?
15:36:36 <alise> Doesn't make any difference, does it?
15:36:54 <pineapple> i think it does for integer wraparound
15:38:09 <olsner> if you write C, signed-integer overflow is undefined :)
15:38:42 <alise> Hey, mandelbrot.b works.
15:38:51 <alise> I only made one mistake in writing the entire program.
15:39:31 <alise> Slowly, mind, but not nearly as slowly as you'd expect from a relatively naive first draft.
15:40:28 <alise> $ time ./bf1 > /dev/null
15:40:53 <alise> So, I need to make "parsing" smarter -- combine moves and modifies.
15:41:18 <alise> Then I need to shift moves and the like into the other instructions.
15:41:25 <alise> Then I need to do linear-loop optimisation.
15:41:41 <alise> #include "mandelbrot.h"
15:42:18 <olsner> and implement reading a program from file perhaps?
15:50:47 * alise benchmarks bf1 vs bf2
15:50:58 <alise> I imagine around bf10 might be faster than bff4 with linear loop optimisation
15:51:07 <alise> incremental development is a blast
15:52:09 -!- cheater3 has joined.
15:53:09 <alise> Hmm, I do wonder if indexing into my static tape array with an integer might not help the compiler figure out more than using just an opaque pointer.
15:53:17 <alise> $ ./bf1 > /dev/null; time ./bf1 >/dev/null; ./bf2 >/dev/null; time ./bf2 >/dev/null
15:53:23 <alise> Only change was combining multiple <>, +- instructions.
15:53:31 <alise> Low hanging fruit right there.
15:53:37 <alise> (Well, and I changed the type to int, not void *.)
15:53:43 <alise> (It should probably be long.)
15:55:08 <alise> Changing to long only varies mandelbrot.b's time from 20.209s to 20.635s
15:55:25 -!- cheater2 has quit (Ping timeout: 260 seconds).
15:56:02 <alise> eh, don't have the 32 libs
15:58:09 <alise> Daniel B. Cristofani's self-interpreter is so amazing.
15:58:12 <alise> Hey, changing to a tape index shortened the time to 18.194s.
16:01:12 <alise> Speeding this thing up is... rather ridiculously easy.
16:01:44 <alise> Oh, dear; bf4 slowed things down.
16:03:25 <alise> Down to 17.969s; I'm almost as fast as bff.c on mandelbrot.
16:03:43 <alise> And only 101 lines, too -- though I need to add program loading, and possibly variable tape allocation.
16:05:48 <alise> Strangely enough, not pre-dereferencing ip speeds it up a little bit (<1s, but still).
16:05:59 <alise> (<.5s, too, but it's still definitely not a coincidence giving time's results)
16:06:18 <alise> It's now only 99 lines.
16:09:41 * Sgeo_ growls at everyone who uses non-domain-name-based package names
16:09:44 <alise> I guess I'll bite the bullet. bf6 will be the one that does the first combining of move operations into other instructions. I think.
16:10:45 <alise> ++++>+<[>[>+>++<<-]>>[<<[>+<-]>[<++>-]>-]<<<-]>[<+>-]< ;; bf program to calculate 2^(2058 + 2^4116)
16:11:45 <alise> source: http://www.iwriteiam.nl/D9901.html#24
16:11:55 <alise> even bigger? http://www.iwriteiam.nl/D0904.html#15
16:12:03 <alise> if you add +s to the start of that program you get something even bigger
16:12:31 <alise> 2^(2058 + 2^4116) has 10^1239 digits in base 10
16:13:00 <alise> or, in other words,
16:13:06 <alise> it has 100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
16:13:06 <alise> 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
16:13:06 <alise> 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 base-10 digits
16:13:52 <alise> So what we've learned here is with that with the BF kolgomorov complexity K(x):
16:14:09 <alise> K(2^(2058 + 2^4116)) <= 54
16:14:12 <alise> It is a rather simple integer.
16:16:45 * alise considers folding in moves by having an int that gets inc/dec on move instructions, then putting it in any newly created instruction
16:21:44 <alise> Oh dear; it seems like bf6, with its move-folding, is going slower than bf5.
16:22:21 -!- adam_d has joined.
16:22:32 <alise> I guess what I really need to do is handle >^nX<^n (also swapping >/<) for all n.
16:22:47 <Ilari> I think your number of digits is off by factor of about 3... :->
16:23:05 <alise> Ilari: Quite possibly.
16:23:16 <alise> I just asked Wolfram Alpha then pasted the result into Ruby (nearest thing to hand), then copy-pasted the result.
16:23:27 <alise> The potential for error at any point is large.
16:23:57 <alise> Oh, look: bf6 does not even work.
16:23:57 <alise> I'd better fix it.
16:25:18 * Sgeo_ wonders how playable the JS version of Robozzle is
16:26:00 <Ilari> I get (rounding off a bit): 3.296643047157257677279598742963425708214531905272149037702927150038*10^1238 base 10 digits.
16:26:59 <alise> Maybe I rounded a .5 down, rather than up, in the log result.
16:27:30 <alise> Grr; this really should work.
16:30:48 <Ilari> That was rounded from result I got (to avoid pasting 1239 digit number to IRC).
16:32:35 <alise> Is it using floats?
16:33:09 <Ilari> Fixed point (at scale of 10^1500).
16:34:21 <alise> Clearly what we /really/ need is someone to evaluate it symbolically.
16:34:40 -!- adam_d has quit (Ping timeout: 245 seconds).
16:35:03 <alise> Well, it's /approximately/ 10^1238.518071925292.
16:35:07 <alise> But that is not very helpful.
16:35:31 -!- adam_d has joined.
16:36:11 <Ilari> 1 + floor((2058 + 2^4116)*log(2)/log(10))
16:36:19 <Sgeo_> It's amazing how star placement can make a puzzle easier or harder, just by leading you in the right or wrong direction to approach the puzzle
16:36:41 <Sgeo_> [ignoring placement that changes the puzzle itself, ofc]
16:37:35 <alise> Ilari: Well, that is just cheating.
16:37:58 <alise> Anyone have axiom? Or Octave?
16:40:03 * Ilari is installing octave and axiom... Takes a while to download ~130MB...
16:40:31 <alise> Octave isn't symbolic, I don't think, but a lot of people use it.
16:40:35 <alise> I'm downloading Maxima.
16:40:40 <fizzie> Octave doesn't do much else than double-precision floats. It's an engineer thing.
16:40:52 <alise> Alright then; skip Octave.
16:41:03 <alise> It is of the utmost importance that we get an exact answer to this question!
16:42:31 * Sgeo_ goes to try /* Comments */
16:42:46 <Sgeo_> alise, isn't Maxima costly?
16:43:56 <alise> Are you thinking of Mathematica?
16:44:00 <alise> I have Mathematica somewhere. I pirated it.
16:44:17 * Sgeo_ was thinking of Mathematica, yes >.>
16:45:47 * Sgeo_ drools at http://www.youtube.com/watch?v=SnWJ29eNCbY
16:46:33 <Sgeo_> "purchasing of puzzle solutions"? WTF?
16:52:42 <alise> grr, why the hell doesn't this work
16:58:05 <alise> It's behaving differently for... no reason whatsoever.
17:06:15 <alise> Ilari: Any luck with axiom?
17:08:51 * Sgeo_ wonders if it's possible to make an iPhone emulator for Android
17:10:06 <alise> Ilari: I've got the precise result.
17:11:45 <alise> Ilari: http://pastie.org/924690.txt?key=ofuqp78ktc37x7uktmhuuw
17:12:09 <alise> But ++++>+<[>[>+>++<<-]>>[<<[>+<-]>[<++>-]>-]<<<-]>[<+>-]< doesn't even calculate the number shown there; it calculates a number with that many digits.
17:12:13 <alise> 2^(2058 + 2^4116); what a number.
17:13:45 <Ilari> Looks like that number matches to what I calculated...
17:14:18 <alise> I just kept prompting Wolfram Alpha for more digits. :-)
17:14:22 <Ilari> What would adding fifth '+' in beginning do to number it calculates? How large it would then be?
17:15:44 <alise> The author didn't specify: just that it was much larger.
17:15:56 <alise> You could probably work it out by figuring out what formula it's running, and treating the initial +s as parameters.
17:16:11 <alise> http://www.iwriteiam.nl/Ha_bf_numb.html has links to the blogposts; the 1999 one is the one we're talking about.
17:20:22 * alise is absolutely determined to beat mazonka's interp...
17:20:28 <alise> why isn't my move-combining working!
17:23:38 -!- lament has joined.
17:24:45 <alise> successive iterations of a relatively naive BF interpreter with a new idea of sorts, aiming to beat the current champion (mazonka's bff4.c with linear loop optimisation)
17:24:49 <alise> or this specific bit?
17:25:05 <alise> I'm trying to eliminate the Move instruction by e.g. turning >><+ into a + instruction with the field move = 1
17:25:26 <alise> but either the bit that does this combining or the actual interpreter loop's handling of these values is meaning that the tape pointer is being moved in an entirely incorrect way
17:25:31 <alise> and i can't figure out why
17:25:56 <AnMaster> * Sgeo_ growls at everyone who uses non-domain-name-based package names <-- for what?
17:26:36 <alise> to be general, java
17:27:52 <pineapple> alise: maybe you have move and the +/- the wrng way around
17:28:02 <alise> case '>': mov++; break;
17:28:02 <alise> case '<': mov--; break;
17:28:05 <alise> #define NEXT ip++; tp += ip->mov; goto *ip->kind
17:28:53 <pineapple> the difference btween prefix and postfix ++ is why you;re getting errors
17:29:58 <alise> #define NEXT ip++; tp += ip->mov; goto *ip->kind
17:30:01 <alise> is the bit that actually does the moving
17:30:16 <alise> and since i merge the mov modified in the past loop into the instruction done now, the moves come before the instruction
17:30:20 <alise> ip->kind is what actually executes it
17:30:24 <alise> so clearly the move is in the right place
17:32:12 <pineapple> so... ip.mov is how much to move by, and ip.kind is how much to +/- by once you're tehre?
17:32:45 <alise> there is the issue
17:32:51 <alise> if (last && last->kind == Change) {
17:32:52 <alise> last->val += c == '+' ? 1 : -1;
17:32:55 <alise> a relic from when i always did p++
17:33:01 <alise> but now I have it as a separate macro
17:33:05 <alise> so that p-- keeps running backwards
17:33:08 <alise> one step forwards, two back
17:33:24 <alise> pineapple: ip->kind is a pointer to a computed goto label, that contains the relevant code for the instruction that it is
17:33:54 <alise> jane@jane-desktop:~/code/bf$ gcc -std=gnu99 -O3 bf6.c -o bf6
17:33:54 <alise> jane@jane-desktop:~/code/bf$ ./bf6
17:33:54 <alise> Segmentation fault
17:33:58 <alise> Well, that is an improvement.
17:34:07 <alise> (re: use name - not my computer)
17:34:12 <alise> (haven't unpacked mine yet :P)
17:34:56 <alise> well i have it back to sitting there doing nothing useful now...
17:34:58 <alise> turns out that wasn't my bug
17:35:25 <alise> nope ... not that either
17:35:39 <alise> if (last && last->kind == Change) {
17:35:40 <alise> p->val += c == '+' ? 1 : -1;
17:35:40 <alise> p->val = c == '+' ? 1 : -1;
17:35:47 <alise> adv advances the ip in the parser, and also sets the mov
17:35:56 <alise> and when the last instruction was a change
17:35:58 <alise> we just add to the value
17:36:01 <alise> but then ADV OVERWRITES IT
17:36:31 <alise> now it... still doesn't work!
17:36:38 <alise> but I'll get there eventually i'm sure
17:37:29 <fizzie> alise: Without seeing the code it's obviously guesswork, and I wouldn't feel like looking anyway, but... I guess you 0 mov at all the right places? Have you tried dumping the code you create?
17:38:05 <alise> Dumping the created code I should probably do.
17:38:05 <alise> #define ADV p->mov += mov; mov = 0; last = p; p++; p->mov = 0
17:38:06 <alise> and the place that, I think might be causing "trickiness":
17:38:07 <alise> if (last && last->kind == Change) {
17:38:08 <alise> p->val += c == '+' ? 1 : -1;
17:38:08 <alise> p->val = c == '+' ? 1 : -1;
17:38:17 <alise> with the p-- and the need to combine movs and the like
17:39:52 <alise> apart from that it's just boring set-kind-advance
17:39:57 <fizzie> Yes, should the p--; p->val += ... part also do something to p->move? I guess not necessarily, since you'll add the current "mov" anyway... or is that in p->mov before p-- at that point? Ah well, I don't quite know your logicks.
17:39:58 <alise> loops[--lp]->val = (long)p;
17:39:58 <alise> p->val = (long)loops[lp];
17:40:01 <alise> but i don't think that should make a difference
17:40:20 <alise> fizzie: Well, p-- makes p = what last was before.
17:40:26 <alise> ADV, later on, expands to adding mov to p->mov.
17:40:30 <alise> So we should add it anyway, I think.
17:40:39 <alise> fizzie: Imagine >+>+
17:40:43 <alise> We get + with mov=1
17:40:47 <alise> we increase mov, mov=1
17:40:50 <alise> since the last instruction was +
17:40:53 <alise> + with amount=2 mov=2
17:40:55 <alise> this is clearly incorrect
17:41:10 <alise> we need to stipulate that our current mov is 0, or we cannot combine Changes
17:42:40 <pineapple> this would be so much easier if i could see your code
17:43:26 <alise> pineapple: i was considering pasting it, but, you know, too busy tweaking random things and seeing if they work
17:44:19 <fizzie> I had an attitude like that with ff3 the other day, but then people pestered me too much about it. Should add that border-tracking there.
17:45:08 <alise> Is ff3 becoming Funge-98 then?
17:45:36 <alise> So, I now have a 93-line program that runs mandelbrot.b in 15.581s.
17:45:48 <alise> Admittedly, it has a fixed size tape, no bounds checking (but that's okay), and doesn't load in the program from a file yet.
17:45:52 <alise> But it's only the sixth revision.
17:46:05 <alise> bf5: 0m17.648s; bf6: 0m15.581s
17:46:12 <alise> bf1 took ~40s on mandelbrot.b
17:46:21 <fizzie> alise: No, I just want less useless nops in the wrapping: http://pastebin.com/00xjESHr
17:46:55 <alise> Say; there isn't any Brainfuck benchmark.
17:47:25 <fizzie> I don't know of any, which is a shame, because with the ^bf thing that'd work as a rudimentary Befunge benchmark too.
17:48:10 <alise> How about calculating A(3, 20)?
17:48:19 <alise> 8,388,605 is big but not too unwieldy to manipulate with brainfuck.
17:48:42 <alise> Of course, that would be most useful with already-fast interpreters.
17:49:37 <alise> And then perhaps outputting the result in base-10.
17:50:06 <alise> http://mozaika.com.au/oleg/brainf/ ;; some "sort of benchmark" programs
17:51:24 <Ilari> Hmm... Wonder where I calculated wrong: I got that "output" of that big number BF program would be 2^(2058 + 2^2059)...
17:52:58 <alise> Maybe he got it wrong.
17:53:53 <alise> bf6 takes 34.845s to run long.b; not so good.
17:56:43 <alise> Ilari: http://www.iwriteiam.nl/Ha_bf_numb.html#lbl
17:56:46 <alise> http://www.iwriteiam.nl/Ha_bf_numb.html
17:56:49 <alise> explains the algorithm behind the program
17:57:27 <alise> 0m31.911s to run si ! si ! hi123; not very fast
17:57:49 <alise> I think I'll merge +-s into the surrounding instructions, and then perhaps think about optimising >>x<<, and then do linear loops
17:59:53 <alise> I can't just have the variables mov and chg, because then I can't distinguish +> and >+.
18:01:20 <Ilari> Anyway, for 5 +'s, I get that number would be bigger than 2^2^2^2059.
18:01:29 <alise> pineapple: ackermann function
18:01:41 <alise> http://en.wikipedia.org/wiki/Ackermann_function
18:01:48 <alise> you know, grows extremely quickly
18:01:55 <alise> computable but not primitive recursive -- the first such function found
18:02:23 <alise> A(4,4) = 2^(2^(2^65536)) - 3
18:02:54 <alise> A(3,20) is the more manageable 8,388,605
18:03:00 <alise> but it'll still take a while to compute...
18:04:19 <Sgeo_> Seems easy to express in Haskell
18:04:28 <Sgeo_> Although the trivial way is probably not efficient
18:04:39 * alise wonders what the big-O of ackermann is
18:04:57 <alise> Sgeo_: Efficient doesn't matter; beyond very small values you can't fit the result into the universe, or indeed any nearby universes, anyway
18:06:02 <Sgeo_> For A(20, 20), the result is simply A(20, 20)
18:06:42 <Ilari> Isn't ackerman function fairly easily describable in terms of hyper function?
18:07:13 <alise> Hyper function isn't primitive recursive either.
18:07:21 <alise> Sgeo_: That is not the result, that is a symbolic representation of the result.
18:07:28 <alise> "... Solve for n." "n = n"
18:07:52 <alise> The /result/ has to be some primitive notion: what it actually returns, such that it cannot be reduced further.
18:10:45 <fizzie> Hrm, this is awfully confusing results: http://pastebin.com/KrSjfAgS
18:11:41 <fizzie> AnMaster: Yes, because of the last number.
18:12:45 <Ilari> What's the length of BF program that loads first cell with number at least g64 and leaves the rest zero?
18:12:54 <fizzie> The difference between -DPF_X=15 -DPF_Y=1 and -DBOUNDARY_TRACKING for the actual time-wasting loop part in benchmark.bef is that for -DPF_X=15, in the wrapping instruction -- ip += PF_DELTA(0, -pf_box_w, 0); IP_GOTO; -- pf_box_w is a compile-time constant, whereas for -DBOUNDARY_TRACKING it's a file-scope "static int pf_box_w".
18:13:09 <fizzie> You wouldn't normally assume a compile-time constant be slower to subtract than a variable value.
18:17:30 <AnMaster> fizzie, run more timings and see if they agree
18:18:14 <fizzie> I ran the benchmark a couple of times, and it seems to be constantly close to those numbers. The actual moving of boundaries on 'p' isn't done yet, so I can't run anything very complicated.
18:19:15 <fizzie> I've been sick, man! Or possibly just "sick man". Getting better now, though; will see if I get some jitfungey done tomorrow. There's that bug I was chasing still there.
18:20:02 <AnMaster> fizzie, where can I svn/bzr/hg/darcs/cvs it from?
18:20:45 <alise> I like this style of development. Write a really stupid program with 1 appended to its name, then copy it, increment the number and improve on it. Only advance to a higher number if the current revision is better than the past, by whatever metric you're going for.
18:20:51 <alise> pineapple: AnMaster really, really hates git.
18:20:55 <alise> to the point of religious zealotry.
18:21:07 <AnMaster> pineapple, ah I missed that. And no I don't love it
18:21:38 <fizzie> It's a nice miss, given that git is where everything else (public) of mine is. jitfunge's not shared yet, though.
18:21:47 <alise> now you've got him going
18:21:52 <alise> prepare for an hour of inanity
18:22:08 <AnMaster> pineapple, horrible user interface. Hard to remember commands. Confusing approach at version control.
18:22:12 <Sgeo_> The only thing I know about Git is that there's GitHub
18:22:23 <pineapple> alise: that's what /ignore is for, should i fee it necessary
18:22:41 <AnMaster> pineapple, transitioning from svg to bzr was easy. bzr -> hg was somewhat easy. git is just very alien to me
18:23:10 <fizzie> Hrm, http://pastebin.com/caKbRGzh is the generated assembly with static and tracked boundaries; just based on the number of instructions one would think the first faster, but of course that's a singularly unreliable way of measuring speed. Still.
18:23:11 * Sgeo_ would probably use TortoiseGit
18:23:15 <alise> pineapple: As long as you don't point out that you're ignoring AnMaster every 5 seconds or whenever you miss a line of his, like he does with me. :-)
18:23:36 <AnMaster> pineapple, I find darcs easier, and darcs isn't remotely similar to any other the other ones I find.
18:24:02 <alise> Huh; doing increments/decrements before moves in the queuer thing makes performance only slightly worserer than the previous version.
18:24:32 <alise> So, that bf7 attempt failed.
18:24:46 <fizzie> That's really strange. For that fixed-size block, it's decided to replace those jmp *%rax's with jmp .L281, where .L281: jmp *%rax.
18:24:52 <AnMaster> oh btw I just checked the logs to see what alise said that caused that comment on /ignore up there... "10:23:15 <alise> pineapple: As long as you don't point out that you're ignoring AnMaster every 5 seconds or whenever you miss a line of his, like he does with me. :-)" <-- not remotely true.
18:25:10 <alise> Oh, he just can't get enough of me.
18:25:13 <alise> I know you truly love me <3
18:25:30 <alise> AnMaster: How about either you stop ignoring me or you don't fucking respond to things I say
18:27:34 -!- Mathnerd314 has quit (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.2.2/20100316074819]).
18:27:38 <alise> The question is, what low-hanging fruit are remaining before I take the plunge and do linear loop optimisation...
18:29:02 <alise> "If you're receiving this automated message, you moderate at least one popular reddit community"
18:29:04 <alise> I do? I wasn't aware...
18:29:08 * Sgeo_ reads fiction instead of doing homework
18:29:12 <Sgeo_> alise, what's the message?
18:29:17 <Sgeo_> alise, the mspaint one?
18:29:22 <alise> If you're receiving this automated message, you moderate at least one popular reddit community. Thanks for your contribution to the site, and congratulations on your success. Please subscribe to /r/modnews, a place we've set up for announcements of interest to moderators. Only the reddit admins can post links there, so it shouldn't clutter up your front page too much.
18:29:26 <alise> I guess it's probably mspaint
18:29:32 <alise> but I don't really know how many posts that gets...
18:31:00 <alise> RedditNomic(/r/nomic/)
18:31:00 <alise> Yeah, this is a crap idea.
18:31:09 <alise> What was I thinking?
18:31:25 <alise> Huh, mspaint is reasonably popular.
18:33:59 <alise> I don't suppose there are any general loop semantics faster than
18:34:00 <alise> loop: if (!tape[tp]) ip = (void *)ip->val; NEXT;
18:34:00 <alise> end: if (tape[tp]) ip = (void *)ip->val; NEXT;
18:34:08 <Sgeo_> alise, do you know why I can't get to /r/nomic ?
18:34:16 <alise> Sgeo_: dunno. it has 0 subscribers, strangely
18:34:19 <alise> not even i am subscribed
18:34:31 <Sgeo_> alise, for me, it just says forbidden (reddit.com)
18:34:44 <alise> maybe i set it private
18:39:57 <alise> http://pastebin.com/raw.php?i=W4G2jwzU Can anyone think of a way to improve this interpreter that /isn't/ optimising balanced loops? :-)
18:41:44 -!- alise_ has joined.
18:45:10 -!- alise has quit (Ping timeout: 258 seconds).
18:45:39 <alise_> Hmm; if I can have a five-megabyte program, I can have a five-megabyte tape.
18:47:10 <Sgeo_> optimizing balanced loops?
18:47:13 <Sgeo_> How do you do that?
18:47:27 <Sgeo_> Also: alise_, what do you think of Scala?
18:48:50 <alise_> Scala appears to me to be a hodgepodge of features, none particularly cohering too well with each other; and the OOP parts do not really add anything. I gather that this is considered a common misconception about Scala by some very smart people who like Scala, though. Mainly I abandoned Scala because you had to use, not only the tedious Java toolchain, but some extra build-system related quirks are there if you use Scala; at least when I used it there wer
18:48:50 <alise_> e. That was using, I think, not the most recommended build tool for Scala though.
18:48:59 <alise_> If you're already using Java, using Scala would be absolutely fine. JRuby and Jython too.
18:49:39 <Sgeo_> Is that a copy/paste?
18:49:57 <alise_> Sgeo_: Optimising balanced loops - [>>+<[>+<]<<+>] is p[2]++; p[0] = 0; p[-2]++;
18:50:09 <alise_> You can do this for every nested loop structure with matching > and <.
18:50:29 <alise_> Sgeo_: no, I wrote it now
18:59:41 <pikhq> alise_: Yes, Scala is very much a thing to make Java programming nicer from what I've seen.
18:59:58 <pikhq> Worthwhile if you've already got reasons to be in Java, not worth it otherwise.
19:00:33 * Sgeo_ really needs to learn that he can like multiple languages
19:04:37 <alise_> Anyone have a working clang compiler? pikhq?
19:06:00 <alise_> Would you be so kind as to compile a lil' 64-bit binary with high optimisation for me? I'm thinking clang might have the wisdom to beat gcc on my current version.
19:06:43 <alise_> http://pastie.org/924802.txt?key=9hndhxn9dpruigx3zxg bf7.c
19:06:46 <alise_> http://pastie.org/924803.txt?key=drcs7zwkn7w5buut0xzl9g the requisite mandelbrot.h
19:07:00 <alise_> I'd install clang but I'm on an old version of Ubuntu with only a mobile internet connection.
19:07:52 <pikhq> Any prefered -march=?
19:08:11 <pikhq> Also, -fwhole-program, correct?
19:08:21 <alise_> Yeah, whole program. And, this is an... /me looks it up
19:09:40 -!- alise__ has joined.
19:09:55 <alise__> <pikhq> Also, -fwhole-program, correct?
19:10:03 <alise__> <alise_> Yeah, whole program. And, this is an... /me looks it up
19:10:03 <alise__> <alise_> ...an AMD Athlon 64 X2 5200+.
19:10:03 <alise__> <alise_> So I guess just dual-core Athlon 64.
19:10:03 <alise__> <alise_> Not sure what march that is.
19:11:17 <alise__> There's very little to the program, really, so I don't expect it to do /vastly/ better.
19:11:26 <pikhq> http://filebin.ca/jnad/a.out
19:12:47 -!- alise_ has quit (Ping timeout: 258 seconds).
19:14:01 <alise__> http://pastie.org/924812.txt?key=bq9xhffo89frcoacjgqr0w ;; I hope that bf7 being very, very slightly slower than its predecessor on average is just coincidence in my measurings.
19:14:08 <alise__> - p->val += c == '+' ? 1 : -1;
19:14:08 <alise__> + last->val += c == '+' ? 1 : -1;
19:14:11 <alise__> and only running ADV if we need to
19:14:14 <alise__> should be a speed up if anything
19:14:19 <alise__> - #define ADV p->mov += mov; mov = 0; last = p; p++; p->mov = 0
19:14:20 <alise__> + #define ADV p->mov = mov; mov = 0; last = p; p++
19:14:23 <alise__> almost certainly either does the same thing, or less
19:15:55 <alise__> pikhq: Congratulations. Your computer produces far better code for my computer than my computer does.
19:16:14 <alise__> 11.314s, vs average of 15.000 to 15.350 for mine.
19:16:23 <alise__> You shaved off ~4 seconds. Fuck yeah, clang.
19:16:33 <pikhq> BTW, -O3 -march=k8 -msse3 should be good "absurdly good" flags for your computer.
19:16:46 <pikhq> -O2 -march=k8 -msse3 should be sane ones.
19:17:44 <alise__> Hey, gcc does -fwhole-program too.
19:17:47 <alise__> Or does -O3 automatically do that?
19:18:03 <pikhq> For this program, -fwhole-program as well.
19:18:08 <alise__> Hmm... no loops to unroll that wouldn't be cheating (unrolling the parsing loop would be cheating; the program is currently a constant string)
19:18:22 <pikhq> BTW, -fwhole-program will break not-small programs. :)
19:18:26 <alise__> No fucking clue what most of the -f options do.
19:18:38 <alise__> pikhq: This program will grow to at most a couple hundred lines ;-)
19:18:45 <olsner> what does whole-program do?
19:18:55 <alise__> olsner: assumes that nothing will link with it
19:19:01 <alise__> and so basically fucks everything into one great big ball of mud
19:19:13 <alise__> then smashes it with a hammer so that it looks like the pure operations that need doing, nothing more
19:19:20 <pikhq> olsner: -fwhole-program tells the compiler that the only symbol that will be exported is main.
19:19:20 <alise__> you can see how this would cause problems on complicated programs.
19:19:40 <alise__> pikhq: Why SSE? I can't think of a single thing in my program that would be helped by SSE.
19:20:00 <pikhq> alise__: Oh, that's just because your CPU supports -msse3.
19:20:31 <pikhq> The -march flags will turn on most of the supported such extensions, but your CPU supports SSE3 and -march doesn't tell the compiler that.
19:21:07 <alise__> I wonder if -Os might not help here; the programs are very small (bf7 is just 93 lines), and the actual tight main loop is all manual computed gotos, so there's not many clever optimisations to be done there.
19:21:15 <alise__> So having everything fit in the computer's nice little pocket could help.
19:21:26 <olsner> ah, right... -fwhole-program wouldn't really be needed if it wasn't so fiendishly complicated to tell a C compiler/linker/etc system exactly what needs to be exported
19:21:37 <alise__> pikhq: -fwhole-program -march=k8 -msse3 don't seem to have improved bf7 performance any, which supports my hunch that it can't optimise my awesomeness.
19:21:49 <alise__> also it bloated the size of the binary by like 500 :P
19:21:52 <pikhq> Your program is already small enough to fit in the whole cache.
19:21:59 <pikhq> Okay, GCC sucks. :)
19:22:09 <comex> I never knew about -fwhole-program
19:22:34 <pikhq> alise__: Strip, man, strip!
19:22:36 <alise__> How queer; they won't go smaller.
19:22:47 <pikhq> olsner: The link-time optimiser that GCC and Clang have should help with that.
19:22:49 <alise__> Will -fwhole-program work with, or against, -Os?
19:22:57 <alise__> I assume -march=k8 is fine to use with it.
19:22:59 <comex> what are you trying to accomplish?
19:23:13 <pikhq> And yes, -march=k8 is just fine.
19:23:14 <alise__> A brainfuck interpreter faster than bff4 with linear loop optimisation.
19:23:32 <comex> you're compiling brainfuck to C?
19:23:44 <alise__> Compiling, esotope has already cornered that market.
19:23:49 <alise__> It compiles hello world to a constant output, after all.
19:23:54 <alise__> When interpreting, optimisations cost.
19:23:57 <alise__> Post-stripping, an -Os'd bf7 is 19K.
19:24:11 <alise__> Let's see how fast it goes. Brrm brrm!
19:24:26 <alise__> This is all just tactics to avoid working on the linear loop optimisation :-)
19:25:17 <wareya> am I stupid for trying to cast a file to a string in C?
19:25:37 <alise__> $ ./bf7 >/dev/null; time ./bf7 >/dev/null
19:26:08 <alise__> I'd love to see the assembly for this thing. Computed gotos can't be pretty.
19:26:40 <alise__> -O3 restores everything back to its original glory.
19:27:13 <pikhq> Clang seems to handle computed gotos *much* better than GCC.
19:27:40 <alise__> http://pastie.org/924802.txt?key=9hndhxn9dpruigx3zxg Anyone know if I can initialise blueprints without having to call interp?
19:27:45 <alise__> After all, clearly it can be done in asm.
19:28:25 <Deewiant> Given that 2.6 doesn't support indirectbr :-P
19:28:52 <pikhq> Still handles it better.
19:29:40 <alise__> I can't just put the declaration of blueprints inside interp, can I?
19:29:42 <Deewiant> 2.6 just lowers indirect gotos to switches
19:29:47 <alise__> And I can't assign an array literal like that.
19:29:56 <Deewiant> So it makes me wonder what GCC must be doing there, if that's better
19:30:01 <alise__> Deewiant: Well, maybe that would turn out faster.
19:30:18 <alise__> Since theoretically the indirect goto has an "unknown" destination, not just one-of-a-few-cases.
19:30:23 <alise__> So we have to jump "generically", not specialisedly.
19:30:35 <alise__> The only reason computed gotos are faster with gcc is that it sucks at switches, and a switch makes it jump more.
19:31:24 <alise__> #define NEXT ip++; tp += ip->mov; goto *ip->kind
19:31:59 <pikhq> *Gah*, that's right. GCC is merging the tails of all that.
19:32:00 <alise__> Some of them have code I don't even know what it does, though.
19:32:09 <pikhq> So it can have a single indirect jump instruction.
19:32:37 <alise__> which is, you know, longer than I'd like for threaded code
19:32:39 <alise__> also there is an awful lot of .quads around here
19:32:41 <alise__> pikhq: Can I disable that?
19:33:09 <pikhq> alise__: I've been trying to.
19:34:30 <alise__> In the next revision, or at least in the next few, I'm going to have to bite the bullet and implement linear loop optimisation.
19:34:38 <alise__> When I do that I should beat least competitive with bff4lnr.
19:34:44 <alise__> Hopefully, I'll be able to beat it.
19:35:02 <alise__> Here's what I'm up against: http://mozaika.com.au/oleg/brainf/bff4.c compiled with -DLNR.
19:35:22 <alise__> Of course, it will be cheating until I add loading a program somehow, and then an automatically growing tape.
19:35:33 <alise__> I have a feeling malloc will slow my program down immensely; right now I don't use it at all.
19:35:43 <alise__> Perhaps I will mmap some ridiculously large space instead, and depend on overcommitting.
19:37:08 <comex> doing it in hardware ftw!
19:37:24 -!- lament has quit (Quit: lament).
19:38:36 <comex> you could mmap a bunch of contiguous pages, mark the last one PROT_NONE, and install a SIGSEGV handler to grow the space
19:39:16 <pikhq> That seems... Awful.
19:39:30 <olsner> besides, isn't that exactly what the kernel does internally if you just mmap the whole free address space?
19:39:44 <alise__> Something like that, I think.
19:39:50 <alise__> pikhq: Hey, there's a library to handle segfaults.
19:39:54 <alise__> Not that I'd use it; too much overhead.
19:40:02 <comex> that's not necessary at all
19:40:12 <alise__> it's cleaning up afterwards that's the problem
19:40:13 <alise__> olsner: the kernel will likely do it faster though, won't it?
19:40:16 <comex> as for mmaping the whole space, I don't know :p
19:40:46 <comex> isn't it likely to reserve a whole lot of physical memory? or does it not do that until the memory is actually used
19:40:48 <alise__> The advantage of the SIGSEGV solution is that it would work even with overcommit turned off.
19:40:54 <alise__> Linux always grants a request for memory
19:41:01 <alise__> as long as it's within certain (ludicrous) bounds
19:41:08 <alise__> you can't ask for more than you have
19:41:11 <alise__> but you can ask for what you have, twice
19:41:15 <alise__> it'll grant both immediately
19:41:21 <alise__> then it only actually grabs the memory when you need it
19:41:24 <alise__> this is why it needs the OOM killer
19:41:34 <alise__> a program gets some memory, uses it, suddenly we can't give it the memory we've already told it we have
19:41:36 <comex> yes, but it could also allocate some memory to you in the assumption yuou're about to use it
19:41:39 <alise__> who's the culprit? who's hogging our memory?
19:41:46 <comex> but I'm wrong about that so k :p
19:41:53 <alise__> comex: I've done it before and it doesn't actually reserve much memory at all
19:42:08 <alise__> http://pastie.org/924840.txt?key=jhefhf0gduvence49befva Look for low hanging fruit, feeble-minded slaves!
19:42:23 <pikhq> comex: malloc almost *cannot* fail on Linux.
19:42:31 <alise__> I bet using the C stack is faster than maintaining my loop stack.
19:42:37 <pikhq> Unless you turn off overcommitting.
19:42:42 <comex> alise__: why would it be faster?
19:42:45 <pikhq> alise__: Yes, the C stack is very fast.
19:43:06 <comex> x86 has dedicated opcodes for pushing on the stack
19:43:09 <alise__> I'm doing lots of manual stack operations for something that C compilers are optimised to do millions of times a second
19:43:47 <comex> the question is whether processors actually treat *SP specially
19:44:18 <pikhq> C stack handling is *absurdly* fast on x86.
19:45:11 <alise__> eh, bf7 will be a cleanup revision
19:45:40 <comex> otoh, if you mean using recursion for loops, you are wasting some stack space
19:45:40 <alise__> this is just like using a version control system, but nicer :P
19:45:51 <comex> for the return address etc
19:45:53 <alise__> case '[': p->kind = Loop; loops[lp++] = p; ADV; break;
19:45:55 <alise__> loops[--lp]->val = (long)p;
19:46:00 <alise__> also not if your compiler optimises that
19:46:17 * alise__ wonders how to write the above using recursion
19:46:26 <comex> never heard of a compiler optimizing that :p
19:46:32 <alise__> gcc optimises tail recursion.
19:46:41 <comex> well, I may be thinking of a different implementation than you
19:46:47 <comex> that would definitely not be tail recursion
19:46:54 <alise__> it wouldn't be in this case
19:46:59 <alise__> but it'd be better than using my manual stack
19:47:02 <Sgeo_> All recursion can be turned into iteration [unless it's just tail recursion]. Can all iteration be turned into recursion somehow?
19:47:04 <comex> if you feel like being a jerk, you could use inline asm to push/pop :p
19:47:27 <alise__> All recursion can be turned into iteration [unless it's just tail recursion].
19:47:30 <comex> that would probably be the fastest, but I doubt there's a way to do that in C
19:47:36 <alise__> which is basically just recursion
19:47:41 <alise__> Sgeo_: and the answer is yes
19:47:44 <alise__> iteration is just tail recursion
19:48:45 <comex> one thing you could do is do a loop beforehand that converts non-BF characters to some known character
19:49:22 <alise__> I just completely ignore non-BF chars.
19:49:36 <comex> then you could optimize the switch statement because you know all characters are one of 8 characters
19:49:49 <Sgeo_> [About Ubisoft] "They're actually trying to stop piracy. If the servers stay down, it's impossible for the pirates to track communication between client and server in order to get the data they need to fully crack the game. So, if they keep the servers down forever, the game will be never be cracked!"
19:49:52 <comex> that would probably simplify the machine code significantly and avoid a branch
19:49:53 <Sgeo_> http://www.fark.com/cgi/comments.pl?IDLink=5216097
19:50:02 <comex> well, maybe about the branch :p
19:50:52 <alise__> comex: oh, I'm not optimising the parser yet
19:51:16 <pikhq> The parser should be the quickest thing you deal with.
19:51:19 <alise__> case '[': p->kind = Loop; loops[lp++] = p; ADV; break;
19:51:19 <alise__> what I really want to do here is parse the current s
19:51:28 <comex> btw, I wouldn't be surprised if it runs faster in 32-bit mode
19:51:32 <pikhq> Like, "parse all of LostKng in a few fractions of a second".
19:51:46 <pikhq> comex: My experience has been "no".
19:51:53 <comex> pikhq: then it makes sense to preprocess for faster runtime
19:51:54 <alise__> I need to have parse return, not modify a global variable
19:52:11 <comex> parse gives me a headache :p
19:53:27 <comex> I'm misunderstanding your code
19:53:45 <alise__> Admittedly I have not wrote for clarity much.
19:53:52 <alise__> I think parse is quite nice code though.
19:54:12 <comex> parse is running once, beforehand, right? and then interp?
19:54:31 <comex> oh, End actually stores hwere it is going
19:54:42 <alise__> and then modifies the Start to point to the End
19:55:16 <comex> also, mov could be a short
19:56:13 <alise__> To what avail? And what if you had more <>s than that in a row?
19:56:34 <alise__> Unlikely but not almost impossible in the way overflowing the int is.
19:56:40 <comex> well the tape is only 65536 long eh?
19:56:48 <comex> such a thing would overflow the tape anyway
19:56:57 <alise__> But it can be increased, and will be dynamically sized later.
19:57:03 <alise__> I don't think shorts would be stored more efficiently on most machines, anyway.
19:58:14 <comex> fwiw 'val' could also be 32-bit if it's an offset from prog instead of a pointer
19:58:18 <comex> but I guess that wouldn't be much gain
19:58:55 <alise__> the arithmetic would make it worse on the whole
19:59:11 <alise__> Loops would be faster if their pointers pointed to the instructions /after/ the loop instructions.
19:59:19 <comex> I don't believe that without a test :p
19:59:20 <alise__> That way, we could do less work than the general NEXT; we could skip ip++.
19:59:28 <alise__> jane@jane-desktop:~/code/bf$ ./bf8
19:59:35 <alise__> (bf8 is the recursive-parser version)
20:00:13 <comex> well you should definitely use a pointer to tape + tp that changes, instead of indexing every time
20:00:17 <comex> though maybe the compiler does that ofr you
20:00:23 <comex> for that matter, what if you make rsp = &tape[tp]
20:01:42 <comex> using the syntax that lets you reserve a register for a variable
20:01:42 <alise__> comex: actually i used a pointer to tape + tp
20:01:57 <alise__> comex: I think because the compiler can optimise the array access because it knows tape is static
20:02:02 <alise__> whereas a pointer could be any old thing
20:02:24 <comex> wouldn't the same apply to indexing prog :p
20:02:46 <alise__> I think because prog already has the indirect jump magic, so it doesn't help much, and the overhead of the indexing wins out.
20:02:52 <comex> can I have a copy of mandelbrot.h?
20:02:54 <comex> I want to try something
20:03:11 -!- BeholdMyGlory has joined.
20:03:43 <olsner> alise__: it should be obvious from the assembly if it actually does (optimize indexing)
20:03:51 <comex> and the compiler flags even :p
20:03:57 <alise__> pineapple: it's just mandelbrot.b without newlines enclosed in ""
20:04:08 <alise__> comex: of bf7, presumably, since that one actually works
20:04:13 <alise__> bf8 is just my tweak-parser version
20:04:20 <comex> sure, I was using the one on pastie
20:04:54 <alise__> http://pastie.org/924867.txt?key=y1tsv0fos2dcg2ku9rkqw
20:05:09 <alise__> -O3 -march=k8 -msse3 -fwhole-program
20:05:13 <alise__> then afterwards, strip -s it
20:05:24 <alise__> Change the march if you're not on AMD Athlon or similar, of course.
20:05:30 <alise__> core2, if you're on Core 2.
20:05:38 <comex> (why not just -march=native?)
20:05:47 <alise__> Because pikhq did it at first :P
20:06:01 <comex> you're using clang or gcc?
20:06:35 <alise__> comex: gcc. pikhq did it with clang and got significant (many seconds) improvement
20:06:38 <alise__> pineapple: ascii art mandelbrot set renderer
20:07:04 <comex> book.c:41: warning: comparison is always false due to limited range of data type
20:07:32 -!- kar8nga has joined.
20:08:15 <comex> yep clang is faster for me too
20:08:45 <comex> slightly faster with -m32
20:09:12 <comex> changing mov to short has no effect
20:09:37 <comex> maybe a very slight improvement
20:09:53 <alise__> By low hanging fruit I meant codewise, not typewise. :-)
20:11:52 <comex> I get a significant improvement using a pointer instead of tape[tp]
20:12:16 <comex> on core2 who knows if you're different
20:12:45 -!- jcp has quit (Ping timeout: 264 seconds).
20:14:42 <comex> -fomit-frame-pointer is also an improvement
20:15:00 <alise__> what /is/ the frame poitner anyway?
20:15:05 <alise__> comex: hmm really? plz post timings for pointer
20:16:14 <Deewiant> The frame pointer points to a location in the stack frame :-P
20:16:31 <comex> http://pastie.org/private/f9etyzhaoucns4mm0hfua <- pretty obvious change
20:16:32 <Deewiant> Typically the return address or thereabouts
20:16:45 <comex> omitting it makes debugging impossible
20:17:32 <Deewiant> I've always considered it as more a tool for humans and don't understand why compilers use it by default
20:20:30 -!- ENKI-][ has quit (Read error: Connection reset by peer).
20:20:47 <comex> it's not that much of an improvement, but definitely there
20:21:10 <comex> ~.025s improvement, 5.214 instead of 5.234
20:21:16 <alise__> input: if ((tape[tp] = getchar()) == EOF) tape[tp] = 0; NEXT;
20:21:16 <alise__> even though the comparison is always false
20:21:19 <alise__> and it should only work with 0 eof
20:21:25 <alise__> comex: measured multiple times yeah?
20:21:31 <alise__> otherwise disk cache and stuff
20:21:50 <alise__> ok, as soon as this new parser works i'll add that
20:25:43 <alise__> this keeps segfaulting and I have no idea why
20:27:41 <fizzie> Deewiant: Did you notice my curious ff3 thing?
20:28:09 <fizzie> Deewiant: http://pastebin.com/KrSjfAgS
20:28:29 <alise__> comex: gdb is worse than useless. usually :P
20:28:54 <Deewiant> fizzie: How does boundary tracking work versus PF_X/PF_Y?
20:29:05 <fizzie> Deewiant: Where the difference between -DPF_X=15 and -DBOUNDARY_TRACKING is that for -DPF_X the subtraction of pf_box_x has a compile-time constant argument, whereas for the other it's a file-scope "static int pf_box_x".
20:29:13 <fizzie> Deewiant: Here's the generated assembly: http://pastebin.com/KrSjfAgS
20:29:21 <fizzie> Uh, copypaste mishap. :p
20:29:38 <fizzie> Deewiant: http://pastebin.com/caKbRGzh I mean.
20:30:07 <fizzie> And for the upper, .L281: jmp *%rax; and nothing else.
20:30:10 <Deewiant> There must be other differences :-P
20:30:33 <fizzie> That snippet is the wrapping function. Of course there are other differences in the code.
20:30:37 <fizzie> It's a strange thing to do though.
20:30:48 <fizzie> Should perhaps try both with clang.
20:31:03 <fizzie> After some ice-cream experiences, away a while.
20:32:08 -!- oerjan has joined.
20:33:54 <oerjan> <AnMaster> <oerjan> i guess that answer your previous question, then <-- what was that question?
20:34:53 <alise__> oh i think i know how it is segfaulting?
20:36:28 <oerjan> <alise> (The simple answer, of course, is that mirrors rotate in the fourth dimension.*)
20:36:39 * oerjan swats alise__ -----###
20:36:56 <oerjan> they swap _back_ with _front_
20:38:03 <comex> I tried manually (in the assembly) swapping edi (which clang picked to store ptr) with esp
20:38:07 <comex> in case it would speed things up
20:38:38 <comex> admittedly, my assembly was nonoptimal (it used two 'xchg' around each putchar) but that shouldn't make a huge difference; however, the code just slowed down a lot
20:39:59 <alise__> Program received signal SIGSEGV, Segmentation fault.
20:40:00 <alise__> 0x00000000004005f4 in interp (setup=0 '\0') at bf8.c:39
20:40:00 <alise__> 39change: tape[tp] += ip->val; NEXT;
20:40:50 <alise__> (gdb) print *(op*)*(ip+1)->val
20:40:51 <alise__> $11 = {kind = 0xf00213959058b48, val = -4574530908104654666, mov = -1958210955}
20:41:02 <alise__> ok; I have an end-loop instruction whose val (go back to...) is pointing to random memory
20:41:24 <alise__> last should always be valid, so how is this happening?
20:43:16 <alise__> im jumpin = yo bitch, this is parse() and we got a ], returning nao
20:43:23 <alise__> back in da haus = parse totally gave us some fucking shit
20:43:30 <alise__> so we have an un-haused jumpin.
20:43:44 <alise__> I know the brackets are balanced so HOW IS THIS MONSTROSITY
20:44:08 <alise__> comex: if i give you the code, you fix it k
20:44:09 <fizzie> Deewiant: Oh, right, forgot; did try clang earlier, but http://pastebin.com/9qX7qyd5
20:44:36 <alise__> comex: http://pastie.org/924919.txt?key=djk4pkptyma547uhozx1q
20:47:04 * oerjan swears at the neighbor's barking dog
20:47:38 <alise__> I don't increment s when I recurse
20:47:47 <alise__> ugh, so parse needs to return a tuple
20:47:54 <fizzie> Deewiant: I guess it could be something a bit like http://llvm.org/bugs/show_bug.cgi?id=6608 which seems fixed already; I don't exactly use LLVM trunk, maybe I should start.
20:48:13 <Sgeo_> fizzie, when did you last play Robozzle?
20:48:13 <oerjan> so your s is cursed rather than recursed
20:48:28 <Deewiant> fizzie: You could try llvm-gcc 2.6 as well
20:48:28 <alise__> oerjan: I would enjoy killing you!
20:49:00 <alise__> Now it works but segfaults anyway
20:49:27 * Sgeo_ hands alise__ a potion of holy water
20:50:01 <fizzie> Sgeo_: When it was talked about back then; I haven't played since.
20:50:29 <fizzie> Deewiant: I'll try this Ubuntu "llvm-gcc-4.2" thing first, but I guess if I'm serious about jitfunge's llvm side, I should try to get them codes too.
20:52:56 <fizzie> Deewiant: Well, that's better: http://pastebin.com/xQFwEaUu
20:56:29 <alise__> WHY DOES THIS DEFOUL MY PEOPLE.
20:57:26 -!- tombom has joined.
20:59:59 <alise__> Work, blasted computer! Work!
21:01:04 -!- tombom_ has joined.
21:02:56 * Sgeo_ sees another Nexus One ad and starts hyperventilating
21:04:34 -!- tombom has quit (Ping timeout: 260 seconds).
21:05:51 <oerjan> 12:21:16 <alise__> input: if ((tape[tp] = getchar()) == EOF) tape[tp] = 0; NEXT;
21:05:54 <oerjan> 12:21:16 <alise__> how come this works?
21:06:05 <oerjan> is it possible that EOF % 256 is accidentally 0?
21:06:23 <comex> no, because it's -1
21:06:35 <oerjan> well then it should set it to 255
21:06:54 <alise__> oerjan: it sets it to -1 actually
21:07:13 <alise__> maybe this is false somehow, dunno :P
21:08:13 <oerjan> !c ((char)(-1) == EOF)
21:08:40 <EgoBot> languages: Esoteric: 1l 2l adjust asm axo bch befunge befunge98 bf bf8 bf16 bf32 boolfuck cintercal clcintercal dimensifuck glass glypho haskell kipple lambda lazyk linguine malbolge pbrain perl qbf rail rhotor sadol sceql trigger udage01 underload unlambda whirl. Competitive: bfjoust fyb. Other: asm c cxx forth sh.
21:09:04 <alise__> !c char c = EOF; if (c) { printf("true\n"); } else { printf("false\n"); }
21:09:24 <oerjan> !c printf ("%d", ((char)(-1) == EOF))
21:09:49 <oerjan> so it is actually true
21:09:59 * Sgeo_ doesn't like the thought that most apps will come out for the iPhone before Android
21:10:14 <alise__> Sgeo_: the iphone isn't an option if you have any morals.
21:10:34 <oerjan> alise__: i guess you'll get a bug if you input an _actual_ -1 char, then
21:10:42 <alise__> oerjan: er... there is no such thing :P
21:11:20 <alise__> !c int gcr = EOF; char c = gcr; printf("%d\n", c);
21:11:37 <fizzie> oerjan: On the other hand, 255 isn't used in any UTF-8 combination, so if you only use UTF-8 input, you should be safe.
21:11:40 <oerjan> !c printf("%d", (char)255)
21:12:00 <oerjan> alise__: the printing converts from char to int, preserving sign, obviously
21:12:35 <fizzie> The "passing as argument to a vararg function" already converts it to int, doesn't it?
21:13:03 <alise__> !c int gcr = EOF; char c = gcr; if (c) printf("hmm\n"); else printf("WHAT THE FUCK IN THE WORLD\n");
21:13:53 <oerjan> alise__: (char) EOF is not 0
21:14:10 <alise__> input: if ((tape[tp] = getchar()) == EOF) tape[tp] = 0; NEXT;
21:14:10 <alise__> loop: if (!tape[tp]) ip = (op *)ip->val; NEXT;
21:14:11 <alise__> end: if (tape[tp]) ip = (op *)ip->val; NEXT;
21:14:12 <alise__> It undeniably shouldn't work
21:14:15 <alise__> tape[tp] is never set to 0
21:14:30 <alise__> !c int gcr = EOF; unsigned char c = gcr; if (c) printf("hmm\n"); else printf("WHAT THE FUCK IN THE WORLD\n");
21:14:39 <alise__> WHAT DO YOU WANT FROM ME, COMPUTER?!
21:15:04 <oerjan> alise__: er wait tape is _unsigned_?
21:15:13 <oerjan> i just had an explanation if it was signed :(
21:15:15 <alise__> Well, it didn't use to be!
21:15:19 <alise__> oerjan: what's the explanation?
21:15:27 <alise__> TOGETHER SCIENCE WILL UNLOCK THIS MYSTERY, & ALL OTHER MYSTERIES AFTER IT
21:15:42 <oerjan> (== converts char back to int, preserving sign, so (char)(-1) is actually compared as (int)(-1)
21:16:03 <alise__> gcc even tells me the comparison can't be true
21:16:06 <oerjan> to EOF, which is also (int)(-1)
21:16:13 <alise__> maybe i should make it signed
21:16:48 <oerjan> !c printf("%d", (char)(-1) == (int)(-1))
21:16:54 <alise__> is char defined to be signed, or undefined either way?
21:16:56 <oerjan> !c printf("%d", (unsigned char)(-1) == (int)(-1))
21:17:05 <alise__> heh with char the warning disappears
21:17:12 * Sgeo_ is afraid that part of the reason he wants N1 is to show off and counter the iPhone stuff
21:17:33 <fizzie> Of course it disappears; if tape[tp] is signed, it can never be == -1, while if it's signed, it can.
21:18:10 <alise__> so is char defined to be signed? iirc i read that it was undefined
21:18:24 <fizzie> Implementation-defined, isn't it? Can't quite recall.
21:19:32 <oerjan> i vaguely recall it's implementation-defined
21:19:59 <fizzie> Maybe you should just do the input part right (something like "t = getchar(); tape[tp] = (t == EOF ? 0 : t);" with an int t); if you map the 257 possible return values (-1, 0, .., 255) of getchar() into a type that can hold 256 values, you'll undoubtedly have problems distinguishing two of them.
21:20:13 <alise__> fizzie: But that is slower.
21:20:25 <alise__> in the incredibly common case that t != EOF
21:20:34 <fizzie> Why would it be slower than writing a bogus value to tape[tp], then testing?
21:20:48 <alise__> when == EOF, it's the same
21:20:51 <alise__> input: if ((tape[tp] = getchar()) == EOF) tape[tp] = 0; NEXT;
21:21:00 <alise__> we have to set t and then set tape[tp]
21:21:05 <alise__> with ours, it's only one assignment
21:21:26 <fizzie> The compiler is not going to start sticking t into memory somewhere.
21:21:40 <fizzie> You can't really count the =s and say "this is slower, it has more of 'em".
21:22:18 <fizzie> Though you might want to put a { int t = getchar(); ... } block around to make sure t's scope is so short as possible to help it a bit.
21:22:31 <alise__> What's wrong with just making the tape signed, though?
21:22:43 <olsner> implementation-defined, it varies between compilers
21:22:47 <fizzie> You'll think that the character 255 is EOF in that case.,
21:22:53 <alise__> We're already squeezing 257 values into 256
21:22:56 <alise__> because we're using 0 as \0 and EOF
21:25:38 <alise__> this parser still confuses me to no end
21:31:06 <alise__> wtf? i know there aren't unbalanced brackets in this program...
21:31:13 <alise__> oh it is that problem again.
21:36:10 <alise__> recursive parser, though ugly, cut time from 15.152s to 14.552s
21:36:15 <alise__> comex: I'll try your pointer now
21:36:30 <Sgeo_> What if I'm mostly getting the Nexus One because it looks sexier than the iPhone? :/
21:37:21 <Sgeo_> This almost reminds me of Linux -- and I did end up switching back to Windows
21:38:29 <alise__> comex: yes; and my compiler
21:38:44 <alise__> comex: using pointer increases from 14.552 to 16.357
21:42:19 <alise__> comex: can i send you bf[89].c so you can test yourself?
21:43:51 <alise__> http://sprunge.us/JTZe bf8.c
21:43:53 <alise__> http://sprunge.us/KZMR bf9.c
21:44:03 <alise__> gcc -O3 -march=<your architecture> -fwhole-program -fomit-frame-pointer
21:44:05 <alise__> then strip -s the resulting binary
21:44:12 <alise__> ./bf8 >/dev/null; time ./bf8 >/dev/null
21:44:15 <alise__> ./bf9 >/dev/null; time ./bf9 >/dev/null
21:44:20 <alise__> ...and report the timings to me
21:44:32 <alise__> Deewiant need not apply as his computer runs everything in infinitesimal time
21:45:42 <alise__> although, you know, he can if he wants.
21:45:55 <comex> I thought you were using clang
21:45:59 <alise__> also doing it with clang may be worthwhile
21:46:01 <alise__> comex: no; I don't have clang
21:46:07 <alise__> comex: do the timings plox :P
21:46:13 <alise__> i can't believe it is faster for you
21:46:22 <fizzie> I can't believe it's not butter.
21:49:09 <Deewiant> 4.95 and 6.41 using gcc (GCC) 4.3.0 20080305 (alpha-testing) mingw-20080502
21:49:38 <comex> with gcc, bf9 is slightly slower
21:49:41 <alise__> Well, it's Windows, so I'm inclined to almost entirely ignore the data point, but it supports my rejection of comex's findings.
21:49:41 <comex> with clang, bf9 is slightly faster
21:49:53 <comex> neither of them give me as much of a result; .05 sec both ways
21:49:59 <comex> however, clang is *much* faster than gcc
21:50:01 <alise__> For me, 14.552s vs 16.357s is not "slightly".
21:50:07 <alise__> So I will stick to array access.
21:50:14 <comex> 11ish seconds vs 7 seconds
21:50:16 <alise__> comex: Yes, well, I'm on an old version of Ubuntu.
21:50:20 <alise__> I really don't want to compile LLVM & clang.
21:50:27 <comex> ther'es no package for it?
21:50:51 <alise__> It wasn't even released then.
21:51:22 <comex> clang is pretty cool in general though :p
21:51:28 <fizzie> What's this mandelbrot.h file? (Haven't been following.)
21:51:46 <Deewiant> fizzie: http://pastie.org/924867.txt?key=y1tsv0fos2dcg2ku9rkqw
21:52:04 <alise__> Gah, and I just started to paste it, too.
21:53:36 <alise__> If I have T a[], and and v = (long)(a[0] + 1), then a[v] should = a[1], right?
21:53:41 <alise__> It's that silly 1-not-meaning-1 thing, isn't it?
21:53:47 <alise__> I mean, that is the definition of array dereferencing.
21:53:51 <alise__> So, I wonder, why it isn't working...
21:54:11 <alise__> Oh, I see what I did wrong
21:54:19 <alise__> Deewiant: It's not actually a[0] in the code
21:54:33 <Deewiant> Regardless, adding one to a[0] does not, in general, give a[1]
21:54:35 -!- Oranjer has joined.
21:54:50 <alise__> Well, "in general" here it's worked perfectly
21:55:34 <fizzie> Adding one to a[0]'s address might work; I'm having hard time believing adding one to a[0]'s value will yield a[1] unless you've set up a very specifically.
21:55:41 <Deewiant> I think you're confused or your code does not represent your actual code
21:55:58 <alise__> It was actually &a[0] because it was a pointer to a variable which happens to be in the array
21:56:48 <fizzie> clang on bf8.c: http://pastebin.com/krFjTXma -- it seems I really should get a newer clang.
21:56:59 <alise__> http://pastie.org/924983.txt?key=nksyxpkqzwqs6fwwvmmppg
21:57:04 <alise__> What a fucking ridiculous speedup
21:57:09 <alise__> Why on earth does that make more than a tiny amount of difference
21:57:54 <alise__> Seriously, it's over .5s faster just because it avoids some ip++s
21:58:03 <alise__> And it even pays some +1s for that at the start
21:58:24 <alise__> comex: I bet if you apply that diff and do it with clang the difference is nil...
21:58:28 <fizzie> As for gcc, 10.4s for bf8, 11.35s for bf9.
21:58:57 <alise__> The http://pastie.org/924983.txt?key=nksyxpkqzwqs6fwwvmmppg bf9 or the pointer-not-array bf9?
21:59:08 <fizzie> The one you pasted when asking for timings.
21:59:10 <alise__> If the latter, just delete it; the former is the proper bf9 because the latter didn't work out so well.
21:59:23 <alise__> There's a nice olde-style diff, if you like that kind of thing, in the pastie, from bf8 :P
21:59:27 <fizzie> http://sprunge.us/JTZe one
21:59:52 <fizzie> Oh, right. Well, the one next to it.
22:00:10 <fizzie> Gnblblblb qweeb zkxvfs speaking in tongues.
22:00:32 <alise__> I'm surprised I've been able to get such good performance out of very little code.
22:01:51 <alise__> Anyway, http://sprunge.us/JTZe + diff in http://pastie.org/924983.txt?key=nksyxpkqzwqs6fwwvmmppg = bf9 that I'm curious as to the performance of.
22:01:57 <alise__> Mostly with clang, comex, ahem.
22:06:20 <comex> yeah, I'm impressed at the simplicity
22:07:12 -!- ze_german has joined.
22:07:58 <alise__> Deewiant: Well, that's just part of the whole file-loading malarkey, which is really not the most important or difficult part of brainfuck implementation.
22:08:32 <alise__> Deewiant: I'd complain more about the fixed tape size.
22:08:46 <comex> alise__: that patch increases performance with clang by 1s
22:08:48 <alise__> I don't think the code to handle segfault-means-realloc should be too terribly difficult.
22:08:55 <Deewiant> alise__: But isn't that defined in BF
22:09:19 <alise__> Deewiant: No, not defined, just in one of the original implementations. The original compiler had significantly fewer cells, iirc.
22:09:23 <alise__> comex: it's like... barely anything
22:10:01 <alise__> because i recurse to do loops
22:10:04 <alise__> and it advances through the string
22:10:17 <alise__> please, rewrite it without the extra star, I'd love that; I hate pointers-to-pointers
22:10:24 <comex> maybe it affects some random register allocation
22:10:27 <alise__> I'm not dropping the recursion, though; it came out quite a bit faster this way.
22:10:40 <alise__> comex: it's better, though, not just some random hack, because it /is/ objectively doing less things
22:10:51 <alise__> $ time ../bf_compet/bff4 <mandelbrot.b >/dev/null
22:11:30 <alise__> Mind, I won't beat it in the general case until I do linear loop optimisation.
22:12:55 * alise__ tries the self-interp!self-interp!hi123 combo
22:13:28 <alise__> comex: I wish I could get rid of the setup part of interp
22:13:32 <alise__> it's such an ugly way to do it
22:17:32 <alise__> I'm worried I may be overfitting for mandelbrot.
22:17:47 <alise__> Well, maybe I just need linear loops.
22:17:54 <alise__> I don't think I have any mandelbrot-ishly-specific optimisations.
22:21:41 <alise__> it was just waiting for input
22:26:12 <alise__> yeah i actually beat bff4lnr
22:36:04 <Sgeo_> Why are there more games for iPhone :(
23:00:07 <alise__> an iphone is like windows, android is like linux, except android isn't as fiddly as linux :P
23:02:37 <alise__> Anyone have any idea how to write an unordered pair {,} A type such that you can write {,} (bool,A) => (A,A) but not {,} A => (A,A)
23:02:42 <alise__> i.e. it preserves unorderedness
23:04:09 <oerjan> please rephrase that mess
23:06:02 <oerjan> if the first one is an unordered pair of elements of type (bool,A), then i don't see how you can get an (A,A) from it unless the bools are different
23:06:58 <alise__> {,} A is an unordered pair of two As
23:07:24 <oerjan> _clearly_ it must then be a mess
23:07:46 <pineapple> hang on... what are you tryuing t do?
23:08:09 <alise__> oerjan: I cannot rephrase that bool example to get it working properly...
23:08:09 <alise__> (T : {,} (bool,A)) /\ (exists x y, fst x =/= fst y /\ x in T /\ y in T)
23:08:12 <alise__> the problem with that is - constructively -
23:08:16 <alise__> exists x y hands us the two values on a platter
23:08:19 <alise__> which is not really the point at all
23:08:32 <alise__> so I guess I just want {,} A such that we cannot write {,} A => (A,A) and similar
23:10:10 <alise__> http://lifthrasiir.jottit.com/esotope-bfc_comparison ;; I want to do "Simple loop detection"; I don't think I want to do "Pointer propagation" -- too expensive on the whole
23:10:11 * oerjan knows nothing about that
23:10:42 <pineapple> alise__: i'm not sure i understand
23:11:01 <alise__> pineapple: hmm do you know anything about type theory? or at least haskell
23:11:07 <alise__> if not it's hard to explain...
23:11:33 <alise__> um... your regular tuple of two values, except unordered
23:11:42 <alise__> think of a two-element set -- you are familiar with basic set theory, right?
23:12:16 <alise__> anyway, let's think about it as two-element sets
23:12:32 <alise__> so we have a function that takes two values and returns an unordered pair of those two values
23:12:42 <alise__> but we don't have (function taking a function here)
23:12:48 <pineapple> which side of that is the unordered pair?
23:13:03 <alise__> we do intro(3,2) and get {2,3}, we do intro(2,3) and get {2,3}
23:13:07 <alise__> obviously this function is valid.
23:13:20 <alise__> because we cannot pick which value is x, and which value is y
23:13:28 <alise__> it matters, because F can distinguish its two arguments
23:13:51 <pineapple> creating the unorderd pair is a one way "move", because it can't be reversed
23:14:23 <alise__> I'm trying to come up with an analogous type in type theory -- basically a functional language's type system but more abstracted
23:16:04 -!- MigoMipo has quit (Quit: When two people dream the same dream, it ceases to be an illusion. KVIrc 3.4.2 Shiny http://www.kvirc.net).
23:16:16 <pineapple> i don't understand the "new" notation
23:19:16 -!- alise__ has quit (Ping timeout: 258 seconds).
23:20:03 -!- alise has joined.
23:20:10 <alise> Sorry; what did I last say?
23:20:38 <alise> pineapple: I am just using {,}A to denote the type of an unordered pair of As
23:20:46 -!- tombom_ has quit (Quit: Leaving).
23:20:49 <alise> i.e., intro(X,Y) has-type {,}A where X and Y have-type A
23:20:51 <Sgeo_> <alise__> {,} A := A x A => Bool
23:21:04 -!- dbc has quit (Quit: Seeeeeya).
23:21:28 <alise> pineapple: http://pastie.org/925078.txt?key=s1xvjdrz0hakx4spiqbiq
23:21:35 -!- dbc has joined.
23:21:46 <alise> A x A is an ordered tuple of As
23:22:26 <alise> tbh it helps to grasp how type theory, computation and logic intertwine to understand all of this...
23:22:32 <alise> and that requires a good knowledge of type theory
23:23:31 * alise starts work on bf10.c
23:23:35 <pineapple> you do know that i struggle with pointers, right?
23:23:58 <alise> pineapple: actually this is far more theoretical and mathematical than pointers. so that is not /necessarily/ an impairment
23:24:38 * Sgeo_ struggles with how magical & types seem
23:24:44 <pineapple> my point is that i haven't worked out how to get my head around them
23:24:48 * alise pulls an AnMaster, and reads bff4's source to find out how to do linear loops nicely
23:24:49 <Sgeo_> Well, not really badly struggle, but it's strange
23:25:02 <Sgeo_> int& some_ref_type;
23:25:05 <alise> pineapple: have you watched Pointer Fun with Binky
23:25:14 <Sgeo_> I like pointers. They're sensible.
23:25:16 <alise> http://www.youtube.com/watch?v=i49_SNt4yfk
23:25:19 <alise> pineapple: become enlightened
23:25:38 <alise> (it's actually a really good explanation!)
23:25:38 <pineapple> i'm about to (at some point) read chapter 5 of K&R though
23:25:52 <alise> pointer fun with binky. you will be enlightened forevermore
23:26:08 <pineapple> but... finding the syntax for what i want to do feels like pot luck
23:26:34 <alise> basically... here's a good intuition to develop:
23:26:47 <alise> if only I (this scope; mostly, this function) will want to change this, use a value
23:27:12 <alise> if I want someone else to change the individual items in this compound value (structure, array, pointer, etc), but not the compound value as a whole, use one *
23:27:26 <alise> if Iw ant someone else to be able to change the individual items /and/ the whole value in this compound, use two **s
23:27:42 <alise> pineapple: there is your intuition ^
23:28:19 <pineapple> and... how much of this vid is relevant to C?
23:29:58 <alise> pineapple: the whole vid is C
23:30:09 <Sgeo_> Anything that doesn't involve, say, int&, is probably relevant. (something& is revevant thoug)
23:30:22 <alise> pineapple: *** probably has /some/ use, but if you think it does, unless you're really experienced with pointers -- and so already /know/ what uses it has -- you're wrong; and you don't need it.
23:30:27 <alise> *** is almost always really bad practice.
23:30:36 <alise> It should be exceedingly rare; I wouldn't worry about it. If you end up doing ***, rethink.
23:30:45 <Sgeo_> alise, our professor, without explanation, had a function take an argument *&
23:30:51 <Sgeo_> Took me a bit to work it out
23:30:52 <alise> Ignore Sgeo_; I've seen the vid and it's not C++ at all :P
23:31:00 <Sgeo_> I don't think anyone else worked it out
23:31:05 <alise> Sgeo_: as we all know that is the same as taking a value argument!
23:32:17 <alise> The linear loop code in http://mazonka.com/brainf/bff4.c is not very helpful at all...
23:33:51 <alise> I think if( o[i].c == '[' && o[i].igo == i+1 && o[i].shift==0 && o[i].off <= 0 )is the magic bit...
23:35:07 <alise> this is a C++ version
23:35:12 <alise> forget every single thing you heard
23:35:18 <alise> and watch this http://www.youtube.com/watch?v=r4-9Mh3761E&feature=related
23:35:47 <Sgeo_> alise, unless it goes over reference types and not pointers, why bother wiping your mind?
23:35:56 <alise> because it's probably stupid
23:35:58 <Sgeo_> Although new instead of malloc could be hurtful
23:37:59 <alise> I am merely deflecting your blows
23:41:51 -!- alise_ has joined.
23:42:41 -!- Rugxulo has joined.
23:43:04 <alise_> Rugxulo: wow i almost forgot about you
23:43:19 <Rugxulo> that's no surprise, I'm nobody ;-)
23:43:47 -!- alise has quit (Ping timeout: 258 seconds).
23:43:58 <Rugxulo> BTW, if anybody cares, I updated the tiny BEFI.COM, fixed a bug (negmod.bef), now only 1014 bytes
23:44:38 <alise_> You'll be glad to know I'm doing my bit to combat bloated and slow software by writing a very small, very fast brainfuck interpreter!
23:45:09 <alise_> I do use computed gotos, but that makes things faster. It works with clang too.
23:45:26 <alise_> Apart from the computed gotos -- vital to its speed -- it's standard C.
23:45:26 <Rugxulo> yeah, Clang is getting lots of press these days, self-hosting, ClangBSD in testing, etc.
23:45:38 <alise_> It's much faster with clang because gcc does really stupid things to it.
23:45:43 <Rugxulo> it's just that GCC isn't exactly super optimal in output size
23:45:51 <Rugxulo> (not that any compiler is)
23:45:56 <alise_> It's bloated up marvellously for its first day of development -- bf1.c compiled to 19K when stripped; bf9, 27K.
23:46:21 <Rugxulo> BTW, here's a modified benchmark for someone to test:
23:46:34 <alise_> Mind, bf1 is 81 lines and bf9 is 97 lines, so the actual code isn't bloating much; plus, the former takes ~40s to run mandelbrot.b, the latter something like 13s
23:46:43 <alise_> pineapple: Did I ever say it was?
23:46:50 <Rugxulo> N.B. for some reason, it's much slower on my P4 and AMD64 (but much faster on P1), probably self-modifying code
23:47:01 <alise_> Rugxulo: -Os doesn't really help size at all here
23:47:05 <pineapple> alise_: no... but that seems to be the "default" answer
23:47:06 <alise_> -O3 and stripping produce an executable just as small
23:47:06 <Rugxulo> -Os isn't bad anymore, but it's not perfect either
23:47:13 <alise_> I dunno about clang's output size, but it is much faster
23:47:25 <alise_> pineapple: computed gotos are non-standard
23:47:35 <alise_> clang is a C compiler that's better than gcc.
23:47:49 <alise_> computed goto lets you make pointers to goto labels then do
23:47:51 <Rugxulo> Clang is considered "more modern" (whatever that means)
23:48:04 <Rugxulo> but GCC supports more targets and languages
23:48:13 <alise_> Clang is the apple-funded -- but totally open source and independent -- ultra-optimising, helpful-error-spewing, actually-well-designed-unlike-GCC C compiler.
23:48:28 <alise_> Clang supports C/C++/Objective-C (admittedly, C++ not so well); and LLVM has many non-Clang compilers
23:48:44 <Rugxulo> C++ has supposedly improved a lot, it can self-host now (itself being written in C++)
23:48:44 <alise_> GCC is like a badly-implemented and badly-specified half of LLVM plus something worse than Clang
23:48:58 <Rugxulo> GCC 4.5.0 was just released, now with plugin support
23:48:59 <alise_> all apps in mac os x 10.6 are compiled with clang...
23:49:28 <alise_> anyway i'm trying to beat the current bf world champion of speed... mazonka's bff4lnr
23:49:42 <alise_> i think i do already, but I'm implementing the same linear loop optimisation just to clinch it
23:49:48 <Rugxulo> I also recompiled the standard bef 2.2.1 bef.c with GCC 4.4.2 -march=pentium, but it was like twice as slow as -mtune=pentium4 (even on a P1)
23:49:52 <alise_> as a bonus my code is a lot shorter
23:49:54 <Rugxulo> bah, optimization is so tricky :-(
23:50:11 <alise_> admittedly I need to add some code to open source files and stuff
23:50:16 <alise_> and i need a tape-expander
23:50:21 <alise_> (hook into segfault, make that grow the tape)
23:50:29 <alise_> (either that or mmap a huge amount and rely on overcommitting)
23:50:33 <alise_> (right now my tape is fixed-size)
23:50:47 <Rugxulo> so is your hard drive! ;-)
23:51:13 <Rugxulo> dumb question, but how are you testing the speed?
23:51:28 <alise_> my hard drive isn't 65536 bytes long though.
23:51:43 <Rugxulo> no, but it's a fixed size, so basically I meant "don't sweat it too much" ;-)
23:51:55 <alise_> my impl can never be truly tc because c pointers cannot be infinite
23:52:03 <alise_> Rugxulo: yes but you need an arbitrary growing type lest you allocate 2gb every time someone runs it
23:52:09 <alise_> and besides the universe is fixed-size too, but that doesn't...matter
23:52:15 <alise_> testing speed, I have it hardcoded to parse & run mandelbrot.b
23:52:20 <alise_> which renders a pretty ASCII art mandelbrot; slowly.
23:52:21 <Rugxulo> the universe is expanding (or so they say)
23:52:44 <Rugxulo> dunno how they claim to know that anyways ;-)
23:53:04 <alise_> it's called physics and you can't dismiss it with a wink
23:53:14 <Rugxulo> BTW, there's "mandel.bf" (Befunge) also ;-)
23:53:19 <fizzie> Gads, I hate computers. I have been getting suspicious filesystem corruptions on the system SSD, so since the manufacturer has a newer firmware (1.5 vs. 1.42) I download the updater ISO and boot.
23:53:20 <alise_> turns out we can measure shit and make models that predict the things that happen
23:53:23 <fizzie> "[ERROR]Firmware download fail! Bye!" says the updater, reboots, and now BIOS or anything else no longer sees the disk.
23:53:32 <alise_> and they get incredibly detailed such that it is very likely that certain measurements imply certain things
23:53:48 <alise_> Rugxulo: just out of curiosity do you live in the US? and if so what state?
23:53:49 <Rugxulo> fizzie, still in warranty?
23:54:28 -!- Tritonio_GR has joined.
23:54:30 <fizzie> Rugxulo: Less than a month old, would assume so. Won't help much before Monday, I guess.
23:54:45 <Rugxulo> yes, but before I give out my precious SSN, I'd like to know why you are asking :-P
23:55:06 <alise_> state you live in != SSN
23:55:09 <Rugxulo> fizzie, scroll back and see my modified benchmark, try testing it (if you can drag yourself away from your SSD woes)
23:55:18 <alise_> "I live in $state" is about as information-giving as "I live in Wales"
23:55:23 <alise_> or did you not realise that states are fucking huge?
23:55:34 <Rugxulo> not all of 'em, some (e.g. R.I.) are small
23:55:59 <pineapple> what's a recent version of clang? pacman is saying 2.6-6
23:56:43 <alise_> Rugxulo: I just have a certain hunch. I'll tell you the hunch if you answer my question.
23:56:49 <alise_> pineapple: lemme look up the recentest
23:56:57 <Rugxulo> huh, mandel.bf is slow also (surprisingly)
23:57:00 <pineapple> Build Date : Tue 05 Jan 2010 22:52:09 GMT
23:57:01 -!- Rugxulo has left (?).
23:57:18 <alise_> the svn version is more up to date but that involves a bunch of boring compilation, so just go for it
23:57:18 -!- kar8nga has quit (Read error: Connection reset by peer).
23:57:48 <alise_> he hasn't answered my question yet :-)
23:57:58 <fizzie> (2.7 svn from March is not fine, it has problems with the labels-as-values thing.)
23:58:07 -!- Rugxulo has joined.
23:58:30 <fizzie> Rugxulo: My main workstation is the one that had the SSD as a system disk, so I don't have much to test it with right now. I'll check once I've finished dd'ing a backup on a spare HD so that I get a usable computer back.
23:58:37 <Rugxulo> sorry, optical mouse is quite squirrelly sometimes, it jumped to corner and closed my Opera :-(
23:58:42 <alise_> Rugxulo: going to answer? :-)
23:58:59 <Rugxulo> fizzie, no pressure, didn't want to bug you, just found it weird that it's twice as slow on "modern" cpus :-P
23:59:19 <Rugxulo> alise, just guess, you have a 2% chance of being right ;-)
23:59:49 <alise_> Rugxulo: north or south?