Re: [Caml-list] Let-less syntax for coreML
The underlying question is how to make ML mainstream which is what the Am I the only one to be very, very, very, tired of this question ? There's an obvious thing missing in the list of what has been tried. Well-done and maintained libraries you can use for about any programming task you have at hand -- but I highly doubt this will make ML mainstream either, I'm just defending my own interest. IIRC you used to be a library designer, please stop fiddle with the syntax of the language. Library design is also language design. Pick a missing OCaml library you'd have interest in implementing (e.g. a good interface to imap protocol but you may not be interested in that) and fill in the void with a great, modular and tasteful implementation. Best, Daniel P.S. If you think syntax is the main answer to the question above maybe you should have a chat with users of mainstream programming languages. In my experience, you'll soon see that their tastes and philosophical view points on programming are rather different than yours (which may be due to ignorance, lack of education and marketing influence but that's rather presumptuous for me to say). -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] Semantic Web Journal: Call for Papers on Big Data: Theory and Practice
Deadline: February 13, 2012 Semantic Web Journal: Call for Papers on Big Data: Theory and Practice http://www.semantic-web-journal.net/blog/semantic-web-journal-call-papers-big-data-theory-and-practice Semantic Web Journal Call for Papers on Big Data: Theory and Practice http://www.semantic-web-journal.net The Semantic Web journal calls for innovative and high-quality papers describing theory and practice of storing, accessing, searching, mining, processing, and visualizing big data. We especially invite papers that describe or demonstrate how ontologies, Linked Data, and Semantic Web technologies can handle the problems arising when integrating massive amounts of multi-thematic and multi-perspective information from heterogeneous sources to answer complex questions that cut through domain boundaries. We welcome all paper categories, i.e., full research papers, application reports, systems and tools, ontology papers, as well as surveys, as long as they clearly relate to challenges and opportunities arising from processing big data - see our listing of paper types in the author guidelines. In other words, we expect all submitted manuscripts to address how the presented work can exploit massive and/or heterogeneous data. Topics include but are not limited to Sensor Semantics and Smart Dust Semantics-based Aggregation and Generalization of (Observation) Data Massive Data Integration for the Digital Earth Semantic Interoperability and Heterogeneity Linked Science Knowledge Discovery from Linked Data Mining the Social and Mobile Web Inductive and Abductive Approaches to Ontology Learning Ontology Modularization Ontology Evolution Knowledge Patterns On-the-fly Ontology Alignment and Matching Semantic Translation Distributed Reasoning Handling Uncertainty, Vagueness, and Inconsistencies Ontology-driven Data Visualization Semantics-enabled User Interfaces to Handle Massive Data Trust and Privacy Issues in Publishing and Reasoning about Big Data The User as Knowledge Engineer Semantics-based Negotiation between Domain Experts Dialog and Question Answering Systems based on Linked Data and Ontologies Connecting the Semantic Web with Spatial Data Infrastructures and the Model Web Internet of Things Applications of Linked Data Important Dates Manuscript submission due: 13. February 2012 First notification: 26. March 2012 Issue publication: Summer 2012 Submissions The special issue on Big Data Theory and Practice calls for original high-quality research on any of the above mentioned topics. Authors are requested to follow the author guidelines, submit online as detailed in the author guidelines, and include the name of the call within the submission letter. All manuscripts will be reviewed based on the SWJ open and transparent review policy and will be made available during online the review process. Best Regards, Pascal Hitzler Krzysztof Janowicz Editors-in-Chief -- Prof. Dr. Pascal Hitzler Dept. of Computer Science, Wright State University, Dayton, OH pas...@pascal-hitzler.de http://www.knoesis.org/pascal/ Semantic Web Textbook: http://www.semantic-web-book.org Semantic Web Journal: http://www.semantic-web-journal.net -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Let-less syntax for coreML
On 01/04/2012 08:30 AM, Diego Olivier Fernandez Pons wrote: I think the biggest thing the community can do to improve OCaml is not to tweak around with language design. It's to improve the library packaging situation. Then just do it. I have, and the result is odb[1]. It backends with oasis-db[2], meaning if you upload your oasis package, it will be installable via odb, including deps. After finding out about barbra[3], a similar project with a different starting point, I stole many of their good ideas, and now have support for a local `packages` file that provides metadata for packages not available through oasis-db. This packages file allows installation of packages available from arbitrary URLs (anything curl-able), git, svn, cvs, hg, darcs, as well as local directories. For a large number of package examples (plus non-examples of packages that fail to auto-install through make/omake/oasis), look here: https://github.com/thelema/odb/blob/master/packages Contributions of additional packages welcome, fixes to the programs that don't auto-install (See the bottom half of the packages file) are doubly welcome. E. [1] https://github.com/thelema/odb [2] http://oasis.forge.ocamlcore.org/oasis-db.html and http://oasis.ocamlcore.org/dev/odb/ [3] still in stealth mode, maybe I shouldn't have stolen their thunder by mentioning them -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Let-less syntax for coreML
On Wed, Jan 4, 2012 at 07:18, Yaron Minsky ymin...@janestreet.com wrote: I think the biggest thing the community can do to improve OCaml is not to tweak around with language design. It's to improve the library packaging situation. Oasis seems to be the effort in this direction that has the most momentum, so I think pushing Oasis to become every bit as good as Hackage and Cabal is really the place to get maximum leverage. I would say that Jane Street is in a unique position to make a difference here. Having by far the largest OCaml team in the world, nobody else is as likely to benefit from and to achieve the goal of improving the library packaging situation. Just being able to attract more people to OCaml and hence potential employees would seem well worth the cost of specifically dedicating resources and pushing this project through. It is not very likely that individuals or small companies will be able or willing to support this project in the long term, and the OCaml team/INRIA understandably has other priorities (= research). Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mo...@gmail.com -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Let-less syntax for coreML
On 2012-01-04, at 14:30, Diego Olivier Fernandez Pons wrote: Mmm... I didn't request or even suggest a syntax change. I only asked what potential issues it could create. Here is one: as far as I can tell, it cannot be parsed by an LALR(1) parser. -- Damien -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Hashtbl and security
On 2012-01-02, at 02:43, oliver wrote: If the type is an abstract type, which comes from something like Hashtbl.Randomseed and has type t, not type int, this problem would vanish. You have to be careful. If we make hash table randomization mandatory, the Frama-C people will hate us, as will all the people who want reproducible results from their programs (for purposes of testing and benchmarking, for example). So, even if randomized is the default, there must be a way to get a plain hash table that does the same thing every time. -- Damien -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Understanding usage by the runtime
On 2012-01-01, at 13:44, Richard W.M. Jones wrote:
Is compaction disabled? lablgtk disables it unconditionally by
setting the global Gc max_overhead (see also the Gc documentation):
src/gtkMain.ml:
let () = Gc.set {(Gc.get()) with Gc.max_overhead = 100}
Anyone who disables compaction should seriously consider switching
to the first-fit allocation policy:
let () = Gc.set {(Gc.get ()) with Gc.allocation_policy = 1}
This may slow down allocations a bit, but the theory tells us that
it completely prevents unbounded fragmentation of the OCaml heap.
-- Damien
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Understanding usage by the runtime
There is however something to do. Quoting lablgtk's README: IMPORTANT: Some Gtk data structures are allocated in the Caml heap, and their use in signals (Gtk functions internally cally callbacks) relies on their address being stable during a function call. For this reason automatic compation is disabled in GtkMain. If you need it, you may use compaction through Gc.compact where it is safe (timeouts, other threads...), but do not enable automatic compaction. I've never really understood why it worked: I'm surprised the GC would update addresses stored in the C side of GTK. I think the problem is, a C function can invoke a callback that calls ocaml code that moves the object being operated on by the C function. Because the C function is precompiled it does not register its copy of the pointer as a GC root. When the callback returns the C function's pointer is invalid. This should be fixable with another level of indirection. Finalization can free the C object. I infer from reading the source that the extra level of indirection is considered an unacceptable penalty. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Hashtbl and security
On Wed, Jan 04, 2012 at 06:56:11PM +0100, Damien Doligez wrote: On 2012-01-02, at 02:43, oliver wrote: If the type is an abstract type, which comes from something like Hashtbl.Randomseed and has type t, not type int, this problem would vanish. You have to be careful. If we make hash table randomization mandatory, the Frama-C people will hate us, as will all the people who want reproducible results from their programs (for purposes of testing and benchmarking, for example). [...] I did not meant it must be mandatory. But provide a way, that makes it easy to use randomization and not-so-easy to use the always-same values e.g. for testing puroposes. If it needs extra effort to make simple seed values, people would prefer the randomized ones, if not they want to write some extra code (maybe applying a functor). So, even if randomized is the default, there must be a way to get a plain hash table that does the same thing every time. Yes, of course. But maybe it should not be encouraged, and the programmer-in-a-hurry would use ready-to-use random initializations, which are provided by the Hashtbl-module and the one who needs it non-randomized would need to write his own addition then. Then the lazy programmer goes safe and the unsafe way needs extra effort. Nevertheless I think optional int value as a first fix would also be ok. And maybe some of you remember the Debian random-device bug (some years ago), where the random-device under certain circumstances ran out of entropy So in any case it needs to be possible to change the random generator. But pseudo-random is always a compromise. Who really needs true random should of course use special hardware that creates wide bandwith noise and uses an ADC to sample the signal. Ciao, Oliver -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
oasis (was Re: [Caml-list] Let-less syntax for coreML)
On 4 January 2012 13:18, Yaron Minsky ymin...@janestreet.com wrote: I think the biggest thing the community can do to improve OCaml is not to tweak around with language design. It's to improve the library packaging situation. Oasis seems to be the effort in this direction that has the most momentum, so I think pushing Oasis to become every bit as good as Hackage and Cabal is really the place to get maximum leverage. Agreed, and all my packages will eventually support oasis. This was planned about half a year ago but I was told it would be simpler for me to wait for oasis-db 0.1.0~alpha3 but somehow that never materialized. I see two problems with oasis right now : 1) It seems Sylvain doesn't have much time to work on the system. Oasis tries to solve (IMHO too) many problems and is therefore a significant piece of software. This means it is less easy to contribute to and if Sylvain doesn't work on it, the project grinds to a halt. I think Sylvain, in order to gain acceptance maybe tried to be too inclusive feature-wise w.r.t. to dev practices -- not to mention that as a debian packager he also had ideas to save time there. It is perfectly understandable but it may have had some perverse effects on the complexity of the system. If I may, I would like to suggest to Sylvain that development of the oasis and oasis-db should entirely focus on the infrastructure needed so that a reasonable and useful set of packages are able to work with something like odb.ml. To give an example, oasis-db as the human browsable website is a very nice plus (e.g. I do enjoy browsing on hackage), but it is a significant piece of work and IMHO just shouldn't be a priority. By showing us that something like odb.ml actually solves the problems we have as ocaml developers --- quickly install this (high-quality of course) lib to help me write my program --- I'm sure the supposedly stubborn library devs would be willing to change and standardize their practice around those mandated by oasis and this could lead to a simpler system (vs. trying to please everyone). Just give us something that you have enough confidence in and tell us, this is usable now, use it, it may have limitations, but it already helps. And after iterate on that to eventually get to the big, planned system -- or not. 2) The current documentation is useless. When I did the _oasis file for cmdliner I had to find what the actual value of OASISformat should be by trial/error... The documentation provides a high-level description of all the available fields for _oasis files but it doesn't precisely describe their _syntax_ (types !) and their _effect_. It also doesn't describe how the system works from an architectural perspective. We need a good manual -- and please not a wiki. Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
