From amal at tti-c.org Wed Oct 1 13:05:57 2008 From: amal at tti-c.org (Amal Ahmed) Date: Wed Oct 1 13:06:03 2008 Subject: [MLton-user] TLDI 2009: call for papers Message-ID: <1222891557.20006@whale.he.net> [ Just a quick reminder that the TLDI deadline is Oct 8th... ] ********************************************************************* CALL FOR PAPERS TLDI 2009 ACM SIGPLAN Workshop on Types in Language Design and Implementation 24 January 2009 Savannah, Georgia, USA To be held in conjunction with POPL 2009 http://ttic.uchicago.edu/~amal/tldi2009/ ********************************************************************* IMPORTANT DATES Submission: 8 Oct 2008, 5PM EDT (Wed) Notification: 8 Nov 2008 (Sat) Camera ready: 19 Nov 2008 (Wed) TLDI'09: 24 January 2009 (Sat) SCOPE The role of types and proofs in all aspects of language design, compiler construction, and software development has expanded greatly in recent years. Type systems, type analyses, and formal deduction have led to new concepts in compilation techniques for modern programming languages, verification of safety and security properties of programs, program transformation and optimization, and many other areas. In light of this expanding role of types, the ACM SIGPLAN Workshop on Types in Language Design and Implementation (TLDI'09) follows six previous International Workshops on types in compilation and language design (TIC'97, TIC'98, TIC'00, TLDI'03, TLDI'05, and TLDI'07), with the hope of bringing together researchers to share new ideas and results in this area. Submissions for this event are invited on all interactions of types with language design, implementation, and programming methodology. This includes both practical applications and theoretical aspects. TLDI'09 specifically encourages papers from a broad field of programming language and compiler researchers, including those working in object-oriented, dynamically-typed, late-binding, systems programming, and mobile-code paradigms, as well as traditional fully-static type systems. Topics of interest include: - Typed intermediate languages and type-directed compilation - Type-based language support for safety and security - Types for interoperability - Type systems for system programming languages - Type-based program analysis, transformation, and optimization - Dependent types and type-based proof assistants - Types for security protocols, concurrency, and distributed computing - Type inference and type reconstruction - Type-based specifications of data structures and program invariants - Type-based memory management - Proof-carrying code and certifying compilation This is not meant to be an exhaustive list; papers on novel utilizations of type information are welcome. Authors concerned about the suitability of a topic are encouraged to inquire via electronic mail to the program chair prior to submission. SUBMISSION GUIDELINES Authors should submit a full paper of no more than 12 pages (including bibliography and appendices) by Wednesday, October 8, 2008 5PM Eastern Daylight Savings Time. The submission deadline and length limitations are firm. Submissions that do not meet these guidelines will not be considered. All submissions should be in standard ACM SIGPLAN conference format: two columns, nine-point font on a ten-point baseline. Detailed formatting guidelines are available on the SIGPLAN Author Information page, along with a LaTeX class file and template: http://www.sigplan.org/authorInformation.htm Papers must be submitted in Adobe Portable Document Format (PDF) and must be formatted for US Letter size (8.5"x11") paper. Authors for whom this is a hardship should contact the program chair before the deadline. Submitted papers must adhere to the SIGPLAN Republication Policy: http://www.sigplan.org/republicationpolicy.htm Submissions should contain original research not published or submitted for publication elsewhere. The URL for submission will be announced closer to the deadline. GENERAL CHAIR Andrew Kennedy Microsoft Research, Cambridge PROGRAM CHAIR Amal Ahmed Toyota Technological Institute, Chicago PROGRAM COMMITTEE Amal Ahmed Toyota Technological Institute, Chicago (Chair) Juan Chen Microsoft Research Peter Dybjer Chalmers University of Technology Jeff Foster University of Maryland, College Park Neal Glew Intel Robert Harper Carnegie Mellon University Andrew Myers Cornell University Atsushi Ohori Tohoku University Matthew Parkinson University of Cambridge Didier Remy INRIA Paris-Rocquencourt Andreas Rossberg Max Planck Institute for Software Systems STEERING COMMITTEE Craig Chambers University of Washington Robert Harper Carnegie Mellon University (Chair) Xavier Leroy INRIA Paris-Rocquencourt Greg Morrisett Harvard University George Necula Rinera Networks and UC Berkeley Atsushi Ohori Tohoku University Francois Pottier INRIA Paris-Rocquencourt Zhong Shao Yale University From leaf.petersen at intel.com Mon Oct 6 18:11:42 2008 From: leaf.petersen at intel.com (Petersen, Leaf) Date: Mon Oct 6 18:12:18 2008 Subject: [MLton-user] DAMP 2009: Final Call For Papers Message-ID: <517AF11CC9FF404E8B27650E116B147C3BFDDA66@orsmsx505.amr.corp.intel.com> [Note the revised full paper submission date.] CALL FOR PAPERS DAMP 2009: Workshop on Declarative Aspects of Multicore Programming Savannah, GA, USA (co-located with POPL 2009) January 20, 2009 ABSTRACT SUBMISSION DEADLINE: OCTOBER 10 http://www.cse.unsw.edu.au/~pls/damp09/ Important Dates: Deadline for abstract submission: October 10, 2008 Deadline for full paper submission: October 14, 2008 Notification of acceptance: November 10, 2008 Final papers due: November 17, 2008 DAMP 2009: January 20, 2009 DAMP 2009 is the fourth in a series of one-day workshops seeking to explore ideas in programming language design that will greatly simplify programming for multicore architectures, and more generally for tightly coupled parallel architectures. DAMP 2009 is co-located with the ACM SIGPLAN - SIGACT Symposium on Principles of Programming Languages (POPL 2009). Scope The emphasis will be on functional and (constraint-)logic programming, but any programming language ideas that aim to raise the level of abstraction are welcome. DAMP seeks to gather together researchers in declarative approaches to parallel programming and to foster cross fertilization across different approaches. Specific topics include, but are not limited to: * suitability of functional and (constraint-)logic programming languages to multicore applications; * run-time issues such as garbage collection or thread scheduling; * architectural features that may enhance the parallel performance of declarative languages; * type systems and analysis for accurately knowing or limiting dependencies, aliasing, effects, and nonpure features; * ways of specifying or hinting at parallelism; * ways of specifying or hinting at data placement which abstract away from any details of the machine; * compiler techniques, automatic parallelization, automatic granularity control; * experiences of and challenges arising from making declarative programming practical; * technology for debugging parallel programs; * design and implementation of domain-specific declarative languages for multi-core; Accepted papers will be published in the ACM Digital Library and in a physical proceedings. Papers must adhere to the SIGPLAN Republication Policy: http://www.sigplan.org/republicationpolicy.htm Concurrent submissions to other conferences, workshops, journals, or similar forums of publication are not allowed. However, DAMP is intended to be a venue for discussion and exploration of works-in-progress, and so publication of a paper at DAMP 2009 is not intended to preclude later publication as appropriate. Submission Details: Authors should submit an abstract of at most 300 words and a full paper of no more than 10 pages (including bibliography and appendices) in the ACM SIGPLAN conference format. Further details are on the workshop web page: http://www.cse.unsw.edu.au/~pls/damp09/submission.html Program Chair: Manuel Chakravarty University of New South Wales Program Committee: Guy Blelloch Carnegie Mellon University Manuel Carro Universidad Polit??cnica de Madrid Koen Claessen Chalmers University of Technology Matthew Fluet Toyota Technological Institute at Chicago Vivek Sarkar Rice University Sven-Bodo Scholz University of Hertfordshire Satnam Singh Microsoft Research, Cambridge Martin Sulzmann IT University of Copenhagen Don Syme Microsoft Research, Cambridge Phil Trinder Heriot-Watt University General Chair: Leaf Petersen Intel Corporation Past DAMPs: http://www.cliplab.org/Conferences/DAMP08 http://glew.org/damp2006 http://www.cs.cmu.edu/~damp From tuulos at gmail.com Fri Oct 10 11:24:09 2008 From: tuulos at gmail.com (Ville Tuulos) Date: Fri Oct 10 11:31:53 2008 Subject: [MLton-user] How to access large amounts of data through FFI Message-ID: <12fdabad0810101124y2eabbe38q5ba00e6938c6b015@mail.gmail.com> Hi I'm a total SML / Mlton newbie, so please excuse my ignorance. I'm trying to find out if I could use Mlton to perform some data processing tasks that I used to do in C, or slowly in Python. I have large amounts (hundreds of megs to a gigabyte) of data memory mapped (using mmap) to my process' address space in C. The mapping is read-only. I would like to access the data in Mlton without copying it first, due to obvious performance reasons. The data itself is a flat array of native 32-bit ints. Since it's an immutable array of native ints, I was hoping that I could access it as an int vector (or something similar) in Mlton. How to construct and pass a valid int vector from C to SML through Mlton's FFI, preferably without copying the data first? The FFI interface seems pretty straighforward but I couldn't find any documentation how arrays and vectors should be initialized based on a C pointer and size of the data. Or, if the int vector is not a good idea, what would be a better way to get access to the memory space? Thank you, Ville Tuulos From fw at deneb.enyo.de Fri Oct 10 11:36:24 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri Oct 10 11:36:31 2008 Subject: [MLton-user] How to access large amounts of data through FFI In-Reply-To: <12fdabad0810101124y2eabbe38q5ba00e6938c6b015@mail.gmail.com> (Ville Tuulos's message of "Fri, 10 Oct 2008 11:24:09 -0700") References: <12fdabad0810101124y2eabbe38q5ba00e6938c6b015@mail.gmail.com> Message-ID: <87ljwwwb4n.fsf@mid.deneb.enyo.de> * Ville Tuulos: > Or, if the int vector is not a good idea, what would be a better way > to get access to the memory space? You probably should use MLton.Pointer: Perhaps with a wrapper to add bounds checking. From vesa.a.j.k at gmail.com Fri Oct 10 16:06:40 2008 From: vesa.a.j.k at gmail.com (Vesa Karvonen) Date: Fri Oct 10 16:06:45 2008 Subject: [MLton-user] How to access large amounts of data through FFI In-Reply-To: <12fdabad0810101124y2eabbe38q5ba00e6938c6b015@mail.gmail.com> References: <12fdabad0810101124y2eabbe38q5ba00e6938c6b015@mail.gmail.com> Message-ID: <9e43b9a0810101606m550ffc92m8f297a77a5001763@mail.gmail.com> On Fri, Oct 10, 2008 at 9:24 PM, Ville Tuulos wrote: > I would like to access the data in Mlton without copying it first, due > to obvious performance reasons. The data itself is a flat array of > native 32-bit ints. Since it's an immutable array of native ints, I > was hoping that I could access it as an int vector (or something > similar) in Mlton. > > How to construct and pass a valid int vector from C to SML through > Mlton's FFI, preferably without copying the data first? Unfortunately, you can't access a mmapped region of memory as an ordinary SML vector, because ordinary SML vectors live in MLton's garbage collected heap (and have a special header for MLton's runtime and may be moved by MLton's GC). > The FFI interface seems pretty straighforward but I couldn't find any > documentation how arrays and vectors should be initialized based on a > C pointer and size of the data. Or, if the int vector is not a good > idea, what would be a better way to get access to the memory space? Like suggested by Florian Weimer, likely the most efficient approach is to access the data using MLton.Pointer. The attached files contain an example of a way to do it. The example contains the beginnings of a RawVector module that allows one to mmap a file and access it similarly to an ordinary vector. As an example, it opens a file ("data"), prints the length of the resulting RawVector and then prints all the elements of the RawVector. For (my) convenience, the example makes (rather minimal) use of an extended basis library from the "mltonlib" repository. You can check out the mltonlib repository with the following command: svn co svn://mlton.org/mltonlib/trunk mltonlib You'll then need to modify the Build.sh script to point to the location of mltonlib in order to build the example with the script. -Vesa Karvonen -------------- next part -------------- A non-text attachment was scrubbed... Name: Build.sh Type: application/x-sh Size: 254 bytes Desc: not available Url : http://mlton.org/pipermail/mlton-user/attachments/20081011/3d0800ed/Build.sh -------------- next part -------------- A non-text attachment was scrubbed... Name: data Type: application/octet-stream Size: 8 bytes Desc: not available Url : http://mlton.org/pipermail/mlton-user/attachments/20081011/3d0800ed/data.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: mmap.c Type: text/x-csrc Size: 554 bytes Desc: not available Url : http://mlton.org/pipermail/mlton-user/attachments/20081011/3d0800ed/mmap.c -------------- next part -------------- A non-text attachment was scrubbed... Name: mmap.mlb Type: application/octet-stream Size: 226 bytes Desc: not available Url : http://mlton.org/pipermail/mlton-user/attachments/20081011/3d0800ed/mmap.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: mmap.sml Type: application/octet-stream Size: 2273 bytes Desc: not available Url : http://mlton.org/pipermail/mlton-user/attachments/20081011/3d0800ed/mmap-0001.obj From tuulos at gmail.com Fri Oct 10 21:49:05 2008 From: tuulos at gmail.com (Ville Tuulos) Date: Fri Oct 10 21:49:10 2008 Subject: [MLton-user] How to access large amounts of data through FFI In-Reply-To: <9e43b9a0810101606m550ffc92m8f297a77a5001763@mail.gmail.com> References: <12fdabad0810101124y2eabbe38q5ba00e6938c6b015@mail.gmail.com> <9e43b9a0810101606m550ffc92m8f297a77a5001763@mail.gmail.com> Message-ID: <12fdabad0810102149v715b748etcb70b50b3deded99@mail.gmail.com> On Fri, Oct 10, 2008 at 4:06 PM, Vesa Karvonen wrote: > On Fri, Oct 10, 2008 at 9:24 PM, Ville Tuulos wrote: >> How to construct and pass a valid int vector from C to SML through >> Mlton's FFI, preferably without copying the data first? > > Unfortunately, you can't access a mmapped region of memory as an > ordinary SML vector, because ordinary SML vectors live in MLton's > garbage collected heap (and have a special header for MLton's runtime > and may be moved by MLton's GC). ok. Good to know. >> The FFI interface seems pretty straighforward but I couldn't find any >> documentation how arrays and vectors should be initialized based on a >> C pointer and size of the data. Or, if the int vector is not a good >> idea, what would be a better way to get access to the memory space? > > Like suggested by Florian Weimer, likely the most efficient approach > is to access the data using MLton.Pointer. ok. Thanks for the suggestion. > The attached files contain an example of a way to do it. The example > contains the beginnings of a RawVector module that allows one to mmap > a file and access it similarly to an ordinary vector. As an example, > it opens a file ("data"), prints the length of the resulting RawVector > and then prints all the elements of the RawVector. > > For (my) convenience, the example makes (rather minimal) use of an > extended basis library from the "mltonlib" repository. You can check > out the mltonlib repository with the following command: > > svn co svn://mlton.org/mltonlib/trunk mltonlib > > You'll then need to modify the Build.sh script to point to the > location of mltonlib in order to build the example with the script. Perfect! This is exactly what I need. Actually when I got the Florian's reply about MLton.Pointer, I started to consider writing something like RawVector which would support map, foldl etc. over mmaped memory. Going through your code will be even better exercise for me. Thanks! Ville From vesa.a.j.k at gmail.com Sat Oct 11 05:47:49 2008 From: vesa.a.j.k at gmail.com (Vesa Karvonen) Date: Sat Oct 11 05:47:54 2008 Subject: [MLton-user] How to access large amounts of data through FFI In-Reply-To: <12fdabad0810102149v715b748etcb70b50b3deded99@mail.gmail.com> References: <12fdabad0810101124y2eabbe38q5ba00e6938c6b015@mail.gmail.com> <9e43b9a0810101606m550ffc92m8f297a77a5001763@mail.gmail.com> <12fdabad0810102149v715b748etcb70b50b3deded99@mail.gmail.com> Message-ID: <9e43b9a0810110547t1e1d9f26o9e6d8ea7c51f8593@mail.gmail.com> On Sat, Oct 11, 2008 at 7:49 AM, Ville Tuulos wrote: [...] > Actually when I got the Florian's reply about MLton.Pointer, I started > to consider writing something like RawVector which would support map, > foldl etc. over mmaped memory. Going through your code will be even > better exercise for me. I extended my example somewhat. The most significant change in the attached version is that it uses MLton's finalizers (http://mlton.org/MLtonFinalizable) to munmap the mapped region automatically when the RawVector is garbage collected. This can be convenient, but assuming that the mapped file is large, it is usually best to free (munmap) it explicitly (which is also supported), because it might take a long time before the finalizers are run. The use of finalizers also adds some "access overhead" to the RawVector implementation and also has some other effects. For something like the sub operation the access overhead may be significant. Aggregate operations (foldl, find, app, ...) only incur the access overhead once. Implementing map, i.e. a function of type ('a -> 'b) -> 'a t -> 'b t, for something like RawVector is not entirely straightforward. The main problem is that if one is using it to map very large files to memory, like suggested in your initial message, then creating a new RawVector by mapping a function over it is likely to be inefficient. Rather than use map, it is probably better to use "lower level" functions like foldl directly or use lazy sequence of some form. One possibility would be to use "iterator combinators" or something similar that allows you to lazily map over the raw vector. Iterator combinators are explained on the http://mlton.org/ForLoops page (note that RawVector.for is essentially an iterator function and can be used with iterator combinators) and there is a module implementing iterator combinators in the extended basis library (http://mlton.org/cgi-bin/viewsvn.cgi/mltonlib/trunk/com/ssh/extended-basis/unstable/public/control/iter.sig?view=auto). -Vesa Karvonen -------------- next part -------------- A non-text attachment was scrubbed... Name: mmap.c Type: text/x-csrc Size: 873 bytes Desc: not available Url : http://mlton.org/pipermail/mlton-user/attachments/20081011/7483a834/mmap.c -------------- next part -------------- A non-text attachment was scrubbed... Name: mmap.mlb Type: application/octet-stream Size: 226 bytes Desc: not available Url : http://mlton.org/pipermail/mlton-user/attachments/20081011/7483a834/mmap.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: mmap.sml Type: application/octet-stream Size: 5053 bytes Desc: not available Url : http://mlton.org/pipermail/mlton-user/attachments/20081011/7483a834/mmap-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: Build.sh Type: application/x-sh Size: 254 bytes Desc: not available Url : http://mlton.org/pipermail/mlton-user/attachments/20081011/7483a834/Build.sh From seanmcl at gmail.com Tue Oct 21 07:10:41 2008 From: seanmcl at gmail.com (Sean McLaughlin) Date: Tue Oct 21 07:10:48 2008 Subject: [MLton-user] new warn unused anomoly Message-ID: <6579f8680810210710n6f381b29vdc876dc74190305d@mail.gmail.com> Hi, I just wanted to contribute a warn-unused anomaly that doesn't occur on http://mlton.org/WarnUnusedAnomalies. It regards pattern matching in records: structure Tmp = struct datatype record = R of {x : int * int} fun doit () = let val record = R {x = (1, 2)} val R {x as (y, z)} = record in print (Int.toString (y + z) ^ "\n") end val _ = doit() end mlton -default-ann 'warnUnused true' tmp.sml flags x as an unused variable, even when y, z are used and necessary to extract y,z by pattern matching. Best, Sean From vesa.a.j.k at gmail.com Tue Oct 21 08:09:24 2008 From: vesa.a.j.k at gmail.com (Vesa Karvonen) Date: Tue Oct 21 08:09:27 2008 Subject: [MLton-user] new warn unused anomoly In-Reply-To: <6579f8680810210710n6f381b29vdc876dc74190305d@mail.gmail.com> References: <6579f8680810210710n6f381b29vdc876dc74190305d@mail.gmail.com> Message-ID: <9e43b9a0810210809k3853b5f1wf61622fedfea089b@mail.gmail.com> On Tue, Oct 21, 2008 at 5:10 PM, Sean McLaughlin wrote: > I just wanted to contribute a warn-unused anomaly that doesn't occur > on http://mlton.org/WarnUnusedAnomalies. It regards pattern matching > in records: > > structure Tmp = > struct > > datatype record = R of {x : int * int} > > fun doit () = > let > val record = R {x = (1, 2)} > val R {x as (y, z)} = record > in > print (Int.toString (y + z) ^ "\n") > end Actually, this isn't a warn-unused anomaly. When you write label as pattern the label is bound, but when you write label = pattern the label isn't bound. So, if you write val R {x = (y, z)} = record you shouldn't get the unused warning. BTW, I hadn't personally noticed that SML's grammar has the "label as pattern" pattern --- I had to check this from the Definition. So, thanks for reporting this! :-) -Vesa Karvonen