Seq forms with preceding #^metadata lose the metadata
Hi,
Whenever a seq form is preceded by #^metadata, the metadata is ignored
or only {:line n} is associated with.
For example, these return the metadata as expected:
(meta (with-meta '(1) {:v 1}))
(meta (with-meta (quote (1)) {:v 1}))
(meta (with-meta (list 1) {:v 1}))
(meta (with-meta (vector 1) {:v 1}))
(meta (with-meta (hash-map :a 1) {:v 1}))
(meta (with-meta (set [1]) {:v 1}))
But none of these equivalents work and either nil or {:line n} is
returned:
(meta #^{:v 1} '(1))
(meta #^{:v 1} (quote (1)))
(meta #^{:v 1} (list 1))
(meta #^{:v 1} (vector 1))
(meta #^{:v 1} (hash-map :a 1))
(meta #^{:v 1} (set [1]))
However, these work (because what's following is a non-seq form):
(meta #^{:v 1} [1])
(meta #^{:v 1} {:a 1})
(meta #^{:v 1} #{1})
Looking at the Clojure source code, it looks like
LispReader.MetaReader does associate the metadata to the seq form but
it's ignored when the seq form is analyzed by Compiler.analyzeSeq.
Is this by design?
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Serializing Clojure objects
Tayssir John Gabbour wrote:
> Hi!
>
> How should I approach serialization? I made a little test function
> which serializes and deserializes Clojure objects. It works for
> strings, integers, symbols, LazilyPersistentVectors and.. oddly..
> PersistentHashMaps that have exactly one element. (My Clojure is about
> a month old.)
>
I am not much of a Java guy so this would be what I would do.
Clojure has reader syntax of its data structures (maps, vectors etc.)
so they can be easily written to a stream as test using write.
Reading it is equally simple:
user=> (def a (with-in-str "{:a 1 :b 2}" (read)))
#'user/a
user=> a
{:a 1, :b 2}
user=>
So as long as your data has reader syntax its not too much
of an issue. If the data needs to be shared between languages
as highlighted by someone, you may consider using another
format like json or so.
If the data used java object it may not be serializable so
easily. Generally my approach is to stick to data structures
at Clojure level as it has reader syntax.
Parth
> But for other things, like keywords and most PersistentHashMaps, it
> throws NotSerializableException.
>
> My imagined possible solutions:
>
> * Implement Serializable for Clojure data -- but is it possible in a
> dynamic "Hey I'll just write a new method!" way?
>
> * Go into Clojure's source and implement Serializable to the Java
> classes.
>
>
> My end goal is using a nonrelational DB like Tokyo Cabinet or
> BerkeleyDB.
>
> Thanks,
> Tayssir
>
>
> PS: Here's my test code:
>
> (defn my-identity "Copies obj through serialization and
> deserialization."
> [obj]
> (let [byte-out (new java.io.ByteArrayOutputStream)
> obj-out (new java.io.ObjectOutputStream byte-out)]
> (try (.writeObject obj-out obj)
> (finally (.close obj-out)))
> (let [obj-in (new java.io.ObjectInputStream
>(new java.io.ByteArrayInputStream (.toByteArray
> byte-out)))]
> (try (.readObject obj-in)
>(finally (.close obj-in))
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Serializing Clojure objects
Don't forget XMLEncoder/XMLDecoder. They come in pretty handy when you want to serialize objects that (already) follow bean conventions. -- KD Dakshinamurthy Karra (blog: http://blog.marathontesting.com) (daily dose: http://twitter.com/marathontesting) On Tue, Dec 2, 2008 at 4:06 PM, Tayssir John Gabbour <[EMAIL PROTECTED]> wrote: > > Interesting, thanks for the new perspective! Using YAML seems more > flexible than what I was thinking, particularly since Clojure > apparently doesn't make me worry too much about the specific kind of > sequence/map I'm using. > > (Yeah, I have an app which sends serialized objects all over the > place, and one thing I didn't like was how brittle my serialization > tool was when I made a little change to object definitions. (This is > in Common Lisp.) In my next release, I'd like to make it less strict.) > > > Tayssir > > > On Dec 2, 11:12 am, Luc Prefontaine <[EMAIL PROTECTED]> > wrote: >> I use YAML to serialize. I needed a simple way to pass Maps, Lists and >> Vector between java, Ruby and Clojure components. >> I change the classes of Clojure in the YAML output to java.util.Map, >> List and so on to remove dependencies >> on Clojure classes while retaining the ability to walk through the >> structures using these basic types in "foreign" >> components. In Java it's pretty obvious, Map, List and Vectors are >> always present and in Ruby these things are >> also part of the core language. >> >> Have a look athttp://jyaml.sourceforge.net/ >> >> Essentially it sums up to something like this: >> >> (def *YAML-config* (YamlConfig.)) >> (. *YAML-config* load yamlmsg) ;; Loads a YAML representation to an >> equivalent object representation >> (. *YAML-config* dump msg) ;; Dumps an object to a YAML string. >> >> I extended a bit the library to deal transparently with types like >> java.sql.Date (I deal with several databases) >> but nothing else was changed. Just beware of binary characters in your >> strings. I encoded these with XML/HTML escapes before serializing. >> I need to talk to the maintainer about this issue. >> >> Never liked Java serialization mainly because: >> >> a) The the binary representation of classes has to be exactly the same >> at both ends otherwise you are stuck in a dead end. >> >> b) You need that [EMAIL PROTECTED]@[EMAIL PROTECTED] Serializable interface >> which should be >> implemented by default everywhere by Java, not you. >> An embedded object misses the interface ? Well find it.. at run-time >> and good luck. >> >> c) It's not easy to debug since it's not human readable. >> >> d) It makes upgrading a distributed environment a pain in the ass since >> you may have upgrade everything even if no major >> changes occurred in your classes. You added a method irrelevant to >> most of the components in a class ? >> That single change forces you to upgrade everything... this is a >> typical example of developpers disconnected from real life. >> In real life your systems are running and you may not be able to >> interrupt services for a long period to upgrade them >> all at once. You may have to do so in multiple steps and without >> interrupting the service. >> >> e) I want the data serialized, not the access to it... >> >> If size of the YAML output becomes an issue then zip it. >> >> Luc >> >> On Tue, 2008-12-02 at 00:57 -0800, Tayssir John Gabbour wrote: >> > Hi! >> >> > How should I approach serialization? I made a little test function >> > which serializes and deserializes Clojure objects. It works for >> > strings, integers, symbols, LazilyPersistentVectors and.. oddly.. >> > PersistentHashMaps that have exactly one element. (My Clojure is about >> > a month old.) >> >> > But for other things, like keywords and most PersistentHashMaps, it >> > throws NotSerializableException. >> >> > My imagined possible solutions: >> >> > * Implement Serializable for Clojure data -- but is it possible in a >> > dynamic "Hey I'll just write a new method!" way? >> >> > * Go into Clojure's source and implement Serializable to the Java >> > classes. >> >> > My end goal is using a nonrelational DB like Tokyo Cabinet or >> > BerkeleyDB. >> >> > Thanks, >> > Tayssir >> >> > PS: Here's my test code: >> >> > (defn my-identity "Copies obj through serialization and >> > deserialization." >> > [obj] >> > (let [byte-out (new java.io.ByteArrayOutputStream) >> > obj-out (new java.io.ObjectOutputStream byte-out)] >> > (try (.writeObject obj-out obj) >> > (finally (.close obj-out))) >> > (let [obj-in (new java.io.ObjectInputStream >> >(new java.io.ByteArrayInputStream (.toByteArray >> > byte-out)))] >> > (try (.readObject obj-in) >> >(finally (.close obj-in)) >> >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroup
Re: DISCUSS: replace (rand)
nextDouble calls next, which according to Java 5 docs is:
synchronized protected int next(int bits) {
seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1);
return (int)(seed >>> (48 - bits));
}
This is exactly the kind of thing I think we shouldn't have to worry
about in Clojure.
Stuart
> Looks like the only synchronization is for lazy initialization of the
> instance of Random used by the static method:
>
> public final class Math {
>
>private static Random randomNumberGenerator;
>
>private static synchronized void initRNG() {
>if (randomNumberGenerator == null)
>randomNumberGenerator = new Random();
>}
>
>public static double random() {
>if (randomNumberGenerator == null) initRNG();
>return randomNumberGenerator.nextDouble();
>}
>
> }
>
> public class Random implements java.io.Serializable {
>public Random() { this(++seedUniquifier + System.nanoTime()); }
>private static volatile long seedUniquifier = 8682522807148012L;
>
>public double nextDouble() {
>long l = ((long)(next(26)) << 27) + next(27);
>return l / (double)(1L << 53);
>}
> }
>
> On Dec 2, 12:04 am, Stuart Halloway <[EMAIL PROTECTED]> wrote:
>> Clojure's rand delegates to Java's Math.random(), which I am pretty
>> sure has a synchronized block in it.
>>
>> One problem with living on top of Java is calling into methods that
>> have no (conceptual) need to be synchronized. This could hurt
>> performance in an app carefully written in Clojure to avoid mutable
>> state and locking. Since unsynchronized PRNGs exist, I would suggest
>> we modify rand to use one. (I am willing to take the lead on writing
>> one in Clojure if needed.)
>>
>> Thoughts?
>>
>> Stuart
> >
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: DISCUSS: replace (rand)
Even if you use a per-thread instance, you pay the synchronization
penalty. Because there is no contention, the penalty is lower, but it
is still not zero.
Is it big enough to matter? My intuition says "yes". That's worth
nothing, so I will write some tests when I have some spare time ...
but secretly I was hoping that this thread would goad someone else
into writing the tests and publishing their results. :-)
Stuart
> On Tue, Dec 2, 2008 at 3:05 PM, Stuart Halloway
> <[EMAIL PROTECTED]> wrote:
>>
>> nextDouble calls next, which according to Java 5 docs is:
>>
>> synchronized protected int next(int bits) {
>> seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1);
>> return (int)(seed >>> (48 - bits));
>> }
>>
>> This is exactly the kind of thing I think we shouldn't have to worry
>> about in Clojure.
>
> The docs for Math.random() say:
>
> ; When this method is first called, it creates a single
> ; new pseudorandom-number generator, exactly as if by
> ; the expression
> ;
> ;new java.util.Random
> ;
> ; This new pseudorandom-number generator is used
> ; thereafter for all calls to this method and is used
> ; nowhere else.
> ;
> ; This method is properly synchronized to allow correct
> ; use by more than one thread. However, if many threads
> ; need to generate pseudorandom numbers at a great rate,
> ; it may reduce contention for each thread to have its
> ; own pseudorandom-number generator.
>
> So can't you just create multiple instances of java.util.Random if you
> need that sort of thing?
>
> --
> Michael Wood <[EMAIL PROTECTED]>
>
> >
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: DISCUSS: replace (rand)
Ah, I didn't see the call to next. The java docs do say that is the
implementation for that method, but they are lying:
protected int next(int bits) {
long oldseed, nextseed;
AtomicLong seed = this.seed;
do {
oldseed = seed.get();
nextseed = (oldseed * multiplier + addend) & mask;
} while (!seed.compareAndSet(oldseed, nextseed));
return (int)(nextseed >>> (48 - bits));
}
On Dec 2, 8:05 am, Stuart Halloway <[EMAIL PROTECTED]> wrote:
> nextDouble calls next, which according to Java 5 docs is:
>
> synchronized protected int next(int bits) {
> seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1);
> return (int)(seed >>> (48 - bits));
> }
>
> This is exactly the kind of thing I think we shouldn't have to worry
> about in Clojure.
>
> Stuart
>
> > Looks like the only synchronization is for lazy initialization of the
> > instance of Random used by the static method:
>
> > public final class Math {
>
> > private static Random randomNumberGenerator;
>
> > private static synchronized void initRNG() {
> > if (randomNumberGenerator == null)
> > randomNumberGenerator = new Random();
> > }
>
> > public static double random() {
> > if (randomNumberGenerator == null) initRNG();
> > return randomNumberGenerator.nextDouble();
> > }
>
> > }
>
> > public class Random implements java.io.Serializable {
> > public Random() { this(++seedUniquifier + System.nanoTime()); }
> > private static volatile long seedUniquifier = 8682522807148012L;
>
> > public double nextDouble() {
> > long l = ((long)(next(26)) << 27) + next(27);
> > return l / (double)(1L << 53);
> > }
> > }
>
> > On Dec 2, 12:04 am, Stuart Halloway <[EMAIL PROTECTED]> wrote:
> >> Clojure's rand delegates to Java's Math.random(), which I am pretty
> >> sure has a synchronized block in it.
>
> >> One problem with living on top of Java is calling into methods that
> >> have no (conceptual) need to be synchronized. This could hurt
> >> performance in an app carefully written in Clojure to avoid mutable
> >> state and locking. Since unsynchronized PRNGs exist, I would suggest
> >> we modify rand to use one. (I am willing to take the lead on writing
> >> one in Clojure if needed.)
>
> >> Thoughts?
>
> >> Stuart
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Java libraries
On Mon, Dec 1, 2008 at 8:16 PM, Chouser <[EMAIL PROTECTED]> wrote: > > On Mon, Dec 1, 2008 at 1:01 PM, puzzler <[EMAIL PROTECTED]> wrote: >> >> Clojure is designed for concurrency, but I don't see any functions in >> the API to spin off new threads. > > See 'send' and 'send-off'. send-off in particular will start a new > thread if there are not idle threads available in its pool. If that > abstracts away details you'd rather have your hand on, you may find > this tutorial useful: > > http://java.sun.com/docs/books/tutorial/essential/concurrency/executors.html > >> So I assume you're expected to know >> and use Java libraries for this. For those of us who are coming to >> Clojure without knowing a whole lot of Java, it would be useful if >> someone could provide pointers to the most essential libraries, >> especially a tour of the concurrency primitives that work well with >> Clojure's approach. > > Here are some classes I've heard mentioned or have used myself with Clojure: > http://java.sun.com/javase/6/docs/api/java/util/concurrent/BlockingQueue.html > http://java.sun.com/javase/6/docs/api/java/util/concurrent/atomic/package-summary.html > >> As for other libraries, I've already located the documentation for the >> String class at http://java.sun.com/javase/6/docs/api/java/lang/String.html. >> It would also be helpful to know which File I/O libraries are most >> relevant, and a couple short examples of how to use them. Any other >> critical libraries? > > http://java.sun.com/docs/books/tutorial/essential/io/ See also the Apache Commons libraries as mentioned in these threads: http://groups.google.com/group/clojure/browse_thread/thread/986e8b246f296bd2/92df3cacd6111f71 http://groups.google.com/group/clojure/browse_thread/thread/979fe987ef046110/de59307741e39ba6 -- Michael Wood <[EMAIL PROTECTED]> --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Serializing Clojure objects
On Dec 2, 9:57 am, Tayssir John Gabbour <[EMAIL PROTECTED]> wrote: > (defn my-identity "Copies obj through serialization and > deserialization." > [obj] > (let [byte-out (new java.io.ByteArrayOutputStream) > obj-out (new java.io.ObjectOutputStream byte-out)] > (try (.writeObject obj-out obj) > (finally (.close obj-out))) > (let [obj-in (new java.io.ObjectInputStream >(new java.io.ByteArrayInputStream (.toByteArray > byte-out)))] > (try (.readObject obj-in) >(finally (.close obj-in)) BTW, sorry for the absurd code; I should .close() byte-out instead of obj-out. And I'll have to figure out how to readably close a stream in a finally clause. Tayssir --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Vim tag file generator
On Monday 01 December 2008 23:32, Meikel Brandmeyer wrote: > Hi, > > On 2 Dez., 00:49, Randall R Schulz <[EMAIL PROTECTED]> wrote: > > Trying to make me look bad, eh? Well, it's not really a challenge, > > you know... > > o.O Do I? You do now... > ... > > Concerning the filename issue, one maybe can do > a heuristic: > > - Filename is identical to the last component of the > namespace: > => some/name/space.clj > > - Filename is different form the last component of the > namespace. Try the following: > * some/name/file.clj exists? => Use it. > * some/name/space/file.clj exists? => Use it > * recursing here into some/name/space/*? > > I think the first two cases should cover most of the > cases. I would pefer to exchange the first two checks, > since I think, the "normal" layout would be, that there > is some subdirectory containing "include" files. Clojure > itself on the other hand has a flat structure... Hmmm... Don't forget the fact that hyphens in namespace symbols are transliterated to underscores in the corresponding file name when you (use ...) or (require ...) or otherwise refer to a namespace in a manner that requires a file to be located. > > ... > > > And don't forget that the tags file must be sorted in simple > > lexicographic order, which does not seem to be what you get if you > > just dump symbol names into a sorted set or map. (So far, I've just > > been sorting the files afterward from the command line using the > > Gnu "sort" utility with the environment variable LC_ALL set to > > "C".) > > Hmmm... At least for vim this seems to be not necessary. However > you are right. In the specification of the format it is stated, that > the entries must be sorted. I missed that. Check it out. The names enclosed in *asterisks* will sort improperly, e.g. In version 6 Vim, an unsorted (or improperly sorted) tags file will yield an error, at least for some symbols (binary search might never encounter a subsequence deemed out-of-order if the file is mostly sorted). Apparently in later versions of Vim, a fall-back linear search is used when the file is deemed unsorted. That could become a performance (responsiveness) issue for large unsorted tags files. > I already noticed some issues with Windows and Namespaces > containing -, eg. clojure.contrib.duck-streams. Will post an update > later on, today. > > Sincerely > Meikel 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Code Analysis Tools
On Dec 2, 12:54 pm, Peter Wolf <[EMAIL PROTECTED]> wrote: > Since the code doesn't exist yet, I'd have to say no... Like I said, > I'm just getting started. > > How about I get the basic framework going so that IntelliJ knows about > CLJ files, and say paren matching works. Then we can start a > SourceForge project and others can implement the API for references, > refactoring, formatting etc. > Just found this http://code.google.com/p/clojure-intellij-plugin/ - I guess that's another one? Might be worth looking into working on that rather than starting up a competitor. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: DISCUSS: replace (rand)
Cool, that's much better. Can we establish that all (or all important)
Java 5+ VMs use AtomicLong in next?
> Ah, I didn't see the call to next. The java docs do say that is the
> implementation for that method, but they are lying:
>
>protected int next(int bits) {
>long oldseed, nextseed;
>AtomicLong seed = this.seed;
>do {
> oldseed = seed.get();
> nextseed = (oldseed * multiplier + addend) & mask;
>} while (!seed.compareAndSet(oldseed, nextseed));
>return (int)(nextseed >>> (48 - bits));
>}
>
> On Dec 2, 8:05 am, Stuart Halloway <[EMAIL PROTECTED]> wrote:
>> nextDouble calls next, which according to Java 5 docs is:
>>
>> synchronized protected int next(int bits) {
>> seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1);
>> return (int)(seed >>> (48 - bits));
>> }
>>
>> This is exactly the kind of thing I think we shouldn't have to worry
>> about in Clojure.
>>
>> Stuart
>>
>>> Looks like the only synchronization is for lazy initialization of
>>> the
>>> instance of Random used by the static method:
>>
>>> public final class Math {
>>
>>>private static Random randomNumberGenerator;
>>
>>>private static synchronized void initRNG() {
>>>if (randomNumberGenerator == null)
>>>randomNumberGenerator = new Random();
>>>}
>>
>>>public static double random() {
>>>if (randomNumberGenerator == null) initRNG();
>>>return randomNumberGenerator.nextDouble();
>>>}
>>
>>> }
>>
>>> public class Random implements java.io.Serializable {
>>>public Random() { this(++seedUniquifier + System.nanoTime()); }
>>>private static volatile long seedUniquifier = 8682522807148012L;
>>
>>>public double nextDouble() {
>>>long l = ((long)(next(26)) << 27) + next(27);
>>>return l / (double)(1L << 53);
>>>}
>>> }
>>
>>> On Dec 2, 12:04 am, Stuart Halloway <[EMAIL PROTECTED]>
>>> wrote:
Clojure's rand delegates to Java's Math.random(), which I am pretty
sure has a synchronized block in it.
>>
One problem with living on top of Java is calling into methods that
have no (conceptual) need to be synchronized. This could hurt
performance in an app carefully written in Clojure to avoid mutable
state and locking. Since unsynchronized PRNGs exist, I would
suggest
we modify rand to use one. (I am willing to take the lead on
writing
one in Clojure if needed.)
>>
Thoughts?
>>
Stuart
> >
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Lazy living, without variables
On Dec 1, 9:35 pm, Timothy Pratley <[EMAIL PROTECTED]> wrote: > > The reason is simple - plain mutable variables have no concurrency > > semantics. What if you closed over a mutable local? Now you have an > > object with no synchronization, a concurrency mess. > > Thanks Rich for the clarification... that makes it immediately obvious > why using mutable locals is a bad idea in general. > > Just to play the devil's advocate, it is theoretically possible to > detect someone attempting to close over a mutable local as a compiler > error. But given that such a feature would just allow/encourage > imperative style, it would be an evil feature. It really comes down to > a question of enforcing style I believe? :) > Well, if there were mutable locals people would reasonably expect to be able to close over them. Where they are available in Lisps, it's an idiom e.g. to map a local fn that mutates a local var, when that is easier/cleaner than a loop. But yes, obviously I've made decisions about what kinds of programs I want Clojure to encourage :) Mutation locally is just as hard to reason about as mutation globally, independent of concurrency. See for example a typical Java for loop that sets other local vars and contains breaks/returns. If it takes more thought initially to construct solutions that don't need variables, please try to expend the effort - it will repay you many times over. I imagine there are now some Clojure users who can attest to that. This whole thread has gotten so icky, and has lost focus on the beauty and lesson of Stuart's original example. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Lazy living, without variables
The "@" symbol is a reader macro. It's a hard coded table so that when the reader comes across the @ symbol it knows to instead change it to a deref call. For eg, (def a (ref 0)) (dosync (alter inc a)) @a ;; is the same thing as (deref a) http://clojure.org/reader#toc2 or http://clojure.org/api#toc178 Luke Amdor On Dec 2, 3:03 am, David Powell <[EMAIL PROTECTED]> wrote: > Hi, > > On the subject of with-local-vars, I noticed that I could use @ to > deference them in addition to var-get. Is that intended behaviour? I > didn't see it documented anywhere. > > -- > Dave --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Lazy living, without variables
On Dec 2, 8:43 am, Luke Amdor <[EMAIL PROTECTED]> wrote: > The "@" symbol is a reader macro. It's a hard coded table so that when > the reader comes across the @ symbol it knows to instead change it to > a deref call. For eg, > > (def a (ref 0)) > > (dosync (alter inc a)) > > @a ;; is the same thing as > (deref a) > Right, but the deref doc didn't mention vars, now it does. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Test Coerced-BigDecimal in clojure.contrib.test-clojure throws an Exception
On Nov 18, 5:35 pm, "Stephen C. Gilardi" <[EMAIL PROTECTED]> wrote: > I think Clojure should change to allow (bigdec 3) to succeed. > BigDecimal has a valueOf method that accepts a long. It has a > constructor that accepts an int. I haven't made a bug report on this > yet, but here it is. > SVN 1135 enhances bigdec/bigint to support all numeric types and all single-arg ctors, including from String. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Code Analysis Tools
Thanks, I strongly agree. I just emailed curious.attempt.bunny to join forces. Curious, are you out there? P [EMAIL PROTECTED] wrote: > On Dec 2, 12:54 pm, Peter Wolf <[EMAIL PROTECTED]> wrote: > >> Since the code doesn't exist yet, I'd have to say no... Like I said, >> I'm just getting started. >> >> How about I get the basic framework going so that IntelliJ knows about >> CLJ files, and say paren matching works. Then we can start a >> SourceForge project and others can implement the API for references, >> refactoring, formatting etc. >> >> > Just found this http://code.google.com/p/clojure-intellij-plugin/ - I > guess that's another one? Might be worth looking into working on that > rather than starting up a competitor. > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Lazy living, without variables
Hi, On the subject of with-local-vars, I noticed that I could use @ to deference them in addition to var-get. Is that intended behaviour? I didn't see it documented anywhere. -- Dave --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Code Analysis Tools
On Tuesday 02 December 2008 06:16, [EMAIL PROTECTED] wrote: > ... > > Just found this http://code.google.com/p/clojure-intellij-plugin/ - I > guess that's another one? Might be worth looking into working on that > rather than starting up a competitor. I retrieved the code. It is at best a skeleton. There appears to be virtually no implementation at all beyond the identification of the language supported and the file suffixes used. I believe "failure to launch" would characterize that project... 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
symbol-macrolet (was: Monads in Clojure)
On 25.11.2008, at 15:06, Konrad Hinsen wrote: > I just saw a reference to symbol-macrolet with a description. My > function replace-syms is indeed very similar, the difference being > that it takes a map for defining the substitutions to be done, > instead of a let-like sequence. The difference is not just in syntax > though, as expressions in symbol-macrolet can refer to earlier > "bindings" (they aren't really bindings) whereas my replace-syms > doesn't check for substitutions to be made inside other > substitutions. But it would be fairly easy to implement symbol- > macrolet on top of my replace-syms. After having read more on macrolet and symbol-macrolet, I no longer agree with my earlier self ;-) symbol-macrolet does not do a simple substitution, it creates a binding-like environment from which replacements are done repeatedly as other macros are expanded. I haven't yet found a complete description of how macros and symbol-macrolet work together. A macro can expand into code that contains a symbol defined in symbol- macrolet, and the expansion of such a symbol can produce code containing macros. I'd expect everything to be expanded repeatedly until the form no longer changes, but I haven't see this being stated explicitly anywhere. In any case, implementing macrolet and symbol-macrolet is probably not a trivial project. I see basically two approaches: 1) Full repeated expansion of the form, which is then handed to the compiler. 2) Implementation as an extension to the compiler's macro handling scheme. When I started working on my monad implementation, I was in fact looking for something much like macrolet, and if I had pursued that approach I would have wanted symbol-macrolet just a bit later. Both would be nice to have. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Seq forms with preceding #^metadata lose the metadata
Hi,
On 2 Dez., 10:30, Kei Suzuki <[EMAIL PROTECTED]> wrote:
> (meta #^{:v 1} (vector 1))
>
> Is this by design?
I think you are right. The metadata is assigned to
the list (vector 1). Then the function vector is executed
and you get the vector [1], but the metadata is "lost".
So one could argue, the metadata should be transferred.
However, how do you want to do this consistently?
Consider (meta #^{:v 1} (fn [] 1)). The metadata is
assigned to the list (fn ...). But why should it transfer
the metadata to the return value of the function? And
indeed this is not possible, because it's a number.
Should vector, set and friends behave differently?
I think the point about *reader* macros is, that they
happen at *read* time. However, the call to vector
happens at run-time. So in that case one has to
use with-meta.
One really has to be aware of the different times
when things happen:
- reader macros => read time
- macros => compile time
- functions => run-time
Sincerely
Meikel
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Seq forms with preceding #^metadata lose the metadata
On Dec 2, 4:30 am, Kei Suzuki <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Whenever a seq form is preceded by #^metadata, the metadata is ignored
> or only {:line n} is associated with.
>
> For example, these return the metadata as expected:
>
> (meta (with-meta '(1) {:v 1}))
> (meta (with-meta (quote (1)) {:v 1}))
> (meta (with-meta (list 1) {:v 1}))
> (meta (with-meta (vector 1) {:v 1}))
> (meta (with-meta (hash-map :a 1) {:v 1}))
> (meta (with-meta (set [1]) {:v 1}))
>
> But none of these equivalents work and either nil or {:line n} is
> returned:
>
> (meta #^{:v 1} '(1))
> (meta #^{:v 1} (quote (1)))
> (meta #^{:v 1} (list 1))
> (meta #^{:v 1} (vector 1))
> (meta #^{:v 1} (hash-map :a 1))
> (meta #^{:v 1} (set [1]))
>
> However, these work (because what's following is a non-seq form):
>
> (meta #^{:v 1} [1])
> (meta #^{:v 1} {:a 1})
> (meta #^{:v 1} #{1})
>
> Looking at the Clojure source code, it looks like
> LispReader.MetaReader does associate the metadata to the seq form but
> it's ignored when the seq form is analyzed by Compiler.analyzeSeq.
>
> Is this by design?
First and most important:
#^ is not sugar for with-meta. It does not expand into a call to with-
meta. They are not equivalent.
#^ is a way to place metadata on the data objects read by the reader.
Once read by the reader, the compiler can utilize metadata on the
forms. Currently the primary use is to convey type hints. Macros can
interpret metadata on forms they are passed for various purposes. This
is all about code-as-data, not a runtime thing.
Since a list is interpreted by the compiler as a call, any metadata on
the list is searched for type hints. There is no other meaning for
metadata on a list as far as the compiler is concerned. Ditto metadata
on symbols.
Since vector and map literals are interpreted by the compiler as
evaluated data, it evaluates any metadata on the literal to become
metadata on the value:
(set! *print-meta* true)
(quote #^{:a (+ 1 2)} [1 2 (+ 3 4)])
=> #^{:a #^{:line 17} (+ 1 2)} [1 2 #^{:line 17} (+ 3 4)] ;what was
read, vector + meta
#^{:a (+ 1 2)} [1 2 (+ 3 4)]
=> #^{:a 3} [1 2 7] ;evaluated vector + meta
Metadata on a seq form is not ignored:
(set! *print-meta* false)
(set! *warn-on-reflection* true)
(def x "foo")
(.length (identity x))
=> Reflection warning, line: 26 - reference to field length can't be
resolved.
=> 3
=> (.length #^String (identity x))
=> 3
So #^ allows the reader to read data with metadata on it.
Interpretation of forms that have metadata is up to the compiler.
Bottom line:
#^ is not sugar for with-meta. It does not expand into a call to with-
meta.
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Clojure Code Analysis Tools
We are working on a Netbeans plugin (.enclojure.org) and are currently working to isolate non-nb specific clojure-ide support code. We should have the basic libraries up this coming Monday. The code that is up there now has been following the changes in Clojure since February and is less than organized and clean. Even if we do not have the libraries fully integrated into the Netbeans plugin, we'll still have some stuff ready to look at Monday. We have been focusing on the REPL: Several instances running at once/starting/stopping Connecting to a REPL server running in a Clojure app. and some better code analysis tools, (lexer, namespace browser for Clojure symbols). We've done minimal work on completion as well. I just started reading about the IntelliJ plugin architecture to ensure we can reuse the Clojure specific stuff over there as wellsince I'm very interested in having a IntelliJ plugin :) Eric On Dec 2, 2008, at 9:31 AM, Peter Wolf wrote: > > Thanks, I strongly agree. > > I just emailed curious.attempt.bunny to join forces. Curious, are you > out there? > > P > > > > [EMAIL PROTECTED] wrote: >> On Dec 2, 12:54 pm, Peter Wolf <[EMAIL PROTECTED]> wrote: >> >>> Since the code doesn't exist yet, I'd have to say no... Like I >>> said, >>> I'm just getting started. >>> >>> How about I get the basic framework going so that IntelliJ knows >>> about >>> CLJ files, and say paren matching works. Then we can start a >>> SourceForge project and others can implement the API for references, >>> refactoring, formatting etc. >>> >>> >> Just found this http://code.google.com/p/clojure-intellij-plugin/ - I >> guess that's another one? Might be worth looking into working on that >> rather than starting up a competitor. >>> >> >> > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Proxy questions
Hi I'm trying to use Clojure with Apache MINA. I think Clojure it's the ideal language to concurrently handle all the events that arrive into MINA's separate threads. So I tried to port the simplest example, the EchoServer (files here: http://svn.apache.org/viewvc/mina/branches/1.0/example/src/main/java/org/apache/mina/example/echoserver/EchoProtocolHandler.java?view=log and here: http://svn.apache.org/viewvc/mina/branches/1.0/example/src/main/java/org/apache/mina/example/echoserver/Main.java?view=log) This is what I wrote: (import '(org.apache.mina.common ByteBuffer IdleStatus IoHandler IoHandlerAdapter IoSession)) (import '(org.apache.mina.transport.socket.nio SocketAcceptor SocketAcceptorConfig)) (import '(org.apache.mina.filter LoggingFilter)) (import '(java.net InetSocketAddress)) (def echo-handler (proxy [IoHandlerAdapter] [] (sessionCreated [sess] (println (format "Session created: %s" sess))) (sessionIdle [sess status] (println (format "Session idle: %s" sess))) (messageReceived [sess message] (println (format "Received message: %s" message))) ) ) (def acceptor (SocketAcceptor.)) (def config (SocketAcceptorConfig.)) (.. config getFilterChain (addLast "log" (LoggingFilter.))) (. acceptor bind (InetSocketAddress. 1234) echo-handler config) (println "Listening in port 1234") The server starts, but when I connect to it, it doesn't print anything, so I'm guessing that I wrote the proxy wrong. It's supposed to simply be a class that extends IoHandlerAdapter and overwrites the sessionCreated, sessionIdle and messageReceived methods any ideas? thanks --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: undefined symbols (CL vs. Clojure)
On Dec 2, 2:39 am, Meikel Brandmeyer <[EMAIL PROTECTED]> wrote: > Hi, > > On 2 Dez., 04:47, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > > So why is the above form not legal in Clojure? I would think it might > > come in handy to define a function that relies on something currently > > not-yet-defined. Why is this the appropriate behavior? > > As other stated you should use declare to tell Clojure about Vars > you will use before they are def'd with a meaningful value. > > As for the > reasons:http://groups.google.com/group/clojure/browse_thread/thread/c34188752... > > Sincerely > Meikel Meikel, thanks for the response. I actually did read that thread in the past but forgot about it. So much to remember these days. I don't fully understand Rich's explanation yet, but I'm sure that's because of my inexperience with Lisp. Stuart, I have been using your PCL solutions as a way to check my answers! My CD database wasn't quite as elegant as yours, but I think I did a good job for my limited Lisp/Clojure experience. I also bought your book "Programming Clojure". Thanks for all your hard work! It's really helping me understand Clojure better. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: AOT/gen-class docs
I've made substantial enhancements to gen-class over the weekend.
Please refresh and read:
http://clojure.org/compilation
In short, I've made it so that you can call gen-class stand-alone.
This will generate a stub class at AOT compile time.
The relationship between a generated class and its implementing
namespace is now parameterized, as is whether or not the implementing
ns gets loaded by the class, and the prefix used by the method->var
mapping.
You can still use :gen-class in a ns directive, and many parameters
will be defaulted. (:gen-class) by itself will give you a class with
the same name as the ns, a main function, and "-" as the prefix. Note
that now, without any (:gen-class) in ns, you will _not_ get a stub
class generated.
This brings tremendous flexibility - you can define macros that expand
into gen-class calls, and both declare and implement multiple classes
in a single file.
I've also added gen-interface, based on a contribution from Chouser,
which works similarly at AOT compile time.
I've enhanced proxy so that it, too, will pre-generate the proxy
classes at AOT compile time, although doing so is not necessary in
order to use proxy. The interface of the proxy API is unchanged. Two
advantages come from this:
Proxies now have deterministic names, and so their construction can
be a direct constructor call, rather than reflective, as it was
previously.
Proxy generation was the last runtime code-gen/classloader
requirement. So the path is clear for building Clojure apps without
runtime codegen, for delivery in those environments that preclude it
(e.g. Android, unsigned applets). Looking forward to feedback from
people trying to reach those targets.
Rich
On Nov 27, 10:32 am, Rich Hickey <[EMAIL PROTECTED]> wrote:
> On Nov 26, 11:06 pm, Chas Emerick <[EMAIL PROTECTED]> wrote:
>
>
>
> > Looks good so far, Rich. Should be a blissfully smooth transition
> > from the "legacy" gen-class impl.
>
> > This is only tangentially related to the docs you're writing, but I
> > won't let that stop me:
>
> > As you know, I have at least one use case where being able to generate
> > gen-class specs from a macro (or, the full ns declaration, in the
> > absence of an evaluated gen-class spec). Going one step further than
> > that though, I'm wondering how best to approach contexts where one
> > would like to generate classes whose names don't match up with the
> > name of the current file (or with the package the generated class will
> > land from the current file). Right off the top of my head, easily and
> > cleanly generating BeanInfo classes based on attributes/methods/
> > interfaces/whatever of the current file's class would be super-handy.
>
> > This doesn't look possible right now -- adding a second, different ns
> > declaration does not generate the corresponding classfiles. The docs
> > you've written so far make it sound like this should work -- "The unit
> > of compilation is the namespace" -- but right now, it seems like files
> > are the unit of compilation. Just as an example, assume the following
> > is in com/foo/test.clj:
>
> > (ns com.foo.test
> > (:gen-class
> > :implements [java.util.Iterator]
> > :init ctor
> > :constructors {[String] []}
> > :state state))
>
> > (ns com.foo.test2
> > (:gen-class
> > :implements [java.util.Iterator]
> > :init ctor
> > :constructors {[String] []}
> > :state state))
> > -
>
> > (compile 'com.foo.test) yields the com.foo.test classfiles one would
> > expect. However, (compile 'com.foo.test2) throws an exception, as
> > it's looking for a com/foo/test2.clj file (rather than using whatever
> > has already been defined in the com.foo.test2 namespace). I see why
> > that's the case, as compilation and loading are very tightly bound.
> > If that's going to remain the case, then I'd say that clj files are
> > the unit of compilation, not namespaces. It's not yet clear (to me,
> > anyway) whether the current state is an intermediate stable step, or
> > if the first cut on the docs are slightly off on this point.
>
> > - Chas
>
> The unit of compilation will probably be called the 'lib', but that
> isn't defined anywhere on the site yet. As far as 2 or more ns calls
> in the same file, that violates the ns/file classpath requirements,
> which say that my.ns.lib must be defined in my/ns/lib.clj. I'll make
> the requirement that ns be the first expression in any file that
> contains it explicit.
>
> That doesn't make the unit of compilation the file though, as a
> namespace can be defined in more than one file.
>
> All that notwithstanding, I understand your needs and those of the few
> others who have chimed in that were using gen-and-save-class, and I
> hope to facilitate most of them soon.
>
> One thing I have been considering is the possibility to opt-out of
> generating a class when compiling (ns ...) via something like (ns
> (:gen-class :external true) ...), which would state that the cl
Re: DISCUSS: replace (rand)
2008/12/2 Stuart Halloway <[EMAIL PROTECTED]>: > > Cool, that's much better. Can we establish that all (or all important) > Java 5+ VMs use AtomicLong in next? While compare-and-swap is a lot better than a mutex, it's still not free. IIRC a CAS is one (or maybe two) order(s) of magnitude more expensive than a normal store. So a non-threadsafe PRNG should still give you a performance boost compared to the CAS-version. But, as you said, this is all speculation until someone writes some tests... -- ! Lauri --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Serializing Clojure objects
Hi! How should I approach serialization? I made a little test function which serializes and deserializes Clojure objects. It works for strings, integers, symbols, LazilyPersistentVectors and.. oddly.. PersistentHashMaps that have exactly one element. (My Clojure is about a month old.) But for other things, like keywords and most PersistentHashMaps, it throws NotSerializableException. My imagined possible solutions: * Implement Serializable for Clojure data -- but is it possible in a dynamic "Hey I'll just write a new method!" way? * Go into Clojure's source and implement Serializable to the Java classes. My end goal is using a nonrelational DB like Tokyo Cabinet or BerkeleyDB. Thanks, Tayssir PS: Here's my test code: (defn my-identity "Copies obj through serialization and deserialization." [obj] (let [byte-out (new java.io.ByteArrayOutputStream) obj-out (new java.io.ObjectOutputStream byte-out)] (try (.writeObject obj-out obj) (finally (.close obj-out))) (let [obj-in (new java.io.ObjectInputStream (new java.io.ByteArrayInputStream (.toByteArray byte-out)))] (try (.readObject obj-in) (finally (.close obj-in)) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: DISCUSS: replace (rand)
I wanted to ask what algorithm Java is using for calculating its random numbers (having a choice of algorithms would be great - some applications favor one above the other), but I found a website digging into exactly this question: http://www.math.utah.edu/~beebe/java/random/README "I therefore had to resort to peeking inside the source, found on Sun Solaris 9 in /usr/j2se/src.zip, member java/util/Random.java. It uses a 48-bit linear congruential generator recommended by Donald Knuth (a good sign), but returns only a 32-bit subset of the computed bits. The default seed is the current time-of-day, returned by System.currentTimeMillis()." I'll compare it later on to the one ruby is using (Mersenne Twister Algorithm, which is excellent for monte carlo-like simulations), just to get my own bearings. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Serializing Clojure objects
Interesting, thanks for the new perspective! Using YAML seems more flexible than what I was thinking, particularly since Clojure apparently doesn't make me worry too much about the specific kind of sequence/map I'm using. (Yeah, I have an app which sends serialized objects all over the place, and one thing I didn't like was how brittle my serialization tool was when I made a little change to object definitions. (This is in Common Lisp.) In my next release, I'd like to make it less strict.) Tayssir On Dec 2, 11:12 am, Luc Prefontaine <[EMAIL PROTECTED]> wrote: > I use YAML to serialize. I needed a simple way to pass Maps, Lists and > Vector between java, Ruby and Clojure components. > I change the classes of Clojure in the YAML output to java.util.Map, > List and so on to remove dependencies > on Clojure classes while retaining the ability to walk through the > structures using these basic types in "foreign" > components. In Java it's pretty obvious, Map, List and Vectors are > always present and in Ruby these things are > also part of the core language. > > Have a look athttp://jyaml.sourceforge.net/ > > Essentially it sums up to something like this: > > (def *YAML-config* (YamlConfig.)) > (. *YAML-config* load yamlmsg) ;; Loads a YAML representation to an > equivalent object representation > (. *YAML-config* dump msg) ;; Dumps an object to a YAML string. > > I extended a bit the library to deal transparently with types like > java.sql.Date (I deal with several databases) > but nothing else was changed. Just beware of binary characters in your > strings. I encoded these with XML/HTML escapes before serializing. > I need to talk to the maintainer about this issue. > > Never liked Java serialization mainly because: > > a) The the binary representation of classes has to be exactly the same > at both ends otherwise you are stuck in a dead end. > > b) You need that [EMAIL PROTECTED]@[EMAIL PROTECTED] Serializable interface > which should be > implemented by default everywhere by Java, not you. > An embedded object misses the interface ? Well find it.. at run-time > and good luck. > > c) It's not easy to debug since it's not human readable. > > d) It makes upgrading a distributed environment a pain in the ass since > you may have upgrade everything even if no major > changes occurred in your classes. You added a method irrelevant to > most of the components in a class ? > That single change forces you to upgrade everything... this is a > typical example of developpers disconnected from real life. > In real life your systems are running and you may not be able to > interrupt services for a long period to upgrade them > all at once. You may have to do so in multiple steps and without > interrupting the service. > > e) I want the data serialized, not the access to it... > > If size of the YAML output becomes an issue then zip it. > > Luc > > On Tue, 2008-12-02 at 00:57 -0800, Tayssir John Gabbour wrote: > > Hi! > > > How should I approach serialization? I made a little test function > > which serializes and deserializes Clojure objects. It works for > > strings, integers, symbols, LazilyPersistentVectors and.. oddly.. > > PersistentHashMaps that have exactly one element. (My Clojure is about > > a month old.) > > > But for other things, like keywords and most PersistentHashMaps, it > > throws NotSerializableException. > > > My imagined possible solutions: > > > * Implement Serializable for Clojure data -- but is it possible in a > > dynamic "Hey I'll just write a new method!" way? > > > * Go into Clojure's source and implement Serializable to the Java > > classes. > > > My end goal is using a nonrelational DB like Tokyo Cabinet or > > BerkeleyDB. > > > Thanks, > > Tayssir > > > PS: Here's my test code: > > > (defn my-identity "Copies obj through serialization and > > deserialization." > > [obj] > > (let [byte-out (new java.io.ByteArrayOutputStream) > > obj-out (new java.io.ObjectOutputStream byte-out)] > > (try (.writeObject obj-out obj) > > (finally (.close obj-out))) > > (let [obj-in (new java.io.ObjectInputStream > >(new java.io.ByteArrayInputStream (.toByteArray > > byte-out)))] > > (try (.readObject obj-in) > >(finally (.close obj-in)) > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: DISCUSS: replace (rand)
On Tue, Dec 2, 2008 at 3:05 PM, Stuart Halloway
<[EMAIL PROTECTED]> wrote:
>
> nextDouble calls next, which according to Java 5 docs is:
>
> synchronized protected int next(int bits) {
>seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1);
>return (int)(seed >>> (48 - bits));
> }
>
> This is exactly the kind of thing I think we shouldn't have to worry
> about in Clojure.
The docs for Math.random() say:
; When this method is first called, it creates a single
; new pseudorandom-number generator, exactly as if by
; the expression
;
;new java.util.Random
;
; This new pseudorandom-number generator is used
; thereafter for all calls to this method and is used
; nowhere else.
;
; This method is properly synchronized to allow correct
; use by more than one thread. However, if many threads
; need to generate pseudorandom numbers at a great rate,
; it may reduce contention for each thread to have its
; own pseudorandom-number generator.
So can't you just create multiple instances of java.util.Random if you
need that sort of thing?
--
Michael Wood <[EMAIL PROTECTED]>
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: DISCUSS: replace (rand)
Since this is just pure java, shouldn't it be the same on all 1.5
JVMs? Would it be different on other JVM implementations? Just to
verify, I checked on my Mac OS X 10.5 and in the Sun JDK 1.5 on
Windows XP, and it does appear to be the same.
On Dec 2, 9:17 am, Stuart Halloway <[EMAIL PROTECTED]> wrote:
> Cool, that's much better. Can we establish that all (or all important)
> Java 5+ VMs use AtomicLong in next?
>
> > Ah, I didn't see the call to next. The java docs do say that is the
> > implementation for that method, but they are lying:
>
> > protected int next(int bits) {
> > long oldseed, nextseed;
> > AtomicLong seed = this.seed;
> > do {
> > oldseed = seed.get();
> > nextseed = (oldseed * multiplier + addend) & mask;
> > } while (!seed.compareAndSet(oldseed, nextseed));
> > return (int)(nextseed >>> (48 - bits));
> > }
>
> > On Dec 2, 8:05 am, Stuart Halloway <[EMAIL PROTECTED]> wrote:
> >> nextDouble calls next, which according to Java 5 docs is:
>
> >> synchronized protected int next(int bits) {
> >> seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1);
> >> return (int)(seed >>> (48 - bits));
> >> }
>
> >> This is exactly the kind of thing I think we shouldn't have to worry
> >> about in Clojure.
>
> >> Stuart
>
> >>> Looks like the only synchronization is for lazy initialization of
> >>> the
> >>> instance of Random used by the static method:
>
> >>> public final class Math {
>
> >>> private static Random randomNumberGenerator;
>
> >>> private static synchronized void initRNG() {
> >>> if (randomNumberGenerator == null)
> >>> randomNumberGenerator = new Random();
> >>> }
>
> >>> public static double random() {
> >>> if (randomNumberGenerator == null) initRNG();
> >>> return randomNumberGenerator.nextDouble();
> >>> }
>
> >>> }
>
> >>> public class Random implements java.io.Serializable {
> >>> public Random() { this(++seedUniquifier + System.nanoTime()); }
> >>> private static volatile long seedUniquifier = 8682522807148012L;
>
> >>> public double nextDouble() {
> >>> long l = ((long)(next(26)) << 27) + next(27);
> >>> return l / (double)(1L << 53);
> >>> }
> >>> }
>
> >>> On Dec 2, 12:04 am, Stuart Halloway <[EMAIL PROTECTED]>
> >>> wrote:
> Clojure's rand delegates to Java's Math.random(), which I am pretty
> sure has a synchronized block in it.
>
> One problem with living on top of Java is calling into methods that
> have no (conceptual) need to be synchronized. This could hurt
> performance in an app carefully written in Clojure to avoid mutable
> state and locking. Since unsynchronized PRNGs exist, I would
> suggest
> we modify rand to use one. (I am willing to take the lead on
> writing
> one in Clojure if needed.)
>
> Thoughts?
>
> Stuart
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Clojure Code Analysis Tools
Since the code doesn't exist yet, I'd have to say no... Like I said, I'm just getting started. How about I get the basic framework going so that IntelliJ knows about CLJ files, and say paren matching works. Then we can start a SourceForge project and others can implement the API for references, refactoring, formatting etc. [EMAIL PROTECTED] wrote: > On Dec 1, 4:11 pm, Peter Wolf <[EMAIL PROTECTED]> wrote: > >> Since I plan to introduce Clojure into existing large Java projects, I want >> to use a decent IDE. So I am writing a Clojure plugin for my favorite-- >> IntelliJ. When I'm done I hope to offer a nice integrated environment >> complete with debugger, profiler and automatic refactoring. >> >> However, this will take me a while as I am new to writing IntelliJ plugins. >> All help welcome. >> >> Peter >> > > Hurry up! That would be awesome. Is the plugin code publicly available > anywhere? > > -Darren > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Code Analysis Tools
On Dec 1, 4:11 pm, Peter Wolf <[EMAIL PROTECTED]> wrote: > > Since I plan to introduce Clojure into existing large Java projects, I want > to use a decent IDE. So I am writing a Clojure plugin for my favorite-- > IntelliJ. When I'm done I hope to offer a nice integrated environment > complete with debugger, profiler and automatic refactoring. > > However, this will take me a while as I am new to writing IntelliJ plugins. > All help welcome. > > Peter Hurry up! That would be awesome. Is the plugin code publicly available anywhere? -Darren --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Serializing Clojure objects
I use YAML to serialize. I needed a simple way to pass Maps, Lists and Vector between java, Ruby and Clojure components. I change the classes of Clojure in the YAML output to java.util.Map, List and so on to remove dependencies on Clojure classes while retaining the ability to walk through the structures using these basic types in "foreign" components. In Java it's pretty obvious, Map, List and Vectors are always present and in Ruby these things are also part of the core language. Have a look at http://jyaml.sourceforge.net/ Essentially it sums up to something like this: (def *YAML-config* (YamlConfig.)) (. *YAML-config* load yamlmsg) ;; Loads a YAML representation to an equivalent object representation (. *YAML-config* dump msg) ;; Dumps an object to a YAML string. I extended a bit the library to deal transparently with types like java.sql.Date (I deal with several databases) but nothing else was changed. Just beware of binary characters in your strings. I encoded these with XML/HTML escapes before serializing. I need to talk to the maintainer about this issue. Never liked Java serialization mainly because: a) The the binary representation of classes has to be exactly the same at both ends otherwise you are stuck in a dead end. b) You need that [EMAIL PROTECTED]@[EMAIL PROTECTED] Serializable interface which should be implemented by default everywhere by Java, not you. An embedded object misses the interface ? Well find it.. at run-time and good luck. c) It's not easy to debug since it's not human readable. d) It makes upgrading a distributed environment a pain in the ass since you may have upgrade everything even if no major changes occurred in your classes. You added a method irrelevant to most of the components in a class ? That single change forces you to upgrade everything... this is a typical example of developpers disconnected from real life. In real life your systems are running and you may not be able to interrupt services for a long period to upgrade them all at once. You may have to do so in multiple steps and without interrupting the service. e) I want the data serialized, not the access to it... If size of the YAML output becomes an issue then zip it. Luc On Tue, 2008-12-02 at 00:57 -0800, Tayssir John Gabbour wrote: > Hi! > > How should I approach serialization? I made a little test function > which serializes and deserializes Clojure objects. It works for > strings, integers, symbols, LazilyPersistentVectors and.. oddly.. > PersistentHashMaps that have exactly one element. (My Clojure is about > a month old.) > > But for other things, like keywords and most PersistentHashMaps, it > throws NotSerializableException. > > My imagined possible solutions: > > * Implement Serializable for Clojure data -- but is it possible in a > dynamic "Hey I'll just write a new method!" way? > > * Go into Clojure's source and implement Serializable to the Java > classes. > > > My end goal is using a nonrelational DB like Tokyo Cabinet or > BerkeleyDB. > > Thanks, > Tayssir > > > PS: Here's my test code: > > (defn my-identity "Copies obj through serialization and > deserialization." > [obj] > (let [byte-out (new java.io.ByteArrayOutputStream) > obj-out (new java.io.ObjectOutputStream byte-out)] > (try (.writeObject obj-out obj) > (finally (.close obj-out))) > (let [obj-in (new java.io.ObjectInputStream >(new java.io.ByteArrayInputStream (.toByteArray > byte-out)))] > (try (.readObject obj-in) >(finally (.close obj-in)) > > > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Accept RE Pattern in (find-doc ...)?
Hi, I was thinking it would be nice if (find-doc ...) accepted a Pattern (in addition to the String it now accepts), thus allowing #"RE pattern" regular expression pattern literals. What do Rich and others think? 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: proposal: match multimethod
On Dec 1, 5:07 pm, Stuart Halloway <[EMAIL PROTECTED]> wrote:
> I am thinking about adding a match method to Clojure-contrib. This
> would work like Ruby's threequals ("===", a.k.a. case equality) and
> would be implemented as a multimethod to do sensible things with a
> wide variety of types.
>
> (1) Good idea?
>
> (2) What should it be named?
>
For those of us that don't do Ruby - what does === do?
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Serializing Clojure objects
JBossSerialization looks nifty, though I haven't tried it yet: http://www.jboss.org/serialization/ Thanks to everyone who responded! (I've just been immersing myself in Externalizable, object versioning, etc; and your thoughts have been helpful.) All best, Tayssir On Dec 2, 9:57 am, Tayssir John Gabbour <[EMAIL PROTECTED]> wrote: > Hi! > > How should I approach serialization? I made a little test function > which serializes and deserializes Clojure objects. It works for > strings, integers, symbols, LazilyPersistentVectors and.. oddly.. > PersistentHashMaps that have exactly one element. (My Clojure is about > a month old.) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: DISCUSS: replace (rand)
--- On Tue, 12/2/08, Paul Barry wrote: > Since this is just pure java, shouldn't it be the same on all 1.5 > JVMs? Would it be different on other JVM implementations? Just > to verify, I checked on my Mac OS X 10.5 and in the Sun JDK > 1.5 on Windows XP, and it does appear to be the same. A Sun v. Sun comparison? What about JDK/JVM implementations from different vendors? Dave --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: randomize a collection?
Seems like shuffle should be part of the core or in the contrib. Is there a reason why it's not? On Mon, Dec 1, 2008 at 9:55 PM, Timothy Pratley <[EMAIL PROTECTED]>wrote: > > > http://groups.google.com/group/clojure/browse_thread/thread/180842eb58c58370/0e19ab338452c64f?lnk=gst&q=shuffle#0e19ab338452c64f > The recommendation was to use java.util.Collections/shuffle and an > example was given: > > (defn shuffle [coll] > (let [l (java.util.ArrayList. coll)] >(java.util.Collections/shuffle l) >(seq l))) > > user=> (shuffle [1 2 3 4 5]) > (4 2 1 5 3) > > On Dec 2, 3:28 pm, "Brian Doyle" <[EMAIL PROTECTED]> wrote: > > Is there a function that takes a collection and randomizes, or shuffles, > the > > items? > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Code Analysis Tools
I just pulled the code down. While it's true that there is no implementation, Curious Bunny (merlyn) did an excellent job of making a minimal custom language plugin. This is something that is lacking in IntelliJ's own documentation. By making a trivial change to Curious's code I was able to change the icon for CLJ files. So I know it is working. I vote that we take Merlyn's code as a base and put it on SourceForge. I'll add my Lexer and Parser and work on formatting, parens matching and coloring. Erik can add his REPL and completion stuff. However, I think it would be polite to wait 24 hours for Merlyn to give his/her OK before I do this. Randall R Schulz wrote: > On Tuesday 02 December 2008 06:16, [EMAIL PROTECTED] wrote: > >> ... >> >> Just found this http://code.google.com/p/clojure-intellij-plugin/ - I >> guess that's another one? Might be worth looking into working on that >> rather than starting up a competitor. >> > > I retrieved the code. It is at best a skeleton. There appears to be > virtually no implementation at all beyond the identification of the > language supported and the file suffixes used. > > I believe "failure to launch" would characterize that project... > > > 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Code Analysis Tools
On Tuesday 02 December 2008 08:52, Peter Wolf wrote: > ... > > I vote that we take Merlyn's code as a base and put it on > SourceForge. I'll add my Lexer and Parser and work on formatting, > parens matching and coloring. Erik can add his REPL and completion > stuff. > > However, I think it would be polite to wait 24 hours for Merlyn to > give his/her OK before I do this. Polite, certainly. But as ever, the bottom line is the license under which it was released, and in this case that's the Apache License 2.0. You should decide whether that's consistent with your intentions. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Serializing Clojure objects
I've been working on the same issue. So far it has mostly been just researching various options, but I can give you my two cents... It really depends on your goals and constraints. I have narrowed down to two major families of serialization for storage and networking. One is the JSON/YAML/XML style, where you generate a serialized version of data structures primarily based on vectors and hashes that contain only simple data types. (Note, JSON is a subset of YAML, so you can parse JSON with YAML but not vice versa.) This is by far the fastest to develop and the most light weight in terms of programmer time. Basically one line each for read/write. The potential hidden cost depends on what data structures you use in your program. If you have clearly defined chunks of data to serialize, YAML works nicely, but for more complex structures you often have to do an intermediate conversion to simpler data structures where you deal by hand with things like circular references and pointers to ephemeral data that you don't want serialized. The previous options are however, inefficient for storage, transmission and parsing in comparison to a more strictly defined protocol. If you need raw performance and you are willing to spend the effort defining your protocol, then I think something like the Google protocol buffers or Facebook thrift are good options. They are basically the new-school versions of CORBA RPC. In essence, you define a schema for your messages or data serialization units, and then some tools generate classes or functions that are used to read/write and transmit this data. (SOAP pretty much works the same way, but it idiotically sits on XML too, so you get the worst of both worlds...) Again, if your data units to be serialized are self contained this can work pretty smoothly, but in more complex structures you will also have to convert between the simple, generated classes and your more complex application classes. The real work though, is in creating and maintaining your protocol definitions and the code that uses the generated classes. I think the default for a language like clojure should be YAML too. For dynamic languages where developer time is the focus it is by far the quickest mechanism to get up and running using databases, configuration files, networking, etc. Maybe we should look into integrating the built-in Clojure data-types with a YAML library, or otherwise creating a new one, so we can dump and load directly between serialized strings and Clojure data structures. If you run up against the limits of YAML, then I would go protocol buffers. They seem like a clean and efficient way to support multi-language communication without wasting time writing a bunch of custom serialization methods. It would be interesting if there was a way to sort of generate .proto files by example, by sniffing YAML on the wire or something... It could at least help bootstrap the protocol definition phase. Hopefully that helps. -Jeff Tayssir John Gabbour wrote: > Hi! > > How should I approach serialization? I made a little test function > which serializes and deserializes Clojure objects. It works for > strings, integers, symbols, LazilyPersistentVectors and.. oddly.. > PersistentHashMaps that have exactly one element. (My Clojure is about > a month old.) > > But for other things, like keywords and most PersistentHashMaps, it > throws NotSerializableException. > > My imagined possible solutions: > > * Implement Serializable for Clojure data -- but is it possible in a > dynamic "Hey I'll just write a new method!" way? > > * Go into Clojure's source and implement Serializable to the Java > classes. > > > My end goal is using a nonrelational DB like Tokyo Cabinet or > BerkeleyDB. > > Thanks, > Tayssir > > > PS: Here's my test code: > > (defn my-identity "Copies obj through serialization and > deserialization." > [obj] > (let [byte-out (new java.io.ByteArrayOutputStream) > obj-out (new java.io.ObjectOutputStream byte-out)] > (try (.writeObject obj-out obj) > (finally (.close obj-out))) > (let [obj-in (new java.io.ObjectInputStream >(new java.io.ByteArrayInputStream (.toByteArray > byte-out)))] > (try (.readObject obj-in) >(finally (.close obj-in)) > > > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: AOT/gen-class docs
On Tue, Dec 2, 2008 at 10:24 AM, Rich Hickey <[EMAIL PROTECTED]> wrote: > > Proxy generation was the last runtime code-gen/classloader > requirement. So the path is clear for building Clojure apps without > runtime codegen, for delivery in those environments that preclude it > (e.g. Android, unsigned applets). Looking forward to feedback from > people trying to reach those targets. You asked for it. :-) Here's a minimal applet .clj: (ns net.n01se.Tree (:gen-class :extends java.applet.Applet)) Since it's missing a main fn, I would expect an exception like the this: java.lang.UnsupportedOperationException: net.n01se.Tree/-main not defined (NO_SOURCE_FILE:0) Using svn 1136 I can compile and get the above exception from a normal Clojure REPL, but if I try to use it as an applet: $ appletviewer test.html java.lang.ExceptionInInitializerError at clojure.lang.Namespace.(Namespace.java:31) at clojure.lang.Namespace.findOrCreate(Namespace.java:116) at clojure.lang.Var.internPrivate(Var.java:95) at net.n01se.Tree.(Unknown Source) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at java.lang.Class.newInstance0(Class.java:372) at java.lang.Class.newInstance(Class.java:325) at sun.applet.AppletPanel.createApplet(AppletPanel.java:798) at sun.applet.AppletPanel.runLoader(AppletPanel.java:727) at sun.applet.AppletPanel.run(AppletPanel.java:380) at java.lang.Thread.run(Thread.java:636) Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission createClassLoader) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:342) at java.security.AccessController.checkPermission(AccessController.java:553) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:611) at java.lang.ClassLoader.(ClassLoader.java:218) at java.security.SecureClassLoader.(SecureClassLoader.java:71) at java.net.URLClassLoader.(URLClassLoader.java:99) at clojure.lang.DynamicClassLoader.(DynamicClassLoader.java:30) at clojure.lang.RT.(RT.java:243) ... 14 more You can see it found my class okay, but it looks like there may be some dynamic classloader stuff still going on? --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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: proposal: match multimethod
It is called "case equality" which is a terribly confusing way to say
"the predicate used to match in case statements". "Match" is really
the best verb. In Ruby, most things match by value equality. But
classes match their instances. Ranges match things in the range.
Regexps match strings that they would match against.
I find the construct useful, but difficult to define. In particular,
if regular expressions match against matching strings, should
collections match against their members? Subsets?
The use case I have in mind for Clojure is in unit tests, where one
might say something like
(each-matches
[actual-value expected-value]+)
and have the match operator applied.
Stuart
> On Dec 1, 5:07 pm, Stuart Halloway <[EMAIL PROTECTED]> wrote:
>> I am thinking about adding a match method to Clojure-contrib. This
>> would work like Ruby's threequals ("===", a.k.a. case equality) and
>> would be implemented as a multimethod to do sensible things with a
>> wide variety of types.
>>
>> (1) Good idea?
>>
>> (2) What should it be named?
>>
>
> For those of us that don't do Ruby - what does === do?
>
> 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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Accept RE Pattern in (find-doc ...)?
On Tue, Dec 2, 2008 at 11:03 AM, Randall R Schulz <[EMAIL PROTECTED]> wrote: > > I was thinking it would be nice if (find-doc ...) accepted a Pattern (in > addition to the String it now accepts), thus allowing #"RE pattern" > regular expression pattern literals. +1 "in addition to the String" is important --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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Accept RE Pattern in (find-doc ...)?
On Tuesday 02 December 2008 09:24, Chouser wrote: > On Tue, Dec 2, 2008 at 11:03 AM, Randall R Schulz <[EMAIL PROTECTED]> wrote: > > I was thinking it would be nice if (find-doc ...) accepted a > > Pattern (in addition to the String it now accepts), thus allowing > > #"RE pattern" regular expression pattern literals. > > +1 > > "in addition to the String" is important (ns rrs.docs) (defn doc-find "Like find-doc but also accepts a java.util.regex.Pattern" [pat] (find-doc (.toString pat))) Woo-Hoo! RRS --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure Code Analysis Tools
> Polite, certainly. But as ever, the bottom line is the license under > which it was released, and in this case that's the Apache License 2.0. > You should decide whether that's consistent with your intentions. It's worth noting that JetBrains has a history of including third- party plugins as part of the core IntelliJ IDEA distribution, if the authors are amenable and the plugin is of quality and felt to be generally useful to the IDEA community. I've had a few of mine included that way, and consider it quite an honor. In those cases, the plugin gets relicensed as Apache 2.0.I don't know if that's something you might be interested in eventually, but it's something to think about. It's early days for Clojure, but who knows what the future might bring. Dave Griffith --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
More Monads
A couple of weeks ago, I took a crack at figuring out monads by implementing them in Clojure. Inspired by Konrad's work, I pulled that out and completed it. I had chosen to implement a monad as a hash-map which is then passed in to the standard monadic operations as an additional parameter. Lifting 'with-monad' and 'domonad' from Konrad's file, I implemented versions using that idea. One thing I saw is that 'replace-syms' could be simplified. I rewrote it as: (defn- replace-syms [sym-map expr] (cond (seq? expr) (map #(replace-syms sym-map %) expr) (coll? expr) (into (empty expr) (map #(replace-syms sym-map %) expr)) :else (get sym-map expr expr))) And then I changed it further to accommodate my needs. I also changed 'monad-expr' to be a single call to 'reduce'. There's a quick explanation of monads at the beginning of the file. Thanks to Konrad for posting some good code. File is at: http://groups.google.com/group/clojure/web/monad-redux.clj Jim --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
clojure.main default print function
With the adoption of the clojure.main at SVN r1127, the print behavior
of the REPL changed from prn-style to println-style, e.g.
;r1126
user=> (list "hey" 'hey)
("hey" hey)
;r1127 & on
user=> (list "hey" 'hey)
(hey hey)
I missed it when looking over Stephen's clojure.main code when
proposed, but I think the prior behavior is pretty clearly preferable.
Others?
(To make the change, the docstring on line 73 & the default function
on line 85 would both be changed from println to prn.)
Perry
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: More Monads
Hi, Am 02.12.2008 um 18:49 schrieb jim: A couple of weeks ago, I took a crack at figuring out monads by implementing them in Clojure. Inspired by Konrad's work, I pulled that out and completed it. Seems, that we have some inflation here. :) I also re-activated my try from spring, which I use for my Parsec clone. It uses multimethods to handle the definitions of the monadic functions like bind or return. http://www.bitbucket.org/kotarak/monad However, since I'm a complete newbie to monads, half of it is probably wrong and half of it doesn't work.. Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: delimited continuations for web development
Rich Hickey <[EMAIL PROTECTED]> writes: > On Jun 20, 11:58 am, Jaime Barciela <[EMAIL PROTECTED]> wrote: >> Hello Phil, >> >> My understanding is that Common Lisp doesn't have support for >> continuations either and that's why Weblocks uses cl-cont (http:// >> common-lisp.net/project/cl-cont/, a library by the same author) to >> "fake" them >> >> The implication appears to be that you don't need compiler support for >> them if you have macros (which are, in a way, compiler extensions) >> >> I know the Java world has tried and the Resources section here is a >> good summary:http://www-128.ibm.com/developerworks/java/library/j-cb03216 >> >> The search continues :) >> >> Thanks >> Jaime >> >> On Jun 20, 11:30 am, Phil Jordan <[EMAIL PROTECTED]> wrote: >> >> > Jaime Barciela wrote: >> > > Is there anybody writing or thinking about writing a continuations >> > > +component-based web framework for Clojure? Although I don't think I >> > > can carve time to start such a project myself I would be happy to >> > > contribute to one if it exists. >> >> > Clojure doesn't have support for continuations, and as far as I've seen, >> > nobody has tried anything like it. I have no idea how hard it would be >> > to implement them, as I'm insufficiently familiar with the JVM's guts. >> >> > However, there appear to be some continuation and coroutine libraries >> > for Java out there. I've never looked into these, so I don't know if >> > they've got any limitiations that limit the usefulness for this kind of >> > purpose, but if they work in Java, they should work with Clojure. Google >> > returns plenty of results to start digging, although at first glance it >> > worries me that these libraries seem to be written for Java 1.0, which, >> > I think, didn't yet support native threads and still used Green threads. >> > (effectively a way of implementing coroutines) >> > I know they are all the rage, but I am skeptical of the trend towards > continuation-based web apps, especially to the degree in which they > hold state in language-based continuations. > > First, it encourages writing apps like the old 70's style terminal > apps - present a menu, wait for a choice, goto the next screen etc - > very imperative. Yes, it's easy, and so was that. Then there were > event-driven interfaces, and the world moved on. > > Second, why ever would I want a client's state tied up in something as > opaque as a language continuation? > > Third, there are bound to be things captured in a continuation whose > viability is extremely time or context dependent - prices, > availability etc. To the extent you need to care about what is ok from > the captured stack and what you need to refresh on resumption, > continuations are insufficient. > > Fourth, the continuations freeze the application logic - what if the > business rules or workflow have changed since the continuation was > captured? Continuations reflect a view of applications as static. > > That's not to say that these frameworks aren't trying to address real > challenges. Some of the challenges have to do with state-transition/ > workflow management. Some have to do with breaking the 1:1 > relationship between connections and threads, and process re- > activation. There are some cool Comet capabilities in the Java servlet > containers that address the latter (some even call themselves > continuations, but are in reality event-driven). > > The short of it is that Clojure is not going to provide continuations > any time soon, and I encourage Clojure web framework developers to > think outside the box rather than chase this trend. Rich, I'm responding to an old thread, as I've just discovered Clojure, and I've just been thinking about how to start using it. I also work with Weblocks (and like it a lot). Your comments are spot-on if applied to one particular approach to continuation-based web development. That approach is popular with Schemers, as Scheme supports first-class continuations as part of the language. There have been many presentations and demos by schemers where each HTTP request basically calls a continuation with the entire application state. This is not what Weblocks does. Weblocks does something quite different. The continuations we're talking about are delimited and do not serve the purpose of freezing the application logic. Also, the sequential/imperative flow you mention isn't their main purpose. The main goal is to support actions, e.g. code like this: (defmethod render-widget-body :before ((w news-story) &rest args) [...] (when (display-mode-toggling-enabled w) (ecase (display-mode-of w) (:short (link "[+]" (toggle-display-mode w))) (:full (link "[-]" (toggle-display-mode w) The link macro actually renders a HTML link pointing to the captured continuation -- an action, which in this case just toggles how the widget is displayed. Notice we aren't actually freezing anything and this is not a full first-class continuation, it do
Re: Serializing Clojure objects
On Dec 2, 7:02 am, Parth Malwankar <[EMAIL PROTECTED]> wrote:
> Tayssir John Gabbour wrote:
> > Hi!
>
> > How should I approach serialization? I made a little test function
> > which serializes and deserializes Clojure objects. It works for
> > strings, integers, symbols, LazilyPersistentVectors and.. oddly..
> > PersistentHashMaps that have exactly one element. (My Clojure is about
> > a month old.)
>
> I am not much of a Java guy so this would be what I would do.
> Clojure has reader syntax of its data structures (maps, vectors etc.)
> so they can be easily written to a stream as test using write.
>
> Reading it is equally simple:
>
> user=> (def a (with-in-str "{:a 1 :b 2}" (read)))
> #'user/a
> user=> a
> {:a 1, :b 2}
> user=>
>
> So as long as your data has reader syntax its not too much
> of an issue. If the data needs to be shared between languages
> as highlighted by someone, you may consider using another
> format like json or so.
>
> If the data used java object it may not be serializable so
> easily. Generally my approach is to stick to data structures
> at Clojure level as it has reader syntax.
>
Yes, please consider print/read. It is readable text, works with a lot
of data structures, and is extensible.
As part of AOT I needed to enhance print/read to store constants of
many kinds, and restore faithfully. This led to a new multimethod -
print-dup, for high-fidelity printing. You can get print-dup behavior
by binding *print-dup*:
(binding [*print-dup* true]
(dorun
(map prn
[[1 2 3]
{4 5 6 7}
(java.util.ArrayList. [8 9])
String
"string"
42M
:hello
#"ethel"
(sorted-set 9 8 7 6)
#'rest])))
[1 2 3]
{4 5, 6 7}
#=(java.util.ArrayList. [8 9])
#=java.lang.String
"string"
42M
:hello
#"ethel"
#=(clojure.lang.PersistentTreeSet/create [6 7 8 9])
#=(var clojure.core/rest)
It can handle all of the Clojure data structures (including sorted
variants), Java collections, classes etc.
You can extend it to new types by defining the print-dup method for
the type.
Rich
>
> > But for other things, like keywords and most PersistentHashMaps, it
> > throws NotSerializableException.
>
> > My imagined possible solutions:
>
> > * Implement Serializable for Clojure data -- but is it possible in a
> > dynamic "Hey I'll just write a new method!" way?
>
> > * Go into Clojure's source and implement Serializable to the Java
> > classes.
>
> > My end goal is using a nonrelational DB like Tokyo Cabinet or
> > BerkeleyDB.
>
> > Thanks,
> > Tayssir
>
> > PS: Here's my test code:
>
> > (defn my-identity "Copies obj through serialization and
> > deserialization."
> > [obj]
> > (let [byte-out (new java.io.ByteArrayOutputStream)
> > obj-out (new java.io.ObjectOutputStream byte-out)]
> > (try (.writeObject obj-out obj)
> > (finally (.close obj-out)))
> > (let [obj-in (new java.io.ObjectInputStream
> >(new java.io.ByteArrayInputStream (.toByteArray
> > byte-out)))]
> > (try (.readObject obj-in)
> >(finally (.close obj-in))
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: AOT/gen-class docs
On Dec 2, 12:12 pm, Chouser <[EMAIL PROTECTED]> wrote: > On Tue, Dec 2, 2008 at 10:24 AM, Rich Hickey <[EMAIL PROTECTED]> wrote: > > > Proxy generation was the last runtime code-gen/classloader > > requirement. So the path is clear for building Clojure apps without > > runtime codegen, for delivery in those environments that preclude it > > (e.g. Android, unsigned applets). Looking forward to feedback from > > people trying to reach those targets. > > You asked for it. :-) > > Here's a minimal applet .clj: > > (ns net.n01se.Tree > (:gen-class >:extends java.applet.Applet)) > > Since it's missing a main fn, I would expect an exception like the this: > java.lang.UnsupportedOperationException: net.n01se.Tree/-main not > defined (NO_SOURCE_FILE:0) When and why? The mappings are dynamic, you'll get an error if you try to call it, and you could define that later somehow. > > Using svn 1136 I can compile and get the above exception from a normal > Clojure REPL, but if I try to use it as an applet: > > $ appletviewer test.html > java.lang.ExceptionInInitializerError > at clojure.lang.Namespace.(Namespace.java:31) > at clojure.lang.Namespace.findOrCreate(Namespace.java:116) > at clojure.lang.Var.internPrivate(Var.java:95) > at net.n01se.Tree.(Unknown Source) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:532) > at java.lang.Class.newInstance0(Class.java:372) > at java.lang.Class.newInstance(Class.java:325) > at sun.applet.AppletPanel.createApplet(AppletPanel.java:798) > at sun.applet.AppletPanel.runLoader(AppletPanel.java:727) > at sun.applet.AppletPanel.run(AppletPanel.java:380) > at java.lang.Thread.run(Thread.java:636) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission createClassLoader) > You can see it found my class okay, but it looks like there may be > some dynamic classloader stuff still going on? > Thanks, that's useful. Yes, the dynamic loader is still there, just won't be used, but it looks like the security check is on creation. Getting it completely out is another project... 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Accept RE Pattern in (find-doc ...)?
On Dec 2, 10:03 am, Randall R Schulz <[EMAIL PROTECTED]> wrote: > Hi, > > I was thinking it would be nice if (find-doc ...) accepted a Pattern (in > addition to the String it now accepts), thus allowing #"RE pattern" > regular expression pattern literals. > > What do Rich and others think? > > Randall Schulz +1. I think it's a nice addition. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: proposal: match multimethod
On Dec 2, 12:16 pm, Stuart Halloway <[EMAIL PROTECTED]> wrote: > It is called "case equality" which is a terribly confusing way to say > "the predicate used to match in case statements". "Match" is really > the best verb. In Ruby, most things match by value equality. But > classes match their instances. Ranges match things in the range. > Regexps match strings that they would match against. > > I find the construct useful, but difficult to define. In particular, > if regular expressions match against matching strings, should > collections match against their members? Subsets? > > The use case I have in mind for Clojure is in unit tests, where one > might say something like > > (each-matches > [actual-value expected-value]+) > > and have the match operator applied. > I'm pretty sure I don't like the sound of that at all. We had a nice discussion about fcase/condf, which I'd like to get in, here: http://groups.google.com/group/clojure/browse_frm/thread/dee910bef6296035/d1858b3b0233183e I think a predicate match system is much nicer than a fuzzy-value match. Also, I think people will want a true structural match macro at some point (yesterday). 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: quit
On Sun, Nov 30, 2008 at 3:05 PM, Mon Key <[EMAIL PROTECTED]> wrote: > > Maybe (quit-clojure) instead of (quit)? This would save vanilla `quit' > just in case it's needed later/elsewhere. > Might also be nice to have (exit-clojure). Ditto saving vanilla `exit' > for other purposes > > When first configuring Clojure on both linux box and windows from the > command line (e.g. pre-slime, sans Jline ); the (quit) form was one of > the first things I evaluated at the REPL :P > When I first started (quit) and (exit) are the first two things I've tried for getting out of the Repl. Having either of those work for terminating the REPL would be great. Using exit-clojure or quit-clojure instead will continue to require the user the look up how to terminate the REPL somewhere, at which point they might as well read about C-d. For example, here's what happens when someone new to Python tries to exit the interactive console. >>> quit Use quit() or Ctrl-D (i.e. EOF) to exit >>> quit() -- Cosmin Stejerean http://www.offbytwo.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Serializing Clojure objects
On Dec 2, 11:52 pm, Rich Hickey <[EMAIL PROTECTED]> wrote: > As part of AOT I needed to enhance print/read to store constants of > many kinds, and restore faithfully. This led to a new multimethod - > print-dup, for high-fidelity printing. You can get print-dup behavior > by binding *print-dup*: > ... > > It can handle all of the Clojure data structures (including sorted > variants), Java collections, classes etc. > > You can extend it to new types by defining the print-dup method for > the type. > > Rich Very cool. I did not know much about print-dup and the support for java collections. Thanks. Parth --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Accept RE Pattern in (find-doc ...)?
On Dec 2, 11:03 am, Randall R Schulz <[EMAIL PROTECTED]> wrote: > Hi, > > I was thinking it would be nice if (find-doc ...) accepted a Pattern (in > addition to the String it now accepts), thus allowing #"RE pattern" > regular expression pattern literals. > > What do Rich and others think? > Done, svn 1138 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: clojure.main default print function
Clarification: clojure.lang.Repl's behavior hasn't changed, it's just that the clojure.main default REPL behaves differently from it. Those who don't call clojure.main in their clj scripts won't notice a difference. Perry --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: clojure.main default print function
On Dec 2, 2:37 pm, Perry Trolard <[EMAIL PROTECTED]> wrote: > Clarification: clojure.lang.Repl's behavior hasn't changed, it's just > that the clojure.main default REPL behaves differently from it. Those > who don't call clojure.main in their clj scripts won't notice a > difference. > Fixed (svn 1139) - thanks for the report. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Proxy questions
On Dec 2, 12:51 pm, Andrés M. Quijano <[EMAIL PROTECTED]> wrote:
> Hi
>
> I'm trying to use Clojure with ApacheMINA. I think Clojure it's the
> ideal language to concurrently handle all the events that arrive
> intoMINA'sseparate threads.
Hi Andrés,
I bumped into Mina a couple of weeks ago, and was thinking that might
be interesting to use a non-blocking IO library from Clojure. I'm not
sure about the ideal design for coupling the Concurrency features of
Clojure with the effectful NIO Mina classes. I would be happy to
discuss it though if anyone has bright ideas ;-)
Anyway, I've managed to run the 'MinaTimeServer' from
http://mina.apache.org/mina-v20-quick-start-guide.html by implementing
the server and handler in Clojure and using the new (AOT) compile
feature to generate classes.
I've attached a zip with the source together with a 'trace' of me
making it run, which should be easy to follow...
zip: http://groups.google.com/group/clojure/web/echo-mina.zip
Kind Regards,
- Karl
Some source:
;;mina.clj
(ns clojure.examples.mina
(:gen-class)
(:import (org.apache.mina.core.session IdleStatus)
(org.apache.mina.core.service IoAcceptor)
(java.nio.charset Charset)
(java.net InetSocketAddress)
(org.apache.mina.filter.codec ProtocolCodecFilter)
(org.apache.mina.filter.codec.textline TextLineCodecFactory)
(org.apache.mina.filter.logging LoggingFilter)
(org.apache.mina.transport.socket.nio NioSocketAcceptor)))
(defn -main [s]
(doto (NioSocketAcceptor.)
(.. getFilterChain (addLast "logger" (LoggingFilter.)))
(.. getFilterChain (addLast "codec" (ProtocolCodecFilter.
(TextLineCodecFactory. (.forName Charset "UTF-8")
(.setHandler (clojure.examples.timeserverhandler.))
(.. getSessionConfig (setReadBufferSize 2048))
(.. getSessionConfig (setIdleTime (.BOTH_IDLE IdleStatus) 10))
(.bind (InetSocketAddress. 9123
;;timerserverhandler.clj
(ns clojure.examples.timeserverhandler
(:gen-class
:constructors {[] []}
:extends org.apache.mina.core.service.IoHandlerAdapter)
(:import (org.apache.mina.core.session IdleStatus
IoSession)
(org.apache.mina.core.service IoHandlerAdapter)))
(defn -exceptionCaught
[this, ses, cau]
(.printStackTrace cau))
(defn -messageReceived
[this, ses, msg]
(prn msg))
(defn -sessionIdle
[this, ses, stat]
(prn "IDLE"))
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Proxy questions
Just tried the zip file link. I forgot to put the trace :-( Sry, I've uploaded another zip file hoping it would overwrite the other. Alas, it didn't. So here is the new zip: http://groups.google.com/group/clojure/web/echo-mina%20%282%29.zip --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Serializing Clojure objects
On Tue, Dec 2, 2008 at 12:52 PM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> On Dec 2, 7:02 am, Parth Malwankar <[EMAIL PROTECTED]> wrote:
>> Tayssir John Gabbour wrote:
>> > Hi!
>>
>> > How should I approach serialization? I made a little test function
>> > which serializes and deserializes Clojure objects. It works for
>> > strings, integers, symbols, LazilyPersistentVectors and.. oddly..
>> > PersistentHashMaps that have exactly one element. (My Clojure is about
>> > a month old.)
>>
>> I am not much of a Java guy so this would be what I would do.
>> Clojure has reader syntax of its data structures (maps, vectors etc.)
>> so they can be easily written to a stream as test using write.
>>
>> Reading it is equally simple:
>>
>> user=> (def a (with-in-str "{:a 1 :b 2}" (read)))
>> #'user/a
>> user=> a
>> {:a 1, :b 2}
>> user=>
>>
>> So as long as your data has reader syntax its not too much
>> of an issue. If the data needs to be shared between languages
>> as highlighted by someone, you may consider using another
>> format like json or so.
>>
>> If the data used java object it may not be serializable so
>> easily. Generally my approach is to stick to data structures
>> at Clojure level as it has reader syntax.
>>
>
> Yes, please consider print/read. It is readable text, works with a lot
> of data structures, and is extensible.
>
> As part of AOT I needed to enhance print/read to store constants of
> many kinds, and restore faithfully. This led to a new multimethod -
> print-dup, for high-fidelity printing. You can get print-dup behavior
> by binding *print-dup*:
>
> (binding [*print-dup* true]
> (dorun
> (map prn
> [[1 2 3]
>{4 5 6 7}
>(java.util.ArrayList. [8 9])
>String
>"string"
>42M
>:hello
>#"ethel"
>(sorted-set 9 8 7 6)
>#'rest])))
>
> [1 2 3]
> {4 5, 6 7}
> #=(java.util.ArrayList. [8 9])
> #=java.lang.String
> "string"
> 42M
> :hello
> #"ethel"
> #=(clojure.lang.PersistentTreeSet/create [6 7 8 9])
> #=(var clojure.core/rest)
>
> It can handle all of the Clojure data structures (including sorted
> variants), Java collections, classes etc.
>
> You can extend it to new types by defining the print-dup method for
> the type.
I don't understand what the print-dup mechanism outputs and how to
reconstruct objects from that output later. I was expecting an API
similar to this.
(def my-string (print-dup [1 2 3]))
(def my-data (read my-string))
Can you give a simple example of serializing and deserializing a
Clojure collection?
--
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Accept RE Pattern in (find-doc ...)?
On Tuesday 02 December 2008 11:21, Rich Hickey wrote: > On Dec 2, 11:03 am, Randall R Schulz <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I was thinking it would be nice if (find-doc ...) accepted a > > Pattern (in addition to the String it now accepts), thus allowing > > #"RE pattern" regular expression pattern literals. > > > > What do Rich and others think? > > Done, svn 1138 > > Rich Thanks. You gotta' love that instant gratification. Usually I have to write code to get that... RRS --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Possible Reflector Bug
On Sat, Nov 29, 2008 at 6:17 PM, JMan <[EMAIL PROTECTED]> wrote:
>
> Consider these 2 interfaces:
>
> - PackagePrivateInterface.java
>
> package test;
>
> interface PackagePrivateInterface {
>public void myPublicMethod();
> }
>
> - PublicTagInterface.java
>
> package test;
>
> public interface PublicTagInterface extends PackagePrivateInterface {
> }
>
> And these 2 classes:
>
> - Factory.java
>
> package test;
>
> public class Factory {
>public static PublicTagInterface newImpl() {
>return new PackagePrivateClass();
>}
> }
>
> - PackagePrivateClass.java
>
> package test;
>
> class PackagePrivateClass implements PublicTagInterface {
>PackagePrivateClass(){
>}
>public void myPublicMethod() {
>}
> }
>
> Now examine the following snippet of clojure code:
>
> (import '(test Factory PublicTagInterface))
>
> (def foo (. Factory newImpl))
>
> (. foo myPublicMethod)
> java.lang.IllegalAccessException: Class clojure.lang.Reflector can not
> access a member of class test.PackagePrivateInterface with modifiers
> "public abstract" (NO_SOURCE_FILE:0)
>
> Also "can not" should be spelled "cannot."
>
That message is coming from the Java reflection library, not Clojure.
As defined above, the method cannot be called via reflection. This is
because the resulting type of myPublicMethod in PublicTagInterface is:
public abstract void test.PackagePrivateInterface.myPublicMethod()
Reflection will not let you call methods of private classes.
If PublicTagInterface redeclares the method as follows:
public interface PublicTagInterface extends PackagePrivateInterface {
public void myPublicMethod();
}
then the type is:
public abstract void test.PublicTagInterface.myPublicMethod()
and it works fine.
There is nothing I can do about this in Clojure.
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Possible Reflector Bug
Thanks for the in depth response. OK, not a Clojure problem . But as
an aside, it is unfortunate that the Java reflection API cannot handle
this case. The redeclaration solution may work fine, but it defeats
the purpose of having the package private interface (which may have
other public sub-types). In the end, this means code duplication in
the interfaces code. Perhaps a better solution is to not make the
interfaces package private, but at the cost of exposing the client to
unnecessary details. Oh well...
On Dec 2, 3:37 pm, "Rich Hickey" <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 29, 2008 at 6:17 PM, JMan <[EMAIL PROTECTED]> wrote:
>
> > Consider these 2 interfaces:
>
> > - PackagePrivateInterface.java
>
> > package test;
>
> > interface PackagePrivateInterface {
> > public void myPublicMethod();
> > }
>
> > - PublicTagInterface.java
>
> > package test;
>
> > public interface PublicTagInterface extends PackagePrivateInterface {
> > }
>
> > And these 2 classes:
>
> > - Factory.java
>
> > package test;
>
> > public class Factory {
> > public static PublicTagInterface newImpl() {
> > return new PackagePrivateClass();
> > }
> > }
>
> > - PackagePrivateClass.java
>
> > package test;
>
> > class PackagePrivateClass implements PublicTagInterface {
> > PackagePrivateClass(){
> > }
> > public void myPublicMethod() {
> > }
> > }
>
> > Now examine the following snippet of clojure code:
>
> > (import '(test Factory PublicTagInterface))
>
> > (def foo (. Factory newImpl))
>
> > (. foo myPublicMethod)
> > java.lang.IllegalAccessException: Class clojure.lang.Reflector can not
> > access a member of class test.PackagePrivateInterface with modifiers
> > "public abstract" (NO_SOURCE_FILE:0)
>
> > Also "can not" should be spelled "cannot."
>
> That message is coming from the Java reflection library, not Clojure.
>
> As defined above, the method cannot be called via reflection. This is
> because the resulting type of myPublicMethod in PublicTagInterface is:
>
> public abstract void test.PackagePrivateInterface.myPublicMethod()
>
> Reflection will not let you call methods of private classes.
>
> If PublicTagInterface redeclares the method as follows:
>
> public interface PublicTagInterface extends PackagePrivateInterface {
> public void myPublicMethod();
>
> }
>
> then the type is:
>
> public abstract void test.PublicTagInterface.myPublicMethod()
>
> and it works fine.
>
> There is nothing I can do about this in Clojure.
>
> 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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Serializing Clojure objects
On Tue, Dec 2, 2008 at 3:52 PM, Mark Volkmann <[EMAIL PROTECTED]> wrote: > > (def my-string (print-dup [1 2 3])) > (def my-data (read my-string)) > > Can you give a simple example of serializing and deserializing a > Clojure collection? For "serializing" you have a couple options: (def my-string (binding [*print-dup* true] (pr-str [1 2 3]))) (def my-string (with-out-str (print-dup [1 2 3] *out*))) I don't know which is "better". Both produce a my-string like: "#=(clojure.lang.LazilyPersistentVector/create [1 2 3])" The regular 'read' function can read these *print-dup* strings to reproduce the original structure, a.k.a. deserialize: (def my-data (with-in-str my-string (read))) --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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
eval in macro: No method for dispatch value
After playing around with macros, I ran into this problem with Clojure (the latest version from github). The following code throws an IllegalArgumentException: "No method for dispatch value: class java.lang.StringBuffer" (defmacro wrap [h] (eval h)) (wrap (new StringBuffer)) But this works fine: (eval (new StringBuffer)) Apparently this fails for StringBuffers, but not for Strings or ArrayLists. I'm not sure if this is a bug, or what the underlying rules here are. At the very least the error message is ... unhelpful. I hope that somebody can shine a light on this. Cheers, Michiel --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: eval in macro: No method for dispatch value
Hi Michiel, eval is for form data, so I am more surprised that it works for ArrayList than that it fails for StringBuffer. Stu > After playing around with macros, I ran into this problem with Clojure > (the latest version from github). The following code throws an > IllegalArgumentException: "No method for dispatch value: class > java.lang.StringBuffer" > > (defmacro wrap [h] (eval h)) > (wrap (new StringBuffer)) > > But this works fine: > > (eval (new StringBuffer)) > > Apparently this fails for StringBuffers, but not for Strings or > ArrayLists. I'm not sure if this is a bug, or what the underlying > rules here are. At the very least the error message is ... unhelpful. > I hope that somebody can shine a light on this. > > Cheers, > > Michiel > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
change in doto behavior
Can someone tell me whether this change was intentional? In the
20080916 release, I get this:
user=> (doto (new java.util.HashMap) (.put "a" "b"))
java.lang.IllegalArgumentException: No matching method found: .put
java.lang.IllegalArgumentException: No matching method found: .put
at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:44)
at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:28)
at user.eval__4117.invoke(Unknown Source)
at clojure.lang.Compiler.eval(Compiler.java:3891)
at clojure.lang.Repl.main(Repl.java:75)
user=> (doto (new java.util.HashMap) (put "a" "b"))
{a=b}
In revision 1139, I get this:
user=> (doto (new java.util.HashMap) (put "a" "b"))
java.lang.Exception: Unable to resolve symbol: put in this context
(NO_SOURCE_FILE:2)
user=> (doto (new java.util.HashMap) (.put "a" "b"))
#=(java.util.HashMap. {"a" "b"})
I'm using JRE 1.6.0.10.
Bill Smith
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: quit
> REPL would be great. Using exit-clojure or quit-clojure instead will > continue to require the user the look up how to terminate the REPL > somewhere, at which point they might as well read about C-d. Not entirely - once Slime/Jline is up tab completion on qu TAB or ex TAB would give you what you needed. Firing up a python2.51 at the shell and entering ex TAB gets me: >>> ex exceptexec execfile exit >>> Which is entirely different than getting nothing at all. Maybe comparing McIntosh to Granny Smiths is more apropos. SBCL at the shell gives: * exit debugger invoked on a UNBOUND-VARIABLE: The variable EXIT is unbound. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. The point isn't simply that at a naked shell `quit' or `exit' don't get anywhere but that in more well heeled environs Clojure still feels underdressed in this *particular* situation. Certainly there are times when one would like to exit the REPL without leaving the environment entirely, and while setups like Slime can accomadate this that is only one environ. Future setups may in fact benefit from the ability to call `quit' or `exit' directly - However, in a concurrent, parallel, or threaded situation it may be beneficial to leave quit for some other use than to leave the game entirely. Having `quit-clojure' and/or `exit-clojure' available as a tab-complete in addition to leaving open the shorter tokens `quit' and `exit' for future potential uses or User Code makes sense. s_P On Dec 2, 2:07 pm, "Cosmin Stejerean" <[EMAIL PROTECTED]> wrote: > On Sun, Nov 30, 2008 at 3:05 PM, Mon Key <[EMAIL PROTECTED]> wrote: > > > Maybe (quit-clojure) instead of (quit)? This would save vanilla `quit' > > just in case it's needed later/elsewhere. > > Might also be nice to have (exit-clojure). Ditto saving vanilla `exit' > > for other purposes > > > When first configuring Clojure on both linux box and windows from the > > command line (e.g. pre-slime, sans Jline ); the (quit) form was one of > > the first things I evaluated at the REPL :P > > When I first started (quit) and (exit) are the first two things I've tried > for getting out of the Repl. Having either of those work for terminating the > REPL would be great. Using exit-clojure or quit-clojure instead will > continue to require the user the look up how to terminate the REPL > somewhere, at which point they might as well read about C-d. > For example, here's what happens when someone new to Python tries to exit > the interactive console. > > >>> quit > > Use quit() or Ctrl-D (i.e. EOF) to exit > > >>> quit() > > -- > Cosmin Stejereanhttp://www.offbytwo.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: change in doto behavior
Yes. doto is more general now. The . is needed to indicate Java
interop calls because doto can do other things which are not Java
interop calls:
(doto "double" println println)
double
double
-> "double"
Stuart
> Can someone tell me whether this change was intentional? In the
> 20080916 release, I get this:
>
> user=> (doto (new java.util.HashMap) (.put "a" "b"))
> java.lang.IllegalArgumentException: No matching method found: .put
> java.lang.IllegalArgumentException: No matching method found: .put
> at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:44)
> at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:28)
> at user.eval__4117.invoke(Unknown Source)
> at clojure.lang.Compiler.eval(Compiler.java:3891)
> at clojure.lang.Repl.main(Repl.java:75)
> user=> (doto (new java.util.HashMap) (put "a" "b"))
> {a=b}
>
> In revision 1139, I get this:
>
> user=> (doto (new java.util.HashMap) (put "a" "b"))
> java.lang.Exception: Unable to resolve symbol: put in this context
> (NO_SOURCE_FILE:2)
> user=> (doto (new java.util.HashMap) (.put "a" "b"))
> #=(java.util.HashMap. {"a" "b"})
>
> I'm using JRE 1.6.0.10.
>
> Bill Smith
> >
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Supporting protected fields in genclass
Updated patch attached, the extra let for readability looked ugly to me after some sleep. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~--- genclass-protected-fields.diff Description: Binary data On Dec 1, 2008, at 3:44 PM, Rich Hickey wrote: > > > > On Dec 1, 2:57 pm, Matt Revelle <[EMAIL PROTECTED]> wrote: >> Yes, this again. Now that we have AOT, I wanted to revisit >> supporting >> the exposing of inherited protected fields that originate from >> farther >> up the hierarchy chain than the super class. >> >> Attached is a patch against SVN revision 1133. >> >> I promise to never bring this up again. =) >> >> -Matt >> > > I'm glad you did. There were a couple of enhancements that got delayed > in the AOT process. > > As far as the patch, I'd prefer not to have any logic that uses > exceptions as part of normal flow control (i.e. calling > getDeclaredField and eating the exception), so could you please define > in terms of getDeclaredFields instead? > > Thanks, > > 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 [EMAIL PROTECTED] > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -~--~~~~--~~--~--~--- >
Re: proposal: match multimethod
On Dec 2, 9:22 pm, Rich Hickey <[EMAIL PROTECTED]> wrote: > > For those of us that don't do Ruby - what does === do? It's a supporting method for the case keyword case object when pred1: action1 when pred2: action2 .. end translates to if pred1 === object action1 elsif pred2 === object action2 .. end It's not really a fuzzy-value match, just nice syntactic sugar for a multiply-dispatched match method. martin --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
[PATCH] Improved Maven Build
I've created a patch for the clojure source that does the following: - Adds a minimal site build, with links to the main Clojure web site (http://clojure.org) - Generates a source JAR to go with the binary JAR - Generates JavaDoc for the project site (if profile "javadoc" is enabled) - Adds a Maven profile, "ci", for a nightly continuous integration build, to deploy Maven artifacts to a local Maven repository This is based on icky Maven stuff I wrote for Tapestry a year or so ago. I'm also in the process of revamping tapestry.apache.org to make it more of a project hosting site; it will (soon) have Bamboo (continuous integration server), Confluence (Wiki), JIRA (Issue Tracking) and SVN. I could set up a post-commit and nightly build for Clojure at any time. This has served the Tapestry community quite well, giving people easy access to latest-and-greatest snapshots and (JavaDoc) documentation. Note that the clojure-logo.png file must be stored in src/site/resources/images. -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~--- <>Index: pom.xml === --- pom.xml (revision 1139) +++ pom.xml Tue Dec 02 21:50:15 PST 2008 @@ -1,31 +1,162 @@ http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http//www.w3.org/2001/XMLSchema-instance" - xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 -http://maven.apache.org/maven-v4_0_0.xsd";> + xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> - 4.0.0 +4.0.0 - jvm.clojure +org.clojure - clojure-lang - clojure-lang - 1.0-SNAPSHOT +clojure-lang +clojure-lang +1.0-SNAPSHOT - http://clojure.org/ +http://clojure.org/mvn-site/ + +Clojure core environment and runtime library. + + + +Common Public License Version 1.0 +http://www.opensource.org/licenses/cpl1.0.txt +repo + + + + +scm:https://clojure.svn.sourceforge.net/svnroot/clojure/ +http://clojure.svn.sourceforge.net/viewvc/clojure/ + + + + +rh +Rich Hickey +[EMAIL PROTECTED] + +Bringer Of Light + +EST + + + + + +Clojure Google Group +[EMAIL PROTECTED] +[EMAIL PROTECTED] +http://groups.google.com/group/clojure + + + - - src/jvm - src/clj - - -maven-compiler-plugin - - 1.5 - 1.5 - true - - + +src/jvm +src/clj + + +maven-compiler-plugin + +1.5 +1.5 +true + + + +maven-site-plugin + +2.0-beta-5 + + +org.apache.maven.plugins +maven-source-plugin + + + +jar + + + + + +org.apache.maven.plugins +maven-jar-plugin + + +true +true + + + - - - -src/clj/ - - - + + + +src/clj/ + + + + + + + +org.apache.maven.plugins +maven-project-info-reports-plugin + + + +license +scm +project-team +mailing-list + + + + + + + + + + + +javadoc + + + +org.apache.maven.plugins +maven-javadoc-plugin + +2.2 + +true + +http://java.sun.com/j2se/1.5.0/docs/api/ + +true + + +
Re: [PATCH] Improved Maven Build
Sorry, that http://tapestry.formos.com as the project hosting site. It currently runs Bamboo at http://tapestry.formos.com/bamboo On Tue, Dec 2, 2008 at 10:05 PM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > I've created a patch for the clojure source that does the following: > > - Adds a minimal site build, with links to the main Clojure web site > (http://clojure.org) > - Generates a source JAR to go with the binary JAR > - Generates JavaDoc for the project site (if profile "javadoc" is enabled) > - Adds a Maven profile, "ci", for a nightly continuous integration > build, to deploy Maven artifacts to a local Maven repository > > This is based on icky Maven stuff I wrote for Tapestry a year or so ago. > > I'm also in the process of revamping tapestry.apache.org to make it > more of a project hosting site; it will (soon) have Bamboo (continuous > integration server), > Confluence (Wiki), JIRA (Issue Tracking) and SVN. I could set up a > post-commit and nightly build for Clojure at any time. This has > served the Tapestry community quite well, giving people easy access to > latest-and-greatest snapshots and (JavaDoc) documentation. > > > Note that the clojure-logo.png file must be stored in > src/site/resources/images. > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure could be to Concurrency-Oriented Programming what Java was to OOP
On Dec 1, 12:03 am, bc <[EMAIL PROTECTED]> wrote: > I've written a blog post titled "Clojure could be to Concurrency- > Oriented Programming what Java was to OOP" in which I discuss > Clojure's approach to concurrency:http://bc.tech.coop/blog/081201.html > > Any comments/criticisms would be appreciated. Great article! :-) A picky point -- "concurrency" refers to multiple actors and the shared data problem (which is not necessarily related to performance), whereas "the free lunch is over" refers to "parallelism" (using multiple CPUs to improve performance), regardless of what terminology the article actually uses ;-) mfh --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Interactive Charting with Clojure & the Google Chart API
I thought this may interest this group: I created a little interactive charting environment for Clojure which you can find here: http://code.google.com/p/charts4j/downloads/list. Simply load it with the following command: (load-file "charting.clj"), setting your path appropriately, of course. You will also need the charts4j jar in your Clojure classpath. Find that jar at the same link above. Moreover, you must be connected to the Internet for this script to run, as the charts are ultimately rendered by the Google Chart API. It should play a slide show, and can be a starting point for generating your own charts interactively. It should be straightforward to generate all the charts available in charts4j by using that script as an example. One last important note about the charting.clj script; it works with the latest Clojure SVN revision. I also provide a "charting-20080916.clj" that works with the official latest release. I wrote a blog post about this exercise here: http://radioeiffel.blogspot.com/2008/12/interactive-charting-with-clojure.html --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Seq forms with preceding #^metadata lose the metadata
Hi Meikel, Rich, Thank you for your clarification. Now I understand the difference between #^ and with-meta and I can see #^metadata on a seq form is intact at compile time (and it can be passed down to runtime) so that now I know I was wrong to say like the topic. Thanks again. -- Kei --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
