Re: ivtools

[Scott J. <joh...@ve...>]

I had no idea idraw/Unidraw was using a temp file to implement that 
capability (and I've been studying this source for ten years).  You 
clearly showed me a hole in my knowledge.

That said, this is something that has worked without problem (and 
without any changes to the source code) for as long as I can 
remember.  I have a suspicion it is due to a change in behavior of 
the iostreams capability, the most volatile component.  But it would 
take time to prove this, and to figure out a workaround.  Time I 
don't have at the moment, and I doubt you'll find any volunteers on 
this mailing list to do it for you.

So you have two options.  Either figure out how to fix it yourself, 
then submit any relevant patch, and I'll make sure to include it in 
the next release of ivtools.  You seem to have a good start on 
understanding the problem.  Perhaps this is useful learning activity 
for you.  Or enter it as a bug or support request at the ivtools 
SourceForge project page (http://sf.net/projects/ivools), so we have 
a record of it for future reference.

Scott

p.s. I would be curious if you have same problem using ivtools drawtool.


>Hi Scott,
>
>Thanks for your reply.
>More details about the ivtools problem.
>
>I am using idraw. I figured out that everytime I do a simple "group" of two
>lines and then "duplicate" the group, there is an error message "Unidraw
>error: couldn't copy object (/tmp unwritable?)", which comes from
>Catalog::RetrieveObject in src/Unidraw/catalog.c. The function will create a
>tmp file in /tmp, and write something in.
>
>Then I traced into the source code. In Catalog::RetrieveObject, ReadObject
>will be called. I checked in.good() of the istream(in) that corrsponds to
>the filebuf of the tmp file (something like /tmp/.udcpAAA4dayEO) in a couple
>of places in the funcition, and then found that
>Catalog::ReadBgfilled()
>is the place where in.good() turns 0.
>
>The tmp files is as follows:
>---------------------------------------------------------------------
>%I Unidraw 1
>%I 9025 661760 0 2
>
>%I 1002 256976 9030 %END_ARROWLINE_COMP% 77 305 122 306
>%I 1
>%I c Black 0 0 0
>%I c White 1 1 1
>%I b 65535 0
>%I t 1 -0 -0 1 143 183 0 0 1
>%I p n %END_ARROWLINE_COMP%
>
>%I 1002 643920 9030 %END_ARROWLINE_COMP% 90 320 132 294
>%I 1
>%I c Black 0 0 0
>%I c White 1 1 1
>%I b 65535 0
>%I t 1 -0 -0 1 143 183 0 0 1
>%I p n %END_ARROWLINE_COMP%
>
>%I 4294967295
>%I b ~ (the line was read by ReadBgFilled, and in<<bgFilled will return a
>value other than 0 and 1)
>%I c ~
>%I c ~
>%I f ~
>%I p ~
>%I t ~
>%I 0
>%I 0
>----------------------------------------------------------------------------
>-------
>
>The function ReadBgFilled should read the second line of each section in the
>temp file (%I 1) and set the variable bgFilled to 0 or 1.
>For some reason, the ReadBgFilled will set bgFilled to a value of 149168,
>after two correct ReadBgfilled() for those two lines that need to be grouped
>and duplicated.  Note that bgFilled is a boolean type variable.  Since the
>first two ReadBgFilled call were OK, I guess the incorrect value of bgFilled
>comes from the line "%I b ~" in the last section (%I 4294967295). It expects
>a 1 or 0 but there is b in the tmp file.
>
>Question: Why do we need the tmp file? What is the last section of the tmp
>file for?
>I suspect that the last section is correctly done(look at %I 4294967295)....
>There are only 2 exist components (lines) that need to be duplicated, so
>maybe the last section should not be there, and Catalog::ReadObject should
>only call ReadBgFilled twice.........
>
>Any idea?
>
>Thanks!
>
>-Pei