1. Bug in read_bitmap?
I'm trying to read a lot of bitmaps from disk with "read_bitmap".
After reading ten (10) of them, I get an error telling I've open too many
files.
Does anybody know if read_bitmap does close the bitmap after reading it?.
Jesus-trying-the-resources-issue.
2. Re: Bug in read_bitmap?
At 05:58 PM 6/17/98 +0200, Jesus wrote:
>I'm trying to read a lot of bitmaps from disk with "read_bitmap".
>After reading ten (10) of them, I get an error telling I've open too many
>files.
>Does anybody know if read_bitmap does close the bitmap after reading it?.
Yes, read bitmap closes the file after
reading it, however it appears it dosn't
close the file after NOT reading it
(i.e. when returning an unsupported
format error).
The fix is simple; insert "close(fn)"
before each of the
"return BMP_UNSUPPORTED_FORMAT"
lines in the read_bitmap() function,
in image.e
I wonder how this one slipped through after
so long?
Graeme.
----------------------------------------------------
3. Bug in read_bitmap?
Jesus,
In your CONFIG.SYS file, set files to a higher number.
--Alan
=
4. Re: Bug in read_bitmap?
Jesus writes:
>I'm trying to read a lot of bitmaps from disk with "read_bitmap".
>After reading ten (10) of them, I get an error telling I've open too
> many files.
>Does anybody know if read_bitmap does close the bitmap after reading it?.
Graeme writes:
> Yes, read bitmap closes the file after
> reading it, however it appears it dosn't
> close the file after NOT reading it
> (i.e. when returning an unsupported
> format error).
> The fix is simple; insert "close(fn)"
> before each of the
> "return BMP_UNSUPPORTED_FORMAT"
> lines in the read_bitmap() function,
> in image.e
> I wonder how this one slipped through after
> so long?
Thanks Jesus and Graeme.
I'll fix read_bitmap() for the next release.
It has been that way since v1.3 (3 years ago) and no one
has reported the problem until now. I guess not many
programs open multiple bitmap files
that exist, but are in an unsupported format.
While we're on the subject of bugs, here's one I
encountered yesterday:
If your program executes trace(1) in a section of code that
was not compiled "with trace", nothing will appear to happen,
but the get_key() function will start delaying 8 seconds
on each call, whether there's a key to read or not. Normally,
if you do have "with trace", then trace(1) will open the
interactive trace screen and the 8 second delay on get_key()
is what is supposed to happen, to give you a
chance to enter a keystroke for testing purposes.
This bug might show up as a program that suddenly
seems to "hang" or run extremely slowly compared to normal,
after you start inserting trace() statements.
This will also be fixed for the next release.
Regards,
Rob Craig
Rapid Deployment Software
5. Re: Bug in read_bitmap?
It's windows NT, no way.
Jesus.
>
> Jesus,
>
> In your CONFIG.SYS file, set files to a higher number.
>
6. Re: Bug in read_bitmap?
- Posted by Robert Craig <rds at EMAIL.MSN.COM>
Jun 17, 1998
-
Last edited Jun 18, 1998
Alan Tu writes:
> In your CONFIG.SYS file, set files to a higher number.
Jesus writes:
> It's windows NT, no way.
Euphoria has a limit of 12 open files.
This is quite distinct from the limit that DOS imposes.
Probably Jesus ran into Euphoria's limit, when he called
read_bitmap() many times on unsupported-format
bitmap files (see my earlier message). Euphoria's limit
could easily be raised, but no one seems to be
complaining about it.
Regards,
Rob Craig
Rapid Deployment Software
