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``Erikonce 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``ErikO.o I thrashed a web page database
02:37.11yukonbob:)
02:37.51yukonbobkinda 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.06PrezKennedyso i dont think accounting will be sending me a christmas card this year
04:32.54PrezKennedyi 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``Erikwow, my freshmeat 'changes' chunk went through without editing
14:42.32``Erikhttp://www.xkcd.com/
14:42.39``Erik"real programmers use..."
15:08.09CIA-31BRL-CAD: 03erikgreenwald * r30181 10/brlcad/trunk/src/libbu/image.c: PPM save support
15:08.54CIA-31BRL-CAD: 03erikgreenwald * r30182 10/brlcad/trunk/src/adrt/libutil/ (Makefile.am image.c image.h): libbu is now responsible for saving images
15:34.14CIA-31BRL-CAD: 03erikgreenwald * r30183 10/brlcad/trunk/ (include/bu.h src/libbu/image.c): change image data type to be unsigned
15:40.15CIA-31BRL-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.24MaloeranEheh, nice comic
15:43.18MaloeranAnd woohoo, the commit went through finally. +30000 lines, -13000 lines, you could say it was about time
15:44.07``Erikheh, saw the email O.o :)
15:44.21Maloeran:)
15:52.27MaloeranOh erik, any idea how other OSes will react to mmap()ing gigabytes of read-only memory?
15:52.47``Erikum, archaic ones might freak out
15:52.53MaloeranThe idea is just to reserve big chunks of consecutive addresses for further uses, of course
15:52.53``Erikwindows will probably flip
15:53.05MaloeranOh? It's a free operation on Linux obviously
15:53.23``Erikopensolaris and fbsd should be "right there", linux probably is ok with it after 2.6,
15:53.30MaloeranWhat about the other Unixes?
15:53.37MaloeranI see
15:54.13MaloeranI don't want OSes to try to reserve 128gb of swap space or something
15:54.24MaloeranAs Linux would if the memory was initially read-write
15:54.27``Erikmmap is a pretty trivial operation on any half-sane unix, the biggie is being able to address it
15:54.34Maloeran( without MMAP_NORESERVE, etc. )
15:54.38``Erikyeah, linux is pretty stupid about swap management
15:54.40``ErikO:-)
15:54.53``Erikthe bsd family all does COW even on mmap'd stuff
15:55.08MaloeranCOW?
15:55.11``Erikso you can mmap a terabyte file with only 128 megs around
15:55.13``Erikcopy on write
15:55.34MaloeranAh sure, so does Linux obviously
15:55.50MaloeranThe 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.56MaloeranHence reserving the swap space for it
15:56.22``Erikhm, I've never actually seen an oom on bsd with mmap, and I do big mmaps on small machines
15:56.34``ErikI'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.53MaloeranBut I'm talking about a mmap that is not backed by any file
15:56.57``ErikO.o
15:57.03MaloeranLike 128gb of MMAP_ANONYMOUS mmap
15:57.03``Erikuh, what're you mmapping?
15:57.18MaloeranNothing, just reserving memory space for further uses
15:57.27``Erikhrm, I d'no, I don't use those
15:57.41MaloeranI need a big chunk of consecutive addresses and I have no idea how much of it I will actually use
15:57.48``Erikhave yet to see where they offer any advantage
15:57.53MaloeranLinux does not mind if I reserve a tetrabyte that way through mmap()
15:58.18``Erikhrm
15:58.35MaloeranAny thoughts?
15:58.35``Eriklinux doesn't have memory management routines that cope with demands of contiguity? (is that a word, even?)
15:58.49``Eriklike, I'd use contigmalloc() on fbsd
15:59.09MaloeranHum, no.. Not sure what that does
15:59.36MaloeranI 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``Erikyou don't trust linux's LAB mapping? :)
16:00.55MaloeranThat's not the point, the memory addresses *must* be tightly packed in the virtual memory space
16:00.56``Erikso just malloc in multiples of page size
16:01.22MaloeranThere's absolutely no garantee there
16:01.55brlcadkorean in 30
16:02.28MaloeranHow do you think BSD will react if I mmap() 128gb of MMAP_ANONYMOUS read-only memory?
16:03.02``Erikd'no, haven't tried it
16:03.07``Erikdon't you have a bsd machine? :)
16:03.09MaloeranOr does it offer any other mechanism to reserve a big chunk of virtual mapping?
16:04.01MaloeranLinux 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.15CIA-31BRL-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.16CIA-31BRL-CAD: 03tossup * r30186 10/jbrlcad/trunk/ (14 files in 13 dirs):
20:52.17CIA-31BRL-CAD: Moved geometry, preppedGeometry, spacePartition, numerics, and samples
20:52.19CIA-31BRL-CAD: directories to src directory. Moved test.asc file to test directory.
21:00.31``ErikO.O
21:24.35*** join/#brlcad iraytrace (n=iraytrac@cocoa.sci.utah.edu)
21:29.23``Erikleebert
22:04.53*** join/#brlcad obfucius (n=casey@adsl-99-128-43-142.dsl.chi2ca.sbcglobal.net)
22:06.20obfuciusWhere can I submit a bug rep?
22:07.19brlcadhttp://sourceforge.net/tracker/?group_id=105292&atid=640802
22:07.41brlcadmore specifically, http://sourceforge.net/tracker/?func=add&group_id=105292&atid=640802
22:08.44iraytraceevenin
22:08.49brlcadhowdy
22:09.15iraytracesaw the jbrlcad commit.  Way cool someone's working with it.
22:09.59brlcada bit of a flurry regarding it over the past couple weeks
22:11.33obfuciusno 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.25brlcadobfucius: does the command window show up?
22:15.07obfuciuswell 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.56yukonbobobfucius: 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.