1. seek() bug?
I think i found a seek() bug.
This doesn't work:
junk_i = seek(indexfile,junk_i)
This does:
seek_i = seek(indexfile,junk_i)
The program snippet is:
-- now open the index.noun and correct all the lines there too
indexfile = open(index_noun,"u")
readline = gets(indexfile)
while not atom(readline) do
newreadline = replace(readline,origindex_s,realindex_s)
if not equal(newreadline,readline) then
trace(1)
junk_i = where(indexfile)
junk_i = junk_i - length(readline) - 1
seek_i = seek(indexfile,junk_i)
junk_i = where(indexfile)
puts(indexfile,newreadline)
end if
readline = gets(indexfile)
end while
close(indexfile)
I kept breaking up the operations in junk_i, and finally replaced junk_i with
seek_i as the seek() assignee, and it worked. Why is this?
Kat
2. Re: seek() bug?
Kat writes:
> This doesn't work:
> junk_i = seek(indexfile,junk_i)
> This does:
> seek_i = seek(indexfile,junk_i)
Both of these are syntactically incorrect.
seek() takes 2 arguments, so you need a comma.
Maybe in the heat of battle, you corrected the syntax error
along with changing the name of the result variable.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: seek() bug?
Kat writes:
> This doesn't work:
> junk_i = seek(indexfile,junk_i)
> This does:
> seek_i = seek(indexfile,junk_i)
That's weird.
In Outlook Express the first two commas in your message
are invisible, even in my reply, while all the other ones are visible,
but if I save the message as a .eml file and examine it,
all the commas are there. They also appear on the
Web interface at Topica.
I guess I don't know then what your problem was.
Perhaps I should report it to Microsoft - no, wait -
the last time I reported a bug to Microsoft
they charged the company I was working for
$200 U.S. just to confirm that, yes, you've found
a new Microsoft bug.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
4. Re: seek() bug?
On 14 Feb 2002, at 17:09, Robert Craig wrote:
>
> Kat writes:
>
> > This doesn't work:
> > junk_i = seek(indexfile,junk_i)
>
> > This does:
> > seek_i = seek(indexfile,junk_i)
>
> Both of these are syntactically incorrect.
> seek() takes 2 arguments, so you need a comma.
> Maybe in the heat of battle, you corrected the syntax error
> along with changing the name of the result variable.
But there ARE commas there! The comma looks like it's part of the 'j' in
some fonts.
",j" = ',' & 'j'
inserting spaces, it looks like:
This doesn't work:
junk_i = seek(indexfile , junk_i)
This does:
seek_i = seek(indexfile , junk_i)
Looks like using the same var in the arguement as the assignee breaks
something?
Kat
5. Re: seek() bug?
On 14 Feb 2002, at 17:41, Robert Craig wrote:
>
> Kat writes:
> > This doesn't work:
> > junk_i = seek(indexfile,junk_i)
> > This does:
> > seek_i = seek(indexfile,junk_i)
>
> That's weird.
> In Outlook Express the first two commas in your message
> are invisible, even in my reply, while all the other ones are visible,
> but if I save the message as a .eml file and examine it,
> all the commas are there. They also appear on the
> Web interface at Topica.
>
> I guess I don't know then what your problem was.
The seek didn't goto junk_i in the non-working code, it went to the start of the
file, position zero (or one, depending on how you look at it). The where() in
the line after that reported different positions.
> Perhaps I should report it to Microsoft - no, wait -
> the last time I reported a bug to Microsoft
> they charged the company I was working for
> $200 U.S. just to confirm that, yes, you've found
> a new Microsoft bug.
Ummm,, are you asking for tech support money?
Kat
6. Re: seek() bug?
Kat writes:
> The comma looks like it's part of the 'j' in some fonts.
Yes, I can see that now.
With the font I'm using, the comma is only about 2 pixels.
It extends the hook on the j a tiny bit, rather than
appearing as a separate character.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
7. Re: seek() bug?
On 14 Feb 2002, at 21:55, Robert Craig wrote:
>
> Kat writes:
> > The comma looks like it's part of the 'j' in some fonts.
>
> Yes, I can see that now.
> With the font I'm using, the comma is only about 2 pixels.
> It extends the hook on the j a tiny bit, rather than
> appearing as a separate character.
Well, i'm so glad that is solved. <sigh> Clinton argued over the meaning of
"is", but we are still on individual chars. <sigh>
Now, after working on seek() and where() for 3 days, the puts() is still not
puts()ing where i told the program to seek() to. Both gets()ing and then
where()ing and subtracting the length(readline)+1 , or where()ing and then
gets()ing,, the seek()ing *seems* to work, but the puts() lands 100's or
1000's or 10,000's of bytes in the wrong place. I can't see how the puts()
lands so far away, when length(readline) = 30. Seek() was a wonderful tool in
pascal for not get()ing 50meg files, and now i need to do() that in Eu.
So is there a buglist for seek? Is seek() maybe allergic to long filenames, or
filenames with sp aces in them?
Jeffrey Fielding's WIN32FIL.EW saved my tail yesterday. Little things like
being able to access files is handy. <sigh> Perhaps there is a seek() in
kernal32.dll i should be using? How? This should be native Eu code, how is a
newbie to programming to find these things?
Kat
8. Re: seek() bug?
Kat writes:
> So is there a buglist for seek?
There aren't any known bugs in seek().
EDS uses seek() extensively, and there aren't
any known bugs in EDS either.
> Is seek() maybe allergic to long filenames, or
> filenames with sp aces in them?
The file name is irrelevant to seek(), but
there are some potential "gotchas".
1. It's strongly recommended that you open the file in binary mode,
"rb", "wb" or "ub". (otherwise \r\n is secretly converted to \n by the o/s,
and you'll go crazy trying to set the file position correctly)
2. Opening in append mode, "a" is possibly a bit dicey.
A bug was fixed in 2.3 official in that case because of
a Watcom bug.
3. The Euphoria manual states:
"After seeking and reading (writing) a series of bytes, you may
need to call seek() explicitly before you switch to writing
(reading) bytes, even though the file position should already be
what you want."
If you can reduce the problem to something small, but runnable,
and post it here, maybe we can see the problem.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
9. Re: seek() bug?
On 15 Feb 2002, at 15:58, Robert Craig wrote:
>
> Kat writes:
> > So is there a buglist for seek?
>
> There aren't any known bugs in seek().
> EDS uses seek() extensively, and there aren't
> any known bugs in EDS either.
>
> > Is seek() maybe allergic to long filenames, or
> > filenames with sp aces in them?
>
> The file name is irrelevant to seek(), but
> there are some potential "gotchas".
>
> 1. It's strongly recommended that you open the file in binary mode,
> "rb", "wb" or "ub". (otherwise \r\n is secretly converted to \n by the
> o/s,
> and you'll go crazy trying to set the file position correctly)
>
> 2. Opening in append mode, "a" is possibly a bit dicey.
> A bug was fixed in 2.3 official in that case because of
> a Watcom bug.
>
> 3. The Euphoria manual states:
> "After seeking and reading (writing) a series of bytes, you may
> need to call seek() explicitly before you switch to writing
> (reading) bytes, even though the file position should already be
> what you want."
>
> If you can reduce the problem to something small, but runnable,
> and post it here, maybe we can see the problem.
I did, but you missed the ',' remember?
Kat
10. Re: seek() bug?
Kat and Robert,
I can confirm that there is a bug somewhere in Euphoria's handling of
puts(), gets(), seek(), and where() when using a file opened for either "u"
or "ub".
Here is the sample code I used to confirm it. It converts a text file into
all 'A' so its not practical except to demonstrate this bug.
If you run it with anthing on the command line, it works. The trick to
making it work is that I reset the file position using seek() AFTER I do a
puts().
I don't understand why this works, because I used seek() and where() often
in the past without problems.
--------------
include file.e
include get.e
without warning
with trace
trace(1)
sequence index_noun
integer indexfile
object readline
object newreadline
object env
atom junk_i, seek_i, junk_j, junk_k
env = command_line()
index_noun = "sample.f"
indexfile = open(index_noun,"ub")
readline = gets(indexfile)
while not atom(readline) do
-- generate a line the same length as the current one.
newreadline = repeat('A', length(readline)-2) & 13 & 10
-- Find out where I am
junk_k = where(indexfile)
-- Calc the posn of the START of the line just read in
junk_i = junk_k - length(readline)
-- Move to the start of the line
seek_i = seek(indexfile,junk_i)
-- confirm that it worked
junk_i = where(indexfile)
-- Replace the line with generated one
puts(indexfile,newreadline)
if length(env) > 2 then
-- Works if this line is executed.
seek_i = seek(indexfile, junk_i + length(newreadline))
end if
-- See if I now where I should be
junk_j = where(indexfile)
-- read next line
readline = gets(indexfile)
end while
close(indexfile)
--------------
Derek
----- Original Message -----
From: "Kat" <gertie at PELL.NET>
To: "EUforum" <EUforum at topica.com>
Sent: Friday, February 15, 2002 9:33 AM
Subject: Re: seek() bug?
>
> On 15 Feb 2002, at 15:58, Robert Craig wrote:
>
> >
> > Kat writes:
> > > So is there a buglist for seek?
> >
> > There aren't any known bugs in seek().
> > EDS uses seek() extensively, and there aren't
> > any known bugs in EDS either.
> >
> > > Is seek() maybe allergic to long filenames, or
> > > filenames with sp aces in them?
> >
> > The file name is irrelevant to seek(), but
> > there are some potential "gotchas".
> >
> > 1. It's strongly recommended that you open the file in binary mode,
> > "rb", "wb" or "ub". (otherwise \r\n is secretly converted to \n by
the o/s,
> > and you'll go crazy trying to set the file position correctly)
> >
> > 2. Opening in append mode, "a" is possibly a bit dicey.
> > A bug was fixed in 2.3 official in that case because of
> > a Watcom bug.
> >
> > 3. The Euphoria manual states:
> > "After seeking and reading (writing) a series of bytes, you may
> > need to call seek() explicitly before you switch to writing
> > (reading) bytes, even though the file position should already be
> > what you want."
> >
> > If you can reduce the problem to something small, but runnable,
> > and post it here, maybe we can see the problem.
>
> I did, but you missed the ',' remember?
>
> Kat
>
>
>
>
11. Re: seek() bug?
Derek Parnell writes:
> I can confirm that there is a bug somewhere in Euphoria's handling of
> puts(), gets(), seek(), and where() when using a file opened for either "u"
> or "ub".
OK, Thanks for the example.
I think I see the problem.
Your code and Kat's code seem to be falling into the little trap
that I mentioned in my previous post:
> 3. The Euphoria manual states:
> "After seeking and reading (writing) a series of bytes, you may
> need to call seek() explicitly before you switch to writing
> (reading) bytes, even though the file position should already be
> what you want."
I discovered this a couple of years ago, and I originally thought it
was due to some kind of bug in Watcom, but it seems to happen
with all the C compilers (tested using the Translator).
I'm not doing much in Euphoria, other than passing the seek
and puts/gets info to the C routines, so it seems to be a quirk in C.
So the rule is: when switching between reading the file and
writing the file, do an explicit seek() to set the file pointer.
I also tried calling flush() and that also works in this case.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
