glean-dev — Glean development discussions

Re: [glean-dev] Uh...

[Brian S. <br...@gl...>]

At 10:50 AM 12/17/00 -0700, you wrote:
>I got a very similar message just now when I checked in a change
>in the DRI project on SourceForge.  My check-in completed however.
>Nothing's changed in my local configuration.
>
>Might be a temporary glitch.  You could check if it's already in
>the SourceForge bug/support database.

Yep, looks like it was due to their downtime (which I hadn't heard 
about).  In fact, it's right on the sourceforge.net frontpage!  Mea 
culpa.  Just wanted to make sure other people were seeing the same thing.

.b

Re: [glean-dev] Uh...

[Brian P. <br...@va...>]

Brian Sharp wrote:
> 
> Being no security expert, I haven't a clue what this means, but it's
> preventing me from checkin into SourceForge:
> 
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @       WARNING: HOST IDENTIFICATION HAS CHANGED!         @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
> Someone could be eavesdropping on you right now (man-in-the-middle attack)!
> It is also possible that the host key has just been changed.
> Please contact your system administrator.
> Add correct host key in c:\bsharp/.ssh/known_hosts to get rid of this message.
> Password authentication is disabled to avoid trojan horses.
> Permission denied.
> CVS.EXE [commit aborted]: end of file from server (consult above messages
> if any)
> 
> ... any thoughts?


I got a very similar message just now when I checked in a change
in the DRI project on SourceForge.  My check-in completed however.
Nothing's changed in my local configuration.

Might be a temporary glitch.  You could check if it's already in
the SourceForge bug/support database.

-Brian

[glean-dev] Also...

[Brian S. <br...@gl...>]

On the plus side, the stuff I'm trying to check in is:

-- Fixes to the various makefile.win such that it now builds in debug mode 
on Win32 (I'd never tried before, but I needed to run it in the MSVC 
debugger today).

-- Fixes to the GeomRenderer; it seems to work perfectly now!  It's pretty 
cool; you can just make one function call and it'll render the exact same 
geometry via totally different paths.  Display list stuff works, too, and 
the compiled vertex array extension can be used, too (that's what I needed 
to debug; I was casting it to a __cdecl when it should have been a 
__stdcall, and so things were crashing).

.b

[glean-dev] Uh...

[Brian S. <br...@gl...>]

Being no security expert, I haven't a clue what this means, but it's 
preventing me from checkin into SourceForge:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: HOST IDENTIFICATION HAS CHANGED!         @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the host key has just been changed.
Please contact your system administrator.
Add correct host key in c:\bsharp/.ssh/known_hosts to get rid of this message.
Password authentication is disabled to avoid trojan horses.
Permission denied.
CVS.EXE [commit aborted]: end of file from server (consult above messages 
if any)


... any thoughts?

Thanks.
.b

Re: [glean-dev] window acquisition

[Rik F. <fa...@va...>]

On Fri 15 Dec 2000 20:21:49 -0800,
   Allen Akin <ak...@po...> wrote:
> On Fri, Dec 15, 2000 at 02:23:20PM -0500, Brian Sharp wrote:
> | Is it possible to get the current window from somewhere?  My texgen test 
> | inherits from BasicTest, and the BasicTest runOne only passes in the 
> | Result&, not the Window as well.  So I'm afraid I actually can't swap 
> | buffers... not a huge deal (it's purely cosmetic and not worth changing 
> | much for) but kind of perplexing...
> 
> Depends on the window-system binding.  But perhaps BasicTest should
> just change to allow the window to be passed to runOne, as is done in
> several other tests.

I've made this change on my branch -- in the future, runOne will have
Window& as a second argument.

Re: [glean-dev] window acquisition

[Allen A. <ak...@po...>]

On Fri, Dec 15, 2000 at 02:23:20PM -0500, Brian Sharp wrote:
| Is it possible to get the current window from somewhere?  My texgen test 
| inherits from BasicTest, and the BasicTest runOne only passes in the 
| Result&, not the Window as well.  So I'm afraid I actually can't swap 
| buffers... not a huge deal (it's purely cosmetic and not worth changing 
| much for) but kind of perplexing...

Depends on the window-system binding.  But perhaps BasicTest should just
change to allow the window to be passed to runOne, as is done in several other
tests.

Allen

[glean-dev] window acquisition

[Brian S. <br...@gl...>]

Is it possible to get the current window from somewhere?  My texgen test 
inherits from BasicTest, and the BasicTest runOne only passes in the 
Result&, not the Window as well.  So I'm afraid I actually can't swap 
buffers... not a huge deal (it's purely cosmetic and not worth changing 
much for) but kind of perplexing...

.b

Re: [glean-dev] texgen test

[Brian S. <br...@gl...>]

At 09:22 AM 12/15/00 -0700, you wrote:
>I'm saying that it would be interesting to do the image comparison
>between the original 2D texture image and sphere-gen reflection of
>the image mapped onto the sphere.  It would require fine tessellation
>and precise sphere scaling though.  Mmmm, the more I think about it
>I doubt it would work very well.

Yeah, especially when you allow for non-perspective-correct interpolation 
(although I guess since the test is in ortho that's not a problem)...

I am planning on using a direct image comparison for another test I'm 
planning on writing, the results of which I think will be interesting: a 
test to make sure the invariance rule with respect to 1:1 pixel mapping 
works -- that odd comment in the Red Book invariance section about using a 
pixel-exact projection and a 0.375 translation from pixel coords in x and y 
yielding pixel-exact results.  So I'll draw something with a texture on 
GL_NEAREST and mapped to its exact pixel size and do a subtract of the 
texture from the readback result and make sure the resulting magnitude is 0...

But first, I have to fix up ttexgen and then finish up the little rendering 
helper...

.b

Re: [glean-dev] texgen test

[Brian S. <br...@gl...>]

At 08:16 AM 12/15/00 -0800, you wrote:
>The string stuff hasn't been standardized by ANSI, unfortunately, so
>the STL files in g++ only support a very old (and inferior) version.
>I don't have ready access to the source code, but I believe the code
>in the drawing-surface configuration library that generates canonical
>descriptions of configs shows how to work around the problem in a
>portable way.

Argh.  Well, I don't use it for very much (just for stringing together the 
failure message) so I can fix that to use something else.

.b

Re: [glean-dev] texgen test

[Brian P. <br...@va...>]

Brian Sharp wrote:
> 
> At 09:08 AM 12/15/00 -0700, you wrote:
> >1. Need to capitialize the GL in #include <GL/glut.h>
> 
> Argh.  Well, I'm removing that anyway, but I'll fix it in the meantime.
> 
> >2. There is no <sstream> header file.  There's an strstream header
> >but it doesn't define the stringstream type.
> 
> Hmm... that's really weird.  stringstream is definitely a standard part of
> the STL; it's in the STLPort and the MSVC STL... and it's in <sstream> in
> both of them.  That's really confusing.  If you do a
> 
> find /wherever/your/stl/is/ -regex ".*" -exec grep -Hn "stringstream" {} ;
> 
> ... what does it turn up?

Not much.  Just a comment:

% find /usr/include/g++-2/ -regex ".*" -exec grep -Hn "stringstream" '{}' \;
grep: /usr/include/g++-2/: Is a directory
grep: /usr/include/g++-2/std: Is a directory
/usr/include/g++-2/stl_rope.h:92:// behave a little like
basic_ostringstream<sequence::value_type> and a


-Brian

Re: [glean-dev] texgen test

[Brian P. <br...@va...>]

Allen Akin wrote:
> 
> On Fri, Dec 15, 2000 at 08:52:35AM -0700, Brian Paul wrote:
> |
> | Glean hasn't used GLUT so far, and it probably shouldn't.  There's a few
> | alternatives for drawing a sphere:
> |
> | 1. gluSphere()
> | 2. look in the tpgos.cpp file for a sphere drawing routine.
> | 3. I've attached David Blythe's code for drawing a uniformly-tesselated
> |    sphere.
> 
> Sounds like a good candidate for geomutils.cpp.  Brian?

Yes.


> | Doing a full image comparison and examining the difference might work.
> 
> I try to avoid image comparisons where possible, because there's so
> much variation in rasterization from card to card that it's difficult
> to make the comparisons reliable.  But comparisons of multiple
> rendering techniques for the same geometry on a single card should be
> relatively safe.  (I guess that's what you were suggesting.)

I'm saying that it would be interesting to do the image comparison
between the original 2D texture image and sphere-gen reflection of
the image mapped onto the sphere.  It would require fine tessellation
and precise sphere scaling though.  Mmmm, the more I think about it
I doubt it would work very well.


> | You might try rendering to the front buffer with glDrawBuffer(GL_FRONT)
> | and omit SwapBuffers.
> 
> I haven't decided what to do about rendering to the front buffer.
> Some cards literally can't do it, so making a test depend on it could
> restrict the usefulness of the test.

Yikes, front buffer rendering now working?!?  I didn't know that.
I was suggesting it as a debugging step for Brian anyway.

-Brian

Re: [glean-dev] texgen test

[Brian S. <br...@gl...>]

At 08:13 AM 12/15/00 -0800, you wrote:
>| Immediate Mode: glVertex
>| Vertex Arrays: glArrayElement
>| Vertex Arrays: glDrawArrays
>| Vertex Arrays: glDrawElements
>| Any of the above baked into a display list.
>
>Compiled vertex arrays?

Yes, of course, thanks.  Nearly forgot.

>It sounds like a good idea.  Would it be general enough to subsume
>what's done in tvtxperf.cpp?

I'll check and make sure that it will be.

.b

Re: [glean-dev] texgen test

[Allen A. <ak...@po...>]

On Fri, Dec 15, 2000 at 09:08:38AM -0700, Brian Paul wrote:
| 
| 2. There is no <sstream> header file.  There's an strstream header
| but it doesn't define the stringstream type.

The string stuff hasn't been standardized by ANSI, unfortunately, so
the STL files in g++ only support a very old (and inferior) version. 
I don't have ready access to the source code, but I believe the code
in the drawing-surface configuration library that generates canonical
descriptions of configs shows how to work around the problem in a
portable way.

Allen

Re: [glean-dev] texgen test

[Brian S. <br...@gl...>]

At 09:12 AM 12/15/00 -0700, you wrote:
>Here's the Linux "strstream.h" file (which is included by "strstream"),
>in case it helps:

strstream is an STL object that uses a C-string (char array) as its basis; 
stringstream uses an STL string object as its basis; so they're distinct 
classes.  But both are part of the standard... I'm still confused.

.b

Re: [glean-dev] texgen test

[Allen A. <ak...@po...>]

On Fri, Dec 15, 2000 at 10:55:49AM -0500, Brian Sharp wrote:
| -- Adding two objects, one to generate spheres, and one to generate 
| tessellated planes (not sure if the latter is already covered by one of 
| those, I'll check).

RandomMesh2D might be helpful.

| -- Adding an object, GeomRenderer, that can be used in conjunction with 
| these objects, to render primitives in a variety of ways.  One of my 
| concerns with some tests I'm writing is that drivers do things wildly 
| differently sometimes depending on which method you use to pass in the 
| geometry, so GeomRenderer will take a pile of data and render it for you in 
| one of a host of ways:
| 
| Immediate Mode: glVertex
| Vertex Arrays: glArrayElement
| Vertex Arrays: glDrawArrays
| Vertex Arrays: glDrawElements
| Any of the above baked into a display list.

Compiled vertex arrays?

| It also allows you to specify which parameters are enabled or disabled 
| (vertices, normals, colors, texcoords, etc.)
| 
| This way I hope it'll be easy to take the texgen test and others I'm 
| writing and just have them iterate over what they're already doing 10 times 
| or so, each done using a different geometry path.  I think it should be 
| really handy.

It sounds like a good idea.  Would it be general enough to subsume
what's done in tvtxperf.cpp?

Allen

Re: [glean-dev] texgen test

[Brian S. <br...@gl...>]

At 09:08 AM 12/15/00 -0700, you wrote:
>1. Need to capitialize the GL in #include <GL/glut.h>

Argh.  Well, I'm removing that anyway, but I'll fix it in the meantime.

>2. There is no <sstream> header file.  There's an strstream header
>but it doesn't define the stringstream type.

Hmm... that's really weird.  stringstream is definitely a standard part of 
the STL; it's in the STLPort and the MSVC STL... and it's in <sstream> in 
both of them.  That's really confusing.  If you do a

find /wherever/your/stl/is/ -regex ".*" -exec grep -Hn "stringstream" {} ;

... what does it turn up?

.b

Re: [glean-dev] texgen test

[Allen A. <ak...@po...>]

On Fri, Dec 15, 2000 at 08:52:35AM -0700, Brian Paul wrote:
| 
| Glean hasn't used GLUT so far, and it probably shouldn't.  There's a few
| alternatives for drawing a sphere:
| 
| 1. gluSphere()
| 2. look in the tpgos.cpp file for a sphere drawing routine.
| 3. I've attached David Blythe's code for drawing a uniformly-tesselated
|    sphere.

Sounds like a good candidate for geomutils.cpp.  Brian?

| Doing a full image comparison and examining the difference might work.

I try to avoid image comparisons where possible, because there's so
much variation in rasterization from card to card that it's difficult
to make the comparisons reliable.  But comparisons of multiple
rendering techniques for the same geometry on a single card should be
relatively safe.  (I guess that's what you were suggesting.)

| You might try rendering to the front buffer with glDrawBuffer(GL_FRONT)
| and omit SwapBuffers.

I haven't decided what to do about rendering to the front buffer. 
Some cards literally can't do it, so making a test depend on it could
restrict the usefulness of the test.

Allen

Re: [glean-dev] texgen test

[Brian P. <br...@va...>]

Brian Paul wrote:
> 
> Brian Sharp wrote:
> >
> > At 08:52 AM 12/15/00 -0700, you wrote:
> > > > Well, I finally got around to writing a test. :-)
> > > >
> > > > I just checked it in; it tests the texgen modes.
> > >
> > >I haven't seen the check-in message and a cvs update didn't find it.
> >
> > Really?  It's in there... I just did a cvs get glean to a new location and
> > it came through.  It's src/glean/ttexgen.[h,cpp] and src/glean/makefile.win.
> 
> I tried again after I sent my message and I got it (weird).
> 
> But now I'm getting compilation problems on Linux.
> 
> 1. Need to capitialize the GL in #include <GL/glut.h>
> 
> 2. There is no <sstream> header file.  There's an strstream header
> but it doesn't define the stringstream type.

Here's the Linux "strstream.h" file (which is included by "strstream"),
in case it helps:

-Brian

Re: [glean-dev] texgen test

[Brian P. <br...@va...>]

Brian Sharp wrote:
> 
> At 08:52 AM 12/15/00 -0700, you wrote:
> > > Well, I finally got around to writing a test. :-)
> > >
> > > I just checked it in; it tests the texgen modes.
> >
> >I haven't seen the check-in message and a cvs update didn't find it.
> 
> Really?  It's in there... I just did a cvs get glean to a new location and
> it came through.  It's src/glean/ttexgen.[h,cpp] and src/glean/makefile.win.

I tried again after I sent my message and I got it (weird).

But now I'm getting compilation problems on Linux.

1. Need to capitialize the GL in #include <GL/glut.h>

2. There is no <sstream> header file.  There's an strstream header
but it doesn't define the stringstream type.

-Brian

Re: [glean-dev] texgen test

[Brian S. <br...@gl...>]

At 08:52 AM 12/15/00 -0700, you wrote:
> > Well, I finally got around to writing a test. :-)
> >
> > I just checked it in; it tests the texgen modes.
>
>I haven't seen the check-in message and a cvs update didn't find it.

Really?  It's in there... I just did a cvs get glean to a new location and 
it came through.  It's src/glean/ttexgen.[h,cpp] and src/glean/makefile.win.

.b

Re: [glean-dev] texgen test

[Brian S. <br...@gl...>]

At 07:44 AM 12/15/00 -0800, you wrote:
>glean itself has never required glut, although the tiff tools
>(showtiff and difftiff) have.  So technically there's a new
>dependency, but only for the glean executable.
>
>...
>
>Sounds like we could use a couple of new functions in geomutils.cpp or
>glutils.cpp to generate spheres.  (We already have utilities to
>generate other kinds of geometry for testing, so this would probably
>fit right in.)

I'm working on this right now.  What I'm planning on doing is the following:

-- Adding two objects, one to generate spheres, and one to generate 
tessellated planes (not sure if the latter is already covered by one of 
those, I'll check).

-- Adding an object, GeomRenderer, that can be used in conjunction with 
these objects, to render primitives in a variety of ways.  One of my 
concerns with some tests I'm writing is that drivers do things wildly 
differently sometimes depending on which method you use to pass in the 
geometry, so GeomRenderer will take a pile of data and render it for you in 
one of a host of ways:

Immediate Mode: glVertex
Vertex Arrays: glArrayElement
Vertex Arrays: glDrawArrays
Vertex Arrays: glDrawElements
Any of the above baked into a display list.

It also allows you to specify which parameters are enabled or disabled 
(vertices, normals, colors, texcoords, etc.)

This way I hope it'll be easy to take the texgen test and others I'm 
writing and just have them iterate over what they're already doing 10 times 
or so, each done using a different geometry path.  I think it should be 
really handy.

.b

Re: [glean-dev] texgen test

[Brian P. <br...@va...>]

Brian Sharp wrote:
> 
> Well, I finally got around to writing a test. :-)
> 
> I just checked it in; it tests the texgen modes.

I haven't seen the check-in message and a cvs update didn't find it.


>  I came up with (what I
> think is) a neat way to test sphere_map: I draw a sphere with sphere_map on
> and check that the texture came through undistorted.

Good idea!


> Some concerns I have about the test are:
> 
> -- I'm using an ortho projection; it could be that some drivers would have
> bugs (say, with eye_linear) that would only show up under a perspective
> transform.
> 
> -- I'm using glutSolidSphere to render the sphere.  A couple issues: does
> glean necessarily require glut, or am I introducing a dependency?  And the
> other thing is that GLUT probably uses the glBegin/glEnd style for drawing
> the sphere, where a lot of drivers' problems might only show up when you
> use vertex arrays (since Quake3 didn't use texgen, I've seen drivers that
> skip it when you turn it on if you otherwise look like the Q3 path).

Glean hasn't used GLUT so far, and it probably shouldn't.  There's a few
alternatives for drawing a sphere:

1. gluSphere()
2. look in the tpgos.cpp file for a sphere drawing routine.
3. I've attached David Blythe's code for drawing a uniformly-tesselated
   sphere.


> -- My sampling method isn't particularly rigorous; I basically hand-entered 6
> different sample points that should fall inside the sphere's pixels but
> also on the lower-left quadrant of the image.  Then I read back the whole
> 50x50 pixel image and check each quadrant using those sample points to make
> sure they're all the right color.  Obviously it would be possible for a
> driver to pass that without doing the right thing, but it's not
> particularly likely, so I think this is okay.

Doing a full image comparison and examining the difference might work.
Choosing the tolerance is hard though.  You could at least check against
a gross threshold, in addition to your current tests.


> -- I put in a sleep(1000) between rendering passes to make sure it all
> looked okay, and for the first visual it looked fine, but for all the
> others all I see is white in the window (but the test passes, so maybe it's
> just not being flipped?)  I didn't bother really checking into why this is
> happening, since it seems to be working okay.  (Oh, and I took the sleep
> out before checking it in :-) ).

You might try rendering to the front buffer with glDrawBuffer(GL_FRONT)
and omit SwapBuffers.

-Brian

Re: [glean-dev] texgen test

[Allen A. <ak...@po...>]

On Fri, Dec 15, 2000 at 06:18:50AM -0500, Brian Sharp wrote:
| Well, I finally got around to writing a test. :-)

Excellent!

| -- I'm using an ortho projection; it could be that some drivers would have 
| bugs (say, with eye_linear) that would only show up under a perspective 
| transform.

That's true, though the ortho projection test is valuable enough that
I wouldn't lose sleep over it.  Adding a note to the TODO list might
be a good idea.

| -- I'm using glutSolidSphere to render the sphere.  A couple issues: does 
| glean necessarily require glut, or am I introducing a dependency?  ...

glean itself has never required glut, although the tiff tools
(showtiff and difftiff) have.  So technically there's a new
dependency, but only for the glean executable.

Whether this is a real problem or not is open to question.  I'd like
to ensure that glut is never used to create windows or to manage
events, because it doesn't have a rigorous method for selecting pixel
formats and because it preempts the entire event-management process.

|                                                                ... And the 
| other thing is that GLUT probably uses the glBegin/glEnd style for drawing 
| the sphere, where a lot of drivers' problems might only show up when you 
| use vertex arrays (since Quake3 didn't use texgen, I've seen drivers that 
| skip it when you turn it on if you otherwise look like the Q3 path).

Sounds like we could use a couple of new functions in geomutils.cpp or
glutils.cpp to generate spheres.  (We already have utilities to
generate other kinds of geometry for testing, so this would probably
fit right in.)

| -- My sampling method isn't particularly rigorous; I basically hand-entered 6
| different sample points that should fall inside the sphere's pixels but 
| also on the lower-left quadrant of the image.  Then I read back the whole 
| 50x50 pixel image and check each quadrant using those sample points to make 
| sure they're all the right color.  Obviously it would be possible for a 
| driver to pass that without doing the right thing, but it's not 
| particularly likely, so I think this is okay.

Probably.  I haven't looked at the code (I'm at my parents' house and
net connectivity here is limited) but your reasoning seems sound.

|              ... for the first visual it looked fine, but for all the 
| others all I see is white in the window (but the test passes, so maybe it's 
| just not being flipped?)  ...

Probably.  Most of the existing tests make a point of swapping the
buffers so that there's something to see.  Otherwise users get antsy. :-)

Allen

[glean-dev] texgen test

[Brian S. <br...@gl...>]

Well, I finally got around to writing a test. :-)

I just checked it in; it tests the texgen modes.  I came up with (what I 
think is) a neat way to test sphere_map: I draw a sphere with sphere_map on 
and check that the texture came through undistorted.

Some concerns I have about the test are:

-- I'm using an ortho projection; it could be that some drivers would have 
bugs (say, with eye_linear) that would only show up under a perspective 
transform.

-- I'm using glutSolidSphere to render the sphere.  A couple issues: does 
glean necessarily require glut, or am I introducing a dependency?  And the 
other thing is that GLUT probably uses the glBegin/glEnd style for drawing 
the sphere, where a lot of drivers' problems might only show up when you 
use vertex arrays (since Quake3 didn't use texgen, I've seen drivers that 
skip it when you turn it on if you otherwise look like the Q3 path).

-- My sampling method isn't particularly rigorous; I basically hand-entered 6
different sample points that should fall inside the sphere's pixels but 
also on the lower-left quadrant of the image.  Then I read back the whole 
50x50 pixel image and check each quadrant using those sample points to make 
sure they're all the right color.  Obviously it would be possible for a 
driver to pass that without doing the right thing, but it's not 
particularly likely, so I think this is okay.

-- I put in a sleep(1000) between rendering passes to make sure it all 
looked okay, and for the first visual it looked fine, but for all the 
others all I see is white in the window (but the test passes, so maybe it's 
just not being flipped?)  I didn't bother really checking into why this is 
happening, since it seems to be working okay.  (Oh, and I took the sleep 
out before checking it in :-) ).

As always, I'd appreciate knowing if gcc has any problems with my code, too.

Thanks!
.b

Re: [glean-dev] testing texgen, etc.

[Brian P. <br...@va...>]

Brian Sharp wrote:
> 
> At 08:19 AM 12/12/00 -0700, you wrote:
> > > Texgen and lighting are two things I'd like good tests for, given that lots
> > > of drivers have problems with them where they all pretty much have the
> > > basic vertex transforms solid at this point.
> >
> >I hadn't heard that many drivers were broken in this area.  Interesting.
> 
> I remember a certain driver I was working on was doing spheremap texgen
> wrong, and so I ran a test app on that driver, the MS OGL driver, the SGI
> OGL driver, and Mesa.  Each driver's result was completely different.
> 
> (Mesa was the only one that got it right :-) ).


You just made my day!

-Brian