To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cad.devOpen lugnet.cad.dev in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / Development / 4623
4622  |  4624
Subject: 
Re: LDLITE cache limit bug (Was Apollo lunar module)
Newsgroups: 
lugnet.cad.dev
Date: 
Fri, 28 Apr 2000 17:00:33 GMT
Viewed: 
606 times
  
In lugnet.cad.dev, Don Heyse writes:
In lugnet.cad.dev, Steve Bliss writes:
LDLite has always been slightly flakey on MPD files.  I think v1.6 is
better than v1.5, but I'm not in a position to make absolute statements--I
use L3Lab these days.

Heh, um, I also use L3Lab nowadays, actually. :)
LDLite v1.6 is better than 1.5 at MPD files.

Yeah, this is a caching bug in the ldlite parser. • [...]
Unfortunately I really don't know what I'm doing with the lex parsing code
in ldlite so I can't make a "good" fix.  Here's the change I made.


You did it the right way.  Actually, the log output should show warnings
about files not being cached, although it does not mention how fatal
this is for MPD files.  LDLite uses fixed-size
allocations because I still cling to the hope of getting it running
on a small hand-held device, one with enough FLASH space for the
LDRAW .dat files, and only enough RAM for the zbuffer and tiny caches.

The "right way" to fix this is to make the cache sizes configurable
from the command line or ini settings, changing the static arrays to
pointers that are malloc'd once at start-up time. Or automatically
grow the caches when needed.

// caching lex defines
#if TOO_SMALL_FOR_BIG_MPD_FILES
#define MAX_CACHED_TOKENS (3*1024)
#define MAX_MPD_CACHED_TOKENS (8*1024)
#define MAX_CACHED_FILES  (12*128)
#else
#define MAX_CACHED_TOKENS (10*1024)
#define MAX_MPD_CACHED_TOKENS (16*1024)
#define MAX_CACHED_FILES  (24*128)
#endif

Perhaps I'll play with it some more, or maybe Paul could fix it the right
way for the next version of ldlite...

Don



Message is in Reply To:
  LDLITE cache limit bug (Was Apollo lunar module)
 
(...) at (...) works), (...) Yeah, this is a caching bug in the ldlite parser. I get the same problem in ldglite when I use the ldlite parser, but not with the L3 parser. I think it's because one of the caching structures is full before it gets (...) (24 years ago, 27-Apr-00, to lugnet.cad.dev)

20 Messages in This Thread:







Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR