Hi Mark Green, I'm no longer working on Hugs so the following is based on my memory of how things work and I'm copying this message to hugs-bugs. I think what you've found is a flaw in the documentation rather than a bug in the system. The problem is that compileExpr (and any other functions which invoke the compiler) allocates a bunch of things which are required during evaluation (Names (sometimes used to represent functions) and Texts (used to represent strings and program identifiers)). If Hugs had been written with the intention of supporting compileExpr, we might have written the garbage collector in such a way that these objects were only kept alive by the HVal reference returned from compileExpr and so freeHVal would have released them. But that isn't the case, the Hugs Server was added long after the system was first written and changing the garbage collector to automatically collect the Names and Texts wasn't feasible. In short, your "workaround" is the recommended programming style and the documentation should make it clear that you need to use reset both with loadFile and compileExpr. [btw note the warning at the end of section 6 that HVals may be invalidated by calling reset. This is a very real problem and should probably be reworded as "will be invalidated, using them will cause your program to crash".] -- Alastair Reid [EMAIL PROTECTED] http://www2.cs.utah.edu/~reid/ ps I must admit I'm a bit surprised that you're using machine generated Haskell with hand-written Java. I find that Haskell (with its polymorphism, overloading, higher-order functions, etc) is much, much more flexible than Java and would tend to do things the other way: use hand-written Haskell to machine-generate Java code. Mark Green <[EMAIL PROTECTED]> writes: > I am presently using the Hugs server in my research for providing the > link between a Java front-end and a back-end consist of Haskell code > automatically generated from a user specification. > I have discovered what appears to be a bug in the Hugs Server. Although > my examples refer to Java, I have checked that the bug applies equally when > the code is invoked from C. > It would appear that Haskell's "number of scripts loaded" counter is > incremented by one every time compileExpr() is called. Using freeHVal() on > the return does not fix this. Also, the return from getNumScripts() does > not change - it still returns the actual number of script files loaded via > loadFile(). However, when the sum of the number returned by > getNumScripts() and the number of compileExpr() calls so far exceeds 100, > any further calls to Haskell result in an error, "Too many script files in > use". > This can be worked around by calling reset(getNumScripts()) any time > before the final call to compileExpr() that would trigger the failure > condition. This resets the counter without unloading any scripts.
