[Caml-list] Is it really a non issue?

[Caml-list] Is it really a non issue?

[malc]

I noticed that my bug report was silently moved to 'not a bug'
section. Despite report's subject 'Not a bug, but...' i do think its
atleast an issue. Consider this:

file a.ml:
let a = 1

file a.mli:
val a : int \
val a : int  |
...........  | n times 
val a : int  |
val a : int /


After compilation/linking we will get huge .cmi and binary with data
section (n-1)*4(on 32bit architectures) bytes bigger that it should have
been. Current ocamlopt.opt is 12 bytes bigger due to redundant declartions
in bytecomp/lambda.mli(is_guarded,patch_guarded) and
utils/clflags.ml(dump_scheduling), not a big deal but still anoying.

-- 
mailto:malc@pulsesoft.com

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Is it really a non issue?

[Xavier Leroy]

> I noticed that my bug report was silently moved to 'not a bug'
> section.

Yes, because I consider that it is not a bug.

> Despite report's subject 'Not a bug, but...' i do think its
> atleast an issue.

I don't.  End of discussion.

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Is it really a non issue?

[Luc Maranget]

> 
> 
> I noticed that my bug report was silently moved to 'not a bug'
> section. Despite report's subject 'Not a bug, but...' i do think its
> atleast an issue. Consider this:
> 
> file a.ml:
> let a = 1
> 
> file a.mli:
> val a : int \
> val a : int  |
> ...........  | n times 
> val a : int  |
> val a : int /
> 
> 
> After compilation/linking we will get huge .cmi and binary with data
> section (n-1)*4(on 32bit architectures) bytes bigger that it should have
> been. Current ocamlopt.opt is 12 bytes bigger due to redundant declartions
> in bytecomp/lambda.mli(is_guarded,patch_guarded) and
> utils/clflags.ml(dump_scheduling), not a big deal but still anoying.


This is probably an issue, but I do not think it is related to the
previous post on records.

At least, we should get those nasty 12 bytes back !

Thank you for your issue report (:->)

--Luc

PS> I guess I can understand Xavier, sometimes some people complain
about so-called bugs which are in facts features, and for features
such as the ``cannot use record labels as I would have wished to'' it
is just too often.

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Is it really a non issue?

[Jeremy Fincher]

> > file a.mli:
> > val a : int \
> > val a : int  |
> > ...........  | n times 
> > val a : int  |
> > val a : int /
> 
> At least, we should get those nasty 12 bytes back !

Wouldn't the most appropriate way to get those 12 bytes back be to remove the redundant data from the .mli file?

Jeremy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr