Re: getting compiler-like meta data from read
the alternative is patching the java reader, which may not be too bad On Mon, Apr 19, 2010 at 4:30 PM, Kevin Livingston kevinlivingston.pub...@gmail.com wrote: Cool, thanks. Although, the clojure reader seems fine for what I need - i'd like to keep it as simple as possible. (the whole reason for doing this is to not have to write a parser for a whole new rule file format) I just wanted the extra meta data, if it was easy to grab. Seems like there could be an *attach-metadata* flag or something for calls to read - since there is clearly code that already exists that knows how to compute it. Kevin On Apr 19, 4:44 pm, Kevin Downey redc...@gmail.com wrote: if you really want I have a port of LispReader to clojure, it only adds metadata to list forms, like LispReader, but altering it should not be too hard. I haven't made any attempt to keep the reader up to date, but I don't believe LispReader is under going very many changes. http://github.com/hiredman/clojure/blob/readerII/src/clj/clojure/read... On Mon, Apr 19, 2010 at 11:43 AM, Kevin Livingston kevinlivingston.pub...@gmail.com wrote: SO as a complete hack to get file and line number metadata I implemented this macro, my file of rules is now just loaded with load- file and the rules that are define in it with RULE have the appropriate file and line associated with them. This is compete abuse of DEF and maybe the compiler (although it's not too dissimilar from very valid approaches in common lisp), but is this creating any ridiculous side effects that I should be aware of? is using the same symbol to def to over and over and over again bad? register rule is what takes care of putting the rule that was constructed where I need it to be. in common lisp I would use a progn here I used a let with no bindings, is there a better way in clojure? (defmacro RULE macro for creating an registering a rule [ params] ;; is there a way to do this without the let? this is progn? `(let [] ;;def is used as a hack to get file name and line number metadata ;; arguably instead of using a repeated symbol, rules could be ;; def'ed to their own name, except that would create a lot of vars ;; which likely are never needed and would waste memory? (def r# (verify-name (struct-map rule ~...@params))) ;; gets the metatdata from the var, but changes :name to rule's name (let [reg-r# (with-meta r# (assoc (meta (var r#)) :name (:name r#)))] (register-rule reg-r#) reg-r#))) On Apr 17, 10:48 am, Per Vognsen per.vogn...@gmail.com wrote: On Sat, Apr 17, 2010 at 2:29 AM, Kevin Livingston kevinlivingston.pub...@gmail.com wrote: I have an application that will read in a large number of structures from a file. those structures will be used throughout the application to produce additional data etc. since they are user configurable, it would be nice to know where they come from should one of them start misbehaving. the type of metadata the compiler associates with function definitions etc. would be very valuable. if I'm reading my structures in with (read) is there anyway to get it to attach filename and line-number etc. metadata? The reader doesn't do that but you can easily do it yourself if you only want to annotate top-level values. Thinking about this made me realize that it would be nice if the reader reentered itself (as it does in LispReader's readDelimitedList() and a few other contexts) through a var so it could be rebound by a programmer. Then you could inject your own line number annotation into the reader which would apply not only to top-level values (e.g. a vector literal) but also its subvalues (e.g. the elements of the vector literal). -Per -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated
Re: Event-handling and Clojure
You might want to check out this paper on a simple functional I/O system: http://www.ccs.neu.edu/scheme/pubs/icfp09-fffk.pdf The basic idea is really simple and natural. I've used something similar in my own past programs and I noticed that Penumbra has a GLUT-like event-driven interface that works along similar lines. -Per On Mon, Apr 19, 2010 at 2:45 PM, Chris Riddoch riddo...@gmail.com wrote: I'd like to call on the collective wisdom of the group to help me with a project I've come up with (partly) for the purpose of understanding Clojure's parallelism synchronization primitives. Imagine a library that both creates and accepts network sockets, acting like a simple proxy, forwarding data in both directions. It would provide hooks for intermediate processing of data in both directions. But don't just think web proxy -- my main purpose is to allow for better testing of *any* given networking protocol. Specifically, to log the interactions, replay either side of the communication to simulate any system too complicated to mock, do fuzz-testing in the middle of the stream for security testing... that sort of thing. (Simple protocol logging with timestamps is the first task I have in mind.) To better my understanding, I'd like to use a design that requires no explicit main event loop in my code, and exposes me to functional techniques. I suspect the result will look a little like the various libraries such as Ruby's IO::Reactor, Perl's POE, or Python's Twisted. But I also suspect that Clojure's unique features will make this a lot easier. Here's where I'm stuck: I don't quite understand how to use Clojure's parallelization and synchronization primitives for solving this kind of problem -- I understand the designs for ordinary servers quite a lot better than those for proxies. I'd appreciate pointers to documents about this, but I especially want to inspire some discussion of what would be idiomatic clojure for an event-driven asynchronous-I/O application like the one I'm describing. Please help me design! -- Chris Riddoch -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: getting compiler-like meta data from read
I've encountered the same problem (as far as I understood) in Fleet. My solution is http://github.com/Flamefork/fleet/blob/master/src/fleet/loader.clj#L55 There code comes from String, but you can use FileReader instead of StringReader. File path must be specified additionally, but this should be obvious. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: sharing multiple jogl opengl contexts in clojure
Right now it seems calling (.getContext (new GLCanvas)) returns nil Right. The context doesn't get set at construction, but will be set by the time the canvas gets passed to any of the GLEventListener methods. The Javadoc mentions that the underlying context may need to get created and destroyed multiple times as components get added and removed, but it seems to imply that the GLContext object itself provides a stable handle to whatever the current underlying context is. So you might be able to share them. Another possibility though is that you don't *need* to share them... and looking at what's in the one I get back, I notice that it has AWT window handles in its members, so maybe that's not intended after all. I'm curious in general how an OpenGL program should properly be written when dealing with multiple windows. So am I, now :) 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: sharing multiple jogl opengl contexts in clojure
Further, from the JOGL user guide: In the JSR-231 abstractions, a context is always associated with exactly one drawable. I guess that answers that question. So, while we certainly might want to share some of our GLish state between windows, the Context is not the right vehicle... 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Beginners question about Don't know how to create ISeq from: Symbol
Tanks, i was total focus on the (make-lotto), // Anders On 20 Apr, 02:53, Michael Gardner gardne...@gmail.com wrote: On Apr 19, 2010, at 4:52 PM, uap12 wrote: (defn -main (make-lotto)) ([] (-main ))) You're missing the empty arglist in your definition of -main. It should be: (defn -main [] (make-lotto)) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: (- x 1) and (dec x) behave differently
Thanks Per, This definitely works Try (loop [x (. 1 longValue)] (if (= 0 x) x (recur (- x (long 1). but from my understanding of clojure internals clojure.lang.Numbers should take care of that. Since one of the arguments of '-' is a long a LongOps should do the minus and return a long. Which leads me to the ask why the first version doesn't work when it should. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
copious FAIL when building clojure-contrib HEAD
greetings! This is a follow-up to my posts form this past weekend [1], where it seemed as if the problem were solved (on my mac, at least.) Now that I'm back on my netbooks and quad-core desktop (all various flavors of ubuntu), I'm finding I can't actually build clojure-contrib 1.2.x *at all*. I'm at my wits end! I've tried building current clojure-contrib head against the last 59 revisions of clojure master and every single one fails the build. Am I doing something wrong? Is there a known bug in the linux JVMs? Is anyone else seeing this? I've attached the output I'm seeing bzip2 compressed as it's voluminous but repetitive. I'll include a sample inline. The script I am using to reproduce this inline. [1] http://groups.google.at/group/clojure/browse_thread/thread/1830a793986c4935?hl=de# // Ben - sample output -- ERROR in (complex-sqrt) (run-test54346.clj:44) Uncaught exception, not in assertion. expected: nil actual: java.lang.IllegalArgumentException: No method in multimethod 'sqrt' for dispatch value: :clojure.contrib.complex-numbers/complex at clojure.lang.MultiFn.getFn (MultiFn.java:115) clojure.lang.MultiFn.invoke (MultiFn.java:157) clojure.contrib.test_complex_numbers/fn (test_complex_numbers.clj:291) clojure.test$test_var__6824$fn__6825.invoke (test.clj:644) clojure.test/test_var (test.clj:644) clojure.test$test_all_vars__6829$fn__6830$fn__6837.invoke (test.clj:659) clojure.test/default_fixture (test.clj:617) clojure.test$test_all_vars__6829$fn__6830.invoke (test.clj:659) clojure.test/default_fixture (test.clj:617) clojure.test/test_all_vars (test.clj:655) clojure.test/test_ns (test.clj:677) clojure.core$map__4099$fn__4100.invoke (core.clj:1870) clojure.lang.LazySeq.sval (LazySeq.java:42) clojure.lang.LazySeq.seq (LazySeq.java:56) clojure.lang.Cons.next (Cons.java:37) clojure.lang.RT.next (RT.java:540) clojure.core/next (core.clj:54) clojure.core/reduce (core.clj:707) clojure.core/reduce (core.clj:698) clojure.core$merge_with__4189.doInvoke (core.clj:2046) clojure.lang.RestFn.applyTo (RestFn.java:140) clojure.core/apply (core.clj:480) clojure.test$run_tests__6846.doInvoke (test.clj:691) clojure.lang.RestFn.invoke (RestFn.java:1261) user$eval__12092$fn__12095.invoke (run-test54346.clj:46) user/eval (run-test54346.clj:44) clojure.lang.Compiler.eval (Compiler.java:5325) clojure.lang.Compiler.load (Compiler.java:5736) clojure.lang.Compiler.loadFile (Compiler.java:5699) clojure.main/load_script (main.clj:213) clojure.main/script_opt (main.clj:265) clojure.main$main__6299.doInvoke (main.clj:346) clojure.lang.RestFn.invoke (RestFn.java:409) clojure.lang.Var.invoke (Var.java:365) clojure.lang.AFn.applyToHelper (AFn.java:165) clojure.lang.Var.applyTo (Var.java:482) clojure.main.main (main.java:37) FAIL in (complex-conjugate) (run-test54346.clj:44) expected: (= (conjugate (complex 1 2)) (complex 1 -2)) actual: false - reproduce.sh -- #!/bin/bash set -x ( ant -version mvn --version uname -a REALLY_BLOW_AWAY_M2_REPOSITORY=$1 if [[ $REALLY_BLOW_AWAY_M2_REPOSITORY == BLOW_AWAY_M2 ]] then rm -rf ~/.m2/repository fi tmp=/tmp/bsmith.occs.$RANDOM mkdir $tmp cd $tmp git clone git://github.com/richhickey/clojure.git pushd clojure git log HEAD^..HEAD ant CLOJURE=$PWD/clojure.jar popd git clone git://github.com/richhickey/clojure-contrib.git pushd clojure-contrib git log HEAD..HEAD^ mvn -e -Dclojure.jar=$CLOJURE dependency:tree |\ fgrep -e [INFO] [dependency:tree -B1 -A3 mvn -e -Dclojure.jar=$CLOJURE package popd ) 21 | tee reproduce-output.txt - end reproduce.sh -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en reproduce-output.txt.bz2 Description: BZip2 compressed data
Re: (- x 1) and (dec x) behave differently
On Tue, Apr 20, 2010 at 6:43 PM, jvshahid jvsha...@gmail.com wrote:
Thanks Per,
This definitely works
Try (loop [x (. 1 longValue)] (if (= 0 x) x (recur (- x (long 1).
but from my understanding of clojure internals clojure.lang.Numbers
should take care of that.
The Numbers class doesn't do any fancy dispatching for primitive
types. You can see there are direct static methods for the arithmetic
operations on primitive types like longs, floats, etc:
static public long add(long x, long y){
long ret = x + y;
if ((ret ^ x) 0 (ret ^ y) 0)
return throwIntOverflow();
return ret;
}
Then there is a catch-all implementation for Object which double
dispatches on the dynamic types of the operands to determine the right
Ops implementation. It then delegates all the real work to that:
static public Number add(Object x, Object y){
return ops(x).combine(ops(y)).add((Number)x, (Number)y);
}
With the way primitive types are currently supported in the compiler,
if you wanted it to work the way you expect, you'd need to express the
complicated arithmetic tower and its grid of type conversions in a
static form accessible to the compiler. It seems like it would be a
good amount of work. You can file a feature request for it if you
want.
-Per
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Clojure job opportunity at Bangalore
Hi, Vipashyin Labs (at Marathalli, Bangalore) is looking for a fulltime Clojure developer. This is a long term contract position (1+ year) with attractive remuneration. The candidate should be well versed in Clojure, JVM, web development and REST. If interested, please contact at the email address below: Harsha Konduri har...@vipashyin.com Regards, Shantanu -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: (- x 1) and (dec x) behave differently
On Tue, Apr 20, 2010 at 7:02 PM, Per Vognsen per.vogn...@gmail.com wrote:
With the way primitive types are currently supported in the compiler,
if you wanted it to work the way you expect, you'd need to express the
complicated arithmetic tower and its grid of type conversions in a
static form accessible to the compiler. It seems like it would be a
good amount of work. You can file a feature request for it if you
want.
Actually, a less elegant, more brute force way would be to add method
implementations for all operand type combinations. For example, you'd
have
static public long add(long x, int y){
return add(x, (long) y);
}
static public long add(int x, long y){
return add((long) x, y);
}
and so on.
Unfortunately, there are a whole lot of combinations if you want to
cover the whole arithmetic tower. The issue is that the current
primitive type support relies directly on Java's type system, so you
cannot abstractly express the pattern underlying the arithmetic tower
like you might in some languages with type-level functions.
-Per
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: (- x 1) and (dec x) behave differently
Again thanks a lot for your patience and help.
My problem was that I thought the literal 1 will be boxed behind the
scenes, I didn't even bother looking for a version of add for
primitives because I thought they never existed in Clojure.
I'll try to go over the Numbers class again and see if all this makes
sense.
- John
On Apr 20, 8:10 am, Per Vognsen per.vogn...@gmail.com wrote:
On Tue, Apr 20, 2010 at 7:02 PM, Per Vognsen per.vogn...@gmail.com wrote:
With the way primitive types are currently supported in the compiler,
if you wanted it to work the way you expect, you'd need to express the
complicated arithmetic tower and its grid of type conversions in a
static form accessible to the compiler. It seems like it would be a
good amount of work. You can file a feature request for it if you
want.
Actually, a less elegant, more brute force way would be to add method
implementations for all operand type combinations. For example, you'd
have
static public long add(long x, int y){
return add(x, (long) y);
}
static public long add(int x, long y){
return add((long) x, y);
}
and so on.
Unfortunately, there are a whole lot of combinations if you want to
cover the whole arithmetic tower. The issue is that the current
primitive type support relies directly on Java's type system, so you
cannot abstractly express the pattern underlying the arithmetic tower
like you might in some languages with type-level functions.
-Per
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group
athttp://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: copious FAIL when building clojure-contrib HEAD
You're not alone. I see the very same thing. Quad core, Ubuntu 10.04, Linux 2.6.32-21-generic java version 1.6.0_18 OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8-0ubuntu1) OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Concurrency Screencast Available
Craig, I enjoyed you presentations, but I have a bit of a tangent question. I'm still new to slime, so it's not a comfortable environment for me yet. What I am wondering is how exactly, when operating with the split code and repl buffers, you are getting code buffer expressions to evaluate in the repl? Is this a customization, or am I missing something basic? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: (- x 1) and (dec x) behave differently
My problem was that I thought the literal 1 will be boxed behind the
scenes, I didn't even bother looking for a version of add for
primitives because I thought they never existed in Clojure.
I'll try to go over the Numbers class again and see if all this makes
sense.
Looks like the compiler is enforcing that loop arguments match the
primitive type of the local bindings; if they do, it'll emit code with
unboxed primitives.
if(lb.getPrimitiveType() != null)
{
Class primc = lb.getPrimitiveType();
try
{
if(!(arg instanceof MaybePrimitiveExpr arg.hasJavaClass()
arg.getJavaClass() == primc))
throw new IllegalArgumentException(recur arg for
primitive local: +
lb.name + must be matching primitive);
}
catch(Exception e)
{
throw new RuntimeException(e);
}
((MaybePrimitiveExpr) arg).emitUnboxed(C.EXPRESSION, objx, gen);
}
else
{
arg.emit(C.EXPRESSION, objx, gen);
}
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
clojure.contrib.sql insert id
Hello, I'm using clojure.contrib.sql/insert-records to add data to a database. I've hit a problem where I am unable to get the autogenerated IDs of the records that I have inserted. I believe in JDBC this is normally done with statement_handle.getGeneratedKeys(). Unfortunately, as far as I can see, the statement handle is unavailable to the users of clojure.contrib.sql. Has anyone else had this problem? Saul Hazledine -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Concurrency Screencast Available
On Tue, 20 Apr 2010 06:47:05 -0700 (PDT) Mark Hamstra markhams...@gmail.com wrote: Craig, I'm not Craig, but he's not answered yet, so... I enjoyed you presentations, but I have a bit of a tangent question. I'm still new to slime, so it's not a comfortable environment for me yet. What I am wondering is how exactly, when operating with the split code and repl buffers, you are getting code buffer expressions to evaluate in the repl? Is this a customization, or am I missing something basic? This is pretty basic. There are commands for sending various bits of code from the code buffer to REPL. They are a standard part of slime, not clojure-specific. Most useful to me are C-M-x, which ships the def around the point to the repl, and C-c C-r, which evaluates the active region. Others can be found with C-h M in the code buffer, which brings up the documentation for the buffer mode. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Concurrency Screencast Available
I enjoyed you presentations, but I have a bit of a tangent question. I'm still new to slime, so it's not a comfortable environment for me yet. What I am wondering is how exactly, when operating with the split code and repl buffers, you are getting code buffer expressions to evaluate in the repl? Is this a customization, or am I missing something basic? This is pretty basic. There are commands for sending various bits of code from the code buffer to REPL. They are a standard part of slime, not clojure-specific. Most useful to me are C-M-x, which ships the def around the point to the repl, and C-c C-r, which evaluates the active region. Others can be found with C-h M in the code buffer, which brings up the documentation for the buffer mode. Yep: that's good advice, although I can't say I find much in emacs to be basic, even after using it casually for 20 years :). The one I tended to use in the tutorial (in case someone saw it flash by in the minibuffer) is C-x C-e, which I have bound to lisp-eval-last-sexp, and that is a custom binding. Something from Scheme-based muscle memory a million years ago. In addition to checking out C-h m (which is a great way to learn keystrokes in emacs), you can also use the menu bar. If it's not enabled, just do M-x menu-bar-mode, and you should see the menu bar appear with a SLIME menu item. Pop it down and you'll see all sorts of goodness with the keybindings listed as well. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Concurrency Screencast Available
On 20 April 2010 15:41, Craig Andera craig.and...@gmail.com wrote: Yep: that's good advice, although I can't say I find much in emacs to be basic, even after using it casually for 20 years :). The one I tended to use in the tutorial (in case someone saw it flash by in the minibuffer) is C-x C-e, which I have bound to lisp-eval-last-sexp, and that is a custom binding. Something from Scheme-based muscle memory a million years ago. C-x C-e is by default bound to eval-last-sexp in emacs and to slime-eval-last-expression in a slime enabled buffers (e.g. a clojure-mode buffer with the slime minor mode enabled). That is, it should work out of the box for everyone using slime. Another common default key binding is C-c C-k (slime-compile-and-load) which will load all of the current clojure-mode buffer. Out of all of these bindings, C-M-x is IMHO the most useful one (funnily enough I didn't know about it!). C-x C-e requires you to be at the end of a form to be useful. And C-c C-k loads everything even when you only need one form to be updated. -- ! 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
ANN: clj-base64
A very basic library of functions for encoding and decoding strings (sequences of characters) using the base64 coding scheme. Code: http://github.com/remvee/clj-base64 Clojars: http://clojars.org/clj-base64 Lein it up with: [clj-base64 0.0.0-SNAPSHOT] Usefulness: network protocol related License: Eclipse Public License 1.0 Enjoy, Remco -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: copious FAIL when building clojure-contrib HEAD
Try Rich's commit 1b8d5001ba094053b24c55829994785be422cfbf For me, he's fixed the build problem. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: sharing multiple jogl opengl contexts in clojure
I found this code some code that supposedly works for creating a context that can be shared for multiple panels http://www.javagaming.org/index.php/topic,19911.0.html I can't seem to get a pbuffer create. I believe I'm using the correct Clojure syntax for these static methods (pasted below). It could be a JOGL issue, I guess, as the API has changed quite a bit recently and the documentation is still pretty bad. GLPBuffer sharedPBuffer = GLDrawableFactory.createGLPbuffer(...,1,1, null); new GLJPanel(...,sharedPBuffer.getContext()); new GLCanvas(...,sharedPBuffer.getContext()); But I can't seem to call createGLPbuffer w/o getting an exception. (if (not gl-canvas-context) (let [sharedPbuffer (GLDrawableFactory/createGLPbuffer nil nil 1 1 nil)] (.paint sharedPbuffer) (println (.getContext sharedPbuffer Caused by: java.lang.IllegalArgumentException: No matching method: createGLPbuffer at clojure.lang.Compiler$StaticMethodExpr.init(Compiler.java:1255) at clojure.lang.Compiler$HostExpr$Parser.parse(Compiler.java:763) at clojure.lang.Compiler.analyzeSeq(Compiler.java:4496) ... 45 more I've tried this to get a suitable factory if that's required, but that doesn't seem to work either. (let [factory (GLDrawableFactory/getFactory GLProfile/GL2)] (println factory)) Exception in thread Main Thread java.lang.ClassCastException: java.lang.String (start.clj:0) at clojure.lang.Compiler.eval(Compiler.java:4543) at clojure.lang.Compiler.load(Compiler.java:4857) at clojure.lang.Compiler.loadFile(Compiler.java:4824) at clojure.main$load_script__5833.invoke(main.clj:206) at clojure.main$script_opt__5864.invoke(main.clj:258) at clojure.main$main__5888.doInvoke(main.clj:333) at clojure.lang.RestFn.invoke(RestFn.java:413) at clojure.lang.Var.invoke(Var.java:346) at clojure.lang.AFn.applyToHelper(AFn.java:173) at clojure.lang.Var.applyTo(Var.java:463) at clojure.main.main(main.java:39) Caused by: java.lang.ClassCastException: java.lang.String at user$add_canvas__31.invoke(ui.clj:19) at user$eval__123.invoke(start.clj:12) at clojure.lang.Compiler.eval(Compiler.java:4532) ... 10 more On Tue, Apr 20, 2010 at 2:11 AM, Joel Gluth joel.gl...@gmail.com wrote: Further, from the JOGL user guide: In the JSR-231 abstractions, a context is always associated with exactly one drawable. I guess that answers that question. So, while we certainly might want to share some of our GLish state between windows, the Context is not the right vehicle... 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: copious FAIL when building clojure-contrib HEAD
B Smith-Mannschott bsmith.o...@gmail.com writes: expected: nil actual: java.lang.IllegalArgumentException: No method in multimethod 'sqrt' for dispatch value: :clojure.contrib.complex-numbers/complex Just thought I'd expand on what the problem was. I was able to reproduce this on an older Linux machine and narrowed it down to being triggered by clojure.contrib.test-load-all reloading all the namespaces. Then Rich spotted the actual cause: test-load-all uses a hash set to store the namespaces. The ordering imposed by the set's hash function can, it seems, vary in different environments, so on some machines the complex-numbers namespace would be reloaded before generic.math-functions, which meant the sqrt multimethod would lose the method for complex numbers, hence the above exception. As Mark mentioned Rich has committed a change to defmulti so that multimethods can only be defined once. (This just affects defmulti, not defmethod). http://github.com/richhickey/clojure/commit/1b8d5 This makes reloading namespaces safer, but there's a subtle change for interactive development. To clear a multimethod you now need to explicitly call the (newly added) remove-all-methods function. To actually redefine it and change the dispatch function you have to unmap it or def it to something else, before calling defmulti again, eg: (defmulti foo :a) (ns-unmap *ns* 'foo) (defmulti foo :b) or (defmulti foo :a) (def foo nil) (defmulti foo :b) -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: (- x 1) and (dec x) behave differently
On Tue, Apr 20, 2010 at 04:43:13AM -0700, jvshahid wrote: Thanks Per, This definitely works Try (loop [x (. 1 longValue)] (if (= 0 x) x (recur (- x (long 1). but from my understanding of clojure internals clojure.lang.Numbers should take care of that. Since one of the arguments of '-' is a long a LongOps should do the minus and return a long. Which leads me to the ask why the first version doesn't work when it should. I think that the problem is that in (- x 1), even though x is a primitive long, 1 is an Integer (non-primitive). That is why you are able to do (. 1 longValue), it treats 1 as an Integer object. Therefore, x is boxed into a Long (non-primitive) and 1 is promoted to a Long. So, the result of the operation is a Long. However, in the loop/recur you have created, the x in loop is a primitive, and recur is unable to automatically unbox the Long into a long. On the other hand (dec x) only has one argument, a long. So, I am guessing that dec has the ability to decrement a primitive without any boxing, so it naturally returns a primitive long. In most Clojure code that depends on retaining primitives, numeric constants are coerced into primitives, like (int 1). Sincerely, Daniel Solano Gómez pgpGy8AxHEMJE.pgp Description: PGP signature
Re: copious FAIL when building clojure-contrib HEAD
Mark, Alex, and especially Rich: thanks for the help, explanation and quick fix! Works great. // Ben -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: (- x 1) and (dec x) behave differently
Yup, you're definitely right Daniel. Everyone's comment on the subject was very helpful and gave us all insight into the internals of Clojure. I guess the key points to learn in our case is: 1- Clojure supports primitives, but only when you ask for them (by casting) 2- Clojure cannot unbox the boxed recur arguments which causes a problem when the arguments of loop are primitive. This looks like a bug to me. The code posted by Armando can be expanded to include boxed versions of primitive types, why the code doesn't include such a check ? Will Clojure's class hierarchy be a blocker ? Again, I'm fairly new to Clojure and cannot answer these questions. I'm only throwing them at you guys hoping someone will clarify them. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure unifier (also other symbolic reasoning support including rdf/owl/etc. ?)
Thanks Jim, I'll definitely keep this in mind, I appreciate it. This seems mostly like a tool for constraint satisfaction, which I've been keeping my eyes on, but don't use as much as more 'open world' reasoning, back-chaining, and pattern matching etc. (which is why I was looking for a unifier) There are some problem I have for which your type of constraint logic may help me. I did port Norvig's unifier, although I'm not convinced I did it with good clojure code, it's here, I'm hoping to get some feedback: http://groups.google.com/group/clojure/browse_thread/thread/996ecadf98328c6b# Kevin On Apr 19, 8:16 am, jim jim.d...@gmail.com wrote: Lack of coffee this morning. :) Tryhttp://intensivesystems.net/tutorials/logic_prog.html On Apr 19, 9:05 am, Meikel Brandmeyer m...@kotka.de wrote: Check out file:///home/jim/logic-prog.html 404 ;P -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: clojure.contrib.sql insert id
I am doing the following after an insert for a Derby database: (sql/with-query-results res [VALUES IDENTITY_VAL_LOCAL()] (first (vals (first res For MySQL it would be something like: (sql/with-query-results res [SELECT LAST_INSERT_ID()] (first (vals (first res I am not sure if it's actually safe to do it this way, considering connection pooling etc. It sure is ugly.. Saul Hazledine shaz...@gmail.com writes: Hello, I'm using clojure.contrib.sql/insert-records to add data to a database. I've hit a problem where I am unable to get the autogenerated IDs of the records that I have inserted. I believe in JDBC this is normally done with statement_handle.getGeneratedKeys(). Unfortunately, as far as I can see, the statement handle is unavailable to the users of clojure.contrib.sql. Has anyone else had this problem? Saul Hazledine -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
deftype feature or bug?
Hello group, I am working with edge Clojure and, as of today, noticed that deftype's behavior has changed (which is expected as it is still alpha). The version in question is: clojure-1.2.0-master-20100420.150114-37.jar Here is my REPL interaction which demonstrates the difference: user (defprotocol HelloWorld (say-hello [this])) HelloWorld user (deftype HelloJoe [] HelloWorld (say-hello [this] Hello Joe)) user.HelloJoe user (def hello (HelloJoe)) ; Evaluation aborted Expecting var, but HelloJoe is mapped to class user.HelloJoe user (def hello (user.HelloJoe.)) user (say-hello hello) Hello Joe Before today (def hello (HelloJoe)) would not cause an error. Is this a bug or a new feature of deftype? Thanks, Brenton -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: deftype feature or bug?
On Tue, Apr 20, 2010 at 3:09 PM, Brenton bashw...@gmail.com wrote: Hello group, I am working with edge Clojure and, as of today, noticed that deftype's behavior has changed (which is expected as it is still alpha). The version in question is: clojure-1.2.0-master-20100420.150114-37.jar Here is my REPL interaction which demonstrates the difference: user (defprotocol HelloWorld (say-hello [this])) HelloWorld user (deftype HelloJoe [] HelloWorld (say-hello [this] Hello Joe)) user.HelloJoe user (def hello (HelloJoe)) ; Evaluation aborted Expecting var, but HelloJoe is mapped to class user.HelloJoe user (def hello (user.HelloJoe.)) user (say-hello hello) Hello Joe Before today (def hello (HelloJoe)) would not cause an error. Is this a bug or a new feature of deftype? feature. deftype creates a Java class. Thanks, Brenton -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: version compatibility between clojure and clojure-contrib
On Apr 20, 2010, at 4:01 , John Sanda wrote: I am working with a simple leiningen project with the build defined as follows,' ; project.clj (defproject myproject 1.0.0-SNAPSHOT :description FIXME: write :dependencies [[org.clojure/clojure 1.2.0-master-SNAPSHOT] [org.clojure/clojure-contrib 1.2.0-SNAPSHOT]]) I am running the repl via lein repl and I am trying to use clojure.contrib.string. The docs at http://richhickey.github.com/clojure-contrib/string-api.html suggest using require. I have run into the following though, Hi John, you fell for the lein repl version problem. lein repl (in the current version) runs the clojure version that lein uses not the one your project uses. I take the freedome to quote technomancy who I oddly enough just talked about this: Licenser:The thing that I look forward most is when lein starts using the 'correct' version of clojure [21:46]technomancy:you can have that now if you manually apply the #299 clojure patch and use the repl-fix branch Best regards, Heinz -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: version compatibility between clojure and clojure-contrib
On Tue, Apr 20, 2010 at 12:50 PM, Heinz N. Gies he...@licenser.net wrote: On Apr 20, 2010, at 4:01 , John Sanda wrote: I am working with a simple leiningen project with the build defined as follows,' ; project.clj (defproject myproject 1.0.0-SNAPSHOT :description FIXME: write :dependencies [[org.clojure/clojure 1.2.0-master-SNAPSHOT] [org.clojure/clojure-contrib 1.2.0-SNAPSHOT]]) I am running the repl via lein repl and I am trying to use clojure.contrib.string. The docs at http://richhickey.github.com/clojure-contrib/string-api.html suggest using require. I have run into the following though, Hi John, you fell for the lein repl version problem. lein repl (in the current version) runs the clojure version that lein uses not the one your project uses. I take the freedome to quote technomancy who I oddly enough just talked about this: Licenser:The thing that I look forward most is when lein starts using the 'correct' version of clojure [21:46]technomancy:you can have that now if you manually apply the #299 clojure patch and use the repl-fix branch In the mean time if you use the lein-swank or lein-nailgun plugins you will not be affected by this bug. Looking forward to getting it fixed in Clojure though. -Phil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: binary structures/bitstrings
After looking through the code and tests, it looks like *exactly* what I'll need and I doubt I'll need/want to change anything. Thanks for the docs as well - it's nice to see code that looks like it was written like you meant it :). I'll probably use clojure to build my prototype (with all 8.5 seconds of free time I have), and if I come up with any feedback or contributions, I'll let you know. -Scott On Apr 19, 8:52 pm, Scott T scott.tho...@gmail.com wrote: Thanks a lot for pulling that out. I'll let you know how it goes. -Scott On Apr 19, 1:40 am, Geoff geoff.sal...@gmail.com wrote: I've pushed the bytebuffer stuff into it's own repo and project and cleaned up the documentation a bit. Seehttp://github.com/geoffsalmon/bytebuffer I'd appreciate any feedback you have after trying it out. - Geoff -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: (- x 1) and (dec x) behave differently
On 20 April 2010 19:33, John jvsha...@gmail.com wrote: 2- Clojure cannot unbox the boxed recur arguments which causes a problem when the arguments of loop are primitive. This looks like a bug to me. The code posted by Armando can be expanded to include boxed versions of primitive types, why the code doesn't include such a check ? Will Clojure's class hierarchy be a blocker ? If I correctly understand your meaning, I'm inclined to view this behaviour as a feature. Simply because the whole point of having unboxed primitives in loop bindings seems to be defeated if they're going to be boxed/unboxed at each iteration due to some operation stealthily boxing the new values passed to recur -- so if I do write some code which performs unexpected boxing, I'd rather be warned about it. Sincerely, Michał -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: (- x 1) and (dec x) behave differently
On Apr 20, 2010, at 1:33 PM, John wrote: Yup, you're definitely right Daniel. Everyone's comment on the subject was very helpful and gave us all insight into the internals of Clojure. I guess the key points to learn in our case is: 1- Clojure supports primitives, but only when you ask for them (by casting) 2- Clojure cannot unbox the boxed recur arguments which causes a problem when the arguments of loop are primitive. This looks like a bug to me. The code posted by Armando can be expanded to include boxed versions of primitive types, why the code doesn't include such a check ? Will Clojure's class hierarchy be a blocker ? Again, I'm fairly new to Clojure and cannot answer these questions. I'm only throwing them at you guys hoping someone will clarify them. Clojure could of course auto-unbox on recur to primitive local, but it doesn't, for a reason. If you are using primitive locals it is because you are looking for the speed of primitive operations. If by the point you recur you have a boxed number, you have made a mistake somewhere in preserving primitive ops. Were the compiler to auto-unbox, you'd never find out. So, should you get this error, you can't ignore it, and you definitely shouldn't just add a coercion in recur. Instead, find the spot where you lost primitiveness and fix it. 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: (- x 1) and (dec x) behave differently
Clojure could of course auto-unbox on recur to primitive local, but it doesn't, for a reason. If you are using primitive locals it is because you are looking for the speed of primitive operations That's the answer I was looking for. It is just confusing because it is mentioned everywhere that Clojure uses boxed version of primitives. The reason I got into this was converting a rational (or ratio) to long in order to mimic Java's division operator. It is just a tough experience on my first encounter to Clojure, I just couldn't figure out what's wrong in my code. My suggestion would be to print a detailed solution to the problem along with the exception message, or may be document it somewhere. The mere existence of unboxed primitives was a surprise to me. I believe a lot of newbies will try to do something similar to what I was doing and will fail. Thanks for everyone's effort and patience. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
default maps with the :or keyword in parameters - bug? / feature request
So it would strike me that with-defaults-bad (below) is a fairly
straightforward way of using destructuring in Clojure yet it can't be
done, instead of passing the same map in that's being destrucured you
need a new type that has keys being the variable names instead of
keys being keywords... it would seem when using the :keys keyword
this shouldn't be necessary.
(defstruct params :x :y)
(def defaults (struct-map params :x 1 :y 2))
(defn no-defaults [{:keys [x y]}]
(list x y))
;since this is thing that's being destructed, I'd like to provide one
as default
; but this won't work because the :or expects the var names not the
keys
(defn with-defaults-bad [{:keys [x y] :or defaults}]
(list x y))
;note the absence of colons on the defaults matching the variables not
keys
; but now I can't use my nice structure as a default
(defn with-defaults-good [{:keys [x y] :or {x 1 y 2}}]
(list x y))
user (no-defaults defaults)
(1 2)
user (with-defaults-bad {:x 4 :y 5})
(4 5)
user (with-defaults-bad {:x 4})
(4 nil)
user (with-defaults-good {})
(1 2)
user (with-defaults-good {:x 4})
(4 2)
minimally in the presence of the :keys feature in the paramaters it
would be nice if with-defaults-bad worked. although there are other
ways to work around this - this way just seems cleaner
also presumably the value of all defaults is evaluated at call time,
right?
Kevin
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: request for comments/code-review - clojure implementation of unifier
On 19 April 2010 20:34, Kevin Livingston kevinlivingston.pub...@gmail.com wrote: I ported the unifier posted by Norvig in Common Lisp to Clojure... Cool! Before I comment on a few specific points you make / questions you ask, here are the results of a few minutes I spent playing with / rewriting your code: http://gist.github.com/373303 major questions 1. this is ugly: (and (seq? x) (not (empty? x))) in common lisp you just use consp is there no equivalent in clojure? there is (seq x) but that barfs if it's given a symbol. The loss of the cleanness of iterating/recursing until you hit nil is unfortunate (it made for some elegant lisp code) I can't think of a direct equivalent now, but it's straightforward enough to supply your own equivalent, like my compound? function (basically #(and (seq? %) (seq %))). This won't work on arrays and other things which seq can operate upon, but which respond with a false to seq?, though. If that could be a problem, you can just use seq and for non-seqables catch the exception and return false. 2. there are self calls and mutual calls throughout - which could create a stack problem. advice for how to get around this? specifically calls like the following seem hard to fix, or at least I don't know the duh way to do it (I always just let my lisp compiler do all the work for me) You could perform a CPS transform by hand (which I haven't (yet) done with the code in the Gist). For occurs-check this would mean having an extra to-do argument (or maybe just [... to-do]); whenever false would normally be returned, you'd first check if to-do is empty, returning false if so and doing (recur args taken from (first to-do) (rest to-do)) otherwise. true should short-circuit and disregard to-do, of course. Finally, whenever occurs-check would normally branch on first / rest, it would recur with first *and* an extended to-do including rest. 2'. I'm to understand that next is now preferred to rest? (which is an unfortunate name at least for my lisp mind, since it seems like it should be returning an element instead of rest - but I'll learn eventually) Not at all. next is basically #(seq (rest %)); you might want to use it when the extra bit of strictness is beneficial to your code and you shouldn't use it when it isn't. minor questions: a. what's the preferred indenting style for cond? Good question. I really prefer the fully parenthesised cond clauses from Scheme / CL / elisp, in good part because of the nicer indentation without particularly elaborate rules... :-( b. is def the correct way to introduce constants and thread safe places to bind over? c. is that the correct / best / preferred way to set default values for the optional parameter in unify? If you expect to want / need to replace the default occasionally, then sure, you could do it with a Var and (binding [...] ...). On the other hand, unify already accepts a bindings parameter, so you could just as well pass in an explicit starting value when you need to. I think that your code would benefit from direct use of Clojure data structure literals and such facilities as the IFn implementation available on maps; see my gist for examples of what I have in mind. Sincerely, Michał -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: version compatibility between clojure and clojure-contrib
#299 has been applied in master. Stu On Tue, Apr 20, 2010 at 12:50 PM, Heinz N. Gies he...@licenser.net wrote: On Apr 20, 2010, at 4:01 , John Sanda wrote: I am working with a simple leiningen project with the build defined as follows,' ; project.clj (defproject myproject 1.0.0-SNAPSHOT :description FIXME: write :dependencies [[org.clojure/clojure 1.2.0-master-SNAPSHOT] [org.clojure/clojure-contrib 1.2.0-SNAPSHOT]]) I am running the repl via lein repl and I am trying to use clojure.contrib.string. The docs at http://richhickey.github.com/clojure-contrib/string-api.html suggest using require. I have run into the following though, Hi John, you fell for the lein repl version problem. lein repl (in the current version) runs the clojure version that lein uses not the one your project uses. I take the freedome to quote technomancy who I oddly enough just talked about this: Licenser:The thing that I look forward most is when lein starts using the 'correct' version of clojure [21:46]technomancy:you can have that now if you manually apply the #299 clojure patch and use the repl-fix branch In the mean time if you use the lein-swank or lein-nailgun plugins you will not be affected by this bug. Looking forward to getting it fixed in Clojure though. -Phil -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: version compatibility between clojure and clojure-contrib
Thanks for seeing that through! -Phil On Apr 20, 2010 7:16 PM, Stuart Halloway stuart.hallo...@gmail.com wrote: #299 has been applied in master. Stu On Tue, Apr 20, 2010 at 12:50 PM, Heinz N. Gies he...@licenser.net wrote: On Apr 20, 2010,... -- You received this message because you are subscribed to the Google Groups Clojure group -- You received this message because you are subscribed to the Google Groups Clojure group. To ... -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
