| 00:10.17 | IriX64 | http://www.pastebin.ca/580158 there it is |
| 00:15.40 | poolio | Is that with optimized and on what system? |
| 00:16.38 | IriX64 | optimized yes and compiler optimizations on cygwin |
| 00:17.13 | IriX64 | but as i say system was loaded, a compile going etc |
| 00:21.20 | IriX64 | 63 processes running, just checked |
| 00:41.55 | IriX64 | I see, I wouldn't lie to you about this, my system is capable. |
| 01:08.43 | poolio | Hooray, my first project segment works! |
| 01:13.42 | IriX64 | err well you know i can't spell |
| 01:13.58 | poolio | :) |
| 01:16.03 | IriX64 | poolio? what is voxel? |
| 01:17.52 | poolio | a pixel is a point in 2d space, a voxel is a point in 3d space |
| 01:37.20 | IriX64 | thankyou so you somehow represent a voxel using pixels correct? |
| 01:37.53 | poolio | well that's what ray tracing is about |
| 01:38.04 | poolio | in terms of internal representation a voxel is just a vector of 3 values |
| 01:38.15 | poolio | but I don't store voxels, I store rays |
| 01:38.56 | IriX64 | i picture rays as a point moving through whatever dimensional space |
| 01:39.18 | IriX64 | or hitting whatever object in that space |
| 01:40.28 | poolio | yeah that's normally the way it is, but in the context I'm using them a ray is "shot" through the model, and I essentially get a list of partitions of where that ray intersects the model |
| 01:40.46 | poolio | Although I don't have to calculate all that, that's librt :) |
| 01:42.33 | IriX64 | I picture mine as 3d raterization :) |
| 01:42.41 | IriX64 | rasterization too |
| 01:43.17 | IriX64 | ahh i see geometry is your method, thank you |
| 01:43.22 | IriX64 | :) |
| 01:47.18 | IriX64 | btw i would add an fcloseall() before the abort in bu_bomb(str) function, if you really want to try to preserve the database |
| 01:50.20 | poolio | Which code are you looking at? |
| 01:50.22 | IriX64 | and if anybodys listening, terra.g a null pointer happens somehow in g_dsp when you do an extract all |
| 01:51.03 | IriX64 | the bu_bomb code in is it bomb.c in util lib |
| 01:51.15 | poolio | oh alright, I thought you were referencing beset :P |
| 01:51.26 | IriX64 | no man sewage :) |
| 01:51.39 | poolio | sorry, vetoed by brlcad. complain to him ;) |
| 01:51.54 | IriX64 | sigh pulled rank again ;) |
| 02:18.20 | poolio | dinner time. I worked 12 hours today...why!?!? |
| 02:18.34 | IriX64 | so youd appreciate a break :) |
| 02:19.36 | poolio | 30:40 in 3 days. eek. |
| 02:20.02 | IriX64 | 5 seconds in a month (I'm a sloth) :) |
| 02:21.30 | IriX64 | I'm also a glutton for punishment, i'm trying to compile 7.8 and 7.10 at the same time:) |
| 03:08.21 | brlcad | yukonbob: you specified 100 0 0 for rcc wire's height vector, which means -- point it in the X direction 100 units |
| 03:11.13 | brlcad | IriX64: seriously, cut it out with the comments on the build if you're not going to work with me to resolve the issues (referring to comment you made earlier regarding 'so called upgrade' as that has nothing to do with your build problems) |
| 03:11.47 | IriX64 | farther down it does the undefs are in tk |
| 03:11.49 | brlcad | i asked you to leave the build alone too, so that we can proceed one issue at a time before you go all edit-happy on configure.ac too |
| 03:12.05 | IriX64 | that tree is alone |
| 03:14.42 | IriX64 | the undefs prevent bwish and also mged from getting built |
| 03:15.38 | brlcad | the information is way too out of context, i've no idea what you're referring to at this point |
| 03:15.51 | IriX64 | lets let it lie ok? |
| 03:16.10 | brlcad | and it's irrelevant -- there were/are other build issues in front of it that need to be addressed |
| 03:16.45 | brlcad | if the earlier build errors are not fixed correctly, *everything* afterwards is suspect and unreliable |
| 03:17.00 | IriX64 | ok |
| 03:17.36 | brlcad | even if it happens to "get past" the error or masks it or whatever .. if it's not properly fixed then the game is over |
| 03:18.14 | IriX64 | agreed do you still want to pursue it? |
| 03:18.21 | brlcad | so i committed a fix for that windows tk header issue -- where does the build stop next? |
| 03:19.13 | brlcad | yes, i want to work on getting your default system to compile completely first |
| 03:19.21 | IriX64 | perhaps we should abandon my effort tkwindefault.h is no where to be found and i cant get past it without it |
| 03:20.07 | brlcad | huh? |
| 03:20.17 | brlcad | you said you have a pristine checkout, yes? |
| 03:20.35 | IriX64 | as of last night as stated |
| 03:20.42 | brlcad | did you run the steps I said earlier today? |
| 03:20.54 | brlcad | i.e. update your sources and recompile |
| 03:21.02 | IriX64 | i stopped after last night you said to wait |
| 03:21.17 | brlcad | and then this morning, I gave you the next step |
| 03:21.28 | IriX64 | missed that just a sec |
| 03:21.58 | brlcad | 09:36 <@brlcad> IriX64: cvs update configure.ac && ./autogen.sh && ./configure && make |
| 03:22.27 | IriX64 | sorry missed that ill try now |
| 03:25.05 | IriX64 | logging in |
| 03:29.39 | brlcad | don't really need a play-by-play -- just what's the next error ;) |
| 03:29.51 | IriX64 | right |
| 03:29.57 | IriX64 | :) |
| 03:30.40 | IriX64 | btw i'm installing a forced build right now just to see |
| 03:32.52 | brlcad | yukonbob: if you make your wire's height vector actually point back downwards (remember hs trigonometry), you'll get the desired angle; something like 100 0 -100 for example for the height vector |
| 03:44.24 | IriX64 | making ill be right back |
| 03:55.25 | *** join/#brlcad poolio (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
| 04:06.02 | IriX64 | http://www.pastebin.ca/580581 your next error:) |
| 04:13.38 | brlcad | that's good, thanks |
| 04:14.01 | poolio | hey brlcad |
| 04:14.10 | poolio | brlcad: I have working code if you'd like to see! :D |
| 04:14.51 | brlcad | if you were committing frequently, I would already be seeing ;) |
| 04:15.01 | brlcad | but yes, i'd love to see :) |
| 04:15.48 | brlcad | don't be afraid to commit, and to commit _frequently_ .. fluidly, as you get something working, commit, new feature, commit, etc |
| 04:15.52 | poolio | brlcad: ok ok, i was cleaning it up a bit before commit |
| 04:16.07 | brlcad | so get it working, commit, clean up, commit, etc ;) |
| 04:16.56 | brlcad | lots of commits is a good thing, and *much* easier to review both in the moment and 10 years down the road |
| 04:17.24 | poolio | ok ok |
| 04:20.58 | brlcad | also, feel free to commit to other parts of the code if you run into things (like the missing assert.h you found earlier) |
| 04:21.20 | brlcad | or if you just want to improve/clean up, whatever floats your boat ;) |
| 04:22.08 | brlcad | they get caught as the other platforms are tested -- just happened to work for that dev (jason) that he didn't need that header on his configuration for some reason |
| 04:33.36 | *** join/#brlcad cadguy (n=cadguy@c-67-166-125-250.hsd1.ut.comcast.net) |
| 04:42.58 | CIA-4 | BRL-CAD: 03poolio * 10brlcad/src/gtools/beset/fitness.c: added working ray trace comparison based on linear difference of the partition |
| 04:44.38 | poolio | brlcad: ^^voila. sorry it took so long I was trying to fix a race condition that developed for i dont know what reason |
| 04:48.17 | brlcad | woot :) |
| 05:02.16 | poolio | brlcad: I had a question regarding allocating cpu resources: do I need to call rt_init_resource and bn_rand_init for everytime a raytrace a new object? |
| 05:04.07 | brlcad | iirc, no you don't -- should be able to call them just once per binary invocation |
| 05:06.14 | poolio | alright, it takes a pointer to rt_i and I change that with every new object, so I was just wondering |
| 05:07.56 | brlcad | hm, then don't quote me on that |
| 05:08.06 | brlcad | lemme look |
| 05:08.31 | poolio | thanks |
| 05:18.25 | poolio | brlcad: so if I run rt_clean on an already set-up rt_i and resources I do not need to re-init the resource? |
| 05:19.37 | poolio | if you look in the current code, I extract the rt_i, re-alloate resources, do stuff with the object, then run rt_clean ... and repeat |
| 05:19.37 | brlcad | no |
| 05:19.48 | brlcad | that sounds right |
| 05:20.02 | poolio | wait, so do or don't re-allocate resources, don't> |
| 05:20.03 | poolio | ? |
| 05:22.00 | brlcad | what do you mean by that? |
| 05:22.13 | brlcad | struct resource? |
| 05:23.27 | poolio | Easiest to see in the code, but I extract an rt_i from the database, run rt_init_resource and bn_rand_init for each CPU, run rt_prep_parallel, raytrace the object, and then run rt_clean(rt_i) |
| 05:24.04 | poolio | my question is do I need to run r_init_resource and bn_rand_init once (on each cpu) for the whole program, or do I need to run it every time I extract a new rt_i from the database |
| 05:24.25 | brlcad | every time you get a new rt_i |
| 05:24.30 | poolio | alright thanks |
| 05:24.38 | brlcad | but clean the old rt_i first like you're doing |
| 05:24.41 | poolio | k |
| 05:36.15 | *** join/#brlcad Laniakea (i=clock@217-162-228-127.dclient.hispeed.ch) |
| 06:02.45 | poolio | gnite zZz |
| 06:07.04 | *** join/#brlcad elite01 (n=elite01@195.37.106.60) |
| 06:40.40 | CIA-4 | BRL-CAD: 03poolio * 10brlcad/src/gtools/beset/fitness.c: moved global vars to fstate and general cleanup |
| 07:36.06 | *** join/#brlcad Laniakea (n=clock@zux221-122-143.adsl.green.ch) |
| 07:56.13 | *** join/#brlcad Elperion (n=Bary@p54874D38.dip.t-dialin.net) |
| 08:08.02 | *** join/#brlcad akreal (n=ak@ll-81-222-164-251.awanti.ru) |
| 08:17.25 | *** join/#brlcad ibot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 08:17.25 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || http://fisheye1.cenqua.com/browse/brlcad/brlcad || 7.10 is now released! .. e-mail announcements will follow posting of binary distributions |
| 08:25.30 | yukonbob | brlcad: re: post/cable heh -- my bad -- I was thinking of coordinates for second set of params, not vectors :P |
| 10:22.12 | *** join/#brlcad Bariton (n=Bary@p5487565E.dip.t-dialin.net) |
| 11:34.24 | *** join/#brlcad thing0 (n=ric@203-59-86-90.dyn.iinet.net.au) |
| 11:34.29 | thing0 | hey guys! |
| 11:34.34 | thing0 | got internet access down here |
| 11:34.39 | thing0 | have to use dialup |
| 11:34.42 | thing0 | but at least I got it |
| 11:34.43 | thing0 | hehe |
| 11:34.55 | thing0 | hey brlcad |
| 11:51.45 | *** join/#brlcad elite01 (n=elite01@195.37.106.60) |
| 11:52.51 | *** join/#brlcad thing1 (n=ric@203-59-86-90.dyn.iinet.net.au) |
| 12:11.43 | *** part/#brlcad thing1 (n=ric@203-59-86-90.dyn.iinet.net.au) |
| 13:39.14 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-079-094.pools.arcor-ip.net) |
| 13:47.31 | *** join/#brlcad poolio (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
| 13:49.09 | *** join/#brlcad SWPadnos (n=Me@dsl245.esjtvtli.sover.net) |
| 15:29.45 | *** join/#brlcad Bariton (n=Bary@p54875F7D.dip.t-dialin.net) |
| 16:00.07 | *** join/#brlcad IriX64 (n=mario_du@bas2-sudbury98-1128565739.dsl.bell.ca) |
| 16:00.41 | IriX64 | brlcad: sorry man machine check exception |
| 16:06.17 | IriX64 | http://rafb.net/p/cG0YgV19.html but this came up |
| 16:06.55 | IriX64 | our tree is still untouched this is another copy |
| 16:09.03 | IriX64 | don't worry about the -noinhibit-exec switch thats just a way to keep the build process going so you can see all the errors and warnings in the project |
| 16:27.23 | *** join/#brlcad docelic (n=docelic@212.91.114.145) |
| 16:58.52 | IriX64 | bwahha the handicapped build is installing :) |
| 17:00.48 | IriX64 | wonder if make bench will run on this |
| 17:02.33 | IriX64 | don't freaking beleive it its doing it |
| 17:12.09 | IriX64 | http://rafb.net/p/8dBwwd81.html haha sweet benchmark |
| 17:21.43 | IriX64 | no fbserv :) |
| 17:22.05 | IriX64 | err :( |
| 17:22.48 | *** join/#brlcad poolio (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
| 17:23.04 | poolio | grrrrr |
| 17:23.45 | IriX64 | christ,everbody run :) |
| 17:24.31 | poolio | internet went down, so I looked at the extension cable I had on the coaxial cable and a mouse had chewed through it. :( |
| 17:25.17 | IriX64 | i take it your cat had fried mouse or dinner then :) |
| 17:25.24 | IriX64 | err for too |
| 18:26.07 | poolio | why does return not return...? |
| 19:15.09 | poolio | brlcad: If I am at some sort of intermediary step in the code and I have a file I'm using to test a "module" of the program, should I commit the file used to run/test the module ? |
| 19:16.12 | brlcad | up to you for testing code, more of question of whether it'd be of any use to anyone watching and/or will it be useful a year from now when it's all said and done (even for just testing) |
| 19:17.07 | brlcad | system integration tests are desirable .. running your tool and expecting certain behavior |
| 19:18.20 | brlcad | we've not gone down the road of white-/black-box testing or unit testing so much |
| 19:18.51 | brlcad | a few of the tools do, and include testing routines w/ test code, but most are system level or non-existent |
| 19:19.02 | brlcad | so yeah.. whatever works for you ;) |
| 19:36.53 | poolio | brlcad: Well in the near future the tool will probably no longer work, it's just that at this step that other file is used as a "driver" to the module |
| 19:51.17 | poolio | brlcad: I opted to leave it out of the repository, but if you're curious in testing I can send it to you |
| 19:51.38 | CIA-4 | BRL-CAD: 03poolio * 10brlcad/src/gtools/beset/ (fitness.h fitness.c): modularized fitness functions |
| 20:11.15 | brlcad | only thing really missing are the build files so I can test-compile here ;) |
| 20:14.32 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/BUGS: annotate a couple of the bugs that dwayne reported regarding facedef and permute not coordinating with the display properly |
| 20:14.52 | *** join/#brlcad poolio_ (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
| 20:15.10 | poolio_ | sorry brlcad, thought mmy laptop was plugged in but ... |
| 20:17.22 | poolio | brlcad: so can I update configure.ac? |
| 20:19.04 | *** join/#brlcad _Bariton_ (n=Bary@p54875E9E.dip.t-dialin.net) |
| 20:20.58 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-079-094.pools.arcor-ip.net) |
| 20:23.47 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/BUGS: more bugs from dwayne's issues sheet including the return of the annoying cursor box character capture. also note BoT editing bug (units always mm), overlap tool inefficiency, and snap-to-grid issues. |
| 20:24.04 | brlcad | poolio: you can update anything, the commits are reviewed by myself and others |
| 20:24.16 | brlcad | if there's an issue, I'd let you know, but don't be shy ;) |
| 20:25.35 | CIA-4 | BRL-CAD: 03poolio * 10brlcad/src/gtools/beset/ (Makefile.am beset.c): added build files and test program |
| 20:26.27 | poolio | oh oops, two more |
| 20:28.46 | CIA-4 | BRL-CAD: 03poolio * 10brlcad/ (configure.ac src/gtools/Makefile.am): updated build files for beset |
| 20:30.02 | poolio | brlcad: Alright, should be good to go =) |
| 20:32.29 | CIA-4 | BRL-CAD: 03jlowenz * 10brlcad/include/vector.h: move now takes a const pointer to the pt |
| 20:34.25 | CIA-4 | BRL-CAD: 03jlowenz * 10brlcad/src/conv/iges/brlcad_brep.cpp: fix another knot issue with openNURBS; adjust brep tolerances (this needs to be looked at in more depth) |
| 20:35.48 | CIA-4 | BRL-CAD: 03jlowenz * 10brlcad/src/conv/iges/n_iges.hpp: turn off some debugging in the converter |
| 20:36.28 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/TODO: implement a region annointment command where the user can turn an assembly into a region and change all lower or higher regions into combinations |
| 20:38.14 | CIA-4 | BRL-CAD: 03jlowenz * 10brlcad/src/librt/g_brep.cpp: make brep_hit a value object (no dynamic alloc); now dropping hit points if they don't fall within subsurface bbox; turned off bbox plotting |
| 20:39.41 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/TODO: validate primitives during export so that it is guaranteed that illegal primitives will not be written to file; preserve an arb8 as an arb8 (instead of writing as arb6 or arb5) and similarly for the other arb# sizes |
| 20:41.00 | CIA-4 | BRL-CAD: 03jlowenz * 10brlcad/src/librt/opennurbs_ext.cpp: fix another knot-related bug; remove debugging output; adjust flatness tolerance for small curves |
| 20:42.57 | CIA-4 | BRL-CAD: 03jlowenz * 10brlcad/src/other/openNURBS/opennurbs_brep.cpp: adjust tolerance values in validity check - openNURBS was not using the values specified by the user (it was using hardcoded tolerances...) - this may need to be investigated further |
| 20:43.50 | brlcad | poolio: coolio |
| 20:44.47 | poolio | brlcad: did it work for you? |
| 20:48.44 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/TODO: Implement an optical shader for the new pixelated military camouflage style |
| 20:59.42 | *** join/#brlcad Laniakea (i=clock@217-162-204-104.dclient.hispeed.ch) |
| 21:21.15 | *** join/#brlcad cad14 (n=93f0ec08@bz.bzflag.bz) |
| 21:30.40 | *** join/#brlcad Bariton (n=Bary@p54875E9E.dip.t-dialin.net) |
| 21:36.22 | *** join/#brlcad cadguy (n=cadguy@c-67-166-125-250.hsd1.co.comcast.net) |
| 21:37.03 | poolio | alright i'm out for the night. gonna start working on the GA tomororw :D |
| 21:42.52 | yukonbob | away |
| 21:43.03 | yukonbob | ww |
| 21:47.46 | yukonbob | brlcad: did you read discussion of DISPLAY variables and how mged attaches? |
| 21:53.00 | brlcad | yukonbob: yes, I did and if I understood you correctly -- it wasn't intentional that it keeps trying |
| 21:53.08 | brlcad | it is intention that it tries :0 if display is not set |
| 21:56.25 | brlcad | and that was merely a support balance decision .. there are more users that try to run mged without ever having set display (particularly common on Mac OS X) than there are X11 users that intentionally unset it for some reason but have it running on :0 |
| 21:57.47 | brlcad | i'll look (or you're welcome to look) into patching it up so that it obeys display when it's set regardless of :0 working |
| 21:58.01 | brlcad | should just be a couple lines |
| 22:00.02 | *** join/#brlcad jimmyz (n=asd@host86-133-245-247.range86-133.btcentralplus.com) |
| 22:00.17 | yukonbob | that sounds good -- I don't know how far is looks, or if it's only the single :0.0 that it looks for (that's actually all that I'm running), but I can take a look... |
| 22:01.13 | yukonbob | as long as there's not some other reason for having it, but _I_ can't think of a good reason to have it, unless there's some internal (to ARL) reason? |
| 22:17.41 | brlcad | depends what the it is when you say by having "it" .. again checking :0 if display is unset is intentional and will preferably stay -- what wasn't intentional is trying :0 if display is set but doesn't work |
| 22:19.06 | brlcad | there's no reason really for the latter other than maybe just "try really hard to show something on a local X display when all else fails" .. which wasn't the intent |
| 22:29.15 | yukonbob | here's the scenarios I tested: |
| 22:29.27 | yukonbob | my real DISPLAY=:0.0 |
| 22:32.36 | yukonbob | setting DISPLAY=192.168.99.99:0.0 (non-existant) seemed to try that, then still connected to :0.0 |
| 22:34.16 | yukonbob | setting DISPLAY='' also connected to :0.0 -- and I personally think this is an error... if somebody is running X Window System on Mac (or Windows, or anywhere), their display should be set... so from an xterm for example, anybody could run mged and have is appear on the proper display |
| 22:36.29 | yukonbob | mged picking display's to run on that are not listed in DISPLAY is overstepping it's responsibilities... |
| 23:06.07 | *** join/#brlcad IriX64 (n=mario_du@bas2-sudbury98-1128565739.dsl.bell.ca) |
| 23:37.17 | brlcad | yukonbob: I entirely believe you that it's falling back to :0 .. I was just saying that that part wasn't intentional -- the intent was for systems were DISPLAY isn't set at all (i.e. running in Mac OS X terminal mostly) |
| 23:39.16 | brlcad | and not empty, but actually unset (which is a bit tricky to test for and likely not accounting for empty either) :) |
| 23:39.39 | yukonbob | OK -- I think we're on same page ;) |
| 23:40.18 | brlcad | probably not entirely, I get the feeling that you'd like it to fail even try if display isn't set too |
| 23:40.34 | brlcad | but the pages are at least facing/close ;) |
| 23:40.35 | yukonbob | Is there a native (ie: Aqua) build for MacOS X? (or a build for MacOS Classic for that matter), or do/have the Macs always required an X Window System installation? |
| 23:40.57 | brlcad | there's not yet a native build |
| 23:41.08 | brlcad | that's part of the reason for the upgrade to 8.5 |
| 23:41.18 | brlcad | a ton of AquaTk stuff was fixed in libtk |
| 23:41.34 | yukonbob | nice... |
| 23:41.41 | brlcad | so far, though, our mac dists have always required X11 on os x |
| 23:42.15 | brlcad | which is exceptionally unfortunate towards the mac ethos.. that's by far the #1 support issue .. how to run brl-cad on a mac |
| 23:43.09 | brlcad | no icon? X-eleve-what? command thingie type what? display? terminal? xterm? where's my icon? |
| 23:43.16 | yukonbob | ok -- I think I _would_ like to fail if there's no DISPLAY set...(ie: running from vt console...) If somebody is running it from w/i their running X11 session (ie: from xterm) they'll have a working DISPLAY, if they're trying to launch from bar on bottom... they'd need a wrapper script that has default :0.0 perhaps? |
| 23:43.47 | yukonbob | ^^ how about a mac-specific wrapper script |
| 23:44.31 | brlcad | actually, several open up terminal and try running from there .. sometimes X11 is running, sometimes it's not even installed, .. one of the most common, though was starting X11 yet typing mged in Terminal (where DISPLAY isn't set) |
| 23:44.53 | yukonbob | that'd be brlcad.runme, pulled into the launch bar... #!/bin/sh; env DISPLAY=:0.0 brlcad.exe |
| 23:45.24 | brlcad | that would be a good solution, though there is no brlcad.exe :) |
| 23:45.46 | yukonbob | you get my point though ;) |
| 23:46.10 | yukonbob | btw, do you know anything about X11 BigFonts? |
| 23:47.05 | brlcad | hm, as a proper noun, not really |
| 23:48.00 | brlcad | a little about "big fonts" in X11, though .. xfontsel your font, and go to town ;) |
| 23:48.25 | brlcad | ah, huh.. wierd |
| 23:48.35 | yukonbob | 1 sec... |
| 23:48.56 | yukonbob | bash-3.2$ pl-X < bridge_plot.plot |
| 23:48.56 | yukonbob | pl-X: Can't open font |
| 23:49.17 | brlcad | source says it should be trying "vtsingle" |
| 23:49.49 | brlcad | which is a bizzare default.... |
| 23:50.00 | brlcad | hard-coded nonetheless |
| 23:50.12 | yukonbob | OK -- I was just assuming Bigfont was issue, because I see string: |
| 23:50.22 | yukonbob | "25509 1 pl-X read(0x3, 0xbfbfe54c, 0x20) = 32 |
| 23:50.22 | yukonbob | <PROTECTED> |
| 23:50.25 | yukonbob | <PROTECTED> |
| 23:50.28 | yukonbob | <PROTECTED> |
| 23:50.30 | yukonbob | <PROTECTED> |
| 23:50.33 | yukonbob | <PROTECTED> |
| 23:50.35 | yukonbob | <PROTECTED> |
| 23:50.38 | yukonbob | " |
| 23:50.43 | yukonbob | ...and don't have loaded, nor had I heard of it before... |
| 23:51.08 | brlcad | sounds like some XFree internal symbol perhaps |
| 23:51.20 | brlcad | did it crash on you or just say can't open? |
| 23:52.00 | yukonbob | xorg has lib for it too -- I've only just started looking into it, but might be mechanism for sharedmem for fonts... I'm just not clear (and might not even pursue it if it's vtsingle issue). |
| 23:53.04 | yukonbob | just said couldn't open... |
| 23:53.56 | yukonbob | to tagent once more ;) ... |
| 23:54.01 | yukonbob | *tangent |
| 23:54.13 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
| 23:54.14 | yukonbob | are there font method in mged? |
| 23:54.23 | yukonbob | *methods |
| 23:54.41 | brlcad | should probably obey some -font option or something similar and default to 'fixed' or '6x10' or something |
| 23:55.17 | brlcad | there are means to set/change the fonts if that's what you mean |
| 23:55.27 | yukonbob | ie: for using fonts in renderings. |
| 23:55.50 | brlcad | File->Preferences->Fonts for changing various aspects of mged |
| 23:56.03 | brlcad | ah, text on renderings |
| 23:56.06 | yukonbob | (in title font "my_cool_font.ttf" "This is my title") |
| 23:56.07 | *** join/#brlcad IriX64 (n=mario_du@bas2-sudbury98-1128565739.dsl.bell.ca) |
| 23:56.21 | brlcad | yes and no, mostly no |
| 23:56.26 | brlcad | that's been a desire for quite a while |
| 23:56.59 | brlcad | yes in the sense that there's a way to do it, but it's really a round-about way that is rather overly complicated |
| 23:57.29 | brlcad | yes you can get to NYC from Miami on a unicycle... but you probably don't want to |
| 23:58.15 | yukonbob | alright --- I'll leave fonts at that for now ;) |
| 23:59.30 | yukonbob | if I supply patches, should I just mail them to you, or post here, or ?? |