<\/a>Mathias Bourgoin presenting SPOC<\/p><\/div>This is the OCaml Users and Developers Workshop 2014 in Gothenburg.<\/p>\n
Parallel OCaml? Lots of libraries. One is SPOC = Stream Processing OCaml (with OpenCL).<\/p>\n
GPGPU programming. Two main frameworks: Cuda and OpenCL. Use different languages to write kernels (Assembly or C\/C++ subset) and to manage kernels (more or less any general purpose language can be used here).<\/p>\n
SPOC compiles to Cuda or OpenCL. It contains the Sarek DSL and a runtime.<\/p>\n
WebSpoc: compile OCaml with SPOC and then to JS with js_of_ocaml.<\/p>\n
Demo: Using SPOC from within a browser to do image manipulation.<\/p>\n
WebSpoc helps develop complex web apps with intensive computations. Good for GPGPU courses.<\/p>\n
Future work: add a JS memory manager dedicated to SPOC vectors; add bindings to WebGL.<\/p>\n
Demo online: http:\/\/mathiasbourgoin.github.io\/SPOC\/tutos\/OCaml2014.html<\/p>\n
SPOC and Sarek are available in OPAM.<\/p>\n
Q: Is there potential to run this code on the GPU of a mobile phone?
\nA: Not yet.<\/p>\n
Using Preferences to Tame your Package Manager, Roberto Di Cosmo (presenting, D+I), Pietro Abate (D), Stefano Zacchiroli (D), Fabrice Le Fessant (I), Louis Gesbert (OCamlPro); (D = Universit\u00e9 Paris Diderot, I = INRIA)<\/i><\/p>\n
Ten years of research on package management -- EDOS and MANCOOSI, bridging research communities. Used as foundation of OPAM.<\/p>\n
LOTS of package managers out there! Binary, source, language specific, application specific, decentralized, functional approach.<\/p>\n
What's inside? Two sides: people maintaining packages (server side) -- maintain a coherent set of packages. Also \"client side\" -- fetch and authenticate metadata and packages, resolve dependencies, user preferences.<\/p>\n
Dependency solving: installability of a single package and co-installability of a set of packages are NP-complete problems.<\/p>\n
Application: find uninstallable packages in a repository: just call a SAT solver on each package in the repository! (\"dose\" library is specialized for this task)<\/p>\n
ows.irill.org is the OPAM Weather Service -- shows which packages can be installed together.<\/p>\n
Finding a solution is NP-complete but installing and upgrading is more demanding -- how many ways are there to install a package? Exponentially many.<\/p>\n
Towards modular package managers. 0. stop coding a petty solver for every new component base system; 1. use a common upgrade description format; 2. provide means for expressing user choice.<\/p>\n
User preferences: built from four ingredients. Package selectors, measurements, maximisation\/minimisation, aggregation.<\/p>\n
Example for minimisation: -count(removed)<\/code> -- we want a solution where the number of removed packages is minimised.<\/p>\nExample profiles:<\/p>\n
\"Paranoid\": -count(removed),-count(changed)<\/code>
\n\"Trendy\": -count(removed),-notuptodate(solution),-count(new)<\/code><\/p>\nSlightly more exotic:<\/p>\n
\"Minimal system\": -sum(solution,installedsize),-count(solution)<\/code>
\n\"Noah's ark\": +count(solution)<\/code>
\n\"Fast bootstrap\": -sum(solution,compiletime)<\/code><\/p>\nRepairing a broken system configuration:<\/p>\n
\"Fixup simple\": -count(changed)<\/code>
\n\"Fixup trendy\": -count(changed),-count(down),-notuptodate(solution)<\/code><\/p>\nThis is all possible with OPAM 1.2! (Check opam --help, look for --criteria)<\/p>\n
You can help: try different profiles, test expressivity of the preference language, help debug OPAM.<\/p>\n
Conclusion: package managers are complex; a very hard part is dependency solving! Modern package managers must share common components, in particular dependency solvers and the user preference language.<\/p>\n
Q: Does this keep track of explicitly installed packages?
\nA: Yes, OPAM knows which packages were installed directly (the \"root set\") and which were installed in order to satisfy dependencies.<\/p>\n
Q: Why don't other package managers use this technology now?
\nA: Package managers are core parts of any system so people tend to be very resilient to change.<\/p>\n
Simple, efficient, sound-and-complete combinator parsing for all context-free grammars, using an oracle (*), by Tom Ridge (University of Leicester)<\/i><\/p>\n
The P3 combinator parsing library. Can handle all context-free grammars (CFGs). Scannerless or can use a lexer. Good theoretical basis, but slow.<\/p>\n
Example given.<\/p>\n
Memoized counting -- you can't do this with any other parser!<\/p>\n
Compute actions over all good parse trees; there are exponentially many such parse trees, but this doesn't have to take exponential time!<\/p>\n
Disambiguation: directly encode in code with using \"option\".<\/p>\n
Supports modular combination, e.g. \"helper parsers\".<\/p>\n
Comparison with Happy: it's faster, in some cases ridiculously so.<\/p>\n
Long term aim: general parser, verified correctness and performance, usable in the real world.<\/p>\n
Q: What's the use case?
\nA: It's extremely flexible, but slower than deterministic parsers.<\/p>\n","protected":false},"excerpt":{"rendered":"
Welcome Many submissions this year so a few had to be squeezed into “short talk” slots. Session 1: Runtime system Multicore OCaml, by Stephen Dolan (presenting), Leo White, Anil Madhavapeddy (University of Cambridge) Still work in progresss. Concurrency v. parallelism. Concurrency: for writing programs (e.g. handle 10000 connections at once). Parallelism is for performance (e.g. […]<\/p>\n","protected":false},"author":39,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[6,30],"tags":[],"_links":{"self":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1831"}],"collection":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/users\/39"}],"replies":[{"embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/comments?post=1831"}],"version-history":[{"count":11,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1831\/revisions"}],"predecessor-version":[{"id":2357,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/posts\/1831\/revisions\/2357"}],"wp:attachment":[{"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/media?parent=1831"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/categories?post=1831"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.syslog.cl.cam.ac.uk\/wp-json\/wp\/v2\/tags?post=1831"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}