Re: A nasty inefficieny in file.c?

2006-07-17 Thread Linus Nielsen Feltzing
Bill Janssen wrote: Why doesn't the sector buffer in the "readwrite" function already do the necessary buffering? The sector buffer in the readwrite function does the buffering, and it works perfectly fine. The "nasty inefficiency" in this special case is that readline reads 1 byte at a time

Re: A nasty inefficieny in file.c?

2006-07-17 Thread Bill Janssen
Doesn't crash, but things don't seem to work quite right, either. Needs more work. Why doesn't the sector buffer in the "readwrite" function already do the necessary buffering? Bill > On 18/07/06, Bill Janssen <[EMAIL PROTECTED]> wrote: > > > In any case, the read_line() inefficiency is not a b

Re: A nasty inefficieny in file.c?

2006-07-17 Thread Bill Janssen
I'm using the libsdl simulator on Mac OS X 10.4. I didn't try to apply your modified read_line(); I just used the one in CVS. > you mean it worked? > I only just got sdl installed so i never actuall tested it properly > and it cashed on my player! OK, I'll try it and report back. Bill

Re: A nasty inefficieny in file.c?

2006-07-17 Thread Jonathan Gordon
On 18/07/06, Bill Janssen <[EMAIL PROTECTED]> wrote: > In any case, the read_line() inefficiency is not a big deal. It is only > used to read config files and stuff, and that isn't really critical. If you build it, people will use it. I wrote a plugin last week that used it. you mean it worked

Re: A nasty inefficieny in file.c?

2006-07-17 Thread Bill Janssen
> In any case, the read_line() inefficiency is not a big deal. It is only > used to read config files and stuff, and that isn't really critical. If you build it, people will use it. I wrote a plugin last week that used it. I liked the rewrite Jonathan posted. Bill

Re: Bit hacking

2006-07-17 Thread Dan Everton
Speaking of trimming cycles, whatever happened to the profiler patch? Is that still actively developed? Dan

Re: Bit hacking

2006-07-17 Thread [EMAIL PROTECTED]
Fascinating stuff. Well worth reading. But many of the tricks have notes indicating that they invoke undefined behavior according to the C Standard, or that their efficiency depends on the target system's assembly language And in all cases, there's a more straightforward way to do these thin

Re: closing old bug reports?

2006-07-17 Thread Linus Nielsen Feltzing
Zakk Roberts wrote: It's saying that this ought to be fixed, nobody's arguing that, so let's get it out of the way of the real bugs, and if it does happen to show up later, we can open a new one. I agree. It's not that we close them as "fixed". We close them as "Out-of-date" because of lack of

Re: closing old bug reports?

2006-07-17 Thread Zakk Roberts
I think it should certainly be closed. For one, work must have been done to alleviate the problem. Secondly, the person who's asking "is it fixed yet?" must have tried and been unable to reproduce it. Thirdly, nobody's commenting, so leaving it open is just kind of "it should be fixed but we don'