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