| 00:04.58 | Jonimus | I did a svn checkout and it was over 1GB 0.o |
| 00:05.01 | Jonimus | that was unexpected |
| 00:20.55 | ``Erik | heh http://www.astrodigital.org/space/stshorse.html |
| 00:21.18 | ``Erik | 1gb? um, did you check out ALL the branches, or just trunk? |
| 00:24.35 | Jonimus | I thought it was just trunk |
| 00:24.58 | Jonimus | nvm its only 500MB or so |
| 00:25.20 | Jonimus | Windows must have miscalculated when I did the copy |
| 00:31.40 | ``Erik | windows? miscalculated file storage? say it ain't so! :D *duck* |
| 00:36.32 | Jonimus | lol, not to mention It doesn't build correctly with my version of msvc |
| 00:38.21 | ``Erik | whatever identifies itself as msvc8 is what's used... there was effort by someone to make it work with msvc9, I don't know how that went |
| 00:38.31 | ``Erik | (is that studio 2005?) |
| 00:39.09 | Jonimus | I have no clue, but I guess I'll live with the current binary available |
| 00:41.30 | Jonimus | <PROTECTED> |
| 00:41.32 | Jonimus | [18:21] Jonimus | I thought it was just trunk â |
| 00:41.34 | Jonimus | [18:21] [30] [irc/freenode] 30:#brlcad(+n){29} [Act: 7,18] |
| 00:41.36 | Jonimus | [Jonimus(i)] |
| 00:41.38 | Jonimus | woops sorry |
| 00:48.56 | ``Erik | smells like irssi |
| 00:49.14 | Jonimus | weechat actually |
| 00:49.32 | ``Erik | yeh, there are some differences |
| 00:50.11 | ``Erik | (yet another BX/epic imitator *cough*) |
| 00:57.26 | Jonimus | Never heard of it :P |
| 00:59.56 | ``Erik | which, bitchx or epic? epic was kinda a sidenote, BitchX was the popular one :D |
| 01:00.23 | Jonimus | ok I think I have herd of BitchX but not epic |
| 01:02.09 | Jonimus | either way I like weechat so far, though it sucks ram like a sieve |
| 07:13.18 | *** join/#brlcad Phurl (~mdupont@2001:0:53aa:64c:2069:172f:ae2d:1b81) |
| 07:37.56 | *** join/#brlcad Phurl (~mdupont@2001:0:53aa:64c:2069:172f:ae2d:1b81) |
| 09:39.50 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 09:47.15 | d_rossberg | the introduction of ssize_t broke the build of the brlcad.dll |
| 09:48.25 | d_rossberg | the rt^3 part of the dll is build without the BRLCADBUILD flag, i.e. without config_win.h which contains the ssize_t declaration |
| 09:51.57 | d_rossberg | however, it looks like it would be optimal to replace the signed ssize_t by the unsigned size_t as all occurrence are in non-negative sizes (number of elements) |
| 09:58.10 | CIA-43 | BRL-CAD: 03d_rossberg * r37702 10/brlcad/trunk/src/libbu/CMakeLists.txt: synced with Makefile.am: added quote.c |
| 11:28.13 | ``Erik | amusingly, the ssize_t stuff was done FOR windows (msvc8 on I believe 64b vista) |
| 11:46.06 | Ralith | why signed, then? |
| 11:59.44 | d_rossberg | the modification was: int/long => ssize_t, unsigned int/unsigned long => size_t |
| 12:40.48 | ``Erik | he was probably just following the trail of warnings/errors from msvc and trying to match without digging in much (mebbe -1 is used as an error code on some of those? *shrug*) |
| 12:40.59 | ``Erik | I'll ask him when he gets in |
| 12:45.37 | d_rossberg | ``Erik: thanks |
| 13:11.14 | d_rossberg | i'm currently testing the ssize_t => size_t behavior on linux (especially if there are some warnings as errors) |
| 13:11.36 | d_rossberg | this may take a while |
| 13:25.20 | Ralith | reminds me |
| 13:25.57 | Ralith | apparently windows' BOOL type actually has *three* states. |
| 13:26.01 | Ralith | true, false, and error. |
| 13:31.46 | d_rossberg | "typedef int BOOL;" in WinDef.h |
| 13:32.23 | d_rossberg | and "typedef BYTE BOOLEAN;" in WinNT.h ;) |
| 13:33.04 | d_rossberg | which "should be TRUE or FALSE" |
| 13:59.11 | brlcad | d_rossberg: the care that will need to be taken .. we ran into several cases of int/long -> ssize_t where the struct or parameter or variable were representing number of elements but negative values were used for initialization or return codes |
| 13:59.26 | brlcad | so the uses of that var have to be reviewed case by case to make sure that's not happening |
| 14:00.35 | Ralith | d_rossberg: namely, many functions returning BOOL apparently also return -1 to indicate error. |
| 14:02.20 | brlcad | converting them all to size_t is better overall, but just have to be careful.. that would be a nasty bug to try to find, a -1 cast to unsigned, possibly truncated. |
| 14:10.23 | d_rossberg | brlcad: i'm trying to replace the ssize_t by size_t and i can assure you that the problem is not the -1 |
| 14:10.51 | d_rossberg | i.e. -1 => (size_t)-1 which means something like ffffffff |
| 14:11.44 | d_rossberg | more difficult are the parts where two sizes are compared |
| 14:12.04 | d_rossberg | i.e. if (difference < 0) then ... |
| 14:13.05 | d_rossberg | btw. libbu/parse.c shouldn't be compilable with gcc |
| 14:19.52 | brlcad | that's what I meant about it being a problem |
| 14:20.30 | brlcad | just the act of using/passing as negative and having other code checking for negative (which would just be an unreachable statement, of course) |
| 14:20.37 | brlcad | what's wrong with parse.c? compiles here |
| 14:22.07 | brlcad | last friday's edits are a bit of a blur, but a look at the last patch to it seems benign |
| 14:23.26 | *** join/#brlcad parigaudi (~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
| 14:28.04 | d_rossberg | i got some signed/unsigned comparison warnings with parse.c, but this could also be because of my changes in the headers (? maybe) |
| 14:35.23 | d_rossberg | brlcad: where should i put os/machine dependent declarations (e.g. ssize_t) which has to be included in an installation? |
| 14:57.48 | brlcad | d_rossberg: that's common.h territory but a little tricky given it's not a standard type |
| 14:58.27 | brlcad | part of me wants to convert them all to size_t, get rid of the negative-means-something specializations |
| 14:59.41 | brlcad | otherwise, the usual way is to have a configure test for the type, then key on it in common.h or config with HAVE_SSIZE_T |
| 15:02.23 | d_rossberg | it looks like size_t is the only type on windows which size's depends on the machine (32 vs. 64 bit) |
| 15:03.27 | d_rossberg | i.e. if you want a signed machine dependent type you are in trouble |
| 15:04.02 | d_rossberg | and db5_decode_signed() needs such a signed type |
| 15:06.07 | brlcad | db5_decode_signed() shouldn't be using a ssize_t |
| 15:06.53 | brlcad | that's where the case by case is going to be a bit of work -- db5_decode_signed()'s first parameter is a pointer to a variable length field |
| 15:06.55 | d_rossberg | the result (in the array) is tested for <0 |
| 15:07.29 | d_rossberg | which sounds logical |
| 15:08.07 | brlcad | sure, but that can be typecasted from the caller's type |
| 15:08.56 | brlcad | i think it's actually wrong for db5_decode_signed() to call it a ssize_t as that's a particular signed size .. the idea is that it's the db's signed size, which may not even match native |
| 15:09.30 | brlcad | like a db_ssize_t |
| 15:09.50 | brlcad | it's treated like a void* |
| 15:25.53 | d_rossberg | i try to fix the (s)size_t issue (i.e. make the next iteration step) |
| 15:40.19 | ``Erik | daniel: bob explicitely defines ssize_t in config_win.h |
| 15:44.24 | ``Erik | reads backlog O.o |
| 16:03.09 | brlcad | right, but then is config_win.h installed -- it's not technically a reliable type on *nix either as it's not posix |
| 16:03.14 | brlcad | only size_t is |
| 16:03.19 | brlcad | and ptrdiff_t |
| 16:08.23 | ``Erik | is just playing go-between *shrug* |
| 16:08.44 | ``Erik | elimination of ssize_t would be nice, but could be time consuming to verify each conversion :/ |
| 16:12.39 | d_rossberg | ``Erik: i think i got it (at least from the headers) but it needs some more tests |
| 16:15.10 | ``Erik | aight, cool |
| 18:16.09 | starseeker | has his car back |
| 18:16.16 | starseeker | and a working computer again |
| 18:16.29 | starseeker | sighs in relief |
| 18:32.09 | starseeker | WOOT - http://itmanagement.earthweb.com/features/article.php/3866316/Bruce-Perens-Inside-Open-Sources-Historic-Victory.htm |
| 18:38.56 | starseeker | That's really good news - the JMRI case had been a scary mess for open source for a long time |
| 18:58.37 | ``Erik | yup |
| 18:58.48 | ``Erik | saw that yesterday I think? |
| 18:59.10 | ``Erik | not perens thing, but the judgement |
| 19:23.41 | *** join/#brlcad parigaudi (~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
| 20:01.06 | *** join/#brlcad parigaudi (~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
| 20:12.53 | *** join/#brlcad CIA-41 (cia@208.69.182.149) |
| 20:55.38 | CIA-41 | BRL-CAD: 03brlcad * r37703 10/brlcad/trunk/configure.ac: check for int32_t, int64_t, ssize_t |
| 21:13.52 | CIA-41 | BRL-CAD: 03brlcad * r37704 10/brlcad/trunk/include/config_win.h: don't typedef ssize_t here. since it's part of public API, common needs to provide it. instead expand and group some of the basic c99 stdint types. |
| 21:14.54 | CIA-41 | BRL-CAD: 03brlcad * r37705 10/brlcad/trunk/include/common.h: if we don't have ssize_t (e.g., windows), use ptrdiff_t instead. it should be a signed type that matches pointer size and is c99. |
| 21:57.14 | louipc | starseeker: nice |
| 22:42.29 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) |
| 23:01.53 | ``Erik | oh, heh, brlcad... when starseeker was briefing his shtuff, he mentioned g-egg for panda3d, wm said that was really interesting because they had someone trying to use panda3d for visualizing stuff ... crazy, ainnit? |
| 23:35.25 | ``Erik | heh http://commons.wikimedia.org/wiki/File:Arch-render-vestibule.png |
