I wrote:
I am completely baffled. I thought I hada solved all my problems on MacOS X 10.6 and was just tidying up, when I had to recompile a 32 bit version of Poly/ML to test a tidied up make file. This failed because PolyML.Compiler.printTypesWithStructureName no longer exists. The same problem happened when i rebuild a 64 bit version. What has happened?
but it was a false alarm: my make file was wrong for other reasons and the absence of PolyML.Compiler.printTypesWithStructureName was not relevant. No doubt there are good reasons why this variable has been withdrawn.
Regards,
Rob.
Rob, Yes, I removed PolyML.Compiler.printTypesWithStructureName. 5.3 does a much better at trying to detect exactly what path is needed to identify a type and always tries to produce the minimal path. This isn't always easy or possible in the presence of sharing, type abbreviations and type and structure renaming since what it's trying to do is get back from the abstract "type name" that represents a unique type to a concrete type constructor that "carries" that type.
For example: Poly/ML 5.3 Enhanced Reporting Testing
structure S = struct datatype t = A val x = A end;
structure S : sig val x : t datatype t = A end (* x just has type t *)
val y = S.x;
val y = A : S.t (* Reports S.t as the path *)
open S;
datatype t = A val x = A : t (* Reports t because it's now in scope *)
x;
val it = A : t (* As above *)
type t = int; (* Redefine t *)
eqtype t
x;
val it = A : S.t (* Now reports S.t because t doesn't mean S.t *)
This makes it difficult to know what printTypesWithStructureName ought to do. Should it suppress all structure prefixes even if they're needed or add them on even if they're not? The simplest answer was to remove it. I could reinstate it for backwards compatibility if it would make things easier and simply ignore the value it has.
Regards, David
Rob Arthan wrote:
I wrote:
I am completely baffled. I thought I hada solved all my problems on MacOS X 10.6 and was just tidying up, when I had to recompile a 32 bit version of Poly/ML to test a tidied up make file. This failed because PolyML.Compiler.printTypesWithStructureName no longer exists. The same problem happened when i rebuild a 64 bit version. What has happened?
but it was a false alarm: my make file was wrong for other reasons and the absence of PolyML.Compiler.printTypesWithStructureName was not relevant. No doubt there are good reasons why this variable has been withdrawn.
David,
Thanks for the info. I don't have any code that needs PolyML.Compiler.printTypesWithStructureName.
Regards,
Rob.
Rob, Yes, I removed PolyML.Compiler.printTypesWithStructureName. 5.3 does a much better at trying to detect exactly what path is needed to identify a type and always tries to produce the minimal path. This isn't always easy or possible in the presence of sharing, type abbreviations and type and structure renaming since what it's trying to do is get back from the abstract "type name" that represents a unique type to a concrete type constructor that "carries" that type.
For example: Poly/ML 5.3 Enhanced Reporting Testing
structure S = struct datatype t = A val x = A end;
structure S : sig val x : t datatype t = A end (* x just has type t *)
val y = S.x;
val y = A : S.t (* Reports S.t as the path *)
open S;
datatype t = A val x = A : t (* Reports t because it's now in scope *)
x;
val it = A : t (* As above *)
type t = int; (* Redefine t *)
eqtype t
x;
val it = A : S.t (* Now reports S.t because t doesn't mean S.t *)
This makes it difficult to know what printTypesWithStructureName ought to do. Should it suppress all structure prefixes even if they're needed or add them on even if they're not? The simplest answer was to remove it. I could reinstate it for backwards compatibility if it would make things easier and simply ignore the value it has.
Regards, David
Rob Arthan wrote:
I wrote:
I am completely baffled. I thought I hada solved all my problems on MacOS X 10.6 and was just tidying up, when I had to recompile a 32 bit version of Poly/ML to test a tidied up make file. This failed because PolyML.Compiler.printTypesWithStructureName no longer exists. The same problem happened when i rebuild a 64 bit version. What has happened?
but it was a false alarm: my make file was wrong for other reasons and the absence of PolyML.Compiler.printTypesWithStructureName was not relevant. No doubt there are good reasons why this variable has been withdrawn.
Rob, Can I take it that the current SVN builds on Mac OS 10.6 without any extra options, although your Makefiles will have to add the -segprot option? I may need to ask you test it again if the official config.guess is updated to include support for 10.6.
Eventually I'd like to remove the need for -segprot but that will require making the code segment at least completely read-only. That in turn requires changes to profiling, data sharing and exporting all of which write to code objects.
Regards, David
rda@lemma-one.com wrote:
Rob Arthan wrote:
I wrote:
I am completely baffled. I thought I hada solved all my problems on MacOS X 10.6 and was just tidying up,
David Matthews <David.Matthews at ...> writes:
Rob, Yes, I removed PolyML.Compiler.printTypesWithStructureName. 5.3 does a much better at trying to detect exactly what path is needed to identify a type and always tries to produce the minimal path. This isn't always easy or possible in the presence of sharing, type abbreviations and type and structure renaming since what it's trying to do is get back from the abstract "type name" that represents a unique type to a concrete type constructor that "carries" that type.
For example: Poly/ML 5.3 Enhanced Reporting Testing
structure S = struct datatype t = A val x = A end;
structure S : sig val x : t datatype t = A end (* x just has type t *)
val y = S.x;
val y = A : S.t (* Reports S.t as the path *)
open S;
datatype t = A val x = A : t (* Reports t because it's now in scope *)
x;
val it = A : t (* As above *)
type t = int; (* Redefine t *)
eqtype t
x;
val it = A : S.t (* Now reports S.t because t doesn't mean S.t *)
This makes it difficult to know what printTypesWithStructureName ought to do. Should it suppress all structure prefixes even if they're needed or add them on even if they're not? The simplest answer was to remove it. I could reinstate it for backwards compatibility if it would make things easier and simply ignore the value it has.
Regards, David
Rob Arthan wrote:
I wrote:
I am completely baffled. I thought I hada solved all my problems on MacOS X 10.6 and was just tidying up, when I had to recompile a 32 bit version of Poly/ML to test a tidied up make file. This failed because PolyML.Compiler.printTypesWithStructureName no longer exists. The same problem happened when i rebuild a 64 bit version. What has happened?
but it was a false alarm: my make file was wrong for other reasons and the absence of PolyML.Compiler.printTypesWithStructureName was not relevant. No doubt there are good reasons why this variable has been withdrawn.
I am trying to install QCheck (http://contrapunctus.net/league/haques/qcheck/qcheck_2.html) which generates unit tests for SML code, and found that it uses printTypesWithStructureName in this way: ---------------------- PolyML.Compiler.printTypesWithStructureName := false; PolyML.print_depth 0; OS.FileSys.chDir "src"; PolyML.make "QCheck"; OS.FileSys.chDir "../tests"; use "from-to-str.sml"; use "from-to-poly.sml"; use "reverse.sml"; use "compose.sml"; ---------------------------- ...in order to check the installation...what should I use in place of
PolyML.Compiler.printTypesWithStructureName := false; ?
or can it just be removed with no consequences?
I tried just removing that first line, and the testcases do run, with 2 failures related to String/invalid and String/from-to (but those failures may have nothing to do with printTypesWithStructureName)
I am just doing a sanity check by asking if anyone has had experience with QCheck. -Dave Topham
On 26/12/2014 19:20, David Topham wrote:
I am trying to install QCheck (http://contrapunctus.net/league/haques/qcheck/qcheck_2.html) which generates unit tests for SML code, and found that it uses printTypesWithStructureName in this way: ...in order to check the installation...what should I use in place of
PolyML.Compiler.printTypesWithStructureName := false; ?
or can it just be removed with no consequences?
I tried just removing that first line, and the testcases do run, with 2 failures related to String/invalid and String/from-to (but those failures may have nothing to do with printTypesWithStructureName)
I am just doing a sanity check by asking if anyone has had experience with QCheck.
I hadn't come across QCheck so thanks for pointing it out. As a result of your message I tried it out and removed the printTypesWithStructureName line. It does report some errors which I don't think are anything to do with printTypesWithStructureName. I need to look more carefully to work out if these are in fact errors. From what I can tell so far it looks as though it is testing conversions between strings and integers and between strings and string-escapes. If there are errors they're likely to be pretty obscure.
Poly/ML does have some regression tests in the distribution which you can run using "make tests". If running the version from SVN make sure to rebuild the compiler first with "make compiler".
David
On 29/12/2014 12:11, David Matthews wrote:
On 26/12/2014 19:20, David Topham wrote:
I am trying to install QCheck I am just doing a sanity check by asking if anyone has had experience with QCheck.
I hadn't come across QCheck so thanks for pointing it out. As a result of your message I tried it out and removed the printTypesWithStructureName line. It does report some errors which I don't think are anything to do with printTypesWithStructureName. I need to look more carefully to work out if these are in fact errors. From what I can tell so far it looks as though it is testing conversions between strings and integers and between strings and string-escapes. If there are errors they're likely to be pretty obscure.
I've looked more closely at this and I believe the tests are wrong and that Poly/ML is actually correct. It looks as though the author of the tests believes that String.fromString should return NONE unless the whole of its argument is a valid string. That does not match my reading of the ML Basis Library specification which says that String.fromString should return SOME s if it is possible to convert at least one character of the argument.
David
-
David.Matthews＠prolingua.co.uk -
dtopham＠gmail.com -
rda＠lemma-one.com