Re: CCW bug [SEVERE]
Try to give Eclipse more memory like this: eclipse.exe -vm e:\jdk8\bin\javaw.exe -vmargs -Xms2048m -Xmx4096m 2014-11-01 13:12 GMT+08:00 Fluid Dynamics a2093...@trbvm.com: On Saturday, November 1, 2014 12:09:33 AM UTC-4, Dylan Butman wrote: Is it hard to actually send the log? Are you purposefully uncooperative to people trying to help? My inspection of the log indicates that the amount of information (namespace names, other things) about what I'm working on that it contains is non-zero. So, not only would there be some effort involved in signing up for wherever-it-was and uploading a copy there, but also some damage to my privacy, and all for zero gain, since it is already a mathematical certainty that the log contains nothing enlightening on this particular issue. Which can only mean one of two things: either you believe I'm lying when I describe the log entries immediately around the time of the hang, or you are so insistent on seeing the log anyway because you're after something else that it is in it, and are not being honest about what you're really looking for. So, either you're untrusting or untrustworthy, and in neither case am I especially inclined to trust you, Mr. Butman. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Deterministic Randomness in Functional Clojure
Hi Isaac, On 01 Nov 2014, at 05:19, Isaac Karth isaacka...@gmail.com wrote: Laurens, Using a PRF actually sounds very close to ideal for what I was looking for. If I can convert a map (or record) to a reproducible seed, and have that be independant from other random checks, that's pretty close to exactly what I wanted. Glad to be of assistance :) Looks like if I want to use libraries like clojure.data.generators or bigml.sampling I'd need to amend the random generators to replace calls to the Mersenne Twister function or (def ^:dynamic *rnd* (java.util.Random. 42)). As long as I can figure out how to install caesium/libsodium on Windows, it should theoretically be possible to substitute the PRF there, though I'd have to rewrite some functions to replace the calls to .nextDouble, .nextFloat, et cetera. Yeah. You’re probably going to have to do some slightly gnarly Float.intBitsToFloat and Double.longBitsToDouble there. Nothing too difficult. Just a little ugly ;-) No clue how to install libsodium on Windows. Sorry! Never tried. Keep in mind that the docs for Random (http://docs.oracle.com/javase/7/docs/api/java/util/Random.html) describe the algorithms for e.g. nextFloat, nextGaussian… You may be able to write those as a HOF in terms of a side-effecting “next” function. Writing next() is a little annoying, of course, because it has some state, when the beauty of the PRF approach is that it doesn’t (besides a seed, that is). This is fine as long as you never want to extract more than one largest-bit-extracting-operation (which I think is a double, which needs 64 bits?). That’s fine: BLAKE2’s output is a whopping 512. If you want to extract *many* bits out of BLAKE2, you probably want to look at the `personal` optional argument. Just put a little incrementing counter there (it’s 16 bytes), and you can get an awful lot of 512-bit sequences. Writing a “streaming” algorithm to support next(n) calls is left as an exercise to the reader ;) I'm assuming that just passing the hash as a seed to MT wouldn't work. If I can get away with something like (binding *rnd* (random-number-generator (blake2b [seed thing-to-hash]))) using it becomes trivial. But I'm just knowledgeable enough to know I don't know enough to be confident of that. Granted, the current application is an art project that will be just fine with some non-random randomness, so the tolerance for error is fairly high. There’s nothing wrong with that, except of course that it’s a bunch of shared state, so you may get into concurrency problems :-) FWIW, the big difference between algorithms like MT and BLAKE2 isn’t in “randomness” in the sense that you most likely require it for your game. MT (and BLAKE2) are both extremely randomly distributed. The difference is that if I can observe a handful of values from MT, I can predict all future values, whereas that should not be possible for BLAKE2. (That is a huge oversimplification. If you’re interested, my free book, Crypto 101, https://www.crypto101.io, touches on this in more detail.) This is an obvious problem for cryptographic purposes, and *might* be a problem for a game, if you’re trying to defend against the scenario of an attacker trying to get an “unfair” advantage. It doesn’t sound like you’re terribly worried about that, though; plus, it’s nothing you can’t fix later. Given the number of samples that you need from MT, if you go with the BLAKE-MT approach you noted, this wouldn’t even be a problem. hth lvh signature.asc Description: Message signed with OpenPGP using GPGMail
Re: io/writer + map/recur
The way you wrote your loop it will only ever run once which means you could take it out. 1 res = take from queue 2 if res nil? terminate 3 if res recur with result from with-open (always nil) 4 back to 2 and terminate Not sure if this is intended but the way it is written it does not make sense to loop. Also remember that .take will block if nothing is available meaning you are writing essentially an infinite loop unless you create some other kind of exit condition. Also if you just want to append a string to a file you can use spit [1] (spit f some-string :append true) Other than that, never use something lazy with IO unless you remember to doall. HTH, /thomas http://grimoire.arrdem.com/1.6.0/clojure.core/spit/ On Friday, October 31, 2014 9:08:01 PM UTC+1, Sam Raker wrote: I'm writing some stuff to interact with the Twitter API. I want to be able to write tweets (as JSON) to a file, so I can, e.g., test things without connecting to the API. I've proxied the LinkedBlockingQueue that Twitter's HBC library uses to use an agent, so ideally I want to be able to write the contents of the agent AND the LBQ. Here's what I have right now: (defmulti write-tweets (fn [q f] (class q))) (defmethod write-tweets clojure.lang.Agent [a f] (with-open [w (clojure.java.io/writer f :append true)] (.write w (apply str (interpose \n @a) (defmethod write-tweets java.util.concurrent.LinkedBlockingQueue [lbq f] (loop [res (.take lbq)] (if res (recur (with-open [w (clojure.java.io/writer f :append true)] (.write w (str (generate-string res) \n))) My first implementation of this used `(map #(.write w %) @a)` and had the `recur` within the `with-open` block. Unfortunately, at least with the agent part, I ran into an error about the file being closed when I tried to write to it. I assumed `with-open` kept the file open within the block, but maybe I'm missing something? I'm worried about the performance of either creating a potentially super-huge string in memory for the agent method (twitter returns pretty sizable JSON blobs) or repeatedly opening/closing a file for the LBQ method (I realize I could collapse this into one problem by taking everything out of the LBQ and putting it into an agent, but that's not really a solution...) Does `writer` auto-close the file after it's done? Is there some better way of handling this kind of situation? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Deterministic Randomness in Functional Clojure
On Friday, October 31, 2014 11:19:19 PM UTC-5, Isaac Karth wrote: Looks like if I want to use libraries like clojure.data.generators or bigml.sampling I'd need to amend the random generators to replace calls to the Mersenne Twister function or (def ^:dynamic *rnd* (java.util.Random. 42)). As long Further clarification: I believe that java.util.Random doesn't use a Mersenne Twister, so clojure.data.generators doesn't by default, either. However, Sean Luke's MersenneTwister.java subclasses java.util.Random, so you should be able to use it as the RNG behind clojure.data.generators, if that seemed like a good idea in other respects. (Luke's other implementation, MersenneTwisterFast.java, does not subclass java.util.Random. I'm not certain whether it can be used it with data.generators. At one time I knew, but I would have to review past investigations to know now.) And, while I'm at it, it's worth mentioning that the Incanter statistical library for Clojure also has some random number generating functions. Some of these are based on java.util.Random. Don't know if they'd be worth looking at for your purposes. (I don't know anything about PRF's so no comments from me about that path.) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: CCW bug [SEVERE]
This thread needs to end, it's no longer productive. Fluid Dynamics - file a ticket for CCW with information useful for addressing the problem if you have it. Otherwise, I do not think there is anything left that anyone can help you with here. Everyone else - thank your for all the helpful comments. On Saturday, November 1, 2014 3:36:18 AM UTC-5, jamesqiugm wrote: Try to give Eclipse more memory like this: eclipse.exe -vm e:\jdk8\bin\javaw.exe -vmargs -Xms2048m -Xmx4096m 2014-11-01 13:12 GMT+08:00 Fluid Dynamics a209...@trbvm.com javascript: : On Saturday, November 1, 2014 12:09:33 AM UTC-4, Dylan Butman wrote: Is it hard to actually send the log? Are you purposefully uncooperative to people trying to help? My inspection of the log indicates that the amount of information (namespace names, other things) about what I'm working on that it contains is non-zero. So, not only would there be some effort involved in signing up for wherever-it-was and uploading a copy there, but also some damage to my privacy, and all for zero gain, since it is already a mathematical certainty that the log contains nothing enlightening on this particular issue. Which can only mean one of two things: either you believe I'm lying when I describe the log entries immediately around the time of the hang, or you are so insistent on seeing the log anyway because you're after something else that it is in it, and are not being honest about what you're really looking for. So, either you're untrusting or untrustworthy, and in neither case am I especially inclined to trust you, Mr. Butman. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: multimethod, record, type, and protocol pitfalls?
Thanks for the responses! This is very helpful. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: On Testing
It would be great if someone could enumerate more explicitly what better test output means. What are the specific problems in the current test output reporting? Similar problem list for test runner might be useful. Discussion here is fine but ultimately needs to land on a design wiki page. I am happy to do what I can to move this through a process toward inclusion in a release. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: On Testing
I can say for certain that at a minimum better indentation of data structures to the console would be a must, a vector with 4+ hash maps in it are currently unreadable and I have to copy to an editor to indent and analyze. Beyond that, I can imagine the need for a structural diff that tells me in a human readable form how things are different. Different types (plain sequence vs hash map), different positions or keys in structures, etc. On Sat, Nov 1, 2014 at 12:58 PM, Alex Miller a...@puredanger.com wrote: It would be great if someone could enumerate more explicitly what better test output means. What are the specific problems in the current test output reporting? Similar problem list for test runner might be useful. Discussion here is fine but ultimately needs to land on a design wiki page. I am happy to do what I can to move this through a process toward inclusion in a release. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: On Testing
On Nov 1, 2014, at 1:58 PM, Alex Miller a...@puredanger.com wrote: It would be great if someone could enumerate more explicitly what better test output means. What are the specific problems in the current test output reporting? If there's any sort of consensus about test reporting, specifically how differing collections should be printed, I'll implement/include that in Midje. Note: speclj and Midje are the frameworks that most support mocking (or, as I like to think of mocking: prerequisites and axioms). That adds some complexity to test output. For example, a single evaluate-function-and-check-the-result operation can fail for more than one reason at once. Latest book: /Functional Programming for the Object-Oriented Programmer/ https://leanpub.com/fp-oo -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: On Testing
Additionally, I think it would be helpful to enumerate example (failing) tests and their output by current clojure.test. On Saturday, November 1, 2014 1:58:32 PM UTC-5, Alex Miller wrote: It would be great if someone could enumerate more explicitly what better test output means. What are the specific problems in the current test output reporting? Similar problem list for test runner might be useful. Discussion here is fine but ultimately needs to land on a design wiki page. I am happy to do what I can to move this through a process toward inclusion in a release. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: On Testing
http://jakemccrary.com/blog/2014/06/22/comparing-clojure-testing-libraries-output/ has some good examples. I'm currently using humane-test-output. It's worked nicely for me. '(Devin Walters) On Nov 1, 2014, at 7:00 PM, Alex Miller a...@puredanger.com wrote: Additionally, I think it would be helpful to enumerate example (failing) tests and their output by current clojure.test. On Saturday, November 1, 2014 1:58:32 PM UTC-5, Alex Miller wrote: It would be great if someone could enumerate more explicitly what better test output means. What are the specific problems in the current test output reporting? Similar problem list for test runner might be useful. Discussion here is fine but ultimately needs to land on a design wiki page. I am happy to do what I can to move this through a process toward inclusion in a release. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
