hpoj-devel

Re: [hpoj-devel] xojpanel

[<pa...@rc...>]

Hi, Joe.

joe...@sn... said:
> There is another problem with either xojpanel or the low-level code.
> Sometimes xojpanel fails to start on the first try. This message is
> displayed  at the command line:
>
> "Error 0 (system error 100) in file mlccon.c, line 280: Unexpected
> error,  please post a bug report to hpo...@bs..."
I will fix that e-mail address.

> If I try to start it a second time, xojpanel usually starts and runs
> with no  problems that I can see.
I'm not sure what the problem here is, but the problem must be in the
low-level driver code.  Do you see any error messages in syslog
(/var/log/messages)?  You could also try using the "debug=1" parameter when
loading ieee12844pp.o, and maybe from that I can tell where it's going wrong.
Could you elaborate on the circumstances in which this happens?  For example,
does it only happen the first time after you load the drivers, or does it
happen after you power-cycle the peripheral, etc.?

> I also made it possible to load the pixmaps from a user-specified
> directory  chosen at build-time. I took most of your advice on
> creating a single pixmap  loading function.  It will be necessary for
> the pixmap path and its enclosing  quotes to be inserted in place of
>
> XOJPANEL_DEFAULT_PIXMAP_PATH 
>
> I hope what I did works correctly. It will correctly handle whatever
> path is  #defined in ojstatus.cpp, but I haven't tested it when
> controlling from  ./configure.
Super.  It looked fine to me.  I will hack this into the configure/build
sequence when I commit it to CVS.

> I removed most of the references to unicode and replaced #define
> UNICODE_SUPPORT with #define USE_QCHAR. 
OK.

> Do my recent changes to the pixmap loading code work correctly? Does
> it still segfault? 
I played with it a lot last night, and I'm no longer seeing the various
segfaults I previously reported.  Thanks for fixing that.

Attached is a patch containing some changes I made.  The second change adds
an explanation if xojpanel dies because the peripheral doesn't support LCD
readback.  The first change changes the poll rate from once to four times
per second, which greatly improved the response when I was scrolling through
menus really fast.  However, it's probably not worth actually putting in,
because I expect most people wouldn't need this level of responsiveness
given the extra overhead it introduces, and IIRC you previously indicated
some reason (debugging?) why you didn't want it to poll more than once per
second anyway.

I'm glad you added the license statement at the top of the files, but you
might want to add a copyright message, similar to what I did in the ptal
and ieee12844 directories.  If you do this then it would be proper to also
include a copyright for the original author, which I think was Andreas
Fester.  (Is this correct, Andreas?  And what copyright year should be
given for you?)

When should I start putting this into CVS?  Once I do, then it would be
preferable for additional changes to be made available as patches to
hpoj-devel, even if you continue to provide a downloadable package on your
website.

Am I correct in assuming that the only file I should remove from CVS is
lcd.bmp?  For the new files you provide, should I include
CHANGES-xojpanel_jsp (possibly renamed to just "CHANGES")?  It might be
easier to let the CVS checkin comments serve as the changelog.  What about
xojpanel.kdelnk (maybe?) and .directory (probably not)?

David

Re: [hpoj-devel] xojpanel

[<pa...@rc...>]

Hi, Joe.

Joe Piolunek wrote:
> Lately the line number reported in the error message has been 263, but that 
> doesn't matter very much now. I'm reasonably certain I found what was causing 
> the problem. In /var/log/messages the OfficeJet is reported as being on an 
> EPP port rather than an ECP, which I thought it was. After I removed the 
> ieee12844pp module and reinserted it with the usenibble=1 option, xojpanel 
> starts every time. I wrote a shell script that would repeatedly start and 
> then kill xojpanel 6 seconds later. It's been through 1000 startups so far 
> without any failures. Previously, one try in 15 starts would fail (rough 
> average).
> I'll see what happens after I change the port type to ECP on the IO card the 
> OfficeJet is connected to. 
That would be interesting to try.  The bidirectional ECP patch causes the
parallel port to be used in different ways compared to before (or when using
usenibble=1).  Is your second parallel port software-configurable, or do you
have to change jumpers?  If you can't get it working on that port, then
perhaps you could try swapping ports.

> The patch installed ok, but it gave two error messages:
> patch unexpectedly ends in middle of line
> patch unexpectedly ends in middle of line
> 
> xojpanel compiles runs fine with the patch.
That's strange.  Did you tell your mail client to save the attachment to a
file, or did you copy and paste (which could cause a problem)?  I just
looked at a hex dump of the patch file as I sent it out, and there is a
newline at the end of the file, which is what it could be complaining about.
Did you double-check the code to make sure it applied the patch correctly?

> Early in development, the printer poll timer controlled scroll speed as well, 
> so to cut down on unnecessary console output during testing, I set it as high 
> as 3000ms (if I remember correctly). Now that the timers are separate, that 
> reason is gone. The poll timer can be set lower than 1000ms. Are there any 
> network delay issues to consider in setting the timer? For instance, if an 
> lcd message is changing in the printer, but it's being polled too often, the 
> wrong message might get to xojpanel first. Could this happen?
Occasionally when I was scrolling through the menus, it looked like it
updated the two lines in separate polls, which might indicate a race
condition with the peripheral where it was in the middle of updating the LCD
as you suggest.  However, it doesn't seem to be a big problem.  My concern
would be more about what happens if the timer pops again before it's done
servicing the previous poll.  I think the most optimal behavior would be
that it ignores timer pops when it's still servicing a previous timer pop.
A less optimal option would be for it to just queue up poll requests.  I
think it would be pretty undesirable for it to initiate another set of PML
transactions before it was done with the last set.

> Overhead doesn't seem to be a big problem with xojpanel. It seems to use a 
> lot of memory, but little processor time.
I guess one should expect a fair amount of memory overhead from a GUI
toolkit such as QT, but it's surprising that it uses more RAM than kwm.
I would suggest checking all the places where you use "new" to make sure
that either there's a corresponding "delete" or there doesn't need to be
one.  I grepped for those strings (with a space after them) and there was
at least one more new than delete of QString.  Of course I doubt this would
add a significant amount of overhead, and at least the memory usage doesn't
appear to grow over time (at least not in the last 15 minutes or so).

> top -p says that most of the time 
> its CPU usage is 0.0%. The timer is set at 500ms for now, though.
OK, that sounds reasonable.

> I'll put a copyright notice in, with credit for anyone who contributed to the 
> remaining parts of the original xojpanel, if the contributors can be 
> identified. If not, I'll give generic credit. It might be important to know 
> the origin of the name 'xojpanel'. Andreas' response should be helpful. 
>
> Hopefully, the copyright issue will be solved soon, so waiting a day or so 
> before committing the new xojpanel code to CVS will probably make one patch 
> unnecessary. 
> 
> Handle the changelog whichever way you think is best.
> 
> You won't need .directory for anything. I probably should have deleted that. 
> lcd.bmp is no longer used or even very usable, due to a size difference. You 
> can leave both of them out.
> 
> A KDE user could copy xojpanel.kdelnk to his/her desktop for a quick way to 
> start the app. Many users may prefer to create their own launchers, but some 
> don't know how, or don't want to go to the trouble. The addition of a GNOME 
> launcher might be nice later on. I have only an older version of GNOME and 
> haven't used it in a while, so I wasn't that interested in making one right 
> away.

OK, so I will go ahead and start making the changes to support the
compile-time pixmap path, but I'll wait for your go-ahead to commit it all
into CVS.  I will take out the changelog file (but reflect it in the checkin
comments) and remove .directory.  I will include xojpanel.kdelnk in the
package but probably won't install it anywhere.

David

Re: [hpoj-devel] xojpanel

[Joe P. <joe...@sn...>]

 On Monday 04 December 2000 05:11, David Paschal wrote:

<...>

> > I'll see what happens after I change the port type to ECP on the IO card
> > the OfficeJet is connected to.
>
> That would be interesting to try.  The bidirectional ECP patch causes the
> parallel port to be used in different ways compared to before (or when
> using usenibble=1).  Is your second parallel port software-configurable, or
> do you have to change jumpers?  If you can't get it working on that port,
> then perhaps you could try swapping ports.
>

I changed the IO card's port type to ECP. The jumpers needed to be moved on 
the card. The reason I installed the card was to add support for a second 
printer. The other printer is connected to a built-in port controlled by the 
BIOS.

There wasn't any real improvement after changing the port type. Without the 
usenibble=1 option, xojpanel still fails to start 1/25 times averaged over 
500 attempts to execute.

Adding the usenibble option is still needed to make xojpanel start reliably 
for me. With it, my script reported two failures in over 2000 attempts to 
execute. Both occurred when I was doing something with another application.

cat /proc/parports/0/devices showed this:
IEEE1284.4 device
lp

which apparently means that both drivers would have access to parport0. I 
added the kernel start-up option  ' append="lp=parport1" ' to /etc/lilo.conf 
that prevents my compiled-in lp from using parport0. Now only 'IEEE1284.4 
device' is reported on that port, but it didn't make any difference to 
xojpanel. It still failed to start about 4% of the time.


> > The patch installed ok, but it gave two error messages:
> > patch unexpectedly ends in middle of line
> > patch unexpectedly ends in middle of line
> >
> > xojpanel compiles runs fine with the patch.
>
> That's strange.  Did you tell your mail client to save the attachment to a
> file, or did you copy and paste (which could cause a problem)?  I just
> looked at a hex dump of the patch file as I sent it out, and there is a
> newline at the end of the file, which is what it could be complaining
> about. Did you double-check the code to make sure it applied the patch
> correctly?
>

I saved it as a file.

The trouble seems to have been related the the last line in your patch, which 
contained only '^@'  . I made my own diff -c  and then using diff, compared 
your patch and mine.  The difference was a newline at the end of one of the 
files. Looking at both patches in vim shows '^@'  at the end of your patch, 
but not at the end of mine. Is the last character something added by your 
editor?

Incidentally, I got the same error when I applied your documentation patch. 
Both patches applied correctly, even with the reported errors.

<...> the wrong message might get to xojpanel
> > first. Could this happen?
>
> Occasionally when I was scrolling through the menus, it looked like it
> updated the two lines in separate polls, which might indicate a race
> condition with the peripheral where it was in the middle of updating the
> LCD as you suggest.  However, it doesn't seem to be a big problem.  My
> concern would be more about what happens if the timer pops again before
> it's done servicing the previous poll.  I think the most optimal behavior
> would be that it ignores timer pops when it's still servicing a previous
> timer pop. A less optimal option would be for it to just queue up poll
> requests.  I think it would be pretty undesirable for it to initiate
> another set of PML transactions before it was done with the last set.
>

Every time the printer polling timer fires (500ms), it calls 
getPrinterLcdMessages() which uses some of the original xojpanel code to make 
a request for each one of the message lines, one immediately after the other. 
They are separate requests in that sense, but the time interval would be 
extremely small unless a delay were introduced somewhere outside xojpanel. 
None of the code I added to xojpanel would create any deliberate delay 
between asking for line 1 and line 2. I still don't know how the low-level 
code retrieves the two message lines, but I haven't spent much time looking 
at it. It probably would be easier to understand if there were more 
documentation in the code.


> > Overhead doesn't seem to be a big problem with xojpanel. It seems to use
> > a lot of memory, but little processor time.
>
> I guess one should expect a fair amount of memory overhead from a GUI
> toolkit such as QT, but it's surprising that it uses more RAM than kwm.
> I would suggest checking all the places where you use "new" to make sure
> that either there's a corresponding "delete" or there doesn't need to be
> one.  I grepped for those strings (with a space after them) and there was
> at least one more new than delete of QString.  Of course I doubt this would
> add a significant amount of overhead, and at least the memory usage doesn't
> appear to grow over time (at least not in the last 15 minutes or so).
>

Most of the program's execution probably takes place in libqt, which seems to 
control or affect memory usage, among other things.  When xojpanel is built 
with Qt 2.x, it uses a lot more memory than if built with Qt 1.x. The docs 
say that qt is able to do some of its own memory clean-up, but I haven't seen 
a complete explanation of this. What it seems like (I might be wrong here) is 
objects created repetitively by 'new' seem to need deletion, but those that 
are only created once and continue to be necessary may not be deletable until 
program termination. When I tried deleting one of those, a segfault occurred. 
I don't have enough information about this. A Qt book is coming soon that may 
help. I have had a different one on order since september, but a recent 
announcement says it won't be published until mid spring. 

I've run xojpanel for several hours at a time after building with qt-1.44 and 
saw no increased memory usage, which seems to indicate that either some of 
the 'new's don't need corresponding 'deletes', or any problem created is 
small. I'll take another look at the undeleted 'new's anyway.


>
> OK, so I will go ahead and start making the changes to support the
> compile-time pixmap path, but I'll wait for your go-ahead to commit it all
> into CVS.  I will take out the changelog file (but reflect it in the
> checkin comments) and remove .directory.  I will include xojpanel.kdelnk in
> the package but probably won't install it anywhere.
>
> David
>

That will be fine.

Probably by tomorrow night (tuesday) I'll have the files on my site with the 
copyright notices added. After that you can put them in CVS whenever you like.

--
Joe

RE: [hpoj-devel] xojpanel

[PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...>]

Hi, Joe.

Joe Piolunek wrote:
> There wasn't any real improvement after changing the port 
> type. Without the 
> usenibble=1 option, xojpanel still fails to start 1/25 times 
> averaged over 
> 500 attempts to execute.
That's strange.  So are there any error messages in syslog related to this?
If I know where it fails, then I might know what needs to be fixed.  You
could also try adding the "debug=1" parameter when loading ieee12844pp.o.

> cat /proc/parports/0/devices showed this:
> IEEE1284.4 device
> lp
I noticed that situation too when playing around with printing the other
day.  It seems dangerous to me, even though I could still print, so that's
why I added a note in color_printing.txt recommending to change the port
from /dev/lpX to /dev/null.

(regarding patch's error messages)
> The trouble seems to have been related the the last line in 
> your patch, which 
> contained only '^@'  . I made my own diff -c  and then using 
> diff, compared 
> your patch and mine.  The difference was a newline at the end 
> of one of the 
> files. Looking at both patches in vim shows '^@'  at the end 
> of your patch, 
> but not at the end of mine. Is the last character something 
> added by your 
> editor?
I just looked at a hex dump of the message I got back from the mailing list,
and I didn't see any null bytes in the message.  Perhaps your mail client is
adding them when you save attachments?  You could always remove the
offending character before patching.

Has anybody else seen this problem, where patch complains that "patch
unexpectedly ends in middle of line"?

> Every time the printer polling timer fires (500ms), it calls 
> getPrinterLcdMessages() which uses some of the original 
> xojpanel code to make 
> a request for each one of the message lines, one immediately 
> after the other. 
> They are separate requests in that sense, but the time 
> interval would be 
> extremely small unless a delay were introduced somewhere 
> outside xojpanel. 
> None of the code I added to xojpanel would create any 
> deliberate delay 
> between asking for line 1 and line 2. I still don't know how 
> the low-level 
> code retrieves the two message lines, but I haven't spent 
> much time looking 
> at it. It probably would be easier to understand if there were more 
> documentation in the code.
What happens is that for each line, getPrinterLCDMessages() calls
PMLGetObjectValue, which sends the request to the peripheral, and then calls
PMLProcess, which sits around and waits for the response.  When PMLProcess
gets the response, it calls XojPanel::processorFunc (which is a callback
function registered at startup by PMLSetup), which saves the string for the
correct line.

I'm not sure why you couldn't add a delay between lines 1 and 2.  Did you
try calling sleep(5 seconds or whatever) in between the two line requests in
getPrinterLCDMessages?

David

Re: [hpoj-devel] xojpanel

[Joe P. <joe...@sn...>]

On Tuesday 05 December 2000 19:06, PASCHAL,DAVID (HP-Roseville,ex1) wrote:
> Hi, Joe.
>
> Joe Piolunek wrote:
> > There wasn't any real improvement after changing the port
> > type. Without the
> > usenibble=1 option, xojpanel still fails to start 1/25 times
> > averaged over
> > 500 attempts to execute.
>
> That's strange.  So are there any error messages in syslog related to this?
> If I know where it fails, then I might know what needs to be fixed.  You
> could also try adding the "debug=1" parameter when loading ieee12844pp.o.
>

You asked earlier about the circumstances when this happens, but I didn't 
send it. Sorry about that. The no-starts occur seemingly at random without 
any special situation that I can identify.

There don't seem to be any related error messages unless I use debug=1, which 
produces a very large number of them. /var/log/messages receives about 185 
lines every second that xojpanel is running.

Here are a few lines from /var/log/messages that may be helpful. The presence 
of the printer's ID string seems to be related to the number of xojpanel 
no-starts.  It also seems related to the time the no-starts occur, but that's 
hard to be sure of. The device ID is the message that most stands out, but 
there are a lot of messages to look at, and I could have missed something 
more important.

Dec  6 10:39:04 tumbleweed kernel: c4842368: event=9. 
Dec  6 10:39:04 tumbleweed kernel: get_nibble(c4842368): nibble=0x6. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=11. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=6. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=9. 
Dec  6 10:39:04 tumbleweed kernel: get_nibble(c4842368): nibble=0xB. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=11. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=6. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=9. 
Dec  6 10:39:04 tumbleweed kernel: get_nibble(c4842368): nibble=0x3. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=11. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=6. 
Dec  6 10:39:04 tumbleweed kernel: mlcpp0: Got device ID string: 
<MFG:Hewlett-Packard;MDL:OfficeJet Series 
600;CMD:MLC,PCL,PML;CLASS:PRINTER;REV:4.03b;> 
Dec  6 10:39:04 tumbleweed kernel: mlcpp0: usebecp=0. 
Dec  6 10:39:04 tumbleweed kernel: do_neg(c4842368,mode=0x10): in_1284=1, 
neg_mode=0x04. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=23. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=27. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=0. 
Dec  6 10:39:04 tumbleweed kernel: c4842368: event=2. 


> > cat /proc/parports/0/devices showed this:
> > IEEE1284.4 device
> > lp
>
> I noticed that situation too when playing around with printing the other
> day.  It seems dangerous to me, even though I could still print, so that's
> why I added a note in color_printing.txt recommending to change the port
> from /dev/lpX to /dev/null.
>.

I was able to print before with the two devices on the same port, though it 
seemed like only one device at a time could use the port. The file 
parport.txt in the 2.2.16 kernel documentation seems to say that multiple 
device drivers can co-exist at the same parallel port. They don't seem to be 
able to use the port simultaneously, though.


> (regarding patch's error messages)

> I just looked at a hex dump of the message I got back from the mailing
> list, and I didn't see any null bytes in the message.  Perhaps your mail
> client is adding them when you save attachments?  You could always remove
> the offending character before patching.
>
> Has anybody else seen this problem, where patch complains that "patch
> unexpectedly ends in middle of line"?

Looking at the files with kedit, there was a single space on the last line. 
Removing the space allowed the patches to be applied without errors. I don't 
know how the space got there, but It  may very well be the mailer I use. It's 
the new kmail that's part of kde2. Nearly everything in kde 2.0 is buggy.
>
> I'm not sure why you couldn't add a delay between lines 1 and 2.  Did you
> try calling sleep(5 seconds or whatever) in between the two line requests
> in getPrinterLCDMessages?
>

We might have been having a misunderstanding. Maybe it was only me. 

The sleep() call did cause a delay when I finally tried to introduce one. It 
didn't prevent the no-start problem though.


-- 
Joe

Re: [hpoj-devel] xojpanel

[Joe P. <joe...@sn...>]

On Saturday 02 December 2000 04:40, David Paschal wrote:

> > Hi, Joe.
>
> joe...@sn... said:
> > There is another problem with either xojpanel or the low-level code.
> > Sometimes xojpanel fails to start on the first try. This message is
> > displayed  at the command line:
> >
> > "Error 0 (system error 100) in file mlccon.c, line 280: Unexpected
> > error,  please post a bug report to hpo...@bs..."
>
> I will fix that e-mail address.
>
> > If I try to start it a second time, xojpanel usually starts and runs
> > with no  problems that I can see.
>
> I'm not sure what the problem here is, but the problem must be in the
> low-level driver code.  Do you see any error messages in syslog
> (/var/log/messages)?  You could also try using the "debug=1" parameter when
> loading ieee12844pp.o, and maybe from that I can tell where it's going
> wrong. Could you elaborate on the circumstances in which this happens?  For
> example, does it only happen the first time after you load the drivers, or
> does it happen after you power-cycle the peripheral, etc.?

Lately the line number reported in the error message has been 263, but that 
doesn't matter very much now. I'm reasonably certain I found what was causing 
the problem. In /var/log/messages the OfficeJet is reported as being on an 
EPP port rather than an ECP, which I thought it was. After I removed the 
ieee12844pp module and reinserted it with the usenibble=1 option, xojpanel 
starts every time. I wrote a shell script that would repeatedly start and 
then kill xojpanel 6 seconds later. It's been through 1000 startups so far 
without any failures. Previously, one try in 15 starts would fail (rough 
average).

I'll see what happens after I change the port type to ECP on the IO card the 
OfficeJet is connected to. 
 

> Attached is a patch containing some changes I made.  The second change adds
> an explanation if xojpanel dies because the peripheral doesn't support LCD
> readback.  The first change changes the poll rate from once to four times
> per second, which greatly improved the response when I was scrolling
> through menus really fast.  However, it's probably not worth actually
> putting in, because I expect most people wouldn't need this level of
> responsiveness given the extra overhead it introduces, and IIRC you
> previously indicated some reason (debugging?) why you didn't want it to
> poll more than once per second anyway.
>

The patch installed ok, but it gave two error messages:
patch unexpectedly ends in middle of line
patch unexpectedly ends in middle of line

xojpanel compiles runs fine with the patch.

Early in development, the printer poll timer controlled scroll speed as well, 
so to cut down on unnecessary console output during testing, I set it as high 
as 3000ms (if I remember correctly). Now that the timers are separate, that 
reason is gone. The poll timer can be set lower than 1000ms. Are there any 
network delay issues to consider in setting the timer? For instance, if an 
lcd message is changing in the printer, but it's being polled too often, the 
wrong message might get to xojpanel first. Could this happen?

Overhead doesn't seem to be a big problem with xojpanel. It seems to use a 
lot of memory, but little processor time. top -p says that most of the time 
its CPU usage is 0.0%. The timer is set at 500ms for now, though.


> I'm glad you added the license statement at the top of the files, but you
> might want to add a copyright message, similar to what I did in the ptal
> and ieee12844 directories.  If you do this then it would be proper to also
> include a copyright for the original author, which I think was Andreas
> Fester.  (Is this correct, Andreas?  And what copyright year should be
> given for you?)

I'll put a copyright notice in, with credit for anyone who contributed to the 
remaining parts of the original xojpanel, if the contributors can be 
identified. If not, I'll give generic credit. It might be important to know 
the origin of the name 'xojpanel'. Andreas' response should be helpful. 

>
> When should I start putting this into CVS?  Once I do, then it would be
> preferable for additional changes to be made available as patches to
> hpoj-devel, even if you continue to provide a downloadable package on your
> website.
>
> Am I correct in assuming that the only file I should remove from CVS is
> lcd.bmp?  For the new files you provide, should I include
> CHANGES-xojpanel_jsp (possibly renamed to just "CHANGES")?  It might be
> easier to let the CVS checkin comments serve as the changelog.  What about
> xojpanel.kdelnk (maybe?) and .directory (probably not)?
>
> David

Hopefully, the copyright issue will be solved soon, so waiting a day or so 
before committing the new xojpanel code to CVS will probably make one patch 
unnecessary. 

Handle the changelog whichever way you think is best.

You won't need .directory for anything. I probably should have deleted that. 
lcd.bmp is no longer used or even very usable, due to a size difference. You 
can leave both of them out.

A KDE user could copy xojpanel.kdelnk to his/her desktop for a quick way to 
start the app. Many users may prefer to create their own launchers, but some 
don't know how, or don't want to go to the trouble. The addition of a GNOME 
launcher might be nice later on. I have only an older version of GNOME and 
haven't used it in a while, so I wasn't that interested in making one right 
away.


-- 
Joe