ivan.lanese | 12 Feb 15:30 2016

FORTE 2016: further 1 week deadline extension (fwd)

The deadlines for FORTE 2016, both the one for abstract and the one for paper 
submission, have been extended by 1 additional week. The new deadlines are 
February 15 and February 22, respectively. You can find below the updated call 
for papers. Please note that FORTE allows also short papers and tool 
demonstration papers.

Best wishes,
Elvira and Ivan


FORTE 2016 Call for Papers
36th IFIP International Conference on Formal Techniques for Distributed 
Objects, Components and Systems

Part of the DisCoTec 2016 event
6-9 June 2016, Aquila Atlantis Hotel, Heraklion, Crete

FORTE 2016 is a forum for fundamental research on theory, models,
tools, and applications for distributed systems. The conference
solicits original contributions that advance the science and
technologies for distributed systems, with special interest in the
areas of:

- service-oriented, ubiquitous, pervasive, grid, cloud, and mobile
computing systems;
- object technology, modularity, component- and model-based design;
- software reliability, availability, and safety;
(Continue reading)

Marco Bernardo | 12 Feb 15:04 2016

SFM-16:QUANTICOL second call for participation (Bertinoro, 20-24 June 2016)

*                                                         *
*                     SFM-16:QUANTICOL                    *
*                                                         *
*               16th International School on              *
*             Formal Methods for the Design of            *
*      Computer, Communication and Software Systems:      *
*  Quantitative Evaluation of Collective Adaptive Systems *
*                                                         *
*           Bertinoro (Italy), 20-24 June 2016            *
*                                                         *
*     http://www.sti.uniurb.it/events/sfm16quanticol/     *
*                                                         *
*                 CALL FOR PARTICIPATION                  *
*                (deadline: 21 March 2016)                *


Formal methods are emerging in computer science as a prominent
approach to the rigorous design of computer, communication and
software systems.

The aim of the SFM series is to offer a good spectrum of
current research in foundations as well as applications of
formal methods, which can be of interest for graduate students
and young researchers who intend to approach the field.
(Continue reading)

Anton Bachin | 11 Feb 20:04 2016

[ANN] Lambda Soup 0.6 + Markup.ml 0.7 – Improved HTML5 processing


I would like to announce releases 0.6 of Lambda Soup, the CSS-selector-based
HTML scraper and rewriter, and 0.7 of Markup.ml, the streaming HTML and XML


The main change in Lambda Soup is that is is now based on Markup.ml instead of
Ocamlnet. As a result,

- parsing now conforms closely to the HTML5 specification, including error
- HTML entity references are translated;
- encodings are detected automatically, Lambda Soup is no longer limited to
  ASCII-compatible input, and all strings emitted by the API are in UTF-8; and
- empty attributes are handled correctly.

Lambda Soup can now accept and emit Markup.ml parsing signal streams, so it can
be used for filters, without having to parse directly from or serialize all the
way to strings. It can also be used safely with XML. Parsing is, however, much
slower – this depends on Markup.ml being optimized in the future.

The HTML parser in Markup.ml, in turn, now implements the adoption agency
algorithm, an error recovery algorithm from the HTML5 specification that is
ill-suited for streaming parsers. It is also more thouroughly tested, and has
received many bugfixes.

I must thank Jerome Vouillon and Leo Wzukw for bug reports. They are greatly
(Continue reading)

Philippe Veber | 11 Feb 15:11 2016

Accessing values calculated by Toploop.execute_phrase

Dear list,

  I'm having quite some fun interacting with the toplevel using `Toploop` and co., and I am now looking for a way to get the values created during a call to `Toploop.execute_phrase`, which sadly only returns a boolean. I would like to get these values as `Obj.t` values, so that I could perform additional computations for certain types.

I'm almost there but not yet:
  - I can find which values were created and what's their type by collecting `Outcometree.out_path` values when they are printed, but this doesn't give access to the actual value (represented as an `Obj.t`).
  - I could use `Toploop.getvalue`, but then I could not get results of evaluations that were not bound to a variable.

Of course I know what I'm trying to do is highly unsafe, so I should probably think of some other design. Still, out of curiosity, I'd be interested if somebody knew a solution to this (I mean, besides "Don't do it" :).


anil.kottikunnath | 11 Feb 12:24 2016

ocaml source files needed

Dear Team,


Could you please share the Source file /Tar file for the below RPM packages. We couldn’t find it in the official websites.



ocaml-camlp4-4.02.3-8.1.x86_64 (https://github.com/ocaml/camlp4/archive/4.02+1.tar.gz )



ocaml-4.02.3-5.1.x86_64   ( http://caml.inria.fr/pub/distrib/ ocaml -4.02/ ocaml -4.02.3.tar.gz )




Best Regards,



The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
Louis Roché | 11 Feb 00:49 2016

Prochain meetup OUPS 16 février 2016 / Next OUPS meetup, 16th of February 2016

(English version below) 

Bonjour, Le prochain meetup OUPS aura lieu mercredi 16 février.
Le lieu du rendez-vous a changé ! Nous nous retrouverons cette fois dans les locaux de Jussieu (4 Place Jussieu - Paris).
Les présentations commenceront à 19h (pour environ 1h30) et seront suivis du pot habituel.

Le programme des exposés confirmés jusqu'ici:

- François Bobot: OCI - For All Your Continuous Integration and Benchmarking Needs
- Rémy El Sibaïe Besognet: Pendulum - une extension réactive pour la programmation Web en OCaml
- Pierre Chambart: "Je vais casser votre code !"

Nous profitons de l'occasion pour rappeler que nous sommes toujours en
demande de *propositions* d'exposés sur les sujets de votre choix pour
les meetups suivants.

Pour vous inscrire, ou pour plus d'informations rendez vous ici:
*L’inscription est nécessaire pour pouvoir accéder au bâtiment !*

Vous pouvez retrouver les slides des dernières sessions ici:

Université Pierre et Marie Curie (Paris V)
4 Place Jussieu
75005 Paris

Les organisateurs du meetup.



The next OUPS meetup will take place on the 16th of February 7pm, at
Jussieu (4 Place Jussieu - Paris). We will have a few talks, followed by

The talks will be the following:

- François Bobot: OCI - For All Your Continuous Integration and Benchmarking Needs
- Rémy El Sibaïe Besognet: Pendulum - une extension réactive pour la programmation Web en OCaml
- Pierre Chambart: "Je vais casser votre code !"
Note that we are always in demand of talk *proposals* for future

To register, or for more information, go here:
*Registration is required!*

Slides from previous sessions are available online:

Université Pierre et Marie Curie (Paris V)
4 Place Jussieu
75005 Paris
The meetup organizers.
Anton Bachin | 10 Feb 16:33 2016

[ANN] Bisect_ppx 1.0.0 – Modernized code coverage for OCaml


We would like to announce the release of Bisect_ppx 1.0.0, a code coverage tool
for OCaml with appealing reports:


You can see a live coverage report here:


Reports can also be submitted to Coveralls.io using ocveralls [1]. See an
example here [2].

Bisect_ppx is a fork of the original Bisect by Xavier Clerc, with extensive
further development. Differences from Bisect, and from earlier versions of
Bisect_ppx, include:

- the nicer and more legible HTML reports,
- more thorough instrumentation, now including nested functions and or-patterns,
- improved compatibility with other PPX rewriters,
- an Ocamlbuild plugin,
- many bugfixes, and
- usage, performance, and documentation improvements.

Bisect_ppx was originally forked to update and maintain Bisect's PPX mode, with
the OCaml community moving to PPX. Bisect_ppx does not have Bisect's Camlp4
dependency. We do not believe that the original Bisect is being actively

Anton & Leonid

P.S. If you are working on a project that uses Bisect_ppx, please let us know!

[1]: https://github.com/sagotch/ocveralls
[2]: https://coveralls.io/builds/4913198/source?filename=src%2Fsyntax%2FinstrumentPpx.ml


Caml-list mailing list.  Subscription management and archives:
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Daniel Bünzli | 9 Feb 14:35 2016

ocamlbuild, build a source that starts with _


It seems I can't convince ocamlbuild to build (i.e. copy) a source that starts with `_`. 
Is there a workaround ? 

  mkdir -p /tmp/test
  cd /tmp/test/
  touch _bla.c
  ocamlbuild _bla.c
  Solver failed:
  Ocamlbuild knows of no rules that apply to a target named _bla.c. This can happen if you    ask Ocamlbuild to
build a target with the wrong extension (e.g. .opt instead of .native) or if the source files live in
directories that have not been specified as include directories.
Compilation unsuccessful after building 0 targets (0 cached) in 00:00:00.



Caml-list mailing list.  Subscription management and archives:
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Benjamin Canou | 9 Feb 12:07 2016

[ANN] Source code for the OCaml-MOOC exercise environment

Hi all, We just released the source code of the exercise environment that OCamlPro developed for the first session of the OCaml MOOC. It includes the whole platform (code editor, toplevel, automatic grader), and a few demo exercises. You can download the source (mostly LGPLv2, some parts under GPLv2): https://try.ocamlpro.com/fun-demo/tryocaml-fun.tgz We also put a standalone demo in which you can try a few exercises: https://try.ocamlpro.com/fun-demo/tryocaml_index.html More details are available here: https://try.ocamlpro.com/fun-demo/ Regards, Benjamin Canou.
Lindsey Kuper | 9 Feb 07:09 2016

ICFP 2016 Second Call for Papers

                              ICFP 2016
The 21st ACM SIGPLAN International Conference on Functional Programming
                        Second Call for Papers

Important dates

Submissions due:    Wednesday, March 16 2016, 15:00 (UTC)
                    (now open)
Author response:    Monday, 2 May, 2016, 15:00 (UTC) -
                    Thursday, 5 May, 2016, 15:00 (UTC)
Notification:       Friday, 20 May, 2016
Final copy due:     TBA
Early registration: TBA
Conference:         Monday, 19 September -
                    Wednesday, 21 September, 2016
                    (note updated conference dates)


ICFP 2016 seeks original papers on the art and science of functional
programming. Submissions are invited on all topics from principles to
practice, from foundations to features, and from abstraction to
application. The scope includes all languages that encourage
functional programming, including both purely applicative and
imperative languages, as well as languages with objects, concurrency,
or parallelism. Topics of interest include (but are not limited to):

- Language Design: concurrency, parallelism, and distribution;
  modules; components and composition; metaprogramming; type systems;
  interoperability; domain-specific languages; and relations to
  imperative, object-oriented, or logic programming.

- Implementation: abstract machines; virtual machines; interpretation;
  compilation; compile-time and run-time optimization; garbage
  collection and memory management; multi-threading; exploiting
  parallel hardware; interfaces to foreign functions, services,
  components, or low-level machine resources.

- Software-Development Techniques: algorithms and data structures;
  design patterns; specification; verification; validation; proof
  assistants; debugging; testing; tracing; profiling.

- Foundations: formal semantics; lambda calculus; rewriting; type
  theory; monads; continuations; control; state; effects; program
  verification; dependent types.

- Analysis and Transformation: control-flow; data-flow; abstract
  interpretation; partial evaluation; program calculation.

- Applications: symbolic computing; formal-methods tools; artificial
  intelligence; systems programming; distributed-systems and web
  programming; hardware design; databases; XML processing; scientific
  and numerical computing; graphical user interfaces; multimedia and
  3D graphics programming; scripting; system administration; security.

- Education: teaching introductory programming; parallel programming;
  mathematical proof; algebra.

- Functional Pearls: elegant, instructive, and fun essays on
  functional programming.

- Experience Reports: short papers that provide evidence that
  functional programming really works or describe obstacles that have
  kept it from working.

If you are concerned about the appropriateness of some topic, do not
hesitate to contact the program chair.

Abbreviated instructions for authors

- By Wednesday, March 16 2016, 15:00 (UTC), submit a full paper of at
  most 12 pages (6 pages for an Experience Report), in standard
  SIGPLAN conference format, including figures but ***excluding

The deadlines will be strictly enforced and papers exceeding the page
limits will be summarily rejected.

***ICFP 2016 will employ a lightweight double-blind reviewing
process.*** To facilitate this, submitted papers must adhere to two

 1. ***author names and institutions must be omitted***, and

 2. ***references to authors' own related work should be in the third
    person*** (e.g., not "We build on our previous work ..." but
    rather "We build on the work of ...").

The purpose of this process is to help the PC and external reviewers
come to an initial judgement about the paper without bias, not to make
it impossible for them to discover the authors if they were to
try. Nothing should be done in the name of anonymity that weakens the
submission or makes the job of reviewing the paper more difficult
(e.g., important background references should not be omitted or
anonymized). In addition, authors should feel free to disseminate
their ideas or draft versions of their paper as they normally
would. For instance, authors may post drafts of their papers on the
web or give talks on their research ideas. We have put together a
document answering frequently asked questions that should address many
common concerns:
(last updated February 8, 2016).

- Authors have the option to attach supplementary material to a
  submission, on the understanding that reviewers may choose not to
  look at it. The material should be uploaded at submission time, as a
  single pdf or a tarball, not via a URL. This supplementary material
  may or may not be anonymized; if not anonymized, it will only be
  revealed to reviewers after they have submitted their review of your
  paper and learned your identity.

- Each submission must adhere to SIGPLAN's republication policy, as
  explained on the web at:

- Authors of resubmitted (but previously rejected) papers have the
  option to attach an annotated copy of the reviews of their previous
  submission(s), explaining how they have addressed these previous
  reviews in the present submission. If a reviewer identifies
  him/herself as a reviewer of this previous submission and wishes to
  see how his/her comments have been addressed, the program chair will
  communicate to this reviewer the annotated copy of his/her previous
  review. Otherwise, no reviewer will read the annotated copies of the
  previous reviews.

Overall, a submission will be evaluated according to its relevance,
correctness, significance, originality, and clarity. It should explain
its contributions in both general and technical terms, clearly
identifying what has been accomplished, explaining why it is
significant, and comparing it with previous work. The technical
content should be accessible to a broad audience. Functional Pearls
and Experience Reports are separate categories of papers that need not
report original research results and must be marked as such at the
time of submission. Detailed guidelines on both categories are given

Presentations will be videotaped and released online if the presenter
consents. The proceedings will be freely available for download from
the ACM Digital Library from at least one week before the start of the
conference until two weeks after the conference.

Formatting: Submissions must be in PDF format printable in black and
white on US Letter sized paper and interpretable by
Ghostscript. Papers must adhere to the standard SIGPLAN conference
format: two columns, nine-point font on a ten-point baseline, with
columns 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter
of 2pc (0.33in). A suitable document template for LaTeX is available
at http://www.sigplan.org/Resources/Author/

Submission: Submissions will be accepted at

Improved versions of a paper may be submitted at any point before the
submission deadline using the same web interface.

Author response: Authors will have a 72-hour period, starting at 15:00
UTC on Monday, 2 May, 2016, to read reviews and respond to them.

ACM Author-Izer is a unique service that enables ACM authors to
generate and post links on either their home page or institutional
repository for visitors to download the definitive version of their
articles from the ACM Digital Library at no charge. Downloads through
Author-Izer links are captured in official ACM statistics, improving
the accuracy of usage and impact measurements. Consistently linking
the definitive version of ACM article should reduce user confusion
over article versioning. After your article has been published and
assigned to your ACM Author Profile page, please visit
http://www.acm.org/publications/acm-author-izer-service to learn how
to create your links for free downloads from the ACM DL.

AUTHORS TAKE NOTE: The official publication date is the date the
proceedings are made available in the ACM Digital Library. This date
may be up to two weeks prior to the first day of your conference. The
official publication date affects the deadline for any patent filings
related to published work.

Special categories of papers

In addition to research papers, ICFP solicits two kinds of papers that
do not require original research contributions: Functional Pearls,
which are full papers, and Experience Reports, which are limited to
six pages. Authors submitting such papers may wish to consider the
following advice.

Functional Pearls

A Functional Pearl is an elegant essay about something related to
functional programming. Examples include, but are not limited to:

- a new and thought-provoking way of looking at an old idea
- an instructive example of program calculation or proof
- a nifty presentation of an old or new data structure
- an interesting application of functional programming techniques
- a novel use or exposition of functional programming in the classroom

While pearls often demonstrate an idea through the development of a
short program, there is no requirement or expectation that they do
so. Thus, they encompass the notions of theoretical and educational

Functional Pearls are valued as highly and judged as rigorously as
ordinary papers, but using somewhat different criteria. In particular,
a pearl is not required to report original research, but, it should be
concise, instructive, and entertaining. Your pearl is likely to be
rejected if your readers get bored, if the material gets too
complicated, if too much specialized knowledge is needed, or if the
writing is inelegant. The key to writing a good pearl is polishing.

A submission you wish to have treated as a pearl must be marked as
such on the submission web page, and should contain the words
``Functional Pearl'' somewhere in its title or subtitle. These steps
will alert reviewers to use the appropriate evaluation
criteria. Pearls will be combined with ordinary papers, however, for
the purpose of computing the conference's acceptance rate.

Experience Reports

The purpose of an Experience Report is to help create a body of
published, refereed, citable evidence that functional programming
really works ? or to describe what obstacles prevent it from working.

Possible topics for an Experience Report include, but are not limited

- insights gained from real-world projects using functional

- comparison of functional programming with conventional programming
  in the context of an industrial project or a university curriculum

- project-management, business, or legal issues encountered when using
  functional programming in a real-world project

- curricular issues encountered when using functional programming in

- real-world constraints that created special challenges for an
  implementation of a functional language or for functional
  programming in general

An Experience Report is distinguished from a normal ICFP paper by its
title, by its length, and by the criteria used to evaluate it.

- Both in the proceedings and in any citations, the title of each
  accepted Experience Report must begin with the words ``Experience
  Report'' followed by a colon. The acceptance rate for Experience
  Reports will be computed and reported separately from the rate for
  ordinary papers.

- An Experience Report is at most six pages long. Each accepted
  Experience Report will be presented at the conference, but depending
  on the number of Experience Reports and regular papers accepted,
  authors of Experience reports may be asked to give shorter talks.

- Because the purpose of Experience Reports is to enable our community
  to accumulate a body of evidence about the efficacy of functional
  programming, an acceptable Experience Report need not add to the
  body of knowledge of the functional-programming community by
  presenting novel results or conclusions. It is sufficient if the
  Report states a clear thesis and provides supporting evidence. The
  thesis must be relevant to ICFP, but it need not be novel.

The program committee will accept or reject Experience Reports based
on whether they judge the evidence to be convincing. Anecdotal
evidence will be acceptable provided it is well argued and the author
explains what efforts were made to gather as much evidence as
possible. Typically, more convincing evidence is obtained from papers
which show how functional programming was used than from papers which
only say that functional programming was used. The most convincing
evidence often includes comparisons of situations before and after the
introduction or discontinuation of functional programming. Evidence
drawn from a single person's experience may be sufficient, but more
weight will be given to evidence drawn from the experience of groups
of people.

An Experience Report should be short and to the point: make a claim
about how well functional programming worked on your project and why,
and produce evidence to substantiate your claim. If functional
programming worked for you in the same ways it has worked for others,
you need only to summarize the results?the main part of your paper
should discuss how well it worked and in what context. Most readers
will not want to know all the details of your project and its
implementation, but please characterize your project and its context
well enough so that readers can judge to what degree your experience
is relevant to their own projects. Be especially careful to highlight
any unusual aspects of your project. Also keep in mind that specifics
about your project are more valuable than generalities about
functional programming; for example, it is more valuable to say that
your team delivered its software a month ahead of schedule than it is
to say that functional programming made your team more productive.

If your paper not only describes experience but also presents new
technical results, or if your experience refutes cherished beliefs of
the functional-programming community, you may be better off submitting
it as a full paper, which will be judged by the usual criteria of
novelty, originality, and relevance. If you are unsure in which
category to submit, the program chair will be happy to help you


General Co-Chairs:

Jacques Garrigue (Nagoya University)
Gabriele Keller (University of New South Wales)

Program Chair:

Eijiro Sumii (Tohoku University)

Program Committee:

Koen Claessen (Chalmers University of Technology)
Joshua Dunfield (University of British Columbia, Canada)
Matthew Fluet (Rochester Institute of Technology)
Nate Foster (Cornell University)
Dan Grossman (University of Washington, USA)
Jurriaan Hage (Utrecht University)
Roman Leshchinskiy (Standard Chartered Bank)
Keisuke Nakano (The University of Electro-Communications)
Aleksandar Nanevski (IMDEA Software Institute)
Scott Owens (University of Kent)
Sungwoo Park (Pohang University of Science and Technology)
Amr Sabry (Indiana University)
Tom Schrijvers (KU Leuven)
Olin Shivers (Northeastern University)
Walid Taha (Halmstad University)
Dimitrios Vytiniotis (Microsoft Research, Cambridge)
David Walker (Princeton University)
Nobuko Yoshida (Imperial College London, UK)

External Review Committee:

See http://conf.researchr.org/committee/icfp-2016/icfp-2016-papers-external-review-committee.


Caml-list mailing list.  Subscription management and archives:
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

David Kaloper Meršinjak | 9 Feb 04:07 2016

[ANN] Notty 0.1.0

Dear list,

I'd like to announce the first release of Notty, a terminal library. The blurb:

``Notty is a declarative terminal library for OCaml structured around
a notion of composable images. It tries to abstract away the basic
terminal programming model, and provide one that is simpler and more

The core layout engine and IO codecs are pure platform-independent
OCaml. Distribution includes modules with input and output facilities
for Unix, and Lwt on Unix.

As an attempt to redefine terminal programming, Notty has to be
"opinionated". It assumes Unicode throughout, does not have universal
support for various terminals out there, and has a peculiar
programming and rendering model.''

Feedback is welcome. Samples of unsupported input escapes are welcome
too, and so are complaints about the rendering.

Homepage: https://github.com/pqwy/notty
Docs: http://pqwy.github.io/notty

Many thanks to Daniel Bünzli who helped discard an endless stream of
bad ideas. Sadly, he's not omnipotent.

Daniel's work is also what Notty's solid Unicode support builds upon.



Caml-list mailing list.  Subscription management and archives:
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs