--- Log opened Mon Mar 17 12:20:15 2014
12:20 -!- matches [matches@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
12:20 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
12:20 -!- Irssi: Join to #ipdf was synced in 0 secs
12:20 -!- sulix changed the topic of #ipdf to: Angry Strawberry Summer
12:20 -!- mode/#ipdf [+o matches] by sulix
12:39 <@sulix> This is sensible discussion about the project.
12:39 <@matches> The suspense
12:39 <@sulix> Anyone up for lunch?
12:39 <@matches> Yes
12:40 <@sulix> drumroll...
12:41 <@matches> I don't think it worked
12:42 <@matches> Yes I did it manually
12:42 <@matches> Maybe cron is broken on motsugo
12:43 <@sulix> We shall find out next time at 12:40, I guess.
12:43 <@sulix> (Or the next time cron emails errors out, maybe)
12:52 <@matches> Let the record show that it didn't work because I didn't install the crontab
--- Day changed Wed Mar 19 2014
10:59 <@matches> Some guy asked me if he could use the whiteboard, so I let him rub out our timeline
10:59 <@matches> And all he did was write "hello world"
10:59 <@matches> >:(
19:10 <@matches> Testing
19:25 <@matches> So the IRC commits should have a different author
19:25 <@matches> So that I don't get a ridiculous number of daily IRC commits
19:26 <@matches> I could rebase the first three of them but I think that might break things
19:45 <@matches> Ok, and now it will only commit when there is more than one new line, so we won't get one every day when no one says anything
19:54 <@matches> Alright, and in theory
19:54 <@matches> If I spam this some more
19:54 <@matches> There will be a commit soonish
19:56 <@matches> Any second...
19:56 <@matches> Yes
19:56 <@matches> Now that is sorted out I can attain maximum productivity
19:56 <@matches> (Sorry)
--- Log closed Mon Mar 24 01:12:25 2014
--- Log opened Mon Mar 24 08:40:12 2014
08:40 -!- matches [matches@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
08:40 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
08:40 -!- Irssi: Join to #ipdf was synced in 3 secs
13:26 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
13:27 < matches> Uh oh
13:29 -!- Netsplit over, joins: @sulix
13:31 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
13:32 -!- Netsplit over, joins: @sulix
13:40 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
13:40 -!- Netsplit over, joins: @sulix
16:19 < matches> Well that will make a nice automatic commit
--- Day changed Tue Mar 25 2014
21:33 < matches> So, I am pretty much free all day tomorrow
21:33 < matches> Also Thursday
21:34 <@sulix> I'm pretty busy Thursday, but I'm free all tomorrow so long as I can get some maths done at some point.
21:34 -!- mode/#ipdf [+o matches] by sulix
21:35 <@matches> I'm supervising a test from 2-3pm but that's it
21:35 <@matches> So, I will try and get to UWA as early as I can
21:35 <@matches> It might be a good idea to have some kind of start on a code base
21:35 <@matches> Even though we're supposed to be focusing on a literature review, I don't really like not having any code done yet
21:36 <@sulix> Yeah. I agree.
21:36 <@sulix> Code + fixing git stuff + preparing for this "talk" on Friday.
--- Day changed Wed Mar 26 2014
11:32 <@matches> I am in the super secret room
11:36 <@sulix> Okay, I'll head in shortly. Had a small "parents fell for a scam email and entered passwords on dodgy websites" crisis here this morning.
11:37 <@matches> Oh dear
11:42 <@matches> The phone is ringing :O
11:43 <@matches> Phew, it stopped
22:42 <@matches> I think I have a way to do tests in the Makefile without using cmake
22:42 <@matches> You can alter a variable for a target
23:20 <@matches> Well, that ended badly
23:21 <@matches> With me erasing my own Makefile using make
23:21 <@matches> :P
23:24 <@sulix> Better than erasing the source code, I guess.
23:34 <@matches> This is why we have git
--- Day changed Thu Mar 27 2014
00:15 <@sulix> Crazy templated loading and saving!
00:15 <@sulix> And now for bed!
00:30 <@matches> Well
00:30 <@matches> It doesn't break the test
01:22 <@matches> We now have an arbitrary precision float
01:22 <@matches> Where in this case arbitrary precision means I have no idea what the precision is but it is very bad
01:35 <@matches> Ok I think I made a half precision float
01:35 <@matches> They are quite bad
01:36 <@matches> Um, I can probably make a graph of it being terrible as my contribution for Friday
01:36 <@matches> Assuming I've done it right
--- Day changed Wed Apr 02 2014
09:41 <@matches> Dammit codejam is coming up again
09:41 <@matches> There goes productivity
09:42 <@matches> If you are not busy this afternoon we should do work
09:42 <@matches> On the project I mean
09:45 <@matches> Although it is tempting to just practice codejam problems for the next week
12:44 <@matches> If I work on the project it will help when the inevitable "64 bits is not enough" problem comes up!
12:45 <@matches> Maybe
--- Day changed Sun Apr 06 2014
13:40 <@matches> I get the feeling my part of the project could just be "typedef Real to something from boost"
14:15 <@matches> I suppose I could talk about FPU and hardware
--- Day changed Mon Apr 07 2014
21:42 <@matches> I had a horrible horrible thought... implement a FPU in VHDL and then somehow run all our floating point operations on it :P
21:42 <@matches> (This is not a good idea at all but it might be fun)
21:42 <@matches> You know, for some definition of fun
21:44 <@matches> So my lit review will probably be 1) We need higher precision documents because science (Pixels or Perish) 2) This is how FP works in hardware 3) This is how you can get higher precision in software
21:45 <@matches> Oh, and 4) Document formats and rendering them (PDF/PostScript etc)
21:46 <@matches> That is starting to sound suitably ridiculously broad?
21:46 <@matches> Can always cut things out I guess
21:47 <@matches> To reflect what we actually end up doing
22:05 <@sulix> From what Tim was saying, I don't think "too broad" is a possibility.
22:05 <@sulix> We could be talking about Aztec history and it'd probably not be "too broad."
22:05 <@sulix> I do need to remember to read "Pixels of Perish," though.
22:19 <@matches> I'll have a look into VHDL stuff, there seem to be compilers and simulators for linux
22:20 <@matches> For a minute I was afraid I'd have to use the UWA EE VHDL environment
22:20 <@matches> Which is like, running a Java program in a Windows XP VM
22:20 <@matches> I heard you liked simulations of hardware so I simulated some hardware in your simulated hardware
--- Day changed Tue Apr 08 2014
10:46 -!- Netsplit arctic.uniirc.com <-> mits.mits.au.uniirc.com, services.uniirc.com, irc.cassa.au.uniirc.com, mussel.ucc.au.uniirc.com quits: @sulix
10:46 -!- Netsplit over, joins: @sulix
11:31 <@matches> The "Experiment Running" sign seems to have worked
11:31 <@matches> Also open source VHDL stuff is less "actually compiles" than I had hoped
11:32 <@matches> The two I've tried so far seem to generate absolute monstrosities of C or C++ files and then fail to compile and/or link
--- Day changed Wed Apr 09 2014
15:27 <@sulix> So I've been hitting my head against my desk for about half an hour trying to work out where some bugs were in some ipdf code I'm writing.
15:27 <@sulix> Turns out to have mostly been precision issues due to the lack of precision in your Real data type.
15:28 <@sulix> Switching it to double fixes them all.
15:32 <@matches> Oh
15:32 <@matches> Sorry
15:37 <@sulix> Nah: it's good. It means that precision actually is important!
15:37 <@sulix> (I was getting a little bit concerned for a while :P)
15:40 <@matches> Well
15:40 <@matches> I have rediscovered just how awful VHDL is
15:41 <@matches> It seems like you can't define anything without typing it three times
15:42 <@matches> You define an entity
15:42 <@matches> Then you define a component with identical ports
15:42 <@matches> Then you tell it to use the entity for that component
15:42 <@matches> Then you tell it to map the identical ports to the entity ports
15:42 <@matches> adder_0 : adder port map (a=>a, b=>b, cin=>cin, s=>s, cout=>cout);
15:44 <@matches> Pretty much all the hardware papers I found talk about using VHDL for things
15:46 <@matches> Let's see if I can make any sense of this jop-devel thing that appears to be a JVM implemented in VHDL
15:47 <@matches> Uh oh, .bat files
15:48 <@matches> This looks ominous
15:51 <@sulix> The whole swapping out main thing breaks the makefile in a few ways btw.
15:51 <@sulix> Because none of main.cpp's dependencies are listed.
15:51 <@matches> Ah
15:51 <@sulix> So if you change main.h, nothing gets recompiled.
16:02 <@sulix> Okay, just pushed support for click+drag and zoom in and out in the viewer.
16:03 <@sulix> (I did change the default precision to single, rather than half, as zoom out was totally broken with half-precision)
16:05 <@matches> The half precision implementation is broken itself anyway
16:07 <@matches> Hmm
16:07 <@matches> I can't seem to compile anymore
16:07 <@matches> Hang on
16:07 <@matches> That would be because `uname -i` reports "unknown"
16:12 <@matches> I have made unknown default to x86_64 :S
16:13 <@matches> I can see the precision issues! Good work
16:14 <@matches> These lecture notes seem useful: http://www.cs.berkeley.edu/~demmel/cs267/lecture21/lecture21.html
16:14 <@matches> Lecture notes > Blog post in terms of suitable reference?
16:16 <@sulix> It's got fortran in it, it must be suitably acedemic.
16:18 <@matches> Haha
16:18 <@matches> The VHDL compiler I am experimenting with uses Ada
16:18 <@sulix> I'm getting my fill of new languages by trying out some c++11 features.
16:20 <@sulix> I think I broak realtofloat by changing things to be single precision by default.
16:22 <@sulix> (Hopefully fixed)
16:49 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
16:49 -!- Netsplit over, joins: @sulix
16:54 <@matches> What's with the netsplits
16:55 <@matches> You're on mussel? I'm on mantis? They are VMs on the same host?
16:55 <@matches> I don't know what this uniirc nonsense is
16:56 <@matches> What is "arctic"
16:56 -!- matches changed the topic of #ipdf to: Happy Bannana Netsplit
17:33 <@matches> Well I compiled the VHDL FPU
17:33 <@matches> It seems to work quite well
17:33 <@matches> Except for the part where it never actually finishes an operation
17:34 <@matches> One of the virtual transistors must have overheated
17:43 <@matches> Oops it might help to actually give it a valid operation
18:27 <@matches> Alright, so I'm going to experiment with getting our Real operations to run on the virtual FPU
18:28 <@matches> Then I can look into both hardware and software ways of getting arbitrary precision.
18:30 <@matches> VHDL appears to have text I/O so I could make everything read and write from pipes, but this seems like a terrible idea
18:30 <@matches> On the other hand the compiler is using Ada
19:21 <@matches> Oh wow
19:21 <@matches> To open stdout
19:22 <@matches> You pass it a string "STD_OUTPUT" for the filename
21:40 <@matches> Ok, I give up trying to link this thing
21:40 <@matches> fork() and exec() is seeming more and more elegant
22:11 <@matches> Nooo, buffering
22:11 <@matches> Ok, screw this
--- Day changed Thu Apr 10 2014
00:00 <@matches> Note: Actually exec'ing the program instead of just going straight to "exit(EXIT_FAILURE)" is generally important
00:00 <@matches> Wall of text commit message incoming
00:01 <@matches> Horribly inefficient interface to virtual FPU sort of implemented
00:02 <@matches> I would have made it based on binary read/write rather than hex strings but I could not work out how to do that in VHDL
00:08 <@matches> I still can't believe what I have just done, it seems ludicrous
00:08 <@matches> Using an entire executable and stdio operations
00:08 <@matches> To do a floating point addition
00:10 <@matches> You should see how much is involved in compiling the VHDL FPU...
00:11 <@matches> I'm very pleased that it actually compiled from the version in jop's github without much effort, but still
00:11 <@matches> It's like 30 object files
00:11 <@matches> This is why it isn't in the code repo
00:19 <@matches> Whoops, there are some blatantly wrong comments in vfpu.cpp
00:19 <@matches> Oh well
--- Day changed Fri Apr 11 2014
13:38 <@matches> Warning! I am about to make a ipdf/vfpu repo
13:43 <@matches> You know what's really cool
13:43 <@matches> You can run it as `vfpu --vcd=output.vcd`
13:43 <@matches> And it will create a gtkwave file as it runs showing all the operations
13:44 <@matches> You only get the simulated time from the point of view of the device
13:44 <@matches> Which is probably useful
13:46 <@matches> Or it would be if I wanted to compare different devices
13:47 <@matches> To do that I need to actually make different devices...
17:12 <@matches> Would you prefer seperate repos for the individual reports or just sub directories in the documents repo?
17:12 <@matches> I can't decide
17:12 <@matches> On the one hand 5+ repos is getting a bit out of hand
17:12 <@matches> On the other hand they are individual work
17:24 <@matches> Individual seems best
20:31 <@matches> Hmm
20:31 <@matches> The sqrt op in the fpu appears to have been commented out
20:31 <@matches> Also despite having constants for the sizes of things they have just used magic numbers everywhere
20:34 <@matches> I need an IRC script to prevent myself from saying stuff unless someone else has said things, or this channel will just be me ranting
--- Day changed Mon Apr 14 2014
13:42 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
13:43 -!- Netsplit over, joins: @sulix
14:42 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
14:43 -!- Netsplit over, joins: @sulix
18:32 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
18:32 -!- Netsplit over, joins: @sulix
18:34 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
18:35 -!- Netsplit over, joins: @sulix
18:36 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
18:38 -!- Netsplit over, joins: @sulix
18:40 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
18:41 -!- Netsplit over, joins: @sulix
18:41 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
18:43 -!- Netsplit over, joins: @sulix
18:45 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
18:45 -!- Netsplit over, joins: @sulix
18:46 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
18:47 -!- Netsplit over, joins: @sulix
18:54 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
18:56 -!- Netsplit over, joins: @sulix
18:59 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:00 -!- Netsplit over, joins: @sulix
19:03 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
19:04 -!- Netsplit over, joins: @sulix
19:07 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
19:08 -!- Netsplit over, joins: @sulix
19:10 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:10 -!- Netsplit over, joins: @sulix
19:13 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:13 -!- Netsplit over, joins: @sulix
19:15 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:15 -!- Netsplit over, joins: @sulix
19:17 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:18 -!- Netsplit over, joins: @sulix
19:21 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
19:22 -!- Netsplit over, joins: @sulix
19:23 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
19:23 -!- Netsplit over, joins: @sulix
19:26 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:26 -!- Netsplit over, joins: @sulix
19:27 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:29 -!- Netsplit over, joins: @sulix
19:30 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
19:31 -!- Netsplit over, joins: @sulix
19:32 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:35 -!- sulix [sulix@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
19:35 -!- ServerMode/#ipdf [+o sulix] by mussel.ucc.au.uniirc.com
19:40 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:42 -!- Netsplit over, joins: @sulix
19:44 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:48 -!- sulix [sulix@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
19:48 -!- ServerMode/#ipdf [+o sulix] by mussel.ucc.au.uniirc.com
19:54 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:54 -!- Netsplit over, joins: @sulix
19:54 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:54 -!- Netsplit over, joins: @sulix
19:55 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:56 -!- You're now known as 13VAAAAGJ
19:56 -!- Netsplit over, joins: @sulix
19:57 <@13VAAAAGJ> Why am I now known as 13VAAAAGJ
19:57 <@13VAAAAGJ> WHAT THE FUCK IS GOING ON
19:57 <@13VAAAAGJ> ARE WE UNDER ATTACK
19:57 <@13VAAAAGJ> Oh crap this is #ipdf
19:57 <@13VAAAAGJ> Um, disregard this bit of the totally project related conversation
19:57 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
19:57 <@13VAAAAGJ> I'd edit the commit script to censor the swear words, but effort
19:57 <@13VAAAAGJ> Oh dear
19:57 -!- Netsplit over, joins: @sulix
19:57 <@13VAAAAGJ> Hello
19:58 <@13VAAAAGJ> I think mantis might be dying?
19:59 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
20:00 -!- Netsplit over, joins: @sulix
20:01 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
20:01 -!- Netsplit over, joins: @sulix
20:04 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
20:04 -!- Netsplit over, joins: @sulix
20:05 <@13VAAAAGJ> Sigh
20:07 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
20:07 -!- Netsplit over, joins: @sulix
20:08 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
20:08 -!- Netsplit over, joins: @sulix
20:08 -!- Netsplit mantis.ucc.au.uniirc.com <-> arctic.uniirc.com quits: @sulix
20:09 -!- Netsplit over, joins: @sulix
20:09 -!- Netsplit arctic.uniirc.com <-> mussel.ucc.au.uniirc.com quits: @sulix
20:10 -!- Netsplit over, joins: @sulix
--- Log closed Mon Apr 14 20:11:29 2014
--- Log opened Mon Apr 14 20:18:05 2014
20:18 -!- matches [matches@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
20:18 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
20:18 -!- Irssi: Join to #ipdf was synced in 0 secs
22:04 < matches> Ergh
22:06 < matches> http://szmoore.net/ghdl.bug
22:06 < matches> Pretty
22:10 < matches> Looks like we'll be sticking with ASCII input files for the FPU
--- Log closed Mon Apr 14 22:29:33 2014
--- Log opened Mon Apr 14 22:44:34 2014
22:44 -!- matches [matches@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
22:44 -!- Irssi: #ipdf: Total of 1 nicks [1 ops, 0 halfops, 0 voices, 0 normal]
22:44 -!- sulix [sulix@motsugo.ucc.gu.uwa.edu.au] has joined #ipdf
22:44 -!- Irssi: Join to #ipdf was synced in 12 secs
22:53 <@matches> Someone's VPS was compromised and killing our network
22:53 <@matches> For reference
22:53 <@matches> It affects this project because
23:07 <@matches> Argh
23:07 <@matches> So I thought I was being really clever
23:07 <@matches> I had files of type "bit" and everything
23:07 <@matches> Guess how a "bit" is represented...
23:08 <@matches> It's an ASCII "0" or "1"
23:09 <@matches> I guess I will just conclude that ASCII strings treated as hex is the only way
--- Day changed Wed Apr 16 2014
00:10 <@matches> I'm either about to perpetrate horrible things on your nice View class or give up and go to sleep
00:28 <@matches> Yeah... the problem is if we want to overlay objects rendered using different precision's over each other
00:28 <@matches> It leads towards templates
00:29 <@matches> And templates lead towards fear
00:29 <@matches> And fear leads towards anger
00:29 <@matches> And anger leads to hate
00:29 <@matches> I think
00:29 <@matches> Saving an image
00:29 <@matches> Recompiling the program
00:29 <@matches> Overlaying the image
00:29 <@matches> Is going to lead to less hate
00:30 <@matches> Otherwise pretty much every occurance of "Real" needs to be come a template
00:50 < sulix> So there are a couple of problems with doing that.
00:51 < sulix> - You'd need some way of storing objects of different precision. Possibly an extra "high-precision bounds" struct.
00:51 < sulix> - View also uses real for its internal bounds, which is where many of the problems appear.
00:52 < sulix> (I guess you could have a "high-precision viewport" as well.)
00:52 < sulix> - The actual upload of graphics data to OpenGL is done as 32-bit floats, no matter the type of real, as that's all OpenGL supports.
00:53 < sulix>   (At some point we'll have to actually do some view transforms on the CPU rather than just passing all of the bounds and viewport straight to OpenGL)
01:02 <@matches> Yeah I don't want to replace Real with templates
01:02 <@matches> That'd be horrible
01:03 <@matches> By the way, the introduction of SDL_Renderer in SDL2 is confusing
01:05 <@matches> I thought it was replacing Surface with Renderer and Texture
01:05 <@matches> But Surface seems to still be a thing
01:13 < sulix> Yeah: basically Surfaces are in CPU memory, textures in GPU memory.
01:13 <@matches> Right
01:14 <@matches> And renderers magically put stuff on surfaces/textures
01:14 < sulix> Yeah.
01:14 < sulix> So it basically represents the graphics card.
01:15 < sulix> But if you want to just use OpenGL yourself, you don't need to create a renderer at all.
01:15 <@matches> Ah, but the plot thickens
01:15 <@matches> I'm saving the window to a bmp
01:16 <@matches> Which requires a renderer
01:16 < sulix> Hmm... I'm not sure if that will work.
01:16 <@matches> It does
01:16 <@matches> It seems rather convoluted though to be honest
01:16 < sulix> (In theory, it shouldn't, but it probably actually does)
01:16 <@matches> I seem to remember it not being this convoluted in SDL1.2
01:16 <@matches> -_-
01:16 <@matches> So the procedure is
01:17 <@matches> 1. Get a surface associated with the window
01:17 <@matches> 2. Allocate buffer of unsigned char for the pixels
01:17 < sulix> Yeah, TBH I prefer SDL1.2's rendering API, but I generally just use OpenGL anyway.
01:17 <@matches> 3. Get renderer from the window (NB: Don't use SDL_CreateRenderer, only the (undocumented) SDL_GetRenderer works because the Window already has a Renderer because it has been created with an OpenGL flag)...
01:18 < sulix> In theory we should probably use glReadPixels.
01:18 <@matches> 4. Use the magical renderer power to put pixels into the pixel array
01:18 <@matches> 5. Create an RGB surface from the pixel array
01:18 <@matches> 6. Now you can call SDL_SaveBMP, congratulations
01:18 <@matches> What's this about a glReadPixels
01:18 <@matches> I was just about to commit this
01:19 < sulix> Well, you can use glReadPixels instead of steps 1,3 and 4.
01:19 < sulix> (This is what SDL is doing behind the scenes)
01:20 < sulix> Unfortunately, the SDL wiki is still down thanks to heartbleed. :/
01:20 <@matches> :O
01:20 <@matches> It was up when I looked at it before
01:20 <@matches> Throwing python exceptions when I tried the search function though
01:21 < sulix> Ryan said that it was up, but I'm still getting revoked certificate errors.
01:22 <@matches> Hmm, I needed to do step 1 in order to know the size of the pixel array in step 2...
01:23 < sulix> Screen::ViewportWidth(), Screen::ViewportHeight()
01:26 <@matches> Yeah this is looking a lot shorter than what I had
01:33 <@matches> It doesn't seem to work though
01:35 <@matches> I'm getting a segfault
01:35 <@matches> And of course valgrind automatically exits when it gets more than 1000000 errors from the flgrx driver
01:38 <@matches> First call to glReadPixels is OK but the bmp is just white, second call segfaults
01:39 < sulix> Hmm... what's the call?
01:44 <@matches> Segfault was due to me forgetting about the pixels needing 4 bytes for RGBA
01:44 <@matches> Still white though
01:45 < sulix> (That was going to be my guess)
01:45 <@matches> The advantage of getting the SDL_Surface
01:45 <@matches> Was that you just pass all the surf->format->format->stuff
01:45 <@matches> Everywhere
01:45 <@matches> Also makes it rather verbose
01:46 < sulix> The white screen might just be an fglrx bug.
01:46 <@matches> There we go
01:47 <@matches> No, it helps to remember that the pixels need 4 bytes for RGBA
01:47 <@matches> I have very selective memory
01:47 <@matches> I had to remember it for each line individually
01:47 <@matches> Right I guess it is slightly nicer now
01:47 <@matches> Although it has a bunch of magical "*4" everywhere
01:48 <@matches> I'm going to put this on Stack overflow as an alternative to the answer I was originally following
01:48 < sulix> Well, I'm going to attempt to sleep...
01:48 <@matches> Thank you for fixing my bug without seeing it :S
01:49 < sulix> I have far too much experience breaking glReadPixels...
01:53 <@matches> We need an easy way to compare our document rendering the same thing using a different Real and/or view representation
01:53 <@matches> Templates would only solve changing the Real and really they probably wouldn't actually solve it
01:53 <@matches> They'd just create nightmares
01:53 <@matches> Hmm
01:55 <@matches> Um
01:55 <@matches> Just looking at View::Render
01:55 <@matches> Why is there a seperate loop for each type of object...
01:56 <@matches> With "continue" statements for the other types in each loop
01:56 <@matches> Is this so you can just make one call to glBegin and glEnd...
01:56 <@matches> I am suitable scared
01:57 <@matches> suitably scared and also suitable scared
22:05 <@matches> Ok, trying again. This is the sort of thing a template is supposed to be used for... I just seem to always end up suddenly having to make everything all the way back to Document into a template class :S
22:07 <@matches> blergh
22:07 <@matches> trying again
22:07 <@matches> After getting coffee
22:07 <@matches> I think
22:30 <@matches> Ok, templates is way too complicated
22:30 <@matches> I am going to do the following instead:
22:31 <@matches> 1. Allow a "save this region to bmp" argument
22:31 <@matches> 2. It reads the specified bmp, saves a new bmp with the current view overlayed in a different colour or something
22:32 <@matches> 3. Makefile hacks to recompile the program using a different typedef of Real and then do 1. and 2. for them all
22:32 <@matches> 4. Realise I probably should have used templates
23:02 <@matches> So, according to my timeline that I haven't looked at since submitting the proposal, I will have done a draft literature review by tomorrow...
23:02 <@matches> Hah
--- Day changed Thu Apr 17 2014
00:26 <@matches> I am not good at OpenGL/SDL
00:26 <@matches> I am the master of producing a black screen
00:26 <@matches> Also we have FILLED and OUTLINE the wrong way round still
14:01 < sulix> Bunch of bugfixes incoming.
14:01 < sulix> I'm not proud of what I did to glReadPixels, but it works.
14:02 <@matches> Uh oh
14:02 <@matches> I just worked it out!
14:03 <@matches> The dreaded merge begins
14:03 <@matches> I'm tempted to just delete my changes and merge yours but I should probably do a real merge
14:04 <@matches> I fixed it (on my machine at least) by: Using GL_BGRA instead of GL_RGBA (should probably detect which one to use from the screen's format)
14:04 <@matches> And calling glReadBuffers and glPixelStorei before glReadPixels
14:05 < sulix> glPixelStorei is probably nicer than what I'm doing.
14:05 < sulix> I tried just giving SDL a negative pitch and a pointer to the bottom-right corner of the buffer, but somehow it didn't like that much.
14:07 <@matches> You do actually check the byte order which is good
14:08 <@matches> I worked that out but basically just changed it to match my machine :S
14:08 < sulix> There are a bunch of endian problems in the load-save code anyway if we want it to run on big-endian machines.
14:09 < sulix> (Well, big-endian documents don't load with little-endian code and vice-versa)
14:10 <@matches> http://szmoore.net/ipdf/code/src/screen.cpp
14:10 <@matches> Is the merge
14:10 <@matches> Which one is better?
14:11 < sulix> I think yours will still get the bitmaps upside down?
14:11 <@matches> Ah yes they do tend to be upside down
14:12 < sulix> I'm not sure you should need the front buffer stuff anymore with mine, so if you just keep mine (which is doing the flipping), everything should work.
14:12 <@matches> Woah you fixed the FILLED vs OUTLINE
14:12 < sulix> I did test overlaying bitmaps and it was fine.
14:12 <@matches> Good
14:12 <@matches> Does this seem like a better way to compare approaches than using a template and having View<float> View<double> etc?
14:13 <@matches> It means recompiling
14:13 <@matches> But it means a lot less templates
14:13 <@matches> Pretty much the entire thing has to be templatified that way
14:13 <@matches> And then there's the issue of what type the document is saving with
14:13 < sulix> I think, long term, it'd be worth just extending the view to have a "bounds" and a "high_precision_bounds" or something.
14:14 < sulix> But that is kind-of ugly.
14:14 <@matches> I think it's probably nicer to just have real.h contain nothing but a typedef
14:14 <@matches> And just recompile with a different typedef and overlay the images
14:15 < sulix> Yeah, but there are some artefacts that really show better in motion, so it's probably worth supporting that at some point.
14:15 <@matches> True
14:15 <@matches> But including a video in the pdf will be difficult anyway
14:16 < sulix> (Clearly, we should add embedded videos to ipdf)
14:16 <@matches> You could also make a movie using ffmpeg
14:16 <@matches> Haha
14:16 < sulix> (I've got some OpenGL video playback code somewhere...)
14:17 <@matches> In fact, if you can output a video you can just overlay two videos
14:17 < sulix> Oh... my... god!
14:17 <@matches> I don't know if there's a better way to make a video but I'd just be saving a .bmp every frame and then combine them all with fmpeg
14:17 < sulix> Nope, that's probably a good way.
14:18 < sulix> With some MAGIC it wouldn't even be slow.
14:20 <@matches> Whoops your code isn't giving me a second bmp anymore
14:20 <@matches> At least, not one that has pixels that aren't white
14:20 <@matches> Does my glReadBuffer thing work for you?
14:21 < sulix> Hmm...
14:21 <@matches> Can fix the upside-downness some other way
14:21 < sulix> Did you make clean
14:21 < sulix> Because main.cpp/main.h won't recompile otherwise.
14:21 < sulix> And I moved the glClear() calls.
14:22 <@matches> I did make clean
14:22 < sulix> Which is a less hacky way of solving the problem than reading the front buffer.
14:23 <@matches> So the problem is that the texture rendered by Screen::RenderBMP isn't in the buffer that glReadPixels reads from?
14:23 <@matches> (Even though it gets shown on the screen fine)
14:25 < sulix> Hmm... it works fine here with or without glReadBuffers.
14:27 < sulix> Try changing it to save the screenshot before calling scr.Present() in main.h
14:29 <@matches> That works
14:29 <@matches> But why?
14:29 < sulix> Because when you call Present(), it allocates a new buffer to render into.
14:30 <@matches> Right
14:30 < sulix> This is so that you can start rendering the new frame immediately, rather than having to wait for the window manager to actually re-render the screen.
14:31 <@matches> I have merged it
14:33 < sulix> Excellent.
14:33 < sulix> This is much more fun than literature!
14:33 <@matches> :S
14:35 <@matches> It's important
14:35 <@matches> It's part of the timeline
14:35 <@matches> Just you know
14:35 <@matches> It comes after the Literature Review
14:37 < sulix> Strictly speaking the Lit Review deadline is past, now, isn't it... :/
14:38 <@matches> Well technically it was never a deadline for me... :P
14:38  * sulix sighs
14:38 < sulix> I'm special.
14:39 <@matches> I need to read that last paper on FPUs more
14:39 <@matches> It was talking about how there are all these software techniques from the 1960s that can actually be done on the FPU itself
14:40 <@matches> I'll probably just work on getting our / jop's FPU working for different sized floats instead
14:40 <@matches> In theory that will teach me how they actually work
14:40 <@matches> Then I can actually understand the papers
14:40 < sulix> But can you write about it in a Lit Review?
14:42 <@matches> Maybe not so much the Lit Review, but it means I can write the Background section that explains how they work
14:43 <@matches> There's probably some early papers on them that I can reference at the same time if I try hard enough to find them
14:44 <@matches> The modern papers all have a lot of assumed knowledge
15:59 <@matches> Instead of reading papers I have progressed towards compiling different types and then overlaying them
16:02 <@matches> I didn't know you could do such cool things with Makefiles and flags to the compiler
16:02 <@matches> If people knew more about this maybe we wouldn't have to have python
16:03 <@matches> I will learn to do all my highlevel programming using Make
19:48 <@matches> Our Render/Screenshot combo for overlaying bitmaps and $$$ only works the first time it is done
19:49 <@matches> Or maybe it's RenderBMP that only works once
19:49 <@matches> Hmm
19:52 <@matches> I swear the format was BGRA earlier and now it's RGBA
19:53 <@matches> This can probably get fixed after some Literature Review
20:09 <@matches> Anyway you can now set the type of Real with `make DEF=-DREAL=X`
20:09 <@matches> Or `make single` and `make double`
20:09 <@matches> 0 and 1 respectively
20:09 <@matches> I tried a little bit too hard to get it working with actual C strings
21:32 <@matches> Minutes now have less "~*" in them
21:32 <@matches> Wrong channel
21:32 <@matches> Very wrong channel