00:00:03 <alise> Truer words never spoken.
00:00:08 <ais523> is there any way to tell who added a quote?
00:00:17 <HackEgo> Runs arbitrary code in GNU/Linux. Type "`<command>", or "`run <command>" for full shell commands. "`fetch <URL>" downloads files. Files saved to $PWD are persistent, and $PWD/bin is in $PATH. $PWD is a mercurial repository, "`revert <rev>" can be used to revert to a revision. See http://codu.org/projects/hackbot/fshg/
00:00:22 <alise> http://codu.org/projects/hackbot/fshg/
00:00:27 <HackEgo> 21|<pikhq> First, invent the direct mind-computer interface. <pikhq> Second, you know the rest.
00:00:28 <Sgeo_> So, Jobs is saying that by limiting everyone to Objective-C, nicer apps are made. Apparently, if you don't kick developers to hand-tweak the result, they won't?
00:00:29 <HackEgo> Runs arbitrary code in GNU/Linux. Type "`<command>", or "`run <command>" for full shell commands. "`fetch <URL>" downloads files. Files saved to $PWD are persistent, and $PWD/bin is in $PATH. $PWD is a mercurial repository, "`revert <rev>" can be used to revert to a revision. See http://codu.org/projects/hackbot/fshg/
00:00:41 <Sgeo_> So better just to force everyone to do it one way to..
00:00:52 <HackEgo> 115|<coppro> hmm... does anyone know a nonsense game designed for the mentally handicapped involving yelling
00:00:58 <ais523> clearly, we need to name a user "No output." just to screw with people
00:01:05 <HackEgo> 58|<mycroftiv> [...] sometimes i cant get out of bed becasue the geometry of the sheet tangle is too fascinating from a topological perspective
00:01:54 <HackEgo> 16|<Madelon> 11 holes for me :D
00:02:02 <HackEgo> 102|<Madelon> I want to read about Paris in the period 1900-1914 <Madelon> not about the sexual preferences of a bunch of writers >.>
00:02:10 <HackEgo> 132|<dtsund> For those who don't know: INTERCAL is basically the I Wanna Be The Guy of programming languages. Not useful for anything serious, but pretty funny when viewed from the outside.
00:02:14 <alise> if anyone says anything of interest i'll stop
00:02:16 <HackEgo> 66|<Aftran> It looks like my hairs are too fat. Can you help me split them?
00:02:25 <AnMaster> Gregor, ehird is spamming with the bot agian
00:02:25 <HackEgo> 18|<fungot> GregorR-L: i bet only you can prevent forest fires. basically, you know.
00:02:32 <alise> no he isn't, ehird isn't even in here
00:02:34 <Gregor> AnMaster: I can see that.
00:02:37 <alise> & besides nobody is saying anything of interest
00:02:44 <AnMaster> Gregor, make it ignore him or something for a while
00:02:56 <ais523> grr, I hate channel politics
00:03:08 <AnMaster> Gregor, tell him to use /msg then
00:03:17 <Sgeo_> Vote for ais523 for #esoteric president!
00:03:30 <AnMaster> Gregor, you could do it with iptables anyway, deep packet inspection to discard packages from him ;P
00:03:37 <HackEgo> 99|<coppro> things are more awesome when written by someone in here
00:03:48 * Sgeo_ may end up slapping alise
00:03:52 <ais523> alise: that's one of the most ridiculous ways to ignore people on IRC I've ever heard
00:04:14 <ais523> deep packet inspection
00:04:24 <ais523> hmm, do you only have three lines of memory even for your own comments?
00:04:26 <Gregor> Deep ... DEEP packet inspection.
00:04:28 <HackEgo> 108|<Warrigal> It's not incest if you're third cousins!
00:04:34 <Sgeo_> ais523, you addressed alise at first
00:04:43 <pikhq> Gregor: iptables is capable of some pretty damned deep packet inspection.
00:04:47 <ais523> Sgeo_: yep, then corrected
00:04:55 <pikhq> And its replacement should be more-so.
00:04:56 <ais523> I thought everyone could do IRC corrections in their head nowadays
00:04:59 <ais523> apart from possibly newbies
00:05:08 <Gregor> Mmm yeah ... I love that DEEP packet inspection. So deeeeep ...
00:05:21 <AnMaster> ais523, I can do it. Just that I thought it was about me having ehird on /ignore
00:05:34 <ais523> AnMaster: but it wasn't him talking, it was me
00:05:42 <ais523> or do you have lines that nickping him/her on ignore too?
00:05:51 <AnMaster> ais523, no but that is a good idea
00:05:57 <alise> Hey guys did I mention I'm ignoring alise
00:06:05 <alise> stop pointing it out you dumbass
00:06:07 <AnMaster> ais523, I didn't see the * however
00:06:07 <alise> it's just irritating
00:06:17 <AnMaster> ais523, I use s/// or put the * after generally
00:06:26 <ais523> umm, putting the * after makes it harder to see
00:06:32 <ais523> it's easy enough to see if a comment starts with a *
00:06:37 <ais523> and it makes little sence out of context otherwise
00:06:53 <ais523> you'd have to read a whole line to know if it was a correction or not, unless you read right to left
00:07:01 <alise> like bork bork bork
00:07:11 <ais523> alise: that's a fake swedishism
00:07:12 <alise> that's postfix too
00:07:52 <alise> 3 weeks HackBot <Guest31015> run chmod 777 Guest_hacked
00:07:53 <alise> 3 weeks HackBot <Guest31015> run printf "#!/bin/sh \n echo Guest Hacked " > Guest_hacked
00:07:55 <alise> That is some pretty major hacking
00:08:51 <alise> 5 weeks HackBot <MissPiggy> touch me
00:08:55 <ais523> still, that isn't really hacking
00:09:04 <ais523> that's like people who edit wikis and claim it's hacking
00:09:20 <alise> PRETTY MAJOR HACKING I THINK YOU'LL FIND
00:09:40 <alise> <alise> addquote <scarf> and an AMICED literal would presumably /add/ info to the source <scarf> whatever info gets added, that's the value that the AMICED doesn't contain <scarf> it's all falling into place
00:10:52 * ais523 actually starts reading the link about the iPhone dev agreement that someone linked ages ago
00:11:01 -!- BeholdMyGlory has quit (Remote host closed the connection).
00:11:04 <ais523> this is why I like new-tab opening at the end, it means I read breadth-first rather than depth first
00:11:11 <ais523> hey, maybe this is how I manage to escape TV Tropes
00:11:54 <alise> ais523: unfortunately, that impedes actual navigational use of tabs
00:12:13 <alise> (I use tabs to basically understand a concept in depth by reading all the concepts I don't understand to complete the picture
00:12:26 <ais523> hmm, I use new-window for that
00:12:32 <ais523> tabs are just a todo list of things to read
00:13:23 <ais523> maybe you should have tabs both vertically and horizontally
00:13:31 * Sgeo_ wishes he didn't need the Marketplace app to download apps from the Marketplace
00:13:32 <ais523> so you can go both depth-first and breadth-first
00:14:23 <pikhq> I use buffers and don't care about the order.
00:14:41 <pikhq> I think internally I've got some sort of data structure assigning order to it in my head?
00:15:03 <alise> "In your head" is usually a bad sign; your computer could probably do that for you.
00:15:55 <pikhq> alise: You mean my computer can account for my random whims?
00:15:55 <coppro> Hmm... I can't even remember what I was thinking of when I wrote 115
00:16:22 <ais523> coppro: obviously, or you wouldn't have had to ask
00:16:24 <pikhq> I think half the order is "interest".
00:16:39 <alise> I said "probably".
00:16:46 <ais523> alise: the quote earlier on
00:16:53 <HackEgo> 115|<coppro> hmm... does anyone know a nonsense game designed for the mentally handicapped involving yelling
00:16:58 <alise> coppro: it was some pun
00:17:22 <alise> like if you pronounced it out it sounded like that
00:17:29 <alise> grep for it in your logs or whatever
00:19:28 * Sgeo_ wonders if he can use ANGEL on Android
00:19:48 <alise> Voice search works about 80% of the time, but you have to speak slowly and enunciate everything, and pronounce marks. And it doesn't recognize some proper nouns, transcribing "Jesus" (pronounced the Spanish way) to "Hey Zeus," Bruce Willis style. The major downside is that all the voice transcription is done in the cloudyou know, it's Googleso you have to have a net connection to use it. It's awesome to dictate text messages or emails, though I p
00:19:48 <alise> robably talk too fast and mumble too much for this to work well.
00:20:18 <alise> [[Battery life lasts around a day with normal use, which includes calling, browsing, Google Mapping, push Gmailing and clothed sexting. That's on par with other smartphones now, and won't see much change until we get a dramatic boost in battery technology.]]
00:21:27 <alise> note that the nexus one only has 4gb of storage but you can expand that to 32 gb by inserting a microsd card
00:21:32 <alise> which you want to do, if you want to put music on it
00:22:04 <Sgeo_> alise, school website
00:22:15 <alise> Sgeo_: does it work in webkit?
00:22:17 <alise> if so, probably yes.
00:22:26 <Sgeo_> alise, it's not officially supported
00:22:35 <Sgeo_> It works well enough for most things, but not everything
00:24:00 <alise> If so, it will probably work on Android.
00:24:13 <alise> Besides, you don't even have iPhone as an option: it's AT&T, yes, but it's also contract.
00:24:19 <ais523> why would music take up that much space?
00:24:22 <alise> And the contractless iPhone 3G S is ~$700.
00:24:27 <alise> ais523: Uh... it does.
00:24:33 <ais523> I'm pretty sure you can fit MIDI files on floppies
00:24:35 <alise> Or is this a shitty "LOL MIDI" leadup?
00:24:45 <Sgeo_> Hey, I like MIDIs!
00:24:59 <ais523> I think the problem is that MIDIs are /good enough/
00:25:00 <Sgeo_> MIDIs have a strong connection with the shitty 3d games I like!
00:25:19 <ais523> although I normally compile them into .ogg files on this computer, so they take less CPU to play
00:25:36 <Sgeo_> [well, actually, outside of a few MIDIs from AW, it's mostly a 2d thing that I get MIDIs from]
00:25:39 <ais523> really, we should have a format along the lines of .s3m
00:25:46 <ais523> or whatever it's called
00:26:05 <ais523> which is basically MIDI+patches in the same file, so you don't lose the information that you lose in a wave-like file
00:28:10 * Sgeo_ now has an excuse to use his phone in class
00:28:26 <Sgeo_> [Well, pending a decent Android .ppt viewer]
00:29:00 <ais523> heh, there isn't even a decent Windows .ppt viewer
00:29:56 <ais523> powerpoint is arguably the worst of the major Office apps
00:30:45 <pikhq> They're all pretty bad though.
00:31:14 <ais523> yep, Excel is the best
00:31:19 <pikhq> Though at least Microsoft has finally gotten at least a *bit* of a clue about how to serialise things.
00:31:33 <ais523> rather dangerously so, in that it tries to encourage people to use it for things you really shouldn't use a spreadsheet program for
00:31:42 * Sgeo_ wonders if there's an Android Market viewer that will let him actually download apps
00:31:58 <pikhq> They used to just write a massive chunk of memory to file.
00:32:10 <pikhq> The registry still does this.
00:32:40 <alise> Sgeo_: you could download the free ones from elsewhere i bet
00:32:43 <pikhq> A registry file sometimes includes random chunks of the actual program.
00:33:03 <Sgeo_> alise, did you get the emulator working?
00:33:12 <alise> Sgeo_: I actually just resumed my java download now...
00:35:06 <alise> The doubt within quantifiers.
00:35:46 <alise> Sgeo_: apparently foxit have been working on an android pdf reader
00:36:27 <alise> oh pdfmenot is now google docs viewer
00:36:29 <alise> shorter url though
00:37:11 <alise> Sgeo_: http://www.dataviz.com/products/documentstogo/android/ does full, proper pdf rendering
00:37:40 <Sgeo_> http://www.androidzoom.com/android_applications/productivity/beamreader-pdf-viewer_bfbo.html looks good
00:37:44 <alise> (oh foxit for android died)
00:37:56 <alise> Sgeo_: http://www.dataviz.com/products/documentstogo/android/ seems to do perfect pdf rendering if you can cough up the $20-1c
00:38:02 <alise> (20 dollars minus one cent)
00:38:15 <alise> like with antialiasing unlike that beamreader
00:40:13 <alise> 16% [1 sun-java6-bin 7749120/27.4MB 28%] 188kB/s 3min 24s
00:40:16 <alise> on mobile internet
00:40:18 <Sgeo_> Pressing Tab doesn't switch between fields
00:40:20 <alise> this is a momentous day for humanity, folks
00:40:28 <alise> Sgeo_: quicker to touch
00:40:34 <ais523> alise: what, downloading Java?
00:40:36 <gm|lap> java serialised classes are pretty hardcore
00:40:42 <alise> ais523: no, the speed over totally wireless internet
00:40:44 <Sgeo_> alise, when I'm in the emulator, it's quicker to press Tab
00:40:46 <alise> gm|lap: java anything is not hardcore.
00:40:56 <gm|lap> and from my experience harder to parse than class files
00:41:40 <gm|lap> if you get at least one of the older minecraft map files, they're basically a gzipped java serialised class with a 5-byte header
00:41:46 <ais523> incidentally, what happens if you serialise a Class object?
00:42:02 <gm|lap> not sure, idunno if it implements Serializable
00:42:04 <ais523> probably nothing particularly interesting
00:42:22 <ais523> gm|lap: gah, for a moment I forgot about Java preventing you doing insane things
00:42:41 * Sgeo_ wonders if Google removed the AppBrain app from the Marketplace
00:42:50 <Sgeo_> Or if the Marketplace detects that I'm trying to cheat it
00:42:52 <ais523> which reminds me, why does no "Java-like OO" language allow you to mark methods abstract but give an implementation anyway?
00:43:08 <ais523> it would make it a lot clearer what methods could be replaced entirely, and which had to be wrapped
00:43:13 <gm|lap> public final class Class<T>
00:43:14 <gm|lap> implements Serializable, GenericDeclaration, Type, AnnotatedElement
00:43:51 <gm|lap> it probably gives you information on the class, but that's about it
00:44:25 <gm|lap> i once made a minecraft map loader in lua
00:44:39 <gm|lap> slow and not very faithful to the spec but it worked
00:44:57 <gm|lap> although i think Notch has decided to use a simpler format
00:45:17 <alise> Sgeo_: the marketplace is not required
00:45:20 <alise> you can install ipk files too
00:45:24 <alise> or are they some other extension i forget
00:45:29 <alise> it's in the emulator website docs
00:45:36 <gm|lap> http://java.sun.com/javase/6/docs/platform/serialization/spec/protocol.html
00:45:55 <Sgeo_> And I know, but there are a lot of apps on the Marketplace, and I don't see how to get to the .apk files without the Marketplace app
00:46:11 <Sgeo_> I installed an alternative Market thing, but I want the real one on here
00:46:25 <gm|lap> it's a fairly well packed format
00:56:45 -!- coppro has quit (Ping timeout: 245 seconds).
00:56:52 <Sgeo_> To have an Internet connection whereever I am
01:04:44 <alise> Sgeo_: It's awesome.
01:08:04 <alise> You can IRC from ANYWHERE
01:08:04 <alise> Nooo, I just ran out of mobile broadband
01:08:24 <ais523> alise: does it charge by the byte?
01:08:31 <ais523> if so, how come you're still talking here?
01:09:28 <ais523> hmm, maybe alise isn't
01:11:03 <pikhq> So, I still haven't a clue why this segfaults.
01:11:19 <pikhq> Heck, I haven't a clue *how* this segfaults.
01:11:52 <ais523> that's sort of like a pong, except it reflects off from a random direction, sort of like a bullet ricochet
01:12:58 -!- alise has quit (Quit: Leaving).
01:14:48 -!- ais523 has quit (Quit: restarting X in an attempt to get rid of a bunch of glitchiness).
01:16:09 -!- ais523 has joined.
01:16:57 -!- ais523 has set topic: | http://tunes.org/~nef/logs/esoteric/?C=M;O=D.
01:21:20 -!- ais523 has quit (Ping timeout: 245 seconds).
01:28:21 <Sgeo_> So, I'm the only person alise wants to say bye too? Or will alise be back before e has to leave?
01:30:11 <pikhq> Finally, running mycology.
01:30:16 <pikhq> BAD: BAD: \ doesn't swap
01:30:33 <pikhq> ... Because \ swaps.
01:31:18 <pikhq> Ah. Comment weirdness.
01:32:17 <pikhq> "// \ " apparently comments out the next line.
01:35:54 <pikhq> And now, mycology.b98 executes, outputs no BAD lines, then segfaults.
01:37:32 <pikhq> I get 2263 lines of output.
01:38:54 <pikhq> v#-5 gv#-20-30pGOOD: p modifies space
01:39:03 <pikhq> Final line before segfaulting.
01:39:50 <pikhq> $1 = {bufsz = 1024, bufused = 18446744073709549303, buf = 0x1000000607010 <Address 0x1000000607010 out of bounds>}
01:39:59 <pikhq> Dear me. That seems quite wrong.
01:40:22 <pikhq> Gregor: Any idea what could cause bufused > bufsz?
01:40:47 <Gregor> pikhq: Something going horribly wrong? :P. Adding to the buffer without EXPANDing it first?
01:41:39 <pikhq> Gregor: Only added to with PUSH. Which checks for that.
01:41:54 <Gregor> PUSH should just be WRITE_BUFFER(..., 1, ...) :P
01:45:22 <pikhq> Same behavior. Hooray.
01:46:26 <pikhq> Welp, that's fun. I was stepping below the array.
01:47:11 <pikhq> In spite of all array indexing being modular arithmetic...
01:47:35 <Gregor> Yessss ... array indexing in crazy-land.
01:47:51 <pikhq> Perhaps my indexes should be unsigned. :P
01:47:55 <pikhq> Yup, that fixes it.
01:48:11 <pikhq> And now I get errorness.
01:48:16 <pikhq> GOOD: p modifies space
01:48:17 <pikhq> BAD: p doesn't modify space%
01:48:27 <pikhq> Which is it, mycology?
01:49:51 <Gregor> Are "space" and "space%" not the same?
01:50:28 <pikhq> % is my terminal showing the lack of newline before EOF.
01:50:44 <pikhq> It was also reversed.
01:53:13 <pikhq> Deewiant: So, any idea how p can both modify and not modify space? :P
01:53:25 <pikhq> I appear to be taking both branches somehow. XD
01:54:37 <Gregor> AnMaster: You should be able to help pikhq here, right?
01:55:24 <pikhq> Gregor: Deewiant wrote Mycology. I presume he could help.
01:55:39 <Gregor> Ah, didn't know the author was also an #esoteric'er.
01:56:30 <pikhq> Course, it's also fairly late/early there. So he may not be conscious.
02:31:02 * Sgeo_ should probably do his C++ homework at some point
02:33:20 * pikhq adds backtraceness to the interpreter
02:39:46 -!- Oranjer has left (?).
02:42:32 * Sgeo_ should learn zippers
02:46:19 -!- Asztal has quit (Ping timeout: 276 seconds).
02:46:48 <pikhq> http://sprunge.us/BhiG Complete program execution.
02:47:11 -!- jcp has quit (Quit: I will do anything (almost) for a new router.).
02:48:25 -!- jcp has joined.
02:54:51 <pikhq> Oh, also. http://sprunge.us/ShIJ
02:57:23 -!- sebbu2 has joined.
02:59:28 -!- adu has joined.
03:00:22 -!- sebbu has quit (Ping timeout: 265 seconds).
03:07:29 -!- augur has quit (Ping timeout: 248 seconds).
03:13:56 -!- coppro has joined.
03:15:20 -!- Gracenotes has quit (Remote host closed the connection).
03:23:02 -!- augur has joined.
03:38:34 -!- augur has quit (Ping timeout: 264 seconds).
03:41:20 -!- Oranjer has joined.
03:41:28 -!- augur has joined.
03:45:28 -!- coppro has quit (Ping timeout: 276 seconds).
03:51:37 -!- augur has quit (Ping timeout: 252 seconds).
04:10:41 -!- Oranjer has left (?).
04:13:16 -!- Oranjer has joined.
04:42:16 -!- augur has joined.
04:55:02 <Sgeo_> Will anyone kill me if I start programming in Scala?
04:55:48 -!- Oranjer has left (?).
05:13:15 -!- coppro has joined.
05:15:54 <Sgeo_> <paulp> I think people have fit full working world taking over AI into 6K. We can fit "x => x + 1"
05:16:20 <Sgeo_> [that was after <paulp> ah, lightweight anonymous functions. http://pastie.org/915119 ]
05:30:47 <Sgeo_> Huh. Scala has mutable and immutable variables
06:22:04 <augur> http://images.4chan.org/co/src/1271047978643.png
06:22:47 -!- oerjan has joined.
06:23:00 <coppro> Sgeo_: so does C++. woop de doo
06:26:29 -!- adu has quit (Quit: adu).
06:28:30 -!- ellisonch has left (?).
06:36:12 <pikhq> coppro: C++ has many sorts of mutability and immutability.
06:36:29 <pikhq> Just like everything else.
06:36:30 -!- FireFly has joined.
07:15:34 -!- jcp has quit (Quit: I will do anything (almost) for a new router.).
07:53:18 -!- FireFly has quit (Quit: Leaving).
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
08:02:12 -!- kar8nga has joined.
08:07:59 -!- oerjan has quit (Quit: leaving).
08:08:58 -!- adam_d has joined.
08:09:34 -!- adam_d has quit (Client Quit).
08:32:50 -!- lament has quit (Quit: lament).
08:58:13 -!- Tritonio_GR has joined.
09:34:22 -!- lereah_ has joined.
10:06:07 <Deewiant> pikhq: After p, it tries to wrap around, and that probably isn't working.
10:15:46 -!- MizardX- has joined.
10:16:50 -!- MizardX has quit (Read error: Connection reset by peer).
10:17:14 -!- MizardX- has changed nick to MizardX.
10:36:51 -!- tombom has joined.
10:47:43 -!- andreas1984 has joined.
10:57:35 -!- andreas1984 has quit (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org).
10:59:48 -!- gm|lap has quit (Quit: ilua).
12:00:29 -!- pikhq has quit (Read error: Connection reset by peer).
12:21:44 -!- Gracenotes has joined.
12:54:17 -!- kar8nga has quit (Remote host closed the connection).
13:04:39 -!- FireFly has joined.
13:25:57 -!- bsmntbombdood_ has joined.
13:27:10 -!- bsmntbombdood has quit (Ping timeout: 245 seconds).
13:34:16 -!- Asztal has joined.
13:35:13 -!- augur has quit (Ping timeout: 264 seconds).
13:50:49 -!- augur has joined.
13:55:54 -!- kar8nga has joined.
14:02:35 -!- augur has quit (Ping timeout: 245 seconds).
14:06:52 -!- Tritonio_GR has quit (Read error: Connection reset by peer).
14:11:26 -!- Tritonio_GR has joined.
14:13:26 -!- BeholdMyGlory has joined.
14:26:06 -!- augur has joined.
14:30:22 -!- MigoMipo has joined.
14:38:00 -!- pikhq has joined.
14:43:31 -!- oerjan has joined.
14:44:44 * oerjan notes an adrian with an L oracle
14:51:52 -!- coppro has quit (Quit: I am leaving. You are about to explode.).
15:04:11 -!- MigoMipo has quit (Remote host closed the connection).
15:09:25 -!- augur has quit (Ping timeout: 264 seconds).
15:18:27 -!- Tritonio_GR has quit (Quit: Leaving.).
15:20:25 -!- augur has joined.
15:22:35 -!- MigoMipo has joined.
15:26:49 -!- MigoMipo has quit (Client Quit).
15:31:38 -!- augur has quit (Ping timeout: 260 seconds).
16:02:13 -!- kar8nga has quit (Remote host closed the connection).
16:35:32 -!- augur has joined.
16:41:28 -!- jcp has joined.
16:48:35 -!- lereah_ has quit (Remote host closed the connection).
16:50:35 -!- augur has quit (Ping timeout: 260 seconds).
16:51:57 -!- augur has joined.
16:57:07 <Sgeo_> "As of now, the only mobile version of RoboZZle is the one for iPhone/iPad/iPod touch. We'll see how much interest there will be in the iPhone client - that will make it clearer how worthwhile it would be be to port RoboZZle to other mobile platforms."
17:03:09 <oerjan> nah, to gibber mush giffle snibble traf a gnome sifting beroth unwards.
17:04:21 -!- oerjan has set topic: This space intentionally left | http://tunes.org/~nef/logs/esoteric/?C=M;O=D.
17:38:28 <pikhq> Deewiant: Which way does it wrap around?
17:39:13 <pikhq> Hrm. Not seeing that in the execution trace.
17:40:13 <Deewiant> It should do that right after it prints the "GOOD: p works" stuff
17:40:33 <pikhq> stepping: (0, 17) ; : No-op
17:40:36 <pikhq> stepping: (15, 17) +; +: 0 0 resulting in 0
17:40:49 <pikhq> ... That... Is an odd place to step to.
17:41:05 <Deewiant> It should step to 80,17 methinks :-)
17:47:38 -!- kar8nga has joined.
17:51:55 <pikhq> And now it goes into an infinite loop between (0, 18) and (14, 18). ... Somehow.
17:52:06 <pikhq> stepping: (0, 18) #; #: skipping char
17:52:10 <pikhq> stepping: (14, 18) ; : No-op
17:52:20 <pikhq> How does that make... Sense?
17:52:51 <pikhq> Didn't fix the wrapping logic in #.
17:53:55 <pikhq> Okay then. Now passes Mycology.
17:55:01 <pikhq> In 0.005 seconds. Granted, Mycology 93, but still.
17:55:11 <pikhq> Now to randomise the directionness.
17:59:30 <pikhq> mycorand.bf has become... An ELF file?
18:00:43 <pikhq> I'm not going to ask how I managed to get an ELF file to the start of that.
18:02:25 <AnMaster> pikhq, still haven't got befunge 93 to work?
18:03:37 <AnMaster> just srand(time(NULL)) and then rand() % 4
18:03:52 <pikhq> I just hadn't *bothered*.
18:03:59 <AnMaster> pikhq, and if your MAX_RAND isn't evenly divisable by 4 you have a strange system
18:04:18 <pikhq> By the way, it's hard to get B93 working when you're segfaulting in getc. :P
18:04:33 <AnMaster> pikhq, what was the cause of that btw?
18:04:50 <pikhq> It was actually segfaulting elsewhere and screwing with gdb.
18:05:00 <AnMaster> wow, must have been a bad segfault
18:05:23 <AnMaster> pikhq, what was the other segfault caused by?
18:06:23 <AnMaster> pikhq, remember to try mycouser too
18:06:57 <fizzie> Well, I have a *** glibc detected *** ./jitfunge: double free or corruption (out): 0x0000000001644ec0 *** which is not much nicer.
18:07:32 <AnMaster> fizzie, those tend to be annoyingly useless backtraces too
18:07:38 <fizzie> It happens inside llvm's _ZN4llvm10VirtRegMap20runOnMachineFunctionERNS_15MachineFunctionE function; don't you just love C++ method name manglings?
18:08:04 <AnMaster> fizzie, suggestion: attach gdb, it handles unmangling too
18:08:27 <fizzie> Yes, though it doesn't help that much to catch the bug.
18:09:14 <fizzie> It's a bit weird because the module->dump()'d llvm assembly compiles just fine with llvm-as + llc into X86 asm; not sure why it crashes like that when it's trying to JIT it.
18:09:29 <AnMaster> fizzie, oh and an idea for the future: find number of CPUs and/or cores. Then if you have more than one start one or two "optimistic tracers". With this I mean something that when you hit a _ or | or such tries to trace the other branch a bit. It is likely to be useful in a bit anyway
18:09:37 <AnMaster> I'm not sure what the locking overhead would be
18:09:45 <AnMaster> but I think it may be not too bad
18:10:05 <fizzie> That could be done, yes.
18:10:09 <AnMaster> well probably do some loop heuristics on the |
18:10:15 <AnMaster> after all it could be a plain if ran once
18:10:29 <AnMaster> maybe look for hot spots by counting hits or such?
18:10:43 <AnMaster> iirc the java vm does that sort of things
18:10:55 <pikhq> AnMaster: I'm still having odd issues on mycorand.bf
18:11:02 <AnMaster> fizzie, I don't know how much of a PITA the locking would be wrt llvm
18:11:18 <pikhq> Among these issues are infinite loops.
18:11:30 <AnMaster> pikhq, I guess your randomness isn't random enough
18:11:44 <AnMaster> pikhq, make sure you actually map 0-3 to different directions
18:12:09 <AnMaster> I remember doing % 4 and then mapping 1-4 once.
18:12:48 <pikhq> AnMaster: It's not getting in an infinite loop there.
18:13:10 <AnMaster> note: I don't have mycology handy atm
18:13:17 <AnMaster> so I can't just take a line/col reference
18:13:35 <pikhq> It's somehow finding itself in the middle of a string and not in string mode.
18:13:45 <pikhq> So it reflect back and forth.
18:14:03 <AnMaster> pikhq, or perhaps like that but wrapping
18:14:04 <pikhq> I'm not sure how it even got there, actually.
18:14:12 <pikhq> It's in the *middle* of the string.
18:14:14 <AnMaster> pikhq, trace it step by step then
18:14:33 <AnMaster> pikhq, as in make it print out x,y,cell-value for each thing it executes
18:15:12 <AnMaster> pikhq, useful if another (known working) interpreter can do that too. Then you can just diff the trace output
18:15:44 <AnMaster> pikhq, ccbi just has a debugger iirc, cfunge can output exactly the kind of debug info I mentioned (with somewhat more fancy formatting than just "x,y,cell-value")
18:16:04 <AnMaster> -t 4 to cfunge should be perfect for this
18:16:10 <pikhq> AnMaster: I've had it stepping for a while now.
18:16:21 <AnMaster> pikhq, then surely you can see where it enters the string?
18:16:54 <AnMaster> pikhq, perhaps some wrapping issue?
18:17:16 <pikhq> AnMaster: It's hard to get this behavior.
18:17:31 <pikhq> Sometimes it just infinite loops putting out the string. Which *also* confuses me.
18:18:30 <AnMaster> when bugs make no sense whatsoever one of the first things to try is valgrind, then valgrind --tool=exp-ptrcheck (or was it ptrcheck-exp? well, some such)
18:18:44 <pikhq> It also only hits "?;" twice.
18:20:50 <pikhq> Oh, sorry. That's from my tracing output. :P
18:21:15 <pikhq> *Ah*. p is modifying the wrong cell.
18:22:13 <AnMaster> pikhq, oh and once you fixed it, please post the source code. I know of a few things mycology93 wouldn't test
18:22:22 <Deewiant> AnMaster: As I've often said, "yes s | ccbi -t" is a tracer :-P
18:22:22 <AnMaster> pikhq, yet you passed mycology?
18:22:32 <AnMaster> Deewiant, in a fairly hard to parse format
18:22:39 <pikhq> AnMaster: Yes, mycology tested (9,9).
18:22:44 <Deewiant> It's not meant to be machine-readable.
18:22:46 <AnMaster> Deewiant, one line per executed instruction?
18:22:51 <AnMaster> Deewiant, well that is what I need it for
18:23:06 <pikhq> And now it passes mycorand.
18:23:12 <AnMaster> Deewiant, maybe you should move that cell in mycology 93
18:23:27 <pikhq> About to test division by zero...
18:23:28 <pikhq> zsh: floating point exception ./a.out mycology/mycouser.b98
18:23:29 <AnMaster> Deewiant, yes but I can't easily sed it to the same format as the trace output to compare to
18:23:54 <pikhq> Because my shell is reporting the exception?
18:24:00 <Deewiant> Well yes, if you're comparing two different interpreters... but you can't assume them to have the same trace format anyway.
18:24:16 <AnMaster> Deewiant, well, that is what you use sed for
18:24:34 <AnMaster> Deewiant, I remember adding such a trace just to track down some t bug early on
18:24:41 <AnMaster> which iirc was the one that turned out to be in ccbi
18:24:43 <Deewiant> So write the sed that changes CCBI's output to whatever you like? You only have to do it once :-P
18:25:19 <AnMaster> Deewiant, also a compact trace is more readable IMO. You can see more of the events without scrolling
18:25:43 <AnMaster> I made sure it was both easy to read in cfunge for the -t 4 level, and easy to parse/grep
18:25:43 -!- augur has quit (Ping timeout: 246 seconds).
18:26:04 <Deewiant> I typically don't want just a trace, I want to see what's going on
18:26:07 <AnMaster> some higher levels is for more detailed info, like top elements of stack and so on, that is less readable
18:26:19 <AnMaster> Deewiant, yes I often find a trace to be a good way to see what is going on
18:26:36 <Deewiant> Aren't you the one who usually uses a debugger to find C bugs? :-P
18:27:26 <AnMaster> Deewiant, for SIGSEGV and similar obviously yes. Otherwise I often tests it without debugger to find the rough point of problem. Then I go into debugger to debug the thing
18:27:54 <Deewiant> So why are you so against debugging Befunge?
18:28:20 <AnMaster> Deewiant, I'm not. I'm just against a lack of easy-to-sed-on trace output
18:28:21 <pikhq> zsh: floating point exception ./a.out mycology/mycouser.b98
18:28:43 <AnMaster> pikhq, also befunge93 should ask you for the value
18:28:44 <Deewiant> AnMaster: I mean, I honestly do not see a use case for tracing
18:28:46 <pikhq> Immediately before?
18:28:47 <pikhq> stepping: (44, 4) %; %: 0 1 resulting in 0
18:29:00 -!- tombom_ has joined.
18:29:07 <pikhq> AnMaster: Also Befunge93 does not say that it should ask you for the value therefore I'm not making it do that.
18:29:08 <Deewiant> AnMaster: I find the good debugger useful, tracing not so much.
18:29:12 <AnMaster> Deewiant, to track down t bugs. Where you can't tell where the error is. But you can compare against a working interpreter and do a game of "spot the difference"
18:29:34 <AnMaster> pikhq, sure it does. I remember reading that
18:29:39 <Deewiant> When there's a bug in t, just break on t and single step.
18:30:01 <AnMaster> Deewiant, well duh in t itself
18:30:06 <AnMaster> Deewiant, I meant in concurrency in general
18:30:23 <Deewiant> Anyway, the point of the CCBI debugger is to debug Befunge, not Befunge interpreters.
18:30:27 -!- augur has joined.
18:30:33 <AnMaster> Deewiant, some timing issue in string mode I remember only tracking down due to tracing
18:30:53 <AnMaster> Deewiant, well okay. I use gdb + a .gdbinit for debugging funge
18:31:08 <Deewiant> You're doing it the wrong way around :-P
18:31:24 <Deewiant> You should use gdb to debug the interpreter and the interpreter to debug Befunge :-P
18:31:31 <AnMaster> Deewiant, didn't you only support a single breakpoint or such in ccbi1?
18:31:54 -!- tombom has quit (Ping timeout: 240 seconds).
18:32:19 <pikhq> AnMaster: Hmm. It seems that this reflects on \0.
18:32:50 <Deewiant> AnMaster: CCBI 2 supports more. I really only need one typically, though.
18:33:30 <AnMaster> Deewiant, also using gdb is in theory faster, it uses hardware breakpoint after all ;P
18:33:43 -!- augur_ has joined.
18:33:50 <Deewiant> Actually it probably uses software breakpoints, but yeah
18:34:01 <Deewiant> I'm just not interested in my interpreter's internals when I've got buggy Befunge.
18:34:06 <pikhq> AnMaster: There's an early newline.
18:34:08 <AnMaster> Deewiant, gdb? No. I prefer hardware breakpoints when possible
18:34:13 <pikhq> The Befunge array is 0-filled.
18:34:20 -!- augur has quit (Read error: Connection reset by peer).
18:34:32 <AnMaster> pikhq, funge space is *space* filled
18:34:44 <pikhq> AnMaster: I'm describing my interpreter.
18:34:51 <AnMaster> pikhq, then you are doing it wrong
18:35:19 <Deewiant> AnMaster: So what, you monitor memory addresses?
18:35:21 <pikhq> http://catseye.tc/projects/befunge93/doc/website_befunge93.html Not in here.
18:35:30 <pikhq> Nor is the "reflect on unknown" thing.
18:35:44 <Deewiant> Mycology isn't very Befunge-93.
18:36:01 <AnMaster> pikhq, a lot of things will break if you don't space fill it
18:36:23 <AnMaster> pikhq, every other interpreter I know of does it. Even for 93
18:36:26 <Deewiant> It doesn't need to be space filled, it just needs to work.
18:36:37 <Deewiant> I.e. if you have something like
18:36:50 <AnMaster> Deewiant, it needs to be space in there
18:36:59 <Deewiant> The v just needs to hit the <.
18:37:00 <AnMaster> Deewiant, because otherwise g on that x,y won't work
18:37:14 <Deewiant> Well, the docs don't say that. :-P
18:37:53 <AnMaster> Deewiant, the docs doesn't say anywhere either that g on a x,y containing a > should return the ascii value of >?
18:38:26 <Deewiant> Eh? They say that g pushes the value of the char at (x,y)
18:38:35 <AnMaster> Deewiant, well then, what is the char space?
18:38:49 <Deewiant> But there is no space to the right of the @
18:39:19 <Deewiant> And what I mean is that the docs don't say what to get for coordinates that weren't in the file
18:39:23 <AnMaster> Deewiant, okay, but that will break a hell of a lot of programs
18:39:38 <AnMaster> pikhq, also a fair number of befunge93 programs depend on unknown reflecting
18:39:39 <Deewiant> I doubt many programs rely on that
18:39:48 <Deewiant> AnMaster: Do they? Don't most interpreters nop?
18:39:54 <pikhq> AnMaster: They're wrong!
18:40:00 <AnMaster> Deewiant, well I remember running into a few
18:40:07 <AnMaster> pikhq, well maybe, but that is your issue then
18:42:30 <AnMaster> pikhq, for 98 it is defined that way anyway. If you plan on doing 98 it is a good idea to get used to it already
18:42:45 <oerjan> depending on the interpreter actually considering a particular character unknown (rather than possibly using it for extensions) sounds like a bad idea to me...
18:42:50 <pikhq> But I'm not *doing* 98.
18:44:46 <AnMaster> Deewiant, have you seen http://catseye.tc/projects/bef/src/bef2c.c ?
18:45:27 <AnMaster> Deewiant, optimisation? befunge? compiler?
18:45:59 <AnMaster> Deewiant, how does it handle self modification?
18:46:06 <AnMaster> if it does then how does it optimise
18:46:21 <Deewiant> It just pretty much bundles an interpreter with the code like all Befunge compilers I know of
18:46:39 <AnMaster> what about the optimisation then
18:46:55 <Deewiant> Dunno, haven't looked into that.
18:47:55 <Deewiant> Or hmm, I'm not sure if that's the one I was thinking of.
18:48:36 <AnMaster> pikhq, the reference befunge93 implementation:
18:48:37 <AnMaster> memset(pg, ' ', LINEWIDTH * PAGEHEIGHT);
18:48:42 <AnMaster> see http://catseye.tc/projects/bef/src/bef.c
18:48:51 <pikhq> AnMaster: Reference implementation != spec.
18:49:12 <AnMaster> pikhq, just telling you that *not* making it default to space is bloody stupid
18:49:33 <pikhq> I'm just telling you that making it default to anything is bloody stupid.
18:49:45 <pikhq> Therefore it defaults to nothing.
18:50:00 <AnMaster> it is filled with random uninitialised data?
18:50:25 <pikhq> No, it's 0-filled, as are all uninitialised C globals.
18:50:26 <AnMaster> pikhq, filling it with \0 is, you see, also defaulting to something
18:50:49 <pikhq> Programs relying on any unspecified behavior will be shot.
18:51:45 <AnMaster> pikhq, what good reason do you have to *not* follow the common practise here? Are you aiming for a DS9K?
18:52:24 <pikhq> AnMaster: "Eff you, unspecified behavior."
18:52:52 <AnMaster> pikhq, I fail to see how that answers my question about your good reason
18:53:39 <pikhq> I do not believe in implementing unspecified behavior soley because of what is common. I am simply going to implement the language.
18:53:48 <pikhq> And I care not for "what other implementations do".
18:54:17 <AnMaster> pikhq, you know if you did befunge98 and do that you would fail. The befunge98 spec doesn't work in some cases
18:54:41 <Deewiant> The only problematic instruction is t.
18:54:46 <AnMaster> Deewiant, yes that is the one I meant
18:55:11 <oerjan> we should all sop using i
18:55:12 <pikhq> If it doesn't work then I would of course look for implementations of it to see what was decided upon as the intended behavior for the language.
18:55:53 <pikhq> http://sprunge.us/SBIe
18:55:53 <Deewiant> It's pretty obvious what to do with t once you've done it "wrong", though.
18:55:56 <AnMaster> pikhq, it doesn't work as in it will cause a fork bomb the way it is defined
18:57:30 <pikhq> AnMaster: Okay then.
18:58:53 <AnMaster> Deewiant, would a to-the-letter befunge-98 spec following implementation (excluding t issues) pass mycology?
18:59:28 <AnMaster> Deewiant, remember it is vague. I'm thinking it would hit issues on k
18:59:46 <Deewiant> Sure, it's vague, but everything non-UNDEF is IMO inferrable.
18:59:58 <AnMaster> Deewiant, not sure about the k issues
19:01:28 <AnMaster> pikhq, anything special to build it? just clang -o pikhq-bef pikhq-bef.c ?
19:02:12 <pikhq> AnMaster: That should do it.
19:02:21 <pikhq> It's very GCC-specific.
19:02:37 <AnMaster> pikhq-bef.c:146:23: error: cannot compile this GNU array range designator extension yet
19:03:09 <Deewiant> Of course it does, since it uses GNU extensions.
19:03:14 <AnMaster> pikhq-bef.c:146:23: error: cannot compile this GNU array range designator extension yet
19:03:15 <AnMaster> ^pikhq-bef.c: In function ‘instrs’:
19:03:15 <AnMaster> pikhq-bef.c:183: warning: array subscript has type ‘char’
19:03:15 <AnMaster> pikhq-bef.c:371: warning: array subscript has type ‘char’
19:03:24 <AnMaster> synergey fails at copy paste fail
19:03:35 <AnMaster> pikhq-bef.c:183: warning: array subscript has type ‘char’
19:03:35 <AnMaster> pikhq-bef.c:371: warning: array subscript has type ‘char’
19:03:35 <AnMaster> pikhq-bef.c:371: warning: array subscript has type ‘char’
19:03:56 <pikhq> AnMaster: Okay. So?
19:04:05 <AnMaster> pikhq, just thought I'd tell you
19:04:20 <pikhq> It's perfectly defined behavior, it's just very likely to be wrong in most programs.
19:06:43 <AnMaster> ./pikhq-bef-tux ~/dragon/src/own/cfunge/trunk/examples/wumpus.bf
19:06:54 <AnMaster> pikhq, let me pastebin the program
19:07:24 <AnMaster> pikhq, it is strange it segfaulted.
19:07:37 <pikhq> Yup, definitely segfaults.
19:07:55 <AnMaster> pikhq, do you grow the stack properly?
19:08:20 <pikhq> AnMaster: The macros do in fact grow the stack.
19:08:21 <Deewiant> These programs are all on catseye.tc
19:08:33 <AnMaster> Deewiant, ah yes indeed I guess
19:08:36 <pikhq> It appears to be trying to access outside of fungespace somehow.
19:08:45 <AnMaster> Deewiant, I forgot the source so I just found it easier to pastebin them
19:08:48 <pikhq> fungespace_x = 4294967295
19:09:05 <AnMaster> pikhq, do you not check that it is in bounds? because these are classical befunge93 apps
19:09:07 <pikhq> The issue is in string mode.
19:09:30 <pikhq> String mode is *probably* supposed to wrap. :P
19:09:31 <AnMaster> pikhq, you don't handle wrapping in string mode?
19:09:41 <pikhq> I thought I did but apparently not.
19:09:42 <AnMaster> pikhq, of course it is supposed to wrap
19:09:55 <pikhq> Yes, it obviously should.
19:10:11 <AnMaster> pikhq, I doubt the primes one segfaults due to this. Since it seems to run fine for quite a bit and I don't see any wrapping strings in it
19:10:15 <AnMaster> so probably another error in it
19:10:36 <AnMaster> Deewiant, and you should extend the 93 part of mycology ;P
19:10:58 <AnMaster> Deewiant, oh and more important: not use 9,9 for p test
19:11:05 <Deewiant> I'm not really interested in the 93 part of Mycology :-P
19:11:06 <AnMaster> use something like 8,9 or whatever
19:11:15 <AnMaster> Deewiant, the p test applies to 98 too iirc?
19:12:02 <Deewiant> Yes, but there's a later pg test that uses -3,-2
19:12:35 <AnMaster> hm wait is http://sprunge.us/jDBL befunge98? Why does does it use .bf extension
19:12:43 <AnMaster> well it is officially befunge97 but...
19:12:55 <Deewiant> Mike's programs all use .f98 IIRC.
19:13:02 <AnMaster> in any case, your interpreter crashes on http://sprunge.us/jDBL as well
19:13:11 <Deewiant> It's not official or anything, it's just a recommendation.
19:13:14 <AnMaster> Deewiant, it says "Kevin Vigor"
19:13:28 <pikhq> Gah! sprunge stopped pasting!
19:13:28 <Deewiant> I just said that Mike uses .f98.
19:14:09 <pikhq> I can't get sprunge to hand me a URL any more.
19:15:18 <pikhq> Still not working for me.
19:15:39 <AnMaster> pikhq, no idea then. Maybe PEBKAC?
19:15:44 <pikhq> I accidentally output into befunge93.c
19:15:54 <pikhq> What was the last paste of it? :P
19:16:11 <pikhq> AnMaster: Not in hg
19:16:11 <AnMaster> pikhq, and if not learn to use version control
19:16:16 <fizzie> echo '(hello)S' | ./jitfunge ../underload.b98 => "main.cc:80: [main] gnuuubl middle of existing trace" -- there's still perhaps some work to do there.
19:16:23 <AnMaster> pikhq, well I hope that taught you a lesson
19:16:26 <pikhq> I don't version control until there's... more than one file.
19:16:42 <AnMaster> well then you will have to find it in scrollback yourself
19:17:11 <AnMaster> pikhq, but if you promise to use a VCS then: <pikhq> http://sprunge.us/SBIe
19:17:16 <fizzie> Deewiant: An expression of despair.
19:17:43 <AnMaster> in what language is "gnuuubl"?
19:17:45 <fizzie> Instead of version control, you could opt for something like NILFS for /home.
19:18:07 <Deewiant> I opt for doing testing in a different directory than the source :-P
19:18:10 <pikhq> http://sprunge.us/KKDR There you go.
19:18:10 <oerjan> it's the sound of a gnu being dragged into a pool by a crocodile. very traumatic.
19:19:39 <pikhq> pi.bf appears to segfault, but that's not B93 so I don't care. :P
19:20:17 <AnMaster> segfaults unless running under gdb
19:20:30 <AnMaster> under GDB it goes negative instead
19:20:54 <pikhq> Fun fact: chars are signed. :P
19:21:07 <pikhq> Well. On x86 and x86_64.
19:21:16 <pikhq> Lemme go make them unsigned.
19:21:18 <AnMaster> pikhq, see: http://sprunge.us/BdIR
19:21:25 <AnMaster> pikhq, I thought you used 32-bit cells?
19:21:32 <fizzie> Wasn't that what the pasted warning was about anyhow?
19:21:46 <pikhq> AnMaster: No, you use "a stack".
19:22:08 <AnMaster> pikhq, you can't really since you can't reach down deep in the stack
19:22:20 <AnMaster> pikhq, oh also: it includes controlcodes
19:22:25 <AnMaster> that seems to have been lost in the paste
19:23:39 <pikhq> http://sprunge.us/bFiZ And now?
19:24:27 <AnMaster> pikhq, works in gdb. Still segfaults outside gdb
19:24:45 <pikhq> Might I suggest getting a core dump?
19:25:37 <pikhq> Then where's it segfaulting?
19:25:48 <AnMaster> ore was generated by `./pikhq-bef-tux /home/arvid/dragon/src/own/cfunge/trunk/examples/prime.bf'.
19:25:48 <AnMaster> Program terminated with signal 11, Segmentation fault.
19:25:48 <AnMaster> #0 0x0000000000401889 in ?? ()
19:25:48 <AnMaster> #0 0x0000000000401889 in ?? ()
19:26:11 <pikhq> Well, I got nothing.
19:26:22 <pikhq> Except "works for me"
19:26:25 <AnMaster> gcc (GCC) 4.4.3 20100316 (prerelease)
19:26:37 <pikhq> gcc (Gentoo 4.4.3 p1.0) 4.4.3
19:27:03 <Deewiant> 401889 looks like a reasonable address.
19:27:29 <AnMaster> gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3
19:27:33 <fizzie> Heh, some bit of jitfunge is trying to put value V to coordinates (X,Y), and ends up putting value X to coordinates (Y,V).
19:27:51 <AnMaster> Deewiant, the next frame does not:
19:27:56 <AnMaster> #1 0x0000000000000006 in ?? ()
19:27:56 <AnMaster> #2 0x003b000000000002 in ?? ()
19:27:56 <AnMaster> #3 0x0000000000000802 in ?? ()
19:28:02 <Deewiant> fizzie: What /are/ you doing in there? :-P
19:28:46 <AnMaster> Deewiant, but unless you tune a sysctl nowdays it is forbidden for normal user space
19:29:10 <AnMaster> pikhq, anyway I can send you the binary and the core dump if that helpos
19:29:12 <fizzie> Deewiant: My first guess is that I populate the intermediate form's "args" structures from the stack in a different order than what I thought I did.
19:29:12 <Deewiant> Well yes, I meant under a typical OS.
19:29:27 <pikhq> AnMaster: Doubtful.
19:29:38 <AnMaster> pikhq, anyway, let me try valgrind
19:29:41 <oerjan> fizzie: it's a rotation
19:29:44 <pikhq> A stack smash isn't all that helpful of a core dump. :P
19:29:59 <AnMaster> it gives lots of invalid reads
19:30:04 <pikhq> Screams bloody murder?
19:30:50 <pikhq> Deewiant: Being able to map 0x0 is a simple system configuration on Linux.
19:31:03 <AnMaster> pikhq, notice some corruption in output for some primes
19:31:38 <oerjan> Deewiant: i recall reading about a recent exploit based on mapping it
19:31:39 <AnMaster> pikhq, anyway, can you reproduce those valgrind errors?
19:31:50 <fizzie> oerjan: Yes, that's actually a bit strange. But p might have a mixture of constant (or already-in-registers) arguments and things it needs to pop, which might cause problems.
19:32:08 <Deewiant> pikhq: Under a typical and typically configured OS >_<
19:32:34 <pikhq> Deewiant: It used to be the default, actually. :P
19:32:35 <AnMaster> pikhq, then I find it not unlikely that fixing those will fix the bug
19:32:37 <oerjan> fizzie: if you are populating V and (X,Y) in the wrong order, you would get that
19:33:16 <pikhq> Deewiant: 2.6.something
19:33:17 <AnMaster> Deewiant, until quite recently
19:33:22 <AnMaster> Deewiant, 2.6.20 or something like that?
19:33:42 <pikhq> Though you'd have to explicitly ask for mmap to 0 for that to happen.
19:34:14 <AnMaster> I always have to change the sysctl when I run sheepshaver
19:34:49 <pikhq> putchar(BUFFER_TOP(stack)); <-- ... *This* is a source of an invalid read. WTH?
19:34:53 <fizzie> oerjan: Well.. the generated intermediate code looks right, it might be I've just messed up when constructing a call to Space.put_at.
19:35:11 <AnMaster> Deewiant, macos classic ppc emulator
19:35:29 <AnMaster> Deewiant, I'm sure I mentioned that when I was working on porting ick to it
19:35:40 <AnMaster> something that mostly worked apart from some compiler bugs in MPW
19:35:46 <Deewiant> I'm sure I've completely forgotten.
19:36:08 <Deewiant> fizzie: How do you identify JITable regions in Befunge?
19:36:21 <pikhq> AnMaster: I think this program relies on 0 being gotten when you pop from an empty stack.
19:36:40 <pikhq> I'll redo my stack code a bit after I get some food.
19:36:42 <Deewiant> pikhq: That it is in the docs.
19:36:44 <AnMaster> pikhq, that is how it should work
19:36:56 <pikhq> Deewiant: I just forgot about it.
19:37:24 <AnMaster> Deewiant, you should add a warning about b93 parts being incomplete ;P
19:37:40 <pikhq> AnMaster: Already is one.
19:38:04 <fizzie> Deewiant: It's a tracing sort of JIT; so I just trace all instructions I execute into a list, and mark those cells as being owned by that trace; then if I at some point end up trying to re-execute cells owned by a trace, I compile that trace instead and execute that.
19:40:31 <fizzie> I could do some sort of "interpret without tracing unless this bit of code sees multiple executions" heuristics too, I guess.
19:41:29 <Deewiant> But where does a trace begin/end?
19:41:50 <pikhq> Deewiant: Presumably on branches.
19:44:24 <fizzie> Deewiant: A trace begins whenever I need to execute anything (so the first trace begins at (0, 0)) and ends when I hit something that has been seen before.
19:44:54 <Deewiant> Something being based on both coordinates and value, I guess?
19:45:33 <fizzie> "something" meaning "a cell registered as being part of an existing trace".
19:46:46 <Deewiant> And "cell" including both coordinates and value, I guess? :-P
19:47:58 <fizzie> No, just coordinates, current delta, and "mode", where "mode" can be normal, string-mode, value-mode (for 'x) or comment-mode (for ;).
19:48:58 <pikhq> Wouldn't that break on p?
19:49:03 <Deewiant> Doesn't that mean that self-modifying code breaks?
19:49:22 <fizzie> If you change the value of a cell that is owned by a trace (no matter what delta it had), then... well, it depends on the mode in that case. For normal mode, I just invalidate the whole trace instead of figuring out if the change is significant; but for something like comment-mode, changes that do not change to/from ; are safe.
19:50:18 <fizzie> And I think for value-mode I update the value stored in the trace, and delete any already compiled code, but keep the trace.
19:50:23 <pikhq> Basically "p is slow mode".
19:50:45 <fizzie> Yes, though I was thinking I might do a compile-time "unsafe p" mode that you can use for programs that don't self-modify.
19:51:22 <pikhq> From the sounds of things your JIT will only be slow when you're modifying something that will then be executed.
19:51:29 <pikhq> Otherwise, you're invalidating 0 traces.
19:51:45 <pikhq> Which will then be executed 0 more times.
19:52:00 <fizzie> Yes, though there's still some overhead in checking for trace-ownership.
19:53:05 <fizzie> There are additional complications in that I compile constant-coordinate p's into a direct memory references, and I have to record those in the space too, so that if I ever trace some coordinate that's being referred by compiled code directly, I have to invalidate that compiled code, because it could do unsafe p on that stop.
19:54:14 <fizzie> This is also a bit hypothetical description since things are more or less broken at the moment.
19:58:04 <fizzie> Well, back to the "put" problem. It compiles what's essentially "\0p" into the intermediate code "r3 <- STACK", "r4 <- STACK", "p 0, r3, r4" where the p args should be first-pop-on-left. That doesn't look quite correct; because of the \ there, the first pop from stack (to r3) should end up as the last argument to p.
19:59:00 <pikhq> Hmm. Are there any notable *Unefunge* 98 interpreters? :P
20:00:33 <fizzie> Well, now it puts V to (Y,X) instead of (X,Y) like it should; but *that* was just because I put the arguments in the wrong order in llbuild.CreateCall4.
20:04:28 <fizzie> TRACE: executing trace 0x1e312f0, in entry 2, stack: 2 2 0
20:04:29 <fizzie> jitfunge llvm runtime: impossible
20:04:29 <fizzie> Segmentation fault (core dumped)
20:04:31 <fizzie> Still not quite it. :p
20:05:11 <oerjan> hm, what if a trace is invalidated _while it is running_?
20:06:20 <fizzie> oerjan: In that case I terminate running it; there's an "exit" out of a branch (with the delta that it had during the tracing) after each p, and same for all A..Z fingerprint-ops, since you never know about those; and a few others that could invalidate traces too.
20:06:37 <AnMaster> pikhq, did you fix your stack?
20:07:00 <AnMaster> <fizzie> jitfunge llvm runtime: impossible <-- I disagree
20:07:29 <fizzie> oerjan: That was also a bit hypothetical, I'm afraid:
20:07:30 <fizzie> fis@eris:~/src/jitfunge/src$ grep -i suicide *.cc
20:07:31 <fizzie> interp.cc: /*! \todo handle: put on current trace - suicide */
20:08:06 <fizzie> It *was* handled properly in some earlier iteration of jitfunge codebase, though.
20:08:12 <fizzie> Except for those cases where it was buggy.
20:08:31 <AnMaster> fizzie, you could probably figure it out directly for constant put, while doing some more checking for when both x and y coordinates are unknown
20:08:50 <AnMaster> in some cases even if x or y is unknown but the other is known you can compute if it is can ever intersect
20:09:22 <fizzie> I already do it sort-of directly for constant put, but that brings the added hassle that if later the code it p's to is executed, the decision needs to be reconsidered.
20:10:31 <pikhq> AnMaster: Not yet.
20:10:54 <pikhq> AnMaster: I'll probably go ahead and make it a little cleaner-looking.
20:11:26 <AnMaster> pikhq, that may take some time
20:11:31 <Deewiant> fizzie: How's Mycology with your current iteration
20:11:56 <AnMaster> (just the chance for that joke was too good to miss)
20:12:07 <AnMaster> pikhq, oh also I think crashing on an invalid program is a bad idea.
20:12:51 <fizzie> Deewiant: I haven't been morbid enough to try.
20:14:04 <fizzie> codegen.cc:275: [compile] not handled: 46
20:14:23 <fizzie> The llvm codegen is really rudimentary.
20:14:34 <pikhq> AnMaster: Crashing on invalid programs.
20:14:41 <fizzie> AnMaster: Ascii 46, so it's "."
20:14:57 <AnMaster> pikhq, The point is there is no such thing as invalid befunge code to my mind
20:15:05 <AnMaster> of course to 93 devs it might appear different
20:15:22 <AnMaster> fizzie, but... how did it output the numbers then?
20:15:42 <Deewiant> fizzie: You're off to a good start!
20:15:43 <fizzie> AnMaster: Those were probably output by the tracing interp. As was the "G" there.
20:16:09 <AnMaster> fizzie, how stable is the tracing interpreter?
20:16:12 <fizzie> For typical print loops, the first , is executed by the tracer, before it hits the loopy part; at that point it tries to compile the trace and hits problems.
20:16:33 <AnMaster> fizzie, so you can't handle >:#,_ yet?
20:16:49 <fizzie> Sure I can, as long as there is nothing in the trace that it can't compile.
20:16:53 <fizzie> It runs hello-world just fine.
20:17:00 <fizzie> A bit noisily, perhaps, but otherwise fine.
20:17:28 <AnMaster> fizzie, btw you realise what with this "two different implementations" thing, you need to test mycology both for the tracer and for the actual jit
20:17:56 <AnMaster> fizzie, I don't think mycology expects , to work once and then stop working the next time
20:18:29 <Deewiant> The readme states that things are generally assumed to work an arbitrary number of times if they worked once :-)
20:18:40 <AnMaster> Deewiant, how can you say "GOOD: , works"?
20:18:41 <fizzie> That's probably true, but the architecture doesn't really let me test it only for the actual JIT. It would be borderline trivial to test only the tracing part, though. (Just drop all traces after generating them.)
20:18:55 <AnMaster> Deewiant, after all you can't see that it was actually output
20:19:18 <AnMaster> Deewiant, well, it could have been faked, Hard coded to always output those letters in a cycle forever ;P
20:19:18 <Deewiant> If it wasn't output, it's not GOOD, now is it.
20:19:39 <Deewiant> Sure, but then it wouldn't output the other things correctly.
20:19:50 <fizzie> http://pastebin.com/vPefjzpw -- jitfunge running hello.b98.
20:20:18 <AnMaster> Deewiant, it could be hardcoded to just output mycology, as a huge printf() to insert date and random randomness values and such
20:20:46 <Deewiant> AnMaster: Mycology isn't meant to be a Turing test...
20:21:34 <Deewiant> The use case is an interpreter dev or general Befunge enthusiast, not somebody actively trying out nonsense to see how many GOODs he can get :-P
20:22:35 <AnMaster> Deewiant, is mycology re-entrant?
20:23:09 <Deewiant> No, (0,0) and thereabouts can have various values after an execution
20:23:43 <fizzie> The shared code/data thing of Befunge makes many JITy things quite messy. For example, if a p instruction ends up growing the borders, I need to recheck all wrapping traces just in case some of those might happen to intersect with that bit. (Since the cell ownership records are only there up to the borders.)
20:24:03 <fizzie> Oh, and I mark all spaces owned by a trace (because otherwise I wouldn't notice changes in them by p), so slowdown will probably totally break jitfunge. :p
20:24:13 <AnMaster> Deewiant, it would be the perfect way to test jitfunge though in both modes
20:25:02 <Deewiant> AnMaster: Just use a loader, hacking the JIT so it doesn't drop traces that were overwritten by an i :-P
20:25:53 <fizzie> Well, maybe it won't; I don't know exactly how it works. If it jumps directly to the far-away bits, then it won't. But if it traverses a huge number of spaces, jitfunge will end up using quite many bytes of memory for each of them.
20:26:42 <Deewiant> It jumps directly, since that's easier to write. (Just subtract the x pos from the target pos)
20:28:47 <fizzie> For the record, "jitfunge llvm runtime: impossible" is what the code says when you call a compiled trace and give it an entry point that doesn't actually exist. If I just knew why it was doing that...
20:30:39 -!- Oranjer has joined.
20:34:03 <AnMaster> fizzie, try gdb? But that may not help with JITing
20:37:18 <fizzie> It seems that some bit of code has been adding entry points to the trace without invalidating the compiled code. (It needs to not flush stack and not stack-fold over those, and in any case the jump table at the beginning needs to contain the new entry points.)
20:38:53 <fizzie> /*! \todo recompile if next->compiled */
20:39:04 <fizzie> Well, yes, I don't think that actually invalidates the compiled code.
20:39:15 <fizzie> Obviously I need a DWIM-capable compiler.
20:42:47 <pikhq> Segfaulting now. HOORAY.
20:44:51 <pikhq> stack_push 9, -1876564017 on stack
20:45:44 <pikhq> That's... The first stack access...
20:46:15 <pikhq> Oh, wait. stack_init is not returning a stack. XD
20:47:44 <pikhq> And the sanity check... Outputs "0 0 1 2 3 4 5 6 7 8 ".
20:51:36 <pikhq> And now mycology fails. :(
20:53:34 <oerjan> so from today's experiences we can deduce that befunge interpreters generally develop _backwards_ in time
20:54:04 <pikhq> bufsz is 0... How is bufsz 0?
20:54:09 <oerjan> (generalized from at least two examples, here)
20:54:31 <AnMaster> presumably it was set to that at some point
20:54:38 <pikhq> AnMaster: It never was.
20:54:41 <pikhq> It was initialised to 1024.
20:54:51 <pikhq> And the only thing that modifies it doubles it.
20:55:08 <oerjan> well if you double it enough times...
20:55:32 <AnMaster> <oerjan> so from today's experiences we can deduce that befunge interpreters generally develop _backwards_ in time <--- no because sanity.bf comes before mycology.b98
20:56:56 <pikhq> Yup, it's actually doubling that much.
20:57:30 <AnMaster> pikhq, it is doing something wrong then
20:57:55 <oerjan> now now, don't leap to conclusions
20:57:56 <AnMaster> pikhq, sure you didn't mix up * and ^?
20:58:36 <pikhq> AnMaster: Wrong test for when to resize the stack.
20:58:53 <pikhq> That I hope is simple.
20:59:39 <pikhq> Okay, then. Passing Mycology again.
20:59:48 <pikhq> But not mycorand.bf
21:00:23 <AnMaster> <pikhq> BAD: 0! != 1 <-- how the?
21:00:49 <Deewiant> You're the first I know of to have triggered that one.
21:00:50 <AnMaster> pikhq, how could just fixing stack underflow cause that?
21:01:01 <AnMaster> Deewiant, why did you test it then?
21:01:10 <pikhq> Deewiant: It was a typo.
21:01:27 <AnMaster> Deewiant, presumably it is a fatal error?
21:01:49 <Deewiant> AnMaster: If I tested only things that ever failed in CCBI Mycology would be less than half its current size :-P
21:02:59 <AnMaster> Deewiant, well, you seem uninterested in adding things no one fails at
21:03:36 <pikhq> And now, the prime number thing is borken.
21:03:45 <pikhq> It thinks everything is prime.
21:03:56 <Deewiant> AnMaster: In this case, since later parts of Mycology depend on !, it has to be tested.
21:04:05 <pikhq> AnMaster: I wish I knew.
21:04:22 <AnMaster> pikhq, do the other ones work? life.bf, wumpus and so on?
21:04:54 <AnMaster> Deewiant, what? If everything was prime? :D
21:06:46 <pikhq> That's a gigantic trace.
21:07:33 <AnMaster> pikhq, from cfunge it would be too, Since it implements befunge98 and that has 32-bit (or more) cells. So that program just goes on and on and on
21:09:31 <pikhq> http://sprunge.us/iZVC
21:09:56 <pikhq> AnMaster: Reversed order of arguments for %.
21:10:46 <pikhq> BTW, this no longer segfaults on pi.bf
21:10:58 <pikhq> It doesn't *do* anything, but it no longer segfaults.
21:12:50 <pikhq> Once again, though. Are there any notable Unefunge '98 programs or interpreters?
21:14:20 <pikhq> I suspect Unefunge '98 would be much easier to compile efficiently is the thing...
21:14:32 <AnMaster> pikhq, it is still selfmodifying
21:14:41 <AnMaster> and I don't know any programs in it at all
21:15:28 <pikhq> The bit about being 2-d makes things a bit harder, what with needing smart data structures and all that.
21:15:42 <AnMaster> pikhq, your current program is broken I think
21:15:54 <pikhq> Yeah. Not sure why.
21:15:58 <AnMaster> pikhq, I think read char perhaps?
21:16:17 <pikhq> Though rot13 still works.
21:17:49 <AnMaster> pikhq, this is also broken: http://sprunge.us/QVgW (fib.bf)
21:17:55 <AnMaster> (usage: give a number, hit enter)
21:18:28 <AnMaster> pikhq, that is what should happen
21:18:43 <pikhq> And what actually happens?
21:18:52 <AnMaster> oh wait, that a can be changed to 91+
21:19:01 <AnMaster> pikhq, it outputs lots of zeros
21:19:35 <pikhq> Here it does a lot of nothing.
21:20:04 -!- oerjan has quit (Quit: Good night).
21:20:08 <pikhq> Yeah, whole lot of 0s here.
21:20:54 <AnMaster> pikhq, well first changing it from a to 91+ didn't fix it
21:21:12 <AnMaster> so consider it a non-reproducible heisenbug
21:21:34 <pikhq> Wait, "a"? Ah. No wonder it does a whole lot of nothing.
21:22:13 <pikhq> Okay, then. It's just wumpus. And I got nothing.
21:22:54 <AnMaster> pikhq, trace it and compare to last working trace
21:23:24 <AnMaster> (or however you do that with hg)
21:23:29 <fizzie> It's annoying that these valgrind errors list "HeaderFileFromTheLibrary.h:1234" for an error inside my function when the error happens in an inlined function; because then it doesn't list the line number where in my function it happens.
21:23:42 <pikhq> I'll futz with it later.
21:24:18 <AnMaster> fizzie, heck valgrind should provide a bt too
21:24:52 <fizzie> AnMaster: It does provide a backtrace, but the problem is that it's an inlined function, there's no call there. In place it lists something like:
21:24:54 <fizzie> ==14642== by 0x4EA678: CodegenLLVM::compile(Trace*, TList<ImOp>*, int) (Function.h:126)
21:25:21 <fizzie> Where CodegenLLVM::compile is my function, but Function.h:126 is some inlined thing inside LLVM's Function.h header.
21:25:39 <fizzie> So it doesn't list the spot in the CodegenLLVM::compile function where the error actually happens.
21:26:34 <fizzie> gdb's backtrace somehow manages to list it properly, though, so --db-attach=yes helped.
21:30:34 <fizzie> I'm a bit unsure on how I managed to get an "Invalid write of size 8" in llvm::Function's constructor, though. It refers to a block free'd by llvm::Function's destructor earlier, but (if I understood the LLVM docs right) it should be safe to say "delete fun" where fun is a llvm::Function*; the destructor should remove all references to the function.
21:33:20 <fizzie> Perhaps it only removes all references held by the function, and I need to call fun->eraseFromParent(); instead.
21:33:22 <AnMaster> fizzie, Can't help you there. Too much C++ nonsense
21:33:30 <fizzie> "This method unlinks 'this' from the containing module and deletes it."
21:34:00 <fizzie> I'm not sure it's C++ nonsense, per se; it's more about LLVM's garbage-collection memory-handling nonsense. Which probably makes an amount of sense, I'm just very unfamiliar with it.
21:35:15 <fizzie> Yes, it fixed that particular problem at least.
21:36:39 <fizzie> There's one "Invalid read of size 1" in llvm::JIT::getPointerToFunction still, and it's from address "0x8", which "is not stack'd, malloc'd or (recently) free'd"; well, that's not a surprise, but I doubt it should refer to 0x8 anyhow.
21:37:35 <AnMaster> fizzie, you know, I would have been able to tell that you wrote that line even without the nick at front.
21:37:45 <AnMaster> Sometimes you have a very distinctive style
21:37:51 <AnMaster> can't really pinpoint what it is
21:41:24 <fizzie> %stack2 = phi i32* [ %entry_stack, %FunEntry ], [ <null operand!>, %Code11 ] ; <i32*> [#uses=1]
21:41:32 <fizzie> The <null operand!> might not be what I want.
21:43:29 <fizzie> It seems to get a bit confused if there's an entry point immediately after a _ branch.
21:49:47 <fizzie> fis@eris:~/src/jitfunge/src$ echo '(hello)S' | ./jitfunge ../underload.b98 2>/dev/null
21:49:52 <fizzie> Well, it doesn't crash...
21:51:12 <AnMaster> fizzie, that is one step forward
21:51:24 <AnMaster> fizzie, also: try mycology, it tells you when something is wrong
21:51:37 <AnMaster> it is probably saner to make it pass a bit further first
21:52:48 <fizzie> Guess so; though it's a bit of a big program, long traces to look through.
21:55:26 <AnMaster> fizzie, well getting mycology going a bit of the way should help
21:55:45 <fizzie> I guess I should at least add the , there. :p
21:59:02 <fizzie> fis@eris:~/src/jitfunge/src$ ./jitfunge ../../jitfunge_old/jitfunge/myco/mycology/mycology.b98 2>/dev/null
21:59:02 <fizzie> Segmentation fault (core dumped)
22:01:04 <fizzie> $1 = (struct llvm::Function *) 0x0
22:01:13 <AnMaster> fizzie, backtrace is useful? I'm surprised
22:01:30 <fizzie> As long as you bother stepping out of the LLVM internals, sure.
22:01:45 <AnMaster> fizzie, what if it crashes in generated code?
22:01:57 <fizzie> Then it'll probably be less helpful.
22:02:34 <fizzie> GOOD: empty stack pops zero
22:02:38 <fizzie> Segmentation fault (core dumped)
22:02:42 <fizzie> Soon it'll be too long to paste here. :p
22:03:40 <fizzie> Crashes when compiling a !.
22:04:55 <AnMaster> fizzie, for bug testing maybe you should make it always compile the trace even the first time
22:05:11 <fizzie> Do you happen to have a pasted mycology output somewhere? (Though I guess I could just run it with some real interpreter.)
22:05:25 <Deewiant> The Mycology comparison page links to .txts for reference output
22:05:47 <AnMaster> fizzie, http://sprunge.us/KFKR
22:05:47 <Deewiant> First column of the table IIRC.
22:05:51 <fizzie> Deewiant: Oh, those are links. I didn't notice. :p
22:05:58 <fizzie> I was there already, but only saw the fancy table.
22:06:52 <Deewiant> In this case I think I remember by heart that it tries 7! = 0 next
22:07:01 <Deewiant> Don't know what's after that, though.
22:07:09 <fizzie> Right; it was compiling the "7!" bit, and I had used regs[arg->value] directly, whereas I should've used get_arg_value(arg), because for the "7!" case arg->value had a constant 7 instead of a register number.
22:07:18 <fizzie> $1 = {arg = 7, c = 1 '\001'}
22:08:12 <fizzie> GOOD: 7! = 0, followed by a "Gcodegen.cc:263: [compile] not handled: 42".
22:08:35 <fizzie> Who needs to multiply numbers anyway?
22:10:33 <fizzie> Also my - instruction subtracts values the wrong way around, eh-heh.
22:10:45 <fizzie> Why didn't you make that "2-2 test unsymmetric? Didn't we talk about this?-)
22:11:01 <Deewiant> I don't know how you people manage these symmetry failures, I don't think I've ever coded one :-P
22:11:27 <fizzie> I have so many intermediate data structures, I can't be expected to remember which way I've put the arguments in there.
22:11:39 <Deewiant> Your fault for overengineering :-P
22:12:04 <fizzie> Last time I was accused of underengineering when it wasn't trivial to switch backends. :p
22:12:27 <fizzie> GOOD: # < jumps into <
22:12:27 <fizzie> Gcompiler.cc:334: [compile] unknown op in intermediate compiler: 96
22:13:02 <AnMaster> fizzie, did it compile the \ btw?
22:13:37 <AnMaster> fizzie, as I said you might want to actually compile these all the time during this phase of development
22:13:44 <fizzie> It does compile \. It doesn't generate any code for \, though.
22:13:52 <fizzie> It's just a matter of swapping register names, after all.
22:13:53 <AnMaster> fizzie, well that could be an issue
22:14:16 <fizzie> No, I mean, it doesn't need to. If there's a stand-alone \, it will create two stack pops and two stack pushes.
22:15:45 <fizzie> Actually it seems to compile out some of mycology's tests too, since the arguments to _s are constant.
22:16:27 <AnMaster> fizzie, hm. You know this will be a problem, that it won't test the "we don't know the value at all" case
22:16:36 <AnMaster> or it won't test "constant one"
22:25:09 <fizzie> There's in fact almost three different implementations for many instructions, because the intermediate-form compiler does constant-folding. It's a leftover from the non-LLVM backend days. These days I could disable all that and let LLVM's IRBuilder and/or optimizer do it directly.
22:25:23 <fizzie> ... then an infinite loop.
22:25:38 <AnMaster> fizzie, infinite loop of what?
22:25:44 -!- kar8nga has quit (Remote host closed the connection).
22:26:01 <AnMaster> fizzie, ah, so not of those two lines repeating?
22:26:09 <fizzie> No, those came just once.
22:26:16 <fizzie> "GOOD: 900pg gets 9" is supposed to come next.
22:26:40 <fizzie> Interestingly it seems to be an infinite loop not in generated code.
22:26:45 <AnMaster> fizzie, how if your fungespace implemented?
22:26:47 <Deewiant> I have an excuse for using (0,0) there, since it makes the code 6 chars shorter.
22:26:51 <AnMaster> fizzie, quad tree? hash table?
22:27:16 <Deewiant> AnMaster: Which actually matters in the Befunge-93 area.
22:27:19 <fizzie> Just a regular hash table at the moment.
22:27:44 <AnMaster> fizzie, do you generate 64 bit code nowdays?
22:28:13 <AnMaster> fizzie, and how hard would switching to that be?
22:28:29 <Deewiant> Should be pretty trivial with LLVM.
22:28:30 <AnMaster> llvm would do some of the work
22:28:41 <AnMaster> Deewiant, you still have to care about type sizes to some extent
22:28:47 <fizzie> Even the previous manual code-generator did that, with a set of 32-bit #ifdefs. Currently I think it generates 64-bit code; it's really pretty abstracted.
22:29:00 <fizzie> I use 32-bit cells currently, but that's just a two-line change.
22:29:10 <AnMaster> fizzie, hah, when I last saw the old one it was 32-bit only
22:29:32 <fizzie> Yes, there's been one or two iterations in-between, more or less borken.
22:32:04 <AnMaster> fizzie, how much easier is it using the llvm backend?
22:34:25 <fizzie> Somewhat. I can't really quantify it much. Not terribly much; I had a reasonably similar assembly-generating class in the old jitfunge, though LLVM's IRBuilder is a bit more nicer to use. And at least I don't have to spend time adding features to it whenever I need something I haven't needed before.
22:34:37 <fizzie> The infinite loop seems to be in (427, 17) with delta (-1, 0); there's a space there, and for some reason it just refuses to move on.
22:35:16 <Deewiant> One wonders why your x coordinate is so high.
22:36:29 <fizzie> Should it wrap around close to these parts? I guess it might, but not before the 900pg test.
22:36:48 <fizzie> I think my wrapping's completely untested.
22:37:00 <Deewiant> I think your wrapping won't work. ;-)
22:39:17 <fizzie> My phrasing was more gentle.
22:40:07 <fizzie> Probably; I haven't exactly figured out yet how. It might also just get lost somehow.
22:42:46 <fizzie> It enters row 17 at column 13 (from row 16), then the next traced X coordinates are: 12, 11, 9, 8, 6, 7, 8, 11, 13; then at (12,17) with delta (-1,0) it compiles something, comes out of it at (5,17) still moving backwards, traces a single $ instruction, and after that trace has been finished it suddenly is there in (427,17).
22:43:16 <fizzie> The $ there on that line looks as if it's supposed to wrap there.
22:44:02 <AnMaster> fizzie, how did it mirror there?
22:46:09 <fizzie> There's an _ at column 6; it hits that, prints something, goes to the < at 13, then enters a print loop.
22:46:33 <fizzie> That's okay so far; then it starts tracing from the _ leftwards, reads the $, and should wrap somewhere.
22:46:49 <fizzie> Instead it ends the trace and comes out of the trace function at column 427.
22:47:01 <fizzie> Yes, I guess you could call that broken, if you were so inclined.
22:49:01 <fizzie> Deewiant: The cardinal movement thing wraps by setting the X coordinate to the largest Y value. :p
22:49:44 <Deewiant> Incidentally, if your line count is 427, your Mycology is very old or you're doing something else wrong.
22:49:56 <fizzie> ../../jitfunge_old/jitfunge/myco/mycology/mycology.b98
22:50:03 <Deewiant> There are bugfixes in the new ones, you know? :-P
22:50:28 <fizzie> Well, now, at least this looks interesting:
22:50:40 <fizzie> GOOD: instructions between ; are skipped
22:51:05 <pikhq> y'might want to check out the latest.
22:51:31 <fizzie> Have to go to sleep, wake-up time at something like 05am "tomorrow"; will continue this hilariosity later.
22:51:52 <Deewiant> fizzie: Now that you're around k, bear in mind that that Mycology will probably disagree with the current one about it.
22:52:07 <Deewiant> At least I think that 427 lines implies somewhere around release one or two.
22:52:26 <Deewiant> Hell, I might not have something that old under revision control.
22:52:27 <fizzie> I'll get a new one, don't you worry. Though the GGBG and BUBAD lines are what I'll look at first.
22:52:52 <Deewiant> It should say "Befunge-98 detected" and stuff before it goes to a.
22:53:25 <fizzie> Just for fun, I'll try the newest one too.
22:54:04 <fizzie> Well, no changes so far; it's still GGBG BUBAD. I guess you haven't changed this early bits significantly.
22:54:30 <Deewiant> (Maybe not at all up to that point.)
23:00:47 <pikhq> I think from this we can learn that Befunge is just plain hard to implement at all.
23:01:16 <Deewiant> There's a bit of a gap between "implement" and "JIT compile"
23:01:39 <pikhq> Yeah, but even B93 gave me some trouble. :P
23:02:02 <pikhq> Granted, what I was doing *was* a not-very-good threaded code compiler. But still.
23:02:37 <Deewiant> Half your problem was writing threaded code in C the first time around :-P
23:14:30 -!- tombom_ has quit (Quit: Leaving).
23:50:27 -!- MizardX has quit (Ping timeout: 276 seconds).