IRC log for #brlcad on 20080201

00:26.55 *** join/#brlcad Twingy (n=justin@74.92.144.217)
01:03.04 *** join/#brlcad PrezKennedy (i=Matt@74.86.45.130)
02:00.52 *** join/#brlcad starseeker (n=CY@c-68-33-217-173.hsd1.md.comcast.net)
02:05.17 ``Erik once again, incremental backups have saved my hind
02:05.33 ``Erik (mental note; update on a large table with no 'where' clause is bad)
02:07.31 ``Erik O.o I thrashed a web page database
02:37.11 yukonbob :)
02:37.51 yukonbob kinda like "rm -fr / home/erik/foo" as root
02:54.14 *** join/#brlcad yukonbob (n=yukonbob@198.235.198.234)
03:26.14 *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6)
04:32.06 PrezKennedy so i dont think accounting will be sending me a christmas card this year
04:32.54 PrezKennedy i only hosed them up for 6 hours the past 2 days... plenty of time for them to master minesweeper at least
05:18.36 *** join/#brlcad cad25 (n=daae6815@bz.bzflag.bz)
06:38.34 *** join/#brlcad vedge (i=vedge@vedge.org)
10:50.24 *** join/#brlcad elite01 (n=elite01@dslc-082-082-072-163.pools.arcor-ip.net)
11:20.34 *** join/#brlcad Gruni (n=gruni@rootgeek.org)
11:26.18 *** join/#brlcad Gruni (n=gruni@rootgeek.org)
13:28.06 *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz)
14:22.23 *** join/#brlcad CIA-31 (n=CIA@208.69.182.149)
14:27.49 ``Erik wow, my freshmeat 'changes' chunk went through without editing
14:42.32 ``Erik http://www.xkcd.com/
14:42.39 ``Erik "real programmers use..."
15:08.09 CIA-31 BRL-CAD: 03erikgreenwald * r30181 10/brlcad/trunk/src/libbu/image.c: PPM save support
15:08.54 CIA-31 BRL-CAD: 03erikgreenwald * r30182 10/brlcad/trunk/src/adrt/libutil/ (Makefile.am image.c image.h): libbu is now responsible for saving images
15:34.14 CIA-31 BRL-CAD: 03erikgreenwald * r30183 10/brlcad/trunk/ (include/bu.h src/libbu/image.c): change image data type to be unsigned
15:40.15 CIA-31 BRL-CAD: 03erikgreenwald * r30184 10/brlcad/trunk/src/util/bwdiff.c: use bu_exit() instead of bu_log (I think that's what was intended)
15:42.24 Maloeran Eheh, nice comic
15:43.18 Maloeran And woohoo, the commit went through finally. +30000 lines, -13000 lines, you could say it was about time
15:44.07 ``Erik heh, saw the email O.o :)
15:44.21 Maloeran :)
15:52.27 Maloeran Oh erik, any idea how other OSes will react to mmap()ing gigabytes of read-only memory?
15:52.47 ``Erik um, archaic ones might freak out
15:52.53 Maloeran The idea is just to reserve big chunks of consecutive addresses for further uses, of course
15:52.53 ``Erik windows will probably flip
15:53.05 Maloeran Oh? It's a free operation on Linux obviously
15:53.23 ``Erik opensolaris and fbsd should be "right there", linux probably is ok with it after 2.6,
15:53.30 Maloeran What about the other Unixes?
15:53.37 Maloeran I see
15:54.13 Maloeran I don't want OSes to try to reserve 128gb of swap space or something
15:54.24 Maloeran As Linux would if the memory was initially read-write
15:54.27 ``Erik mmap is a pretty trivial operation on any half-sane unix, the biggie is being able to address it
15:54.34 Maloeran ( without MMAP_NORESERVE, etc. )
15:54.38 ``Erik yeah, linux is pretty stupid about swap management
15:54.40 ``Erik O:-)
15:54.53 ``Erik the bsd family all does COW even on mmap'd stuff
15:55.08 Maloeran COW?
15:55.11 ``Erik so you can mmap a terabyte file with only 128 megs around
15:55.13 ``Erik copy on write
15:55.34 Maloeran Ah sure, so does Linux obviously
15:55.50 Maloeran The point is that the OS may try to "garantee" that the memory exists, as it won't segfault when trying to access it
15:55.56 Maloeran Hence reserving the swap space for it
15:56.22 ``Erik hm, I've never actually seen an oom on bsd with mmap, and I do big mmaps on small machines
15:56.34 ``Erik I've seen linux crap itself readily and badly in that kinda situation
15:56.51 ``Erik (if it's mmap'd, it's backed by the FILE, so only a fucking retard would reserve swap space... typical linux, tho ;)
15:56.53 Maloeran But I'm talking about a mmap that is not backed by any file
15:56.57 ``Erik O.o
15:57.03 Maloeran Like 128gb of MMAP_ANONYMOUS mmap
15:57.03 ``Erik uh, what're you mmapping?
15:57.18 Maloeran Nothing, just reserving memory space for further uses
15:57.27 ``Erik hrm, I d'no, I don't use those
15:57.41 Maloeran I need a big chunk of consecutive addresses and I have no idea how much of it I will actually use
15:57.48 ``Erik have yet to see where they offer any advantage
15:57.53 Maloeran Linux does not mind if I reserve a tetrabyte that way through mmap()
15:58.18 ``Erik hrm
15:58.35 Maloeran Any thoughts?
15:58.35 ``Erik linux doesn't have memory management routines that cope with demands of contiguity? (is that a word, even?)
15:58.49 ``Erik like, I'd use contigmalloc() on fbsd
15:59.09 Maloeran Hum, no.. Not sure what that does
15:59.36 Maloeran I do my own memory management anyway, but I need big chunks of packed addresses for certain things
15:59.39 ``Erik (tho phkmalloc guarantees singly malloc'd chunks to be contiguous iirc.. no mmap hackery that opens up security holes out the wazoo)
16:00.18 ``Erik you don't trust linux's LAB mapping? :)
16:00.55 Maloeran That's not the point, the memory addresses *must* be tightly packed in the virtual memory space
16:00.56 ``Erik so just malloc in multiples of page size
16:01.22 Maloeran There's absolutely no garantee there
16:01.55 brlcad korean in 30
16:02.28 Maloeran How do you think BSD will react if I mmap() 128gb of MMAP_ANONYMOUS read-only memory?
16:03.02 ``Erik d'no, haven't tried it
16:03.07 ``Erik don't you have a bsd machine? :)
16:03.09 Maloeran Or does it offer any other mechanism to reserve a big chunk of virtual mapping?
16:04.01 Maloeran Linux offers plenty of mechanisms to manage the virtual mapping, I was trying to find a Posix-compliant way with the mmap stuff, without using any Linux-specific options
16:38.15 CIA-31 BRL-CAD: 03brlcad * r30185 10/brlcad/trunk/TODO: the bug of mged outright not working is no longer a problem
16:38.25 *** join/#brlcad docelic (n=docelic@77.237.109.247)
17:01.54 *** join/#brlcad jgay (n=jgay@fsf/staff/jgay)
17:46.27 *** join/#brlcad vedge (i=vedge@vedge.org)
18:14.20 ``Erik <-- hasn't worried about big mem crap like that, doesn't know *shrug*
18:25.58 *** join/#brlcad Elperion (n=Bary@p54873E64.dip.t-dialin.net)
18:53.08 *** join/#brlcad alex_joni (n=juve@emc/board-of-directors/alexjoni)
19:50.50 *** join/#brlcad Elperion (n=Bary@p54873E64.dip.t-dialin.net)
20:19.59 *** join/#brlcad Elperion (n=Bary@p54873E64.dip.t-dialin.net)
20:52.16 CIA-31 BRL-CAD: 03tossup * r30186 10/jbrlcad/trunk/ (14 files in 13 dirs):
20:52.17 CIA-31 BRL-CAD: Moved geometry, preppedGeometry, spacePartition, numerics, and samples
20:52.19 CIA-31 BRL-CAD: directories to src directory. Moved test.asc file to test directory.
21:00.31 ``Erik O.O
21:24.35 *** join/#brlcad iraytrace (n=iraytrac@cocoa.sci.utah.edu)
21:29.23 ``Erik leebert
22:04.53 *** join/#brlcad obfucius (n=casey@adsl-99-128-43-142.dsl.chi2ca.sbcglobal.net)
22:06.20 obfucius Where can I submit a bug rep?
22:07.19 brlcad http://sourceforge.net/tracker/?group_id=105292&atid=640802
22:07.41 brlcad more specifically, http://sourceforge.net/tracker/?func=add&group_id=105292&atid=640802
22:08.44 iraytrace evenin
22:08.49 brlcad howdy
22:09.15 iraytrace saw the jbrlcad commit. Way cool someone's working with it.
22:09.59 brlcad a bit of a flurry regarding it over the past couple weeks
22:11.33 obfucius no geometry display window is appearing in mged, but I think I might have to just compile with glx support because I'm running with an nvidia glx driver under linux
22:12.25 brlcad obfucius: does the command window show up?
22:15.07 obfucius well I'll run mged from the command line like %mged -n project.g and it asks wether I want to use nu, X, or ogl. I've tried both ogl and X but nothing happens.
22:58.56 yukonbob obfucius: what's your platform?
23:14.27 *** join/#brlcad yukonbob (n=yukonbob@198.235.198.234)
23:20.27 *** join/#brlcad jgay (n=jgay@fsf/staff/jgay)
23:27.13 *** join/#brlcad Twingy (n=justin@74.92.144.217)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.