| 01:00.02 | *** join/#brlcad openartist (n=openarti@cpe-69-204-131-93.nycap.res.rr.com) | |
| 01:21.53 | *** join/#brlcad illethal (n=oden@c-69-137-199-63.hsd1.fl.comcast.net) | |
| 01:21.55 | illethal | Hello. |
| 01:51.21 | *** join/#brlcad openartist (n=openarti@cpe-69-204-131-93.nycap.res.rr.com) | |
| 02:05.28 | louipc | hi |
| 02:05.47 | illethal | figured out the problem, all is well now |
| 02:06.53 | louipc | cool |
| 02:20.36 | *** join/#brlcad simoirc_ (n=moni@s235211.ppp.asahi-net.or.jp) | |
| 02:20.50 | *** part/#brlcad simoirc_ (n=moni@s235211.ppp.asahi-net.or.jp) | |
| 03:36.10 | *** join/#brlcad jgay (n=jgay@fsf/staff/jgay) | |
| 03:43.58 | illethal | Hello |
| 04:10.11 | poolio | alloo |
| 06:49.57 | *** join/#brlcad Z80-Boy (i=clock@77-56-93-102.dclient.hispeed.ch) | |
| 07:06.11 | *** join/#brlcad elite01 (n=elite01@195.37.106.60) | |
| 08:08.08 | *** join/#brlcad Z80-Boy (n=clock@zux221-122-143.adsl.green.ch) | |
| 09:16.56 | *** join/#brlcad archivist (n=archivis@host81-149-119-172.in-addr.btopenworld.com) | |
| 09:32.54 | *** join/#brlcad elite01 (n=elite01@195.37.106.60) | |
| 10:17.10 | *** join/#brlcad elite01 (n=elite01@195.37.106.60) | |
| 13:10.23 | *** join/#brlcad ibot (i=ibot@rikers.org) | |
| 13:10.23 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || Channel logs at http://ibot.rikers.org/%23brlcad/ || BRL-CAD is on scan.coverity.com but still offline || Release 7.12.0 coming soon to a desktop near you | |
| 13:11.45 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-080-094.pools.arcor-ip.net) | |
| 13:24.10 | *** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net) [NETSPLIT VICTIM] | |
| 13:26.12 | *** join/#brlcad Z80-Boy (n=clock@zux221-122-143.adsl.green.ch) [NETSPLIT VICTIM] | |
| 13:26.12 | *** join/#brlcad poolio (n=poolio@bz.bzflag.bz) [NETSPLIT VICTIM] | |
| 13:26.12 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) [NETSPLIT VICTIM] | |
| 13:26.12 | *** join/#brlcad Twingy (n=justin@74.92.144.217) [NETSPLIT VICTIM] | |
| 13:26.12 | *** join/#brlcad yukonbob (n=yukonbob@S010600195bd5c415.lb.shawcable.net) [NETSPLIT VICTIM] | |
| 13:26.12 | *** join/#brlcad CIA-31 (n=CIA@208.69.182.149) [NETSPLIT VICTIM] | |
| 13:26.12 | *** join/#brlcad tarzeau (i=gurkan@bee.ethz.ch) [NETSPLIT VICTIM] | |
| 13:27.07 | *** join/#brlcad brlcad (n=sean@pdpc/supporter/silver/brlcad) [NETSPLIT VICTIM] | |
| 13:27.07 | *** join/#brlcad louipc (n=louipc@bas8-toronto63-1128543687.dsl.bell.ca) [NETSPLIT VICTIM] | |
| 13:27.07 | *** join/#brlcad alex_joni (n=juve@emc/board-of-directors/alexjoni) [NETSPLIT VICTIM] | |
| 13:27.07 | *** mode/#brlcad [+o brlcad] by irc.freenode.net | |
| 13:27.56 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-080-094.pools.arcor-ip.net) [NETSPLIT VICTIM] | |
| 13:27.56 | *** join/#brlcad vedge (i=vedge@vedge.org) [NETSPLIT VICTIM] | |
| 13:27.57 | *** join/#brlcad b0ef (n=b0ef@062016141081.customer.alfanett.no) [NETSPLIT VICTIM] | |
| 13:27.57 | *** join/#brlcad Maloeran (n=maloeran@glvortex.net) [NETSPLIT VICTIM] | |
| 13:52.56 | *** join/#brlcad cad50 (n=d5e2fa0f@bz.bzflag.bz) | |
| 15:18.25 | *** join/#brlcad bpoole (n=poolio@c-71-206-247-140.hsd1.pa.comcast.net) | |
| 15:40.06 | *** join/#brlcad minute-web (i=5207211c@gateway/web/ajax/mibbit.com/x-e54d772f368fd6ef) | |
| 15:47.25 | *** join/#brlcad Elperion (n=Bary@p548746A4.dip.t-dialin.net) | |
| 15:52.42 | MinuteElectron | The cache table in drupal has become corrupted, most likley due to a full disk, reapiring table. |
| 15:53.53 | brlcad | MinuteElectron: thanks ... I've got problems on several sites because of that.. *sigh* |
| 15:54.11 | brlcad | that was a pretty bad/long time for it to fill up |
| 15:54.26 | MinuteElectron | yeah, too bad |
| 15:55.38 | MinuteElectron | Table, repaied - should there be any further errors tell me and I'll look into them. |
| 15:57.08 | brlcad | thanks MinuteElectron |
| 15:57.15 | brlcad | ~MinuteElectron++ |
| 15:57.19 | MinuteElectron | :P |
| 15:57.38 | brlcad | really, thanks |
| 15:57.43 | brlcad | my blood pressure is still high |
| 15:57.43 | alex_joni | does he overflow if we do that too often? |
| 15:57.45 | MinuteElectron | no problem |
| 15:57.47 | alex_joni | MinuteElectron++ |
| 15:57.56 | brlcad | have to prefix it with a ~ |
| 15:58.00 | alex_joni | ~MinuteElectron++ |
| 15:58.02 | brlcad | so it gets ibot's attention |
| 15:58.09 | brlcad | ~karma MinuteElectron |
| 15:58.09 | ibot | minuteelectron has karma of 5 |
| 15:58.21 | alex_joni | ~karma brlcad |
| 15:58.21 | ibot | brlcad has karma of 1 |
| 15:58.25 | alex_joni | oh-oh :) |
| 15:58.25 | MinuteElectron | wow, thanks guys :P |
| 15:58.40 | MinuteElectron | I'm going to restart my computer because I just installed some tools for IE6 development so I can hopefully fix the corner problem. |
| 15:58.40 | brlcad | yeah, it's not really useful for me, but can be fun :) |
| 15:58.56 | alex_joni | brlcad: do you remember off-hand what bot it is? |
| 15:58.57 | brlcad | alex_joni: my karma is hard-coded/fixed :) |
| 15:59.02 | brlcad | ~ibot |
| 15:59.02 | ibot | it has been said that ibot is a blootbot written in perl run by TimRiker on his server. logs on http://ibot.rikers.org/<chan>/ , ibot, jbot, apt are all the same process. It uses sqlite, but mysql or other SQL storage is also supported. |
| 15:59.21 | alex_joni | ~brlcad++ |
| 15:59.24 | alex_joni | ~karma brlcad |
| 15:59.24 | ibot | brlcad has karma of 1 |
| 15:59.27 | alex_joni | darn |
| 16:00.26 | brlcad | :) |
| 16:00.48 | brlcad | tim hard-coded it to 1 just for fun/spite |
| 16:05.57 | alex_joni | so what does it usually do? except karma :) |
| 16:07.27 | brlcad | you mean in general? |
| 16:08.02 | alex_joni | yeah |
| 16:08.02 | MinuteElectron | brlcad: "The MySQL error was: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)." |
| 16:08.03 | brlcad | ibot serves a lot of useful purposes, the biggest of which is probably it's extensive factoid database (utterly massive compared to most) |
| 16:08.04 | ibot | brlcad: what are you talking about? |
| 16:08.10 | brlcad | MinuteElectron: yeah, I'm working on it |
| 16:08.16 | MinuteElectron | ok, thanks |
| 16:09.11 | brlcad | back up |
| 16:09.19 | MinuteElectron | thanks |
| 16:09.20 | brlcad | i'd stop'd it |
| 16:09.37 | brlcad | i've got several corrupted sites to deal with atm |
| 16:10.20 | MinuteElectron | ahh, ok |
| 16:22.15 | brlcad | heh |
| 16:22.19 | brlcad | apache just reset |
| 16:22.38 | brlcad | the sites that still can't get to mysql lock up apache, and after about 20 or so lockups, apache restarts |
| 16:23.18 | MinuteElectron | ahh, that is unfourtunate - I'll do some other work while the instabilities are fixed and go back to this in a few minutes. |
| 16:23.27 | brlcad | so you'll probably get a "connection lost" or other random error once every few minutes .. but should work if you just retry |
| 16:23.34 | brlcad | i'll let you know when it should be good |
| 16:23.49 | MinuteElectron | ok, thank you |
| 16:58.11 | yukonbob | ~karma yukonbob |
| 16:58.11 | ibot | yukonbob has karma of 1 |
| 17:00.07 | brlcad | MinuteElectron: all better now |
| 17:00.16 | brlcad | ~yukonbob++ |
| 17:00.18 | brlcad | howdy |
| 17:01.10 | yukonbob | goodmorning brlcad :) |
| 17:02.40 | brlcad | not a good one, but morning to you too! :) |
| 17:03.01 | yukonbob | :P -- it's alright for me so far... |
| 17:03.07 | brlcad | yeah, hopefully to do great things :) |
| 17:03.23 | yukonbob | mathy stuff? |
| 17:03.25 | brlcad | it was alright for me too.. until I checked my e-mail and logs |
| 17:03.40 | yukonbob | shit->fan? |
| 17:03.42 | sunbleach | brlcad: what about me? |
| 17:03.48 | brlcad | the server's disks filled up last night .. so all went to hell while I was sleeping |
| 17:03.53 | yukonbob | :P |
| 17:04.29 | brlcad | mostly due to brl-cad's massive cvs2svn dumpfile and cvsroot backups that were still in place |
| 17:04.51 | brlcad | but took down mysql and httpd services for most sites on the box |
| 17:05.08 | brlcad | corrupted several mysql db's that had to be repaired |
| 17:05.10 | MinuteElectron | brlcad: cool |
| 17:05.24 | yukonbob | ah -- do those dumpfile/backups need to stay online for review or reference? |
| 17:05.38 | brlcad | i'd left them "just in case" I needed to run it one more time |
| 17:05.55 | yukonbob | ~mysql-- |
| 17:05.56 | brlcad | and yeah, I was still using them too |
| 17:06.13 | yukonbob | ~karma mysql |
| 17:06.13 | ibot | mysql has karma of -1 |
| 17:06.14 | brlcad | working with the cvs2svn devs to look into some of the things that went wrong |
| 17:06.36 | yukonbob | nice |
| 17:06.41 | brlcad | already figured one of our problems out.. they changed the behavior of the auto-props file |
| 17:06.51 | brlcad | that's what caused the bad juju on the svn:executable |
| 17:07.03 | yukonbob | re: binary encoding and +x |
| 17:07.04 | yukonbob | ? |
| 17:07.13 | brlcad | not binary encoding, but the +x |
| 17:07.17 | brlcad | yes |
| 17:07.39 | yukonbob | Opensource works, David. Opensource works, David. |
| 17:07.40 | brlcad | binary coding was the mime-type, already fixed that (that was my/apache's fault) |
| 17:08.05 | brlcad | but the exec bit was my/cvs2svn's fault |
| 17:09.16 | brlcad | they changed the behavior of the auto-props file -- if svn sees svn:executable in your auto-props.. it means make sure that file type is +x .. but cvs2svn folks changed it to mean exactly the opposite because they needed a way to forcibly unset +x |
| 17:09.46 | brlcad | I suggested seeing !svn:executable would probably be better than changing from svn's behavior |
| 17:10.18 | sunbleach | brlcad: any work for me there? |
| 17:10.51 | yukonbob | seems to have been _lots_ of cruft-cleaning and repairs done in development over last while -- is there a sched for next release? |
| 17:11.30 | sunbleach | brlcad: I wonder if you got my ":( |
| 17:11.34 | sunbleach | " smiley on the query |
| 17:11.41 | sunbleach | Because onb freenode the queries sometimes don't work |
| 17:12.40 | yukonbob | sunbleach: re: your animation -- do you have pubished notes or a blog, etc. re: the process you took to make it? |
| 17:13.03 | sunbleach | yukonbob: no but it's compiled through a makefile |
| 17:13.10 | sunbleach | so if you read the makefiles you see how it's made |
| 17:13.11 | yukonbob | smart |
| 17:13.28 | sunbleach | I think full-feature movies should also be done with a makefile |
| 17:13.47 | sunbleach | So if at the end they wouldn't like the main character they would just replace the actor and type "make" |
| 17:13.51 | sunbleach | And go for a coffee. |
| 17:13.56 | brlcad | sunbleach: I got your :( and hopefully you got my response |
| 17:14.15 | yukonbob | *it's just so much nicer typing "make" than remembering _any_ number of incatations... |
| 17:14.32 | brlcad | you should/could write up the animation how-to on the wiki |
| 17:14.44 | yukonbob | ^--- ++ |
| 17:14.55 | sunbleach | But it's a dumb animation |
| 17:15.05 | sunbleach | a shell script countsm from 0 to 359 and calls rt with different azimuth |
| 17:17.44 | MinuteElectron | The corners problems with the sidebar have been fixed on the Drupal, but not MediaWiki (yet, just need to port some of the code over). |
| 17:18.16 | brlcad | sunbleach: doesn't matter what the animation is, it's having *simple* instructions and steps for creating an animation |
| 17:18.31 | sunbleach | Oh |
| 17:18.53 | brlcad | like how I wrote up instructions for making the sgi cube |
| 17:18.54 | brlcad | http://my.brlcad.org/wiki/SGI_Cube |
| 17:18.59 | sunbleach | How to create a simple animation from BRL-CAD with a complicated custom-written shell script ;-) |
| 17:19.13 | brlcad | it's not that it was hard at all for me, took just a few min .. but there are details in there that hardly anyone knows about |
| 17:19.22 | brlcad | and it's a nice simple tutorial on scripting with brl-cad |
| 17:19.39 | yukonbob | sunbleach: ;) -- we'll wikify it into simplicity |
| 17:19.46 | brlcad | simplify it, reduce the steps to the essential |
| 17:20.50 | sunbleach | looks complicated to me ;-) |
| 17:20.55 | *** join/#brlcad vedge (n=vedge@vedge.org) | |
| 17:21.05 | sunbleach | magical mged scripting commands |
| 17:21.11 | sunbleach | but at least I could look them up in the man |
| 17:22.23 | brlcad | most everything I used is considered really *old school* brl-cad |
| 17:22.44 | sunbleach | It's the only really useful stuff |
| 17:22.46 | brlcad | they're basics that most all modelers know with maybe the exception of the cook-torrence shader I used |
| 17:23.32 | brlcad | otherwise 2/3rds of it is the procedural scripting that generates the cube |
| 17:23.49 | sunbleach | Here is the script for the animations with matte channel http://ronja.twibright.com/utils/rt_script |
| 17:24.34 | brlcad | that is nice and short |
| 17:24.43 | sunbleach | Actually not |
| 17:24.50 | sunbleach | It mattes the colours and edges together |
| 17:24.55 | sunbleach | The result is matted once more |
| 17:25.55 | sunbleach | But the C program is nonportable |
| 17:26.08 | sunbleach | assumes that the double zero is all zeroes on the architecture |
| 17:26.14 | sunbleach | Which I don't know if it's guaranteed |
| 17:26.22 | sunbleach | Can be some weird architecture where double zero is not all zeroes |
| 17:26.34 | sunbleach | Or what if the thing produces negative zero? No guarantee either |
| 17:26.44 | brlcad | "double zero"? |
| 17:26.50 | sunbleach | brlcad: is there a guarantee that rt never produces negative zeroes if the pixel hits infinity |
| 17:26.55 | sunbleach | zero in the double precision |
| 17:27.39 | sunbleach | Here is the program that makes the background http://ronja.twibright.com/utils/double_mask.c |
| 17:27.50 | brlcad | where do you write out doubles? |
| 17:28.12 | sunbleach | I read them in |
| 17:28.24 | sunbleach | In the "network" format that the rt produces |
| 17:28.34 | sunbleach | Which is the root cause of the pain in the ass |
| 17:28.52 | brlcad | i'm not seeing where you tell that to rt though? |
| 17:28.55 | sunbleach | What happens in double if I compare negative zero with positive zero? |
| 17:28.59 | sunbleach | Do I get equality or not? |
| 17:29.25 | brlcad | your rtopts are bgcolor size and ambient light |
| 17:30.55 | sunbleach | Oh that script was for stills |
| 17:31.00 | sunbleach | This one is for animation: http://ronja.twibright.com/utils/render_animation |
| 17:31.29 | *** join/#brlcad jgay (n=jgay@fsf/staff/jgay) | |
| 17:31.30 | sunbleach | fixed_root=`echo "$1" | sed -e 's/\\//\\\\\\//g;s/\\./\\\\./g'` && |
| 17:31.52 | brlcad | as for +0 == -0 I believe most implementations will consider them equal though I don't think C/C++ have anything to say about it |
| 17:31.56 | brlcad | implementation defined |
| 17:32.10 | *** join/#brlcad vedge (n=vedge@vedge.org) | |
| 17:32.37 | sunbleach | What I would prefer would be one byte telling if the pixel is model or infinity. |
| 17:33.01 | sunbleach | Floating point numbers turn a digital computer into an analogue one |
| 17:33.24 | sunbleach | Like the code printf("%ld",a); printf("%ld",a); printed two different numbers for me |
| 17:33.40 | sunbleach | So if I load a zero and then compare it it can already be something slightly different |
| 17:33.48 | sunbleach | Because IEEE guarantees nothing |
| 17:34.44 | sunbleach | And btw I think the rt should generate +Inf and not zero |
| 17:35.23 | brlcad | mm, that it could do with -d1 |
| 17:35.35 | brlcad | just not without it obviously |
| 17:36.11 | brlcad | that's what that default/reserved 0/0/1 is for in a way |
| 17:36.15 | brlcad | for non-doubles |
| 17:36.26 | sunbleach | But that's in-band signalling and that's bad |
| 17:36.37 | sunbleach | It corrupts the picture |
| 17:36.53 | sunbleach | If your model hits the right colour it cannot be expressed and a deviated colour has to be emitted |
| 17:37.05 | sunbleach | -> error signal is intentionally mixed in -> crap |
| 17:37.09 | brlcad | sure |
| 17:37.16 | brlcad | but then you only have three channels |
| 17:37.22 | brlcad | 24 bits of data |
| 17:37.33 | brlcad | so what do you do, without increasing the number of bits |
| 17:37.41 | sunbleach | you cannot do it |
| 17:37.41 | brlcad | in practice, its not a problem |
| 17:37.46 | sunbleach | The channel is already occupied |
| 17:38.00 | brlcad | exactly, so it does the best it can without changing the requirements |
| 17:38.04 | sunbleach | in a Microsoft-style practice |
| 17:38.30 | sunbleach | it's a kludge. A scotchtape solution. |
| 17:38.47 | brlcad | actually, it was rather carefully designed that way |
| 17:39.07 | sunbleach | By who? |
| 17:39.15 | sunbleach | It's bad style |
| 17:39.18 | brlcad | as you said it yourself, you cannot do it otherwise without increasing the number of bits |
| 17:39.27 | brlcad | you obviously don't like it, that's your right :) |
| 17:40.04 | sunbleach | It's like this http://www.getreligion.org/wp-content/photos/60324190_1678a0a1d8_o.jpg |
| 17:40.11 | brlcad | but the tradeoff would be no background distinction by default, or another output channel (which was pretty darn impossible back when it was implemented) |
| 17:40.15 | sunbleach | Yeah I obviously don't like it :) |
| 17:43.37 | brlcad | what I'd really like is a full alpha transparency channel |
| 17:43.54 | brlcad | that's really what's needed, then all background could be properly represented |
| 17:44.16 | sunbleach | yes |
| 17:44.18 | brlcad | couldn't do that 15 years ago, and still can't with some hardware, but just about everything can handle it these days |
| 17:44.24 | sunbleach | but wouldn't express the hit distance of course |
| 17:45.51 | sunbleach | If you use more rays per pixel it could generate intermediate alpha values |
| 17:45.58 | brlcad | -d already does that |
| 17:46.17 | brlcad | just needs the tweak for a miss |
| 17:46.30 | brlcad | you should fix it :) |
| 17:46.34 | sunbleach | But doesn't it break the paralellism? |
| 17:46.57 | sunbleach | I could screw it up and think I've fixed it if I had time ;-) |
| 17:46.57 | brlcad | huh? |
| 17:47.43 | brlcad | yeah, with an alpha channel and -H hypersampling turned on, you could get beautiful antialiased alpha values on the edges |
| 17:47.46 | sunbleach | can't different rays of the same pixel get scheduled to different CPUs or so? |
| 17:48.01 | brlcad | hypersampling already does that |
| 17:48.18 | brlcad | i was talking about fixing -d to recognize a miss and have it report +Inf |
| 17:48.32 | brlcad | that should be pretty simple |
| 17:48.34 | sunbleach | but maybe the code somewhere secretly assumes only the first 3 bytes are added |
| 17:48.55 | *** join/#brlcad vedge (n=vedge@vedge.org) | |
| 17:49.14 | brlcad | first 3 bytes .. added .. hm? |
| 17:49.24 | sunbleach | or averaged |
| 17:49.31 | brlcad | speculation either way, but the -d code just reports the hit-dist |
| 17:49.36 | brlcad | probably just reports 0 for miss |
| 17:49.43 | sunbleach | what does -d report with antialiasing? |
| 17:49.45 | brlcad | it knows when it's a miss |
| 17:49.46 | sunbleach | Average distance? |
| 17:50.00 | sunbleach | and on the edge? |
| 17:50.27 | brlcad | actually I don't know what -d does if you try to use it with hypersample turned on |
| 17:51.33 | MinuteElectron | Ok, all stylistic bugs fixed. |
| 17:51.42 | brlcad | hypersample as it is doesn't do antialiasing, just averages the rays that do hit if the first ray hits iirc |
| 17:51.58 | brlcad | something that could be improved either way, I've never liked -H without supersampling |
| 17:52.15 | brlcad | MinuteElectron: seriously?! |
| 17:52.17 | brlcad | awesome! |
| 17:52.21 | sunbleach | When I did hypersamnpling I did it myself |
| 17:52.41 | sunbleach | Because I doubt rt takes gamma into account when averaging the samples |
| 17:52.50 | brlcad | that usually gives better results.. jack up the -s by 4/8x and downsample |
| 17:53.29 | brlcad | that way it can take neighbors into account instead of operating on a per-cell basis |
| 17:53.47 | MinuteElectron | brlcad: Well, on the face of it - yes. The pages with forms on could do with some clean up\design, but I'm concerned about this taking months (I've literally been working on this since July) so that can probably come later, once it's moved over - LDAP, at least, is more important.. |
| 17:54.47 | brlcad | MinuteElectron: quite true, you've put massive (great) efforts into this -- very much appreciated if I've not said it enough :) |
| 17:54.56 | brlcad | MinuteElectron: what was the ie6 problem? |
| 17:55.17 | MinuteElectron | brlcad: It's my pleasure, I wouldn't be doing this unless I enjoyed it ;) |
| 17:55.23 | brlcad | :) |
| 17:55.34 | MinuteElectron | The IE6 problem was just rounded corners and the blue box in the middle of the front page. |
| 17:55.40 | MinuteElectron | Both of which are fixed now. |
| 17:55.51 | sunbleach | rounded corners are in today, especially combined with white |
| 17:57.19 | MinuteElectron | Once we do get the site live and have spruced up the forms a bit I'll be concentrating on commenting my code, it is now getting very complex and difficult to maintain. |
| 17:58.16 | MinuteElectron | And, of course, anyone else who may need to edit the code will need commentes too (not that I plan to leave any time soon). |
| 17:59.26 | brlcad | i mean what was the problem with the rounded corners on ie6? |
| 17:59.29 | brlcad | what was the fix? |
| 17:59.36 | yukonbob | MinuteElectron: getting familiar with Babs? |
| 18:00.09 | MinuteElectron | brlcad: they were all missaligned significantly, to fix it i had to add a variety of margin and width hacks in the ie6 only css file. |
| 18:00.57 | MinuteElectron | yukonbob: babs? |
| 18:00.58 | brlcad | ahh |
| 18:01.10 | brlcad | so ie6 has it's own set of hacks :) |
| 18:01.21 | brlcad | guess you did have to do that for the header anyways :) |
| 18:01.37 | MinuteElectron | Yeah, lots of ie hacks. |
| 18:01.40 | yukonbob | MinuteElectron: so many references to Barbara Jenson in the ldap docs I've read over the years ;) |
| 18:02.01 | MinuteElectron | brlcad: But they are all in nice labelled ie only css files so it is easy to maintain ;) |
| 18:02.10 | MinuteElectron | yukonbob: I'm still reading the opening paragraph. :P |
| 18:02.48 | MinuteElectron | Also I'll be expanding support for the theme into other browsers hopefully once everything else is done, at least the big 5 all work perfectly. |
| 18:04.47 | MinuteElectron | yukonbob: haha, indeed |
| 18:10.09 | yukonbob | MinuteElectron: I believe I've got the first edition of this book: http://tinyurl.com/2s8832 -- which is a good (and necessary, imo) high-level view of LDAP |
| 18:10.30 | MinuteElectron | cool, i'll have a look shortly |
| 18:10.30 | brlcad | yukonbob: how're those others working out? |
| 18:11.16 | yukonbob | heh -- arrived just after I left south, and I'm only _just_ getting ready to head back ;) |
| 18:12.32 | brlcad | ahh, dumbasses |
| 18:12.38 | brlcad | they were supposed to ship separate |
| 18:13.01 | brlcad | they did say they would send two shipments, so they lied! |
| 18:15.21 | *** join/#brlcad vedge (i=vedge@vedge.org) | |
| 18:40.36 | MinuteElectron | >:C |
| 18:41.55 | brlcad | so is it using skin or skin2? |
| 18:42.07 | MinuteElectron | skin2 |
| 18:42.33 | MinuteElectron | 1) I made a mistake in the IE6 fixes so need to fix some more code, 2) LDAP is weird. |
| 18:44.04 | brlcad | it looks like it's trying ldap now |
| 18:45.02 | brlcad | but is failing to fall-back to the previously existing accounts too |
| 18:45.20 | MinuteElectron | yeah |
| 18:45.27 | MinuteElectron | well, i can't test that |
| 18:45.32 | MinuteElectron | unless i make a new account |
| 18:45.34 | MinuteElectron | well i will |
| 18:45.43 | MinuteElectron | in a while |
| 18:45.54 | brlcad | i'll stop asking questions so you can eat :) |
| 18:46.05 | sunbleach | see u later |
| 18:46.08 | MinuteElectron | lol :P |
| 18:46.12 | MinuteElectron | thxs |
| 18:46.19 | brlcad | mm eating is a good idea |
| 18:46.22 | brlcad | i haven't either |
| 18:47.23 | brlcad | yay, my ReliaMed 700 shipped today |
| 18:53.45 | brlcad | the new skin is considerably cleaner.. |
| 18:53.49 | brlcad | nice work |
| 18:54.51 | bpoole | sorry bout the overflow craziness brlcad |
| 19:01.55 | brlcad | bpoole: not your fault afaik :) |
| 19:04.12 | brlcad | mine for leaving cad's cvs2svn files around, not finishing the server migration faster, and not watching the system more carefully last night :) |
| 19:05.01 | MinuteElectron | ... |
| 19:06.01 | brlcad | minor nit |
| 19:06.20 | MinuteElectron | hmm, ok |
| 19:06.21 | brlcad | so that background rendering overlaps underneath the left-header instead of over it |
| 19:06.34 | brlcad | just swapped their order in the page.tpl |
| 19:07.05 | MinuteElectron | looks good |
| 19:07.06 | MinuteElectron | (Y) |
| 19:07.19 | brlcad | and (re)fixed the clear="all" you had on the br's |
| 19:07.37 | MinuteElectron | cool |
| 19:07.38 | brlcad | but instead of a clear style, added a clear:both; to the footer |
| 19:09.35 | brlcad | hm, http://validator.w3.org/check?uri=http%3A%2F%2Fmy.brlcad.org%2Fwiki%2F&charset=%28detect+automatically%29&doctype=Inline&ss=1&outline=1&group=0&verbose=1&st=1 |
| 19:10.48 | MinuteElectron | I'll take a look later, I have to go out do something now. |
| 19:10.52 | brlcad | i think it's a typo |
| 19:10.57 | brlcad | looks too |
| 19:11.30 | brlcad | yeah, found it |
| 19:11.46 | brlcad | cool, validates |
| 19:14.43 | brlcad | FYI, there is scheduled maintenance at the server's ISP on Thursday january 24th at 00:00AM EDT for at most 6 hours at their atlanta hub that may affect connectivity (maybe not) |
| 19:19.55 | PrezKennedy | who hosts your server brlcad? |
| 19:30.44 | *** join/#brlcad Z80-Boy (i=clock@77-56-92-109.dclient.hispeed.ch) | |
| 19:34.25 | Z80-Boy | re |
| 21:02.54 | MinuteElectron | eh? |
| 21:02.58 | MinuteElectron | What is the problem... |
| 21:03.41 | brlcad | oh snap, I think I just found it |
| 21:03.47 | MinuteElectron | :S |
| 21:06.36 | brlcad | it doesn't draw the bottom bezel if there's no width defined |
| 21:06.48 | brlcad | but then if you define a width, it's no longer properly auto-expanding |
| 21:07.02 | MinuteElectron | Which bezel are you talking about? |
| 21:07.35 | brlcad | the bottom rounding on the search boxes and the top menu |
| 21:07.57 | brlcad | the top search box was working, the bottom wasn't -- the difference was top had a width: |
| 21:08.20 | brlcad | but, like I said, if/when you define the width, you lose the resizing |
| 21:09.15 | MinuteElectron | The bottom search box looks to be working here, what browser are you using? |
| 21:09.22 | brlcad | ie7 |
| 21:09.40 | brlcad | look from one of the wiki pages -- drupal caches |
| 21:10.05 | brlcad | it works fine on the 'good' browsers |
| 21:10.51 | brlcad | i wonder if it's collapsing them because they have nothing in them.. |
| 21:11.01 | MinuteElectron | probably |
| 21:11.45 | poolio | brlcad: random question about using bz.bzflag.bz when you have time to respond :) Whenever I resize my local terminal window it messes up the characters and I have character artifacts all over the terminal. If I resize it back to where it was before and refresh the screen it's ok, but not at any other size. |
| 21:14.15 | brlcad | poolio: there aren't termcap resize events set up, so you have to log in at the size you want |
| 21:14.33 | brlcad | could be fixed, but never been enough of an annoyance to me (and screen doesn't care) |
| 21:14.47 | brlcad | you can notify a screen resize with ctrl-a F |
| 21:16.35 | poolio | ah, thanks :] |
| 21:22.38 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 21:25.33 | brlcad | hm, well it doesn't seem to be because there is nothing in them |
| 21:34.57 | MinuteElectron | brlcad: There is a similar problem on the top-right bevel. |
| 21:39.47 | brlcad | you mean the menu? |
| 21:39.57 | brlcad | i just got both search boxes working |
| 21:40.11 | brlcad | using a div similar to what you did for the right panel boxes |
| 21:41.55 | MinuteElectron | ah, gdgd |
| 21:41.58 | MinuteElectron | and yes, the menu |
| 21:43.00 | brlcad | yay, works |
| 21:43.10 | brlcad | same hack on the menu worked |
| 21:43.18 | brlcad | that work in ie6? |
| 21:43.31 | MinuteElectron | ahh, congrats. |
| 21:43.32 | brlcad | i recall it had the same rendering problem, but don't have it on this machine to test |
| 21:43.35 | MinuteElectron | IE6 was already fixed. |
| 21:43.45 | brlcad | okay, cool |
| 21:44.09 | MinuteElectron | wait, which file did you just edit to fix IE7? |
| 21:45.03 | brlcad | fix wasn't ie7 specific |
| 21:45.11 | brlcad | edited the page.tpl and style.css |
| 21:45.26 | MinuteElectron | Well, the fix broke IE6, not sure about the other browsers. |
| 21:45.27 | brlcad | to add a new sboxfooter |
| 21:45.36 | brlcad | huh |
| 21:46.11 | MinuteElectron | the main navigation base is now misalighed in IE6. |
| 21:46.26 | brlcad | what abou tnow? |
| 21:46.30 | brlcad | er, now |
| 21:46.41 | MinuteElectron | ahh, better |
| 21:46.48 | brlcad | hrm |
| 21:58.45 | brlcad | i'm running out if ideas |
| 21:59.03 | brlcad | whatever exactly you did on the left panels works right? |
| 21:59.26 | brlcad | i thought I was basically doing the same, but the position:absolute; seems to be what's borking ie6 |
| 22:05.45 | brlcad | MinuteElectron: how about now? |
| 22:06.00 | brlcad | I just made the div ie-7 specific for now |
| 22:08.03 | MinuteElectron | it's prefect |
| 22:17.44 | MinuteElectron | goodnight |
| 22:31.51 | brlcad | goodnight |
| 22:55.42 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 23:30.25 | PrezKennedy | hey Twingy |
