| 00:41.29 | *** join/#brlcad mpictor (~mark@99-93-104-202.lightspeed.iplsin.sbcglobal.net) | |
| 01:13.51 | Notify | 03BRL-CAD:starseeker * 55406 (brlcad/trunk/include/bu.h brlcad/trunk/src/conv/stl/g-stl.c and 52 others): Add the bu_ prefix to htond, ntohd, htonf, and ntohf functions in libbu. |
| 01:16.09 | Notify | 03BRL-CAD:starseeker * 55407 brlcad/trunk/doc/docbook/system/man3/en/htond.xml: Add prefix to man page too |
| 01:16.51 | Notify | 03BRL-CAD:starseeker * 55408 brlcad/trunk/doc/docbook/system/man3/en/CMakeLists.txt: rename man page file to have bu prefix as well. |
| 01:31.32 | brlcad | starseeker: huh, that's actually pretty amazing that they'd define them |
| 01:33.07 | brlcad | they're not posix or portable, generally speaking |
| 01:34.19 | brlcad | ours are, however, meant to extend the standard interface portably |
| 01:35.03 | brlcad | they would have belonged in a library like libsysv except that they're the exact opposite (something like a libbsd) |
| 01:37.53 | brlcad | ours should probably be conditionalized, assuming windows is defining the same function, not undef or prefixing, if we are to keep with the theme |
| 01:40.01 | brlcad | ahh, I see what they did |
| 01:41.00 | brlcad | it's actually a much bigger problem, they changed all of the classic [nh]to[hn]* functions incompatibly |
| 01:43.37 | brlcad | http://msdn.microsoft.com/en-us/library/windows/desktop/jj710197(v=vs.85).aspx |
| 01:44.15 | brlcad | WSA[HN]to[nh]* is apparently the old version |
| 01:45.53 | starseeker | well, that might explain why the build is succeeding now but opening a .g file in mged failed... |
| 01:47.09 | starseeker | yeah, archer fails too, same piont |
| 01:47.16 | starseeker | s/piont/point |
| 01:47.21 | brlcad | yeah, it's probably issuing warnings, but all the database i/o is going to be wrong |
| 01:47.26 | brlcad | surprising it doesn't crash |
| 01:47.31 | starseeker | it does |
| 01:47.43 | starseeker | or do you mean the compilation? |
| 01:48.00 | brlcad | runtime |
| 01:48.02 | brlcad | so what changed? |
| 01:48.10 | brlcad | new msvc or win8 compile? |
| 01:48.22 | starseeker | both - VS 2012 + Win 8 |
| 01:48.42 | brlcad | you get a new toy? |
| 01:48.47 | starseeker | punted and got a new PC retail, so it had Win 8 on it - figure it was a good chance to try the new compiler |
| 01:48.56 | brlcad | ahh, k |
| 01:49.22 | brlcad | probably going to be a bigger issue to deal with cleanly |
| 01:49.50 | starseeker | tried to dual boot initially, but the new UEFI thing is a major pain - as a bonus, there's some sort of new Intel pseudo-raid thing going on to use a 32G SSD + larger normal drive to provide the fast performance without sacrificing space |
| 01:51.10 | starseeker | brlcad: feel free to revert my prefix stuff - I mainly wanted to see if that was the only remaining compilation issue after straightening out the C inline stuff - looks like it is |
| 01:52.18 | starseeker | build yes, run without DB open yes, open db crash |
| 01:52.56 | brlcad | makes sense |
| 01:53.16 | brlcad | you realize why, yes? it's on that link I posted |
| 01:54.00 | starseeker | http://msdn.microsoft.com/en-us/library/windows/desktop/jj710197(v=vs.85).aspx |
| 01:54.04 | starseeker | crud, sorry |
| 01:54.27 | starseeker | some things in windows still suck... |
| 01:55.18 | brlcad | it's the diff of http://msdn.microsoft.com/en-us/library/windows/desktop/ms740075(v=vs.85).aspx vs http://msdn.microsoft.com/en-us/library/windows/desktop/ms741663(v=vs.85).aspx |
| 01:56.01 | starseeker | yeah - the htond et. al. functions are very important to the db IO layer, yes? |
| 01:56.22 | brlcad | fundamental |
| 01:57.06 | starseeker | nods |
| 01:57.48 | starseeker | so should I revert the prefix change, or are we going to have to go further down that road? |
| 01:58.22 | brlcad | I suggest we catch it on the next minor |
| 01:58.27 | brlcad | since it technically breaks API |
| 01:58.41 | starseeker | k |
| 01:58.56 | brlcad | do it as one, so we can reapply it as one |
| 01:59.17 | starseeker | figured it came under the "minor" changes, but no point in rocking the boat now since it doesn't give us a working VS2012 buidl |
| 01:59.22 | starseeker | s/buidl/build |
| 01:59.31 | starseeker | (new keyboard too... mutter) |
| 01:59.53 | brlcad | it fits the minimally impacting criteria as a name change |
| 02:00.27 | brlcad | would want to make sure that's all we have to do, though, and don't really want to add one more bean on the scale on this release |
| 02:01.01 | brlcad | I suspect we'll need to wrap all of them, i.e., extend bu API |
| 02:01.31 | starseeker | nods |
| 02:02.01 | brlcad | ironically, the new functions they define are nearly identical in definition to our xdr functions |
| 02:02.14 | starseeker | as long as I'm here, what would you like to see on the ftell/lseek/etc. issue? |
| 02:04.53 | Notify | 03BRL-CAD:starseeker * 55409 (brlcad/trunk/doc/docbook/system/man3/en/CMakeLists.txt brlcad/trunk/include/bu.h and 53 others): Reverse merge back out the bu_ prefixing of ntohd and htond - will probably need it later, so doing it all in one commit per Sean's suggestion. Should do this after release, and anyway a complete solution to the Windows API changes will be a lot more extensive than this - while this rename |
| 02:04.55 | Notify | lets BRL-CAD compile with VS2012, there are runtime failures in database IO due to related Windows API changes. |
| 02:04.57 | starseeker | shazam |
| 02:04.59 | brlcad | well, first off, what happens if there's no #include <stdio.h> in the config_win_cmake.h.in |
| 02:05.39 | starseeker | it may look different here, but I'll test it quick |
| 02:05.58 | brlcad | ideally should have no #includes in config_win_cmake.h.in |
| 02:06.15 | brlcad | those are seriously going to slow things down and break the header ordering |
| 02:08.59 | starseeker | http://paste.lisp.org/display/137147 |
| 02:09.31 | starseeker | (also took out the undef lines that followed the two stdio.h calls) |
| 02:10.32 | starseeker | (the pre-existing fcntl.h and errno.h includes are still there, fwiw) |
| 02:11.00 | brlcad | okay, and without them, same errors? |
| 02:11.25 | starseeker | you mean if I nuke fcntl.h and errno.h? (those were pre-existing, afaik) |
| 02:11.38 | starseeker | or without the re-defines? |
| 02:12.34 | starseeker | without re-defining them to the 64 bit versions, the build succeeds |
| 02:12.49 | starseeker | I just don't know what happens when the relevant functions meet a 64 bit sized file |
| 02:16.19 | starseeker | those two (ftell and fseek) may actually need wrappers if we want to guarantee the 64 bit call w/o first loading stdio.h and then overriding it |
| 02:17.24 | starseeker | near as I can tell, it's basically the MSVC stdio.h not checking to see if someone else has defined the macro first - frustrating but unsurprising |
| 02:22.07 | Notify | 03BRL-CAD:brlcad * 55410 brlcad/trunk/src/libbu/affinity.c: try an unsigned long (might need i64 instead) literal to quell compilation warning on win8 msvc |
| 02:22.28 | brlcad | I means without the fcntl and errno headers keeping the defines |
| 02:22.44 | starseeker | ah - one sec... |
| 02:22.51 | brlcad | we're not redefining them, it's the first header |
| 02:23.01 | brlcad | msvc might be later on in stdio.h |
| 02:23.11 | starseeker | they are, IIRC |
| 02:24.08 | starseeker | yeah, same long list of compilaints |
| 02:25.41 | brlcad | okay, so that's good -- means they can go away ;) |
| 02:26.00 | starseeker | http://paste.lisp.org/display/137148 |
| 02:26.09 | starseeker | brlcad: that's just libbu |
| 02:26.21 | starseeker | I'd have to do a full build to see if they matter or not |
| 02:27.03 | starseeker | hang on - that'll take a few minutes (I'll comment out ftell and fseek definitions) |
| 02:27.10 | brlcad | don't worry |
| 02:27.13 | brlcad | it's fine for now |
| 02:27.54 | brlcad | can you post up stdio.h somewhere, or look at it around lines 247-252 |
| 02:31.38 | brlcad | it's saying that _ftelli64 is getting redefined, but we don't define it |
| 02:32.31 | brlcad | proabaly the decl for ftelli() but need to confirm |
| 02:32.40 | starseeker | http://paste.lisp.org/display/137149 |
| 02:32.51 | starseeker | I think that's the relevant part of stdio.h |
| 02:33.46 | brlcad | yep, that's it |
| 02:34.56 | brlcad | starseeker: try adding this: # define _ftelli64 _ftelli64_hidden |
| 02:35.07 | brlcad | to the config header with the define for ftelli |
| 02:35.30 | brlcad | and same for fseek |
| 02:35.54 | brlcad | or just ftelli64 and see if fseek needs it |
| 02:37.48 | starseeker | I'm adding that before the #define ftell line? |
| 02:41.11 | starseeker | it's complaining about redefining _ftelli64 now... |
| 02:42.11 | starseeker | or rather, redefining _ftelli64_hidden |
| 02:44.29 | brlcad | has to be after |
| 02:44.55 | brlcad | ftell to _ftelli64 |
| 02:45.10 | brlcad | _ftelli64 to anything else |
| 02:45.24 | starseeker | trying... |
| 02:46.12 | Notify | 03BRL-CAD:brlcad * 55411 (brlcad/trunk/include/bu.h brlcad/trunk/src/libbu/bitv.c): make bu_bitv_shift() return a size_t instead of an unsigned int in order to avoid a type downcast warning on windows |
| 02:46.50 | starseeker | http://paste.lisp.org/display/137150 |
| 02:47.15 | starseeker | (just a snippit - lots more where that came from) |
| 03:10.50 | brlcad | still thinking, their preprocessor seems to be behaving a little different too |
| 03:11.41 | starseeker | has to hit the hay - I'll keep the Windows install for a little bit before trying a Linux install so we can do some tests |
| 03:12.05 | starseeker | (yay VirtualBox!) |
| 04:30.21 | *** join/#brlcad kesha (~kesha@49.249.1.164) | |
| 04:32.31 | *** join/#brlcad zero_level (~0_level@14.139.82.6) | |
| 04:35.31 | Notify | 03BRL-CAD:brlcad * 55412 (brlcad/trunk/include/bu.h brlcad/trunk/src/libbu/bitv.c): promote bitv to using size_t instead of unsigned int, quells warnings on windows |
| 04:53.22 | *** join/#brlcad zero_level (~androirc@14.139.82.6) | |
| 05:14.29 | *** join/#brlcad caen23 (~caen23@92.83.177.177) | |
| 05:51.46 | *** join/#brlcad kesha (~kesha@49.249.1.164) | |
| 05:56.45 | *** join/#brlcad zero_level (~androirc@14.139.82.6) | |
| 06:20.23 | *** join/#brlcad kesha (~kesha@49.249.1.164) | |
| 06:39.16 | *** join/#brlcad kesha (~kesha@49.249.1.164) | |
| 06:56.57 | *** join/#brlcad kesha (~kesha@49.249.1.164) | |
| 07:03.19 | *** join/#brlcad kesha (~kesha@49.249.1.164) | |
| 07:39.45 | *** join/#brlcad kesha (~kesha@49.249.1.164) | |
| 07:50.22 | *** join/#brlcad kesha (~kesha@49.249.1.164) | |
| 08:10.38 | *** join/#brlcad kesha (~kesha@49.249.1.164) | |
| 08:21.34 | *** join/#brlcad kesha (~kesha@49.249.1.164) | |
| 08:31.01 | *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua) | |
| 08:49.38 | *** join/#brlcad kesha_ (~kesha@49.249.1.164) | |
| 10:14.09 | *** join/#brlcad zero_level (~androirc@14.139.82.6) | |
| 12:12.49 | *** join/#brlcad crdueck_ (~cdk@24.212.219.10) | |
| 12:32.18 | Notify | 03BRL-CAD:bob1961 * 55413 brlcad/trunk/src/tclscripts/mged/mged.tcl: This fixes the problem encountered when a user calls dbclose (why is dbclose exposed to the user?) and then tries to open a database. |
| 13:35.58 | *** join/#brlcad avneet (~avneet@202.164.53.122) | |
| 14:18.46 | *** join/#brlcad zero_level (~androirc@14.139.82.6) | |
| 14:34.23 | Notify | 03BRL-CAD:starseeker * 55414 brlcad/trunk/include/bu.h: Need to restore the undef of INFINITY as well for the value reversion to succeed. |
| 14:34.28 | *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua) | |
| 14:49.31 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 14:56.41 | *** join/#brlcad Ch3ck (~Ch3ck@41.205.14.41) | |
| 15:01.30 | brlcad | hi Ch3ck |
| 15:03.45 | Ch3ck | Hi brlcad |
| 15:03.58 | Ch3ck | trying to work on a new code patch.. |
| 15:04.15 | Ch3ck | which involves combining the push and xpush routines into one |
| 15:09.58 | brlcad | awesome, how's it going with that? |
| 15:12.56 | Ch3ck | well trying to see how i can integrate the push src into the xpush |
| 15:13.12 | Ch3ck | which i believe will be easier to implement.. |
| 15:13.13 | brlcad | hm |
| 15:13.17 | Ch3ck | just started today.. |
| 15:13.34 | Ch3ck | well any pointers? on how i can go about it? |
| 15:14.10 | brlcad | well you either merge push into xpush or xpush into push ;) |
| 15:14.27 | brlcad | or just write a new command that combines the behaviors of both sensibily |
| 15:14.41 | Ch3ck | yeah i'm trying to merge push into xpush.. |
| 15:14.47 | Ch3ck | ok |
| 15:15.31 | Ch3ck | well i think i could add some conditions into the xpush which can execute the normal push easily.. |
| 15:15.32 | brlcad | the real simple solution would be to add a -x option to push and just call the xpush routine |
| 15:15.45 | Ch3ck | wow |
| 15:15.50 | Ch3ck | thats nice.. |
| 15:15.57 | Ch3ck | well i'll try to see how i can do that... |
| 15:16.07 | Notify | 03BRL-CAD:bob1961 * 55415 brlcad/trunk/src/libged/put.c: Already checking if dbip is NULL in the call to GED_CHECK_DATABASE_OPEN. |
| 15:16.20 | Ch3ck | So by when am I expected to have submitted the code patch? |
| 15:16.22 | brlcad | but that has its drawbacks, push should probably "xpush" by default and have an option to not split |
| 15:16.39 | Ch3ck | ok |
| 15:16.56 | brlcad | plus codewise, it's desirable to not just lump them all together, one loop that does the right thing |
| 15:17.27 | brlcad | timeframe is by the end of this week ideally |
| 15:17.30 | Notify | 03BRL-CAD:bob1961 * 55416 brlcad/trunk/src/libged/adjust.c: No need to call GED_CHECK_DATABASE_OPEN twice. |
| 15:18.10 | Ch3ck | well |
| 15:18.13 | brlcad | it was supposed to have been submitted before the application deadline, so just as soon as you can ;) |
| 15:18.13 | *** join/#brlcad merzo_ (~merzo@user-94-45-58-138-1.skif.com.ua) | |
| 15:18.16 | Ch3ck | i updated my proposal on the wiki.. |
| 15:18.21 | brlcad | i saw |
| 15:18.21 | Ch3ck | is it still valid? |
| 15:18.33 | Ch3ck | ok |
| 15:18.42 | brlcad | sure, it's not about the deadline or rules, it's about doing good work and demonstrating what you can do |
| 15:19.32 | brlcad | if you have at least a full day to work on it, I'd suggest trying to write a new command that combines them both |
| 15:19.52 | brlcad | if you don't, go for xpush into push or push into xpush as an option |
| 15:20.18 | Ch3ck | ok |
| 15:20.43 | Ch3ck | just kept working on the problem so as soon as i got something further on tackling the problem |
| 15:20.50 | Ch3ck | i thought it would be good to post on the wiki pages.. |
| 15:21.10 | Ch3ck | well since i have some school projects i'm currently working on |
| 15:21.27 | Ch3ck | i'll dedicate the whole of thursday to the problem |
| 15:21.46 | Ch3ck | just gathering some more ideas on how i can tackle the problem.. |
| 15:22.52 | brlcad | it's a good time to try to apply a "code complete" practice to how you approach the problem |
| 15:23.19 | Ch3ck | yeah |
| 15:23.20 | Ch3ck | thats what i'm trying to do now.. |
| 15:23.20 | brlcad | a partial patch is completely useless, so you should always have the code and any changes you make in a "complete" state |
| 15:24.46 | Ch3ck | ok |
| 15:24.54 | Ch3ck | ok |
| 15:29.14 | brlcad | ok |
| 15:29.17 | brlcad | ok |
| 15:29.45 | Ch3ck | Thanks very much brlcad |
| 15:29.51 | Ch3ck | gotta go to class |
| 15:29.54 | Ch3ck | will be in touch.. |
| 15:30.08 | Ch3ck | bye |
| 15:30.56 | brlcad | cya |
| 15:32.01 | *** join/#brlcad kesha (~kesha@49.202.231.197) | |
| 16:38.26 | *** join/#brlcad rays2pix (~deepak@110.234.229.2) | |
| 16:48.57 | Notify | 03BRL-CAD:carlmoore * 55417 brlcad/trunk/src/anim/anim_track.c: list the options for anim_track so I can move on to another file |
| 16:50.41 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) | |
| 16:55.48 | Notify | 03BRL-CAD:carlmoore * 55418 brlcad/trunk/src/anim/anim_turn.c: h, ?, Usage |
| 17:13.45 | Notify | 03BRL-CAD:indianlarry * 55419 brlcad/trunk/src/librt/primitives/brep/brep.cpp: Adding bail-out when the step would walk outside the current SBV broke other surface walks, now closer to original stepping with a half-step backward when overstep based on UV points(after pushback into current SBV). If doesn't find a closer root goes to next iteration like before. |
| 17:20.31 | Notify | 03BRL-CAD:brlcad * 55420 brlcad/trunk/sh/cmp.sh: even more coarse for testing, 256x256 |
| 17:23.24 | Notify | 03BRL-CAD:brlcad * 55421 brlcad/trunk/sh/cmp.sh: comment out the bot/tie testing too |
| 17:26.22 | Notify | 03BRL-CAD:carlmoore * 55422 brlcad/trunk/src/util/ap-pix.c: implement h,? |
| 17:51.04 | Notify | 03BRL-CAD:carlmoore * 55423 brlcad/trunk/src/conv/nmg/asc-nmg.c: implement h,? |
| 18:11.37 | Notify | 03BRL-CAD:carlmoore * 55424 brlcad/trunk/src/util/asc-pl.c: implement -h, -? |
| 18:22.40 | Notify | 03BRL-CAD:carlmoore * 55425 brlcad/trunk/src/conv/asc/asc2g.c: implment -h,-? ; also fix compiler warnings |
| 19:15.10 | *** join/#brlcad merzo (~merzo@48-124-132-95.pool.ukrtel.net) | |
| 19:47.59 | Notify | 03BRL-CAD:carlmoore * 55426 brlcad/trunk/src/util/azel.c: already had -?, but implemented -h, along with run-with-no-arguments help (program continues running) |
| 20:41.03 | *** join/#brlcad merzo (~merzo@48-124-132-95.pool.ukrtel.net) | |
| 20:56.11 | *** join/#brlcad vladbogo (~vlad@188.25.239.64) | |
| 21:36.50 | Notify | 03BRL-CAD:carlmoore * 55427 brlcad/trunk/src/util/bary.c: implement -h and run-with-no-arguments; -? was already present |
| 21:50.21 | Notify | 03BRL-CAD:starseeker * 55428 (brlcad/trunk/CMakeLists.txt brlcad/trunk/include/bu.h and 31 others): Try using macro re-definitions for all the 64 bit functions except ftell and fseek. For those two, add function test and tweak wrapper definitions. |
| 22:09.50 | *** join/#brlcad jasleen_ (~chatzilla@117.253.202.77) | |
| 22:37.54 | *** join/#brlcad mpictor (~mark@99-93-104-202.lightspeed.iplsin.sbcglobal.net) | |