| 00:07.12 | Malyce | svc co svn://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk brlcad-sf |
| 00:07.26 | Malyce | svn: can't connect ot host: Connection refused |
| 00:07.29 | Malyce | to |
| 00:19.06 | *** join/#brlcad Ralith|trip (i=40f692fb@gateway/web/ajax/mibbit.com/x-969114c0f859777f) |
| 00:21.29 | Malyce | what did I do wrong ? |
| 00:21.45 | Ralith|trip | you looked at it funny |
| 00:21.48 | Ralith|trip | we don't allow that around here |
| 00:21.53 | Malyce | rats |
| 00:21.57 | Malyce | I knew it |
| 00:22.21 | Malyce | was my syntax wrong ? |
| 00:22.29 | Malyce | or was it the repo address |
| 00:22.58 | Malyce | syntax |
| 00:23.06 | Malyce | fixed |
| 00:25.07 | Malyce | though, I am not sure why the other one didn't work |
| 00:25.41 | Malyce | svn:// instead of http:// |
| 00:34.04 | brlcad | only certain protocols are allowed |
| 00:34.14 | brlcad | have to follow the checkout instructions ;) |
| 00:40.41 | Malyce | and where can I read these instructions |
| 00:41.00 | Malyce | ? |
| 00:43.04 | Malyce | are these SF specific or do you mean general unix syntax ? |
| 00:46.24 | brlcad | Malyce: even the general sf instructions say to use http/https instead of svn |
| 00:47.12 | Malyce | again, where are these instructions ? |
| 00:47.30 | Malyce | on the SF main page, there is news about new project. There is a help button at the bottom |
| 00:47.38 | Malyce | but the help is pretty useless |
| 00:47.42 | brlcad | Malyce: have you looked? |
| 00:48.13 | Ralith|trip | the new layout does make it kind of hard to find if you don't know where to look |
| 00:48.52 | Malyce | I tried the first time I tried to checkout from XP |
| 00:48.53 | brlcad | Ralith|trip: i'm not talking about hunting around the repo -- there are docs on our site and on sf.net that say exactly what to use |
| 00:49.23 | brlcad | i mean, if you even put "brl-cad svn" into google, it's in the top results |
| 00:49.32 | Ralith|trip | I was referring to the docs on source forge |
| 00:49.33 | brlcad | hence my question of whether he even looked |
| 00:49.42 | Ralith|trip | didn't know it was that googleable, though |
| 00:49.59 | Malyce | I did look into the SF page, but I didn't google that |
| 00:50.06 | Ralith|trip | always google |
| 00:50.14 | Malyce | then someone told me the repo address |
| 00:50.19 | Malyce | Erik |
| 00:50.21 | brlcad | http://brlcad.org/wiki/Building_from_SVN is the page, under our Documentation |
| 00:50.23 | Malyce | and it worked |
| 00:50.31 | brlcad | and it's been said here too :) |
| 00:50.33 | brlcad | ~cadsvn |
| 00:50.34 | ibot | To obtain BRL-CAD from Subversion: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk brlcad |
| 00:50.52 | Malyce | is this an IRC service ? |
| 00:51.04 | brlcad | so... someone told you here.. don't you have logs? |
| 00:52.33 | Malyce | Erik |
| 00:52.57 | brlcad | what about him? |
| 00:53.03 | madant | hmm.. another great morning :) |
| 00:53.09 | brlcad | howdy madant |
| 00:53.12 | pacman87 | hi madant |
| 00:53.17 | Malyce | he gave me the url |
| 00:53.34 | Ralith|trip | tries to work out how to bit-pack floats given min, max, and desired precision values |
| 00:53.45 | madant | hi all :) just heading out to town . |
| 00:53.47 | Malyce | but i used it inside windows the first time, so i didn't have the svn:/https: problem |
| 00:53.52 | brlcad | Malyce, yes, you already said that.. :) I presume over IRC? don't you have logs? |
| 00:54.01 | Malyce | I should pay more attention to the brl-wiki |
| 00:54.07 | Malyce | I checked |
| 00:54.47 | Malyce | is it possible to also read the backlog when I am not on the channel ? |
| 00:54.55 | brlcad | ~logs |
| 00:54.56 | ibot | All conversations are logged to http://ibot.rikers.org/channel, where "channel" is replaced by the URL-encoded channel name, such as %23freenode for #freenode. Lines starting with spaces are not logged. |
| 00:55.15 | brlcad | it's generally better to stay on the channel, though, like via a screen session |
| 00:55.38 | brlcad | with irc hilight history over a screen session, you're always on irc and can review logs/history/hilight |
| 00:56.28 | brlcad | i'm sure there are tutorials on the web, but basically running screen+irssi or simply leaving an irc client running and just using /away while minimizing as an alternative to screen |
| 00:56.52 | Malyce | I am always on IRC unless I am offline |
| 00:57.15 | Malyce | so, to read the backlog, I'll go to ibot |
| 00:57.37 | Malyce | I thought you meant the IRC client logs |
| 00:57.39 | Malyce | heh |
| 00:57.56 | pacman87 | I log IRC chats through my client |
| 00:58.09 | Ralith|trip | doesn't everyone? |
| 00:58.30 | Malyce | its auto with mIRC |
| 00:59.05 | brlcad | Malyce: many are *always* on IRC even when offline, that's part of the beauty of screen |
| 00:59.28 | Malyce | how so ? |
| 00:59.40 | brlcad | and I was referring to *your* irc logs earlier, but there are also general channel logs |
| 00:59.59 | Malyce | you mean the url you gave just now ? |
| 01:00.18 | brlcad | those would be the general channel logs |
| 01:00.28 | brlcad | the one that ibot mentioned are the general logs |
| 01:00.41 | Malyce | what is ibot ? |
| 01:00.54 | Malyce | just a channel bot ? |
| 01:00.54 | brlcad | an irc bot with lots of factoids |
| 01:01.11 | Malyce | so, you invoked it ? |
| 01:01.12 | brlcad | a multiple-channel bot, hundreds of channels |
| 01:01.21 | brlcad | no |
| 01:01.46 | Malyce | when does it provide info ? |
| 01:01.53 | brlcad | when you ask it? |
| 01:02.25 | brlcad | Malyce: I take it you're very new to IRC? |
| 01:02.28 | Malyce | i didn't ask it anything, did you ? |
| 01:02.31 | Malyce | very very new |
| 01:02.57 | Malyce | I knew about bot's from the Basshunter song |
| 01:03.01 | Malyce | Boten Anna |
| 01:03.07 | brlcad | you get ibot's attention with ~ or with its name prefixed to the line |
| 01:03.08 | Malyce | then did some wiki reading |
| 01:03.25 | Malyce | cool |
| 01:03.34 | brlcad | the bot has various tidbits of information, humor, actions, and other services it provides |
| 01:03.35 | Malyce | ~what's up |
| 01:03.36 | ibot | Up is the direction away from the central point of gravity. |
| 01:03.43 | Malyce | ahahahahaha |
| 01:03.58 | Malyce | this is so cooooool |
| 01:04.41 | brlcad | it can be very useful and entertaining, but try to keep the public usage tamed -- you can talk to it in private or in #botpark if you want to "play" |
| 01:04.56 | Malyce | I have a new friend now |
| 01:04.58 | Malyce | :D |
| 01:05.19 | brlcad | ~malyce is very very new to IRC, but learning quickly |
| 01:05.20 | ibot | brlcad: okay |
| 01:05.37 | brlcad | ibot: malyce? |
| 01:05.38 | ibot | i heard malyce is very very new to IRC, but learning quickly |
| 01:05.41 | Ralith|trip | wow |
| 01:05.59 | Ralith|trip | ##c++ is full |
| 01:06.06 | brlcad | "full"? |
| 01:06.13 | Ralith|trip | or under attack, or something? |
| 01:06.16 | Ralith|trip | I got shunted to overflow |
| 01:06.21 | pacman87 | bouncers at the door? |
| 01:06.27 | Ralith|trip | prety much |
| 01:06.29 | Ralith|trip | pretty* |
| 01:06.32 | brlcad | Ralith|trip: I got in just fine |
| 01:06.37 | Ralith|trip | hm. |
| 01:06.44 | Ralith|trip | probably filtering unregistered users |
| 01:06.53 | Ralith|trip | gives Ralith a sidelong look |
| 01:07.27 | Ralith|trip | more likely, filtering mibbit users |
| 01:07.41 | Ralith|trip | oh well. |
| 01:08.18 | brlcad | you're not identified |
| 01:08.44 | Ralith|trip | hmm |
| 01:08.49 | brlcad | don't remember my modes, but pretty sure one of the modes (+Pcflnrt #overflow 777) means kick you to overflow |
| 01:09.03 | Ralith_ | yay |
| 01:09.18 | Ralith_ | victory |
| 01:13.20 | brlcad | yukonbob: request pending for you |
| 01:13.24 | brlcad | poolio: you too, pending request |
| 01:20.04 | poolio | brlcad: gsoc stuffs? |
| 01:20.45 | brlcad | yes |
| 01:20.49 | brlcad | poolio: are you on the devel list? |
| 01:21.00 | brlcad | sending out a gsoc e-mail |
| 01:21.41 | Ralith_ | oo |
| 01:24.18 | brlcad | anyone who has already submitted an application -- do you get an e-mail notification if a comment is posted? |
| 01:25.31 | Ralith_ | I don't think I've had any comments posted. |
| 01:25.37 | Ralith_ | didn't yesterday, anyway |
| 01:25.39 | Ralith_ | rechecks |
| 01:26.48 | Ralith_ | there's a 'subscribe to updates button,' suggesting that such a thing might be opt in |
| 01:27.01 | brlcad | okay, that's good to know |
| 01:27.19 | brlcad | mentors get two buttons (one for public, another for private) |
| 01:27.21 | Ralith_ | it's not clear whether that means notify on edits, comments, or both |
| 01:27.28 | brlcad | tediously had to subscribe to everything |
| 01:33.40 | Ralith_ | wonders how long it takes the mailing list to get stuff out |
| 01:36.10 | poolio | brlcad: woops, I wasn't :) |
| 01:36.14 | brlcad | i've seen anywhere from less than a minute to the next day |
| 01:36.24 | brlcad | poolio: ah, okay |
| 01:36.26 | brlcad | thought so |
| 01:36.31 | brlcad | removes poolio from the CC line |
| 01:36.47 | Ralith_ | the next day? O.o |
| 01:36.52 | poolio | I just subscribed to it though |
| 01:37.16 | Ralith_ | I guess I shouldn't bother eagerly spamming refresh on gmail. |
| 01:37.53 | brlcad | usually within 5 minutes |
| 01:41.18 | brlcad | cool, gives an e-mail and a count |
| 01:41.33 | brlcad | this is gonna be a flurcking ton of e-mail... |
| 01:43.47 | poolio | brlcad: err, what's going on? |
| 01:43.56 | brlcad | hm? |
| 01:44.19 | brlcad | poolio: i was just drafting up a message about gsoc to the list, making sure all the mentors are included |
| 01:44.35 | poolio | ah cool cool |
| 01:44.58 | brlcad | poolio: you still have to confirm on socghop site too |
| 01:45.37 | poolio | yeah I know, I'm filling out the forms now |
| 01:45.41 | brlcad | it's a silly 3-way ping-pong |
| 01:45.45 | Ralith_ | confirm? |
| 01:45.52 | Ralith_ | poolio's mentoring? |
| 01:46.19 | brlcad | always good to have backup mentors |
| 01:46.29 | Ralith_ | cool |
| 01:46.52 | brlcad | anyone that's not a student could conceivably be a mentor, *especially* if they have already worked with the code |
| 01:47.06 | brlcad | but even that is technically not requisite.. depends on the student/project/org |
| 01:51.08 | poolio | brlcad: I think I'm done...? |
| 01:51.13 | poolio | Ralith_: Yep :) |
| 01:52.17 | Ralith_ | heads off |
| 01:52.19 | Ralith_ | back home tomorrow. |
| 01:54.54 | poolio | brlcad: do you know how many slots we have yet? |
| 02:00.28 | brlcad | preliminary slots will be on tuesday iirc |
| 02:00.41 | brlcad | but we're not taking more than 5 regardless |
| 02:00.53 | brlcad | and technically as few as 1 |
| 02:08.16 | dreeves | brlcad I have an image of the simple brep I was wondering if you had a minute to look and tell me if it looks correct? |
| 02:15.18 | dreeves | I emailed and image to you |
| 02:17.12 | brlcad | okay |
| 02:48.35 | brlcad | dreeves: test case in what regard? |
| 02:48.55 | brlcad | is that one of the breps made from one of the proc-db tools? |
| 02:49.18 | brlcad | and what do you mean by "this is using the utah code"? |
| 02:50.43 | dreeves | yes it is brep_simple from the proc-db |
| 02:52.01 | dreeves | the utah code is the code written by William Martin from University of Utah |
| 02:52.28 | brlcad | i'm familiar with the project |
| 02:52.53 | dreeves | I just didn't know if I had a good test case or not |
| 02:53.04 | brlcad | so you made a brep using brep_simple, then exported that out to whatever they're taking as input? |
| 02:53.24 | brlcad | brep_simple is certainly a starting point |
| 02:53.30 | dreeves | No I pulled the source into librt |
| 02:53.30 | brlcad | or breplicator's cube |
| 02:53.54 | brlcad | so you hooked into _shot() and _prep() to hand off to their code? |
| 02:54.00 | dreeves | Yeah I tried that one to and it looked good |
| 02:54.34 | brlcad | how are you using their code? |
| 02:54.52 | dreeves | More as a reference than anything |
| 02:55.16 | dreeves | I just replaced brep_intersect with their code |
| 02:55.50 | dreeves | I'm still using everything outside that |
| 02:56.05 | dreeves | So did you say it looked right? |
| 02:56.32 | brlcad | no, it's not right, but it looks good |
| 02:57.12 | dreeves | Yeah that is what I thought...So what's the main thing that is wrong? |
| 02:57.32 | brlcad | there's errors on the back side |
| 02:57.46 | brlcad | that could the the additional parity work that brep_shot() does after brep_intersect() |
| 02:58.24 | brlcad | if their tracer is robust, much of that may even simplify |
| 02:58.28 | dreeves | Are you talking about what looks like the little dots |
| 02:58.43 | brlcad | right |
| 02:58.46 | dreeves | ok |
| 02:58.54 | dreeves | Yeah I noticed that |
| 02:59.07 | brlcad | there are various edge cases that have to be accounted for |
| 02:59.46 | dreeves | Yeah let me go take a look at that |
| 02:59.46 | brlcad | where any two surfaces join, where trimmings join, grazing tangentially to a surface, going through a corner, going through multiple corner/edges, etc |
| 03:00.01 | brlcad | I'd start by simplifying brep_shot() |
| 03:00.19 | brlcad | you should also probably be working on a branch so your changes can be tracked/seen/shared |
| 03:00.21 | dreeves | Yeah that is what I'm going to take a look at |
| 03:01.46 | dreeves | sure |
| 03:03.45 | brlcad | you could start by checking the a_onehit flag in shot() -- if that is set, you only need to know the first/surface hit and can return quickly |
| 03:03.52 | brlcad | that will give better optical renderings |
| 03:04.02 | brlcad | then if a_onehit is not set, return all hit segments |
| 03:04.19 | brlcad | where you'll need to know when you go in/out through the solid |
| 03:04.51 | brlcad | that skewed cube is a good example because you can get two segments if you shoot through that tip and through the main body |
| 03:05.31 | yukonbob | reads scrollback |
| 03:07.44 | dreeves | ok I will play around with it |
| 03:12.44 | brlcad | dreeves: okay, you have commit access |
| 03:12.49 | brlcad | be sure to read HACKING in detail if you've not already (particularly with respect to commit acces and responsibility) |
| 03:13.16 | brlcad | suggest you commit as you work to a branch for now for that thread of work |
| 03:13.37 | brlcad | maybe /svnroot/brlcad/brlcad/branches/utah_brep or something |
| 03:14.33 | starseeker | gets REDUCE (sort of) working - yet again Emacs is the default interface :-/ |
| 03:18.10 | dreeves | ok brlcad I will commit soon |
| 03:18.56 | starseeker | When you stop and think, it really is incredible how much mathematical crunching power can be downloaded for free these days :-) |
| 03:25.49 | brlcad | starseeker: you've made the same mistakes I've been making |
| 03:25.54 | brlcad | have to repost your comments |
| 03:25.58 | brlcad | they're private by default |
| 03:30.36 | *** join/#brlcad dreeves (n=dreeves@67.130.253.14) |
| 03:36.03 | brlcad | dreeves: shared your image with the mailing list |
| 03:36.15 | dreeves | cool |
| 03:36.34 | dreeves | Maybe I should get on the mailing list |
| 03:41.08 | brlcad | dreeves: on second thought, forget using a branch -- just work on trunk for now |
| 03:41.26 | brlcad | we can work out what to do about a conflict when one arises |
| 03:41.51 | brlcad | in the meantime, maybe just have #ifdef sections for old/new |
| 03:42.23 | dreeves | Yeah I'm trying to be careful to minimize the existing code I touch for now....once things look right I will clean up |
| 03:42.24 | brlcad | brep is all WIP so it's not subject to controls beyond what we need to collaborate, so might as well use trunk |
| 03:42.54 | dreeves | Hey how do I get on the mailing list I know I have seen it somewhere but I can't find it now |
| 03:42.56 | brlcad | plus this is priority, and i'm frankly surprised that you got it working that easily |
| 03:43.17 | brlcad | i'm like 80% sure that acne you saw is probably a bug in the existing code |
| 03:44.00 | dreeves | Yeah I still have more to do in the trimming department there |
| 03:44.20 | dreeves | I think I know what is going on with the acne problem |
| 03:44.39 | dreeves | First things first is to clean up trimming |
| 03:52.07 | poolio | dreeves: purty image :D |
| 03:52.11 | brlcad | i'm actually not convinced that's trimming |
| 03:52.48 | brlcad | those are outer-trim surfaces where the trims match the edges (i.e. nothing to trim) |
| 03:53.07 | brlcad | that's why it's 80% that it's something on our existing side |
| 03:53.14 | brlcad | i.e. in the parity checking |
| 03:53.53 | brlcad | either point collapse/merging or it really is missing both surfaces numerically |
| 03:54.36 | brlcad | and please do commit asap, would like to test this out as well :) |
| 04:01.41 | dreeves | Ok I will |
| 04:01.53 | dreeves | So how do I get on the mailing list? |
| 04:03.17 | dreeves | nm I found it |
| 04:03.20 | louipc | I think you need to sign up on sourceforge |
| 04:55.24 | starseeker | brlcad: ah, thanks |
| 04:57.16 | starseeker | dreeves: nice work! |
| 04:59.24 | dreeves | thanks |
| 05:00.41 | dreeves | Still issues but I think we are getting closer |
| 05:08.20 | dreeves | brlcad those spots are being caused by the shader...seems like the surface normals are messed up |
| 05:30.29 | dreeves | Ok fixed the spots they were caused because I had my root finder tolerance set too low up'd it and spots went away |
| 05:34.38 | dreeves | brlcad sent you an updated image with spots gone...working on trimming some |
| 05:41.51 | *** join/#brlcad dreeves (n=dreeves@67.130.253.14) |
| 05:48.48 | *** join/#brlcad deeeffache (n=deeeffac@adsl-99-151-192-240.dsl.emhril.sbcglobal.net) |
| 05:55.35 | dreeves | brlcad btw in your message I think you said it lacked some optimizations I assume you are talking about ray/plane optimization, it does have that in it |
| 05:56.11 | dreeves | I will try to commit tomorrow night latest and then you can check it out for yourself |
| 05:56.31 | dreeves | maybe tonight if I get the trimming stuff straightened out |
| 06:00.15 | *** join/#brlcad andrecastelo_ (n=Andre_Ca@201008161042.user.veloxzone.com.br) |
| 06:35.33 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 06:53.59 | *** join/#brlcad madant (n=madant@117.196.134.66) |
| 07:17.10 | *** join/#brlcad _sushi_ (n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 07:26.46 | *** join/#brlcad andrecastelo (n=Andre_Ca@189.71.30.67) |
| 08:01.56 | *** join/#brlcad cad63 (n=ca727801@bz.bzflag.bz) |
| 08:55.53 | brlcad | dreeves: the optimizations I'm thinking of are actually the ones in the 2006 paper that made nurbs raytracing interesting in the first place :0 |
| 08:56.29 | brlcad | using vectorized evaluation and compact representation to get interactive results |
| 08:57.25 | brlcad | given you have something, I'd hope you'd already commit what you have |
| 08:57.42 | brlcad | doesn't need to be complete and tells a better story the more little steps you break it up, even if there are 500 intermediate steps before it "works" |
| 08:58.10 | brlcad | helps others to understand the code by watching the work in progress, mistakes and changes all |
| 09:27.32 | *** join/#brlcad mafm (n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 09:31.31 | *** join/#brlcad Lez (n=lezardfl@189.58.208.46.dynamic.adsl.gvt.net.br) |
| 10:56.15 | mafm | hi |
| 11:31.49 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 11:44.10 | brlcad | howdy mafm |
| 11:45.18 | mafm | :) |
| 11:45.55 | mafm | -> Today Debian gets one step closer to really becoming 'the universal operating system' by adding two architectures based on the FreeBSD kernel to the unstable archive. |
| 11:46.10 | mafm | One Swirl To Rule Them All. |
| 12:44.30 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 13:10.20 | CIA-40 | BRL-CAD: 03ddreeves70 * r34159 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: This is code that works well with the test cube |
| 13:11.19 | dreeves | brlcad I committed but the trimming isn't there and there currently is a hack in it that I think is need because the trimming isn't there I have the code for trimming I believe but haven't had a chance to work on it |
| 13:12.27 | dreeves | brlcad I have my editor settings hopefully set to comply with the rules outlined in the HACKING guide if you spot please let me know |
| 13:13.11 | brlcad | dreeves: cool |
| 13:13.13 | dreeves | also I haven't had a chance to read the rules on committing (well I scanned them). I just scanned through that because I didn't have commit access at the time |
| 13:13.30 | brlcad | rules for committing are pretty simple |
| 13:13.34 | brlcad | don't break stuff |
| 13:13.37 | brlcad | and when you do, fix it ;) |
| 13:13.49 | dreeves | I think I can handle that |
| 13:14.15 | brlcad | consistency updates are always good as are other cleanups through the code -- shouldn't be mixed in with logic changes if you can help it though |
| 13:15.10 | brlcad | you'll find all sorts of styles throughout, it's a bit of an on-going cleanup to make everything consistent but they should minimally be self-consistent within a given file |
| 13:15.27 | dreeves | I will try...but to be honest I usually scan the code right before I commit and I haven't had the chance to do that on this code because I wanted to go ahead and commit |
| 13:15.44 | brlcad | also we work on a monthly iteration cycle for releases, so commits should "slow down" near the end of the month and be more focused on just bug fixes and cleanup or holding until the release is tagged |
| 13:15.53 | dreeves | Yeah I have noticed that |
| 13:16.30 | dreeves | Do you want me to go ahead and commit the code for the extrude or well you still handle that via the patch? |
| 13:16.43 | brlcad | i'll can still handle that |
| 13:16.48 | dreeves | ok |
| 13:17.01 | brlcad | something I wanted to look into with that anyways, let you know if I change my mind :) |
| 13:17.01 | dreeves | Well I'm off to my day job :) |
| 13:17.06 | brlcad | cya! |
| 13:17.08 | brlcad | and thanks |
| 13:17.11 | brlcad | cool progress |
| 13:17.21 | brlcad | oh, last commit 'note' |
| 13:17.28 | brlcad | you can't really commit too frequently |
| 13:17.35 | dreeves | thanks needs work...I did |
| 13:17.37 | brlcad | but you can certainly commit too infrequently |
| 13:17.46 | dreeves | :) |
| 13:19.00 | dreeves | I have 2 issues in the code you that I think once addressed we will be able to handle the complex geometries...One is trims and the other is a big ole fat hack in the shot code |
| 13:19.25 | dreeves | later... |
| 13:28.31 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) |
| 13:33.52 | _sushi_ | Anyone knows how to force CUPS to print A4 instead of A4 cut off to Letter size? |
| 13:34.08 | _sushi_ | I switched from Letter to A4 in already about 3 different config files and restarted cups and still doesn't work |
| 13:34.24 | _sushi_ | cd /etc |
| 13:35.26 | _sushi_ | replaces all occurences of "Letter" on /dev/hda with "A4" |
| 13:36.54 | _sushi_ | Lol: DefaultPageSize, DefaultPageRegion, DefaultImageableArea, DefaultPaperDimension |
| 13:37.27 | _sushi_ | sets the dimension of all conceivable objects in the Universe to A4 |
| 13:58.53 | *** join/#brlcad _sushi_ (n=_sushi_@84-72-93-63.dclient.hispeed.ch) |
| 15:13.49 | *** join/#brlcad yukonbob (i=1000@s142-179-54-198.bc.hsia.telus.net) |
| 15:36.26 | *** join/#brlcad dreeves2 (n=c752f348@bz.bzflag.bz) |
| 15:37.59 | *** join/#brlcad BigAToo (n=BigAToo@64.74.225.82) |
| 15:42.55 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) |
| 15:43.01 | *** join/#brlcad Malyce (n=iamtanma@deimos.jacobs-university.de) |
| 15:44.07 | *** join/#brlcad AlexandreGuedes (n=chatzill@187-24-30-229.3g.claro.net.br) |
| 15:54.33 | *** join/#brlcad AlexandreGuedes_ (n=chatzill@189-92-146-80.3g.claro.net.br) |
| 15:59.10 | brlcad | comments for most of you on the socghop site |
| 15:59.14 | brlcad | (students) |
| 16:02.52 | pacman87 | goes to check |
| 16:03.19 | hippieindamakin8 | hasnt found any |
| 16:03.34 | brlcad | hippieindamakin8: you're one of the few remaining, patience :) |
| 16:03.47 | hippieindamakin8 | brlcad, sure :) |
| 16:03.52 | starseeker | brlcad: ah, thanks for restating my question |
| 16:03.55 | brlcad | yours was longer and I'm getting fatigue :) |
| 16:04.06 | brlcad | starseeker: just the one, dont' know if there were others |
| 16:04.24 | brlcad | doesn't like the html-enabled comment box .. pastes should be plain-text |
| 16:13.18 | pacman87 | same thing happened to me when i pasted my application |
| 16:20.48 | brlcad | hippieindamakin8: fwiw - a lot better than last year, but still a lot of issues to sort out too |
| 16:20.53 | brlcad | let me know if you have any questions |
| 16:22.06 | Malyce | hey brl |
| 16:22.09 | Malyce | read the comment |
| 16:22.12 | brlcad | howdy Malyce |
| 16:22.14 | Malyce | how do i get onto the wiki |
| 16:22.19 | Malyce | do you mean the brl wiki ? |
| 16:23.34 | hippieindamakin8 | runs to look at the comment |
| 16:23.47 | typ0 | brlcad: any comments on the IGES converter ? |
| 16:25.11 | ``Erik | <PROTECTED> |
| 16:30.23 | *** join/#brlcad BigAToo (n=BigAToo@64.74.225.82) |
| 16:40.38 | hippieindamakin8 | brlcad, do i discuss with you out here ? |
| 16:40.59 | hippieindamakin8 | or do i put up a reply out there on melange ? |
| 16:41.10 | brlcad | hippieindamakin8: yes |
| 16:42.16 | hippieindamakin8 | brlcad, the precision computation is worth it for getting the exact vertices and the edges.Though i did propose on simplifying the sturm sequence solving process by approximations |
| 16:42.33 | hippieindamakin8 | ESOLID does it without any approximations. |
| 16:43.44 | hippieindamakin8 | because we need to have the vertices and edges right for the intersections.but again like the paper on ESOLID says some are rendered without this precise computation with a good tolerance |
| 16:44.10 | brlcad | true, though they still take "forever" in comparison :) |
| 16:45.09 | hippieindamakin8 | brlcad, approximations like formulation of low degree equations for sturm sequences with precise computation is halfway between these two |
| 16:45.23 | hippieindamakin8 | two == ESOLID and BOOLE |
| 16:45.25 | brlcad | basicaly, right almost all the time -> very slow OR right only some of the time -> fast |
| 16:45.42 | hippieindamakin8 | brlcad, yeah :) |
| 16:46.26 | brlcad | but was boole's "failing" something that could have been solved with better book-keeping or failure detection/recovery on top |
| 16:47.31 | hippieindamakin8 | brlcad, how is that ? |
| 16:48.48 | hippieindamakin8 | dint get the word book-keeping in this context :| |
| 16:49.06 | brlcad | dreeves: question for when you see this -- curious, what sort of performance difference was there between what is previously/currently implemented and having utah do the eval? |
| 16:49.33 | brlcad | hippieindamakin8: keeping track of a graph/stack/tree/whatever of decisions that are made about the topology |
| 16:49.48 | hippieindamakin8 | brlcad, aah |
| 16:50.22 | brlcad | so you decide A==B and later run into degenerate geometry .. maybe if the tolerance was locally constrained and A!=B it would have worked |
| 16:51.05 | brlcad | keeping track of the topological decisions seems (to me) like a very strong way to have failure recovery while still searching a solution space very quickly with imprecise numerics |
| 16:51.23 | brlcad | you only work harder if you're degenerate or within ambiguous tolerances |
| 16:51.24 | hippieindamakin8 | brlcad, i completely agree with that point |
| 16:51.48 | brlcad | it's just a lot harder to code it that way :) |
| 16:52.05 | hippieindamakin8 | brlcad, its worth a try aint it ? :) |
| 16:52.25 | hippieindamakin8 | degenerate cases are the worst |
| 16:57.35 | hippieindamakin8 | brlcad, i ll update the application/append another comment on the appspot |
| 17:00.17 | dreeves2 | brlcad I didn't really keep up but seems like the utah was a little faster until I up'd the tolerance (but again this is just feel not by the numbers) |
| 17:01.44 | *** join/#brlcad dreeves2 (n=c752f348@bz.bzflag.bz) |
| 17:01.52 | *** join/#brlcad typ0 (n=coder@um-sd06-125-2.uni-mb.si) |
| 17:05.04 | dreeves2 | brlcad if you responded to my last comment I didn't see it because I'm having to use the web interface to irc...I need to get irc working from here but haven't taken the time to investigate |
| 17:05.53 | pacman87 | dreeves2: you didn't miss anything |
| 17:06.12 | dreeves2 | did you see my comment about speed? |
| 17:06.55 | pacman87 | dreeves2: brlcad I didn't really keep up but seems like the utah was a little faster until I up'd the tolerance (but again this is just feel not by the numbers) |
| 17:07.54 | brlcad | hippieindamakin8: okay |
| 17:08.02 | dreeves2 | thanks that is it |
| 17:10.46 | *** join/#brlcad ibot (i=ibot@rikers.org) |
| 17:10.46 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || Release 7.14.6 posted (20090403) || GSoC2009 Next Step: we're reviewing applications, preliminary slot count on 7th, selections announced on the 15th |
| 17:13.01 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-155.sbndin.btas.verizon.net) |
| 17:15.28 | brlcad | dreeves2: that's kinda scary actually, because the current implementation is basically dog-slow :) |
| 17:15.36 | brlcad | but certainly workable |
| 17:15.46 | brlcad | if it works, that will be the biggest factor |
| 17:16.52 | brlcad | wanders off for a bit |
| 17:24.58 | dreeves2 | brlcad yeah I'm sure there is a ton of work to optimize and make fast. Like I said I didn't really look at numbers or pay attension. My focus was completely on getting the intersections right. There are several things that I noticed that could speed it up but I want to get it fully functional first then worry about performance |
| 17:25.55 | starseeker | nods vigorously :-) |
| 17:34.49 | *** join/#brlcad madant (n=madant@117.196.129.23) |
| 17:39.19 | *** join/#brlcad _sushi_ (n=_sushi_@77-58-239-204.dclient.hispeed.ch) |
| 17:41.51 | *** join/#brlcad AlexandreGuedes_ (n=chatzill@189-92-175-113.3g.claro.net.br) |
| 18:01.01 | CIA-40 | BRL-CAD: 03starseeker * r34160 10/brlcad/trunk/ (4 files in 2 dirs): Convert bolt man page to docbook |
| 18:23.28 | CIA-40 | BRL-CAD: 03starseeker * r34161 10/brlcad/trunk/ (4 files in 2 dirs): Convert gastank man page to docbook |
| 18:36.45 | CIA-40 | BRL-CAD: 03starseeker * r34162 10/brlcad/trunk/ (4 files in 2 dirs): Convert handle man page to docbook |
| 19:02.10 | brlcad | starseeker: as entire dirs are done being converted, should remove the manpage copies in that dir so we have minimal duplicates to keep updated |
| 19:02.37 | starseeker | brlcad: right |
| 19:02.49 | starseeker | in this case, doing it as I go - that ok? |
| 19:03.13 | starseeker | if fewer commits is better, I can wait |
| 19:03.47 | brlcad | nothing to do with commit count, just more as a progress measure |
| 19:03.55 | starseeker | ah, k |
| 19:03.59 | ``Erik | looks at doc/docbook/system/man1/en/ and src/rt/ O.o |
| 19:04.10 | brlcad | didn't know you were removing as you went -- there are a few in there that haven't been removed iirc |
| 19:04.23 | starseeker | yeah, I need to do a bit of cleanup |
| 19:04.25 | brlcad | (e.g. rtarea came up when richard was working on it) |
| 19:04.31 | starseeker | nods |
| 19:04.41 | brlcad | just don't want to get into an indeterminate state with mixes |
| 19:04.49 | starseeker | I'll pick off the strays once I get through shapes |
| 19:05.11 | brlcad | either dir at a time, or keep 'em in sync so we know what is left to do at a dir/file level |
| 19:05.20 | ``Erik | imagines uninstall would fail right now due to that |
| 19:05.46 | starseeker | ``Erik: ok, ok I'll do it now ;-) |
| 19:05.55 | brlcad | ``Erik: uninstall doesn't fail on missing files (at least the automake uninstall doesn't) |
| 19:06.09 | ``Erik | ah, it uses rm -f? |
| 19:06.17 | brlcad | yeah |
| 19:06.29 | ``Erik | I know the bsd pkg_delete gets bitchy on missing iles |
| 19:06.35 | ``Erik | files, or fiels with changed md5sums |
| 19:07.08 | ``Erik | but that should go clean, since it generates a manifest after install is complete |
| 19:07.11 | ``Erik | *shrug* |
| 19:07.15 | ``Erik | stops blabbering and codes some |
| 19:08.22 | *** join/#brlcad Malyce2 (n=iamtanma@deimos.jacobs-university.de) |
| 19:09.15 | brlcad | ~seen jdoliner |
| 19:09.18 | ibot | jdoliner <n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net> was last seen on IRC in channel #brlcad, 3d 20h 42m 54s ago, saying: 'k nm found it'. |
| 19:21.37 | CIA-40 | BRL-CAD: 03starseeker * r34163 10/brlcad/trunk/src/ (24 files in 7 dirs): Remove old man pages that have been incorporated into the docbook system. |
| 19:21.47 | starseeker | there we go |
| 19:29.13 | CIA-40 | BRL-CAD: 03starseeker * r34164 10/brlcad/trunk/ (4 files in 2 dirs): Convert picket_fence man page to docbook |
| 19:39.35 | CIA-40 | BRL-CAD: 03starseeker * r34165 10/brlcad/trunk/doc/docbook/system/man1/en/bolt.xml: Whoops - fix bolt author. |
| 19:40.57 | mafm | ~starseeker++ |
| 19:41.37 | CIA-40 | BRL-CAD: 03starseeker * r34166 10/brlcad/trunk/ (4 files in 2 dirs): Convert window man page to docbook |
| 19:46.55 | *** join/#brlcad ibot (i=ibot@rikers.org) |
| 19:46.55 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || Release 7.14.6 posted (20090403) || GSoC2009 Next Step: we're reviewing applications, preliminary slot count on 7th, selections announced on the 15th |
| 19:53.53 | *** join/#brlcad ibot (i=ibot@rikers.org) |
| 19:53.53 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || Release 7.14.6 posted (20090403) || GSoC2009 Next Step: we're reviewing applications, preliminary slot count on 7th, selections announced on the 15th |
| 20:01.21 | CIA-40 | BRL-CAD: 03starseeker * r34167 10/brlcad/trunk/doc/docbook/system/man1/en/ (bolt.xml gastank.xml handle.xml window.xml): it's window_frame(1), not winfrm(1) |
| 20:07.27 | *** join/#brlcad Malyce (n=smartmin@deimos.jacobs-university.de) |
| 20:07.40 | Malyce | hi |
| 20:07.52 | Malyce | I tried compiling on ubuntu |
| 20:08.06 | madant | howdy Malyce |
| 20:08.08 | madant | and ? |
| 20:08.09 | Malyce | autogen.sh gives autreconf and libtoolize failure |
| 20:08.38 | Malyce | what should I do ? |
| 20:09.15 | madant | hmm.. weird.. pastebin error message ? |
| 20:10.00 | Malyce | this is what i get |
| 20:10.01 | Malyce | Reading package lists... Done |
| 20:10.01 | Malyce | Building dependency tree |
| 20:10.01 | Malyce | Reading state information... Done |
| 20:10.01 | Malyce | E: Couldn't find package autoreconf |
| 20:10.32 | Malyce | sorry |
| 20:10.37 | Malyce | i posted the wrong messages |
| 20:10.42 | Malyce | this is what i get .. |
| 20:10.45 | Malyce | Preparing the BRL-CAD build system...please wait |
| 20:10.45 | Malyce | Found GNU Autoconf version 2.63 |
| 20:10.45 | Malyce | Found GNU Automake version 1.10.2 |
| 20:10.45 | Malyce | Found GNU Libtool version 2.2.6 |
| 20:10.45 | Malyce | Automatically preparing build ... Warning: autoreconf failed |
| 20:10.45 | Malyce | Attempting to run the preparation steps individually |
| 20:10.47 | Malyce | Preparing build ... ERROR: libtoolize failed |
| 20:11.23 | starseeker | use http://pastebin.bzflag.bz/ |
| 20:12.09 | CIA-40 | BRL-CAD: 03starseeker * r34168 10/brlcad/trunk/ (4 files in 2 dirs): Convert window_frame man page to docbook |
| 20:13.09 | Malyce | http://pastebin.bzflag.bz/m393a0eda |
| 20:13.49 | ``Erik | which OS? |
| 20:13.54 | Malyce | Ubuntu |
| 20:13.56 | starseeker | ubuntu linux |
| 20:14.16 | starseeker | do you have all the autotools installed? |
| 20:14.21 | Malyce | yes |
| 20:14.29 | ``Erik | hm, I know the macs rename libtoolize 'glibtoolize', have you checked to make sure libtoolize installed with a 1.5 or later version, and tried running it manually? |
| 20:14.29 | starseeker | huh |
| 20:14.37 | Malyce | and automake, libtools, m4 etc |
| 20:14.39 | madant | Malyce, no idea why libtoolize is failing.. :) i have never faced it .. you should wait for our build ( and in general) guru brlcad :) |
| 20:15.00 | madant | ``Erik, libtool provides /usr/bin/libtoolize in debian, same for ubuntu i guess |
| 20:15.35 | madant | and this is the output of running ./autogen.sh ? |
| 20:15.38 | Malyce | yes |
| 20:16.47 | ``Erik | hmmmm, I'm still using 1.5.26, wonder if something changed in 2 |
| 20:18.32 | madant | Malyce, just make sure you have the latest revision and no changes from the trunk etc ? I myself have autoconf 2.63 automake 1.10.1 and libtool 2.2.6 and no probs :) |
| 20:19.21 | ``Erik | imagines running libtoolize -cf by hand will provide more informatin |
| 20:19.34 | ``Erik | s/n$/o&/ |
| 20:19.55 | Malyce | I co this morning |
| 20:19.58 | madant | what is the output if you run autoreconf manually ? |
| 20:20.30 | ``Erik | *sigh* autoreconf will need the m4 directory wired into it and will try to make libtoolize silent |
| 20:24.34 | CIA-40 | BRL-CAD: 03starseeker * r34169 10/brlcad/trunk/ (4 files in 2 dirs): Convert wire man page to docbook. |
| 20:25.59 | Malyce | how should i run the autoreconf manually ? |
| 20:26.05 | Ralith | returneth! |
| 20:27.25 | mafm | chanting hymns for returneth Ralith |
| 20:27.32 | madant | Malyce, is the ./autogen.sh --verbose output any different ? |
| 20:35.24 | Malyce | just ran the autogen --verbose |
| 20:35.27 | Malyce | but the output is the same |
| 20:35.34 | Malyce | just quote detailed |
| 20:35.40 | Malyce | i can post the output if it would help |
| 20:35.41 | Malyce | ? |
| 20:35.49 | louipc | yeah put it in a pastebin |
| 20:36.33 | Malyce | http://pastebin.bzflag.bz/m52ab321c |
| 20:37.44 | hippieindamakin8 | brlcad, ``Erik there was a bug on bug tracker on sf which was "latest svn failed on debian sid" |
| 20:38.25 | hippieindamakin8 | the build was successful with some minimal errors during the build (these errors are generally ignored) |
| 20:42.49 | madant | weird , why the tick and quote=> 'ibtoolize: Failed to create `m4 |
| 20:46.30 | louipc | I thought the same thing |
| 20:52.47 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1177593680.dsl.bell.ca) |
| 20:53.50 | ``Erik | now why would libtoolize want to create m4, and is it trying to make it as a dir or file? O.o |
| 21:14.41 | starseeker | prepares some more nurbs test cases to put in the repository |
| 21:15.34 | brlcad | suspects malyce *doesn't* have the autotools installed, at least not some of the tools |
| 21:17.31 | brlcad | ah, verbose log |
| 21:20.44 | brlcad | "'ibtoolize" certainly looks wrong |
| 21:25.33 | CIA-40 | BRL-CAD: 03brlcad * r34170 10/brlcad/trunk/TODO: implement prim->brep |
| 21:28.30 | CIA-40 | BRL-CAD: 03brlcad * r34171 10/brlcad/trunk/TODO: need a routine to convert from NMG to BREP, ideally for both NURBS and polygonal NMG objects. makes it easier to update functionality to the new data types. |
| 21:30.04 | CIA-40 | BRL-CAD: 03brlcad * r34172 10/brlcad/trunk/TODO: need _tess() for brep primitive |
| 21:34.53 | brlcad | gives mafm some high praises |
| 21:36.23 | starseeker | brlcad: any idea why asc2g would say m_object_table[0].m_object is NULL ? |
| 21:36.41 | poolio | brlcad: I started on nmg -> brep...I think it may work for polygonal NMG objects, bu I believe it had some bugs |
| 21:36.52 | brlcad | poolio: yeah, I saw that |
| 21:37.04 | brlcad | my eyebrow went all crooked |
| 21:37.19 | poolio | I also think there's a newer version around here (locally) that I forgot to commit |
| 21:37.35 | brlcad | ahh, should hunt that shtuff down! :) |
| 21:38.07 | poolio | Cause I remember proclaiming myself done with arb*, and then I moved onto the other shapes |
| 21:38.24 | starseeker | grr. Well, looks like the .g goes in the repository, with hunting down the asc2g bug being on the list |
| 21:38.52 | brlcad | you mean g2asc I hope ;) |
| 21:38.54 | mafm | brlcad: why? |
| 21:38.58 | brlcad | otherwise, "there's your problem" :) |
| 21:39.19 | starseeker | not sure |
| 21:39.35 | brlcad | starseeker: .g is certainly better than nothing, but maybe just shove it up on the website then |
| 21:39.40 | brlcad | or into the wiki |
| 21:39.52 | starseeker | k |
| 21:40.06 | brlcad | a wiki page showing the progress would be pretty useful |
| 21:40.16 | brlcad | before after sets like you started |
| 21:40.31 | starseeker | hmm. ok, that should be doable |
| 21:40.44 | starseeker | let me get this file up somewhere for dreeves when he gets back :-) |
| 21:42.13 | starseeker | here's the g2asc output for the file: http://pastebin.bzflag.bz/m360c1791 |
| 21:43.08 | starseeker | doesn't see how g2asc is preserving the brep/nurbs info in the asc file, to be honest |
| 21:43.52 | brlcad | starseeker: ah |
| 21:43.53 | brlcad | yeah |
| 21:44.02 | brlcad | tclget/put havent' been implemented apparently |
| 21:44.11 | starseeker | ooo, that'll do it |
| 21:44.28 | starseeker | ok, here's the .g: http://bzflag.bz/~starseeker/nurbs_tests.g |
| 21:44.31 | brlcad | I mean, just looking at that output, that is clear |
| 21:44.50 | starseeker | I thought so, but I wasn't sure if there was some magic going on ;-) |
| 21:45.07 | mafm | brlcad: * brlcad gives mafm some high praises -- why? |
| 21:45.41 | brlcad | mafm: oh just talking about you to other mentors |
| 21:45.58 | mafm | ah |
| 21:46.06 | mafm | what for? |
| 21:46.18 | brlcad | nosey, eh? :) |
| 21:46.27 | brlcad | just talking about you, not to you ;) |
| 21:46.40 | mafm | well, it's you who ignited the curiosity :) |
| 21:46.52 | brlcad | I know, it's more fun that way |
| 21:46.58 | mafm | btw, have you seen my reply in google thingy? I can't sign up as mentor |
| 21:47.09 | brlcad | I know why you can't sign up |
| 21:47.31 | brlcad | can't be a mentor and a student |
| 21:47.37 | mafm | yes |
| 21:47.41 | brlcad | and given you have multiple apps in, you're fixed as a student |
| 21:47.51 | mafm | however I'll try to advise anyway, if anybody would find my advise useful :P |
| 21:48.05 | brlcad | nods |
| 21:48.09 | brlcad | that would be appreciated and useful |
| 21:48.15 | brlcad | if someone continues that work |
| 21:49.02 | mafm | well, in fact I already advised a few ppl under the hood :P |
| 21:50.18 | mafm | brlcad: if my apps go bad, maybe I can sign up officially as mentor too? melange gods might provide... :) |
| 21:55.07 | madant | mafm, did u see Malyce's error, i faintly remember having a similar problem ( quote, tick and unnecessary characters :D ) in debian long back.. it disappeared of course .. it might be a debian bug |
| 21:56.07 | mafm | madant: can't remember, I did have problems last year but it was for another reason (autotools version or similar) |
| 22:01.01 | brlcad | mafm: nope, not really possible unless you know before the 15th that you're rejected from everywhere you applied and could get an admin to remove your student status |
| 22:01.18 | brlcad | students aren't announced until the 20th, so I suspect "no" :) |
| 22:03.04 | mafm | :/ |
| 22:03.19 | mafm | well, unofficial mentor will do |
| 22:04.24 | madant | mafm: t-shirt would be nice ;) |
| 22:04.43 | hippieindamakin8 | recounts that he sounded stupid talking abt the debian sid compile without checking the complete log/comment. |
| 22:04.56 | starseeker | dreeves: OK, if it's helpful I've got some test nurbs shapes up at http://bzflag.bz/~starseeker/nurbs_tests.g and a script to raytrace them all at http://bzflag.bz/~starseeker/nurbs_tests.sh - should be a bit more of a workout than brep_simple ;-) |
| 22:05.22 | brlcad | thinks starseeker should implement tclget/put support ;) |
| 22:05.38 | starseeker | me too :-) |
| 22:05.38 | brlcad | has to be done eventually anyways, now there's actually a compelling reason ;) |
| 22:05.52 | *** join/#brlcad Malyce (n=iamtanma@wlanaccess-ext.jacobs-university.de) |
| 22:06.32 | starseeker | should also go to the gym, and since that closes that'll have to be first... |
| 22:06.38 | mafm | madant: well, that's a shame, yes |
| 22:07.01 | Malyce | do you guys know brlcad's email ? |
| 22:07.13 | Malyce | I could just send my compile pastebin's to him |
| 22:07.22 | *** join/#brlcad AlexandreGuedes (n=chatzill@189-92-146-147.3g.claro.net.br) |
| 22:07.26 | starseeker | he can see them on pastebin.bzflag.bz |
| 22:07.47 | starseeker | or are they too big for it? |
| 22:07.49 | Malyce | shouldn't I send him the urls ? |
| 22:07.57 | ``Erik | say the URL in channel |
| 22:08.06 | ``Erik | it may be possible that someone else coudl help you, too... O.o |
| 22:08.10 | Malyce | http://pastebin.bzflag.bz/m52ab321c |
| 22:08.15 | Malyce | http://pastebin.bzflag.bz/m393a0eda |
| 22:08.25 | Malyce | I did that, like half an hour ago, remember ? |
| 22:09.06 | Malyce | Besides, I don't have access to that machine anymore right now |
| 22:09.17 | ``Erik | sh -xe libtoolize -a -c <-- would probably tell ya a lot more |
| 22:09.19 | ``Erik | :D |
| 22:09.21 | Malyce | If somebody can tell me what went wrong, I'll try it out |
| 22:09.41 | Malyce | ok |
| 22:09.54 | Malyce | This was me building on Ubuntu |
| 22:10.00 | Malyce | I also did it on Cygwin |
| 22:10.10 | Malyce | There, autogen.sh went without a hitch |
| 22:10.18 | Malyce | but,.. |
| 22:10.21 | louipc | hehehe try to get it working on ubuntu first |
| 22:10.29 | brlcad | Malyce: yet again, one of the downsides of not using 'screen' to stay on irc .. I commented on your pastebin while you were gone |
| 22:10.39 | Malyce | oh |
| 22:10.44 | Malyce | rats |
| 22:10.55 | Malyce | It was a different machine |
| 22:11.06 | ``Erik | if you auto* on cygwin, the resultant may possibly not be ok for a leenewx |
| 22:11.12 | brlcad | haven't seen that specific problem before, but you can try to run exactly what autogen.sh is running to see why (like try what ``Erik suggested) |
| 22:11.32 | Malyce | ok |
| 22:11.42 | ``Erik | also; you could try googling the issue, surely this isn't the only place it's existed :D I see an ubuntu link when I chuck it in google... |
| 22:11.47 | Malyce | and just that one command will do the same ? |
| 22:11.52 | brlcad | only thing I can think of is the "-I m4" is confusing that version of libtoolize |
| 22:12.07 | louipc | :D |
| 22:14.00 | Malyce | Can I ask about the Cygwin build ? I don't have immediate access to the Ubuntu machine, will get it soon |
| 22:15.33 | Malyce | http://pastebin.bzflag.bz/m6cb9d321 |
| 22:15.44 | brlcad | starseeker: if you serialize the BREP similar to what 'l' outputs but just using a shorthand single-letter notation, you can get tclget/adjust/form for free |
| 22:15.46 | Malyce | Although autogen.sh runs without a hitch, configure dies on me |
| 22:16.18 | brlcad | see rt_ell_parse[] in src/librt/primitives/ell/ell.c for an example |
| 22:16.24 | ``Erik | awesome |
| 22:16.40 | brlcad | you'd have to have vars for the entity count, then other vars for values for each entity type |
| 22:16.58 | brlcad | pretty huge table, but should be less than 52 entities I'd think |
| 22:17.13 | brlcad | (not that they need to be short, but is consistent) :) |
| 22:17.29 | starseeker | ok :-) |
| 22:18.02 | brlcad | otherwise you'll have to find a compressed shorthand to store, maybe openNURBS has a text serialization routine |
| 22:18.17 | brlcad | probably easier to define the table |
| 22:21.51 | Malyce | hints ? |
| 22:23.12 | brlcad | ehm, what erik said to try |
| 22:23.17 | brlcad | basically run the steps manually |
| 22:23.38 | brlcad | see what's breaking, see if the options make sense with that version of the tool's documentation |
| 22:23.46 | Malyce | I will try that out in a couple hrs, when I get to steal the machine back |
| 22:24.01 | Malyce | but I was also asking for the Cygwin build |
| 22:24.10 | Malyce | that's the last pastebin i posted |
| 22:24.20 | Malyce | autogen.sh ran fine there |
| 22:24.33 | Malyce | ./configure --without-x11 broke down |
| 22:25.03 | ``Erik | um, cygwin is gonna try to look like unix, which'll make configure need x11 |
| 22:25.14 | brlcad | try running ./autogen.sh --verbose, see if there are any warnings |
| 22:25.18 | ``Erik | cygwin should have all the right x11 crap with it |
| 22:25.55 | brlcad | otherwise, read the configure script and see what looks wrong -- it's a shell script, those are errors near the very beginning of the file |
| 22:26.01 | ``Erik | feel free to make configure.ac grok cygwin and try to do the right thing, but I suspect that'd require fixing tcl/tk |
| 22:26.02 | ``Erik | :D |
| 22:26.15 | ``Erik | (and yes, those broken lines are setting the version info) |
| 22:27.23 | Malyce | well, 15th time's the charm (crosses fingers and toes) |
| 22:27.43 | louipc | haha |
| 22:30.56 | CIA-40 | BRL-CAD: 03erikgreenwald * r34173 10/brlcad/trunk/src/conv/intaval-g.py: don't assume that pythong is /usr/bin/python, use /usr/bin/env to find it |
| 22:32.46 | CIA-40 | BRL-CAD: 03erikgreenwald * r34174 10/brlcad/trunk/ (INSTALL m4/Makefile.am m4/python.m4 m4/sdl.m4): Remove python.m4 and sdl.m4 |
| 22:37.36 | CIA-40 | BRL-CAD: 03erikgreenwald * r34175 10/brlcad/trunk/src/adrt/libtienet/ (Makefile.am g-adrt.c): start putting in g-adrt |
| 22:38.54 | ``Erik | hopes he busted it all up good 'nuff to piss some people off :D |
| 23:01.11 | Malyce | in Arb8.cpp, the number of vertices is a size_t type. Would it be ok, for me to simply typecast it to int ? |
| 23:01.19 | Malyce | in CoreInterfaces |
| 23:06.10 | mafm | what for? |
| 23:06.20 | Malyce | I want to pass it to other functions |
| 23:06.37 | Malyce | I guess it should be ok. number of vertices has to be an integer |
| 23:06.55 | mafm | do you know what a size_t is? :) |
| 23:07.05 | Malyce | its what you get from sizeof |
| 23:07.11 | Malyce | size in bytes |
| 23:07.21 | Malyce | oh shoot |
| 23:07.35 | Malyce | sorry, (conks himself on the head) |
| 23:08.34 | mafm | actually, using int is better than an unsigned int sometimes |
| 23:08.47 | mafm | but size_t is the type used for indexes and the like |
| 23:08.50 | Malyce | here, it has to be an integer |
| 23:09.06 | Malyce | I haven't seen it being used outside of sizeof |
| 23:09.13 | mafm | unsigned int, 32 bits in 32 bit architectures, 64 in 64 bits |
| 23:09.15 | Malyce | why ? |
| 23:09.23 | ``Erik | not always |
| 23:09.45 | mafm | well, because it's the number of elements that you can address |
| 23:09.47 | ``Erik | some 64b archs make a uint32_t when you say unsigned int |
| 23:10.11 | Malyce | is it ok for me to typecast it ? |
| 23:10.31 | Malyce | numerically, it will be the same. integer to integer |
| 23:10.44 | Malyce | value won't change |
| 23:10.56 | mafm | ``Erik: I mean size_t, that it's defined as an unsigned int(eger) of 32 or 64, not literal "typedef unsigned int size_t" :) |
| 23:11.45 | mafm | Malyce: you might even change the original, but probably who did that created it size_t for a reason |
| 23:11.52 | ``Erik | isn't sure where/what malyce means, sees no function name or line number or anything |
| 23:12.39 | mafm | I doubt you'll have more than INT_MAX number of vertices in a given thingy, so it should be safe, but don't take my word as law :) |
| 23:13.22 | ``Erik | if it's used as an offset or pointer, might run into issues past the 4gb mark, though... |
| 23:13.22 | Malyce | size_t NumberOfVertices(void) const throw(); |
| 23:13.34 | Malyce | I don't think so |
| 23:14.09 | ``Erik | ahhhhhh, in rt^3, ok |
| 23:14.10 | Malyce | the corresponding Arb8.c comments say (rt_arb_std_type), that return should be 0-8 |
| 23:14.29 | Malyce | so, the return value will be 0-8, irrespective of size_t or int |
| 23:14.36 | Malyce | just being cautious |
| 23:16.31 | mafm | Malyce: the point is that maybe it makes more sense that you use size_t in your code, or maybe it doesn't matter if you use different types, it's hard to say for me :) |
| 23:16.48 | ``Erik | hrm, the function used to fill ret is returning a regular old int :/ |
| 23:17.50 | mafm | I prefer to use the same types everywhere instead of casting, but I don't know if this is carefully maintained in coreInterface or not (according to what ``Erik says, it seems not :) ) |
| 23:18.05 | Malyce | I don't know why it wasn't typecasted in the function itself, that's my point |
| 23:18.34 | Malyce | But, I do *need* to typecast it to use it elsewhere, no choice there |
| 23:18.46 | Malyce | wanted to know the side effects |
| 23:18.52 | ``Erik | doesn't know, would ask DRoßerg |
| 23:18.53 | mafm | why? the compiler should issue a warning, not an error |
| 23:19.17 | Malyce | k, will ask DRossberg |
| 23:19.19 | ``Erik | ~seen drossberg |
| 23:19.24 | ibot | i haven't seen 'drossberg', ``Erik |
| 23:19.37 | mafm | anyway, casting from size_t to int won't cause problems unless you pass the 2GB barrier :) |
| 23:19.49 | mafm | ~seen d_rossberg |
| 23:19.50 | ibot | d_rossberg <n=rossberg@bz.bzflag.bz> was last seen on IRC in channel #brlcad, 4d 14h 43m 58s ago, saying: 'i.e. the student should not be able to see it'. |
| 23:20.07 | Malyce | so it won't be an issue, since the return is known to be between 0-8 |
| 23:20.18 | mafm | that would be correct |
| 23:20.23 | Malyce | cool |
| 23:20.36 | ``Erik | or negative on error |
| 23:20.37 | ``Erik | ? |
| 23:20.43 | Malyce | hihi |
| 23:21.18 | mafm | in C++ you can use: int blah = static_cast<int>(teh_var); |
| 23:21.50 | mafm | ``Erik: if the signature of the function is size_t, returning a negative number is kind of a ... bad design, I guess |
| 23:21.57 | ``Erik | yeh |
| 23:22.07 | mafm | is kind -> would be :) |
| 23:22.08 | ``Erik | well, it's signed int in librt |
| 23:22.44 | madant | Malyce, things are much better understood with a short code excerpt @ pastebin showing what u want to do :) |
| 23:22.50 | mafm | so maybe it's the signature of the function in CoreInterface which slightly wrong |
| 23:23.12 | mafm | +1 madant |
| 23:23.30 | ``Erik | *shrug* shoot daniel an email or try to catch him on irc, he may've had a reason for doing it that way, I d'no :) |
| 23:24.54 | mafm | or shoot him directly, then ask :) |
| 23:25.12 | Malyce | Panda: an animal that eats, shoots and leaves |
| 23:25.16 | madant | thinks using size_t for denoting the "size" of things - arity of a function, number of points in a primitive etc. etc. - is just pedantic :D |
| 23:26.17 | ``Erik | I'd argue more misleading than pedantic... size_t insinuates some relation to pointers 'n stuff, no? |
| 23:26.27 | mafm | would say yes |
| 23:27.05 | Malyce | http://pastebin.bzflag.bz/d5d2fe1cd |
| 23:27.21 | Malyce | just a small something i was experimenting |
| 23:27.52 | *** join/#brlcad AlexandreGuedes_ (n=chatzill@189-92-169-90.3g.claro.net.br) |
| 23:28.15 | Malyce | I should have commented it |
| 23:29.43 | Malyce | http://pastebin.bzflag.bz/d3ca55d6d |
| 23:29.48 | Malyce | commented version |
| 23:30.22 | ``Erik | hrmmmm |
| 23:31.44 | mafm | Malyce: ret might be uninitialized |
| 23:31.51 | mafm | and returned as such |
| 23:32.25 | Malyce | I thought that |
| 23:32.28 | ``Erik | that centroid func doesn't quite smell right to me |
| 23:32.34 | Malyce | I should make it =0; |
| 23:32.49 | ``Erik | hrm, guess it is heh |
| 23:32.58 | ``Erik | must be tired |
| 23:33.10 | Malyce | I thought so too. It has to be *heh* |
| 23:33.14 | Malyce | I knew it |
| 23:33.44 | mafm | Malyce: also, in C++ you can declare "npoints" in the same place: int npoints = (int) NumberOfVertices(); |
| 23:34.41 | mafm | if you're not going to use it outside that scope, that is :) |
| 23:35.01 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 23:35.10 | mafm | well, I go to bed now, take care gentlemen (and ladies? :) ) |
| 23:35.15 | mafm | night |
| 23:35.18 | Malyce | good nigt |
| 23:35.25 | Malyce | sweet dreams |
| 23:35.25 | ``Erik | later, mafm |
| 23:36.27 | Malyce | oh, I remembered |
| 23:36.38 | Malyce | the reason I did not initialise ret = 0; |
| 23:36.57 | Malyce | its a point_t type. I don't know what that looks like |
| 23:37.15 | Malyce | *investigates* |
| 23:38.39 | ``Erik | typedef fastf_t point_t[4]; |
| 23:38.40 | ``Erik | or so |
| 23:39.09 | ``Erik | fully resolved out to typedef double point_t[4]; |
| 23:39.31 | Malyce | I can understand the first 3, but what do you do with double no. 4 ? |
| 23:39.45 | ``Erik | xyzw |
| 23:39.46 | Malyce | x,y,z,? |
| 23:39.50 | Malyce | ahahaha |
| 23:39.57 | Malyce | seriously, what is w ? |
| 23:40.08 | ``Erik | homogenous coordinates |
| 23:40.31 | Malyce | so it is the index of the local coords being used ? |
| 23:40.38 | Malyce | coord sys that is |
| 23:42.58 | Malyce | where is this defined ? |
| 23:44.47 | madant | ``Erik, mafm :) yeah maybe misleadingly pedantic :P |
| 23:44.51 | Malyce | uh, I think it is only three points |
| 23:44.57 | Malyce | #define ELEMENTS_PER_POINT3 |
| 23:45.28 | Malyce | typedef fastf_tpoint_t[ELEMENTS_PER_POINT]; |
| 23:46.10 | madant | off to a 5km run |
| 23:46.40 | ``Erik | okie, sorry, was thinking hvect_t |
| 23:46.44 | ``Erik | too used to opengl O:-) |
| 23:48.55 | Malyce | so, I initialize it to {0,0,0}, origin, is okie ? |
| 23:50.15 | ``Erik | should be |
| 23:50.37 | ``Erik | VSET(ret,0,0,0); :D |
| 23:50.46 | ``Erik | VSETALL(ret,0); |
| 23:51.00 | Malyce | useful. will keep that in mind |
| 23:51.19 | ``Erik | (just in case we go turn all that stuff into simd stuff some day) |
| 23:51.37 | Malyce | how so ? |
| 23:53.16 | Malyce | how is that useful, in parralel processing ? |
| 23:55.27 | Ralith | scatter instruction support? |
| 23:55.29 | Malyce | ugh, parallel |
| 23:55.56 | Malyce | so, all the user defined ops are already there ? |
| 23:55.58 | Malyce | ahhh |
| 23:56.10 | Ralith | what? |
| 23:56.32 | Malyce | when you use scatter/gather instructions, you can give it user defined operations to perform |
| 23:56.51 | Malyce | collective operations |
| 23:57.06 | Malyce | i take it that is what you meant |