gmane.comp.lang.ml.polyml.general

Re: assertion failed in r1520

David Matthews — 2012-05-07T14:39:02

Ramana,
I've been doing a lot of work on the garbage collector and it is now running multithreaded by default. You can set it to single threaded by using --gcthreads 1. I suspect that this is a timing-related problem so that will work round it.
I've had a previous report of this but I've not been able to reproduce it on any of the machines I have access to. I assume it depends on some differences between machines that just happens to work for me. I won't be able to do anything this week but if you can provide any information I'll look at it next week.
Regards,
David


Ramana Kumar <ramana.kumar-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

I keep running into this kind of problem in svn revision 1520.

Aborted

I'm guessing it's a known problem in unstable, but if not I'd be happy to provide more information as necessary.
If it is known, is it likely to be fixed in svn soon?

Thanks,
Ramana

_______________________________________________
polyml mailing list
polyml-9iOJEv++55WFxr2TtlUqVg< at >public.gmane.org

assertion failed in r1520

Ramana Kumar — 2012-05-07T12:37:44

I keep running into this kind of problem in svn revision 1520.

MTGCProcessMarkPointers::ScanAddressesInObject(PolyObject*, POLYUNSIGNED):
Assertion `gMem.SpaceForAddress(wordAt.AsCodePtr()) != 0' failed.
Aborted

I'm guessing it's a known problem in unstable, but if not I'd be happy to
provide more information as necessary.
If it is known, is it likely to be fixed in svn soon?

Thanks,
Ramana
_______________________________________________
polyml mailing list
polyml-9iOJEv++55WFxr2TtlUqVg< at >public.gmane.org
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml

Re: gcbench in SML

Ian Zimmerman — 2012-05-06T17:04:40

Jeremy> * printf without lots of String.concat

David> I don't know about that.  Does anyone else have any ideas?

http://mlton.org/Printf.html

Re: gcbench in SML

Makarius — 2012-04-26T17:38:21


The web page says:

   The benchmark should run in roughly 32MB or less on most systems, and
   some systems run it in about half that.

To get meaningful numbers on current hardware, you should try to drive it 
to 32GB.  This is where things are getting interesting -- it is also about 
the limit of what the fine Poly/ML 5.4.1 by David can handle comfortable 
so far, say in really big Isabelle applications.

Old SML/NJ is loosing the game long before 100 MB total heap size, 
resulting in a factor 10..100 performance loss due to memory menagement,
compared to Poly/ML.

I've also seen the JVM getting awkward at 1..2 GB heap size.


 Makarius

Re: gcbench in SML

David Matthews — 2012-04-26T17:36:08

Hi Jeremy,

There are several non-standard functions that may help.

On 26/04/2012 17:06, Jeremy Singer wrote:

I don't know about that.  Does anyone else have any ideas?


Poly/ML in SVN has a facility to get quite a lot of internal statistics. 
  Use PolyML.Statistics.getLocalStats to get statistics for the current 
process or PolyML.Statistics.getRemoteStats to get statistics for 
another Poly/ML by pid.  Note: it seems that this structure is only 
included if you rebuild the compiler with "make compiler" after "make".


PolyML.objSize will show the number of words being used by a data 
structure.  Be careful that if you have any function closures in the 
data structure it can include everything reachable from the function 
which could be more than you expect.

One further complication: as part of the great Poly/ML storage 
management rebuild in SVN there's now a pass that tries to merge 
identical immutable data structures to reduce the live data size; like 
PolyML.shareCommonData but only on a single el

Re: gcbench in SML

Phil Clayton — 2012-04-26T17:14:44

Quick answer to this one: instead of
   print (String.concat strs)
do
   List.app print strs

Here the text is just kept as a list of strings but, in general, one can 
build up any abstract text representation to suit a particular need. 
For example, I use the following interface for horizontal text:

signature H_TEXT_TREE =
   sig
     type t

     (* Constructors *)
     val empty : t
     val sp    : int -> t
     val str   : string -> t
     val chr   : char   -> t
     val seq   : t list -> t

     (* Derived constructors *)
     val concat : string list -> t

     (* Predicates *)
     val isEmpty : t -> bool

     (* Operations *)
     val size : t -> int
     val app : (string -> unit) -> t -> unit
     val toStrings : t -> string list
   end

Phil

gcbench in SML

Jeremy Singer — 2012-04-26T16:06:12

Hi David,

I am trying to create something like Hans Boehm's GC benchmark -
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_bench.html
in SML. My current attempt is at:
http://pastebin.com/2RW9jpCJ

Sorry - I forgot all my ML years ago. Here are some things I'm not sure how to do nicely in Poly/ML:

* printf without lots of String.concat
* is there a runtime API call to get the totalMem (current heap size?) and the free mem (currently unused blocks in heap?)
* Are all my ephemeral objects being created properly, or is the compiler optimizing away their allocation? How could I tell?
* So far, I have been checking gc activity with --debug gc flag. Are there any more powerful tools for GC profiling/checking?

Thanks,
Jeremy




The University of Glasgow, charity number SC004401

Re: Poly/ML and SML/NJ warn inconsistently about using op for an infix constructor

David Matthews — 2012-04-04T14:09:18

It's probably worth summarising the current and previous situation.

There's no change to the handling of patterns or expressions.  Poly/ML 
produces warnings if it is able to parse an infix operator without "op". 
  So "(+)" and "map (+)" will continue to be accepted but produce a warning.

"op" is now allowed in exception declarations but not in signatures.  So
exception op y
exception op x = op y
are accepted.  The "op" is simply ignored; there's no warning if it is 
missing for infix operators.

In a datatype constructor previously a warning was produced if a value 
constructor was declared which had infix status but "op" was not used. 
That warning has been removed so "op" is simply ignored.

In a datatype specification (i.e. in a signature) "op" used to be 
allowed but ignored.  No warning was produced for constructors with 
infix status.  This has changed.  Now a warning is produced if "op" is 
used at all.  This is the only place where a warning is produced when it 
wasn't previously.  Since I've no

Re: Poly/ML and SML/NJ warn inconsistently about using opfor an infix constructor

Rob Arthan — 2012-04-04T13:59:18

On 4 Apr 2012, at 14:33, Makarius wrote:


I should explain that "Tut, tut" was just intended to be a light-hearted jibe at the Isabelle code. I didn't intend to suggest that Poly/ML should stop supporting the extended syntax that allows your old code to compile.

Regards,

Rob.

Re: Poly/ML and SML/NJ warn inconsistently about using op for an infix constructor

Makarius — 2012-04-04T13:33:38


Historically, we've always tried to minimize the problems in the grey 
areas of the SML standard, with its occasional changes that were not 
immediately clear from outside.

I have no problems to remove inappropriate "op" occurrences from the 
Isabelle sources, if it does not break SML/NJ or old versions of Poly/ML 
(5.2.1, 5.3.0, 5.4.x).  On the other hand it will make testing of old 
Isabelle versions with brand new Poly/ML versions more difficult.


 Makarius

Re: Poly/ML and SML/NJ warn inconsistently about using opfor an infix constructor

Rob Arthan — 2012-04-04T12:28:55

On 4 Apr 2012, at 11:48, David Matthews wrote:


Tut, tut :-). Somewhat to my surprise, the ProofPower source does comply with the standard syntax, even though I was completely unaware that "op" wasn't allowed in signatures.


Yes, SML/NJ and MLton don't allow an infix vid without an "op" as an expression or a pattern.


It is only a warning. I think Phil's point was that, as things stood, you couldn't write a datatype declaration with an infix constructor that would not give a warning on one of the two compilers: as was, Poly/ML warned when you didn't use "op" before an infix constructor in a datatype, while SML/NJ warned when you did.


Likewise SML/NJ appears to extend the standard syntax by allowing "op" in datatypes in signature (but giving a warning saying that they are unnecessary).


No, that is what I meant: Poly/ML 5.4.1 doesn't share your view that it is illegal:

Poly/ML 5.4.1 Release
Warning-(+) has infix status but was not preceded by op.
val it = fn: int * int -> int
Warning-(+) has infix sta

Re: Poly/ML and SML/NJ warn inconsistently about using op for an infix constructor

David Matthews — 2012-04-04T10:48:18

I've now reduced the error message to a warning since it seems Isabelle 
has "op" in signatures.


Do any other compilers complain about missing "op" in those cases? 
Phil's point was that SML/NJ was complaining about the presence of "op" 
rather than its absence.  I tried an "op" in a datatype in a signature 
in MLton and it didn't say anything although it's not correct.


Do you mean something like
     val p = map (+)
rather than
     val p = map (op +)    ?
I wasn't planning to since I don't think it's legal ML.  Did you mean 
somewhere else?

Regards,
David

Re: Poly/ML and SML/NJ warn inconsistently about using opfor an infix constructor

Rob Arthan — 2012-04-03T15:20:43

On 30 Mar 2012, at 12:52, David Matthews wrote:


I didn't look at the syntax of modules. You are quite right. In fact, as far as I can see, op is not allowed anywhere in a signature.


I think it is wise to give the warning in those cases, because other compilers are not as liberal as Poly/ML, so I read the warning as a warning about a potential portability problem (and always act on it).

Out of interest, are you still planning to allow things like "(+)"?

Regards,

Rob.

_______________________________________________
polyml mailing list
polyml-9iOJEv++55WFxr2TtlUqVg< at >public.gmane.org
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml

Re: Poly/ML and SML/NJ warn inconsistently about using op for an infix constructor

Phil Clayton — 2012-04-02T12:49:16

Good point - I'd forgotten about nonfix.

Thanks for the updates.  That is much more preferable to a workaround!

Phil

Re: Poly/ML and SML/NJ warn inconsistently about using op for an infix constructor

David Matthews — 2012-03-30T11:52:20

I've had another look at this and committed a change to the parser.  I 
can't see any reason for producing the warning in this case so I've 
removed it.  I have a vague feeling that in an early draft of Standard 
ML the syntax of datatype bindings more closely resembled pattern 
matching so there was a real reason for using "op".  Something like
datatype 'a list = nil | 'a :: 'a list
compared with
datatype 'a list = nil | op :: 'a * 'a list

Looking carefully at the syntax, though, "op" is not allowed in a 
datatype specification although in all other respects the syntax of a 
binding and a specification are the same.  I've added an error message 
if "op" is used in a specification.


It is, of course, possible to write
     local nonfix & in datatype t = & end
This should work in both Poly/ML and SML/NJ although I haven't tested 
SML/NJ here.


I hadn't actually realised that "op" was allowed on exception bindings 
and I've now fixed that.  I think a sensible approach is to produce a 
warning in the cases

Re: Poly/ML and SML/NJ warn inconsistently about using opfor an infix constructor

Rob Arthan — 2012-03-29T15:00:44

On 27 Mar 2012, at 22:41, Phil Clayton wrote:


All it says is "The only required use of op is in prefixing a non-infixed occurrence of an identifier vid which has infix status; elsewhere op, where permitted, has no effect". vid here is the syntactic category of value identifiers. Then at various points in the syntax an optional op appears (written <op>). The relevant point in the syntax here is in the production for conbind, the thing to the right of the equals signs in a data type declaration. It looks like this:

conbind = <op> vid < of ty> < | conbind>

It is a bit odd to allow op here if it is never necessary, so I can see the Poly/ML point of view, suggesting that it is good style to put it in. On the other hand, there is nothing else other than a vid that can appear immediately after the equauls signs in datatype declaration, so I can see the SML/NJ point of view too. However, SML/NJ isn't consistent. What I have just said about the equals sign in a data type declaration is equally try of a value dec

Poly/ML and SML/NJ warn inconsistently about using op for an infix constructor

Phil Clayton — 2012-03-27T21:41:56

For example, given

   infix &
   datatype t = &

Poly/ML (5.4) reports:

   Warning-(&) has infix status but was not preceded by op.

So Poly/ML seems to prefer the use of 'op' in a datatype declaration. 
However, if 'op' is present, i.e.

   datatype t = op &

SML/NJ (110.73) reports:

   stdIn:2.14-2.16 Warning: unnecessary `op'

Generally, it is a good principle to avoid warnings but, in this 
particular respect, that isn't possible for code that is shared between 
Poly/ML and SML/NJ.  Note that MLton (20100608) doesn't warn either way.

Does the Standard provide any guidance about the use of op here?  Can 
anything be done to align the warnings from Poly/ML and SML/NJ in this 
respect?

Thanks,
Phil

Calling C functions

Phil Clayton — 2012-02-15T13:38:27

I thought it could be useful to mention the approach that I have been 
taking for calling C functions.  In particular, it avoids the need to 
have a family of callN functions.  For example, instead of writing

   call2 (load_sym lib "sum") (DOUBLE, DOUBLE) DOUBLE

operators --> and &&> are used to construct function specifications that 
are given to a single call function:

   call (load_sym lib "sum") (DOUBLE &&> DOUBLE --> DOUBLE)

The resulting function takes nested pair arguments rather than an 
n-tuple, so we would give the argument e.g. (x & y), where & is an 
infixr constructor for a pair type, rather than (x, y).  See example 1 
in attached.

I didn't extend this scheme for passing parameters by reference because 
that was easily dealt with elsewhere (still avoiding the family of 
callNretX functions): in my approach, each C function binding has two 
levels: a low-level as above and a high-level wrapper that is introduced for
   - converting between abstract types and concrete C types
   - controllin

Re: Overloaded operators for Time.time

David Matthews — 2012-02-06T09:53:34

Generally, I prefer to conform to the standards whenever possible but in 
this case I'm not convinced that it would be a good idea to change it. 
As an experiment I removed the overloading and had to make several 
changes to the rest of the library code to allow it to compile.  Perhaps 
as a first step I'll ensure that the rest of the library will compile if 
the overloading is removed and then people can experiment with removing 
the overloads.  They are just the last few lines of basis/Time.sml.

David

Re: Overloaded operators for Time.time

Phil Clayton — 2012-02-05T19:13:24

I discovered this when MLton rejected some existing code I had.  SML/NJ 
also follows the Basis Library strictly too.  I suppose the question is 
whether the potential portability problems outweigh the benefits.

Phil

Re: Overloaded operators for Time.time

Phil Clayton — 2012-02-05T19:06:40

It is, but I think the point is that if the Basis Library overloaded 
infix operators for Time.time values we wouldn't need to rebind them (by 
whatever means) to make them infix, enabling us to avoid this 
overloading issue.  As Rob says, it must be an oversight.

Phil