Re: [Caml-list] SQL engine in OCaml with client side cache
You don't seem to like SQL much, which is surprising as it is kind of isomorphic to comprehension of sets (of tuples). That's why F# added first class SQL support with comprehension-like syntax http://msdn.microsoft.com/en-us/library/hh225374(v=vs.110).aspx This may be a little off-topic (but who cares at this point?), but I'll take the chance to do some self-advertising here. We (Jerôme Vouillon and I) have done something related a few years ago: Macaque, a DSL for writing typed and composable SQL queries in OCaml, in a comprehension syntax. http://macaque.forge.ocamlcore.org/ http://darcs.ocamlcore.org/repos/macaque/README The comparison is that we also have something capable of typing SQL queries as parts of OCaml programs. It more or less stops here, this project is much less mature than the excellent LINQ work: it's mostly a research prototype (with a very short development time: three months) that hasn't been put to real use, mostly by lack of interested users; it's understandable that the interest of the approach doesn't compensate the cost of using a small, feature-restricted and relatively arcane library when we have relatively solid SQL bindings. By limitation of the implementation, it only supports PostgreSQL (through the excellent PG'OCaml project, a pure-ocaml reimplementation of the pgsql client protocol), and in retrospect the decision to use a comprehension syntax instead of the real SQL syntax (that can be typed all the same) is a bit unfortunate. But you may still be interested, for example as inspiration if you decide to write some database stuff in OCaml -- or, why not, as a user-developer. http://pgocaml.forge.ocamlcore.org/ For other SQL stuff in OCaml, see the Sqlite3 bindings, and possible the ocaml-orm-sqlite project on top of it (whose approach is to use code generation rather than a query DSL or combinator library; less flexible, but result in simpler interfaces): http://www.ocaml.info/home/ocaml_sources.html https://github.com/avsm/ocaml-orm-sqlite On Mon, Jan 30, 2012 at 12:26 AM, Diego Olivier Fernandez Pons dofp.oc...@gmail.com wrote: Caml-list, [Gerd Stolpmann wrote] The SQL server solves this by deciding on a query strategy beforehand. What ??? I thought SQL servers shipped on-the-fly optimizing compilers that would evaluate the query and use some heuristics (like table size and density) to decide in which order to execute the loops + learning on sequences of queries + on-the-fly reindexing. [Gerd Stolpmann wrote] (Just as I side note: Missing scalability has always been a problem for SQL databases. Currently, many companies go away from this technology for their giant data warehouses just because of this. Of course, these are not read-only, but read-write, but even having read-only scalability would be a big achievement.) Mmm... I thought relational databases were a universal object, in the mathematical sense meaning any other object maps into them. What do they use if not relational databases ? And an ugly parser :-( You don't seem to like SQL much, which is surprising as it is kind of isomorphic to comprehension of sets (of tuples). That's why F# added first class SQL support with comprehension-like syntax http://msdn.microsoft.com/en-us/library/hh225374(v=vs.110).aspx The idea being probably that on top of a certified whole-program optimizing compiler, pattern matching optimizer, multi-core capable garbage collector and generalized lexing/parsing library, functional language implementers will also have to write an optimizing SQL / comprehension engine. Diego Olivier -- 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 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
Gerd Stolpmann i...@gerd-stolpmann.de writes: Hi, there was recently a security alert for web services that use hash tables to store web form parameters sent via POST (so that millions of such parameters can be sent in a single request). It is possible to keep the web service busy for hours with such a DoS (denial of service) attack. The type of attack boils down to a problem in most hash table implementations, namely that the hash functions are invertible, and it is possible for a malicious user to construct lots of keys that all map to the same bucket of the hash table, creating a mass collision. The text of the alert: http://www.nruns.com/_downloads/advisory28122011.pdf I'd like to discuss this issue, because it is not restricted to the processing of web requests, but may also occur for all other data coming from untrusted sources. The web is only the most exposed area where this issue exists. So how is Ocaml affected? The hash functions used in recent Ocaml releases are also insecure in the above mentioned sense (currently MurmurHash3, and even a simpler hash function in previous releases). A quick survey of the Internet revealed at least one site that tries to break it. Probably a good cryptographer could do it in minutes. A pure Hashtbl.add of the constructed keys does not yet lead to the performance degradation, but a Hashtbl.replace, and of course Hashtbl.find after the table is built up will. So it depends very much of the details of the programs whether they are affected or not. I've just checked that Ocamlnet uses only Hashtbl.add to collect POST parameters, so it is not directly vulnerable. But if the crafted request is actually served by a handler, the handler would get a degraded table, and could show in turn bad performance (again leading to DoS). What are possible fixes? 1) Avoid hash tables in contexts where security is relevant. The alternative is Set (actually a balanced binary tree), which does not show this problem. Unfortunately O(log n) O(1) and that can be a deciding factor in the overall runtime. Even for small n your code then runs 2,3,4,... times slower. 2) Use cryptographically secure hash functions. 3) Use randomized hash tables. The trick here is that there is not a single hash function h anymore, but a family h(1)...h(n). When the hash table is created, one of the functions is picked randomly. This makes it impossible to craft an attack request, because you cannot predict the function. I don't think 1) is viable - hash tables are too wide spread, and are loved by programmers because of their good performance. 2) would be good in extremely critical contexts - although it is then again questionable, because it is likely to have worse performance than 1). So, the question is how to do 3). I see two problems here: a) how to define the family of hash functions. Is it e.g. sufficient to introduce an initialization vector for the Murmurhash algorithm, and fill it randomly? How to get a random number that is good enough? b) the Hashtbl in the standard library does not allow it to set the hash function dynamically. Maybe one can get this effect by using first-class modules (haven't checked). Anyway, I think these problems are difficult enough to deserve some discussion here. At least I cannot solve them immediately, and this problem may exist for lots of Ocaml applications. Gerd You are forgetting a variable in this. To create a DOS in the hashtable you need to hit the same bucket again and again. And bucket = hash % size. You focused on the hash but lets talk about the size for a moment. The size is rather limited and large hashtabels simply won't increate size anymore and allways have lots of collisions. So even if someone isn't actively trying to create DOS the performace still tanks as you add more items. And this isn't only a problem in ocaml. The glib hashtable also has a maximum size in the 32bit range for example. So for ocaml the first thing that needs to be fixed is to allow larger size arrays of buckets. MfG Goswin -- 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
Xavier Leroy xavier.le...@inria.fr writes: On 01/01/2012 01:52 PM, Richard W.M. Jones wrote: On Fri, Dec 30, 2011 at 06:06:26PM +0100, Xavier Leroy wrote: Indeed. The optional seed parameter to Hashtbl.create does exactly this in the new implementation of Hashtbl (the one based on Murmur3). It may be worth noting that Perl solved this problem (back in 2003) by unconditionally using a seed which is a global set to a random number during interpreter initialization. That's how my initial reimplementation of Hashtbl worked, using the Random module to produce seeds, but I was told (correctly) that in security-sensitive applications it's better to leave the generation of random numbers under control of the programmer. For some applications Random.self_init might be good enough and for others stronger randomness is needed. Of course, you can trivially emulate Perl's behavior using the new Hashtbl implementation + the Random module. - Xavier Leroy It is also crucial if you are doing performance tests or debugging. You want the same behaviour on every run for that. MfG Goswin -- 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] WING 2012: First Call for Papers
[Please post - apologies for multiple copies.] WING 2012 - 4th International Workshop on INvariant Generation http://cs.nyu.edu/acsys/wing2012/ June 30, 2012 Manchester, UK (a satellite Workshop of IJCAR 2012) --- First Call for Papers --- General --- The ability to automatically extract and synthesize auxiliary properties of programs has had a profound effect on program analysis, testing, and verification over the last several decades. A key impediment for program verification is the overhead associated with providing, debugging, and verifying auxiliary invariant annotations. Releasing the software developer from this burden is crucial for ensuring the practical relevance of program verification. In the context of testing, suitable invariants have the potential of enabling high-coverage test-case generation. Thus, invariant generation is a key ingredient in a broad spectrum of tools that help to improve program reliability and understanding. As the design and implementation of reliable software remains an important issue, any progress in this area will have a significant impact. The increasing power of automated theorem proving and computer algebra has opened new perspectives for computer-aided program verification; in particular for the automatic generation of inductive assertions in order to reason about loops and recursion. Especially promising breakthroughs are invariant generation techniques by Groebner bases, quantifier elimination, and algorithmic combinatorics, which can be used in conjunction with model checking, theorem proving, static analysis, and abstract interpretation. The aim of this workshop is to bring together researchers from these diverse fields. Scope - We encourage submissions presenting work in progress, tools under development, as well as work by PhD students, such that the workshop can become a forum for active dialogue between the groups involved in this new research area. Relevant topics include (but are not limited to) the following: * Program analysis and verification * Inductive Assertion Generation * Inductive Proofs for Reasoning about Loops * Applications to Assertion Generation using the following tools: - Abstract Interpretation, - Static Analysis, - Model Checking, - Theorem Proving, - Theory Formation, - Algebraic Techniques * Tools for inductive assertion generation and verification * Alternative techniques for reasoning about loops Committee - Program Chairs: * Gudmund Grov (University of Edinburgh, UK) * Thomas Wies (New York University, USA) Program Committee: * Clark Barrett (New York University, USA) * Nikolaj Bjorner (Microsoft Research, USA) * Gudmund Grov (University of Edinburgh, UK) * Ashutosh Gupta (IST Austria) * Bart Jacobs (Katholieke Universiteit Leuven, Belgium) * Moa Johansson (Chalmers University of Technology, Sweden) * Laura Kovacs (Vienna University of Technology, Austria) * David Monniaux (VERIMAG, France) * Enric Rodriguez Carbonell (Technical University of Catalonia, Spain) * Helmut Veith (Vienna University of Technology, Austria) * Thomas Wies (New York University, USA) Important Dates --- Submission deadline: April 06, 2012 Notification of acceptance: May 04, 2012 Final version due: June 08, 2012 Workshop: June 30, 2012 Submission -- WING 2012 encourages submissions in the following two categories: * Original papers: contain original research (simultaneous submissions are not allowed) and sufficient detail to assess the merits and relevance of the submission. Given the informal style of the workshop, papers describing work in progress, with sufficient detail to assess the contribution, are also welcome. Original papers should not exceed 15 pages. * Extended abstracts: contain preliminary reports of work in progress, case studies, or tool descriptions. These will be judged based on the expected level of interest for the WING community. They will be included in the CEUR-WS proceedings. Extended abstracts should not exceed 5 pages. All submissions should conform to Springer's LNCS format. Formatting style files can be found at http://www.springer.de/comp/lncs/authors.html Technical details may be included in an appendix to be read at the reviewers' discretion and to be omitted in the final version. Please prepare your submission in accordance with the rules described above and submit a pdf file via https://www.easychair.org/?conf=wing2012 Publication --- All submissions will be peer-reviewed by the program committee. Accepted contributions will be published in archived electronic notes, as a volume of CEUR Workshop Proceedings. A special issue of the Journal of Science of Computer Programming with extended versions of selected papers will be published after the workshop. -- The
Re: [Caml-list] OpenGL ES for iPhone Simulator; working example app
Dear Jeffrey I tried your solution for ocaml on Xcode 4.2 with iOS 5.0 But I can't find a way to get a good binary. I got some weird alignment warnings on compilation and the application just doesn't work on the iPhone. Do you have plan to update your work for the last versions of Xcode and iOS ? Thank you, it would be so good to have a nice way to program iOS applications in OCaml ! Christophe -- 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] OpenGL ES for iPhone Simulator; working example app
Greetings, I tried your solution for ocaml on Xcode 4.2 with iOS 5.0 But I can't find a way to get a good binary. I got some weird alignment warnings on compilation and the application just doesn't work on the iPhone. Do you have plan to update your work for the last versions of Xcode and iOS ? Thank you, it would be so good to have a nice way to program iOS applications in OCaml ! Yes, I will make it work with the latest Xcode and iOS. Right now we're in the last few weeks of releasing a new app, and I haven't wanted to disturb our development process. The native code generator of OCaml is based on the native assembler, so generally you just have to make the assembler and the linker happy by adapting the command lines from an ObjC project. If you try any experiments, let me know what you find out. Otherwise I'll look into it as soon as I can. Thanks for your interest and best regards, Jeffrey -- 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] OpenGL ES for iPhone Simulator; working example app
Christophe: I tried your solution for ocaml on Xcode 4.2 with iOS 5.0 But I can't find a way to get a good binary. I got some weird alignment warnings on compilation and the application just doesn't work on the iPhone. One extra comment occurred to me: We're doing development under Xcode 4.0.2 right now, but the generated binaries work fine under iOS 5.0. So any new difficulties in Xcode 4.2 are almost certainly caused by changes in Xcode's cross compilation toolchain. Historically there have been a few of these in each new release of Xcode. Regards, Jeffrey -- 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: Special Call for Surveys on Application Areas of Semantic Technologies
Semantic Web journal Special Call for Surveys on Application Areas of Semantic Technologies http://www.semantic-web-journal.net/blog/semantic-web-journal-special-call-surveys-application-areas-semantic-technologies Semantic Web technologies are currently in a transition from research to practice. The amount of progress made in different application areas, however, differs significantly, as do the challenges which lie ahead. The Semantic Web journal calls for survey papers on the state of the art in research, development, and deployment of Semantic Web technologies in specific application areas and domains. Surveys should focus on one specific application area and discuss in a comprehensive way * its importance, * the particular (past, present, and future) challenges faced in applying Semantic technologies in this area, and * the state of the art in developing foundational principles and practical solutions related to this area. Application areas covered may range from those where commercial solutions have already been deployed, to areas where basic research is still under way. They may address very specific needs, e.g., mobile recommender systems, or span broader scientific domains, e.g., the life sciences. Survey articles should have the potential to become well-known introductory and overview texts. They will be reviewed along the following dimensions: (1) Suitability as introductory text, targeted at researchers, students, or practitioners, to get started on the covered topic. (2) How comprehensive and how balanced is the presentation and coverage. (3) Readability and clarity of the presentation. (4) Importance of the covered material to the broader Semantic Web community. Prospective authors must take notice of the submission guidelines posted at http://www.semantic-web-journal.net/authors Authors must submit an intention to contribute, consisting of (tentative) list of authors, (tentative) title, and a short abstract, by March 15th. The reason for this requirement is to avoid that multiple surveys are written on very similar topics. Deadlines: Intention to contribute: March 15th, 2012 Paper submission: May 15th, 2012 First notification: Usually within 8 weeks of submission In case of questions, please contact the Editors-in-chief: Pascal Hitzler Krzysztof Janowicz cont...@semantic-web-journal.net -- 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
