Re: [Caml-list] Hashtbl and security
Gerd Stolpmann i...@gerd-stolpmann.de writes: Gerd Stolpmann i...@gerd-stolpmann.de writes: 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. I cannot completely follow here. If you add more elements, the bucket array is resized. The ocaml Hashtbl does this when the number of elements exceeds half of the array size. The argument of Hashtbl.create is only the initial size of the bucket array. The upper bound is Sys.max_array_length, of course. Granted, on 32 bit platforms it is low (4M). But nobody of sound mind would run ocaml programs on 32 bit for production purposes. (If you do, consider to switch. You can use more memory and get a little performance boost, not only for ocaml programs.) Gerd In practice I see a serious performance degradation with large hashtables. So much so that I had to use an array of hashtables or hashtable of hashtables and split the values across them. Maybe the size of the hashtable indeed isn't the problem but the hash function. Here is something odd: # for i = 1 to 63 do Printf.printf %d %d\n (1 lsl i) (Hashtbl.hash (1 lsl i)) done;; 2 2 4 4 8 8 16 16 32 32 64 64 128 128 256 256 512 512 1024 1024 2048 2048 4096 4096 8192 8192 16384 16384 32768 32768 65536 65536 131072 131072 262144 262144 524288 524288 1048576 1048576 2097152 2097152 4194304 4194304 8388608 8388608 16777216 16777216 33554432 33554432 67108864 67108864 134217728 134217728 268435456 268435456 536870912 536870912 1073741824 0 2147483648 0 4294967296 0 8589934592 0 17179869184 0 34359738368 0 68719476736 0 137438953472 0 274877906944 0 549755813888 0 1099511627776 0 219902322 0 4398046511104 0 8796093022208 0 17592186044416 0 35184372088832 0 70368744177664 0 140737488355328 0 281474976710656 0 562949953421312 0 1125899906842624 0 2251799813685248 0 4503599627370496 0 9007199254740992 0 18014398509481984 0 36028797018963968 0 72057594037927936 0 144115188075855872 0 288230376151711744 0 576460752303423488 0 1152921504606846976 0 2305843009213693952 0 -4611686018427387904 0 0 0 - : unit = () Is every value over a billion hashed to 0? 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
Le Wed, 08 Feb 2012 10:41:03 +0100, Goswin von Brederlow goswin-...@web.de a écrit : Gerd Stolpmann i...@gerd-stolpmann.de writes: Gerd Stolpmann i...@gerd-stolpmann.de writes: 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. I cannot completely follow here. If you add more elements, the bucket array is resized. The ocaml Hashtbl does this when the number of elements exceeds half of the array size. The argument of Hashtbl.create is only the initial size of the bucket array. The upper bound is Sys.max_array_length, of course. Granted, on 32 bit platforms it is low (4M). But nobody of sound mind would run ocaml programs on 32 bit for production purposes. (If you do, consider to switch. You can use more memory and get a little performance boost, not only for ocaml programs.) Gerd In practice I see a serious performance degradation with large hashtables. So much so that I had to use an array of hashtables or hashtable of hashtables and split the values across them. Maybe the size of the hashtable indeed isn't the problem but the hash function. Here is something odd: # for i = 1 to 63 do Printf.printf %d %d\n (1 lsl i) (Hashtbl.hash (1 lsl i)) done;; 2 2 4 4 8 8 16 16 32 32 64 64 128 128 256 256 512 512 1024 1024 2048 2048 4096 4096 8192 8192 16384 16384 32768 32768 65536 65536 131072 131072 262144 262144 524288 524288 1048576 1048576 2097152 2097152 4194304 4194304 8388608 8388608 16777216 16777216 33554432 33554432 67108864 67108864 134217728 134217728 268435456 268435456 536870912 536870912 1073741824 0 2147483648 0 4294967296 0 8589934592 0 17179869184 0 34359738368 0 68719476736 0 137438953472 0 274877906944 0 549755813888 0 1099511627776 0 219902322 0 4398046511104 0 8796093022208 0 17592186044416 0 35184372088832 0 70368744177664 0 140737488355328 0 281474976710656 0 562949953421312 0 1125899906842624 0 2251799813685248 0 4503599627370496 0 9007199254740992 0 18014398509481984 0 36028797018963968 0 72057594037927936 0 144115188075855872 0 288230376151711744 0 576460752303423488 0 1152921504606846976 0 2305843009213693952 0 -4611686018427387904 0 0 0 - : unit = () Is every value over a billion hashed to 0? MfG Goswin Go to: http://caml.inria.fr/cgi-bin/viewvc.cgi/ocaml/trunk/byterun/hash.c?view=markup line 285 if you want another hasfunction, you can download the sources, modify it and recompile. More seriously, hashtables are here to store values, so you don't want want to have a hash value bigger than (2^30)-1. In fact even such a value is too big for that purpouse IMHO, since on a 4Gio RAM computer, it will take half it to store the table, assuming each entry only takes 4 octets, that is it would be ok only for storing just the structure of the table (each entry has to be a pointer), so that in practice, either your table is ridiculously big to store too few values either it is relevant to have such a size and in this case your computer will spend all its time to swap since you won't have enough RAM. Clearly you cannot a bijection from 63 bits integers to 31 bits integers; so there are a lot of collisions. I do not have a 64 arch, but I guesse that if you hash 2^48+168 you will get 168. I guess such a function is ways to be ideal, since when playing with bitvectors having two integers which differs by only one bit is very common, but at least it is a fast function, and has a good repartition (you have 2^32 collisions exactly per bucket). -- 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
Well, looks like that the upper 32 bits aren't considered at all for computing the hash value. This is for sure surprising - I would have expected that these bits somehow go in to the final value (e.g. that they are xor-ed with the lower half). My guess is that this was done to ensure that an int-to-something hashtable can be marshalled from 64 to 32 bit systems. Not sure for what this is important, but it looks like a nice symmetry. In trunk the method for ensuring this seems to have changed (see function caml_hash_mix_intnat in http://caml.inria.fr/cgi-bin/viewvc.cgi/ocaml/trunk/byterun/hash.c?revision=12072view=markup). Gerd Gerd Stolpmann i...@gerd-stolpmann.de writes: Gerd Stolpmann i...@gerd-stolpmann.de writes: 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. I cannot completely follow here. If you add more elements, the bucket array is resized. The ocaml Hashtbl does this when the number of elements exceeds half of the array size. The argument of Hashtbl.create is only the initial size of the bucket array. The upper bound is Sys.max_array_length, of course. Granted, on 32 bit platforms it is low (4M). But nobody of sound mind would run ocaml programs on 32 bit for production purposes. (If you do, consider to switch. You can use more memory and get a little performance boost, not only for ocaml programs.) Gerd In practice I see a serious performance degradation with large hashtables. So much so that I had to use an array of hashtables or hashtable of hashtables and split the values across them. Maybe the size of the hashtable indeed isn't the problem but the hash function. Here is something odd: # for i = 1 to 63 do Printf.printf %d %d\n (1 lsl i) (Hashtbl.hash (1 lsl i)) done;; 2 2 4 4 8 8 16 16 32 32 64 64 128 128 256 256 512 512 1024 1024 2048 2048 4096 4096 8192 8192 16384 16384 32768 32768 65536 65536 131072 131072 262144 262144 524288 524288 1048576 1048576 2097152 2097152 4194304 4194304 8388608 8388608 16777216 16777216 33554432 33554432 67108864 67108864 134217728 134217728 268435456 268435456 536870912 536870912 1073741824 0 2147483648 0 4294967296 0 8589934592 0 17179869184 0 34359738368 0 68719476736 0 137438953472 0 274877906944 0 549755813888 0 1099511627776 0 219902322 0 4398046511104 0 8796093022208 0 17592186044416 0 35184372088832 0 70368744177664 0 140737488355328 0 281474976710656 0 562949953421312 0 1125899906842624 0 2251799813685248 0 4503599627370496 0 9007199254740992 0 18014398509481984 0 36028797018963968 0 72057594037927936 0 144115188075855872 0 288230376151711744 0 576460752303423488 0 1152921504606846976 0 2305843009213693952 0 -4611686018427387904 0 0 0 - : unit = () Is every value over a billion hashed to 0? 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 -- Gerd Stolpmann, Darmstadt, Germanyg...@gerd-stolpmann.de Creator of GODI and camlcity.org. Contact details:http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de *** Searching for new projects! Need consulting for system *** programming in Ocaml? Gerd Stolpmann can help you. -- 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] syntactic detail
Hi,
Ocaml allows me to add '_' at the end of a floating point literal, e.g.:
1._
What can be a purpose for that?
In case of long or Long integers, optional adding of '_' between the
integer and 'l' or 'L' make sense ('l' is hard to discriminate from '1'
for many fonts). But in case of floats, I am not sure.
--
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] syntactic detail
There is no purpose, it's just an edge case of the simple lexical
specification you can find at:
http://caml.inria.fr/pub/docs/manual-ocaml/lex.html#float-literal
Everywhere digits are allowed, you can insert extraneous underscores. There
is no restriction that there must be at least one digit for underscores to
be valid. I don't see why there should be.
On Wed, Feb 8, 2012 at 1:46 PM, Matej Košík
5764c029b688c1c0d24a2e97cd7...@gmail.com wrote:
Hi,
Ocaml allows me to add '_' at the end of a floating point literal, e.g.:
1._
What can be a purpose for that?
In case of long or Long integers, optional adding of '_' between the
integer and 'l' or 'L' make sense ('l' is hard to discriminate from '1'
for many fonts). But in case of floats, I am not sure.
--
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] syntactic detail
Just in case it was not clear from Gabriel's answer alone, the purpose of allowing underscores is to write big integers like: 1_000_000_000 which is very nice once you are used to it. -- 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] syntactic detail
On 02/08/2012 12:54 PM, Gabriel Scherer wrote: There is no purpose, it's just an edge case of the simple lexical specification you can find at: http://caml.inria.fr/pub/docs/manual-ocaml/lex.html#float-literal Everywhere digits are allowed, you can insert extraneous underscores. There is no restriction that there must be at least one digit for underscores to be valid. I don't see why there should be. I would actually prefer a slightly more constrained format. It is very easy to typo large numbers like: let ten_million = 10_000_ in When eyeballing this, it is extremely easy to mistake this as 10^7, when it actual fact it is 10^8. I would prefer a syntax rule that only allows underscore every three characters (starting at the RHS of the number, i.e. complying to the usual convention). Well, certainly that for decimal literals. For hex literals you probably want to enforce the same, but every four characters. -- 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] syntactic detail
On Wed 08 Feb 2012 01:39:26 PM GMT, oliver wrote: I think the problem of being confounding 10_000_ with 100_000_000 or 10_000_ with 10_000_000 is less prominent then confounding 1 with 1000. So this syntax rule already makes things much easier to read. That's it's advantage. To have here all three characters as syntax rule could make sense, but is less a problem than having no allowance of _ in numbers at all. That is definitely true. Might not be the case that pops up all to often, but if so, it might be fine, if both values can be used: let startval_correct = 3.36639_92_6549992 let startval_wrong = 3.36639_29_6549992 So I have invented reasons why it's fine as it is. Perhaps this could happen. But I feel this could be expressed equally clearly using some other mechanism, like a comment. We don't have to have syntax-level support for every weird thing people would like to do. Why should this case be forbidden? Because it is impossible to distinguish it from the wrongly-deliminated case that I described, which leads to the bugs I described. Your example actually raises another point -- I'm not sure how my ideas would be extended to bits after the decimal place in floating point literals. Doing something like every third character going right from the point would probably be sufficient. I would prefer a syntax rule that only allows underscore every three characters (starting at the RHS of the number, i.e. complying to the usual convention). Well, certainly that for decimal literals. For hex literals you probably want to enforce the same, but every four characters. [...] For Hex it might also make sense to have it all two characters. If the rule would be only all 4 characters, that would be bad. Sure, this seems okay. -- 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] syntactic detail
On Wed, Feb 08, 2012 at 01:46:39PM +, David House wrote: On Wed 08 Feb 2012 01:39:26 PM GMT, oliver wrote: I think the problem of being confounding 10_000_ with 100_000_000 or 10_000_ with 10_000_000 is less prominent then confounding 1 with 1000. So this syntax rule already makes things much easier to read. That's it's advantage. To have here all three characters as syntax rule could make sense, but is less a problem than having no allowance of _ in numbers at all. That is definitely true. Might not be the case that pops up all to often, but if so, it might be fine, if both values can be used: let startval_correct = 3.36639_92_6549992 let startval_wrong = 3.36639_29_6549992 So I have invented reasons why it's fine as it is. Perhaps this could happen. But I feel this could be expressed equally clearly using some other mechanism, like a comment. We don't have to have syntax-level support for every weird thing people would like to do. If something is a weird thing often lies in the eye of the beholder. An int-value which raises an exception on overflow would be something much more important than making this syntax rule more restricted. It's also somehow weird, to write 1_000_000_000 instead of 10. Why should this weird _ stuff supported at all? Writing +. instead of + also might be weird from a certain view. So you are using a weird language. Why should this case be forbidden? Because it is impossible to distinguish it from the wrongly-deliminated case that I described, which leads to the bugs I described. [...] But that case is just a typo, like it would be without any _. For some rsearch it might make sense to delimit those digits which are officially rounded in a setting from those which might be rounded. like 4.526829898 vs. 4.5_26829898 vs. 4.52_6829898 and so on. So, even you have a floating point value with 9 digits after the decimal point, if you have a case where your official rounding is one or two digits, but you have to use the correct value, you could clarify this in the code. But this might also be weird to you. Your example actually raises another point -- I'm not sure how my ideas would be extended to bits after the decimal place in floating point literals. Doing something like every third character going right from the point would probably be sufficient. I would prefer a syntax rule that only allows underscore every three characters (starting at the RHS of the number, i.e. complying to the usual convention). Well, certainly that for decimal literals. For hex literals you probably want to enforce the same, but every four characters. [...] For Hex it might also make sense to have it all two characters. If the rule would be only all 4 characters, that would be bad. Sure, this seems okay. Too late, if the four-digit rule would have been implemented before the (weird?) two-digit rule was asked by someone... 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
Re: [Caml-list] syntactic detail
On Wed 08 Feb 2012 01:58:18 PM GMT, oliver wrote: Perhaps this could happen. But I feel this could be expressed equally clearly using some other mechanism, like a comment. We don't have to have syntax-level support for every weird thing people would like to do. If something is a weird thing often lies in the eye of the beholder. My definition of weird is few people use this in practice. Clearly, delimiting groups of thousands is useful to a lot of people. But it hides bugs, because if you see 10_000_ you are much more likely to think it is 10^7 than you are with 1, where you are likely to be careful and take your time. We can prevent this by more stringent syntax rules. This would also prevent some corner cases that you have described, that probably barely anyone cares about. It's not a free restriction, but it is cheap, and definitely has value. An int-value which raises an exception on overflow would be something much more important than making this syntax rule more restricted. That's completely orthogonal. It's also somehow weird, to write 1_000_000_000 instead of 10. Why should this weird _ stuff supported at all? Writing +. instead of + also might be weird from a certain view. So you are using a weird language. I think this is addressed by my definition of weird above. Why should this case be forbidden? Because it is impossible to distinguish it from the wrongly-deliminated case that I described, which leads to the bugs I described. [...] But that case is just a typo, like it would be without any _. I don't understand. Wouldn't it be better to have a syntax where it is harder to make typos? For some rsearch it might make sense to delimit those digits which are officially rounded in a setting from those which might be rounded. like 4.526829898 vs. 4.5_26829898 vs. 4.52_6829898 and so on. So, even you have a floating point value with 9 digits after the decimal point, if you have a case where your official rounding is one or two digits, but you have to use the correct value, you could clarify this in the code. This could also be done, by, e.g., defining a new type with explicit coercions: module Two_dp_float : sig val of_float : float - t val to_float : t - float end = struct type t = float let of_float x = x let to_float x = x end This actually enforces that you get the notation right in your code, rather than with the underscores, where you could typo and put the underscore too far right, or forget to put them in all together. But more generally, I think it is worth more, in terms of bugs saved, to restrict the syntax versus allowing these infrequently-used cases. For Hex it might also make sense to have it all two characters. If the rule would be only all 4 characters, that would be bad. Sure, this seems okay. Too late, if the four-digit rule would have been implemented before the (weird?) two-digit rule was asked by someone... You're right, that would be a change that would probably break a lot of code. I claim my suggestion would not break much code. -- 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] syntactic detail
People. Please. Tell me you are *not* arguing over underscores in numeric literals ! But it hides bugs, because if you see 10_000_ you are much more likely to think it is 10^7 than you are with 1, where you are likely to be careful and take your time. So your point is : it is dangerous because it is clearer. I also recommend we forbid comments, since: - they can be abused, even by mistake, to make code *harder* to read - removing them will force people to read code more carefully I'm out of this discussion. PS: Planet OCaml needs some love. If you're considering contributing to the present debate, please also consider writing a blog story! On Wed, Feb 8, 2012 at 3:12 PM, David House dho...@janestreet.com wrote: On Wed 08 Feb 2012 01:58:18 PM GMT, oliver wrote: Perhaps this could happen. But I feel this could be expressed equally clearly using some other mechanism, like a comment. We don't have to have syntax-level support for every weird thing people would like to do. If something is a weird thing often lies in the eye of the beholder. My definition of weird is few people use this in practice. Clearly, delimiting groups of thousands is useful to a lot of people. But it hides bugs, because if you see 10_000_ you are much more likely to think it is 10^7 than you are with 1, where you are likely to be careful and take your time. We can prevent this by more stringent syntax rules. This would also prevent some corner cases that you have described, that probably barely anyone cares about. It's not a free restriction, but it is cheap, and definitely has value. An int-value which raises an exception on overflow would be something much more important than making this syntax rule more restricted. That's completely orthogonal. It's also somehow weird, to write 1_000_000_000 instead of 10. Why should this weird _ stuff supported at all? Writing +. instead of + also might be weird from a certain view. So you are using a weird language. I think this is addressed by my definition of weird above. Why should this case be forbidden? Because it is impossible to distinguish it from the wrongly-deliminated case that I described, which leads to the bugs I described. [...] But that case is just a typo, like it would be without any _. I don't understand. Wouldn't it be better to have a syntax where it is harder to make typos? For some rsearch it might make sense to delimit those digits which are officially rounded in a setting from those which might be rounded. like 4.526829898 vs. 4.5_26829898 vs. 4.52_6829898 and so on. So, even you have a floating point value with 9 digits after the decimal point, if you have a case where your official rounding is one or two digits, but you have to use the correct value, you could clarify this in the code. This could also be done, by, e.g., defining a new type with explicit coercions: module Two_dp_float : sig val of_float : float - t val to_float : t - float end = struct type t = float let of_float x = x let to_float x = x end This actually enforces that you get the notation right in your code, rather than with the underscores, where you could typo and put the underscore too far right, or forget to put them in all together. But more generally, I think it is worth more, in terms of bugs saved, to restrict the syntax versus allowing these infrequently-used cases. For Hex it might also make sense to have it all two characters. If the rule would be only all 4 characters, that would be bad. Sure, this seems okay. Too late, if the four-digit rule would have been implemented before the (weird?) two-digit rule was asked by someone... You're right, that would be a change that would probably break a lot of code. I claim my suggestion would not break much code. -- 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] syntactic detail
On Wed, Feb 08, 2012 at 02:50:55PM +, David House wrote: On 02/08/2012 02:39 PM, Gabriel Scherer wrote: People. Please. Tell me you are *not* arguing over underscores in numeric literals ! This is not totally academic. I have come across the exact bug I describe. It was painful. [...] Let me guess where the problem might be came from: When i think of code that uses a value 1_000_000 and you want to change it to a value ten times higher, it should be changed to 10_000_000 Coming from notation that does NOT allow _ in tzhe numbers, it could be done by just adding one 0 at the end of the value: 100 becomes 1000 ^ with the 0 added at the end. But also correct (more correct would be: 100 becomes 1000 ^ 0 added at the millions. Just add one 0 at the end Is the edit-habit, which works fine. But when allowing _ inside numbers, but people don't change the wrong editing behaviour, then allowing the _ at all means introducing a new kind of possible errors. This could be an argument to throw _ at all, because adding a 0 after the 1 instead of just adding a 0 at the end is rarely used behaviour of editing, and some people might call it weird. ;-) So this argument also could be used to disallow _ at all. But no, thats not what I want to argue for ;-) OK, let's stop that discussion now. If someone thinks the three-digit-distance-_ is a feature that makes sense, a feature wish could be added for OCaml. ;-) 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
[Caml-list] sys command
Hello, Does anyone know how I can launch a batch file from Ocaml without pop up windows. Thanks Fady -- 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] sys command
Does anyone know how I can launch a batch file from Ocaml without pop up windows. trollUse an operating system which does not contain the word windows in its name?/troll -- 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] sys command
On 08/02/2012, Paolo Donadeo p.dona...@gmail.com wrote: I use Unix.system but: what popup? I guess the cmd.exe one since Sys.command and Unix.system use the same underlying function: system(3). As far as I remember, Unix.create_process will not pop any additional(*) window. (*) Of course, there's no magic here: if the process itself opens a console window, you will always get one. Linking with gcc -mwindows or ld --subsystem windows (not sure about the syntax for ld) would solve it. If you can't link again, you can still modify the binary with a tool or by hand since it's a single bit (maybe two) in the PE header. Hope this helps, Adrien Nader -- 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] sys command
On Wed, Feb 08, 2012 at 07:18:13PM +0100, Andrej Bauer wrote: Does anyone know how I can launch a batch file from Ocaml without pop up windows. trollUse an operating system which does not contain the word windows in its name?/troll [...] LOL -- 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] OCamlCore.org is down?
Hi, It seems the site and the oasis repo server are not responsive. Regards, J -- 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
