Poly/ML

polyml@lists.polyml.org

695 discussions

current git version crashes
by Michael.Norrish＠data61.csiro.au 08 Nov '17

08 Nov '17

As visible on our CI machinery at travis-ci.org, polyml?s latest git checkouts (Poly/ML 5.7 Release (Git version v5.7-283-g04d3c957)) are crashing when trying to build HOL. See for example https://travis-ci.org/HOL-Theorem-Prover/HOL/jobs/298998364 where the end of the transcript reads /home/travis/build/HOL-Theorem-Prover/HOL/bin/hol.state0 FAILED! <1> Loading /home/travis/build/HOL-Theorem-Prover/HOL/sigobj/boolLib error in quse /home/travis/build/HOL-Theorem-Prover/HOL/src/1/Prim_rec.sml : Fail "Exception- InternalError: codeToPRegRev raised while compiling" error in load $(HOLDIR)/src/1/Prim_rec : Fail "Exception- InternalError: codeToPRegRev raised while compiling" error in load /home/travis/build/HOL-Theorem-Prover/HOL/sigobj/boolLib : Fail "Exception- InternalError: codeToPRegRev raised while compiling" Loading /home/travis/build/HOL-Theorem-Prover/HOL/sigobj/boolLib: Fail "Exception- InternalError: codeToPRegRev raised while compiling" Exception- InternalError: codeToPRegRev raised while compiling Michael

1 0

brew install polyml
by lp15＠cam.ac.uk 14 Sep '17

14 Sep '17

As I?ve mentioned before, attempts to build Poly/ML on my machine (OS X 10.12.6) don?t get very far (see errors below). I do have success with "brew install polyml?. But this presumably does not use the --with-gmp option. Is there a way of getting that using homebrew? Larry Paulson -darwin13.1.0/libstdc++-v3/libsupc++/.libs' ld: warning: could not create compact unwind for _ffi_call_unix64: does not use RBP or RSP based frame Undefined symbols for architecture x86_64: "std::__1::__vector_base_common<true>::__throw_length_error() const", referenced from: std::__1::vector<LocalMemSpace*, std::__1::allocator<LocalMemSpace*> >::insert(std::__1::__wrap_iter<LocalMemSpace* const*>, LocalMemSpace* const&) in libpolyml.a(memmgr.o) void std::__1::vector<LocalMemSpace*, std::__1::allocator<LocalMemSpace*> >::__push_back_slow_path<LocalMemSpace* const>(LocalMemSpace* const&) in libpolyml.a(memmgr.o) void std::__1::vector<PermanentMemSpace*, std::__1::allocator<PermanentMemSpace*> >::__push_back_slow_path<PermanentMemSpace* const>(PermanentMemSpace* const&) in libpolyml.a(memmgr.o) void std::__1::vector<CodeSpace*, std::__1::allocator<CodeSpace*> >::__push_back_slow_path<CodeSpace* const>(CodeSpace* const&) in libpolyml.a(memmgr.o) void std::__1::vector<StackSpace*, std::__1::allocator<StackSpace*> >::__push_back_slow_path<StackSpace* const>(StackSpace* const&) in libpolyml.a(memmgr.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [polyimport] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2

3 2

determining link options
by Michael.Norrish＠data61.csiro.au 13 Sep '17

13 Sep '17

I was wondering if there was any way (short of trying to parse the polyc shell-script) of programmatically knowing what the right options might be when calling the linker to link object files dumped by PolyML.export. Thanks, Michael

2 2

calling PolyML.shell from inside another executable
by Michael.Norrish＠data61.csiro.au 06 Sep '17

06 Sep '17

If I write foo.ML: ```` fun main() = PolyML.shell() ```` and compile this with polyc: ```` $ polyc foo.ML -o foo ```` the resulting executable doesn?t give me the usual acknowledgements of my declarations: ```` $ ./foo > 3; > 4; > print "hello\n"; hello > 3 + true; poly: : error: Type error in function application. Function: + : int * int -> int Argument: (3, true) : int * bool Reason: Can't unify int (*In Basis*) with bool (*In Basis*) (Different type constructors) Found near 3 + true Static Errors ```` Here I?d have expected to see lines like `val it = 3 : int`. The behaviour after the compilation of the print call suggests that stdout is live, and that things really are being compiled. The error message after the last interaction is similarly reassuring. If I call PolyML.main() inside a standard poly shell (a funny thing to do), it does work as expected. I also tried to write code like that behind PolyML.shell by hand, and though I was providing a CPOutStream TextIO.print, I also failed to see any output from the compiler. Is there something I should be doing differently? Michael

2 3

semantics of SaveState.loadState
by Michael.Norrish＠data61.csiro.au 31 Aug '17

31 Aug '17

If I have a program I?d like to compile with polyc that looks like fun main () = let val _ = PolyML.SaveState.loadState (hd (CommandLine.arguments())) in ? end what, if anything can I put in the ? and have it work? All I really want is what is effectively a sequence of calls to ?use? in that slot, but there seem to be many ways of generating executables that silently crash. Michael

3 5

Exit codes and crowbar timeout
by loganjerry＠gmail.com 19 Aug '17

19 Aug '17

Greetings, The PolyML 5.7 build has been failing seemingly randomly on the Fedora builders. On one run it fails on the ppc64le build; on the next, ppc64le succeeds but the 32-bit ARM build fails. The part of the build where the failure happens varies from run to run, as well. The builder always reports that polyml exited with error code 1. I looked in the code. There are several exit(1) calls in there. That leads to my first request. Would you, please, give the different reasons why polyml might exit different exit codes? That would make tracking down problems like this easier. That's essentially what I did. I patched the polyml code to differentiate, and found that these build failures stem from the crowbar code in libpolyml/processes.cpp. I'm sure that 20 seconds is more than adequate for a typical desktop environment, but it is apparently often not enough on a busy build box with multiple compile jobs running simultaneously. My second request is: would you please increase that timeout? Since the builds almost always fail on only a single architecture, and a different one each time at that, I think that 20 seconds is *almost* enough. Perhaps 30 seconds would be enough to avoid this kind of build failure. Thank you and regards, -- Jerry James http://www.jamezone.org/

1 0

Different behaviors between SML/NJ and Poly/ML in a code from 'The Little MLer'
by ronignc＠gmail.com 06 Jul '17

06 Jul '17

Hello, everyone! I am reading The Little MLer from Matthias Felleisen and Daniel Friedman using Poly/ML interpreter. In chapter 7, whe have some sort of stream implementation: datatype chain = Link of datatype chain = Link of int * (int -> chain); fun ints(n) = Link(n + 1, ints); When I try to define the function ints in Poly/ML 5.6 interpreter, it does not work, it runs forever. But when I write the same code in SML/NJ v110.78 interpreter, things work. Is this difference in their behaviors a bug or is it normal or expected? Best regards, Ron? Gon?alves.

6 8

fork/exec woes
by Michael.Norrish＠data61.csiro.au 06 Jun '17

06 Jun '17

Both this (with Posix.Process open): case fork() of NONE => (exece(proc,proc::args,env') handle _ => die ("Exece of "^proc^" failed")) | SOME cpid => let val (_, result) = waitpid(W_CHILD cpid, []) in result end and this: case fork() of NONE => let val () = dup2 {old = outoutfd, new = Posix.FileSys.stdout} val () = dup2 {old = erroutfd, new = Posix.FileSys.stderr} val () = dup2 {old = ininfd, new = Posix.FileSys.stdin} val () = List.app close [errinfd, erroutfd, outinfd, outoutfd, ininfd, inoutfd] in exece(executable,nm_args,env) end | SOME pid => let val out = mkTIO_instream outinfd val err = mkTIO_instream errinfd val () = List.app close [outoutfd, erroutfd, ininfd, inoutfd] in ? end seem to be causing us grief, particularly on a recent Linux, PolyML 5.7 and under conditions of some memory load. The Linux is: Linux gemma 4.9.1-gnu-1 #1 SMP PREEMPT Sun Jan 8 16:17:57 UYT 2017 x86_64 GNU/Linux When strace-d, we get a lot of futex calls and interruptions from SIGCHLD. This is with --gcthreads=1, but pages like http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-usi… make me a bit nervous about how we might be falling prey to horrible problems. Is there a better idiom we might use? Thanks, Michael

3 3

Final CFP: ML Family Workshop 2017
by Sam.Lindley＠ed.ac.uk 28 May '17

28 May '17

---------------------------------------------------------------------- CALL FOR PAPERS ML Family Workshop 2017 7 September 2017, Oxford, UK http://www.mlworkshop.org/ml2017/ (co-located with ICFP) ---------------------------------------------------------------------- ML is a family of programming languages that includes Standard ML, OCaml, F#, SML#, Manticore, MetaOCaml, JoCaml, Alice ML, Dependent ML, Flow Caml, and many others. All ML languages share several fundamental traits, besides a good deal of syntax. They are higher-order, strict, mostly pure, and typed, with algebraic and other data types. Their type systems are derived from Hindley-Milner. The development of these languages has inspired a significant body of computer science research and influenced the design of many other programming languages, including Haskell, Rust, and Scala. ML workshops have been held in affiliation with ICFP continuously since 2005. This workshop specifically aims to recognise the entire extended ML family and to provide a forum for presenting and discussing common issues, both practical (compilation techniques, implementations of concurrency and parallelism, programming for the Web) and theoretical (fancy types, module systems, metaprogramming). The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of the members of the ML family. We also encourage presentations from related languages (such as ATS, Eff, F*, Koka, Links, Rust, Scala, Swift, etc.), to exchange experience of further developing ML ideas. Last year's ML Family workshop included talks covering eight different ML dialects and related languages: Eff, F#, F*, Links, Manticore, OCaml, SML, and SML#. The ML family workshop will be held in close coordination with the OCaml Users and Developers Workshop. Invited speaker --------------- Edwin Brady (University of St Andrews, UK) State machines all the way down A useful pattern in dependently typed programming is to define a state transition system, for example the states and operations in a network protocol, as an indexed monad. We index each operation by its input and output states, thus guaranteeing that operations satisfy pre- and post-conditions, by typechecking. However, what if we want to write a program using several systems at once? What if we want to define a high level state transition system, such as a network application protocol, in terms of lower level states, such as network sockets and mutable variables? In this talk, I will present an architecture for dependently typed applications based on a hierarchy of state transition systems, implemented in a generic data type ST. This is based on a monad indexed by contexts of resources, allowing us to reason about multiple state transition systems in the type of a function. Using ST, we show: how to implement a state transition system as a dependent type, with type level guarantees on its operations; how to account for operations which could fail; how to combine state transition systems into a larger system; and, how to implement larger systems as a hierarchy of state transition systems. I will illustrate the system with a high level network application protocol, implemented in terms of POSIX network sockets. Scope ----- We acknowledge the whole breadth of the ML family and aim to include languages that are closely related, such as Rust and Scala. Those languages have implemented and investigated run-time and type system choices that may be worth considering for OCaml, F# and other ML languages. We also hope that the exposure to state of the art ML might favourably influence those related languages. Specifically, we seek research presentations on topics including (but not limited to): * Language design: abstraction, higher forms of polymorphism, concurrency, distribution and mobility, staging, extensions for semi-structured data, generic programming, object systems, etc. * Implementation: compilers, interpreters, type checkers, partial evaluators, runtime systems, garbage collectors, foreign function interfaces, etc. * Type systems: inference, effects, modules, contracts, specifications and assertions, dynamic typing, error reporting, etc. * Applications: case studies, experience reports, pearls, etc. * Environments: libraries, tools, editors, debuggers, cross-language interoperability, functional data structures, etc. * Semantics: operational and denotational semantics, program equivalence, parametricity, mechanization, etc. Four kinds of submissions will be accepted: Research Presentations, Experience Reports, Demos and Informed Positions. * Research Presentations: Research presentations should describe new ideas, experimental results, or significant advances in ML-related projects. We especially encourage presentations that describe work in progress, that outline a future research agenda, or that encourage lively discussion. These presentations should be structured in a way which can be, at least in part, of interest to (advanced) users. * Experience Reports: Users are invited to submit Experience Reports about their use of ML and related languages. These presentations do not need to contain original research but they should tell an interesting story to researchers or other advanced users, such as an innovative or unexpected use of advanced features or a description of the challenges they are facing or attempting to solve. * Demos: Live demonstrations or short tutorials should show new developments, interesting prototypes, or work in progress, in the form of tools, libraries, or applications built on or related to ML and related languages. (You will need to provide all the hardware and software required for your demo; the workshop organisers are only able to provide a projector.) * Informed Positions: A justified argument for or against a language feature. The argument must be substantiated, either theoretically (e.g. by a demonstration of (un)soundness, an inference algorithm, a complexity analysis), empirically or by substantial experience. Personal experience is accepted as justification so long as it is extensive and illustrated with concrete examples. Format ------ The ML 2017 workshop will continue the informal approach followed since 2010. Presentations are selected from submitted abstracts. There are no published proceedings, so contributions may be submitted for publication elsewhere. We hope that this format will encourage the presentation of exciting (if unpolished) research and deliver a lively workshop atmosphere. Each presentation should take 20-25 minutes, except demos, which should take 10-15 minutes. The exact time will be decided based on the number of accepted submissions. The presentations will likely be recorded. Post-proceedings ---------------- ML 2017 is an informal workshop without proceedings. We are planning to publish a post-proceedings and to invite interested authors of selected presentations to expand their abstracts for inclusion. Coordination with the OCaml Users and Developers Workshop --------------------------------------------------------- The OCaml workshop is seen as more practical and is dedicated in significant part to OCaml community building and the development of the OCaml system. In contrast, the ML family workshop is not focused on any language in particular, is more research-oriented, and deals with general issues of ML-style programming and type systems. Yet there is an overlap, which we are keen to explore in various ways. The authors who feel their submission fits both workshops are encouraged to mention it at submission time or contact the programme chairs. Submission details ------------------ Submissions should be at most two pages, in PDF format, and printable on US Letter or A4 sized paper. A submission should have a synopsis (2--3 lines) and a body between 1 and 2 pages, in one- or two-column layout. The synopsis should be suitable for inclusion in the workshop programme. The bibliography will not be counted against the page limit. Submissions must be uploaded to the workshop submission website https://icfp-mlworkshop17.hotcrp.com/ before the submission deadline (Wednesday 31st May). If you have a question concerning the scope of the workshop or the submission process, please contact the programme chair. Important dates --------------- Wednesday 31st May (any time zone) Abstract submission deadline Wednesday 28th June Author notification Thursday 7th September 2017 ML Family Workshop Programme committee ------------------- Nick Benton (Facebook, UK) Ma?gorzata Biernacka (University of Wroclaw, Poland) Stephen Dolan (University of Cambridge, UK) Shin-ya Katsumata (Kyoto University, Japan) Julia Lawall (LIP6 Paris, France) Sam Lindley (The University of Edinburgh, UK) (PC chair) Andreas Rossberg (Google, Germany) Sukyoung Ryu (KAIST, South Korea) Gabriel Scherer (Northeastern University, US) Alley Stoughton (Boston University, US) Niki Vazou (University of Maryland, US)

1 0

Is there a Windows build that can run at the command prompt?
by cannam＠all-day-breakfast.com 11 May '17

11 May '17

That's good to know, thanks. I'm guessing this has a runtime dependency on other Cygwin or WSL libraries and can't easily be distributed standalone? I'm primarily wondering what is the most minimal possible installation that I can ask a Windows user (who probably starts without either Cygwin or WSL installed) to make, in order to make use of a script that happens to involve running an SML program. For this purpose it doesn't actually have to be a REPL, though that would be nice to have generally. Just running a program and presenting the output would be enough. Chris On Mon, 1 May 2017, at 19:12, Michael.Norrish at data61.csiro.au wrote: > Building under Cygwin or with the official Linux subsystem gives you > this. > > Michael > > On 1/5/17, 19:49, "polyml-bounces at inf.ed.ac.uk on behalf of Chris Cannam" > <polyml-bounces at inf.ed.ac.uk on behalf of cannam at all-day-breakfast.com> > wrote: > > Hello -- I'm wondering whether there is a Windows build of Poly/ML > available that can be used from a within command prompt or executed > from > a Powershell script, in the same sort of way as SML/NJ can be on > Windows, or as Poly/ML can on other platforms. > > As far as I can see the Windows distribution contains an executable > that > always opens its own window and provides its own interactive prompt, > which (although nice enough) is not quite what I want at the moment. > > Is there such a thing out there? > > Thanks, > > > Chris > _______________________________________________ > polyml mailing list > polyml at inf.ed.ac.uk > http://lists.inf.ed.ac.uk/mailman/listinfo/polyml > >

4 13

← Newer
1
...
10
11
12
13
14
15
16
...
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