Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mit-eddie!snorkelwacker.mit.edu!ai-lab!rice-chex!bson From: bson@rice-chex.ai.mit.edu (Jan Brittenson) Newsgroups: comp.sys.handhelds Subject: Re: Chip question Message-ID: <12305@life.ai.mit.edu> Date: 9 Dec 90 00:55:37 GMT References: <1990Dec8.101737.19776@jarvis.csri.toronto.edu> <10031@jarthur.Claremont.EDU> Sender: news@ai.mit.edu Organization: nil Lines: 20 In article <10031@jarthur.Claremont.EDU> sburke@jarthur.Claremont.EDU (Scott Burke) writes: > THe problem is, I can't FIND any correlation between the apparent > state of my machine and whether or not CHIP decides to work. I have written several programs that exhibit the same behaviour. The problem, as far as I can tell, occurs in all programs that use a certain scheme to allocate strings. My (very poorly founded) guess is that the problem arises when a GC is performed. Call MEM DROP before calling CHIP (or at some other tactic point) - this will make it less likely for a GC to occur while CHIP allocates its data. Also try disabling LAST STACK when using CHIP. I'm not exactly sure how the LAST STACK and GC interact, but LAST STACK has given me funny results with CHIP and other programs that use similar allocation schemes. To be more specific, the sequence FOOGAME CHIP [LAST STACK] CHIP will sometimes yield unexpected results.