Re: update in place for unique references
Clean doesn't allow mutation, so it has to do tricks like this or else you'd never be able to write a useful program. Clojure gives you a set of data structures that do very fast non-destructive update. Clojure also gives you tools like atoms, refs, and full access to Java's mutable behavior to specify update in place if that's what you want. Since Clojure gives you a full range of immutable/mutable update choices, I fail to see how Clean's uniqueness typing is at all relevant to Clojure. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: writing bytes to a file
On Jan 7, 7:14 pm, "Brian Doyle" wrote: > (defn write-bytes > "Writes the bytes from the in-stream to the given filename." > [#^java.io.InputStream in-stream #^String filename] > (with-open [out-stream (new FileOutputStream filename)] > (let [buffer (make-array (Byte/TYPE) 4096)] > (loop [bytes (.read in-stream buffer)] > (if (not (neg? bytes)) > (do > (.write out-stream buffer 0 bytes) > (recur (.read in-stream buffer Might I suggest that write-bytes be renamed write-stream, or even spit- stream? Also it would be useful if it was divided into two functions: (defn pipe-stream "Pipe the contents of an InputStream into an OutputStream." ([in out] (pipe-stream in out 4096)) ([#^InputStream in #^OutputStream out bufsize] (let [buffer (make-array Byte/TYPE bufsize)] (loop [len (.read in buffer)] (when (pos? len) (.write out buffer 0 len) (recur (.read in buffer))) (def write-stream "Write the contents of an InputStream to a file." [in filename] (pipe-stream in (new FileOutputStream filename))) - James --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Slime buffer ns is always user
Thanks for your help with this problem, Bill. The function you provided causes slime-repl-set-package to suggest the correct namespace, which is convenient. It doesn't appear to have any effect on my problem though. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Clojure blog post about laziness
A few days ago, Stuart Halloway and I had an offline discussion about some of the "gotchas" related to Clojure's laziness. He encouraged me to blog about my thoughts on the matter. On a related note, about a month ago, I posted comments about Clojure's laziness. Rich's response was: "The argument you've made, however, is theoretical. I've tried what you said. In fact, it's sitting there in the implementation right now - just uncomment lazy-seq. cached-seq is there, as is a non-caching LazySeq class implementing ISeq, and all of the library functions can be defined in terms of it. I also did that, and then tried it and some common code. You should too, and report back your actual experience." So my blog post has a dual purpose. First, I explain the "gotcha" that Stuart and I discussed. Second, I report back to the community about the actual experience I had in the past month, exploring laziness in Clojure. I decided to blog it rather than post it here primarily due to its length. If you're at all interested in laziness, check it out: http://programming-puzzler.blogspot.com/ --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Probability distributions in Clojure
I have just added a new module for handling (finite) probability distributions to clojure-contrib. Some examples are included as well, but for those who want to see the examples without downloading the clojure-contrib source code, I also uploaded them to the files section of this group: http://groups.google.com/group/clojure/web/ probability_distributions.clj This module was initially inspired by the PFP library for Haskell (see http://web.engr.oregonstate.edu/~erwig/pfp/, and in particular the first paper under "further information"), but ended up being quite different: 1) PFP uses lists of (value probability) pairs to represent distributions. Clojure's maps are a more natural fit, so I use maps from values to probabilities. 2) At the moment, I have only implemented deterministic transformations of finite probability distributions. PFP also offers random sampling, which I plan to add in the future. 3) I added a second monad, cond-dist, which allows a straightforward implementation of Bayesian filters. 4) A significant part of the PFP code does nothing else but hide the implementation details behind a few abstract data types. This makes the code much more difficult to understand. In Clojure we don't have to deal with types, so this overhead disappears. Any feedback is welcome, as always! Konrad. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Probability distributions in Clojure
Hey Conrad, this is great. The only suggestion I'd make is that often times you want a probability distribution which is updatable over time. This happens in online learning as well as Gibbs sampling where you always only implicitly store the posterior b/c it's changing constantly. So in my research code, I typically seperate the sufficient statistics of a distribution (raw counts in the case of a multinomial as well as a total count to avoid wasteful re- computations) from the logic of yielding a probability (in the case of multinomials just return count/total-count). This way it's easy to update distributions and make changes on the fly such as altering your smoothing parameters. On Jan 8, 1:54 am, Konrad Hinsen wrote: > I have just added a new module for handling (finite) probability > distributions to clojure-contrib. Some examples are included as well, > but for those who want to see the examples without downloading the > clojure-contrib source code, I also uploaded them to the files > section of this group: > > http://groups.google.com/group/clojure/web/ > probability_distributions.clj > > This module was initially inspired by the PFP library for Haskell > (seehttp://web.engr.oregonstate.edu/~erwig/pfp/, and in particular > the first paper under "further information"), but ended up being > quite different: > > 1) PFP uses lists of (value probability) pairs to represent > distributions. Clojure's maps are a more natural fit, so I use maps > from values to probabilities. > > 2) At the moment, I have only implemented deterministic > transformations of finite probability distributions. PFP also offers > random sampling, which I plan to add in the future. > > 3) I added a second monad, cond-dist, which allows a straightforward > implementation of Bayesian filters. > > 4) A significant part of the PFP code does nothing else but hide the > implementation details behind a few abstract data types. This makes > the code much more difficult to understand. In Clojure we don't have > to deal with types, so this overhead disappears. > > Any feedback is welcome, as always! > > Konrad. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: update in place for unique references
> Clojure gives you a set of data structures that do very fast > non-destructive update. Clojure also gives you tools like atoms, > refs, and full access to Java's mutable behavior to specify update in > place if that's what you want. Yes, I can see that one could implement this oneself via Java. But it wouldn't be an official part of the language. What I am wondering is whether update-in-place for unique references could lead to greater efficiencies (in some cases) than Clojure's current non-destructive updates. And without harming referential transparency or concurrency benefits. Fundamentally I would have thought update-in-place beats update-by-replace in both execution speed and in memory usage. The only problem with it is that it usually breaks referential transparency as well as causing problems with concurrency. But in the case of a unique reference that is about to disappear, update-in-place does no harm! The memory is about to become obsolete soon anyway so why not commandeer it? And if commandeered, why not update it in place - as nothing else is looking at it. I realize there are issues, but maybe these could be solved and it could lead to even more efficient (both time and memory) code from Clojure, while not sacrificing its strengths. I'm just wondering whether anyone has thought about it. And if so, whether it has potential, or whether there are good reasons why it is not practical. Cheers, Mark P. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: yet another Clojure snake
Hi Mark, I don't think this approach works in Clojure / Swing, but I may be mistaken, I often am. The issue is the event thread. In Abhishek's original and it's derivatives the Swing event thread is used and the timer pushes events into it so key press events and the game timer run in the same thread. This allowed Stuart to pass the game into the function containing the JPanel proxy and for everything to live in the Swing event thread (which is hidden from the application). In fact the code should be safe without concurrency constructs. Using loop - recur means there are now two threads in the code (The app loop and Swing event loop) and these must be coordinated. This is, I think, why Mark needed that last global and Stuart didn't. I don't think there is a way to do this without some mutation because of the implementation of Swing, but, as I said, I may be wrong. There will need to be at least one concurrency construct. Cheers Tom 2009/1/6 Mark Engelberg > > One way to approach this without mutation is as follows: > > Decide on a data representation that represents the entire state of > the game world at a given instant. > > Write a function which can draw this state. > Write a function which takes the state and player keypresses as input, > and returns a new updated state. > Write a function which takes the state and returns the new state just > from time elapsing. > > Note that none of the above functions mutate anything. It's all about > returning fresh states, which fits well with Clojure's standard > handling of data structures. > > Then write a loop that consumes an initial state, and creates a game > experience by repeatedly applying the above functions. No globals or > refs are required, just keep passing the new states back into the loop > for further processing. > > This is an outline of the strategy employed by the "world" teachpack > that accompanies the "How to Design Programs" curriculum that uses PLT > Scheme. Students routinely develop the snake program as a homework > assignment, using this approach. > > > > --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Some code review for clj-record?
user=> (load-file "clj_record/core.clj") I got clj_record/util not in system path. Why is it so? Emeka --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Clojure blog post about laziness
On 08.01.2009, at 11:22, Mark Engelberg wrote: > So my blog post has a dual purpose. First, I explain the "gotcha" > that Stuart and I discussed. Second, I report back to the community > about the actual experience I had in the past month, exploring > laziness in Clojure. I decided to blog it rather than post it here > primarily due to its length. An interesting analysis. Looking my own applications, I tend to agree with your observations, but then I also have a similar code base as you have: almost all of it is purely functional code using Clojure's basic data structures. I also agree with your conclusion that the critical point is lazy sequences whose constructors are not referentially transparent. I wonder if there is any way to have them detected reliably (at compile time or at run time), but I expect this can't be done. Another solution would be to detect lazy sequences guaranteed to be purely functional because of the exclusive use of safe functions, and make them uncached by default. That should be doable but perhaps with an unreasonable effort or a high runtime penalty. Konrad. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Probability distributions in Clojure
On 08.01.2009, at 11:38, aria42 wrote: > Hey Conrad, this is great. The only suggestion I'd make is that often > times you want a probability distribution which is updatable over > time. This happens in online learning as well as Gibbs sampling where Definitely. The current module for transforming and combining distributions is just a first step in stochastic modelling in Clojure. Two important parts that are still missing are (1) sampling using pseudo-random numbers and (2) building distributions from input data. Konrad. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Clojure blog post about laziness
On Jan 8, 7:26 am, Konrad Hinsen wrote: > On 08.01.2009, at 11:22, Mark Engelberg wrote: > > > So my blog post has a dual purpose. First, I explain the "gotcha" > > that Stuart and I discussed. Second, I report back to the community > > about the actual experience I had in the past month, exploring > > laziness in Clojure. I decided to blog it rather than post it here > > primarily due to its length. > > An interesting analysis. Looking my own applications, I tend to agree > with your observations, but then I also have a similar code base as > you have: almost all of it is purely functional code using Clojure's > basic data structures. > > I also agree with your conclusion that the critical point is lazy > sequences whose constructors are not referentially transparent. I > wonder if there is any way to have them detected reliably (at compile > time or at run time), but I expect this can't be done. Another > solution would be to detect lazy sequences guaranteed to be purely > functional because of the exclusive use of safe functions, and make > them uncached by default. That should be doable but perhaps with an > unreasonable effort or a high runtime penalty. > The sequence abstraction in Clojure is the list abstraction of Lisp. No more, no less. It is inherently a persistent abstraction. When you ask for the nth element/rest, you get the identical item every time. All laziness adds is the fact that rest might not exist until you ask for it. Once you do, it's a Lisp list. It doesn't matter whether it originally came from an ephemeral source or a long-running calculation or whatever. The claim "So the amazing thing is that whether you choose to build a cached or uncached sequence, it makes not one bit of difference to the consumers of your sequence" is simply untrue. The promise of the abstraction is not merely that the nth item/rest will be equal - it is that it will be identical. I.e. a seq is persistent and immutable. There's nothing wrong with Lisp's list abstraction nor its realization as seqs in Clojure. Making seqs 'non-caching' makes no sense because they are no longer the same abstraction. Lazy != ephemeral. Seqs and streams are different abstractions. The questions really are, is there room for additional, ephemeral, abstraction - streams, and can filter/map et al be freed from working only with the seq abstraction. I've said yes to both of these and have a working solution that supports transparent interoperation of seqs and streams, thread safety, and single-source algorithm definition for both uses. It is not based on non-caching seqs. I've been holding off on integrating this as it is a fairly substantial change (under the hood, no change at all for consumers), introduces a new abstraction (though no impact until you use it), and might delay 1.0. Do people want it now? Rich --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: writing bytes to a file
On Thursday 08 January 2009 01:28, James Reeves wrote: > On Jan 7, 7:14 pm, "Brian Doyle" wrote: > > (defn write-bytes > > "Writes the bytes from the in-stream to the given filename." > > [#^java.io.InputStream in-stream #^String filename] > > (with-open [out-stream (new FileOutputStream filename)] > > (let [buffer (make-array (Byte/TYPE) 4096)] > > (loop [bytes (.read in-stream buffer)] > > (if (not (neg? bytes)) > > (do > > (.write out-stream buffer 0 bytes) > > (recur (.read in-stream buffer > > Might I suggest that write-bytes be renamed write-stream, or even > spit- stream? Also it would be useful if it was divided into two > functions: Please, no more spitting and slurping. These names are unpleasant. I really don't want to think about saliva and ingestion when programming. As for -bytes vs -stream, Streams operate on bytes in Java. Readers and Writers operate on characters. (A schism that never ceases to cause me problems in I/O programming..) So I don't think the suffix matters. However a function that both reads and writes should probably be called copy- or transfer- > ... > > - James Randall Schulz --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Reader metadata syntax vs. (with-meta ...)
Hi.
I'm just wondering wether it's a feature or a bug:
(if (= (meta (with-meta [] {:test-key true}))
(meta #^{:test-key true} []))
"same"
"not same")
=>
"not same"
This behaviour is repeatable for empty lists, vectors and maps. Is
this intentional? Nonempty collections work as expected.
Tomasz
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---
Re: Clojure blog post about laziness
On 08.01.2009, at 14:55, Rich Hickey wrote: > difference to the consumers of your sequence" is simply untrue. The > promise of the abstraction is not merely that the nth item/rest will > be equal - it is that it will be identical. I.e. a seq is persistent > and immutable. There's nothing wrong with Lisp's list abstraction nor > its realization as seqs in Clojure. > > Making seqs 'non-caching' makes no sense because they are no longer > the same abstraction. Lazy != ephemeral. Seqs and streams are > different abstractions. That makes sense, but I am probably not the only one who has used lazy sequences to implement streams. It's the closest abstraction currently available in Clojure. > I've been holding off on integrating this as it is a fairly > substantial change (under the hood, no change at all for consumers), > introduces a new abstraction (though no impact until you use it), and > might delay 1.0. > > Do people want it now? I'd use it right away in a few places in my code, so for me the answer is yes. On the other hand, lazy sequences work pretty well for me as well at the moment. Perhaps the better question is how important it is to get a version 1.0 out rapidly. Personally I don't care at all, but I can understand those who do. Konrad. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Clojure DSL & JVM method length limits
Isn't there a (roughly) 64k limit on the bytecode for any given method? There's definitely some kind of JVM limit. RJ On Jan 7, 12:12 am, Michiel de Mare wrote: > I'm converting a Ruby DSL into Clojure, and I'm running into some > problems. I keep getting errors like this one: > > java.lang.ClassFormatError: Invalid method Code length 91069 in class > file ... > > The DSL is a simple one - basically a long list of short forms. As > each forms is evaluated, it adds its data to a global dictionary. The > DSL is strictly run once; all I need is the dictionary, but when I run > the dsl, Clojure creates 2800 class files. > > I hope that's avoidable. Does anybody have suggestions? --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Clojure blog post about laziness
On Jan 8, 2009, at 8:55 AM, Rich Hickey wrote: > > > > On Jan 8, 7:26 am, Konrad Hinsen wrote: >> On 08.01.2009, at 11:22, Mark Engelberg wrote: >> >>> So my blog post has a dual purpose. First, I explain the "gotcha" >>> that Stuart and I discussed. Second, I report back to the community >>> about the actual experience I had in the past month, exploring >>> laziness in Clojure. I decided to blog it rather than post it here >>> primarily due to its length. >> >> An interesting analysis. Looking my own applications, I tend to agree >> with your observations, but then I also have a similar code base as >> you have: almost all of it is purely functional code using Clojure's >> basic data structures. >> >> I also agree with your conclusion that the critical point is lazy >> sequences whose constructors are not referentially transparent. I >> wonder if there is any way to have them detected reliably (at compile >> time or at run time), but I expect this can't be done. Another >> solution would be to detect lazy sequences guaranteed to be purely >> functional because of the exclusive use of safe functions, and make >> them uncached by default. That should be doable but perhaps with an >> unreasonable effort or a high runtime penalty. >> > > The sequence abstraction in Clojure is the list abstraction of Lisp. > No more, no less. It is inherently a persistent abstraction. When you > ask for the nth element/rest, you get the identical item every time. > All laziness adds is the fact that rest might not exist until you ask > for it. Once you do, it's a Lisp list. It doesn't matter whether it > originally came from an ephemeral source or a long-running calculation > or whatever. The claim "So the amazing thing is that whether you > choose to build a cached or uncached sequence, it makes not one bit of > difference to the consumers of your sequence" is simply untrue. The > promise of the abstraction is not merely that the nth item/rest will > be equal - it is that it will be identical. I.e. a seq is persistent > and immutable. There's nothing wrong with Lisp's list abstraction nor > its realization as seqs in Clojure. > > Making seqs 'non-caching' makes no sense because they are no longer > the same abstraction. Lazy != ephemeral. Seqs and streams are > different abstractions. > > The questions really are, is there room for additional, ephemeral, > abstraction - streams, and can filter/map et al be freed from working > only with the seq abstraction. I've said yes to both of these and have > a working solution that supports transparent interoperation of seqs > and streams, thread safety, and single-source algorithm definition for > both uses. It is not based on non-caching seqs. > > I've been holding off on integrating this as it is a fairly > substantial change (under the hood, no change at all for consumers), > introduces a new abstraction (though no impact until you use it), and > might delay 1.0. > > Do people want it now? I'd use it now. If it's more important to get 1.0 out, I'd happily wait until 1.1. > > > Rich > > > --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: update in place for unique references
Time for another person named Mark to chime in. I expect to hear from all the other Marks before this thread is over. I have three responses to your suggestion: 1. Data: Is this really a problem that is slowing down Clojure programs in practice? Can you provide some data to that effect? I would suggest writing a couple of Java benchmarks - one that updates a simple structure in place and one that only creates new data. Time them. Write more benchmarks, but this time do it in Clojure (though perhaps with some straight Java calls to make the updates). Are there differences in the Java versions from the Clojure versions? Are there differences in the update vs new data versions? My intuition is that you are not going to see a big speed up for this, but let's put the hypothesis to the test. As I understand it, short lived data is cheap to make and discard, as the copying collector doesn't have much to do if nursery data is discarded quickly. But, of course, there are costs to allocation, etc. Perhaps I am wrong. I would be interested to see data on the subject. 2. Take a page from the Scheme playbook. Don't ask the language to implement this feature, ask for the minimal set of tools that you need to implement it. I would think a code walking escape analysis macro could be very useful. Instead of run-time reference counting, the macro could find data that is guaranteed not to escape its scope via a closure (e.g. let bound locals that are not used in any (fn [] ...)s ). What would you need access to? Additional JVM byte-code instructions? Post-compile processing by user code? Update in place methods for the normally immutable types? I don't know exactly what you'd need, but ask for that before asking for a much bigger feature. 3. Remember that Clojure relies on the JVM for its allocation and GC. Clojure is not issuing malloc and free calls. The JVM will not make it easy to repurpose the storage of one object with a new object, without going through a method. As I see it, all functions would require an update-in-place version. The compiler could swap these behind the scenes, but writing them would be a lot of work. I could be wrong about this, as I am not a JVM expert, but without direct access to pointers, how else would this be accomplished? All in all, an interesting research topic -- especially if data show that a big speed up could be found by implementing it. Best of luck, -Mark On Jan 7, 2009, at 8:01 PM, Mark P wrote: > > I am new to clojure, but it seems very interesting. > > Has anyone thought about allowing "update in place" > for situations where it is safe? > > Suppose you have > > (def y (tripleit x)) > > and you know that there is only a single reference to x > at this point, then it would be safe to implement it as > > "y takes on the storage of x and this is multiplied > by 3 in-place". > > Well, I should say it's safe as long as "x" loses scope > at this point. The fact that y has gained its storage and > done an update in place shouldn't bother anyone or > cause any loss in purity. > > This is what "uniqueness types" are used for in the > "Clean" functional lanugage. (And logic language > Mercury uses "unique modes".) > > Now I realize there is the question in Clojure of > "how do we know whether it's unique". Clean does it > via the type system. But one could have other > mechanisms for ensuring uniqueness. One would be > to keep a runtime track of references and only allow an > update-in-place primitive in the case of a single reference. > If this were attempted when multiple references existed, > a runtime error would occur. > > Has anyone thought about this kind of update-in-place > methodology? It seems to be one of the reasons why > both Clean and Mercury achieve good performance. > > Perhaps there are good reasons why this approach is > not workable in clojure (or not useful), but I'd be > interested to hear why. > > Thanks, > > Mark. > > > --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: File organization & bootstrapping
On Jan 7, 12:19 am, "Phil Hagelberg" wrote: > The problem with this is that now you have to repeat your classpath in > two places: your SLIME config and the shell script that you use to > launch your app. This is a DRY[1] violation. I guess I just take that for granted with Java. The classpath is a nuisance, but it works. If you want to launch your app at the command line, use Ant to build a JAR that includes Clojure and all the necessary libraries. -Stuart Sierra --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: test-is: is called? [PATCH]
Nice work, Allen. I want to add stubs/mocks to test-is. One question -- would it work without Var.pushThreadBindings, maybe using a combination of "with-local-vars" and "binding"? I was also thinking of modifying "report" to throw AssertionError, like your "throwing-report", so that I can get a stack trace for where the error occurred. -Stuart Sierra On Jan 6, 11:06 pm, Allen Rohner wrote: > I had to revisit my test stubbing/expectation code after the recent > changes to test-is. The good news is, because of the excellent change > to make "is" a multi-method, the expectation code easily fits into > test-is. The following patch adds a new assertion for is, (is > (called?)) > > ;; creates a stub function, binds it to an existing var and asserts > ;; the stub fn was called the correct number of times. > > (is (called? [[user/foo :times 2 :returns 42] > [user/bar :times 1 :returns 3]] > (user/foo x y z) > (user/bar z))) > > Inside of the called? block, user/foo and user/bar are rebound to stub > functions, and then asserts that each function is called the proper > number of times. Currently, the only two options an expectation takes > are :times and :returns. I expect that more will be needed. > > http://groups.google.com/group/clojure/web/test_is_called.patch > > Allen --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: yet another Clojure snake
On Thu, Jan 8, 2009 at 5:08 AM, Tom Ayerst wrote: > Hi Mark, > > I don't think this approach works in Clojure / Swing, but I may be > mistaken, I often am. > > The issue is the event thread. In Abhishek's original and it's derivatives > the Swing event thread is used and the timer pushes events into it so key > press events and the game timer run in the same thread. This allowed Stuart > to pass the game into the function containing the JPanel proxy and for > everything to live in the Swing event thread (which is hidden from the > application). In fact the code should be safe without concurrency > constructs. > > Using loop - recur means there are now two threads in the code (The app loop > and Swing event loop) and these must be coordinated. This is, I think, why > Mark needed that last global and Stuart didn't. My latest code no longer has any globals. See the atom named key-code-atom at http://www.ociweb.com/mark/programming/ClojureSnake.html. > I don't think there is a way to do this without some mutation because of the > implementation of Swing, but, as I said, I may be wrong. There will need to > be at least one concurrency construct. The code at that URL does work. I haven't been able to think of a scenario where it might fail, despite the fact that I'm painting outside the event dispatch thread (EDT). However, if there's a better way to do this, I'm all ears! > 2009/1/6 Mark Engelberg >> >> One way to approach this without mutation is as follows: >> >> Decide on a data representation that represents the entire state of >> the game world at a given instant. >> >> Write a function which can draw this state. >> Write a function which takes the state and player keypresses as input, >> and returns a new updated state. >> Write a function which takes the state and returns the new state just >> from time elapsing. >> >> Note that none of the above functions mutate anything. It's all about >> returning fresh states, which fits well with Clojure's standard >> handling of data structures. >> >> Then write a loop that consumes an initial state, and creates a game >> experience by repeatedly applying the above functions. No globals or >> refs are required, just keep passing the new states back into the loop >> for further processing. >> >> This is an outline of the strategy employed by the "world" teachpack >> that accompanies the "How to Design Programs" curriculum that uses PLT >> Scheme. Students routinely develop the snake program as a homework >> assignment, using this approach. -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: writing bytes to a file
I incorporated most of James ideas but I don't like the name pipe-stream. (defn write-stream "Writes the data from the istream to the ostream." ([#^java.io.InputStream istream #^java.io.OutputStream ostream #^Integer buffer-size] (let [buffer (make-array (Byte/TYPE) buffer-size)] (loop [bytes (.read istream buffer)] (when (pos? bytes) (.write ostream buffer 0 bytes) (recur (.read istream buffer)) ([#^java.io.InputStream istream #^java.io.OutputStream ostream] (write-stream istream ostream 4096))) (defn write-stream-to-file "Writes the data from the istream to the file." ([#^java.io.InputStream istream #^String filename #^Integer buffer-size] (with-open [ostream (new FileOutputStream filename)] (write-stream istream ostream buffer-size))) ([#^java.io.InputStream istream #^String filename] (write-stream-to-file istream filename 4096))) On Thu, Jan 8, 2009 at 2:28 AM, James Reeves wrote: > > On Jan 7, 7:14 pm, "Brian Doyle" wrote: > >(defn write-bytes > > "Writes the bytes from the in-stream to the given filename." > > [#^java.io.InputStream in-stream #^String filename] > > (with-open [out-stream (new FileOutputStream filename)] > >(let [buffer (make-array (Byte/TYPE) 4096)] > > (loop [bytes (.read in-stream buffer)] > >(if (not (neg? bytes)) > > (do > >(.write out-stream buffer 0 bytes) > >(recur (.read in-stream buffer > > Might I suggest that write-bytes be renamed write-stream, or even spit- > stream? Also it would be useful if it was divided into two functions: > > (defn pipe-stream > "Pipe the contents of an InputStream into an OutputStream." > ([in out] >(pipe-stream in out 4096)) > ([#^InputStream in #^OutputStream out bufsize] >(let [buffer (make-array Byte/TYPE bufsize)] > (loop [len (.read in buffer)] >(when (pos? len) > (.write out buffer 0 len) > (recur (.read in buffer))) > > (def write-stream > "Write the contents of an InputStream to a file." > [in filename] > (pipe-stream in (new FileOutputStream filename))) > > - James > > > --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: yet another Clojure snake
The point, for me, is that Mark Engelberg's construct allowed the system to work with no mutation and I don't think you can do it with Swing implemented the way it is (your latest version puts the mutation in an atom). Given that, and the problems with to threads accessing the Swing layer, I think living in the EDT makes the most sense. For example the "everything in the EDT" approach takes advantage of Swing's painting features and deals with multiple events while cleanly painting the board; the two thread approach flickers terribly when the snake is short. Rgds. Tom 2009/1/8 Mark Volkmann > > On Thu, Jan 8, 2009 at 5:08 AM, Tom Ayerst wrote: > > > > Using loop - recur means there are now two threads in the code (The app > loop > > and Swing event loop) and these must be coordinated. This is, I think, > why > > Mark needed that last global and Stuart didn't. > > My latest code no longer has any globals. See the atom named key-code-atom > at > http://www.ociweb.com/mark/programming/ClojureSnake.html. > > > I don't think there is a way to do this without some mutation because of > the > > implementation of Swing, but, as I said, I may be wrong. There will need > to > > be at least one concurrency construct. > > The code at that URL does work. I haven't been able to think of a > scenario where it might fail, despite the fact that I'm painting > outside the event dispatch thread (EDT). However, if there's a better > way to do this, I'm all ears! > --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Slime buffer ns is always user
On Thu, Jan 8, 2009 at 2:01 AM, Zak Wilson wrote: > > Thanks for your help with this problem, Bill. > > The function you provided causes slime-repl-set-package to suggest the > correct namespace, which is convenient. It doesn't appear to have any > effect on my problem though. The slime-find-buffer-package-function function I posted will be used by slime in some functions that attempt to determine what the "active" namespace is in a buffer. You didn't mention what versions of slime and swank-clojure you are using, so perhaps you should try upgrading to the latest code. After you have done that, try the following simple experiment: Create a new file in your classpath called test.clj with the following 2 lines: (ns test) (defn x) Put the cursor after "(defn x)" and press C-x C-e. In the minibuffer, does it show "#'user/x" (therefore, "x" was defined in the "user" namespace)? If so, that is good and working as it should be working since Clojure doesn't "know" about the "test" namespace yet. Now, press C-x C-s to save the file and C-c C-k to compile the buffer. Then add the following line to the file: (defn y) Put the cursor after "(defn y)" and press C-x C-e. In the minibuffer, does it show "#'test/y" (therefore, "y" was defined in the "test" namespace)? If so, that is also good and working correctly. If you are not getting these results and you have upgraded to the latest slime/swank-clojure, then you might have some .emacs file settings that are causing the problem. Post your setup here if you are still not getting these results. - Bill --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Clojure blog post about laziness
> > Do people want it now? > I would vote for 1.0 ahead of streams if adding streams now will delay 1.0. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: yet another Clojure snake
On Thu, Jan 8, 2009 at 11:05 AM, Tom Ayerst wrote: > The point, for me, is that Mark Engelberg's construct allowed the system to > work with no mutation I don't yet see how that is possible. The detection of key presses has to happen in the Swing thread (by getting a call to keyPressed). That thread has to somehow make the key press known to the main thread. I see below that you are proposing that everything should happen in the Swing thread. My code uses key-code-atom to achieve communication between the Swing thread and the main thread. If there's a better way, I'm definitely interested in learning about it. > and I don't think you can do it with Swing implemented > the way it is (your latest version puts the mutation in an atom). Can you explain in more detail the issues you see with the current code? > Given that, and the problems with to threads accessing the Swing layer, I > think living in the EDT makes the most sense. For example the "everything > in the EDT" approach takes advantage of Swing's painting features and deals > with multiple events I don't remember now who suggested it, but an earlier critique of my code encouraged me to do as much processing as possible off the EDT. > while cleanly painting the board; the two thread > approach flickers terribly when the snake is short. I could be wrong, but I don't think that flicker is related to my choice of doing the painting off the EDT. I think it's just a matter of the relatively large cell size. -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: test-is: is called? [PATCH]
On Jan 8, 10:27 am, Stuart Sierra wrote: > Nice work, Allen. I want to add stubs/mocks to test-is. One question > -- would it work without Var.pushThreadBindings, maybe using a > combination of "with-local-vars" and "binding"? > It should be possible to make that work with binding. I did it that way because I was having problems making the call to binding work inside the macro. If someone with more macro-fu than I would like to look at it, I would love to see how it could be improved. Allen --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Clojure blog post about laziness
Mark, I thought your blog post was really, really good. I have forwarded it to a lot of people; I hope you don't mind! As far as caching goes: I think, regardless of the theoretical considerations of = that caching a lot of objects is ridiculous from a performance perspective. Access to ram takes a long, long time from the CPU's perspective and on-chip caches are never that big. In a world with lots of processing power and not that much bandwidth (not to mention the overhead of garbage collection and various other things) I never cache anything until I know it will provide a distinct benefit. I have to break newer programmers of that habit all the time (I work currently on 3d graphics on NVIDIA's Tegra platform). Furthermore, moving to Andriod platforms means you are dealing with a platform that is always going to be bandwidth and resource constrained as far as ram goes. The tradeoffs here are harder to make and require more research, but generally trying to compute things instead of store them will get you a lot farther especially with regards to the anemic on-chip cache that most ARM processors have. So clearly, for my applications I will be using the stream abstraction unless I have a reason to use the truly lazy (I wouldn't consider a non-caching approach truly lazy) approach. I am not criticizing the decision to be correct first and performant later, but I think that streams fit what I do much better than lazy seqs. I agree with Mark's assessment that the vast majority of the sequences in his program are either only used once or so cheap to create that caching is pointless. This matches my world that has an update-render loop where a lot of the information just doesn't matter after the rendering engine gets to it. Chris On Jan 8, 8:09 am, Matt Revelle wrote: > On Jan 8, 2009, at 8:55 AM, Rich Hickey wrote: > > > > > > > On Jan 8, 7:26 am, Konrad Hinsen wrote: > >> On 08.01.2009, at 11:22, Mark Engelberg wrote: > > >>> So my blog post has a dual purpose. First, I explain the "gotcha" > >>> that Stuart and I discussed. Second, I report back to the community > >>> about the actual experience I had in the past month, exploring > >>> laziness in Clojure. I decided to blog it rather than post it here > >>> primarily due to its length. > > >> An interesting analysis. Looking my own applications, I tend to agree > >> with your observations, but then I also have a similar code base as > >> you have: almost all of it is purely functional code using Clojure's > >> basic data structures. > > >> I also agree with your conclusion that the critical point is lazy > >> sequences whose constructors are not referentially transparent. I > >> wonder if there is any way to have them detected reliably (at compile > >> time or at run time), but I expect this can't be done. Another > >> solution would be to detect lazy sequences guaranteed to be purely > >> functional because of the exclusive use of safe functions, and make > >> them uncached by default. That should be doable but perhaps with an > >> unreasonable effort or a high runtime penalty. > > > The sequence abstraction in Clojure is the list abstraction of Lisp. > > No more, no less. It is inherently a persistent abstraction. When you > > ask for the nth element/rest, you get the identical item every time. > > All laziness adds is the fact that rest might not exist until you ask > > for it. Once you do, it's a Lisp list. It doesn't matter whether it > > originally came from an ephemeral source or a long-running calculation > > or whatever. The claim "So the amazing thing is that whether you > > choose to build a cached or uncached sequence, it makes not one bit of > > difference to the consumers of your sequence" is simply untrue. The > > promise of the abstraction is not merely that the nth item/rest will > > be equal - it is that it will be identical. I.e. a seq is persistent > > and immutable. There's nothing wrong with Lisp's list abstraction nor > > its realization as seqs in Clojure. > > > Making seqs 'non-caching' makes no sense because they are no longer > > the same abstraction. Lazy != ephemeral. Seqs and streams are > > different abstractions. > > > The questions really are, is there room for additional, ephemeral, > > abstraction - streams, and can filter/map et al be freed from working > > only with the seq abstraction. I've said yes to both of these and have > > a working solution that supports transparent interoperation of seqs > > and streams, thread safety, and single-source algorithm definition for > > both uses. It is not based on non-caching seqs. > > > I've been holding off on integrating this as it is a fairly > > substantial change (under the hood, no change at all for consumers), > > introduces a new abstraction (though no impact until you use it), and > > might delay 1.0. > > > Do people want it now? > > I'd use it now. If it's more important to get 1.0 out, I'd happily > wait until 1.1. > > > > > Rich --~--~-~
Re: Clojure blog post about laziness
On Thu, Jan 8, 2009 at 5:55 AM, Rich Hickey wrote: > The > promise of the abstraction is not merely that the nth item/rest will > be equal - it is that it will be identical. I.e. a seq is persistent > and immutable. I get that Clojure is making a promise of identity here, which is not possible if things uncached. But I look at this from a pragmatic standpoint and wonder how much people are relying on that promise? I notice that I haven't written any code that uses identical? And if I did, I don't think I'd mind the overhead of explicitly wrapping the sequence in a call to cache-seq. If people don't need this promise as a rule, maybe it's okay to rethink the abstraction, and start thinking of it as just a way to get the "first" and "rest" of a bunch of items, possibly generated by need, and with no other promises implied. As to your question, I'd vote for streams now. As you can tell from my posts, my own code centers around generating long sequences of things, and the current seq abstraction is just not quite the right fit. I'd really like to get my hands on streams and see whether they work better for my needs. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: yet another Clojure snake
On Thu, Jan 8, 2009 at 12:05 PM, Tom Ayerst wrote: > The point, for me, is that Mark Engelberg's construct allowed the system to > work with no mutation and I don't think you can do it with Swing implemented > the way it is (your latest version puts the mutation in an atom). Isn't a GUI by definition mutable state? Something is visible on the screen, and then you want to change that so something else is visible. There's really nothing Swing or any other GUI API could do to make that not true, is there? If not, then there's got to be some non-functional part of the app that pushes the current state out to the GUI. Given that, it may be cleanest to keep the latest version of the game state in some clojure-managed mutable reference, like an agent or ref. --Chouser --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Clojure blog post about laziness
On Jan 8, 2009, at 1:06 PM, Mark Engelberg wrote: > > On Thu, Jan 8, 2009 at 5:55 AM, Rich Hickey > wrote: >> The >> promise of the abstraction is not merely that the nth item/rest will >> be equal - it is that it will be identical. I.e. a seq is persistent >> and immutable. > > I get that Clojure is making a promise of identity here, which is not > possible if things uncached. But I look at this from a pragmatic > standpoint and wonder how much people are relying on that promise? I > notice that I haven't written any code that uses identical? And if I > did, I don't think I'd mind the overhead of explicitly wrapping the > sequence in a call to cache-seq. If people don't need this promise as > a rule, maybe it's okay to rethink the abstraction, and start thinking > of it as just a way to get the "first" and "rest" of a bunch of items, > possibly generated by need, and with no other promises implied. I think the real test of non-cached seqs is to swap them in for regular seqs, rebuild Clojure and some user libs and see what breaks and why. Then you'll see the dependencies on caching that exist in the real world. Your purely functional code might not care, other than perf, but that is not the only user base Clojure and I need to support. Rich --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: writing bytes to a file
On Jan 8, 5:05 pm, "Brian Doyle" wrote: > I incorporated most of James ideas but I don't like the name pipe-stream. Then wouldn't copy-stream be better? write-stream isn't specific enough, IMO. Also, I don't think there's a huge amount of gain to be had from an Integer type hint in this case, since it's only used once, or for two sets of type hints for the same function. - James --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Clojure blog post about laziness
On Thu, Jan 8, 2009 at 10:20 AM, Rich Hickey wrote: > On Thu, Jan 8, 2009 at 5:55 AM, Rich Hickey > I think the real test of non-cached seqs is to swap them in for > regular seqs, rebuild Clojure and some user libs and see what breaks > and why. Then you'll see the dependencies on caching that exist in the > real world. Your purely functional code might not care, other than > perf, but that is not the only user base Clojure and I need to support. > > Rich I tried to do that, swapping lazy-cons in core.clj to use the commented out code from the lazy-seq macro, but I couldn't get Clojure to build. Clearly something in the bootstrapping code relied on lazy-cons working exactly the way it works. So yes, it is clear that there are currently some dependencies on lazy-cons being cached. What is less clear is whether those depedencies can be easily isolated and rewritten to explicitly use a separate caching version of lazy-cons, leaving the rest of the codebase free to use an uncached variation of lazy-cons by default. I didn't understand the code well enough to find the conflict that was preventing the code from building, so I ended up separating out the uncached variations as a separate library so I could at least experiment within my own code. But I agree that rebuilding Clojure in this way would be very enlightening. Maybe I'll take another stab at it... --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Gen-interface signature
A little time with the Clojure source and a debugger has been
illuminating.
In genclass.clj:gen-interface, the line:
(let [options-map (apply hash-map options)
results in this value for options-map:
{:methods [[(quote foo) [] []]], :name mypkg.ICompileTest}
It looks like "(quote foo)" is being taken as the literal string name,
rather than evaluating to "foo". And it happens that the hex ascii in
the generated method name translates to: [](quote foo).
Seems suspiciously like a macro-time vs fn-time thing... I will submit
an issue on this & see if I can work out a patch.
On Jan 7, 10:39 pm, Greg Harman wrote:
> I'm playing around with gen-interface, and compiled the following:
>
> (ns mypkg.compiletest)
> (gen-interface :name mypkg.ICompileTest
> :methods [['foo [] []]])
>
> I then used a java .class decompiler to look at the resulting .class
> file expecting to see an interface with a single method called "foo"
> but instead I see this:
>
> package mypkg;
>
> public interface ICompileTest {
> public abstract _5B__5D_ _28_quote_20_foo_29_();
>
> }
>
> My questions:
> 1. Why is the method name "_5B__5D_ _28_quote_20_foo_29_" instead of
> "foo"?
> 2. Why is the method abstract? I'm not aware of any meaning for the
> abstract keyword in an interface - not that that means there isn't a
> meaning... :-)
>
> -Greg
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---
Re: sort behavior question
There are two issues here that I'm seeing, first is that the list and vector have different behavior, my understanding is that they are both sequences and one should be able to perform the same operations on them. Second issue is that the behavior is inconsistent, if it is not possible to sort tuples with a list as a second element, then it should never work, as opposed to working sometimes on some data sets. The inconsistency of the behavior is troubling. On Jan 7, 11:47 pm, ".Bill Smith" wrote: > I wonder if the root cause might be clearer if you were to review the > documentation for the sort function and then apply what it says to a > smaller dataset, e.g. a pair of lists. > > Bill --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Bug? overflow check in Numbers.minus
Hi all!
I encountered some corner cases where overflow checking for "-"
doesn't work as I would expect:
user=> (- Integer/MAX_VALUE Integer/MIN_VALUE)
-1
user=> (- Long/MAX_VALUE Long/MIN_VALUE)
-1
The problem seems to be that negating MIN_VALUE yields MIN_VALUE
again, so it slips through the overflow check (see below).
Shall I add that to the issues list?
Kind regards,
achim
src/jvm/clojure/lang/Numbers.java
===
--- src/jvm/clojure/lang/Numbers.java (revision 1205)
+++ src/jvm/clojure/lang/Numbers.java (working copy)
@@ -1740,7 +1740,7 @@
static public int minus(int x, int y){
int ret = x - y;
- if ((ret ^ x) < 0 && (ret ^ -y) < 0)
+ if (((ret ^ x) < 0 && (ret ^ -y) < 0) || (y == Integer.MIN_VALUE))
return throwIntOverflow();
return ret;
}
@@ -1847,7 +1847,7 @@
static public long minus(long x, long y){
long ret = x - y;
- if ((ret ^ x) < 0 && (ret ^ -y) < 0)
+ if (((ret ^ x) < 0 && (ret ^ -y) < 0) || (y == Long.MIN_VALUE))
return throwIntOverflow();
return ret;
}
--~--~-~--~~~---~--~~
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
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
-~--~~~~--~~--~--~---
Re: sort behavior question
On Jan 8, 2009, at 1:55 PM, Dmitri wrote: There are two issues here that I'm seeing, first is that the list and vector have different behavior, my understanding is that they are both sequences and one should be able to perform the same operations on them. I don't know more about the underlying issue, but there's a distinction between *being* a seq and being "seq-able". Something is a seq if it implements the ISeq interface. Lists are seqs, vectors are not seqs. user=> (instance? clojure.lang.ISeq '(1 2 3)) true user=> (instance? clojure.lang.ISeq '[1 2 3]) false Something is seq-able if one can create a seq through which its contents can be viewed sequentially by calling calling "seq" on it. Lists and vectors are both seq-able. user=> (instance? clojure.lang.ISeq (seq '(1 2 3))) true user=> (instance? clojure.lang.ISeq (seq '[1 2 3])) true The distinction is often blurred because most functions that accept a seq automatically call "seq" on the subset of their arguments that they expect to use as seqs. You may have hit on a situation where the distinction matters. --Steve smime.p7s Description: S/MIME cryptographic signature
Re: Gen-interface signature
Hi, Am 08.01.2009 um 19:38 schrieb Greg Harman: It looks like "(quote foo)" is being taken as the literal string name, rather than evaluating to "foo". And it happens that the hex ascii in the generated method name translates to: [](quote foo). Seems suspiciously like a macro-time vs fn-time thing... I will submit an issue on this & see if I can work out a patch. (ns mypkg.compiletest) (gen-interface :name mypkg.ICompileTest :methods [['foo [] []]]) I think the quote is superfluous here. Try: (gen-interface :name mypkg.ICompileTest :methods [[foo [] []]]) Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: Gen-interface signature
Hi again, Am 08.01.2009 um 19:38 schrieb Greg Harman: A little time with the Clojure source and a debugger has been illuminating. (gen-interface :name clojure.example.IBar :methods [[bar [] String]]) You find this example and further information on clojure.org. http://clojure.org/compilation Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: writing bytes to a file
On Thu, Jan 8, 2009 at 11:34 AM, James Reeves wrote: > > On Jan 8, 5:05 pm, "Brian Doyle" wrote: > > I incorporated most of James ideas but I don't like the name pipe-stream. > > Then wouldn't copy-stream be better? write-stream isn't specific > enough, IMO. > Sure, write-stream works for me. > > Also, I don't think there's a huge amount of gain to be had from an > Integer type hint in this case, since it's only used once, or for two > sets of type hints for the same function. Agreed. I had hinted on the other params and just thought I'd do it for the Integer type as well. > > > - James > > > --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: writing bytes to a file
On Thu, Jan 8, 2009 at 12:36 PM, Brian Doyle wrote: > > > On Thu, Jan 8, 2009 at 11:34 AM, James Reeves > wrote: > >> >> On Jan 8, 5:05 pm, "Brian Doyle" wrote: >> > I incorporated most of James ideas but I don't like the name >> pipe-stream. >> >> Then wouldn't copy-stream be better? write-stream isn't specific >> enough, IMO. >> > > Sure, write-stream works for me. > Sorry, I meant that copy-stream works for me. It's been a long day already :( > > > >> >> Also, I don't think there's a huge amount of gain to be had from an >> Integer type hint in this case, since it's only used once, or for two >> sets of type hints for the same function. > > > Agreed. I had hinted on the other params and just thought I'd do it for > the Integer type as well. > > >> >> >> - James >> >> >> > --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Slime buffer ns is always user
Everything is fully up to date. The test works. Setting the ns with (ns test) works, but if I use a more complex ns form like (ns test (:use clojure.xml)), it fails to set the ns. As a workaround, (in-ns test) after the ns definition seems to work. Unless there's some reason not to, I'll just do it that way for now. Thanks for the help. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: sort behavior question
I tried this again with the latest build from svn, and it seems that lists may be running into a race condition due to their lazy nature: Exception in thread "main" java.lang.RuntimeException: java.lang.ClassCastException: clojure.lang.LazyCons cannot be cast to java.lang.Comparable On Jan 8, 2:11 pm, "Stephen C. Gilardi" wrote: > On Jan 8, 2009, at 1:55 PM, Dmitri wrote: > > > There are two issues here that I'm seeing, first is that the list and > > vector have different behavior, my understanding is that they are both > > sequences and one should be able to perform the same operations on > > them. > > I don't know more about the underlying issue, but there's a > distinction between *being* a seq and being "seq-able". > > Something is a seq if it implements the ISeq interface. Lists are > seqs, vectors are not seqs. > > user=> (instance? clojure.lang.ISeq '(1 2 3)) > true > user=> (instance? clojure.lang.ISeq '[1 2 3]) > false > > Something is seq-able if one can create a seq through which its > contents can be viewed sequentially by calling calling "seq" on it. > Lists and vectors are both seq-able. > > user=> (instance? clojure.lang.ISeq (seq '(1 2 3))) > true > user=> (instance? clojure.lang.ISeq (seq '[1 2 3])) > true > > The distinction is often blurred because most functions that accept a > seq automatically call "seq" on the subset of their arguments that > they expect to use as seqs. > > You may have hit on a situation where the distinction matters. > > --Steve > > smime.p7s > 3KViewDownload --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: yet another Clojure snake
2009/1/8 Mark Volkmann > > On Thu, Jan 8, 2009 at 11:05 AM, Tom Ayerst wrote: > > The point, for me, is that Mark Engelberg's construct allowed the system > to > > work with no mutation > > I don't yet see how that is possible. We agree then. > ... > > Can you explain in more detail the issues you see with the current code? > > > Given that, and the problems with to threads accessing the Swing layer, I > > think living in the EDT makes the most sense. For example the > "everything > > in the EDT" approach takes advantage of Swing's painting features and > deals > > with multiple events > See above. I don't remember now who suggested it, but an earlier critique of my > code encouraged me to do as much processing as possible off the EDT. This is one of those 'it depends' questions. You can safely do everything in the EDT in Swing, it will just be very sluggish (and freeze occasionally) if you have long running actions on events. So it is good practice to spin off workers in separate threads for anything that will take a while. Nothing in the snake app falls into that category. Also; if you are spining off additional threads they must use invokeLater to safely rejoin the EDT for displaying updates. > > while cleanly painting the board; the two thread > > approach flickers terribly when the snake is short. > > I could be wrong, but I don't think that flicker is related to my > choice of doing the painting off the EDT. I think it's just a matter > of the relatively large cell size. > I use the same cell sizes on a derivative of Stuart's version and that does not flicker. Cheers Tom --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: yet another Clojure snake
2009/1/8 Tom Ayerst > 2009/1/8 Mark Volkmann > >> >> > while cleanly painting the board; the two thread >> > approach flickers terribly when the snake is short. >> >> I could be wrong, but I don't think that flicker is related to my >> choice of doing the painting off the EDT. I think it's just a matter >> of the relatively large cell size. >> > > I use the same cell sizes on a derivative of Stuart's version and that does > not flicker. > Actually I think the main problem is your snake painting algorithm when the body is one cell long, I'll have a longer look later. Cheers Tom --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: sort behavior question
Lists are not comparable (i.e., you can't do something like (< '(1 2 3) '(4 5 6))). So you can't sort a collection of lists, but you can sort a collection of vectors (provided the vectors contain comparable things). This is always the case; there is no inconsistency. The reason you are sometimes not getting an error is that when you randomly generate small collections of vectors, often the first element will be enough to sort the collection, so it never tries to compare the second elements, which in this case are lists. I'm not sure why lists don't implement comparable. Offhand I can't think of a reason why they wouldn't, but perhaps there is a reason. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Clojure blog post about laziness
I'd vote for increased priority to reaching 1.0 also because of workplace constraints. Kev On Jan 9, 4:23 am, MikeM wrote: > > Do people want it now? > > I would vote for 1.0 ahead of streams if adding streams now will delay > 1.0. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
SLIME: trouble with java.lang.OutOfMemoryError
I was playing around earlier while following Mark Engelberg's blog post, and I found that to my surprise, when I exhaust the heap (java.lang.OutOfMemoryError), it basically fails to pop up the window that gives me the exception (where you can normally abort or throw the cause), and the REPL itself only shows "; Evaluation aborted" and is non-responsive (sometimes it will show the exception in the REPL itself). In order to resolve this, I've tried the following steps: - update swank-clojure to latest - update SLIME to latest - update clojure itself to latest None of these help. Other exceptions I've deliberately caused, such as an NPE, work as expected with SLIME. Can anyone else reproduce this behavior ? In the past, specifically when playing with filter, I have exhausted the heap many times with clojure, and SLIME has always worked perfectly - I'm not sure when this behavior was introduced but I haven't been able to track down exactly when it started happening. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Clojure blog post about laziness
If streams are not a breaking change, my vote is to ship 1.0 and then add them. Stuart > I've been holding off on integrating this as it is a fairly > substantial change (under the hood, no change at all for consumers), > introduces a new abstraction (though no impact until you use it), and > might delay 1.0. > > Do people want it now? > > Rich > --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: finding all vars starting with *
On Tue, Jan 6, 2009 at 2:53 PM, rzeze...@gmail.com wrote: > > On Jan 4, 6:05 pm, "Brian Doyle" wrote: >> Is there some place where all of these vars are defined? Is there some way >> programatically I can find >> them all? Thanks. > > I'm bored, and as an excuse to write some code I thought I'd try to > come up with a solution. > > You can see it here: http://paste.lisp.org/display/73196 > > It could be made better with some of the clojure.contrib.ns-utils > stuff. > > I'm a n00b, use at your own risk :) Not bad, though putting all the names into a single string before doing the regex is a bit startling. Here's another crack at it: (doseq [[sym vr] (mapcat ns-publics (all-ns)) :when (re-find #"^\*" (str sym))] (print-doc vr)) This highlights, though, how many are missing doc strings. Thus: http://code.google.com/p/clojure/issues/detail?id=9 --Chouser --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Slime buffer ns is always user
On Thu, Jan 8, 2009 at 11:57 AM, Zak Wilson wrote: > > Everything is fully up to date. > > The test works. Setting the ns with (ns test) works, but if I use a > more complex ns form like (ns test (:use clojure.xml)), it fails to > set the ns. > > As a workaround, (in-ns test) after the ns definition seems to work. > Unless there's some reason not to, I'll just do it that way for now. > Thanks for the help. It looks like the regular expression that matches namespaces in swank-clojure.el doesn't cater for some combinations of namespace statements. Could you evaluate the following elisp function and let me know whether this fixes the issue for you: (defun swank-clojure-find-package () (let ((regexp "^(\\(clojure.core/\\)?\\(in-\\)?ns\\s-+[:']?\\([^ ()]*\\>\\)[ ()]")) (save-excursion (when (or (re-search-backward regexp nil t) (re-search-forward regexp nil t)) (match-string-no-properties 3) It appears to work ok for me with the following namespace declarations: (in-ns 'test) (ns test) (ns test (:use clojure.xml)) But, it would be good if you could test it with some other combinations before I submit it to Jeffrey as a patch. - Bill --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: sort behavior question
I think the main issue is that sort should behave consistently. Possibly sort could check if the elements implement Comparable before attempting to sort them? I also don't see a reason as to why the lists shouldn't implement Comparable. On Jan 8, 4:17 pm, "Mark Engelberg" wrote: > Lists are not comparable (i.e., you can't do something like (< '(1 2 > 3) '(4 5 6))). So you can't sort a collection of lists, but you can > sort a collection of vectors (provided the vectors contain comparable > things). This is always the case; there is no inconsistency. > > The reason you are sometimes not getting an error is that when you > randomly generate small collections of vectors, often the first > element will be enough to sort the collection, so it never tries to > compare the second elements, which in this case are lists. > > I'm not sure why lists don't implement comparable. Offhand I can't > think of a reason why they wouldn't, but perhaps there is a reason. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Gen-interface signature
Thanks, Meikel. I feel a bit silly, but I do have it working now. * Not quoting foo is more than superfluous; it was the primary cause of my problem. I did study that clojure.org example, just missed the lack of quote... * There wasn't an example of a void return type and I assumed that, like an empty argument list, it would be []. Wrong - turns out it should be void, as in: [foo [] void]. Perhaps this would be a useful example to add to that page? -Greg --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: yet another Clojure snake
On Fri, Jan 9, 2009 at 7:55 AM, Tom Ayerst wrote: > 2009/1/8 Mark Volkmann >> >> On Thu, Jan 8, 2009 at 11:05 AM, Tom Ayerst wrote: >> > The point, for me, is that Mark Engelberg's construct allowed the system >> > to >> > work with no mutation >> >> I don't yet see how that is possible. > > We agree then. > >> >> ... >> >> Can you explain in more detail the issues you see with the current code? >> >> > Given that, and the problems with to threads accessing the Swing layer, >> > I >> > think living in the EDT makes the most sense. For example the >> > "everything >> > in the EDT" approach takes advantage of Swing's painting features and >> > deals >> > with multiple events > > See above. > >> I don't remember now who suggested it, but an earlier critique of my >> code encouraged me to do as much processing as possible off the EDT. > > This is one of those 'it depends' questions. You can safely do everything > in the EDT in Swing, it will just be very sluggish (and freeze occasionally) > if you have long running actions on events. So it is good practice to spin > off workers in separate threads for anything that will take a while. > Nothing in the snake app falls into that category. Also; if you are spining > off additional threads they must use invokeLater to safely rejoin the EDT > for displaying updates. As a newbie looking for good example coding styles - I'd definitely prefer if this were coded for the "normal" case, rather than made special for the "no long running actions" case. I really appreciate this code, by the way. One of my biggest barriers to using Clojure is the terseness of the examples - stuff like http://clojure.org/agents#toc , while nice and concise, is quite off-putting for people used to more readable coding styles. - Korny > >> >> > while cleanly painting the board; the two thread >> > approach flickers terribly when the snake is short. >> >> I could be wrong, but I don't think that flicker is related to my >> choice of doing the painting off the EDT. I think it's just a matter >> of the relatively large cell size. > > I use the same cell sizes on a derivative of Stuart's version and that does > not flicker. > > Cheers > > Tom > > > > > -- Kornelis Sietsma korny at my surname dot com kornys at gmail dot com on google chat -- kornys on skype "Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of" --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
clj-backtrace uses: screenshots and example code
Hi all, A little while ago I released clj-backtrace, a library that produces more readable backtraces for Clojure programs. I originally conceived of the library as just a better (.printStackTrace *e) for use at the REPL, but I've since found some other neat uses. I'd just like to share some screenshots and code that demonstrate these uses: perhaps they will catch your interest. One use for clj-backtrace is better debugging output for errors that occur during unit tests. In the experimental clj-unit framework I use the parse-exception function to introspect on the stack trace, remove those elements that are at or below the test-running logic in the stack, and then use print-trace-elems to pretty-print the remaining, interesting stack elements. http://skitch.com/mmcgrana/byuuj/clj-backtrace-unit-tests http://github.com/mmcgrana/clj-garden/tree/master/clj-unit/src/clj_unit/console_reporter.clj Another use is debugging Clojure webapps. For example, I created some experimental "show exceptions" middleware for a webapp that catches exceptions that occur in the app code and shows a helpful stacktrace in the browser. http://skitch.com/mmcgrana/byu15/clj-backtrace-web-app http://github.com/mmcgrana/clj-garden/tree/master/cwsg/src/cwsg/middleware/show_exceptions.clj I also dump the stacktrace to the webapp's log, just like one would do at the REPL: http://skitch.com/mmcgrana/byuu6/clj-backtrace-logging If these examples seem interesting to you, I encourage you to check out the project page on GitHub: http://github.com/mmcgrana/clj-backtrace/tree/master I'd also be happy to answer any questions you have about using the library and to hear any general comments. - Mark --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: clj-backtrace uses: screenshots and example code
Mark McGranaghan writes: > I'd also be happy to answer any questions you have about using the > library and to hear any general comments. This looks great! I love the way they're aligned. Have you looked at the way Rubinius (a smalltalk-style Ruby VM) prints backtraces? It's pretty similar, although it goes one step further by coloring different portions of the backtraces differently depending on where they came from. See the example in the middle of this article: http://programblings.com/2008/04/15/rubinius-for-the-layman-part-2-how-rubinius-is-friendly/ I would love to see clojure.core code in one color, java-level code in another, "unknown source" (repl-entered) code in another, and my application's code in white. I'll definitely be using this; thanks. -Phil --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
loading namespace from AOT compiled files vs source files
Hello, There is a difference in using (require) on a namespace if it was compiled via (compile) or if it uses plain clj source files. The difference appears if in the source file, you have for example top level (println) commands. If you (require) the namespace from compiled classes, you will not have the top level (println) command executed (it has not been compiled, and it seems normal). But if you (require) the namespace from the corresponding source file, you will have the top level (println) commands executed. Do you think that "in theory", it is normal for namespaces/libs to have top level calls (other than ones that create and assign vars) such as the top level (println) (or maybe something more usefull :-) (maybe start some code that installs agents, ... ?) when loaded / required / used ? If yes, do you think it is acceptable to not have those top level calls made if the lib is loaded / required / used from its compiled version ? I imagine then that it may still be possible to make a tweak that will be assigning a "fake" var with an expression whose return value we don't care about, but its side effects we care about. Then, should there be some standard way in clojure to do this kind of lib initialization stuff ? (Some macro ?) And also, could (compile) not allow libs to be compiled if they contain top level calls (thus preventing the behaviour of the compiled version differ from the behaviour of the uncompiled one) ? Or could (compile) embed all the top level calls that are not translated into class code in some initialization section of the ns that could then be called at the end of the ns loading ? Thanks in advance for your answers, Cheers, -- Laurent --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
(compile) also loads the lib ?
Hello, It seems that (compile) generates .class files as expected, and also loads the lib in the environment as well. Is it a (apparently undocument) feature ? Or a bug ? And also, it seems that (compile) does not load the lib from the compiled classes, but from the source files. I guess that, because if the lib contains top level calls that do not contribute to produce the classes (for example top level (println)s), when I call (compile), those (println)s are executed. Later on, if I call (load) (from a fresh clojure environment) from the compiled classes, the top level (println)s are not executed, since not compiled. Thanks in advance for your answers/remarks, Regards, -- Laurent --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
How can I find all files ending with .clj, for example
Hi all, I can use file-seq (file-seq (File. ".")) But how can I filter out all files ending with .clj? Do we use re-find, re-seq etc? thanks sun --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: How can I find all files ending with .clj, for example
Here's one of many ways to do this: (filter #(.endsWith (.getName %1) ".clj" ) (file-seq (java.io.File. "."))) On Thu, Jan 8, 2009 at 5:48 PM, wubbie wrote: > > Hi all, > > I can use file-seq > (file-seq (File. ".")) > But how can I filter out all files ending with .clj? > Do we use re-find, re-seq etc? > > thanks > sun > > > > --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: How can I find all files ending with .clj, for example
On Jan 9, 12:48 am, wubbie wrote: > I can use file-seq > (file-seq (File. ".")) > But how can I filter out all files ending with .clj? > Do we use re-find, re-seq etc? You can just use filter: (filter #(.endsWith (str %) ".clj") (file-seq (File. "."))) - James --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: How can I find all files ending with .clj, for example
thanks, Is there anyway to specify regular expression, instead of startsWith/ endsWith? -sun On Jan 8, 8:00 pm, James Reeves wrote: > On Jan 9, 12:48 am, wubbie wrote: > > > I can use file-seq > > (file-seq (File. ".")) > > But how can I filter out all files ending with .clj? > > Do we use re-find, re-seq etc? > > You can just use filter: > > (filter > #(.endsWith (str %) ".clj") > (file-seq (File. "."))) > > - James --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: How can I find all files ending with .clj, for example
Hi! (filter #(re-find #".clj$" %) … ) see http://java.sun.com/j2se/1.5.0/docs/api/java/util/regex/Pattern.html (Boundary matchers) Kind regards, achim On 9 Jan., 02:39, wubbie wrote: > thanks, > > Is there anyway to specify regular expression, instead of startsWith/ > endsWith? > -sun > > On Jan 8, 8:00 pm, James Reeves wrote: > > > On Jan 9, 12:48 am, wubbie wrote: > > > > I can use file-seq > > > (file-seq (File. ".")) > > > But how can I filter out all files ending with .clj? > > > Do we use re-find, re-seq etc? > > > You can just use filter: > > > (filter > > #(.endsWith (str %) ".clj") > > (file-seq (File. "."))) > > > - James --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: How can I find all files ending with .clj, for example
On 9 Jan., 03:03, Achim Passen wrote: > (filter #(re-find #".clj$" %) … ) correction: (filter #(re-find #"\.clj$" %) … ) --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: How can I find all files ending with .clj, for example
I tried (filter #(re-find #"\.clj$" %) (seq (file-seq(java.io.File. "." -> java.lang.ClassCastException: java.io.File cannot be cast to java.lang.CharSequence (NO_SOURCE_FILE:0) On Jan 8, 9:06 pm, Achim Passen wrote: > On 9 Jan., 03:03, Achim Passen wrote: > > > (filter #(re-find #".clj$" %) … ) > > correction: > (filter #(re-find #"\.clj$" %) … ) --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: How can I find all files ending with .clj, for example
This works: (filter #(re-find #"\.clj$" (str %)) (file-seq(java.io.File. "."))) On Thu, Jan 8, 2009 at 7:16 PM, wubbie wrote: > > I tried > > (filter #(re-find #"\.clj$" %) (seq (file-seq(java.io.File. "." > -> java.lang.ClassCastException: java.io.File cannot be cast to > java.lang.CharSequence (NO_SOURCE_FILE:0) > > > On Jan 8, 9:06 pm, Achim Passen wrote: > > On 9 Jan., 03:03, Achim Passen wrote: > > > > > (filter #(re-find #".clj$" %) … ) > > > > correction: > > (filter #(re-find #"\.clj$" %) … ) > > > --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: How can I find all files ending with .clj, for example
thank, it was str as usual. On Jan 8, 9:22 pm, "Brian Doyle" wrote: > This works: > > (filter #(re-find #"\.clj$" (str %)) (file-seq(java.io.File. "."))) > > On Thu, Jan 8, 2009 at 7:16 PM, wubbie wrote: > > > I tried > > > (filter #(re-find #"\.clj$" %) (seq (file-seq(java.io.File. "." > > -> java.lang.ClassCastException: java.io.File cannot be cast to > > java.lang.CharSequence (NO_SOURCE_FILE:0) > > > On Jan 8, 9:06 pm, Achim Passen wrote: > > > On 9 Jan., 03:03, Achim Passen wrote: > > > > > (filter #(re-find #".clj$" %) … ) > > > > correction: > > > (filter #(re-find #"\.clj$" %) … ) --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: clj-backtrace uses: screenshots and example code
Phil, Indeed, clj-backtrace was largely inspired by Rubinius' "Awsome Backtrace" feature. I've implemented and pushed to GitHub an experimental implementation of colorized backtraces for the REPL: In addition to the usual (pst) to pretty-print the last exception, you can now (pst+) to colorized-pretty-print it. The current color scheme: (defn elem-color "Returns a symbol identifying the color appropriate for the given trace elem. :green All Java elems :magenta Any fn in the user or repl* namespaces (i.e. entered at REPL) :blueAny fn in clojure.* (e.g. clojure.core, clojure.contrib.*) :default Anything else - i.e. Clojure libraries and app code." [elem] (cond (:java elem) :green (or (nil? (:ns elem)) (re-match? #"^(user|repl)" (:ns elem))) :magenta (re-match? #"^clojure\." (:ns elem)) :blue :else :default)) On Thu, Jan 8, 2009 at 7:17 PM, Phil Hagelberg wrote: > > Mark McGranaghan writes: > >> I'd also be happy to answer any questions you have about using the >> library and to hear any general comments. > > This looks great! I love the way they're aligned. > > Have you looked at the way Rubinius (a smalltalk-style Ruby VM) prints > backtraces? It's pretty similar, although it goes one step further by > coloring different portions of the backtraces differently depending on > where they came from. See the example in the middle of this article: > > http://programblings.com/2008/04/15/rubinius-for-the-layman-part-2-how-rubinius-is-friendly/ > > I would love to see clojure.core code in one color, java-level code in > another, "unknown source" (repl-entered) code in another, and my > application's code in white. > > I'll definitely be using this; thanks. > > -Phil > > > > --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: (compile) also loads the lib ?
On Jan 8, 7:28 pm, lpetit wrote: > It seems that (compile) generates .class files as expected, and also > loads the lib in the environment as well. > > Is it a (apparently undocument) feature ? Or a bug ? It's a feature. I think it's documented somewhere. :) > And also, it seems that (compile) does not load the lib from the > compiled classes, but from the source files. "compile" calls "load" with some special variable bindings. So, yes, both will read the source files. > I guess that, because if the lib contains top level calls that do not > contribute to produce the classes (for example top level (println)s), > when I call (compile), those (println)s are executed. > > Later on, if I call (load) (from a fresh clojure environment) from the > compiled classes, the top level (println)s are not executed, since not > compiled. Yes, that's the expected behavior. "compile" only saves the things defined in the namespace. -Stuart Sierra --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: update in place for unique references
Hi Mark F, Thanks for your responses. > 1. Data: Is this really a problem that is slowing down Clojure > programs in practice? Can you provide some data to that effect? I > would suggest writing a couple of Java benchmarks - one that updates a > simple structure in place and one that only creates new data. Time > them. Write more benchmarks, but this time do it in Clojure (though > perhaps with some straight Java calls to make the updates). Are there > differences in the Java versions from the Clojure versions? Are there > differences in the update vs new data versions? Writing some test code is not a bad idea, but from what I heard Rich Hickey say in his online talks, probably unnecessary to establish that using Clojure built-in data structures involves a performance hit (in the single-thread case anyway). I got the impression that Clojure structures are somewhere in the range of 1.5 to 4 times worse than mutation based structures. Of course, this performance is quite an achievement, given the advantages of Clojure's approach. But for applications which are performance critical, I am wondering whether a uniqueness-based update-in-place would offer a complementary well performing alternative. > 2. Take a page from the Scheme playbook. Don't ask the language to > implement this feature, ask for the minimal set of tools that you need > to implement it. I would think a code walking escape analysis macro > could be very useful. Instead of run-time reference counting, the > macro could find data that is guaranteed not to escape its scope via a > closure (e.g. let bound locals that are not used in any (fn > [] ...)s ). What would you need access to? Additional JVM byte-code > instructions? Post-compile processing by user code? Update in place > methods for the normally immutable types? I don't know exactly what > you'd need, but ask for that before asking for a much bigger feature. The escape analysis macro sounds interesting. But an initial approach might be, for each of these new data structures (mutation based under the hood) to have two versions of each structure: * immutable (ie no more changes will ever occur - if you want a modification you will have to make a full copy); and * uniquely-referenced (arbitrary mutation changes effectively allowed, but only ever referred to uniquely (runtime enforced)). Most structures of this type would start life as a uniquely-referenced structure (either empty or a copy of an immutable), and have lots of mutations effectively applied to them in a safe environment, until they are ready to be "frozen" and released to the world as an immutable version of the structure. (Some structures would stay uniquely-referenced their whole life - used for performance in some single-threaded encapsulated mutation-based algorithm.) I should also clarify one point. I am not "asking for this language feature" so much as "asking whether people have thought about it". There may (or may not) be good reasons for not offering such a language feature. I'm just wondering if it has been considered. (And trying to get a feel for the strengths and weaknesses of Clojure - I am very new to it.) > 3. Remember that Clojure relies on the JVM for its allocation and GC. > Clojure is not issuing malloc and free calls. The JVM will not make it > easy to repurpose the storage of one object with a new object, without > going through a method. Maybe the way to handle this (at least initially) would be to only provide uniqueness interfaces to some of Java's main structures. Perhaps not as general as would be ideal, but would easily allow repurposing via a method. Thanks again for your input. Cheers, Mark P. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Clojure blog post about laziness
On Thu, Jan 8, 2009 at 5:55 AM, Rich Hickey wrote: > When you > ask for the nth element/rest, you get the identical item every time. I know this is nitpicking, but if this is really the promise that the seq abstraction is supposed to fulfill, then Clojure already violates this: (def a (seq [1 2 3])) (identical? (rest a) (rest a)) yields false Presumably what you mean is that the nth element should be identical (but not necessarily the nth rest). > The sequence abstraction in Clojure is the list abstraction of Lisp. > No more, no less. Well, in Lisp, lists are concrete, finite things that are mutable (and therefore don't provide any kind of guarantee that you'll get the same element with multiple traversals). So to say that Clojure's sequence abstraction is no more and no less than the list abstraction of Lisp is a bit misleading. You have a certain concept of what properties of this abstraction you want to model, and what promises you want to keep. And that's great -- honestly, I think it's fantastic that you have such a clear, coherent design vision that you've maintained throughout the creation of Clojure. I'm just saying that your interpretation of what constitutes an abstraction of a Lisp list is more subjective than your statement implies. I'm pretty sure my concept of the list abstraction differs from yours. In my mind the essential abstract concept of a list is anything that can be explained in this way: A list has a first and a rest, where first is some kind of element, and rest is another list or nil. In other words, I would say a sequence abstraction should apply to anything that has this sort of nested, self-referential recursive structure. There is an elegance to the way that algorithms on self-referential data structures can be expressed via recursion. To me, a big part of Clojure's beauty lies in the recognition that so many things can be converted to this view. Strictly speaking, a vector is not structured in this way, but you can convert it into something that has this property, allowing you to program vectors with this sort of recursive elegance. When I think about something like the sequence of whole numbers, it seems like a perfect embodiment of what I consider to be the essential abstraction of a sequence. You've got a first thing, and the rest thing is another sequence that has similarity to the original. Because it has a recursive structure, I want to be able to operate on it using first and rest. To me, a sequence feels like the "right abstraction" for the whole numbers, and writing algorithms that operate on them. And this feels like the right abstraction to me regardless of implementation details such as whether the traversed numbers should reside in memory all at once. > Making seqs 'non-caching' makes no sense because they are no longer > the same abstraction. I get that your design vision revolves around the idea that sequences promise identity, and that there are real technical challenges surrounding the idea of non-cached sequences. But I don't consider "non-caching sequences" to be an oxymoron. If it were possible to implement them in a way that meshed with the rest of Clojure's design, I think there would be real value to being able to manipulate non-cached recursive structures with the existing sequence interface. It's clear you don't think this fits with Clojure's design, but I haven't yet given up hope of finding a clever way to do this, and trying to convince you that it is worthwhile :) . I know that over email, it is all too common for the tone of a post to be misconstrued. So just in case, I want to emphasize here that these posts are in no way intended as bashing Clojure or Rich's design sensibilities. It is precisely because I admire the design, and already care about Clojure, that I raise these points in the hope that community discussion can elevate the language even further. I strive to make my comments as constructive in tone as possible, and I hope that they are perceived in that light. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: contrib/sql with postgresql, problem inserting into column of type date
I don't understand how to use it, can you post an example? I have tried everything and have gotten it to work under circumstances I'm not sure of. However it doesn't work now. (ns progs.netflix.parsing (:require (progs.netflix [pg :as pg])) (:import (java.sql Date))) (load-file "C:/clojure/user.clj") (defn str-to-date [string] (let [[y m d] (map #(Integer. %) (split string "-"))] (Date. (- y 1900) (dec m) d))) (defn parse-reviews [path] (let [string (slurp path) movieid (Integer. (str (reduce str (take-while #(not= % \:) string] (loop [[x & xs] (drop 1 (map #(split % ",") (split string "\n"))) acc []] (if (nil? x) acc (recur xs (conj acc [(first x) movieid (.replace (nth x 2) "\r" "") ;;(str-to-date (.replace (nth x 2) "\r" "")) (Integer. (second x))])) --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: Clojure blog post about laziness
Oh, I mentioned this in my blog post, but perhaps it bears repating. If cycle, repeat, and replicate were implemented behind-the-scenes with LazySeq as opposed to LazyCons, they would still implement the promise of identical elements for separate traversals, but would be more efficient. Also, range always returns a sequence of numbers which are inherently identical when equal, so that would be another one that makes sense as a LazySeq. There are probably a few more that could also guarantee identity and would benefit from a LazySeq implementation (take, takewhile, and butlast come to mind). Is there any downside to making at least those changes? --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: (compile) also loads the lib ?
On 9 jan, 04:03, Stuart Sierra wrote: > On Jan 8, 7:28 pm, lpetit wrote: > > > It seems that (compile) generates .class files as expected, and also > > loads the lib in the environment as well. > > > Is it a (apparently undocument) feature ? Or a bug ? > > It's a feature. I think it's documented somewhere. :) OK. I probably skipped it. OK. For the eclipse plugin eclipse-dev, I'm thinking about how to do implement the "build" functionality, and I was thinking of having a clojure environment always running for the purpose of the plugin (using this environment via swank-like remote calls, for asking it to help search doc, compile, ...). But if some people write scripts in libs, there's the risk that compiling the script as a lib starts the script, thus having unexpected undesirable effects (loading a Swing GUI, taking too much time, ...). I think that scripts shouldn't maybe be compiled at all, but doing things in an automated way, it will not be easy to "guess" that a file is a script and that the IDE should not try to compile it, will it ? > > Later on, if I call (load) (from a fresh clojure environment) from the > > compiled classes, the top level (println)s are not executed, since not > > compiled. > > Yes, that's the expected behavior. "compile" only saves the things > defined in the namespace. Well, I easily understand that it is the compiled behaviour. And in the same time, I don't feel it "right" that loading the same lib from source file or from compiled files can have different results. > > -Stuart Sierra --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: (compile) also loads the lib ?
On 9 jan, 07:54, lpetit wrote: > On 9 jan, 04:03, Stuart Sierra wrote: > > > Later on, if I call (load) (from a fresh clojure environment) from the > > > compiled classes, the top level (println)s are not executed, since not > > > compiled. > > > Yes, that's the expected behavior. "compile" only saves the things > > defined in the namespace. > > Well, I easily understand that it is the compiled behaviour. And in > the same time, I don't feel it "right" that loading the same lib from > source file or from compiled files can have different results. Because then, it's not correct to say that we can interchange a source version and a compiled version of a lib. So maybe it should be expressed that libs should not do anything but define things in the namespace (maybe it's also stated in the doc and I skipped it, if so, my apologies). -> And that could be a distinction between libs and plain namespaces. And in that case, do you think it could be interesting to mark the namespace with a "is-a-lib" meta-data to (for example) : - prevent the compiler to compile it by default (or emit a warning, or compile only if some :force flag is set) - allow automatic tools to explicitly see the difference between a lib and a PON (plain old namespace) Thanks in advance for your answers, -- Laurent --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: sort behavior question
On Thu, Jan 8, 2009 at 11:38 PM, Dmitri wrote: > > I think the main issue is that sort should behave consistently. > Possibly sort could check if the elements implement Comparable before > attempting to sort them? > I also don't see a reason as to why the lists > shouldn't implement Comparable. Comparable implies that an Object can be reduced to a scalar value, if only for the purpose of comparing. How do you imagine this should work on list of arbitrary things? -- Venlig hilsen / Kind regards, Christian Vest Hansen. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
Re: sort behavior question
On Thu, Jan 8, 2009 at 11:20 PM, Christian Vest Hansen wrote: > Comparable implies that an Object can be reduced to a scalar value, if > only for the purpose of comparing. How do you imagine this should work > on list of arbitrary things? Lexicographic ordering. Compare the first elements, if equal compare the rests. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
