Updated Monads
I just uploaded an improved version of my monad implementation: http://groups.google.com/group/clojure/web/monads.clj Monad comprehensions now admit filters (using :when, just like Clojure's list comprehensions) and all monads have the operations join, map, and seq. The application examples have been extended as well. 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: Distributed concurrent applications in Clojure?
On Mon, Nov 24, 2008 at 6:41 PM dokondr [EMAIL PROTECTED] wrote: Any ideas how Clojure can be used for distributed concurrent applications ? To my mind it should be possible to implement in Clojure mechanism similar to Erlang light-weight processes running on distributed 'nodes' that can be addressed by 'ports' to send them 'commands'. How this can be done with Clojure 'agents'? An obvious solution would be to create an 'agent proxy' on every node that will maintain a list of its agents and will forward (send ...) messages to other nodes, as well as receive messages addressed to its own agents from remote nodes and then deliver these messages to correct agents. Addressing scheme and message protocols should be developed as well. Other ways to provide for communication between nodes? There was some talk about Clojure running on terracotta (www.terracotta.org) which is a distributed JVM (a single JVM instance running on distributed nodes). Depending on how well terracotta can pull it off, clojure's own implementation may remain simple. However, I am wondering if having a clojure conscious distributed version of agents, STM, Threads and the global namespace can prove to be better at efficiency and providing time-memory-network_traffic guarantees to the programmer. Immutability of objects and the design of the global and thread local namespace should reduce implementation hassles a lot. I will really appreciate some comments. Pinocchio --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Trouble compiling clojure.contrib libs
I'm having trouble compiling code from clojure-contrib. Here's a reproducible example based on the current svn heads of each (1121, 257). % cd /tmp % svn co https://clojure.svn.sourceforge.net/svnroot/clojure/trunk clojure /dev/null % svn co https://clojure-contrib.svn.sourceforge.net/svnroot/clojure-contrib/trunk clojure-contrib /dev/null % cd clojure % ant /dev/null % java -cp clojure.jar:/tmp/clojure-contrib/src:/tmp/myclasses clojure.lang.Repl Clojure user= (require 'clojure.contrib.except) ; same behavior with or without this line, just showing that clojure.contrib is accessible nil user= (binding [*compile-path* /tmp/myclasses] (compile 'clojure.contrib.except)) java.lang.RuntimeException: java.lang.ClassNotFoundException: clojure.contrib.except$throwf__35 (NO_SOURCE_FILE:0) user= (System/getProperty java.class.path) clojure.jar:/tmp/clojure-contrib/src:/tmp/myclasses user= (binding [*compile-path* /tmp/myclasses] (compile 'clojure.contrib.except)) java.lang.RuntimeException: java.lang.ClassNotFoundException: clojure.contrib.except$throwf__44 (NO_SOURCE_FILE:0) user= % ls -R /tmp/myclasses clojure /tmp/myclasses/clojure: contrib /tmp/myclasses/clojure/contrib: except$throwf__35.class except$throwf__44.class except.class % java -version java version 1.6.0_07 Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode) The ClassNotFoundException is thrown even though it appears that the class should be found. A class file with that name exists in the (global) classpath. The example shown is Mac OS X Leopard. The failure is exactly the same on Ubuntu 8.10 Linux with this java -version: % java -version java version 1.6.0_0 IcedTea6 1.3.1 (6b12-0ubuntu6) Runtime Environment (build 1.6.0_0-b12) OpenJDK Client VM (build 1.6.0_0-b12, mixed mode, sharing) --Steve --~--~-~--~~~---~--~~ 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: Monads in Clojure
On Nov 21, 2008, at 17:10, Chouser wrote: This is pretty code. Did you just implement symbol-macro-let? Very nice. 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. Would that be something of interest to the Clojure community? 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: Adapting a functional pretty-printer to Clojure
On Nov 25, 12:51 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Nov 25, 12:50 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Nov 25, 12:22 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: This approach might just be too inefficient -- perhaps it would be best to implement the pretty-printer in an imperative style after all. OTOH it is pretty darn nifty... ...or would be if Google Groups didn't wrap so well... I've added trampoline, which could significantly ease the work you are trying to do: http://groups.google.com/group/clojure/msg/3addf875319c5c10 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: Monads in Clojure
On Nov 25, 2008, at 9:06 AM, Konrad Hinsen wrote: But it would be fairly easy to implement symbol- macrolet on top of my replace-syms. Would that be something of interest to the Clojure community? I have no experience with it myself, but I've seen it discussed as something that would be a welcome addition to Clojure. It's on Rich's to-do list as the second item listed under Long-term: http://richhickey.backpackit.com/pub/1597914 --Steve --~--~-~--~~~---~--~~ 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: Patch: universal main() with repl/script/compile
On Nov 24, 7:52 pm, Perry Trolard [EMAIL PROTECTED] wrote:
Right, good idea. It would just take checking to see if the path
variable is in System.getProperty(java.class.path), right?
...
Answer: no. I tried the approach below against Stephen's
clojure.lang.Compile, the ant build process failed. All of the
classes currently on the classpath are evidently not reflected in the
system property -- at least when running in Ant. (I believe they would
be when invoking java w/ the -cp option.)
I think it's because of different string representations of the path
(e.g. the path variable may be ./classes but the classpath (under
Ant) is /home/bob/project/classes. It probably need something like
this:
File pathFile = new File(path);
for (String cp : System.getProperty(java.class.path).split(:)) {
File cpFile = new File(cp);
if (pathFile.equals(cpFile)) {
found = true;
break;
}
}
-Stuart Sierra
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Reactive Programming in F# and CELLs
Hi, falcon, I wrote (with MikeM) a pair of basic Cell-like libraries in Clojure, one using Refs and one using Agents: http://groups.google.com/group/clojure/browse_thread/thread/d79392e4c79f8cde (code is in the attachments) In response, Rich added Agent Watches (see same thread), which are like triggers that get called whenever an Agent's value changes. I'm not sure where else to go with this, but I'm interested in talking about it. One thing I was never clear on was the correct transactional behavior. With cells in Refs, modifying a cell blocks until all other cells are up-to-date, which can take time. With cells in Agents, modifying a cell never blocks, but you can't predict the order of events, as I discovered with a simple GUI demo. I know the original Common Lisp version of Cells imposed a global time counter, so it may be a dependency framework rather than a concurrency framework. From Rich: I don't know anything about Cells, but if it has global time ordering it might not be a good fit for multithreading, and not for agents. -Stuart Sierra On Nov 24, 7:33 pm, falcon [EMAIL PROTECTED] wrote: I hope folks here don't mind this post. The following article explains how to do reactive programming in F#:http://tomasp.net/blog/reactive-i-fsevents.aspx(the bottom of the article has links to rest of the articles in the series) There has been some recent discussion on CELLs in Clojure. There was some question of motivation behind 'reactive' programming...I believe this article makes the ideas a bit more concrete. Since Clojure already has some features for concurrent programming, I believe the reactive model should also be easy to accommodate. In F#, one can filter/map/reduce events (and much more) just as if they were operations on a list. How would this be done in cells? How would one combine or split several cells? This type of data-flow programming also brings clojure one step closer my dream of a super-spreadsheet: Instead of typing out expressions on an REPL, why not make the REPL non-linear and allow users to enter expressions in 2-d space (similar to a grid...but without the grid). Unlike Excel, clojure could also very easily let end-users define their own functions and use them in expressions (thereby vastly improving the lack of abstractions in current spread sheets) --~--~-~--~~~---~--~~ 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: trampoline for mutual recursion
On Nov 25, 2008, at 9:05 AM, Rich Hickey wrote: I've added trampoline to ease the conversion/creation of mutually recursive algorithms in Clojure. Very cool! Thanks for enabling that. In looking over the implementation, I found a small problem: the arg vector precedes the doc string leading to: user= (doc trampoline) - clojure.core/trampoline ([f]) nil nil --Steve --~--~-~--~~~---~--~~ 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: trampoline for mutual recursion
On Nov 25, 10:42 am, Stephen C. Gilardi [EMAIL PROTECTED] wrote: On Nov 25, 2008, at 9:05 AM, Rich Hickey wrote: I've added trampoline to ease the conversion/creation of mutually recursive algorithms in Clojure. Very cool! Thanks for enabling that. In looking over the implementation, I found a small problem: the arg vector precedes the doc string leading to: Fixed (SVN 1123) - thanks for the report. I've also added support for passing initial args, so the top-level call can be: (trampoline foo 100) 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 -~--~~~~--~~--~--~---
Type coercion asymmetry
It seems this is the best way to go currently: user= (Integer/parseInt 1234) 1234 but wouldn't it be nice if this worked: user= (str 123) 123 user= (str 12.123) 12.123 user= (int 123) java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Character (NO_SOURCE_FILE:0) user= (float 12.123) java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Number (NO_SOURCE_FILE:0) -Jeff --~--~-~--~~~---~--~~ 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: Trouble compiling clojure.contrib libs
On Tue, Nov 25, 2008 at 9:02 AM, Stephen C. Gilardi [EMAIL PROTECTED] wrote: % java -cp clojure.jar:/tmp/clojure-contrib/src:/tmp/myclasses clojure.lang.Repl The classes directory (/tmp/myclasses in this case) must exist before you start Java with it in your classpath. You get no error at this point, but apparently if the directory doesn't exist it's not really used, even though it's shown in the java.class.parth property string. --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: Patch: universal main() with repl/script/compile
On Nov 25, 8:42 am, Stuart Sierra [EMAIL PROTECTED] wrote: I think it's because of different string representations of the path (e.g. the path variable may be ./classes but the classpath (under Ant) is /home/bob/project/classes. It probably need something like this: ... Yeah, I thought of the same, but when I dump the results of System.getProperty(java.class.path), my classes directory doesn't show up -- running under the Ant task, on my machine, at least. It would if passed as an arg to java -cp, but the Ant is the first case where Compile's got to work. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
categorizing functions
Sometimes it can be time consuming for someone new to Clojure, like myself, to find an existing function that does what they need. I think this would be easier if the standard functions were grouped in some meaningful way. For example, all these functions retrieve items from a sequence: first, second, rest, take, leave. I'm sure I omitted many. Could function metadata be used to help with this? What if functions had a piece of metadata named categories. Each function could be in any number of categories. There could be function similar to find-doc that finds all the functions in a given category. The hardest part might be coming up with good category names. -- 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: Reactive Programming in F# and CELLs
I did see the Cell discussion and noticed that Rich added the ability to watch Agents. Sounds like maintaining correct dependencies is more important than raw speed. I believe this problem of maintaining correct dependencies is called Glitch Prevention in FrTime framework. The FrTime papers are quite interesting (ftp://ftp.cs.brown.edu/pub/ techreports/03/cs03-20.pdf, http://www.cs.brown.edu/~sk/Publications/Papers/Published/ck-frtime/paper.pdf). There is even an FrTime library which has a few years of work behind it: http://download.plt-scheme.org/doc/pdf/frtime.pdf. I get the impression that FrTime is more fully baked than Cells. By the way, even if dependency has to be maintained, as long as there are several independent dependency graphs, the system should still be able to process them concurrently. You mentioned that you weren't sure where to go with this. I think a framework like this could be the foundation of many interesting features. Academic literature often associates reactive programs with GUI programming. You will find plenty of takers in the finance industry, who have to react to multiple streams of data (changing prices, order status, etc.). Complex event processing is becoming a more mature field and is used for tracking RFID chips (at super markets, ports, etc.). I think the most obvious use is spreadsheets. Spreadsheets basically operate on a data-flow programming model such as this. Finally, with Rich's background in simulation, I would think he would be more interested in this than most :) On Nov 25, 10:00 am, Stuart Sierra [EMAIL PROTECTED] wrote: Hi, falcon, I wrote (with MikeM) a pair of basic Cell-like libraries in Clojure, one using Refs and one using Agents:http://groups.google.com/group/clojure/browse_thread/thread/d79392e4c... (code is in the attachments) In response, Rich added Agent Watches (see same thread), which are like triggers that get called whenever an Agent's value changes. I'm not sure where else to go with this, but I'm interested in talking about it. One thing I was never clear on was the correct transactional behavior. With cells in Refs, modifying a cell blocks until all other cells are up-to-date, which can take time. With cells in Agents, modifying a cell never blocks, but you can't predict the order of events, as I discovered with a simple GUI demo. I know the original Common Lisp version of Cells imposed a global time counter, so it may be a dependency framework rather than a concurrency framework. From Rich: I don't know anything about Cells, but if it has global time ordering it might not be a good fit for multithreading, and not for agents. -Stuart Sierra On Nov 24, 7:33 pm, falcon [EMAIL PROTECTED] wrote: I hope folks here don't mind this post. The following article explains how to do reactive programming in F#:http://tomasp.net/blog/reactive-i-fsevents.aspx(thebottom of the article has links to rest of the articles in the series) There has been some recent discussion on CELLs in Clojure. There was some question of motivation behind 'reactive' programming...I believe this article makes the ideas a bit more concrete. Since Clojure already has some features for concurrent programming, I believe the reactive model should also be easy to accommodate. In F#, one can filter/map/reduce events (and much more) just as if they were operations on a list. How would this be done in cells? How would one combine or split several cells? This type of data-flow programming also brings clojure one step closer my dream of a super-spreadsheet: Instead of typing out expressions on an REPL, why not make the REPL non-linear and allow users to enter expressions in 2-d space (similar to a grid...but without the grid). Unlike Excel, clojure could also very easily let end-users define their own functions and use them in expressions (thereby vastly improving the lack of abstractions in current spread sheets) --~--~-~--~~~---~--~~ 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: Trouble compiling clojure.contrib libs
On Nov 25, 2008, at 11:38 AM, Chouser wrote: On Tue, Nov 25, 2008 at 9:02 AM, Stephen C. Gilardi [EMAIL PROTECTED] wrote: % java -cp clojure.jar:/tmp/clojure-contrib/src:/tmp/myclasses clojure.lang.Repl The classes directory (/tmp/myclasses in this case) must exist before you start Java with it in your classpath. You get no error at this point, but apparently if the directory doesn't exist it's not really used, even though it's shown in the java.class.parth property string. Thanks, that works great! It also explains why the ant build works--it always creates the directory first. Unless this changes, perhaps the Clojure AOT mechanism should refuse to create the directory at *compile-path* and instead require that it already exist. That would catch many instances of this problem and could provide a helpful message. Is there any way Clojure can add *compile-path* to classpath at the correct level so it's recognized in all the places it needs to be? I gather if that were easy, Rich would have already done it. Any ideas? --Steve --~--~-~--~~~---~--~~ 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: Patch: universal main() with repl/script/compile
Sorry -- inadvertent send: the Ant task is the first case that's gotta work, so I think the best option is to catch the ClassNotFound exception, unless there's another alternative I'm not thinking of ( given my small amount of knowledge of Java proper, the chances of that are high!). 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: Patch: universal main() with repl/script/compile
On Tue, Nov 25, 2008 at 12:06 PM, Perry Trolard [EMAIL PROTECTED] wrote: Sorry -- inadvertent send: the Ant task is the first case that's gotta work, so I think the best option is to catch the ClassNotFound exception, unless there's another alternative I'm not thinking of I don't have any alternatives to provide, but one potential problem with relying on a ClassNotFound exception is that there's a possibility that the class does exist on the classpath but you are expecting your new implementation to be found before that one. I don't know if this is the expected behavior, but I just thought I'd throw that out there for those working on this stuff. - J. --~--~-~--~~~---~--~~ 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: Patch: universal main() with repl/script/compile
On Nov 25, 11:46 am, Perry Trolard [EMAIL PROTECTED] wrote:
Yeah, I thought of the same, but when I dump the results of
System.getProperty(java.class.path), my classes directory doesn't
show up -- running under the Ant task, on my machine, at least. It
would if passed as an arg to java -cp, but the Ant is the first case
where Compile's got to work.
Is the classpath set up in the java Ant task? It should look
something like this:
Near the top:
property name=build location=classes/
In the compile_clojure task:
java classname=clojure.lang.Compile
classpath=${build}:${cljsrc}
sysproperty key=clojure.compile.path value=${build}/
arg value=clojure.core/
...and so on...
There have been so many patches on this, I'm not sure which one you
have.
-S
--~--~-~--~~~---~--~~
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: trampoline for mutual recursion
On Nov 25, 11:07 am, Rich Hickey [EMAIL PROTECTED] wrote: On Nov 25, 10:42 am, Stephen C. Gilardi [EMAIL PROTECTED] wrote: On Nov 25, 2008, at 9:05 AM, Rich Hickey wrote: I've added trampoline to ease the conversion/creation of mutually recursive algorithms in Clojure. Very cool! Thanks for enabling that. In looking over the implementation, I found a small problem: the arg vector precedes the doc string leading to: Fixed (SVN 1123) - thanks for the report. I've also added support for passing initial args, so the top-level call can be: (trampoline foo 100) I think this will be very useful. Now if only we can convince Sun to make it unnecessary... -- Steve --~--~-~--~~~---~--~~ 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: categorizing functions
This is a reasonable idea, and I would find it useful as well. However, it might be easier (and more appropriate) to make tagging a feature of the documentation website that has come up here. On Tue, Nov 25, 2008 at 11:38 AM, Mark Volkmann [EMAIL PROTECTED] wrote: Sometimes it can be time consuming for someone new to Clojure, like myself, to find an existing function that does what they need. I think this would be easier if the standard functions were grouped in some meaningful way. For example, all these functions retrieve items from a sequence: first, second, rest, take, leave. I'm sure I omitted many. Could function metadata be used to help with this? What if functions had a piece of metadata named categories. Each function could be in any number of categories. There could be function similar to find-doc that finds all the functions in a given category. The hardest part might be coming up with good category names. -- 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: Patch: universal main() with repl/script/compile
Is the classpath set up in the java Ant task? It should look
something like this:
Near the top:
property name=build location=classes/
In the compile_clojure task:
java classname=clojure.lang.Compile
classpath=${build}:${cljsrc}
sysproperty key=clojure.compile.path value=${build}/
arg value=clojure.core/
...and so on...
There have been so many patches on this, I'm not sure which one you
have.
-S
Yes, that's the build.xml I have. If I add
err.println(System.getProperty(java.class.path));
to clojure.lang.Compile, it gives me all of the Ant jars (included
below, but no need to scrutinize) but neither the $build or $cljsrc
directories set in build.xml.
Is there somewhere else to get a comprehensive list of the CLASSPATH?
Perry
java.class.path at time of clojure.lang.Compile's being called by Ant:
/usr/share/ant/lib/ant-launcher.jar:/usr/share/ant/lib/ant-jai.jar:/
usr/share/ant/lib/ant-jmf.jar:/usr/share/ant/lib/ant-junit.jar:/usr/
share/ant/lib/ant-launcher.jar:/usr/share/ant/lib/ant-nodeps.jar:/usr/
share/ant/lib/ant-swing.jar:/usr/share/ant/lib/ant-testutil.jar:/usr/
share/ant/lib/ant-trax.jar:/usr/share/ant/lib/ant.jar:/usr/share/ant/
lib/xercesImpl.jar:/usr/share/ant/lib/xml-apis.jar
--~--~-~--~~~---~--~~
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: egal
er i mean http://tinyurl.com/59l5e5 On Tue, Nov 25, 2008 at 10:53 AM, Raoul Duke [EMAIL PROTECTED] wrote: http://tinyurl.com/5okr87 Our model for object identity is similar to Scheme's concept of operational identity [Rees86], in which objects which behave the same should be the same. However, since behave the same is undecidable for functions and function-closures, we back down from operational identity to operational identity of data structure representations. Operational identity for data structures is much easier than operational identity for function-closures, because there are only a few well-defined operations on data structures, but function-closures can do anything. We define a single, computable, primitive equality predicate called EGAL which we show is consistent with the notion of operational identity of data structures. Egal is the obsolete Norman term for equal, and Égalité is the French word for social equality. During the seventeenth century two parallel vertical lines were frequently used [to denote equality], especially in France, instead of = [Young11]; we will later find that || is a remarkably satisfying infix symbol for egal. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Applying slurp to a java.io.File instance
Hello, I think it would be very nice if slurp (and line-seq, clojure.contrib.duck-streams.spit and clojure.contrib.duck- streams.write-lines) could take as argument a java.io.File instance as well as a string. Since FileInputStreams and FileReaders can be instantiated from both, and since java.io.Files allow for portable path manipulation, I think it's a bit heavy that I have to stringize my Files myself when applying slurp to them. What do you think? Benoit --~--~-~--~~~---~--~~ 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: JMS and Clojure?
Looks interesting. I would try to limit external dependencies by taking out Spring. I have a tiny abstraction layer for JMS written in Java (and another in JavaFX), where I feed in a Properties object with all the parameters (server location, authentication, etc.) and get quick access to various topic consumers and producers. I suspect that involving the properties object is not going to be very idiomatic clojure. On Nov 24, 8:50 pm, Luc Prefontaine [EMAIL PROTECTED] wrote: We use a synchronous layer to JMS queues implemented in Java to hook our Clojure code to the messaging world. Two Java classes to implement a consumer and a producer with some common inheritance are used. We had already some Java implementation so we just beefed it up a bit to make more robust. We use Spring to load beans so loading a consumer look like this: (defn create-producer-consumer [name] (get-bean name) ) The Spring bean being something similar to this: bean id=connectionFactoryBean class=org.apache.activemq.pool.PooledConnectionFactory property name=connectionFactory ref=connectionSimpleFactoryBean / /bean bean id=busMessageQConsumer class=com.softaddicts.products.higiebus.tools.jms.Consumer property name=subject value=HIGIEBUS.QUEUES.BUS_DATA?consumer.exclusive=true / property name=connectionFactory ref=connectionFactoryBean / property name=transacted value=true / property name=name value=HIGIEBUSRouting / property name=ackMode value=CLIENT_ACKNOWLEDGE / /bean Now we have small wrappers in Clojure like these: (defn read-message Consume messages [consumer] (. consumer receive) ) (deftrace send-message ;; Send messages [producer msg] (. producer send msg) ) (defn peek-text-message Peek at messages [consumer] (let [message (. consumer browse)] (if (not (nil? message)) (. message getText)) ) ) and so on for commits, rollbacks, . The Java classes handle connection/release of resources, cleanup when the JVM exits, We use the wrappers to protect ourselves from later changes in the implementation. We use ActiveMq 5.1 with master slave redundancy. Eventually we want to create a wrapper to allow Clojure functions to be called asynchronously but we are not there yet, mainly because we have other priorities. Using the Spring framework is certainly is a viable option, we look at to reuse existing code and getting Clojure code called directly in an asynchronous fashion. We start the consumers in separate thread. polling for messages through read-message and consort. This at least gives us some asynchronous processing illusion for the moment. We expect to shrink the Java code down to a certain size in the next months and shift more stuff to Clojure but meanwhile we had to take the shortest path and that implied reusing existing stuff from the first stage prototype. We are scheduled to be in production in the next 8 weeks. Clojure was targeted for the routing layer in our message bus, that's were the immediate benefits are (dispatch logic, message cloning, ...) For now we have a resilient implementation ready for production so it's satisfactory considering I heard about Clojure in September... Since the beta book is in progress, i am also catching up rapidly about the language and expect to spit out more elegant code in the near future :))) Luc On Mon, 2008-11-24 at 16:36 -0800, falcon wrote: What is the best way of accessing Java Messaging Service though Clojure? Sounds like Rich has already experimented, with good results: rhickey: I did some playing (in Clojure) with JMS and OpenMQ and it was awesome, easy, fun and vert fast, with pro level docs from Sun (http://clojure-log.n01se.net/date/2008-09-08.html) 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: Patch: universal main() with repl/script/compile
On Nov 25, 1:42 pm, Perry Trolard [EMAIL PROTECTED] wrote: Yes, that's the build.xml I have. If I add err.println(System.getProperty(java.class.path)); to clojure.lang.Compile, it gives me all of the Ant jars (included below, but no need to scrutinize) but neither the $build or $cljsrc directories set in build.xml. Is there somewhere else to get a comprehensive list of the CLASSPATH? I guess then Ant is playing around with classloaders, which are black magic to me. -Stuart Sierra --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Can Clojure functions be anonymous, curried and allow composition?
On Mon, Nov 24, 2008 at 6:46 PM, Randall R Schulz [EMAIL PROTECTED] wrote: On Monday 24 November 2008 15:14, dokondr wrote: And what is 'comp'? When in doubt: - Clojure native API http://clojure.org/api - comp http://clojure.org/api#toc122 Or: user= (doc comp) - clojure.core/comp ([ fs]) Takes a set of functions and returns a fn that is the composition of those fns. The returned fn takes a variable number of args, applies the rightmost of fns to the args, the next fn (right-to-left) to the result, etc. - J. --~--~-~--~~~---~--~~ 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: trampoline for mutual recursion
Very nice. Thanks, Rich. I had implemented my own version, but it's much nicer to have it in the language. 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 -~--~~~~--~~--~--~---
Re: Keyword constraints not enforced
Somewhat related, I noticed that the keyword function doesn't seem to make any attempt at ensuring keywords are even readable. user= (keyword (foo)) :(foo) Is this intended? On Nov 24, 9:26 am, Rich Hickey [EMAIL PROTECTED] wrote: On Nov 23, 9:09 am, James Reeves [EMAIL PROTECTED] wrote: On Nov 23, 11:38 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, According tohttp://clojure.org/reader: Keywords are like symbols, except: o They can and must begin with a colon, e.g. :fred. o They cannot contain '.' or name classes. Shouldn't this throw an exception? It seems that keywords aren't checked for correctness at all right now. I'd like to request that keywords continue to allow the '.' character, as it's useful for certain edge cases (Compojure and clj-html use it to specify class attributes, for instance). Does the inclusion of a '.' in a keyword introduce any syntax ambiguity I'm unaware of? Disallowing class names in keywords seems a little odd too, especially with AOT. If you compiled a Clojure file like clojure.contrib.def, would that mean you'd lose the ability to use the keyword :def? I think you've both misread they cannot name classes to be - They cannot contain class names. The symbol String can name a class but the keyword :String can't, that's all I meant there. As far as '.', that restriction has been relaxed. I'll try to touch up the docs for the next release. 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 -~--~~~~--~~--~--~---
why are remove-method and prefer-method macros?
Can't they just be: (defn remove-method Removes the method of multimethod associatedwith dispatch-value. [multifn dispatch-val] (. multifn removeMethod dispatch-val)) (defn prefer-method Causes the multimethod to prefer matches of dispatch-val-x over dispatch-val-y when there is a conflict [multifn dispatch-val-x dispatch-val-y] (. multifn preferMethod dispatch-val-x dispatch-val-y)) --~--~-~--~~~---~--~~ 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: Keyword constraints not enforced
On Nov 24, 2:26 pm, Rich Hickey [EMAIL PROTECTED] wrote: I think you've both misread they cannot name classes to be - They cannot contain class names. The symbol String can name a class but the keyword :String can't, that's all I meant there. Ah, I get it now. As far as '.', that restriction has been relaxed. I'll try to touch up the docs for the next release. Thanks! - James --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Working with trampoline and map
(declare a2) (defn a1 [x] #(vector :a (a2 x) :e)) (defn a2 [x] (if (coll? x) #(apply vector (map a1 x)) x)) (defn a [x] (trampoline a1 x)) (def b (a [[3 5] 1])) (println b) I'd like this program to print: [:a [[:a [[:a 3 :e] [:a 5 :e]] :e] [:a 1 :e]] :e]. Instead, it prints: [:a #core$a2__2636$fn__2638 clojure.core [EMAIL PROTECTED] :e] What must I change? --~--~-~--~~~---~--~~ 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 contrib testing, fix for macro?, did macro? ever work?
On Tue, Nov 25, 2008 at 7:28 PM, Stuart Halloway [EMAIL PROTECTED] wrote: (2) I am using git, and want to make sure my patches are usable here in an svn context. Let me know if this works, or what I need to change. Seems to work for me. (3) I have signed the CA. If you add me as a committer I will be well- behaved. Maybe even install svn. :-) Oh, please don't bother. git-svn works beautifully. --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: Exception reporting
On Nov 24, 7:38 am, Michael Wood [EMAIL PROTECTED] wrote: On Mon, Nov 24, 2008 at 4:45 PM, Stuart Sierra [EMAIL PROTECTED] wrote: If you're running this at the REPL, in recent versions only the name of the exception is printed. If you want the full backtrace, do: (.printStackTrace *e) That doesn't explain why the line number is listed as 0. Is that expected? The stack trace does not appear to be any more helpful anyway: user= (let [listener (new-listener )] (.accept listener)) java.lang.NullPointerException (NO_SOURCE_FILE:0) user= (.printStackTrace *e) java.lang.NullPointerException (NO_SOURCE_FILE:0) at clojure.lang.Compiler.eval(Compiler.java:4118) at clojure.lang.Repl.main(Repl.java:93) Caused by: java.lang.NullPointerException at clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:253) at user$eval__40.invoke(Unknown Source) at clojure.lang.Compiler.eval(Compiler.java:4107) ... 1 more nil -- Michael Wood [EMAIL PROTECTED] The reason the line number is 0 is the NPE happens in the REPL... (new- listener ) is not throwing the exception, it's just returning null. The NPE happens on the next line: (.accept listener) where listener is now set to null. Chris --~--~-~--~~~---~--~~ 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: Exception reporting
Hi On Wed, Nov 26, 2008 at 6:27 AM, Chris Turner [EMAIL PROTECTED] wrote: On Nov 24, 7:38 am, Michael Wood [EMAIL PROTECTED] wrote: On Mon, Nov 24, 2008 at 4:45 PM, Stuart Sierra [EMAIL PROTECTED] wrote: If you're running this at the REPL, in recent versions only the name of the exception is printed. If you want the full backtrace, do: (.printStackTrace *e) That doesn't explain why the line number is listed as 0. Is that expected? [...] The reason the line number is 0 is the NPE happens in the REPL... (new- listener ) is not throwing the exception, it's just returning null. The NPE happens on the next line: (.accept listener) where listener is now set to null. I still don't see why it's line 0 :) I realise that (new-listener) has nothing to do with it really and that it is the null pointer dereference that causes this, but surely it is not on NO_SOURCE_FILE:0. If this is expected on the REPL for some reason, then take a look at Timothy's original message in this thread. He was loading it from test.clj and the exception was reported on test.clj:0. On a related note, if I try to evaluate a nonexistent symbol at the REPL it always seems to report it as line 0, whereas if I try to evaluate a nonexistent function it is reported correctly: $ clj Clojure user= blah java.lang.Exception: Unable to resolve symbol: blah in this context (NO_SOURCE_FILE:0) user= blah java.lang.Exception: Unable to resolve symbol: blah in this context (NO_SOURCE_FILE:0) user= blah java.lang.Exception: Unable to resolve symbol: blah in this context (NO_SOURCE_FILE:0) user= (blah) java.lang.Exception: Unable to resolve symbol: blah in this context (NO_SOURCE_FILE:4) user= This is with r1121. -- 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 -~--~~~~--~~--~--~---
