Dear Cafe,
I was wondering if there exists a tool to approximate what would be the
minimal versions of the dependencies required by a package.
I know that calculating this exactly is a bit intractable, but I was
considering whether a tool that works as follows would work:
1) Compile the package with known to work dependencies
2) For each version of dependency as d:
For each function in d used by My Package:
* Perform unification of the resulting type when compiled with
known to work dependencies
and the type exported by the api of the version of the
dependency in consideration.
If all unifications succeeds, mark the version as compatible,
incompatible otherwise
This approximation is obviously not complete. Nevertheless, I would like to
get opinions about whether this would be a good/useful/feasible
approximation? Does the current GHC api export enough functionality for
this package to be feasible? Are there alternatives? I was consider doing
this as my `hack` during the high energy, intense no-sleep jacobsHack!
<http://jacobshack.com> hackathon, do you think it would be a good idea?
Thank you for the opinions and best regards,
Ernesto Rodriguez
--
Ernesto Rodriguez
Masters Student
Computer Science
Utrecht University
www.netowork.megithub.com/netogallo
https://github.com/blitzcode/ray-marching-distance-fields
"This project is a Haskell and GLSL program containing my distance field / ray marching related
experiments. The Haskell viewing application is doing the pre-processing, functioning as a
development and debugging aid, allowing different shaders to be explored. It automatically reloads
and recompiles shaders when they change, showing an overlay displaying any errors. There's a
flexible frame buffer system, supporting under and super sampling and saving of screenshots. Tiled
rendering avoids shader timeouts and unresponsive UI. It also features offline convolution of
environment maps with a filter kernel to enable fast lighting of diffuse and glossy surfaces. Finally,
there's an implementation of the Mandelbulb fractal as well as several simpler ones like Mandelbrot
and Julia sets. There's some more functionality in the program, try it out and / or visit my website."
Cheers,
Tim
I was very tangentially involved with a use-after-close IO descriptor fault
recently, and I came to realize that descriptor indexes are typically
allocated by the smallest available index, Previously, I had erroneously
believed that the indexes were sequentially allocated by an ever-increasing
counter, until wrap-around occurs.
Obviously, the smallest available index allocation strategy makes
use-after-close faults rather more significant, because in a server
application that is constantly closing and allocating descriptors, it
makes it rather more likely that an erroneous operation will actually have
a tangible effect, and not simply return an EINVAL or similar errno.
So in my low-level linux-inotify binding, I felt it wise to add protection
against use-after-close faults. The approach I'm currently investigating
is the obvious one: to (conceptually) represent the inotify socket by a
"MVar (Maybe Fd)" value.
However, if there's no file system events to read from the socket, we
want to call threadWaitRead, So somewhere there's some code that's
essentially this:
readMVar inotifyfd >>= maybe (throwIO ...) threadWaitRead
So the problem is, what happens when the thread executing this snippet
yields in between the readMVar and the threadWaitRead? It would then
be possible for another thread (or two) to close the inotify descriptor,
and then allocate another descriptor with the same index. The first
thread would then end up blocking until the new descriptor becomes
readable, after which the thread would re-read the MVar and throw an
exception that the descriptor has been closed.
This is a _relatively_ benign effect, but still, it does prevent the
waiting thread from throwing an exception at the earliest possible moment,
and there are several particularly unlucky scenarios I can think of where
such a thread could be waiting on the wrong descriptor for a very long
time. Not to mention that this is a whole family of race conditions,
which I haven't really explored the other possible manifestations of which
might not be as benign.
Somebody did also point me to the new threadWaitReadSTM primitives, but
this doesn't cover this use case although the original proposal (properly
implemented, of course) would:
http://www.haskell.org/ghc/docs/7.8.3/html/libraries/base-4.7.0.1/Control-C…https://ghc.haskell.org/trac/ghc/ticket/7216
In any case, my linux-inotify binding is available on github; the
current main branch is unreleased and also has code to attempt to make
reading from a descriptor a thread-safe operation. However I'm not too
enthusiastic about this unreleased code at the moment, and am considering
throwing it out. However, I'd still very much like to add protection
against use-after-close faults, and I'd certainly prefer being able to
concurrently call both close and read on the descriptor with complete
safety.
https://github.com/lpsmith/linux-inotify
Best,
Leon
I spent a few moments confused by the fact the TypeOperators was insufficient to allow the following type to be parsed
constA :: Arrow (~>) => b -> (a ~> b)
My current intuition is that since I *can* write things like
newtype (~>) a b = A (a -> b)
there is clashing in the type operator space for “upper case” and “lower case” identifiers. Is it possible or advisable to mitigate this clash and provide some syntax for “type operator variables”?
Joseph
Hello,
Please, find below the third call for papers for IFL 2014.
The submission page is now open. The submission date has been
delayed to Sep. 8 2014 anywhere on the world.
Please forward these to anyone you think may be interested.
Apologies for any duplicates you may receive.
best regards,
Jurriaan Hage
---
CALL FOR PAPERS
26th SYMPOSIUM ON IMPLEMENTATION AND APPLICATION OF FUNCTIONAL LANGUAGES - IFL 2014
NORTHEASTERN UNIVERSITY/BOSTON, USA
OCTOBER 1-3, 2014
http://ifl2014.github.io
We are pleased to announce that the 26th edition of the IFL series
will be held at Northeastern University in Boston, USA. The symposium
will be held from 1st to 3rd of October 2014.
Scope
-----
The goal of the IFL symposia is to bring together researchers actively
engaged in the implementation and application of functional and
function-based programming languages. IFL 2014 will be a venue for
researchers to present and discuss new ideas and concepts, work in
progress, and publication-ripe results related to the implementation
and application of functional languages and function-based
programming.
Following the IFL tradition, IFL 2014 will use a post-symposium review
process to produce the formal proceedings. All participants of IFL
2014 are invited to submit either a draft paper or an extended
abstract describing work to be presented at the symposium. At no time
may work submitted to IFL be simultaneously submitted to other venues;
submissions must adhere to ACM SIGPLAN's republication policy:
http://www.sigplan.org/Resources/Policies/Republication
The submissions will be screened by the program committee chair to
make sure they are within the scope of IFL, and will appear in the
draft proceedings distributed at the symposium. Submissions appearing
in the draft proceedings are not peer-reviewed publications. Hence,
publications that appear only in the draft proceedings do not count as
publication for the ACM SIGPLAN republication policy. After the
symposium, authors will be given the opportunity to incorporate the
feedback from discussions at the symposium and will be invited to
submit a revised full article for the formal review process. From the
revised submissions, the program committee will select papers for the
formal proceedings considering their correctness, novelty,
originality, relevance, significance, and clarity.
Submission Details
------------------
Submission deadline draft papers: September 8
Notification of acceptance for presentation: September 10
Early registration deadline: September 11
Late registration deadline: September 17
Submission deadline for pre-symposium proceedings: September 24
26th IFL Symposium: October 1-3
Submission deadline for post-symposium proceedings: December 15
Notification of acceptance for post-symposium proceedings: January 31 2015
Camera-ready version for post-symposium proceedings: March 15 2015
Prospective authors are encouraged to submit papers or extended
abstracts to be published in the draft proceedings and to present them
at the symposium. All contributions must be written in English. Papers
must adhere to the standard ACM two columns conference format. For the
pre-symposium proceedings we adopt a 'weak' page limit of 12
pages. For the post-symposium proceedings the page limit of 12 pages
is firm. A suitable document template for LaTeX can be found at:
http://www.acm.org/sigs/sigplan/authorInformation.htm
Papers should be submitted online at https://easychair.org/conferences/?conf=ifl2014
Topics
------
IFL welcomes submissions describing practical and theoretical work as
well as submissions describing applications and tools in the context
of functional programming. If you are not sure whether your work is
appropriate for IFL 2014, please contact the PC chair at
samth(a)cs.indiana.edu. Topics of interest include, but are not limited
to:
• language concepts
• type systems, type checking, type inferencing
• compilation techniques
• staged compilation
• run-time function specialization
• run-time code generation
• partial evaluation
• (abstract) interpretation
• metaprogramming
• generic programming
• automatic program generation
• array processing
• concurrent/parallel programming
• concurrent/parallel program execution
• embedded systems
• web applications
• (embedded) domain specific languages
• security
• novel memory management techniques
• run-time profiling performance measurements
• debugging and tracing
• virtual/abstract machine architectures
• validation, verification of functional programs
• tools and programming techniques
• (industrial) applications
Peter Landin Prize
------------------
The Peter Landin Prize is awarded to the best paper presented at the
symposium every year. The honoured article is selected by the program
committee based on the submissions received for the formal review
process. The prize carries a cash award equivalent to 150 Euros.
Programme committee
-------------------
Sam Tobin-Hochstadt, Indiana University (Chair)
Rinus Plasmeijer, Radboud University Nijmegen (Co-Chair)
Atze Dijkstra, Utrecht University
Colin Runciman, University of York
Graham Hutton, University of Nottingham
Mary Sheeran, Chalmers University of Technology
Patricia Johann, Appalachian State University
Matthew Fluet, Rochester Institute of Technology
Josef Svenningsson, Chalmers University of Technology
Małgorzata Biernacka, University of Wroclaw
Peter Achten, Radboud Univerity Nijmegen
Laura Castro, University of A Coruña
Hai Paul Liu, Intel Labs
Kathryn Gray, Cambridge University
Lars Bergstrom, Mozilla Research
Lindsey Kuper, Indiana University
Nicolas Wu, Oxford
T. Stephen Strickland, University of Maryland
Xavier Clerc, INRIA
Venue
-----
The 26th IFL will be held in association with the College of Computer
and Information Science at Northeastern University. It can be reached
quickly and easily by public transport.
