23:41 < matches> I guess apt decided to remove it as part of apt-get autoremove in its infinite wisdom
23:41 <@sulix> I have decided to never call apt-get autoremove.
23:42 <@sulix> If at any point there are too many old packages for me to get things done, I'll just reinstall the OS entirely.
+--- Day changed Mon Jul 07 2014
+08:40 < matches> I try to avoid it, but sometimes apt won't let me do anything because it would break some dependency
+08:40 < matches> Although usually even after I run autoremove it complains
+08:41 < matches> Had to use aptitude to fix my "You can'd have kde-runtime!" issues
+08:45 < matches> Anyway wolfram alpha says that example +45,10 - +128 == +18446744073709551533,9
+08:45 < matches> is correct
+08:45 < matches> Checking the algorithm using 8 bits it should work too
+08:46 < matches> So it works as long as you supply the leading zeros...
+08:46 < matches> (On that particular case...)
+08:48 < matches> I hope it's not interpreting Arbint(128L) as Arbint(128u, ...)
+08:48 < matches> Nope sanity seems to prevail there
+08:50 < matches> Ah
+08:50 < matches> Ok
+08:50 < matches> First bug of the day: The subtracted argument needs to be resized
+08:50 < matches> As I am doing (45,10) - (128)
+08:59 < matches> :O
+08:59 < matches> I passed the realops test
+09:00 < matches> And it's also a lot faster now!
+09:00 < matches> Probably because the subtraction bug meant it was spending a long time in division to get the wrong result
+09:01 < matches> Yeah it should have been obvious division can't have been that slow for numbers starting at 64 bits since it does at most as many iterations as the number of bits
+09:01 < matches> Oh well
+09:02 < matches> Should probably not celebrate just yet, now the bezier looks really wierd again
+09:04 < matches> Ok
+09:04 < matches> Actually compiling with Real == Rational<Arbint> might be a better test
+09:04 < matches> But it still passes
+09:05 < matches> In particular it passes with Arbints where int64_t fails horribly
+09:05 < matches> So something is right
+09:05 < matches> Just not all of it...
+09:08 < matches> The GPU rendering seems to workish
+09:09 < matches> We really quickly end up with Arbints of size 30 digits or so :S
+09:09 < matches> Which is big enough to give an overflow in doubles I think
+09:10 < matches> Rational::ToDouble can probably be written as double(integer division) + Rational(remainder, quotient).ToDouble()
+09:10 < matches> (With some things to stop it recursing infinitely)
+09:20 < matches> Or even double(integer division) + double(remainder)/double(quotient)
+09:20 < matches> I don't think any recursion is needed
+09:22 < matches> Oh, there's a "pow" call that is probably broken
+09:24 <@sulix> Yeah, I feel the growing quickly is just a fact of life.
+09:25 <@sulix> Perhaps changing the zooming to avoid coprimes or something.
+09:27 <@sulix> I'm pretty certain that about 3 seconds of zooming is enough to make us need precision and range to match measuring the size of the visible universe in Planck lengths, too.
+09:28 <@sulix> "New biggest Arbint of size 173"
+09:28 <@sulix> and counting...
+09:34 < matches> haha
+09:34 < matches> There are more issues I spotted with add and subtract
+09:34 < matches> Basically you have to add the leading zeros - all of them
+09:35 < matches> My patch only simulates adding one leading zero
+09:35 < matches> Actually maybe I don't need to add them all, just enough until the borrow becomes zero
+09:36 < matches> But whatever
+09:36 < matches> If you're left with a borrow you can't assume that subtracting it from the next digit won't cause a borrow as well
+09:37 < matches> Realops is not a good enough tester
+09:42 <@sulix> Surely if there's borrow bit, subracting it from zero will always give another...?
+09:42 < matches> You only need as many as there are digits in your number
+09:42 < matches> At most
+09:42 < matches> If you still have a borrow at the end
+09:42 < matches> That means the result is negative
+09:43 <@sulix> Yeah, that's what I thought: you need to cap the number of digits you add.
+09:44 < matches> The problem was the algorithm before didn't finish all the borrows
+09:44 < matches> eg: 100 - 2 would have become "-8"
+09:44 < matches> Because 2 only has one digit
+09:44 <@sulix> My powers of mathematics tell me that that is not quite correct.
+09:45 < matches> What, that our algorithm was wrong?
+09:45 <@sulix> No, that 100-2 is not -8
+09:45 < matches> Yes
+09:45 < matches> Yes that's the problem :P
+09:46 < matches> So basically the two numbers need to be the same size but since we have a constant argument I'm sticking in a "borrow_digits" vector if there is a borrow
+09:46 < matches> Addition also needs it for carry
+09:46 < matches> Damn
+09:47 < matches> I'd hoped that might fix the beziers not looking like beziers on the CPU bug
+09:50 <@sulix> I've pushed code to clear the carry/borrow flag before adding/subtracting.
+09:50 <@sulix> I don't think any bug is triggered, but there was the potential for off-by-one errors.
+09:52 < matches> Argh no
+09:52 < matches> Merge
+09:53 < matches> Yeah I'm pushing a fix for bugs that I don't think we've seen (yet)
+09:54 <@sulix> Out of curiosity, I tried removing the Simplify() calls from Rational.
+09:54 <@sulix> Relatedly, I've coined the term "NaN soup"
+09:54 < matches> Oh, clearing the carry/borrow flag might actually fix a bug with the code I just committed
+09:54 < matches> No wait it won't
+09:55 < matches> Eh it's still kind of dangerous to assume it isn't set to start with
+09:55 <@sulix> I think the flag was probably already cleared by the code the compiler generated, but that might not be the case if it's optimized.
+09:55 < matches> One of my early attempts had inline adc instructions in a for loop
+09:56 < matches> Which failed miserably because the for loop was clearing the carry flag :P
+09:57 <@sulix> For some reason "*=" segfaults if optimization is enabled, but I don't know why.
+09:57 < matches> Yuk
+09:58 <@sulix> Somehow we end up with "mul" as a null reference.
+09:58 < matches> Rataional::*= or Arbint?
+09:58 <@sulix> Arbint
+09:58 <@sulix> (So, also rational)
+09:58 <@sulix> Valgrind isn't picking anything up.
+09:58 < matches> null references are the worst
+09:59 < matches> Since I'm pretty sure the point of a reference is that it is never null...
+09:59 < matches> I'm sure this doesn'
+09:59 < matches> t stop people from deliberately creating null references
+09:59 < matches> And also checking that they are not null
+10:02 <@sulix> Tried compiling with clang. Nope.
+10:02 <@sulix> Apparently not even #include <iostream> compiles with clang.
+10:02 < matches> It might be worth implementing a non assembly version of those functions
+10:03 <@sulix> Yeah, that's always a good idea.
+10:03 <@sulix> The assembly ones are more fun, though.
+10:16 < matches> Hmm I should probably head towards the meeting
+16:23 < matches> I have pushed a Gmpint wrapper thing
+16:23 < matches> It mimics Arbint as closely as possible.
+16:24 < matches> Well by that I mean I just wrapped all the calls to mpz_add() etc in operators
+16:24 < matches> It doesn't have all of Arbint's more esoteric functions
+16:24 < matches> If we need bit shifts I think I can add them
+16:27 < matches> So, writing stuff...
+16:28 < matches> Running arbint_vs_gmpint.test in valgrind takes a fair while
+16:28 < matches> We will have the definitive answer of just how terrible our multiplication is compared to the Professional (TM) implementation
+16:29 < matches> I do have some good news, I think our string conversion might be better
+16:29 < matches> Well if you ignore the division
+16:31 < matches> *= is about 11 times slower
+16:32 < matches> Most of that is in std::vector::resize()
+16:32 < matches> But even just mul_digits is greater than the entire Gmpint::operator*=
+16:32 < matches> The plot thickens as I try division
+16:32 < matches> Which is a good opportunity to get food because it will probably take an hour
+16:34 < matches> Note: Don't disable Debug messages if you want time to get food :(
+16:35 < matches> And division is just under 100* slower
+16:36 < matches> No
+16:36 < matches> 1000*
+16:37 < matches> So... if we change Rational<Arbint> to Rational<Gmpint>...
+16:41 < matches> We still get {nan,nan,nan,nan} eventually but it is generally less shoddy
+16:50 <@sulix> Cool: looking at this now.
+16:50 <@sulix> I'm digging through the gmp source code as well.
+16:51 <@sulix> They have a similar "divide by single int64_t" optimization.
+16:51 <@sulix> Also their code is 90% preprocessor macros.
+16:51 < matches> Welp
+16:51 < matches> At least we have a readable Arbint
+16:52 < matches> I don't know what use a readable but slow implementation is
+16:52 <@sulix> Ah: I see what they're doing: this is quite clever, particularly from a pure maths point of view.
+16:52 <@sulix> They've got a natural number implementation, and have then built their integer representation around that.
+16:53 <@sulix> The natural numbler implementation is just a huge set of directories with different assembly implementation.
+16:53 <@sulix> So there's an "x86_64" directory, and in that there's a bunch of assembly + a bunch of directories with optimized versions for different individual processor models.
+16:55 <@sulix> Also their assembly has lots of ASCII art comments.
+16:56 <@sulix> and macros.
+17:07 < matches> Yeah "just use GMP" is probably the answer
+17:08 < matches> Their Makefiles are pretty intimidating
+17:22 < matches> I like that they seem to store the sign as part of the size
+17:22 < matches> If something has a negative size it is negative and has |size| digits
+17:34 < matches> I guess I will try and write some sort of report about how we implemented Arbitrary Integers but they are terrible compared to existing implementations :P
+--- Day changed Thu Jul 24 2014
+14:44 < matches> So I was going to work on the project but existential dread
+14:45 < matches> About whether my major exists
+14:45 < matches> Do I exist?
+14:49 <@sulix> Are you thinking? Because cogito ergo sum.
+14:50 < matches> I'm not sure I was thinking when I picked this major...
+14:50 <@sulix> I did some project code yesterday and then a bug I thought I'd fixed reappeared so I got distracted failing to fix that.
+14:50 < matches> Haha
+14:53 < matches> Should I upset everyone and recommend freshers for wheel again...
+14:54 <@sulix> I'm all for it, but I think the consensus was that we need to make them actually do wheel-y projects first.
+14:55 < matches> That seems kind of hypocritical though
+14:55 < matches> Because nearly none of active wheel has actually done wheel-y projects
+14:55 < matches> Certainly not before getting on wheel
+14:56 <@sulix> My current random guess is that the problem is that people used to fix the desktops and stuff, and now everyone has their own laptops to break.
+14:56 < matches> But I'll be quiet or people might decide I need to be removed due to lack of doing useful things
+14:56 < matches> Yeah
+14:56 < matches> That too
+14:57 <@sulix> I'll definitely bring it up at the meeting.
+15:02 <@sulix> So which CoderDojo forms do I need to fill out?
+15:02 < matches> Ooh!
+15:02 < matches> http://coderdojowa.org.au/volunteer
+15:02 < matches> This one
+15:03 < matches> But now you've said that I'm already adding you to the mailing list...
+15:04 < matches> There's a thing on Saturday in 2.01 in CS at 12:00pm
+15:04 < matches> I hope people actually show up because we are pretty short on presenters
+15:04 <@sulix> Yeah, I've got a programming competition then. I'm trying to work out how much of the schedule for the competitions exists.
+15:06 <@sulix> Okay, apparently there are programming competitions every saturday in August, which will be fun.
+15:07 <@sulix> Although half of them are "details TBD," which sounds ominous.
+15:07 <@sulix> Also there is a round 2 and a round 4 but no round 3.
+15:11 <@sulix> Okay: it looks like the only weeks I don't have programming competitions on are the last 3 on the form.
+15:13 <@sulix> Also I suspect they're running out of names for the programming competitions, because this Saturday's is called the "South Pacific Winter Programming Carnival".
+15:21 < matches> Haha
+15:27 <@sulix> Form submitted. Sorry for the snarkiness.
+15:40 < matches> Brilliant
+15:40 < matches> You can do a C or C++ workshop or something :P
+15:40 < matches> Or just talk about Commander Keen that'll work
+15:40 < matches> Or "Why Javascript is awful and you should forget all the lessons"
+15:42 <@sulix> "Intro to DOS programming." :P
+18:38 < matches> I did a sort of half hearted attempt at writing more about Arbints
+18:39 < matches> Maybe I'll try put fonts in
+18:39 < matches> That seems vaguely like not what I am supposed to be doing right now :P
+18:43 < matches> There's that virtual FPU sitting there doing nothing
+18:43 < matches> That I promised to do things with in my lit review
+18:43 < matches> That Tim is marking
+18:43 < matches> When I haven't actually done anything with it and he knows it...
+18:44 < matches> I can't help but feel like we need a more impressive thing to zoom in on
+18:44 < matches> Or even a way to draw things once we have zoomed in
+18:46 < matches> Does "We implemented Arbitrary Precision Integers but GMP did it better" count as research?
+19:13 < matches> Do we have a memory leak?
+19:13 < matches> I've been running it for a while and things are slowing down
+19:25 <@sulix> matches: With GMP or just doubles?
+19:27 <@sulix> My quick check has us not leaking memory with doubles.
+19:27 <@sulix> Well, X leaks memory and the nVidia driver leaks memory, but we're fine.
+19:35 < matches> I was actually running with singles :S
+19:35 < matches> See push to documents repo
+19:35 < matches> There is a pdf
+19:35 < matches> I did a thing
+19:38 < matches> I'm basing the assumption that x86-64 is IEEE compliant on the fact that it passed the "paranoia" program
+19:39 <@sulix> Yeah, x86_64 is IEEE compliant.
+19:39 <@sulix> x86_32 is "mostly" IEEE compliant if I recall.
+19:41 < matches> Well a picture tells a thousand words
+19:41 < matches> So I think I wrote 8000 words today
+19:41 < matches> Progress!
+19:43 <@sulix> http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/brw_defines.h?id=9d6166880da83887e3246fb4498c3a07d979cc3b#n162
+19:43 <@sulix> I'll see if I can find where they actually set it to non IEEE.
+19:43 < matches> Oh I was going to say fglrx did different things to nVidea but as I don't have nVidea that's difficult to do
+19:45 <@sulix> Although there's this: http://lists.freedesktop.org/archives/mesa-dev/2013-July/041555.html
+19:45 <@sulix> Yeah, nVidia, Intel and fglrx all seem to do different things.
+19:45 <@sulix> fglrx does the strangest things.
+19:45 <@sulix> nVidia does the most consistant things.
+19:45 <@sulix> Intel sits nicely in the middle.
+19:46 < matches> If we can get four screenshots of the different things at the same view bounds that might be useful
+19:47 < matches> Also working out more about what the jagged edges implies about the precision/rounding might be helpful
+19:47 < matches> All I've got is "This is clearly not a circle"
+19:48 < matches> So it's still doing that with the quad trees enabled, so I assume the quad trees aren't amazingly quadifying everything yet :P
+19:48 <@sulix> The quadtrees are basically doing nothing but occasionally causing bugs.
+19:48 <@sulix> http://davidgow.net/stuff/ipdf-nvidia.png
+19:48 < matches> That is progress at least
+19:49 < matches> Thanks
+19:49 < matches> I will update the others to be the same view bounds
+19:49 < matches> I *think* we have code to set the view bounds at start?
+19:51 <@sulix> http://davidgow.net/stuff/ipdf-intel.png
+19:51 < matches> Haha
+19:51 < matches> Well it's really obvious that that's different
+19:52 < matches> Can you rerun it with -b 0.0869386 0.634194 2.63295e-07 2.63295e-07
+19:52 < matches> Obsessive compulsive...
+19:52 < matches> Must all be same view bounds...
+19:53 < matches> I'd run it on my other laptop with intel integrated graphics except the keyboard still doesn't work
+19:55 < matches> Actually don't bother
+19:55 <@sulix> http://davidgow.net/stuff/ipdf-nvidia1.png
+19:57 <@sulix> http://davidgow.net/stuff/ipdf-intel1.png
+19:59 < matches> oah wierd stuff is happening with the quad tree
+19:59 < matches> There is a big circle and a little circle
+19:59 < matches> Is that supposed to be here...
+20:00 < matches> The distance between them is not constant :S
+20:09 <@sulix> Yeah, that doesn't happen on intel and is the bug I've been hitting my head against.
+20:09 <@sulix> Pretty certain I'm trying to render one more object than there actually is somewhere, maybe corruping memory in the process.
+20:32 < matches> Ok so it turns out the CPU is actually about as terrible as the GPU at those view bounds when you replace the "double" with "float" in the Circle Renderer :S
+20:32 <@sulix> That's what I expected.
+20:32 <@sulix> It looks like the nVidia one, right?
+20:32 < matches> But it does slightly different wrong things!
+20:34 < matches> It looks similar-ish
+20:35 < matches> It is blocky as opposed to zig zaggy
+20:39 < matches> As in it doesn't look as whack as intel
+20:43 <@sulix> Hmm... I'm not sure what I'm doing wrong, but I can't see any artefacts at all with CPU rendering w/ those bounds.
+20:55 < matches> They are hard coded as doubles
+20:55 < matches> Not floats
+20:55 < matches> Or reals rather
+20:56 <@sulix> Ah.
+20:56 <@sulix> This explains much.
+21:08 < matches> I have pushed a thing
+21:09 < matches> It almost sounds like a real paper
+21:09 < matches> Until you realise all it is is "we drew some circles and they look different"
+21:09 < matches> Also your screenshots had some kind of crazy blue glowy border
+21:10 <@sulix> Yeah, that's the KDE window shadow.
+21:10 < matches> Fancy
+21:10 <@sulix> It used to make the nVidia driver corrupt screenshots, but it seems to work now.
+21:11 < matches> I'm pretty pleased with that 4 way comparison figure...
+21:12 < matches> "One of these things is not like the others..."
+21:12 < matches> *cough* intel
+21:12 <@sulix> The conclusion is brilliant.
+21:15 < matches> If we assume the nVidia and x86-64 figures are what things are supposed to look like
+21:15 < matches> fglrx tries really hard
+21:15 < matches> But doesn't quite make it
+21:16 < matches> (I'm pretty sure that's just a particularly good view for it)
+21:16 < matches> (If you move it around it goes insane)
+21:16 < matches> I can respect the intel shader
+21:16 < matches> It isn't afraid to blatantly disregard the rules
+21:17 < matches> intel driver rather
+21:17 < matches> Not sure why I put "shader" there
+21:17 < matches> This has not been as productive as I hoped
+21:18 < matches> Still
+21:18 < matches> We finally have something written that Tim can pass judgement on
+21:18 < matches> He's still in the country right?
+21:19 < matches> He might want to finish passing judgement on my literature review first :S
+21:21 <@sulix> I think he's still in the country, but don't hold me to that.
+21:22 < matches> Ok, so if you translate around with the CPU things don't go insane, but they do on the GPU. That might be caused by something else though.
+21:23 < matches> I'll be at University tomorrow
+21:24 <@sulix> I might head in, too, then.
+21:25 <@sulix> Do things still "go insane" on the GPU with CPU-side coordinate transforms.
+21:26 < matches> Yeah
+21:26 < matches> It looks like there is a tear
+21:27 < matches> So you get this rectangle pattern
+21:27 < matches> If you move it around on the CPU it maintains its shape
+21:28 <@sulix> I think that fglrx (or maybe just the AMD hardware) calculates the coordinates per-triangle rather than per-vertex or something.
+21:28 < matches> Under fglrx the bottom part of it sort of maintains its shape but there is a big diagonal line and the stuff above that changes
+21:28 <@sulix> That's pretty weird.
+21:29 < matches> Also the bottom part doesn't have concave bits but the top occasionally gets one
+21:29 < matches> concave/overhanging whatever
+21:29 <@sulix> The whole thing maintains its shape on nvidia (and even intel)
+21:29 < matches> Well, the bottom half (and also the CPU/nVidia entire thing) looks kind of like a stair case
+21:29 < matches> The top bit gets all these sticky out bits and overhangs
+21:30 < matches> Which brings us to our next paper
+21:30 < matches> The geology of fglrx
+21:30 <@sulix> Intel also does the "staircase" on the other side of the circle.
+21:30 < matches> On the other side...
+21:30 < matches> Hmm the plot thickens
+21:31 < matches> Oh well I need to sleep
+21:31 < matches> Why do I feel like I have actually lost sleep over the holidays...
+21:32 < matches> I am not ready for semester to start :(
+21:32 <@sulix> I know exactly what you mean.
+21:33 < matches> I seem to have been roped into unpaid work with physics
+21:34 <@sulix> Oh dear. More lab demonstrating or something more interesting?
+21:34 < matches> Hopefully if I visit ECM they won't make me do GENG5505 yet
+21:34 < matches> Fixing my honours experiment I think...
+21:35 <@sulix> Another pipe corroded through?
+21:35 < matches> Haha
+21:35 < matches> They were wondering where all the electronics went
+21:35 < matches> (I have most of it)
+21:35 < matches> (Also it's no longer functional)
+21:36 < matches> (I may have taken some of it apart...)
+21:36 < matches> (Although really the sensible option would have been to burn it with fire)
+21:37 < matches> Goodnight anyway
+21:37 <@sulix> I'm required to "correct" anything they want to change with this project after submitting it.
+21:37 <@sulix> On the morrow, then!
+--- Day changed Fri Jul 25 2014
+11:24 < matches> I'm at UCC
+11:39 <@sulix> Okay, I'll show up once I've sorted out this acedemic record stuff.
+12:05 < matches> I went to ECM but apparently just a few other people are having difficulties...
+18:24 < matches> So steam browser supports html5 canvas but not keyboard events
+18:24 < matches> This seems to happen with a lot of browsers
+18:25 < matches> We support html5 canvas (which is pretty much solely designed for web based games)
+18:25 < matches> But we don't support any way to actually pass input to the page that doesn't suck
+18:25 < matches> (I'm looking at you Safari)
+18:31 < matches> It sort of spoils the "HTML5 is AWESOME" message the HTML5 people are aiming for
+18:31 < matches> The best bit of html5 is <canvas> and that you no longer need to use html because you can just draw everything in the canvas...
+18:32 < matches> Which is scarily similar to using PostScript
+--- Day changed Mon Jul 28 2014
+10:05 < matches> In 2.07 now
+10:07 < matches> You removed SDL from contrib
+10:07 < matches> So now it won't compile on the lab machines
+10:07 * matches gets out the laptop then
+--- Day changed Tue Jul 29 2014
+09:59 < matches> I seem to have this bizarre illness
+10:00 < matches> Where half my head feels fine
+10:00 < matches> And the other half feels like I've been trying to read brainfuck
+10:00 < matches> I hope you don't catch it
+10:00 < matches> The side that is sick is the side that was closest to the group hug
+10:00 < matches> Coincidence!?
+10:00 < matches> I think not!
+10:08 < matches> You know how there's this theory about the two halves of the brain being semi independent and sort of subconsciously able to think by themselves
+10:08 < matches> I think the left side of my brain is dead
+10:08 < matches> It's not responding to pings
+10:09 < matches> I think the project working side might be the alive one though, so we shall see if I can actually do something useful
+--- Log closed Tue Jul 29 23:13:08 2014
+--- Log opened Wed Jul 30 12:03:38 2014
+12:03 -!- Irssi: #ipdf: Total of 2 nicks [1 ops, 0 halfops, 0 voices, 1 normal]
+12:03 -!- Irssi: Join to #ipdf was synced in 0 secs
+--- Day changed Sun Aug 03 2014
+12:43 < matches> So I found my moronic mistake with the virtual FPU and it seems to actually work
+12:44 < matches> I think it's even slower than using Rational<Arbint>
+12:44 < matches> Unless everything's slow because of the QT now
+12:45 < matches> There's an awful lot of "Rendering QT node" debug
+12:46 < matches> No its the VFPU that makes sense
+12:47 < matches> Since every floating point operation now requires writing 18 hex characters over a unix domain socket
+12:47 < matches> Hooray VHDL
+12:48 < matches> (I'm sure if you have $$$$ and like Enterprise(TM) software VHDL is great)
+12:48 < matches> I'll just do some miscellaneous things and hopefully some of them will be useful
+12:48 < matches> Bye
+14:14 < matches> So with the VFPU and doing everything on the GPU we have 2.2 FPS
+14:14 < matches> It seems to be able to cope with rectangles on the CPU
+14:15 < matches> The circle may present some difficulties
+14:16 < matches> It would be have been pretty cool to change the vfpu and see if anything makes it look like intel
+14:16 < matches> But ultimately useless I suppose
+14:37 < sulix> There might be some info in the hardware docs, though they're pretty incomprehensible: https://01.org/linuxgraphics/documentation/2013-intel-core-processor-family
+14:38 < sulix> AMD also have manuals: http://developer.amd.com/resources/documentation-articles/developer-guides-manuals/
+14:38 < sulix> nVidia are sworn to secrecy.
+--- Day changed Tue Aug 05 2014
+12:38 < matches> I'm looking at the atril source
+12:38 < matches> To see if I can compile it without the oppressive 400% max zoom
+12:39 < matches> It is rather intense
+12:39 < matches> I think the zooms are set depending on the language?
+12:41 < matches> There are po files which are definitely not position independent object files
+12:43 < matches> #define ZOOM_MAXIMAL(zoom_levels[n_zoom_levels - 1].level)
+12:43 < matches> The plot thickens!
+12:45 < matches> Heh this is actually sort of making sense
+12:45 < matches> They have a "cut-n-paste/zoom-control" directory
+12:48 < matches> I'm confused as to how the maximum zoom is 6400% and yet my version will only zoom to 400%
+12:48 < matches> But I guess I shall compile it from source and see what actually happens
+12:51 < matches> They also have a script to configure their configure script...
+12:51 < matches> Oh dear xml is involved
+12:53 < matches> There needs to be a way to save the status of configure so you don't have to rerun it from scratch every time you fix an error
+12:56 < matches> Our document viewer may only be able to render beziers and circles
+12:56 < matches> But at least it doesn't have any dependencies!
+12:56 < matches> Well many
+12:56 < matches> I suppose since SDL is in contrib we should put GMP in contrib too
+12:57 < matches> But yes, I don't care about caja plugins dammit I want to zoom on a pdf
+13:00 < matches> "Warning: Comparison between pointer and integer"
+13:00 < matches> Aaaah
+13:00 < matches> It compiles...
+13:01 < matches> But where did it put the binary...
+13:02 < matches> Oh great it expects things to be in /usr
+13:03 < matches> I guess I will run "install-sh" and hope I will still have a usable pdf viewer
+13:07 < matches> There's a LOT of G_ and g_ variables
+13:07 < matches> Actually functions
+13:07 < matches> I think g_ does not mean global in this context
+13:07 < matches> Maybe
+13:11 < matches> So it's not just a matter of ZOOM_MAXIMAL being redefined to ridiculously huge numbers having any effect
+13:11 < matches> I guess they use some other library that has zooming
+13:13 < matches> It somehow detects what the maximum zoom should be based on the document as well
+13:13 < matches> This is just over engineering!
+13:19 < matches> ev_view_can_zoom_in (EvView *view)
+13:19 < matches> return view->scale * ZOOM_IN_FACTOR <= ev_document_model_get_max_scale (view->model);
+13:19 < matches> Let
+13:19 * matches casually makes it return true
+13:19 < matches> Also wtf
+13:19 < matches> They have a "gboolean" type
+13:19 < matches> Is "bool" inferior?
+13:19 < matches> What more do you need than true and false
+13:20 < matches> Is bool used as a variable name for something
+13:20 < matches> sigh
+13:24 < matches> No ok it still won't let me zoom in more
+13:25 < matches> g_return_if_fail in the zoom functions
+13:25 < matches> They don't look important
+13:28 < matches> There are a surprising amount of places with a "if zoom or scale is bigger than the maximum, return"
+13:28 < matches> Like, are three checks really necessary
+13:29 < matches> I think you can set model->sizing_mode to "EV_SIZING_FREE" but I have no idea what that will do
+13:29 < matches> So I'll just continue commenting out anything that looks like it will return early from the zoom process...
+13:30 < sulix> Sounds like a plan!
+13:31 < matches> The use of g_ for function names makes me want to stab someone :P
+13:31 < matches> I assume it's related to gtk or maybe just gnome
+13:32 < matches> Also about half their doubles are "gdouble"
+13:32 < matches> And the other half are "double"
+13:32 < matches> :S
+13:32 < sulix> gtk had their own crazy, let's implement everything from scratch idea.
+13:32 < sulix> They have their own "classes" in C, IIRC.
+13:32 < matches> It's pretty object orientated yes
+13:34 < matches> Ok I seem to now be able to zoom in a *bit* more and then it just stops drawing things
+13:35 < matches> No wait it's just hopelessly slow
+13:37 < matches> It also zooms in on the wrong spot and then draws it and then moves the view back to the mouse and draws again
+13:38 < matches> But yes, it doesn't cope well with zooming at all
+13:38 < matches> I was kind of hoping it would work
+13:39 < matches> Maybe if I use a simpler document
+13:43 < matches> Congratulations anyway
+13:43 < matches> We can zoom further on a circle than atril can
+13:44 < matches> Unfortunately the reasons atril can't zoom are probably not related to precision
+13:44 < matches> Maybe I need to find some "if zoom > thing don't draw anything" and comment those out too
+13:44 < matches> Sigh
+14:07 < matches> It is resistant to my valgrind attempts
+14:07 < matches> It seems to have spawned 9 processes
+14:10 < matches> Oh "atril" is actually a series of hideous bash scripts that load libraries or something
+14:12 < matches> You know
+14:12 < matches> I'm sure if we tried
+14:12 < matches> We could make a less shitty pdf viewer out of our program
+14:29 < matches> Interesting
+14:30 < matches> "ev_document_render" got called 10.6 Billion times
+14:30 < matches> I don't think I changed the view that many times...
+14:32 < matches> Ok, so just working on our own viewer is probably better at this point than working out why atril has a heart attack if you zoom
+14:33 < matches> I'm going to pretend this wasn't a waste of time...
+14:41 < matches> "existing pdf viewers cap the view because otherwise they break due to bugs that aren't actually related to precision"
+15:43 < matches> So I suspect the GPU Bezier rendering is buggy
+15:44 < matches> Or maybe it's a quad tree thing
+15:45 < matches> Or both...
+15:46 < matches> I'm pretty sure the appearance of an individual bezier should not depend on what other beziers are in the document :P
+15:47 < matches> Yeah there's wierd quad tree shit going on
+15:48 < matches> I'm going to try and add some sort of glyph/font like thing
+15:49 < matches> It's either that or create hand drawn beziers in the current view
+15:50 < matches> But I feel it desperately needs an example of being able to actually zoom in and create something at an "arbitrary" level
+18:54 < matches> So we sort of have a very broken, very badly written, SVG parser
+18:55 < matches> A bunch of bugs showed up in the bezier rendering
+18:56 < matches> Although it might just be fglrx
+22:23 < sulix> The GL code is now consistantly broken, rather than sporadically broken.
+22:24 < sulix> Trying to render SVGs with it might count as modern art, though.
+22:39 < sulix> Man, the buggier the bézier code gets, the more beautiful its output.
+22:53 < sulix> Voilà: http://davidgow.net/stuff/ipdf-koch-svg.png
+23:11 < sulix> And on the CPU: http://davidgow.net/stuff/ipdf-koch-svg1.png
git.ucc.asn.au / ipdf / documents.git / blobdiff
UCC git Repository :: git.ucc.asn.au