| 00:09.22 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 00:12.23 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) | |
| 01:15.43 | *** join/#brlcad cristina (~quassel@188.24.71.103) | |
| 01:16.16 | *** join/#brlcad cristina (~quassel@188.24.71.103) | |
| 01:16.58 | *** join/#brlcad cristina (~quassel@188.24.71.103) | |
| 01:17.50 | *** join/#brlcad cristina (~quassel@188.24.71.103) | |
| 01:19.14 | *** join/#brlcad cristina (~quassel@188.24.71.103) | |
| 01:49.00 | CIA-55 | BRL-CAD: 03crdueck * r50828 10/brlcad/trunk/include/raytrace.h: added pointers to new volume, surface area, and centroid callback functions in functab struct. WIP |
| 02:10.22 | CIA-55 | BRL-CAD: 03crdueck * r50829 10/brlcad/trunk/src/librt/primitives/table.c: updated rt_functab entries for primitives to reflect changes in r50828 |
| 02:37.13 | CIA-55 | BRL-CAD: 03Al Da Best 07http://brlcad.org * r3793 10/wiki/User:Al_Da_Best/devlog: Update for 2nd June 2012 |
| 02:45.13 | CIA-55 | BRL-CAD: 03Phoenix 07http://brlcad.org * r3794 10/wiki/User:Phoenix/GSoc2012/Reports: /* Week 2 */ |
| 02:45.52 | CIA-55 | BRL-CAD: 03Phoenix 07http://brlcad.org * r3795 10/wiki/User:Phoenix/GSoc2012/Reports: /* Week 1 */ |
| 02:46.13 | CIA-55 | BRL-CAD: 03Phoenix 07http://brlcad.org * r3796 10/wiki/User:Phoenix/GSoc2012/Reports: /* Week 2 */ |
| 02:46.47 | CIA-55 | BRL-CAD: 03Phoenix 07http://brlcad.org * r3797 10/wiki/User:Phoenix/GSoc2012/Reports: /* Week 2 */ |
| 03:02.50 | CIA-55 | BRL-CAD: 03Crdueck 07http://brlcad.org * r3798 10/wiki/User:Crdueck/log: |
| 03:46.56 | *** join/#brlcad DarkCalf (~DarkCalf@173.231.40.99) | |
| 08:27.08 | *** join/#brlcad stas (~stas@188.24.41.118) | |
| 09:11.52 | *** join/#brlcad ksuzee (~ksuzee91@193.151.105.83) | |
| 11:46.44 | *** join/#brlcad cristina_ (~quassel@188.24.64.37) | |
| 12:14.50 | *** join/#brlcad cristina (~quassel@unaffiliated/cristina) | |
| 12:32.25 | *** join/#brlcad Al_Da_Best (~Al_Da_Bes@elvyn-248-109.halls.student.lut.ac.uk) | |
| 14:28.22 | *** join/#brlcad _fkr (el@norge.sdf.org) | |
| 14:50.17 | _fkr | Suppose I launch 7.20.6, open a db, then do Modes->Display\ Manager->Tk ; I get a crash (could not access memory at addrss 0x00...). src/libfb/tcl.c:291 tries to do if (!strncmp(ifp->if_name, X_device_name, strlen(X_device_name))) while ifp->if_name is 0x0 |
| 14:51.29 | _fkr | That code is #ifdef IF_X, but there is #ifdef IF_TK also available in fb_configureWindow function. Exec does not reach there. |
| 14:52.33 | _fkr | Not sure if I have tcl/tk set up a bit in a hurry and messed the local setup up. I needed to upgrade from 8.4 to 8.5 and might have some old files laying around and so on. |
| 14:54.44 | _fkr | if I have the disp manager as X, ifp->if_name is "/dev/X" and things seem to be more OK. |
| 14:59.25 | _fkr | If I start single stepping from tcl.c:291 I get some cannot access memory at address 0x0, but they are not fatal. That Tk one causes kernel proection failure and a crash. |
| 15:00.45 | _fkr | Have not looked deeper so far... and it's 7.20.6 with pathes 1-4 applied, not current source. |
| 15:03.25 | _fkr | s/th/cth/ |
| 15:03.44 | _fkr | or tch even, heh |
| 18:49.54 | *** join/#brlcad ksuzee (~ksuzee91@193.151.105.83) | |
| 18:54.40 | brlcad | _fkr: three points |
| 18:54.59 | brlcad | _fkr: 1: it shouldn't crash, thanks for the report |
| 18:55.36 | brlcad | _fkr: 2: the tk display manager is experimental, so shouldn't even really be enabled unless you plan to work on it.. |
| 18:56.58 | brlcad | _fkr: 3: thanks for the debugging pinpoint that particular crash looks easy to prevent (though undoubtedly more issues) |
| 19:27.45 | *** join/#brlcad yukonbob (~bch@50.46.78.234) | |
| 19:31.48 | cristina | has anyone compiled brlcad with the revision 50829? |
| 19:36.18 | cristina | I am getting erorrs for these files: brlcad/src/conv/step/PullbackCurve.cpp, brlcad/src/conv/step/OpenNurbsInterfaces.cpp and brlcad/src/conv/g-voxel.c - gcc4.6 treats the warnings: "variable '...' set but not used [-Wunused-but-set-variable]" as errors |
| 19:43.36 | _fkr | Just checking whether it's just me, or others get similar results. Not worrying about it, just wanted to test and it's good if I actually managed to find a small problem. |
| 19:46.26 | _fkr | One could just compile without-tcl and without-tk and not lose functionality? |
| 19:55.29 | _fkr | perhaps you could get it compiling with less strict settings, cristina? It's probably better to find out the cause. Does the name suggest where someone wanted to use that variable? Perhaps e forgot about it completely and it's safe to just to remove the part of the code that sets it. |
| 19:58.24 | cristina | _fkr: I know exactly where the error is. I commented the declaration of those variables and everything compiles. however, I don't know if it's ok to commit these |
| 19:59.32 | cristina | this is why I am asking because I might be having some stricter settings than anyone else. My cmake command is cmake -DCMAKE_BUILD_TYPE=Debug -DBRLCAD_BUNDLED_LIBS=Bundled . |
| 20:01.19 | _fkr | strict is good if you're developing. Better to know if something is wrong and react by trying to clean code, even if it's a small problem and it still compiles. |
| 20:03.58 | *** join/#brlcad andrei_ (~andrei@5-12-78-85.residential.rdsnet.ro) | |
| 20:09.36 | _fkr | If you want to commit it's another issue, whether it would be better to remove the code completely or to just comment it out. Matter of taste of course and some projects might have specific coding rules for that kind of issues. |
| 20:48.20 | *** part/#brlcad ksuzee (~ksuzee91@193.151.105.83) | |
| 21:05.25 | crdueck | cristina: i'm getting the same errors, its not just you. |
| 21:20.15 | _fkr | You could tune compiler settings or just modify the source. |
| 21:26.45 | crdueck | I could, but svn annotate shows that it was added recently by anagmurty. its certainly related to his GSoC project |
| 21:28.30 | cristina | crdueck: that's right. It was added about 50 hours ago. Do you get errors for the other files as well? |
| 21:30.39 | crdueck | i get errors in conv/g-voxel.c and conv/3dm/3dm-g.cpp |
| 21:30.53 | _fkr | modify your own copy and compile or just a recent successful build. |
| 21:30.57 | crdueck | there could be more but the built stops there |
| 21:31.08 | crdueck | _fkr: i have, and it compiles. thats not really the problem |
| 21:34.29 | cristina | _fkr: same thing here, I have my modified copy that works. I was curious if it was something that only I have encountered |
| 21:38.09 | _fkr | Perhaps someone had an idea, started to write something and then just stopped... perhaps even forgot about it. I guess it's a bit bad practice. |
| 21:39.47 | _fkr | What are you up to there anyways? What are you working with or what are you doing in general, if you do not mind me being curious? |
| 21:40.11 | _fkr | I'm about to force myself to rest soon. Have a few hours of resting time left... |
| 21:55.56 | brlcad | cristina: if depends on the caller code in question, but you can usually remove set-but-unused variables |
| 21:56.10 | CIA-55 | BRL-CAD: 03brlcad * r50830 10/brlcad/trunk/src/libfb/tcl.c: prevent a crash if we somehow try to configure a framebuffer that has not yet been initialized. (crash reported by _fkr via irc selecting Modes->Display\ Manager->Tk after opening a db) |
| 21:56.43 | brlcad | usually is just variations in the versions of gcc being used, that's why the default is strict so we can catch as much as possible |
| 21:58.04 | brlcad | we all get those and are fine to fix them, even if it's in code we didn't change -- compilation warnings are usually trivial and quick to fix |
| 21:58.43 | cristina | I see, so should I fix the code in question? |
| 21:58.48 | brlcad | yep |
| 21:58.54 | brlcad | but not by commenting it out |
| 21:59.09 | brlcad | the variable needs to be used or removed |
| 21:59.34 | brlcad | figuring out which depends on the specific case |
| 21:59.53 | cristina | ok, thanks. I will look into it. One of it is anagmurty's and it's a recent change. He might need it |
| 22:00.10 | cristina | s/one of it/one of them |
| 22:01.03 | brlcad | if anurag returns, you can also punt it over to him |
| 22:01.58 | cristina | ok, thanks brlcad |
| 22:02.20 | brlcad | he might eventually need it, but it's not being used now so coding "complete" means it goes away (now) or code gets added so it's used |
| 22:03.43 | cristina | brlcad: I want to integrate adaptagrams' libavoid library. This should be added into the src/other folder, right? The entire source code for libavoid, not just the headers and the library? |
| 22:04.19 | brlcad | cristina: eventually yes but I'd suggest starting with it as a system-installed dependency |
| 22:04.34 | CIA-55 | BRL-CAD: 03starseeker * r50831 10/brlcad/trunk/misc/CMake/ (BRLCAD_CPackOptions.cmake.in Distcheck.cmake): Make sure there aren't any stale source_archive_contents dirs when creating packages |
| 22:04.38 | brlcad | that's the usual practice for a new dependency being introduced |
| 22:05.05 | _fkr | I like the idea of removing instead of commenting it out too. You can later just return to the revision that had it in if you need. |
| 22:05.10 | brlcad | a build test is added that checks for its existence, and it's used if its found or the code is turned off if it's not |
| 22:05.21 | cristina | brlcad: okay, so I'll leave it for now and come back to it later |
| 22:06.01 | brlcad | cristina: yeah, I suggest putting a reminder in your schedule in late july after more progress is made |
| 22:06.13 | CIA-55 | BRL-CAD: 03starseeker * r50832 10/brlcad/trunk/misc/CMake/BRLCAD_CPackOptions.cmake.in: consistency |
| 22:08.10 | CIA-55 | BRL-CAD: 03brlcad * r50833 10/brlcad/trunk/src/conv/g-voxel.c: ugh. looks like vim crapped all over the file. files should be run through sh/ws.sh to remove trailing whitespace. |
| 22:08.57 | CIA-55 | BRL-CAD: 03brlcad * r50834 10/brlcad/trunk/src/conv/g-voxel.c: no spaces before semicolons |
| 22:09.28 | cristina | brlcad: Should this build test be added now? For now, to check if it is a system-installed library or just when the library is integrated into brlcad? |
| 22:11.19 | starseeker | cristina: I wouldn't worry about it at this stage |
| 22:12.28 | starseeker | once you have some functionality going, it's worth it to futz with the build logic - if you just need it defined in the cmake logic for your own testing, you can call find_library directly |
| 22:14.04 | starseeker | cmake --help-command find_library provides docs for the command, but you won't need to worry about all the bells and whistles - you just want it to define a variable pointing to your installed libavoid that you can use for linking |
| 22:14.05 | cristina | I see, thank you starseeker for the clarification |
| 22:15.09 | starseeker | a full src/other inclusion is a significant undertaking - more tedious than difficult, but definitely enough effort that we want to be sure we need it |
| 22:15.12 | brlcad | cristina: you obviously need to add build flags now in order to use it, so you could add a cmake check in order to find the system-installed version |
| 22:15.51 | brlcad | the point is to avoid the src/other inclusion until it's already not intended to be used, but basically when it's "in use and done" |
| 22:16.50 | starseeker | for example, we still don't have src/other support for the bullet or open shader language libraries |
| 22:17.31 | brlcad | and yet cmake still tests for them and uses them when it finds them -- so you're doing something similar |
| 22:18.01 | CIA-55 | BRL-CAD: 03brlcad * r50835 10/brlcad/trunk/src/conv/g-voxel.c: more cleanup, match our style. spaces after intrinsic keywords and within comments. |
| 22:18.28 | cristina | that makes sense :). No need to add it yet. So I will test its existence in a CMakeLists.txt file where I'd use the find_library command |
| 22:18.45 | brlcad | lets anuragmurty off the hook on the warnings (compiles clean with 4.2) but not for all his style crap not following hacking.. |
| 22:19.08 | brlcad | cristina: if you grep for bullet, you should find similar settings you'll need |
| 22:20.54 | brlcad | cristina: which variables were unused? |
| 22:21.56 | cristina | brlcad: in g-voxel.c: http://pastebin.mozilla.org/1654808 |
| 22:23.00 | cristina | and this is another round of errors http://pastebin.mozilla.org/1654812 |
| 22:30.09 | _fkr | you could make it mandatory to filter files through something that ensures proper style is used before people share their stuff. Through indent or something similar... But if you have at least written some codingstyle document, then I guess people should be careful not following it. |
| 22:30.54 | CIA-55 | BRL-CAD: 03brlcad * r50836 10/brlcad/trunk/src/conv/g-voxel.c: quell set-but-unused warnings. coding complete means not stubbing in variables, not adding until they're actually used. |
| 22:31.42 | brlcad | cristina: to be pedantically correct -- it's not that they're "errors" but they are issues that we treat as errors in order to maintain a higher quality of code |
| 22:32.27 | brlcad | they are technically compilation warnings and should be referred to as such :) |
| 22:33.18 | brlcad | cristina: the C++ warnings are also worth fixing (particularly when they're similarly simple set-but-not-used warnings) .. but they do not halt compilation |
| 22:33.34 | cristina | brlcad: I meant errors because they were treated as errors. I am aware that they were warnings but I had to call them somehow in order to explain why the compilation stopped |
| 22:33.53 | _fkr | small problems might get bigger with time, or lots of small problems might create a bigger one. Unused variables, code commented out instead of removing it would add to the total lines and make it harder to read and understand faster. You start looking for some defined variable just to see that you have wasted your time. If it wasnt there in the first place there would be less confusion. |
| 22:33.54 | brlcad | I know, like I said -- just a pedantic technicality |
| 22:34.14 | brlcad | some people really do see them as errors and that's not 100% valid all the time |
| 22:34.40 | brlcad | c++ has some false positives, for example, that cannot be quieted -- which is why they don't halt |
| 22:35.28 | cristina | :) I'll keep in mind this (It was specified somewhere near the end that they are in fact warnings but the settings asked for them to be considered errors) |
| 22:35.34 | brlcad | _fkr: are you going to set that "something filter" up? :) |
| 22:36.00 | brlcad | cristina: you're probably reading the output interleaved with the failure in g-voxel treating those as errors |
| 22:36.11 | brlcad | the c++ ones aren't (ever I believe) treated as errors |
| 22:37.01 | brlcad | i've actually had it in mind to make some sections of our c++ just as strict, but haven't gotten into the build mods that would be needed |
| 22:37.25 | _fkr | Hehe. Not now at least, but I might keep it in mind that there is a need for it. Is there some codingstyle document or something available at the moment or are the rules in progress? Some like 4 spaces as a tab, some like 8, some 2 and so on. I mean are there recommendations about this project? |
| 22:38.10 | brlcad | our HACKING file talks about our style guidelines to a minimum level of detail and there's a preliminary astyle config that gets close |
| 22:38.13 | _fkr | Perhaps rewrite c++ in c or something.. I do not know c++, but have had a feeling many people have negative feelings about it... |
| 22:38.44 | CIA-55 | BRL-CAD: 03starseeker * r50837 10/brlcad/trunk/regress/CMakeLists.txt: distcheck strikes again. Add new regression files to regress/CMakeLists.txt |
| 22:38.59 | brlcad | there's little value in that exercise for the sake of warnings -- the issues are in headers we don't control, otherwise we could quell them |
| 22:41.55 | starseeker | brlcad: I didn't realize you wanted to selectivly enable strict for the C++ code - I can try taking a stab at that if you think parts of our code are able to build strict |
| 22:42.22 | brlcad | there are portions that build clean now -- I think I got all of librt |
| 22:42.51 | starseeker | hmm |
| 22:43.15 | brlcad | conv is close if someone(tm) ever gets the few remaining step ones I left for keith |
| 22:43.57 | brlcad | code that uses stl like libpc is the harder-to-quell code iirc |
| 22:44.10 | brlcad | several of our src/other deps, etc |
| 22:44.11 | starseeker | thought librt pulled in opennurbs headers that caused strict failures... |
| 22:44.46 | brlcad | maybe, but I fixed most or all of them a long while back |
| 22:45.00 | starseeker | tries it once... |
| 22:45.20 | brlcad | quick test here is clean |
| 22:45.40 | brlcad | (4.2) |
| 22:47.30 | starseeker | huh - yeah, looks OK here too |
| 22:49.25 | starseeker | alrightie, let me ponder a bit |
| 22:52.34 | cristina | brlcad: I'm still getting one warning :D http://pastebin.mozilla.org/1654830 |
| 22:53.23 | cristina | there's one variable left, numVoxelX, that is just set but never used - in main |
| 23:07.04 | *** join/#brlcad tbrowder2 (~tbrowder@fl-67-235-134-204.dhcp.embarqhsd.net) | |