[Caml-list] file close bug?

[Caml-list] file close bug?

[skaller]

The following code has worked for some time:

try (* to write Marshalled parse tree out *)
  let x = open_out_bin pf in
  Marshal.to_channel x (this_version,sts) [];
  close_out x
with _ -> () (* can't write, don't worry *)

Now, I have modified my program to use some specialised
hashtable types using address comparisons on part of the keys.
My largest test case now fails to terminate (weird!, it worked
before with polymorphic comparison ..) but I can kill it with Ctrl-C.

What's weird is that if I rerun it, it tries to reload
the Marshalled data above, and gets an End_of_file error,
indicating the whole file was not written out. 

However,when I run another program which doesn't get up to 
the use of the new hashtbles, and so terminates, the whole
file *is* being correctly written out (by the same piece of code).

This looks like a flushing/closing problem in Ocaml?
[Just because the program aborted should not prevent
a *closed* file's buffers being written to disk ..]

There's been some talk about this in other circumstances?
Is this a known problem?

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] file close bug?

[skaller]

On Mon, 2004-06-28 at 02:21, skaller wrote:
> The following code has worked for some time:

Oops. The file is not being written
because the Marshal is failing because I changed 
Big_int type to be wrapped in a class so it would
hash quickly .. Marshal may not like classes?
Any other suggestions?

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] file close bug?

[skaller]

On Mon, 2004-06-28 at 02:33, skaller wrote:
> Marshal may not like classes?

Invalid_argument("output_value: functional value")

Arggg. Its a class, not a functional value ..

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] file close bug?

[William Lovas]

On Mon, Jun 28, 2004 at 02:45:28AM +1000, skaller wrote:
> On Mon, 2004-06-28 at 02:33, skaller wrote:
> > Marshal may not like classes?
> 
> Invalid_argument("output_value: functional value")
> 
> Arggg. Its a class, not a functional value ..

... which is just a bunch of functions wrapped together :)

Isn't this what the Closures flag was implemented for?

cheers,
William

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] file close bug?

[skaller]

On Mon, 2004-06-28 at 05:04, William Lovas wrote:
> On Mon, Jun 28, 2004 at 02:45:28AM +1000, skaller wrote:
> > On Mon, 2004-06-28 at 02:33, skaller wrote:
> > > Marshal may not like classes?
> > 
> > Invalid_argument("output_value: functional value")
> > 
> > Arggg. Its a class, not a functional value ..
> 
> ... which is just a bunch of functions wrapped together :)

I'm not using it for that. I have a conflict: I need to marshal
a data structure containing bignums out, and, I need to put
it in a Hashtabl which won't work with bignums because 
polymorphic equal fails on abstract types.

I wrapped the bignums in a class just to get a comparable id.
Now I can't marshal it :(

> Isn't this what the Closures flag was implemented for?

I'm using native code.. and I don't want to output any
functions. All I want is the bignums to be treated 
like an address for comparison, but written out as a value
when marshalling..

It seems the only way to do this is to write an equal function
for my terms... anyhow i just deleted the caches .. more grief
than they wre worth, and didn't seem to speed anything up anyhow.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] file close bug?

[Jon Harrop]

On Sunday 27 June 2004 20:42, skaller wrote:
> ...
> I wrapped the bignums in a class just to get a comparable id.
> Now I can't marshal it :(

Unless you're marshalling a hashtable of big nums, can you not just wrap the 
big nums in a class temporarily while they're being hashed?

Incidentally, is it possible to flag to these kinds of functions that you want 
them to skip functional values rather than bail on them?

Cheers,
Jon.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] file close bug?

[skaller]

On Mon, 2004-06-28 at 06:15, Jon Harrop wrote:
> On Sunday 27 June 2004 20:42, skaller wrote:
> > ...
> > I wrapped the bignums in a class just to get a comparable id.
> > Now I can't marshal it :(
> 
> Unless you're marshalling a hashtable of big nums, can you not just wrap the 
> big nums in a class temporarily while they're being hashed?

No. The bignum represent integers in expressions.
I'm marshalling the whole input parse tree in a single line
as shown in the code I gave.

The hashtable was mapping expressions to bound expressions
(ones for which lookup is done annotated with a bound type) 
because that can be done multiple times .. and the algorithm
is purely functional and doesn't record any partial results
for subsequent evalulations.

This complexity arises in Felix because it supports several
advanced features: there's an open directive like Ocaml's
except that there is no hiding or ordering, functions are
overloaded, there is a typeof(e) term, everything is mutually
recursive, and function returns and values have their types
deduced. Polymorphism is also supported (everything is done
in the presence of type variables some of which can be
bound in a call by unification).

Altogether that means the type of an expression
may depend on almost arbitrary other pieces of code than
itself, and so to bind and type it may require binding
and typing those other pieces of code too .. but the result
of those extra evaluation is simply lost at that time,
and recalculated again when needed.

Even binding recursively may not work where the current
algorithm does, since for example to find the return
type of a function only requires binding its signature
and some of the return values (and not the other 
code in the function). Caching partial results is itself
problematic since some types are recursive: Felix doesn't
use fixpoint binder terms, only fixpoints of kind Fix n
where n is the number of 'levels' up in the term structure
the binder would be.. so some sub-terms are incomplete during
construction and mustn't be cached.

Lookup/binding accounts for 80% of all the compiler time,
which is why I'm trying to optimise it. My guess is that
the algorithm is exponential time: if everything was done
only once it would clearly be linear. Almost all the time
seems to be taken doing Hashtbl.find on integer keys,
which I use to represent entities (binding just maps their 
names to integers or to Fix term for recursive types).

Caching type terms seems to make a tiny difference,
caching expressions actually stopped the compiler working
altogether in one case (only) for an unknown reason.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners