Poly/ML

polyml@lists.polyml.org

695 discussions

Unicode in Poly/ML?
by Michael.Norrish＠nicta.com.au 21 Aug '08

21 Aug '08

It is possible to emit Unicode (UTF-8 encoded say) strings in a Poly/ML program by emitting the appropriate sequence of bytes: Poly/ML 5.2 Release > print "\u00e2\u0088\u0080\n"; ? val it = () : unit But as far as Poly is concerned, this is actually a sequence of four characters, not two (the universal quantifier and the newline). Are there any plans to implement some sort of sensible WideChar signature? (The existing WideChar signature in the Basis is not really a good base on which to build good support here.) Michael.

4 4

Should -fno-strict-aliasing be in CXXFLAGS, too?
by lionel＠mamane.lu 18 Aug '08

18 Aug '08

Hi, Background: Achim Brucker and myself are packaging Poly/ML for Debian. I noticed that: 1) Compilation of file libpolyml/xwindows.cpp with gcc 4.2.3 gives several instances of: warning: dereferencing type-punned pointer will break strict-aliasing rules 2) libpolyml/Makefile.am has AM_CFLAGS = $(OSFLAG) -Wall -fno-strict-aliasing So I kinda guess that libpolyml/xwindows.cpp was supposed to be compiled with -fno-strict-aliasing, too, and you just forgot to put it in CXXFLAGS as well as CFLAGS? Or is the situation something else? -- Lionel

4 3

Re: Assertion failure in gc.cpp
by David.Matthews＠prolingua.co.uk 14 Aug '08

14 Aug '08

Rob Arthan wrote: > I am working on porting ProofPower to Poly/ML 5.2. I get the following > assertion failure when I run one of the tests for my parser generator. I can > reproduce the problem deterministically, but the circumstances in which it > occurs are obscure: at first glance it seems to depend on whether I am > calling "use" directly or via a function of my own, but it doesn't fail if I > avoid compiling my function twice. It seems very dependent on exactly how > things are compiled. > > slrp-ml: gc.cpp:878: virtual POLYUNSIGNED > ProcessUpdate::ScanAddressAt(PolyWord*): Assertion > `obj->ContainsNormalLengthWord()' failed. > Rob, Thanks for sending the test program. I finally managed to get to the bottom of this. The problem turned out to be the way that the heap was restored after calling "export". It would only have shown up in certain circumstances and only in a garbage collection after the export. Generally, export is the last thing that is called in a session which may explain why it didn't show up earlier. I've fixed it in CVS and your test now runs successfully. Let me know if you get this again although this assertion could be triggered by any number of different faults connected with the GC. Regards, David.

1 0

xwindows.xpp: deprecated conversion from string constant to 'char*'
by brucker＠spamfence.net 14 Aug '08

14 Aug '08

Hi, using a recent g++ version for compiling Poly/ML results in several warnings of the following form: xwindows.cpp: warning: deprecated conversion from string constant to 'char*' The warning is caused by implicit conversion from string constants (i.e., "foo") to non-constant char pointers. To this email, I attached a simple patch which should remove these warnings. The patch should be safe to apply as it either makes the casts explicit or changes some types from "char *" to "const char *". Please note that I could only test these modifications on my i386 box running Linux.... Achim

2 1

Release 5.2
by David.Matthews＠prolingua.co.uk 31 Jul '08

31 Jul '08

Timothy Bourke wrote: > I've just had some time to test the new version on FreeBSD (6.3-RELEASE). > > On Jun 3 at 15:14 +0100, David Matthews wrote: >> Changes to handling of signals by the Signal structure. Rather than >> forking a new thread to process each signal there is a single thread that >> executes all the signal handlers. This should improve the responsiveness >> to an asynchronous signals such as SIGINT. The original control-C handler >> has been removed and the Poly/ML read-eval-print loop now installs a simple >> handler for control-C that just generates an Interrupt exception. > > I found that the final polyimport -H 10 polytemp.txt kept crashing > with a segmentation fault. It seems that PTHREAD_STACK_MIN is not > enough space on FreeBSD 6.3. Adding 100 (found by trial and error) > fixes the problem as per the attached patch. Tim, Thanks for reporting this. I've installed FreeBSD 6.3 in an emulator and tested Poly/ML. It seems that PTHREAD_STACK_MIN is only 2k on FreeBSD whereas it is 16k on Linux. I've added a test for when it's less than 4k so that there is at least 4k for the stack. The idea was to try and use a smallish stack for this thread because it only calls a single function but there's no need to shave the stack space to an absolute minimum. It's likely to be rounded up to a page boundary anyway. I also fixed a few other things so that it compiles on FreeBSD without any other changes. Regards, David. Copied to the mailing list in case there are other FreeBSD users out there.

2 1

pretty printing oddities
by ldixon＠inf.ed.ac.uk 15 Jul '08

15 Jul '08

A while ago I grumbled about pretty printing of types in PolyML. I have just managed to condense my code into a sensibly viewable example which illustrates what I think the problem is: signature N = sig type T end; signature A = sig type T structure Ns : N sharing type Ns.T = T val mk : T val afoo : T -> T end; signature B = sig include A val bfoo : T -> T end; structure As : A = struct structure Ns = struct type T = string; end; type T = string val mk = "*" fun afoo s = s ^ "a"; end; structure Bs : B = struct open As; fun bfoo s = s ^ "b"; end; structure SafeBs :> B = Bs; Observe the output from PolyML for the signature SafeBs. It prints it out wrongly. And I think this is to do with the sharing constraint: without it, I get what I expect: structure SafeBs : sig structure Ns : N type T val afoo : SafeBs.T -> SafeBs.T val bfoo : SafeBs.T -> SafeBs.T val mk : SafeBs.T end However, with the sharing constraint, I get: structure SafeBs : sig structure Ns : N type T val afoo : A.T -> A.T val bfoo : A.T -> A.T val mk : A.T end I think, given that SafeBs is hiding the types, printing A.T is very confusing, one might even be tempted to say wrong. I would ideally like to have some programmatic control over the printing; perhaps choosing the left or right hand side of the last sharing constraint to be the name of the type that it printed. would be lovely if this was easy to fix - it would help my understanding of type errors enormously! :) cheers, lucas

1 0

polyml input, echo, pipes and PolyML.export oddity
by ldixon＠inf.ed.ac.uk 08 Jul '08

08 Jul '08

Hello, Perhaps this is something to do with my failure to understand unix pipes, but the following confuses me... I open poly from a shell and I type the following: fun loopy () = let val sopt = TextIO.inputLine(TextIO.stdIn); in case sopt of SOME s => (print s; loopy ()) | NONE => () end; PolyML.export ("foo", loopy); OS.Process.exit OS.Process.success; then I make this into a nice program call foo with: cc -o foo foo.o -L${POLYLIB} -lpolymain -lpolyml (${POLYLIB} is the local location of my poly libs) That does what I expect it to, it echos. However, the following misbehaves: echo 'fun loopy () = let val sopt = TextIO.inputLine(TextIO.stdIn); in case sopt of SOME s => (print s; loopy ()) | NONE => () end; PolyML.export ("foo", loopy); OS.Process.exit OS.Process.success;' | poly Somehow the "OS.Process.exit OS.Process.success;" becomes the first input whenever I foo... Is this my confusion, or is it really misbehaving? (PolyML5.2, Ubuntu 8.04) cheers, lucas

2 1

strange failures (problem with shell on Debian?)
by Michael.Norrish＠nicta.com.au 04 Jul '08

04 Jul '08

I have a relatively short piece of ML looking like val _ = PolyML.Compiler.prompt1 := "" val _ = PolyML.print_depth 0 val dir = OS.FileSys.getDir() val _ = OS.FileSys.chDir "somepath" val _ = use "somefile" val _ = OS.FileSys.chDir dir val _ = load "another file" val _ = print "Done\n"; (This text is also in the file foo.) The various files that are 'use'-d are quite big, and the first one includes further calls to use. I have found that on my Debian Linux system (2.6.18), I can't reliably do any of the following: poly <<EOF ..text above.. EOF or poly < foo or echo "use \"foo\";" | poly The error is not in the ML. Each time any of these is run, I see the final "Done". However, a high proportion of the time (33% perhaps), my shell (standard Debian bash) aborts the execution of the process. For example, with the echo "use" piped to poly, I get ...output... Done val it = () : unit Aborted If I use the here document or the redirect from a file, I also get "Aborted" appended to the expected output. So, this really doesn't look like poly's fault, but it beats me as to what the problem may be. Has anyone seen anything like this before? And, is there another route by which I might be able to get my program into poly that won't suffer this problem? On MacOSX, the system uses the here document approach and I've never seen it fail. Michael.

2 1

structure sharing
by ldixon＠inf.ed.ac.uk 02 Jul '08

02 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been trying to use the module system and come across a few issues, some of which I cannot easily pin down, and one which I can. The issue I can clearly identify concerns what seems to be failure of associativity in structure sharing, and is demonstrated in the following: signature ORD_DATA = sig type data end; signature VERTEX = sig type name type data end; signature BVERTEX = sig structure Boundary : ORD_DATA include VERTEX end; signature GRAPH = sig structure Vertex : VERTEX type T; end; signature BGRAPH = sig include GRAPH; structure BVertex : BVERTEX sharing Vertex = BVertex end; signature RG_VERTEX = sig include BVERTEX where type Boundary.data = unit end; signature RG_GRAPH = sig include BGRAPH structure RGVertex : RG_VERTEX sharing BVertex = RGVertex (* why is it OK if I change BVertex to Vertex? *) end Running this gives the error: Error: in '/tmp/sml25644bEn', line 26. Cannot share: (unit) is a type function Found near sig include BGRAPH structure RGVertex : RG_VERTEX sharing BVertex = RGVertex end Exception- Fail Static errors (pass2) raised Apart from just being confused by what the error means, I am confused that given, in BGraph, "sharing Vertex = BVertex", later I get an error if "BVertex = RGVertex" but not if "Vertex = RGVertex". Is there some subtle (or obvious?) thing I'm missing? Another thing I don't quite understand, but which I suspect is just part of the definition of ML, is that you cannot write "sharing type localtype = globaltype", is there some clever reason why this isn't allowed? Or even "sharing local_structure = global_structure", would sometimes be nice. :) The other issue I have is with the names given to types being printed in error messages; is there any way to control this? I sometimes seem to get mis-typed types; which makes errors hard to spot. A common thing I find is that a parameterised type loses it's parameter. I have example of this I can repeat, but they require a large amount of code... I'll try to find a smaller example. any suggestions/corrections/infomration, and possibly bug fixes, very welcome! :) cheers, lucas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFINuQvogMqU4edHsMRAnq3AKDEOOZK6W4Yl9qLIybMvIYRmrGu8ACeKZIG 2RtB76HxIEiw+Kxd/xiYvGw= =mxpJ -----END PGP SIGNATURE-----

4 8

Real.fromDecimal and Real.~
by fluet＠tti-c.org 18 Jun '08

18 Jun '08

* One bug with the implementation of Real.fromDecimal (which also affects Real.scan and Real.fromString) in PolyML 5.2. The string_buffer[30] in Real_convc in <src>/libpolyml/reals.cpp limits the length of the string seen by strtod to 29 characters. However, the construction of the ML string at <src>/basis/Real.sml:359 can construct an arbitrarily large string. In particular, the "E" and exponent can be pushed beyond the end of the string seen by strtod: Poly/ML 5.2 Release > Real.fromString "1234567890.12345678901234"; val it = SOME 1234567890.0 : Real.real option > Real.fromString "1234567890.123456789012345"; val it = SOME 1.23456789 : Real.real option > Real.fromString "1234567890.1234567890123456"; val it = NONE : Real.real option > Real.fromString "1234567890.1234567890123456789"; val it = SOME 0.123456789 : Real.real option * Real.~ doesn't properly flip the sign bit on zero: Poly/ML 5.2 Release > Real.signBit 0.0; val it = false : bool > Real.signBit (Real.~ 0.0); val it = false : bool > Real.signBit 1.0; val it = false : bool > Real.signBit (Real.~ 1.0); val it = true : bool This, in turn, makes 'Real.fromString "~0.0"' get the sign bit wrong: > Real.signBit (valOf (Real.fromString "~0.0")); val it = false : bool

2 1

← Newer
1
...
52
53
54
55
56
57
58
...
70
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Poly/ML