[22:25] <mgrandi> man, this installer script for windows is...buggy
[22:29] <mgrandi> is there a way to see what extensions bzr is complaining about that were not built?
[22:30] <fullermd_> Does it say in .bzr.log (or whatever it's called on benighted platforms)?
[22:30] <mgrandi> well there is a log for compiling the extensions, there are a bunch of warnings but i dont see it saying that compilation failed anywhere
[22:31] <fullermd_> I'm half sure (a clever dodge, since it means I can't be wrong) the runtime log says what it can't load, which would at least tell you what failed compiling.  Why, well, that's a whole different W word...
[22:33] <mgrandi> well its not being run yet, so i guess ill wait until then
[22:33] <fullermd> Ooh, I thought you were already seeing the runtime.  Hm.
[22:34] <fullermd> Hm.  Well, on *nix it just outputs all the compiling stuff like any other program.
[22:35] <fullermd> Only compiler warning I see (clang 3.3) is about an unhandled enum value.  Plus a little grumble from cython about unreachable code.
[22:35] <mgrandi> its running like a bunch of different scripts, maybe its like, the bzr itself trying to compile the extensions? haha
[22:36] <mgrandi> i wish i had clang on windows, they say they are trying to bring it to windows
[22:36] <mgrandi> should shaken up the C compiler monopoly that microsoft has
[22:36] <mgrandi> shake*
[22:36] <mgrandi> maybe even mean every open source project that is multi platform can support something other then c89 =P
[22:36] <fullermd> I'm given to understand that they actually have a middling decent compiler under there, it's just all the surrounding build stuff is so horrifically bad you never get to see it.
[22:37] <fullermd> I think recent VS actually does handle most of the interesting bits of c99.
[22:37] <fullermd> Almost in time for c11   :p
[22:38] <mgrandi> but its not in microsoft's business plan to support C anymore
[22:38] <mgrandi> they want c++, but that is of course bad for python ruby anything that is written in C
[22:39] <fullermd> There's always the chance that C++ will acidentally slip and fall some day.  Into a vat of acid.  On fire.  With a shiv in its back.  Accidentally.
[22:39] <fullermd> I mean, that's what I hear.  I never think such things myself.
[22:39] <mgrandi> looking at the horrible c++ code at work, i can only hoep
[22:39] <mgrandi> hope
[22:40] <mgrandi> it would be better if they used boost or qt or anything that tries to ease the pain, but they stick with the stdlib, which...is awful
[22:40] <fullermd> Well, at least it's consisten...  oh, wait.
[22:42] <mgrandi> my favorite is std::thread::hardware_concurrency()
[22:42] <mgrandi> returns 0 if it can't tell how many cpu's your computer has
[22:42] <mgrandi> which i guess sorta makes sense, but also why not just return 1, since you are...going to have at least 1 cpu in your computer!
[22:44] <fullermd> That sounds like a challenge   :)
[22:45] <fullermd> Available responses include "No, it has an Atom".
[22:45] <mgrandi> maybe its a potato
[22:53] <mgrandi> hardest part about this script is waiting for it to checkout the bzr source from another local directory, haha
[23:08] <mgrandi> GREAT
[23:08] <mgrandi> apparently the wonderful message "msginit:lib/gettext/project-id subprocess failed: bad file descriptor is a completely fine error message
[23:08] <mgrandi> and should be ignored
[23:18] <fullermd> File descriptors go bad all the time.  That's why they come in 2**N-packs.
[23:26] <mgrandi> haha