| 00:00.36 | CIA-61 | BRL-CAD: 03brlcad * r36514 10/brlcad/trunk/src/libbn/fortran.c: remove the ifdopn/IFDOPN fortran wrapper as it uses fdopen() which supposedly isn't in c99 (yet is c89). old unpublished interface, see if anyone is affected. |
| 00:33.24 | CIA-61 | BRL-CAD: 03brlcad * r36515 10/brlcad/trunk/src/libbu/ (backtrace.c brlcad_path.c crashreport.c): quell a variety of compliance warnings. popen, kill, and fileno are annoyingly not in c99. |
| 00:44.31 | CIA-61 | BRL-CAD: 03brlcad * r36516 10/brlcad/trunk/src/libbu/malloc.c: in more than 15 years, i've not derived any useful value knowing sbrk(0) on an out-of-memory state. bye. |
| 00:47.58 | CIA-61 | BRL-CAD: 03brlcad * r36517 10/brlcad/trunk/src/libbu/parse.c: there's no point in limiting parsing to chars < 127, testing if it's a space is sufficient |
| 00:48.44 | CIA-61 | BRL-CAD: 03brlcad * r36518 10/brlcad/trunk/src/libbu/parse.c: another isascii() |
| 00:58.15 | CIA-61 | BRL-CAD: 03brlcad * r36519 10/brlcad/trunk/src/libbu/ (9 files): |
| 00:58.19 | CIA-61 | BRL-CAD: quell a slew of additional warnings for strict mode compilation. we still use |
| 00:58.21 | CIA-61 | BRL-CAD: non-c99 functions, but have to declare them ourselves if it's a strict |
| 00:58.25 | CIA-61 | BRL-CAD: compliance compile (configure takes care of when they're not available at all |
| 00:58.34 | CIA-61 | BRL-CAD: for some symbols). re-enable STRICT_FLAGS. |
| 01:03.27 | CIA-61 | BRL-CAD: 03brlcad * r36520 10/brlcad/trunk/configure.ac: test for popen, used by libbu in a few places |
| 01:37.33 | Emton | hello |
| 01:37.35 | Emton | ? |
| 01:37.58 | Emton | anybody know the rate tabinterp directive well?? |
| 01:38.42 | Emton | I put in a step value of -15 and it's dropping me by 3.5 |
| 01:38.44 | Emton | weird |
| 01:39.02 | Emton | $ cat tabinterpcmds |
| 01:39.03 | Emton | file chans.vsize -; |
| 01:39.03 | Emton | file chans.eyept - - 3; |
| 01:39.03 | Emton | file chans.orient 4 5 6 7; |
| 01:39.03 | Emton | times 0 12 4; |
| 01:39.03 | Emton | rate 0 439.42 0; |
| 01:39.04 | Emton | rate 1 76.2 0; |
| 01:39.06 | Emton | rate 2 52.07 -14; |
| 01:39.08 | Emton | interp cspline 3 4 5 6 7; |
| 01:40.26 | Emton | channel 2, first val = 52.07 |
| 01:40.44 | Emton | channel 2, second val = 38.9845 |
| 01:40.44 | Emton | whoops |
| 01:41.10 | Emton | channel 2, second val = 48.57 |
| 01:41.42 | Emton | ** read from the sentinel file ** |
| 03:17.07 | starseeker | installs llvm and clang |
| 03:17.35 | starseeker | can't do much in the way of c++, otherwise it would be fun to try a BRL-CAD compile |
| 03:17.46 | starseeker | suppose llvm-gcc might work |
| 03:41.33 | *** join/#brlcad CIA-13 (n=CIA@208.69.182.149) | |
| 03:49.37 | Emton | ok, in tabinterp.c->rate_interpolate() |
| 03:49.37 | Emton | chp->c_oval[t] = ival + rate * times[t]; |
| 03:49.37 | Emton | should probably be: chp->c_oval[t] = ival + rate * t; |
| 03:49.37 | Emton | i'm backing up and will try to compile and see if it works |
| 03:58.36 | *** join/#brlcad CIA-28 (n=CIA@208.69.182.149) | |
| 04:02.33 | *** join/#brlcad R0b0t1 (n=Enigma@unaffiliated/r0b0t1) | |
| 04:03.12 | starseeker | heh |
| 04:03.15 | starseeker | ../../../brlcad/src/libbu/crashreport.c:75:21: error: format string is not a string literal |
| 04:03.18 | starseeker | <PROTECTED> |
| 04:03.21 | starseeker | <PROTECTED> |
| 04:03.23 | starseeker | <PROTECTED> |
| 04:03.41 | starseeker | must say he like's clang's approach to error reporting at least |
| 04:06.48 | *** join/#brlcad Notme (n=yas@47.18.28.72.cpe.echoes.net) | |
| 04:07.17 | Notme | niven went down, but i did compile and it appears to work correclty now =) |
| 04:09.50 | Notme | if i had SVN access, i would post but the change is in src/tab/tabinterp.c->rate_interpolate() |
| 04:10.21 | Notme | last line before end of FOR loop should read: chp->c_oval[t] = ival + rate * t; |
| 04:10.52 | starseeker | Notme: make a patch and submit it to sf |
| 04:11.04 | Notme | huh? |
| 04:11.35 | Notme | not familiar w/the process of open source dev |
| 04:11.46 | Notme | I got SVN but no privileges |
| 04:12.04 | starseeker | yeah - you do an svn diff to see what changes were made |
| 04:12.31 | Notme | what do you mean, i'm giving the change |
| 04:12.39 | starseeker | cd src/tab |
| 04:12.41 | starseeker | svn diff |
| 04:12.51 | Notme | ok hang on |
| 04:13.01 | starseeker | let me check if brlcad has a preferred way to make a patch |
| 04:13.28 | Notme | lol, i use tortoise really not cmdline |
| 04:13.36 | starseeker | erm |
| 04:13.46 | Notme | is not my copy there, where i compiled |
| 04:13.59 | starseeker | ok, well svn diff > tabinterp.c.patch would work |
| 04:14.27 | starseeker | Notme: check the file HACKING in the toplevel |
| 04:15.00 | Notme | alright, i think i need privs tho to do any updates |
| 04:15.17 | Notme | i'm not pulling from the https trunk |
| 04:15.51 | starseeker | yeah, first you submit a patch here: http://sourceforge.net/tracker/?group_id=105292&atid=640804 |
| 04:15.55 | Notme | btw, it's me Emton in case u didnt realize |
| 04:16.00 | starseeker | figured :-) |
| 04:16.05 | Notme | heh |
| 04:16.17 | starseeker | then it gets reviewed by a dev and incorporated |
| 04:16.25 | starseeker | takes a little while to get commit access |
| 04:16.42 | Notme | yea, that makes sense |
| 04:17.49 | Notme | i remember when i gen'd the html pages from man was a process, hmm.. |
| 04:20.41 | Notme | ok, i got the diff |
| 04:21.11 | Notme | line 782, tabinterp.c |
| 04:40.07 | Notme | i dunno, sourceforge signup email not showing up |
| 04:40.25 | Notme | starseeker if u got an account u can post it up |
| 04:40.41 | Notme | *if u don't mind* =) |
| 05:31.22 | Notme | alright is put up in the patches |
| 07:25.50 | *** join/#brlcad d_rossberg (n=rossberg@BZ.BZFLAG.BZ) | |
| 07:41.42 | CIA-28 | BRL-CAD: 03d_rossberg * r36521 10/brlcad/trunk/src/libbu/fchmod.c: there is no mode_t in MSVC |
| 08:00.26 | *** join/#brlcad akafubu (n=akafubu@c-71-228-183-181.hsd1.al.comcast.net) [NETSPLIT VICTIM] | |
| 10:01.21 | *** join/#brlcad mafm (n=mafm@cpc2-bexl3-0-0-cust843.bmly.cable.ntl.com) | |
| 12:23.04 | *** join/#brlcad parigaudi (n=quassel@pd95b7f5e.dip0.t-ipconnect.de) | |
| 13:27.37 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1802 10/wiki/Talk:BRL-CAD_Commands: |
| 13:30.03 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1803 10/wiki/MGED_CMD_cp: |
| 13:30.12 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1804 10/wiki/MGED_CMD_cpi: |
| 13:31.11 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1805 10/wiki/MGED_CMD_db: |
| 13:31.11 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1806 10/wiki/MGED_CMD_db_glob: |
| 13:31.12 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1807 10/wiki/MGED_CMD_dbbinary: |
| 13:31.12 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1808 10/wiki/MGED_CMD_dbconcat: |
| 13:33.43 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1809 10/wiki/MGED_CMD_dbfind: |
| 13:34.00 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1810 10/wiki/MGED_CMD_dbfindtree: |
| 13:34.08 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1811 10/wiki/MGED_CMD_debugbu: |
| 13:34.18 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1812 10/wiki/MGED_CMD_status: |
| 13:34.27 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1813 10/wiki/MGED_CMD_sph-part: |
| 13:34.47 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1814 10/wiki/MGED_CMD_solids_on_ray: |
| 13:35.00 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1815 10/wiki/MGED_CMD_solids: |
| 13:35.04 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1816 10/wiki/MGED_CMD_size: |
| 13:35.14 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1817 10/wiki/MGED_CMD_showmats: |
| 13:35.23 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1818 10/wiki/MGED_CMD_shells: |
| 13:35.27 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1819 10/wiki/MGED_CMD_share: |
| 13:35.35 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1820 10/wiki/MGED_CMD_set_more_default: |
| 13:35.41 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1821 10/wiki/MGED_CMD_sed: |
| 13:35.48 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1822 10/wiki/MGED_CMD_sca: |
| 13:35.58 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1823 10/wiki/MGED_CMD_ls: |
| 13:36.04 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1824 10/wiki/MGED_CMD_lookat: |
| 13:36.20 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1825 10/wiki/MGED_CMD_loadtk: |
| 13:36.37 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1826 10/wiki/MGED_CMD_l_muves: |
| 13:44.26 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1827 10/wiki/MGED_CMD_aip: |
| 13:45.24 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1828 10/wiki/MGED_CMD_cmd_win: |
| 13:45.47 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1829 10/wiki/Category:MGED_developer_commands: New page: [[category:MGED]] |
| 13:49.21 | CIA-28 | BRL-CAD: 03starseeker * r36522 10/brlcad/trunk/src/libbu/ (10 files): Take a stab at cleaning up some warnings in libbu with llvm-gcc. |
| 13:57.03 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1830 10/wiki/MGED_CMD_collaborate: |
| 13:57.17 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1831 10/wiki/MGED_CMD_get_edit_solid: |
| 13:57.28 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1832 10/wiki/MGED_CMD_get_more_default: |
| 13:57.39 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1833 10/wiki/MGED_CMD_grid2model_lu: |
| 13:57.47 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1834 10/wiki/MGED_CMD_grid2view_lu: |
| 13:58.01 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1835 10/wiki/MGED_CMD_get_comb: |
| 13:58.02 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1836 10/wiki/MGED_CMD_get_dm_list: |
| 13:58.08 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1837 10/wiki/MGED_CMD_gui_destroy: |
| 13:58.14 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1838 10/wiki/MGED_CMD_hist: |
| 13:58.22 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1839 10/wiki/MGED_CMD_model2grid_lu: |
| 13:58.26 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1840 10/wiki/MGED_CMD_model2view: |
| 13:58.33 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1841 10/wiki/MGED_CMD_model2view_lu: |
| 13:58.36 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1842 10/wiki/MGED_CMD_make_name: |
| 13:58.41 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1843 10/wiki/MGED_CMD_mged_update: |
| 13:58.49 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1844 10/wiki/MGED_CMD_mmenu_get: |
| 13:58.56 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1845 10/wiki/MGED_CMD_mmenu_set: |
| 13:59.03 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1846 10/wiki/MGED_CMD_output_hook: |
| 13:59.15 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1847 10/wiki/MGED_CMD_put_comb: |
| 13:59.30 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1848 10/wiki/MGED_CMD_stuff_str: |
| 13:59.37 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1849 10/wiki/MGED_CMD_svb: |
| 13:59.44 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1850 10/wiki/MGED_CMD_tie: |
| 13:59.48 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1851 10/wiki/MGED_CMD_view2model_lu: |
| 14:01.32 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1852 10/wiki/MGED_CMD_reset_edit_solid: |
| 14:01.35 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1853 10/wiki/MGED_CMD_put_edit_solid: |
| 14:01.45 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1854 10/wiki/MGED_CMD_rset: |
| 14:01.57 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1855 10/wiki/MGED_CMD_set_more_default: |
| 14:02.16 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1856 10/wiki/MGED_CMD_share: |
| 14:02.27 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1857 10/wiki/MGED_CMD_solids_on_ray: |
| 14:02.36 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1858 10/wiki/MGED_CMD_view2model_vec: |
| 14:02.49 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1859 10/wiki/MGED_CMD_view_ring: |
| 14:02.58 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1860 10/wiki/MGED_CMD_viewget: |
| 14:03.08 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1861 10/wiki/MGED_CMD_viewset: |
| 14:03.17 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1862 10/wiki/MGED_CMD_winset: |
| 14:07.04 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1863 10/wiki/Category:MGED_developer_commands: |
| 14:10.14 | CIA-28 | BRL-CAD: 03Ssd 07http://brlcad.org * r1864 10/wiki/MGED_CMD_hist_add: |
| 14:35.31 | *** join/#brlcad d-lo (n=claymore@BZ.BZFLAG.BZ) | |
| 15:04.55 | CIA-28 | BRL-CAD: 03erikgreenwald * r36524 10/brlcad/trunk/src/libbu/ (backtrace.c fchmod.c): wrap the extern fileno to avoid explosions where fileno is defined as a macro (freebsd). |
| 15:53.10 | CIA-28 | BRL-CAD: 03starseeker * r36525 10/brlcad/trunk/src/libbu/parse.c: Put the %V back for now - apparently there's some sort of custom BRL-CAD specific logic at work here? |
| 17:13.04 | CIA-28 | BRL-CAD: 03indianlarry * r36526 10/brlcad/trunk/src/conv/step/TrimmedCurve.cpp: Added unit converions to Trim_Curve entity when trimming by cartesian_point. |
| 17:33.44 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1177879483.dsl.bell.ca) | |
| 18:12.50 | CIA-28 | BRL-CAD: 03starseeker * r36527 10/brlcad/trunk/src/libbu/parallel.c: Sigh. Put parallel.c back as well - casting is size_t, which appears to complicate things. |
| 18:23.43 | CIA-28 | BRL-CAD: 03starseeker * r36528 10/brlcad/trunk/src/libbu/ (9 files): Sigh. Size differences on different archs are causing trouble - revert for now. |
| 18:42.37 | CIA-28 | BRL-CAD: 03starseeker * r36529 10/brlcad/trunk/src/libbn/ (plane.c sphmap.c tabdata.c): Revert the libbn stuff too - need a plan on how to approach this. |
| 18:44.44 | starseeker | ``Erik: does this look to be of any interest? http://local.wasp.uwa.edu.au/~pbourke/geometry/polygonise/ |
| 18:54.39 | starseeker | hmm - looks like we might have to ask permission to use code on that page |
| 18:55.19 | starseeker | this one looks like it might be public domain though: http://local.wasp.uwa.edu.au/~pbourke/geometry/polygonise/table2.txt |
| 18:55.56 | starseeker | oh, so is this: http://local.wasp.uwa.edu.au/~pbourke/geometry/polygonise/marchingsource.cpp |
| 18:59.24 | starseeker | Looks like GTS has some marching stuff as well |
| 18:59.43 | brlcad | cracks open an editor, finally able to get started with his day |
| 18:59.51 | starseeker | morning ;-) |
| 18:59.55 | starseeker | sorry for the mess |
| 19:00.05 | brlcad | what mess? |
| 19:00.24 | starseeker | attempted to quell some warnings and ended up causing other problems |
| 19:00.27 | starseeker | reverted now |
| 19:00.31 | brlcad | ah |
| 19:00.42 | brlcad | yeah, I suspect there will be a bit of backlash with Werror |
| 19:00.57 | CIA-28 | BRL-CAD: 03indianlarry * r36530 10/brlcad/trunk/src/conv/step/OpenNurbsInterfaces.cpp: |
| 19:00.57 | CIA-28 | BRL-CAD: Cleaned up ellipse code to directly build ellipse from bezier(similar to the |
| 19:00.57 | CIA-28 | BRL-CAD: hyperbola) versus using openNURBS ellipse routine allowing for better control |
| 19:00.57 | CIA-28 | BRL-CAD: of the curve parameterization. Also removed unit conversion of curve endpoints |
| 19:00.57 | CIA-28 | BRL-CAD: for trimmed curves now done in one place the trimmed_curve parent. |
| 19:00.59 | brlcad | only quelled a mac and linux box |
| 19:01.07 | starseeker | is on board with getting it cleaned up, but it looks like it will take some work |
| 19:01.45 | brlcad | yep, trying to force the hand so we don't keep having new issues slip in |
| 19:02.03 | starseeker | apparently format hates us |
| 19:03.14 | starseeker | jfmi - does quelling mean "fixing" or just "turn off complaining about"? |
| 19:03.17 | brlcad | yeah, right now it's only protected against by checking for __STRICT_ANSI__ |
| 19:03.41 | brlcad | both, depends on the warning |
| 19:04.07 | brlcad | 95% of our warnings are benign so it's just shutting up the compiler by making something explicit that wasn't |
| 19:04.15 | starseeker | do we eventually want to fix to the point where we don't have to turn off any of the complaints? |
| 19:04.46 | starseeker | nods - unfortunately anything involving size_t seems to be trouble |
| 19:04.59 | brlcad | ideally, but that probably won't happen if only for external deps |
| 19:05.16 | brlcad | size_t? |
| 19:05.53 | starseeker | one of the format statements was casting something as (size_t) - apparently printf doesn't deal properly with that until C99 (via %zu) |
| 19:06.23 | brlcad | fyi, our printf-style functions will all fail on %V because we do add that one and the compiler hinting mechanism doesn't have a means (i'm aware of) for informing it of new character format specifiers |
| 19:06.56 | brlcad | so the 'fix' for that warning is to just turn off the hint we add to tell the compiler it's a printf-style function (it doesn't figure it out automatically) |
| 19:06.58 | starseeker | could we get around that by defining bu_format and doing any new things like %V there? |
| 19:08.10 | brlcad | hm, in that size_t case .. sounds like the cast is wrong |
| 19:08.31 | starseeker | parallel.c line 1067 |
| 19:08.34 | starseeker | libbu |
| 19:09.55 | starseeker | what does %V do - allow printing vls strings? |
| 19:10.31 | brlcad | yes |
| 19:11.15 | brlcad | a bu_format wouldn't get around it -- you'd still have the %V somewhere |
| 19:11.25 | brlcad | so long as it was printf-style |
| 19:11.46 | brlcad | again, we're the ones telling the compiler to treat it as printf-style and validate it as such |
| 19:11.46 | starseeker | ah. couldn't we just do bu_vls_addr(*vlsstring) and use %s? |
| 19:12.06 | brlcad | so the easy fix is just turn off that hint if Werror is in effect |
| 19:12.09 | starseeker | nods |
| 19:12.25 | brlcad | you could do that, lots of places that actually call fprintf/printf/snprintf/etc do that |
| 19:12.33 | brlcad | but it defeats the purpose |
| 19:13.01 | brlcad | and is actually more expensive if it was something that mattered performance-wise (not likely) |
| 19:13.35 | starseeker | where do we hint? |
| 19:14.08 | brlcad | bu.h |
| 19:14.59 | brlcad | look for __STRICT_ANSI__ .. that's where I "turn it off" presently, but __STRICT_ANSI__ will only get set if -std= is set, which we can't enable |
| 19:15.10 | starseeker | hrm |
| 19:15.17 | brlcad | need a better toggle |
| 19:15.36 | brlcad | like maybe an AC_DEFINE from configure |
| 19:16.15 | brlcad | i still need to add a configure toggle too, so we can turn Werror off on the fly if needed without needing an edit |
| 19:16.24 | brlcad | (for third-party users) |
| 19:16.36 | CIA-28 | BRL-CAD: 03bob1961 * r36531 10/brlcad/trunk/src/libged/nirt.c: |
| 19:16.36 | CIA-28 | BRL-CAD: Mods to accommodate an earlier change to the nirt application (.i.e. the |
| 19:16.36 | CIA-28 | BRL-CAD: application is no longer setting the file modes to O_BINARY). Here we, likewise, |
| 19:16.36 | CIA-28 | BRL-CAD: no longer set the file modes to O_BINARY and strip of any CRLF's we find. |
| 19:17.03 | brlcad | o.O |
| 19:17.18 | CIA-28 | BRL-CAD: 03brlcad * r36532 10/brlcad/trunk/src/libbu/parallel.c: quell warning, print the pointer as a pointer instead of a size_t |
| 19:18.09 | starseeker | ah, that does make more sense |
| 19:20.08 | CIA-28 | BRL-CAD: 03indianlarry * r36533 10/brlcad/trunk/src/conv/step/OpenNurbsInterfaces.cpp: cleaned up original ellipse function stubs and some reordering |
| 19:21.17 | starseeker | brlcad: the one ``Erik and I really aren't sure what to do with is bu_rb_summarize_tree in rb_diag.c |
| 19:21.59 | brlcad | what about it? |
| 19:22.40 | starseeker | hang on, let me regenerate the exact error |
| 19:23.08 | brlcad | more than likely, just not passing a voi* |
| 19:24.09 | starseeker | yeah, except one of them (I think the one on line 111) won't take that cast |
| 19:24.18 | starseeker | it's some kind of violation of ISO C |
| 19:24.23 | brlcad | saw those _WIN32's that bob slipped in! |
| 19:25.03 | starseeker | did a lot of (void *) casting in his reverted changes - if that's what's needed I can turn it back on |
| 19:25.14 | brlcad | ah, yeah, you can't cast a function to a void* |
| 19:25.23 | brlcad | people do it all the time and expect it |
| 19:25.38 | brlcad | but the standard says no pretty clearly |
| 19:26.18 | brlcad | probably just not passing the address |
| 19:27.56 | brlcad | looks |
| 19:28.54 | brlcad | the bigger issue is what value is there to printing a red-black tree comparison function address |
| 19:28.55 | Emton | probably a novelty but rttherm isn't in the windows distro |
| 19:29.21 | brlcad | Emton: there are about 150 of 400 binaries missing from windows, iirc |
| 19:29.31 | Emton | ok |
| 19:29.34 | brlcad | er, sorry, flip that |
| 19:29.49 | brlcad | there are about 250 missing, 150 existing of 400 |
| 19:30.09 | Emton | wow, alright is that because they dev work? |
| 19:30.24 | brlcad | yeah, just nobody working on that |
| 19:30.35 | brlcad | nothing hard .. just very tedious |
| 19:30.37 | Emton | yea, i would but i don't have VS |
| 19:30.50 | brlcad | could try express ;) |
| 19:30.52 | brlcad | tis free |
| 19:31.11 | Emton | heh, i'll take a look at it |
| 19:31.16 | brlcad | I think someone even reported that it worked with our multi-project build setup |
| 19:31.23 | Emton | i'm still banging away on my cygwin |
| 19:31.49 | Emton | btw, i put the patch in under icbml for tabinterp.c |
| 19:31.51 | brlcad | if you get the hankering, misc/win32-msvc8 is the dir -- brlcad solution |
| 19:32.01 | brlcad | icbml? |
| 19:32.04 | Emton | ok |
| 19:32.09 | brlcad | ~icbml |
| 19:32.10 | Emton | yea, that's my old handle |
| 19:32.14 | brlcad | ahh |
| 19:32.14 | brlcad | k |
| 19:32.35 | brlcad | :) |
| 19:32.44 | Emton | heheh |
| 19:33.24 | brlcad | tsk tsk .. someone had you post a tracker for a one-liner.. good to know the usual process though :) |
| 19:33.37 | Emton | !!starseeker |
| 19:33.41 | Emton | ugh |
| 19:33.44 | Emton | yea |
| 19:33.50 | Emton | but at least now I know the process |
| 19:35.07 | brlcad | that said.. on the surface, not sure I believe that fix.. |
| 19:35.26 | brlcad | that times[] array is what it's supposed to use for rate interpolation iirc |
| 19:35.43 | brlcad | really old chunk of code, but otherwise the table wouldn't be used (or needed) |
| 19:36.12 | brlcad | maybe you have bad times[t] values |
| 19:36.13 | Emton | not sure, but the rate part itself is a simple step val generator |
| 19:36.33 | Emton | i compiled that and it worked as expectd |
| 19:36.53 | starseeker | brlcad: had him post to (a) learn the process and (b) cause I wasn't sure and wanted someone else to check it |
| 19:37.02 | Emton | it should just iterate for every row and times the row (i) by a constant (the rate) |
| 19:37.39 | Emton | i ripped the blurb in the tracker from the tabinterp man page |
| 19:37.42 | brlcad | starseeker: I know, just giving you some grief ;) |
| 19:37.53 | starseeker | loves grief :-) |
| 19:38.02 | brlcad | I know how "fun" it is to post tracker items |
| 19:38.09 | Emton | hehe |
| 19:39.42 | brlcad | hm |
| 19:40.40 | brlcad | yeah, this really feels like it only works because it's using linear interpolation and the t param matches |
| 19:40.59 | brlcad | there are different interpoliation modes where t isn't what you'd want |
| 19:41.10 | Emton | yea, it's really not even an interp it's a val generator |
| 19:41.30 | Emton | before it would step by 3.5 for me no matter what |
| 19:41.59 | brlcad | nods |
| 19:43.08 | brlcad | well, frankly you're the first to but the interpolater to use in a few years, so taking it at face value ;) |
| 19:43.19 | Emton | hehe, i was trying to use it so I could be lazy and not take keyframe saveviews for my anims |
| 19:43.44 | Emton | btw, i pushed everything into a shell script and it works pretty well |
| 19:44.18 | Emton | not sure if anyone, is interested but i could post if ppl are doing animations |
| 19:45.39 | starseeker | I'm sure some folks would be interested |
| 19:46.27 | Emton | hmm.. well i will clean it up and post to?? tracker? |
| 19:46.35 | CIA-28 | BRL-CAD: 03brlcad * r36534 10/brlcad/trunk/src/tab/tabinterp.c: |
| 19:46.35 | CIA-28 | BRL-CAD: apply imcbml/Emton's sf patch 2899596 (TABINTERP RATE INTERP) where the rate |
| 19:46.36 | CIA-28 | BRL-CAD: interpolation function was taking the (fixed) times table value instead of |
| 19:46.36 | CIA-28 | BRL-CAD: directly using the simple interpolation t value. this should hopefully fix a |
| 19:46.36 | CIA-28 | BRL-CAD: tabinterp bug with rate-based table interpolation, but untested. |
| 19:47.27 | starseeker | Emton: sounds like a good candidate for the wiki |
| 19:47.31 | starseeker | brlcad.org |
| 19:47.55 | Emton | alright, just edit and post there |
| 19:48.26 | starseeker | yep |
| 19:48.34 | starseeker | is looking for good example |
| 19:48.59 | starseeker | might even add to this: http://brlcad.org/wiki/Animation |
| 19:49.04 | Emton | yea |
| 19:49.12 | Emton | that's where i was looking |
| 19:50.22 | CIA-28 | BRL-CAD: 03brlcad * r36535 10/brlcad/trunk/src/tab/tabinterp.c: ws indent style formatting cleanup |
| 19:50.51 | Emton | although this is not a tutorial, this just a shell script to automate what goes on in most of those tutorials |
| 19:51.24 | starseeker | no problem :-) |
| 19:51.52 | Emton | hehe, ok well i'll put it up there after i clean it up (the non-generic) |
| 19:54.12 | CIA-28 | BRL-CAD: 03starseeker * r36536 10/brlcad/trunk/ (configure.ac src/libbu/parse.c): Add a configure option to disable strict compiler flags at need (-disable-strict) - they're enabled by default but this provides a convenient way to turn them off. |
| 19:55.59 | CIA-28 | BRL-CAD: 03starseeker * r36537 10/brlcad/trunk/src/libbu/parse.c: Blast it, sucked in change by mistake. |
| 20:10.24 | CIA-28 | BRL-CAD: 03starseeker * r36538 10/brlcad/trunk/ (configure.ac include/bu.h): Add an configure based flag for the format hitting toggle - this should be more robust for turning on/off format checking. |
| 20:10.27 | starseeker | brlcad: see if that looks OK... |
| 20:13.37 | brlcad | Emton: and keep the patches coming ;) |
| 20:13.47 | brlcad | don't have to be bug fixes |
| 20:18.43 | brlcad | starseeker: looks good |
| 20:19.07 | brlcad | just maybe not in the summary, prime realestate |
| 20:20.39 | CIA-28 | BRL-CAD: 03brlcad * r36539 10/brlcad/trunk/src/tab/tabinterp.c: restructure so forward declarations are not needed |
| 20:21.55 | Emton | heh, alright well looks like i'm getting closer to a fix on my cygwin env problems - seems my AntiVir soft was hooking opened files and holding onto the pointers - latest SVN pull of BRLCAD has been compiling for the last .5hr without real hiccups =) |
| 20:22.23 | starseeker | brlcad: yeah, I was torn - I'll go ahead and nuke |
| 20:22.39 | starseeker | eventually it shouldn't be an issue anyhow |
| 20:23.21 | brlcad | when in doubt, yank |
| 20:23.58 | CIA-28 | BRL-CAD: 03starseeker * r36540 10/brlcad/trunk/configure.ac: Take strict building out of summary |
| 20:24.01 | starseeker | yanked |
| 20:24.12 | brlcad | rather have it short, 50% informative, and used 90% of the time than long, 90% informative, and used 50% of the time.. ;) |
| 20:25.09 | brlcad | few other items in there could probably get nuked at some point |
| 20:27.21 | starseeker | winces - opennurbs_ext.cpp + mmintrin.h is now the breakage point |
| 20:27.22 | starseeker | ouch |
| 20:27.41 | starseeker | brlcad: can I nuke jove from that summary? (next best thing to nuking jove...) |
| 20:29.14 | starseeker | what the bleepitty bleeepity bleep... it's complaining about conversions in the header files |
| 20:31.40 | CIA-28 | BRL-CAD: 03brlcad * r36541 10/brlcad/trunk/src/tab/tabinterp.c: quell warnings, couples bugs |
| 20:31.49 | brlcad | starseeker: yeah, that'd be a good one |
| 20:32.10 | starseeker | http://pastebin.bzflag.bz/m68eefb84 |
| 20:32.14 | brlcad | what plat are you on? |
| 20:32.50 | starseeker | OSX 10.4 |
| 20:33.12 | starseeker | pastebin is the full error |
| 20:33.19 | brlcad | this isn't something new is it? |
| 20:33.36 | starseeker | just when I got past libbu and libbn with strict on |
| 20:33.37 | brlcad | doesn't recall modding librt |
| 20:33.48 | brlcad | only bu/bn have strict enabled |
| 20:33.53 | starseeker | erm |
| 20:34.16 | brlcad | as seen in your compile line .. no warning flags ;) |
| 20:34.38 | starseeker | ok... |
| 20:34.51 | brlcad | isn't that the fpu/gpu issue? |
| 20:34.52 | starseeker | what'd I break now... |
| 20:35.01 | starseeker | oh, could be |
| 20:35.19 | starseeker | that's right, the insufficient test |
| 20:35.45 | brlcad | though the other was an illegal instruction |
| 20:35.56 | starseeker | that one puzzled me (nothing new) - we seem to be doing sse testing in that include conditional... |
| 20:36.44 | starseeker | growls |
| 20:38.13 | starseeker | the other instance was a step-g conv triggered thing, iirc |
| 20:38.22 | brlcad | ah, yes |
| 20:45.47 | brlcad | starseeker: you still have that opennurbs_ext.cpp error? |
| 20:46.07 | starseeker | I started over without strict enabled and got by it |
| 20:46.11 | brlcad | just noticed your compile line is missing sse directives |
| 20:46.23 | starseeker | hmm |
| 20:46.25 | brlcad | turning strict off got by it? |
| 20:46.29 | starseeker | yep |
| 20:46.31 | brlcad | o.O |
| 20:47.00 | brlcad | ahhh |
| 20:47.06 | starseeker | let me capture the compile line from this one... |
| 20:47.25 | starseeker | /bin/sh ../../libtool --silent --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../brlcad/src/librt -I../../include -I../../../brlcad/src/other/libregex -I../../../brlcad/src/other/tcl/generic -I../../../brlcad/src/other/tcl/unix -DOBJ_BREP=1 -I../../../brlcad/src/other/tnt -I../../../brlcad/src/other/openNURBS -I../../../brlcad/src/other/libz -DBRLCADBUILD=1 -I../../../brlcad/include -I../../../brlcad/src/other/openNURBS -I../../../brlcad/src/other/li |
| 20:47.26 | brlcad | I wonder if it's leaving a flag set during configure |
| 20:47.41 | brlcad | that looks normal |
| 20:47.45 | brlcad | no warning flags |
| 20:47.57 | brlcad | so the only diff should be brlcad_config.h detections |
| 20:48.18 | brlcad | and that is missing -msse to enable sse support |
| 20:48.23 | brlcad | hence the failure |
| 20:49.24 | starseeker | sees an sse section commented out in configure.ac |
| 20:49.52 | brlcad | needs msse or msse2 or msse3 |
| 20:50.15 | starseeker | how is strict vs. non-strict impacting anything? |
| 20:50.32 | brlcad | it really shouldn't |
| 20:51.15 | brlcad | only thing that comes to mind is a flag is getting left set .. and further function/lib/header checks then fail |
| 20:52.45 | starseeker | unless it's something done by BC_COMPILER_AND_LINKER_RECOGNIZES I'm at a loss |
| 20:54.12 | brlcad | yeah, dunno .. the [no] at the end specifically means don't leave the flags set |
| 20:54.32 | brlcad | compare your config outputs |
| 20:54.52 | brlcad | for the same flags, they shouldn't be diff other than the strict define |
| 20:58.24 | brlcad | hm |
| 21:00.41 | starseeker | maybe this is one of those weird "tree not clean things..." |
| 21:01.04 | starseeker | is generating configure logs for both options |
| 21:02.03 | CIA-28 | BRL-CAD: 03bob1961 * r36542 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Added a public putString method. |
| 21:05.28 | brlcad | hm, could be that too |
| 21:06.49 | brlcad | but oddness is why it would work *without* strict .. |
| 21:06.58 | starseeker | ah |
| 21:07.22 | brlcad | it HAS to be determining SSE is unavailable somehow |
| 21:07.27 | brlcad | yet with strict on, it tries it |
| 21:07.42 | brlcad | maybe two problems :) |
| 21:07.58 | starseeker | it thinks it is available - remember the step-g problem |
| 21:08.15 | brlcad | since the whole sse section in configure.ac is disabled, it's likely just the emmintrin.h header test or something |
| 21:08.53 | brlcad | since you're working on it, could add a --enable-vector-build option (that's why it's commented out) |
| 21:09.13 | starseeker | hmm - that's a thought |
| 21:09.37 | starseeker | let me figure out why this is busted before I throw in another variable, but that sounds like a good idea |
| 21:13.15 | starseeker | nothing convincing in conf.log diffs |
| 21:15.25 | brlcad | what about config.h themselves? |
| 21:15.30 | CIA-28 | BRL-CAD: 03brlcad * r36543 10/brlcad/trunk/ (AUTHORS NEWS): credit Emton (irc) aka icmbml (sf) with special thanks for his 1-liner patch to tabinterp. should fix a rate interpolation bug where interpolation was at fixed (incorrectly large) increments. |
| 21:15.45 | starseeker | only diff is the line where HAVE_STRICT is comment out vs. defined |
| 21:16.06 | brlcad | that's exactly what I would have expected ... so ..... |
| 21:16.10 | brlcad | something else is going on |
| 21:16.15 | starseeker | doing a clean build now |
| 21:17.04 | starseeker | I take it there should be no issue merging libraries built with the flags (bu and bn ) with libraries built without them? |
| 21:17.54 | brlcad | nope |
| 21:18.27 | starseeker | shoot - it repeated itself |
| 21:18.35 | brlcad | not even different object code output, just tells the compiler 1) to report most warnings, and 2) stop if it finds any |
| 21:19.18 | brlcad | trace through just compiling that one file |
| 21:19.46 | brlcad | see if it's getting to the fpu or gpu vector header for both (tossing in #error's can help) |
| 21:20.40 | starseeker | wait - let me see what happens if I go back, recompile libbu and bn without the flags, and do this again |
| 21:21.46 | starseeker | brlcad: are you on a Mac? |
| 21:23.16 | starseeker | phew - OK, that still fails |
| 21:23.28 | starseeker | ok, what'd I mess up in configure.ac... |
| 21:33.26 | starseeker | god this is strange |
| 21:33.40 | starseeker | I have teh g++ commands for both and they're identical |
| 21:39.45 | starseeker | brlcad: OK, confirmed now - switching the line from /* #undef HAVE_STRICT_FLAGS */ to #define HAVE_STRICT_FLAGS 1 in brlcad_config.h is what causes the failure |
| 21:42.38 | starseeker | I just have no idea why |
| 21:43.03 | Emton | fyi, compiling on Cygwin I had to cp src/other/tk/win/*.h ../unix |
| 21:44.53 | Emton | perhaps we can put a README_CYGWIN file in? |
| 21:46.18 | Emton | I'd be happy to write a quick blurb from my pains on it.. heh |
| 21:46.26 | starseeker | go for it :-) |
| 21:46.48 | Emton | alright, done |
| 21:52.45 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) | |
| 21:55.53 | starseeker | hheeeellllpppp |
| 21:56.01 | louipc | wasup |
| 21:57.03 | starseeker | autoconf/automake bizarreness |
| 21:57.06 | starseeker | I think |
| 21:57.31 | louipc | heheh |
| 21:58.41 | Emton | .Tpo -c -o brlcad_path.lo brlcad_path.c |
| 21:58.41 | Emton | In file included from ../../include/brlcad_version.h:84, |
| 21:58.41 | Emton | <PROTECTED> |
| 21:58.41 | Emton | ../../include/conf/COUNT:1:1: invalid suffix "n" on integer constant |
| 21:58.41 | Emton | ../../include/conf/COUNT:1:3: no newline at end of file |
| 21:59.05 | Emton | in the include/conf/COUNT file is 1n |
| 21:59.16 | Emton | anybody know if this does anything important? |
| 22:03.08 | Emton | heh, seems like all those generated files popped an n on the end wherever they came from |
| 22:03.29 | Emton | cat DATE: "Wed, 18 Nov 2009 15:18:59 -0500"n |
| 22:03.59 | Emton | cat HOST: "nada_lada"n |
| 22:04.22 | Emton | MAJOR and MINOR don't have it |
| 22:07.23 | Emton | so, DATE HOST COUNT TS PATH USER have what looks like a linefeed that never happened |
| 22:08.33 | starseeker | those are autogenerated, iirc - so yeah, probably linefeed/end of line fun |
| 22:08.49 | starseeker | (sucks) |
| 22:09.47 | Emton | yea |
| 22:10.28 | Emton | they keep getting gen'd on the fly hehe |
| 22:14.08 | *** join/#brlcad R0b0t1 (n=Enigma@unaffiliated/r0b0t1) | |
| 22:15.10 | Emton | ok, is fixed include/conf/Makefile:110 from >>> ECHO = printf %s\n |
| 22:15.26 | Emton | to <<< ECHO = printf %s |
| 22:17.02 | Emton | hehe.. hang on - it *likes* to have line feeds |
| 22:17.16 | Emton | not n's but real line feeds, hehe hang on |
| 22:17.31 | starseeker | Emton: the trick will be a solution that works in cygwin and other platforms |
| 22:17.44 | Emton | yea |
| 22:18.17 | brlcad | starseeker: if you take the one that works (i.e. doesn't define HAVE_STRICT_FLAGS) and run: make CPPFLAGS=-DHAVE_STRICT_FLAGS=1 |
| 22:19.34 | Emton | ok, include/conf/Makefile: 110 ECHO = printf "%s\n" |
| 22:19.35 | Emton | works |
| 22:20.50 | Emton | starseeker could you test it on real unix/linux? |
| 22:21.05 | brlcad | Emton: include/conf/Makefile is autogenerated |
| 22:21.10 | brlcad | ECHO is set during configure |
| 22:21.20 | Emton | ok |
| 22:21.36 | brlcad | that would be an autoconf/automake bug |
| 22:21.40 | Emton | on Cygwin looks like the open air format bombs |
| 22:21.45 | brlcad | something that could probably be tested for in configure.ac though |
| 22:22.24 | Emton | yea |
| 22:22.43 | brlcad | if you look in there now, there's a section that makes sure ECHO is at least set (to accommodate an older autoconf bug where it wouldn't even set it) |
| 22:22.59 | brlcad | could test if it's that printf string, and remap it to be quoted |
| 22:24.44 | brlcad | kind of odd they's miss something like that with \n .. might find something insightful if you read through the raw configure script to see how it gets to that point |
| 22:25.03 | Emton | yea, seems basic |
| 22:25.21 | Emton | also weird that they have a ECHO_N but use plain ECHO for the linefeed |
| 22:31.26 | starseeker | brlcad: Ah HA! got it |
| 22:31.45 | starseeker | vector_x86.h and vector_fpu.h both have __attribute__ in them |
| 22:31.59 | starseeker | which is being undefed by bu.h |
| 22:32.47 | Emton | another problem src/libbu/malloc.c:505 needs count to be cast as (long) |
| 22:32.51 | *** join/#brlcad Ralith (n=ralith@d142-058-084-202.wireless.sfu.ca) | |
| 22:34.57 | brlcad | AAHHHHHhhhh... |
| 22:35.00 | brlcad | that makes sense starseeker |
| 22:35.17 | starseeker | let me see if I can narrow the undef |
| 22:35.34 | brlcad | probably shouldn't undef __attribute__ .. maybe just our BU_ attributes |
| 22:39.00 | Emton | problem at src/libbu/parse.c:2187 %V format val not recognized |
| 22:39.07 | brlcad | times like this I love emacs .. figured out what I needed, gotta love introspection |
| 22:39.12 | starseeker | Emton: we're working that now |
| 22:39.20 | Emton | heh, oh ok |
| 22:39.27 | starseeker | brlcad: hmm? |
| 22:39.46 | Emton | yea, i get a bunch more errors after I changed those |
| 22:39.55 | brlcad | starseeker: nothing important .. just wanted to sort a range of lines quickly, based on a field (not just lexicographic) |
| 22:40.01 | Emton | resorted to make -i heh |
| 22:40.13 | starseeker | ah |
| 22:40.23 | brlcad | Emton: if you make CFLAGS=-w it should work |
| 22:40.36 | Emton | what's that -w for? |
| 22:40.52 | brlcad | tells it to not report warnings |
| 22:40.57 | Emton | heh ok |
| 22:41.12 | brlcad | just added strict compilation settings to libbu and libbn yesterday |
| 22:41.23 | brlcad | any warnings cause a failure |
| 22:41.30 | Emton | thanks, the -i i think is ig'ing the errors |
| 22:41.37 | Emton | ok yea |
| 22:41.40 | brlcad | the -w will make them not be errors |
| 22:41.50 | brlcad | otherwise it'll still fail to link |
| 22:42.17 | Emton | it's going good now |
| 22:42.19 | Emton | =) |
| 22:42.34 | starseeker | brlcad: hrm. How do I selectively undef just the format, printf, etc. stuff? |
| 22:42.46 | starseeker | undef __attribute__ ((__format__)) doesn't seem to work |
| 22:42.49 | brlcad | that's the BU attrs |
| 22:43.23 | starseeker | oh, like BU_ATTR_FORMAT12? |
| 22:43.30 | brlcad | __BU_ATTR... make those be conditional instead of __attribute__ itself |
| 22:43.57 | brlcad | alternative, make the __attribute__ in the dvec code be a __BE define too, set before it's undefd |
| 22:45.13 | Emton | btw, before i mention malloc.c:110 cast as long but perhaps should just change the format to %i? shouldn't be able to hold long infos anywayz |
| 22:45.57 | brlcad | 110? |
| 22:46.04 | brlcad | that's a blank line for me |
| 22:46.08 | Emton | whoops, malloc.c:505 in src/libbu |
| 22:46.19 | Emton | my bad |
| 22:47.46 | CIA-28 | BRL-CAD: 03brlcad * r36544 10/brlcad/trunk/src/libbu/malloc.c: cast away the size_t to the size we're printing (thx emton) |
| 22:47.58 | Emton | =) |
| 22:48.07 | brlcad | you could end up with long entries |
| 22:49.28 | Emton | ok, (long) is better then |
| 22:49.59 | brlcad | unsigned ;) |
| 22:50.23 | Emton | hehe yea |
| 22:50.23 | CIA-28 | BRL-CAD: 03brlcad * r36545 10/brlcad/trunk/src/libbu/malloc.c: dead ws |
| 22:55.55 | starseeker | so far, it looks like the compiler is complaining unless __attribute__(ignore) is defined |
| 22:56.23 | starseeker | hmmm |
| 22:58.51 | starseeker | there we go |
| 23:01.58 | CIA-28 | BRL-CAD: 03starseeker * r36546 10/brlcad/trunk/include/bu.h: Don't want to totally undef __attributes__ - causes problems with the vector_x86.h and probably vector_fpu.h files. |
| 23:06.45 | starseeker | phew - nbuilding now |
| 23:07.20 | brlcad | yay |
| 23:07.29 | starseeker | that was fun |
| 23:09.29 | ``Erik | clean on 32 and 64, leenewx bsd and mac? |
| 23:09.36 | ``Erik | msvc? |
| 23:09.58 | starseeker | hmm? |
| 23:10.10 | starseeker | I'm building on Mac |
| 23:10.58 | ``Erik | likes to leave his src on nfs and build in /usr/tmp/ dirs simultaniously on multiple platforms to verify portability |
| 23:11.21 | starseeker | gets confused enough doing one at at time |
| 23:11.28 | ``Erik | hehehe |
| 23:11.42 | ``Erik | yeah, ya seemed confused when I started bouncing around in screens to start my spread |
| 23:12.20 | starseeker | <snort> you had some problem with not picking up the configure.ac change |
| 23:12.48 | ``Erik | no, I had the configure.ac change just fine, it was one of the .c files, my mods were preventing svn from updating it |
| 23:18.03 | starseeker | ah |
| 23:18.29 | starseeker | sighs in relief - no other issues, build finished on Mac |
| 23:18.48 | starseeker | ``Erik: anyway, this isn't one of the toying with casting issues |
| 23:19.02 | starseeker | just the build logic nuking too much stuff |
| 23:20.17 | starseeker | I can't recall - did someone find a clean solution to that rb_diag.c problem with the function pointer casting? |
| 23:41.00 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) | |
| 23:41.26 | brlcad | fg |
| 23:41.35 | brlcad | didn't look into it |
| 23:41.52 | brlcad | quick thought would be to just not print the address |
| 23:41.57 | brlcad | nonissue |