Poly/ML

polyml@lists.polyml.org

2 participants
698 discussions

configure script problem on OS X
by philip.weaver＠gmail.com 06 Jun '10

06 Jun '10

Hello. I have noticed that the configure script fails if the CXX environment variable is set on OS X. The error message is (when CXX=/usr/bin/c++): checking for /usr/bin/c++... no configure: error: No C++ compiler found. Unable to build Poly/ML. This happens when CXX is set to any valid CPP compiler. I'm pretty sure it's not user error. The configure script works fine if CXX is unset or if I bypass the check by setting check_cpp=yes, as in the following example: check_cpp=yes CXX=/usr/bin/c++ ./configure I have confirmed that this happens on at least one other colleague's OS X machine. We both have 10.6 Snow Leopard. I have checked both the 5.3 release and the latest commit in SVN, and both of them display this problem. Has anyone else encountered this problem? On other operating systems besides OS X? Thanks - Philip

2 3

Release of version 0.5 of the ULTRA type error slicer for SML
by vincent.rahli＠gmail.com 04 Jun '10

04 Jun '10

We are happy to announce the release of the version 0.5 of our type error slicing software for the SML programming language. Major improvements over the previous release: * Handling of the SML 'open' feature. * Handling of the SML datatype replication feature. * Type error slices can now be displayed in a terminal window or in a web browser. * We supply Ubuntu and Fedora packages. Other less important improvement is: * We improved our minimisation algorithm. Even more changes are documented in the ChangeLog file. The aim of our type error slicer is to provide useful type error reports for pieces of code written in SML: * It identifies all of the program points that contribute to a type error, including the spot with the actual programming error that caused the type error. * It highlights these program points in the original, unchanged source code. * It avoids showing internal details of the operation of the type inference machinery. New Ubuntu (Debian based) and Fedora (Red-Hat based) packages of our type error slicer can be found at this URL: http://www.macs.hw.ac.uk/ultra/compositional-analysis/type-error-slicing/ We will also shortly release a plain archive of our type error slicer. At the time of the release of version 0.4, we forgot to update the web demo. We have now updated our web demo from version 0.3 to version 0.5. Known limitations: * We have not yet built the software for other operating systems than Linux. * The currently supported user interfaces are via a terminal window, GNU Emacs (or our web demo). We are currently developing a Vim interface. * Some type errors are not yet discovered (the user will need to rely on their usual type checker in these cases). Notable spots where the implementation is incomplete are functors (you can work around this by including signatures on functor applications), equality types. * Concerning fixity declarations, programs are parsed as though the declarations were not there, which gives wrong results. * We don't yet handle overloaded constants (for example 1 is always of type int). * The details of the SML basis library are incomplete (fortunately the user can add any additional details they are using). * The software does not currently scale well to very large programs (we are still improving this). It is currently suitable for small programs and use in teaching. * We do not report free identifiers anymore. * We have some known issues ';' that can lead to incorrect constraint generations and so to wrong type error messages. We are currently working on a new version of the slicer that will fix this issue. Best wishes, Vincent Rahli and Joe Wells

1 0

Poly/ML build fails on Fedora 12
by rda＠lemma-one.com 27 May '10

27 May '10

I get the following failure when I try to build Poly/ML on a Fedora 12 box: ... ./polyimport -H 10 polytemp.txt -I . < ./exportPoly.sml /home/rda/bld/poly/polyml.5.3/.libs/lt-polyimport: error while loading shared libraries: libpolyml.so.1: cannot enable executable stack as shared object requires: Permission denied Any suggestions gratefully received, Regards, Rob.

2 1

Workshop on ML 2010 - Call for Content
by mtf＠cs.rit.edu 24 May '10

24 May '10

The 2010 ACM SIGPLAN Workshop on ML http://www.cs.rit.edu/~mtf/ml2010 Baltimore, Maryland, United States Sunday, September 26, 2010 co-located with ICFP 2010 Call for Content ML is a family of programming languages that includes dialects known as Standard ML, Objective Caml, and F#. The development of these languages has inspired a large amount of computer science research, both practical and theoretical. This workshop aims to provide a forum to encourage discussion and research on ML and related technology (higher-order, typed, or strict languages). The format of the 2010 Workshop on ML will be different than that of recent years, returning to a more informal model: a workshop with presentations selected from submitted abstracts but without published proceedings. We hope that this format will encourage the presentation of more exciting (if unpolished) research and deliver a more lively workshop atmosphere. Invited Speaker ~~~~~~~~~~~~~~~ Luke Hoban (Microsoft) -- Bringing F# to Visual Studio 2010 Important Dates ~~~~~~~~~~~~~~~ Submission: 25 June, 2010 Notification: 9 August, 2010 Format ~~~~~~ The workshop will consist of presentations by the participants, selected from submitted abstracts. Participants are invited to submit working drafts, source code, and/or extended abstracts for distribution on the workshop homepage and to the attendees, but as the workshop will have no formal proceedings, any contributions may be submitted for publication to other venues. (See the SIGPLAN republication policy for more details.) Scope ~~~~~ We primarily seek research presentations on topics related to ML, including (but not limited to): * applications: case studies, experience reports, pearls, etc. * extensions: higher forms of polymorphism, generic programming, objects, concurrency, distribution and mobility, semi-structured data handling, etc. * type systems: inference, effects, overloading, modules, contracts, specifications and assertions, dynamic typing, error reporting, etc. * implementation: compilers, interpreters, type checkers, partial evaluators, runtime systems, garbage collectors, etc. * environments: libraries, tools, editors, debuggers, cross-language interoperability, functional data structures, etc. * semantics: operational, denotational, program equivalence, parametricity, mechanization, etc. Research presentations should describe new ideas, experimental results, significant advances in ML-related projects, or informed positions regarding proposals for next-generation ML-style languages. We especially encourage presentations that describe work in progress, that outline a future research agenda, or that encourage lively discussion. In addition to research presentations, we seek both Status Reports and Demos that emphasize the practical application of ML research and technology. Status Reports: Status reports are intended as a way of informing others in the ML community about the status of ML-related research or implementation projects, as well as communicating insights gained from such projects. Status reports need not present original research, but should deliver new information. In the abstract submission, describe the project and the specific technical content to be presented. Demos: Live demonstrations or tutorials are intended to show new developments, interesting prototypes, or work in progress, in the form of tools, libraries, or application software built on or related to ML technology. In the abstract submission (which need only be about half a page), describe the demo and its technical content, and be sure to include the demo's title, authors, collaborators, references, and acknowledgments. A demonstration should take 10-15 minutes. The exact time per demo will be decided based on the number of accepted submissions. (Please note that you will need to provide all the hardware and software required for your demo; the workshop organizers are only able provide a projector.) Submission Guidelines and Instructions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Email submissions to mtf AT cs.rit.edu. Submissions should be at most two pages, in PDF format, and printable on US Letter or A4 sized paper. Persons for whom this poses a hardship should contact the program chair. Submissions longer than a half a page should include a paragraph synopsis suitable for inclusion in the workshop program. Program Chair ~~~~~~~~~~~~~ Matthew Fluet Rochester Institute of Technology Program Committee ~~~~~~~~~~~~~~~~~ Kathleen Fisher AT&T Labs Research Adam Granicz IntelliFactory Daan Leijen Microsoft Research Johan Nordlander Lulea University of Technology Sungwoo Park Pohang University of Science and Technology Daniel Spoonhower Google

1 0

Poly/ML interpreter's opcodes
by xyly781＠gmail.com 19 May '10

19 May '10

Dear David, Right now I'm studying the Poly/ML's interpreter, trying to understand the semantics of opcodes implemented in interpret.cpp. However, I have difficulty on understanding some of the opcodes: 1. INSTR_non_local, in its implementation case INSTR_non_local: { PolyWord *t = sp+arg1; POLYSIGNED uu; for(uu = 1; uu <= arg2; uu++) t = (t[-1]).AsStackAddr(); uu = arg3; /* Can be negative. */ if (uu > 32767) uu -= 65536; *(--sp) = t[uu]; pc += 6; break; } Here what does this instruction do, and what does t[-1] holds? Also how about the semantics of INSTR_non_local_l_i (where i can be 1, 2 or 3)? 2. INSTR_const_addr_Xb, and INSTR_const_addr_Xw: in their implementations they have long expression for computing the addresses such as: PolyWord::FromCodePtr(pc + (pc[0]+4)*sizeof(PolyWord) + pc[1] + pc[2]*256 + 3)) I'm confused about what does the address computed by the long expression refer to and why it is computed in this way? What are the meanings of Xb, and Xw in the their instruction names? 3. INSTR_ldexc. This instruction pushes the content in p_reg[0] into the stack. I read the definition of the stack object in globals.h, but still couldn't understand what is the stack registers used for? Here could you give me some help for understanding the above instructions? Thanks, Yue

2 2

5.3 variability in Posix.Process.exec
by Michael.Norrish＠nicta.com.au 14 May '10

14 May '10

On my Intel Macbook Pro running 10.5.8, I get SysErr ("Operation not supported", SOME ENOTSUP) On a Linux michaeln-desktop 2.6.31-21-generic #59-Ubuntu SMP Wed Mar 24 07:28:56 UTC 2010 i686 GNU/Linux I get: -- Poly/ML 5.3 Release > Posix.Process.exec ("/bin/ls", []); Warning-The type of (it) contains a free type variable. Setting it to a unique monotype. Segmentation fault -- On a slightly different Linux atp-login1 2.6.26-2-686 #1 SMP Wed Aug 19 06:06:52 UTC 2009 i686 GNU/Linux I get the expected behaviour... -- Is there anything I should have done differently when building these Poly instances? Michael

3 13

Poly/ML exit codes
by Michael.Norrish＠nicta.com.au 13 May '10

13 May '10

I have a Linux shell-script that calls poly-image < script and which is being dying unexpectedly in a cronjob. The end of the log looks like: Poly/ML 5.3 Release > Killed /home/michaeln/stdhol/bin/Holmake: Failed script build for arm_improved_gcScript - exited with code 89 Build failed in directory /home/michaeln/stdhol/examples/machine-code/lisp (exited with code 1) Holmake is reporting the error returned by a call to OS.Process.system, using fun posix_diagnostic stat = let open Posix.Process in case fromStatus stat of W_EXITSTATUS w8 => "exited with code "^Word8.toString w8 | W_EXITED => "exited normally" | W_SIGNALED sg => "with signal " ^ SysWord.toString (Posix.Signal.toWord sg) | W_STOPPED sg => "stopped with signal " ^ SysWord.toString (Posix.Signal.toWord sg) end The presence of "Killed" makes me think that the script is being killed by an external signal, perhaps a SIGSEGV caused by hitting a limit on stack-size. But is this plausible? Would Poly/ML catch that signal and then exit with 89? Annoyingly, the same script doesn't fail when not in a cronjob, so it's hard to test. Michael

2 2

Fwd: Re: [polyml] Documentation of Poly/ML opcode
by xyly781＠gmail.com 01 May '10

01 May '10

forward to the list. -------- Original Message -------- Subject: Re: [polyml] Documentation of Poly/ML opcode Date: Sat, 01 May 2010 13:58:45 -0500 From: Yue Li <xyly781(a)gmail.com> To: David Matthews <David.Matthews(a)prolingua.co.uk> Hi, David, On 05/01/2010 06:38 AM, David Matthews wrote: > Hi, > The opcodes in int_opcodes.h apply only to the interpreted version of > Poly/ML and the interpreter is only used on platforms where there is > no native code-generator. > I see. Ok! > There's not much, if any, documentation for the internals of the > compiler or run-time system. Probably the most useful data structures > to look at are in mlsource/MLCompiler/CODETREESIG.ML . I did not discover that before. The IR is really helpful! Thanks! > The top-level of the compiler builds this intermediate level data > structure and the optimiser transforms it. It is then code-generated > by the bottom level using either a native code-generator; for the X86 > (32 or 64-bit), PPC or Sparc or byte code for the interpreter on any > other platform. Many operations, though, are performed by RTS > (run-time system) functions and these include such basic operations as > integer addition. These are listed in libpoly/sys.h and > basis/RunTimeCalls.ML. In the general case these actually require a > call into the C++ run-time system but simple operations are > implemented in the assembly code section or are recognised by the > code-generator and turned into the appropriate machine instructions. > No problem! Here could you point me to the code where the native and byte code generator lives? Thank you very much! Yue > Regards, > David > > Yue Li wrote: >> Hi, >> >> I'm currently studying the run time system of Poly/ML, looking at its >> source code. I found there are 130 instructions listed in >> int_opcodes.h, and the semantics is defined in interpreter function. >> I'm wondering whether there's any documentation available for >> describing the semantics of each instruction, this will definitely >> help me understand each instruction better. >> >> Thanks for your help, >> >> Yue >> _______________________________________________ >> polyml mailing list >> polyml(a)inf.ed.ac.uk >> http://lists.inf.ed.ac.uk/mailman/listinfo/polyml

1 0

Documentation of Poly/ML opcode
by xyly781＠gmail.com 01 May '10

01 May '10

Hi, I'm currently studying the run time system of Poly/ML, looking at its source code. I found there are 130 instructions listed in int_opcodes.h, and the semantics is defined in interpreter function. I'm wondering whether there's any documentation available for describing the semantics of each instruction, this will definitely help me understand each instruction better. Thanks for your help, Yue

2 1

CUFP 2010 in Baltimore in September -- Call for Participation
by sweeks＠sweeks.com 24 Apr '10

24 Apr '10

Commercial Users of Functional Programming Workshop (CUFP) 2010 Call for Participation Sponsored by SIGPLAN Co-located with ICFP 2010 Baltimore, Maryland Sep 27-29, 2010 Submission Deadline: 15 June 2010 Functional programming languages have been a hot topic of academic research for over 35 years, and have seen an ever larger practical impact in settings ranging from tech startups to financial firms to biomedical research labs. At the same time, a vigorous community of practically-minding functional programmers has come into existence. CUFP is designed to serve this community. The annual CUFP workshop is a place where people can see how others are using functional programming to solve real world problems; where practitioners meet and collaborate; where language designers and users can share ideas about the future of their favorite language; and where one can learn practical techniques and approaches for putting functional programming to work. # Giving a CUFP Talk # If you have experience using functional languages in a practical setting, we invite you to submit a proposal to give a talk at the workshop. We're looking for two kinds of talks: *Experience reports* are typically 25 minutes long, and aim to inform participants about how functional programming plays out in real-world applications, focusing especially on lessons learned and insights gained. Experience reports don't need to be highly technical; reflections on the commercial, management, or software engineering aspects are, if anything, more important. You do not need to submit a paper! *Technical talks* are expected to be 30-45 minutes long, and should focus on teaching the audience something about a technical technique or methodology, from the point of view of someone who has seen it play out in practice. These talks could cover anything from techniques for building functional concurrent applications, to managing dynamic reconfigurations, to design recipes for using types effectively in large-scale applications. While these talks will often be based on a particular language, they should be accessible to a broad range of functional programmers. If you are interested in offering a talk, or nominating someone to do so, send an e-mail to francesco(at)erlang- consulting(dot)com or yminsky(at)janestreet(dot)com by **15 June 2010** with a short description of what you'd like to talk about or what you think your nominee should give a talk about. Such descriptions should be about one page long. There will be no published proceedings, as the meeting is intended to be more a discussion forum than a technical interchange. # Program Committee # * Francesco Cesarini, Erlang Training and Consulting (Co-Chair) * Tim Dysinger, Sonian Networks * Alain Frisch, LexiFi * Nick Gerakines, Chegg * Adam Granicz, IntelliFactory * Amanda Laucher * Romain Lenglet, Google Japan * Yaron Misky, Jane Street (Co-Chair) * Mary Sheeran, Chalmers * Don Stewart, Galois * Dean Wampler, DRW Trading # More information # For more information on CUFP, including videos of presentations from previous years, take a look at the CUFP website at <http://cufp.org>. Note that presenters, like other attendees, will need to register for the event. Presentations will be video taped and presenters will be expected to sign an ACM copyright release form. Acceptance and rejection letters will be sent out by July 15th.

1 0

← Newer
1
...
43
44
45
46
47
48
49
...
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