Re: Generic functions again
On Tue, Mar 24, 2009 at 5:37 PM, Meikel Brandmeyer m...@kotka.de wrote: Hi, Am 24.03.2009 um 22:36 schrieb mikel: CLOS says that if two matches are otherwise equally specific, the one on the left wins. Similarly, it says that if two classes define slots with the same name, the one farthest from the root of the class heterarchy (as defined by a standard traversal algorithm) wins. You can make a theoretical argument that these choices are arbitrary, and that the programmer should control those decisions. In practice, the CLOS approach is not a problem because: Thank you for the long explanation. Please allow me to be sceptical (fatigued and after all long day of work). CLOS is certainly a powerful system, but reading these rules makes me headaches. Interestingly enough the rules described above seem to be exactly how multiple inheritance works in Python, and they seem to me pretty easy to understand. Imagine that you specify interfaces left to right in order of importance, and therefore when a generic function is defined for two of them the leftmost one wins. Should you happen not to remember though you can quickly try out an example at the REPL. I do that all the time in Python when I want to verify that what I remember is in fact correct. -- Cosmin Stejerean http://offbytwo.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Running multiple scripts from the Java realm
I know it isn't advised but I have my various reasons.
What are some of the best ways to invoke clojure scripts from Java but
still maintain the state of the current session.
For example, if I run a script from Java, is there a way to ensure
that script has already been run...say if I run another script.
I was doing the following.
--
package test.toolkit.clojure;
import clojure.lang.Namespace;
import clojure.lang.RT;
import clojure.lang.Symbol;
import clojure.lang.Var;
public class TestSpringLoadClojure {
final static private Symbol CLOJURE_MAIN = Symbol.create
(clojure.main);
final static private Namespace CLOJURE_MAIN_NS =
Namespace.findOrCreate(CLOJURE_MAIN);
final static private Var REQUIRE = Var.intern(RT.CLOJURE_NS,
Symbol.create(require));
final static private Var LEGACY_REPL = Var.intern(CLOJURE_MAIN_NS,
Symbol.create(legacy-repl));
final static private Var LEGACY_SCRIPT = Var.intern(CLOJURE_MAIN_NS,
Symbol.create(legacy-script));
final static private Var MAIN = Var.intern(CLOJURE_MAIN_NS,
Symbol.create(main));
private static void legacy_script(String[] args) throws Exception {
REQUIRE.invoke(CLOJURE_MAIN);
LEGACY_SCRIPT.invoke(RT.seq(args));
}
private static void invoke_script(String[] args) throws Exception {
LEGACY_SCRIPT.invoke(RT.seq(args));
}
public static void main(final String [] args) throws Exception {
final String [] scripts = { };
final String [] scripts2 = { clj/utils/test_use_utils.clj };
legacy_script(scripts);
Var.intern(Namespace.findOrCreate(Symbol.create(clojure)),
Symbol.create(*console*), abc);
invoke_script(scripts2);
}
}
But I get an error message:
[java] java.lang.Exception: Unable to resolve symbol: *console*
in this context (test_use_utils.clj:45)
[java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute
(ExecuteJava.java:194)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Running multiple scripts from the Java realm
On Mar 25, 3:12 am, BerlinBrown berlin.br...@gmail.com wrote:
I know it isn't advised but I have my various reasons.
What are some of the best ways to invoke clojure scripts from Java but
still maintain the state of the current session.
For example, if I run a script from Java, is there a way to ensure
that script has already been run...say if I run another script.
I was doing the following.
--
package test.toolkit.clojure;
import clojure.lang.Namespace;
import clojure.lang.RT;
import clojure.lang.Symbol;
import clojure.lang.Var;
public class TestSpringLoadClojure {
final static private Symbol CLOJURE_MAIN = Symbol.create
(clojure.main);
final static private Namespace CLOJURE_MAIN_NS =
Namespace.findOrCreate(CLOJURE_MAIN);
final static private Var REQUIRE = Var.intern(RT.CLOJURE_NS,
Symbol.create(require));
final static private Var LEGACY_REPL = Var.intern(CLOJURE_MAIN_NS,
Symbol.create(legacy-repl));
final static private Var LEGACY_SCRIPT = Var.intern(CLOJURE_MAIN_NS,
Symbol.create(legacy-script));
final static private Var MAIN = Var.intern(CLOJURE_MAIN_NS,
Symbol.create(main));
private static void legacy_script(String[] args) throws Exception {
REQUIRE.invoke(CLOJURE_MAIN);
LEGACY_SCRIPT.invoke(RT.seq(args));
}
private static void invoke_script(String[] args) throws Exception {
LEGACY_SCRIPT.invoke(RT.seq(args));
}
public static void main(final String [] args) throws Exception {
final String [] scripts = { };
final String [] scripts2 = { clj/utils/test_use_utils.clj };
legacy_script(scripts);
Var.intern(Namespace.findOrCreate(Symbol.create(clojure)),
Symbol.create(*console*), abc);
invoke_script(scripts2);
}
}
But I get an error message:
[java] java.lang.Exception: Unable to resolve symbol: *console*
in this context (test_use_utils.clj:45)
[java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute
(ExecuteJava.java:194)
Nevermind.
(println -- clojure/*console*)
if I do this, I get it
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: dynamic member-symbol in (.) form
Hello, No, it's not possible, dot (.) is a special form and disallows this. Search this mailing list for the subject Help with the dot operator special form for a similar discussion on the ways to achieve more dynamic (runtime) method resolution. HTH, -- Laurent 2009/3/25 ninix nitzan@gmail.com Hi, Is there any way to get a dynamic member-symbol for use in the (.) special form? For example, I get the following exception: user= (def obj (Object.)) #'user/obj user= (. obj (symbol f)) java.lang.IllegalArgumentException: No matching method found: symbol for class java.lang.Object I expected this to behave like: (. obj f), so I can change the accessed member by changing the argument in (symbol ...), but was surprised by the result... 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 clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: oo
On 24.03.2009, at 19:29, mikel wrote: I personally like Haskell's philosophy in this area: there is a facility for defining data layouts, and there is a facility for defining protocols, and they are completely separate. You can define a I like that as well, and I have been trying to do something similar in Clojure with my types module (clojure.contrib.types) and my collection of generic interfaces (clojure.contrib.generic). It's too early to say if these will work out well, but I do think they are as close to Haskell's philosophy as possible in a dynamically typed language. I haven't thought much about extending types yet. It could mean opening the can of worms associated with inheritance and all that. I am waiting for a concrete situation where extension would be useful to think about how best to do it. Clojure's built-in defstruct provides a way to specify record types, but not to extend them. It is not really meant to define types, the documentation clearly says that struct maps are just an implementation of maps optimized for a specific frequent use case. (I have found Clojure MultiFns awkward to use thus far, especially when trying to design extensible APIs around them; client code has to know too much about the implementation details of MultiFns--e.g. you have to know when and how to hand-tweak dispatching for the particular MultiFns you are given). Could you elaborate a bit on this? I haven't met any major obstacles with multimethods yet. The dispatch functions give quite a lot of flexibility in practice. In what situation did you find them inconvenient? Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: oo
On Wed, Mar 25, 2009 at 1:44 AM, Konrad Hinsen konrad.hin...@laposte.net wrote: Could you elaborate a bit on this? I haven't met any major obstacles with multimethods yet. The dispatch functions give quite a lot of flexibility in practice. In what situation did you find them inconvenient? To summarize, I think the points that have been raised here and on related threads are that: 1. Structs don't inherently have a type. If you want to dispatch on type (a common use-case), you have to make a constructor that inserts the type information as part of the struct. Some have expressed concern that it may be too easy for this type information to be altered, or worse, the data could be changed or removed in a way that makes the struct inconsistent with the type label it carries around. 2. No way to call next-method or super, which limits the ability to reuse related methods. 3. The dispatch mechanism requires a lot of explicit prefer-methods, or else it may be hard to guarantee you won't get a run-time error from a situation the dispatch system considers ambiguous. This also makes code less extensible because to add a method, you must know about all the other methods that have been implemented in order to insert all the appropriate preferences. Honestly, the one time I used Clojure's multimethods (contrib.math), they suited my needs perfectly, but I definitely see where these concerns are coming from. The existing mechanism is very flexible in one respect: you can dispatch on anything you want, not just type. In other respects, it seems like Clojure's multimethods are less sophisticated than their CLOS/Dylan counterparts. If there is a way to achieve the same things in Clojure, it's not readily apparent (see recent thread about the next-method/super issue, for example). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: dynamic member-symbol in (.) form
Hi, 2009/3/25 ninix nitzan@gmail.com Thanks. 1) The returned exception is misleading. For example, in the following (contrived) case: user= (. obj (toString )) java.lang.IllegalArgumentException: No matching method found: toString for class java.lang.Object Since the member-symbol is not evaluated, shouldn't the exception be (at least): ... method found: (toString ... ? Indeed. 2) For runtime method resolution - Instead of calling the Clojure reflector methods directly (as was suggested in the discussion you mentioned) perhaps the dot form should attempt to evaluate the member-symbol; it will use the value if the evaluation succeeds and can still use the symbol name (as it currently does) if the evalution fails (e.g. the symbol is not bound). I think the special operator manipulates the symbol at compile time, where no runtime (as the evaluation of a complex expression) is possible. That's certainly as is for a performance reason. Maybe a more dynamic version of it (not requiring one to make calls to internal clojure java code) could have its place in clojure-contrib ? On Mar 25, 10:06 am, Laurent PETIT laurent.pe...@gmail.com wrote: Hello, No, it's not possible, dot (.) is a special form and disallows this. Search this mailing list for the subject Help with the dot operator special form for a similar discussion on the ways to achieve more dynamic (runtime) method resolution. HTH, -- Laurent 2009/3/25 ninix nitzan@gmail.com Hi, Is there any way to get a dynamic member-symbol for use in the (.) special form? For example, I get the following exception: user= (def obj (Object.)) #'user/obj user= (. obj (symbol f)) java.lang.IllegalArgumentException: No matching method found: symbol for class java.lang.Object I expected this to behave like: (. obj f), so I can change the accessed member by changing the argument in (symbol ...), but was surprised by the result... 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 clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: file io
2009/3/25 e evier...@gmail.com: For example, slurp is, perhaps, marginally better than read because it may help express that it reads the whole file. Anyone else hate the names 'slurp' and 'spit' as much as me? IMO changing these names would be a great idea whether these functions are moved up to core or not. -- Iode Software Ltd, registered in England No. 6299803. Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne Wear, DH5 8NE. This message is intended only for the use of the person(s) (the intended recipient(s)) to whom it is addressed. It may contain information which is privileged and confidential within the meaning of applicable law. If you are not the intended recipient, please contact the sender as soon as possible. The views expressed in this communication may not necessarily be the views held by The Company. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: oo
On Mar 25, 4:13 am, Mark Engelberg mark.engelb...@gmail.com wrote: On Wed, Mar 25, 2009 at 1:44 AM, Konrad Hinsen konrad.hin...@laposte.net wrote: Could you elaborate a bit on this? I haven't met any major obstacles with multimethods yet. The dispatch functions give quite a lot of flexibility in practice. In what situation did you find them inconvenient? [... good points snipped...] I agree with all the points you raise here. 3. The dispatch mechanism requires a lot of explicit prefer-methods, or else it may be hard to guarantee you won't get a run-time error from a situation the dispatch system considers ambiguous. This also makes code less extensible because to add a method, you must know about all the other methods that have been implemented in order to insert all the appropriate preferences. [...] it seems like Clojure's multimethods are less sophisticated than their CLOS/Dylan counterparts I dunno if I'd go that far. What I can say is that you don't need anything like prefer-method to prevent dispatching ambiguities in either CLOS or Dylan. The requirement to hand-tweak dispatching strikes me as particularly ugly. How can I design an extensible API on MutiFns? I have no idea. Defining a new method can introduce an ambiguity in dispatching that requires a prefer-method call to fix. When I'm implementing the library, that's just a minor annoyance, but when I contemplate delivering it to someone else for use and extension, it suddenly turns into a major headache. Users of that library can break existing code by defining new methods, because new methods may introduce dispatching ambiguities. In order to fix the breakage, they need to know the right prefer-method calls to make. That means they need to understand esoteric details of the library implementation for no good reason--for no reason at all, except that if they don't know them, they won't be able to make the right prefer- method calls. Yuck. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: file io
On Mar 25, 2009, at 5:52 AM, Paul Drummond wrote: Anyone else hate the names 'slurp' and 'spit' as much as me? You're not alone there. http://groups.google.com/group/clojure/browse_frm/thread/d8064dbb94c5cd2c/bce36a47121d6faf?lnk=gstq=slurp+name#bce36a47121d6faf IMO changing these names would be a great idea whether these functions are moved up to core or not. I agree. --Steve smime.p7s Description: S/MIME cryptographic signature
Re: Generic functions again
On Mar 24, 10:51 pm, mikel mev...@mac.com wrote: On Mar 24, 5:37 pm, Meikel Brandmeyer m...@kotka.de wrote: [...snip...] I wanted to call out a point that I made before, but that is maybe buried in a little too much verbiage. The point is that there is maybe a way for me to implement an automated and predictable answer to the question you raised: === Suppose the following situation: (define-method foo [x some.inter.Face] ...) (define-method foo [x some.other.Interface] ...) Now suppose you call this function foo with something like (proxy [some.inter.Face some.other.Interface] [] ...). Which magic decides which method to use? The answer I propose is that dispatch chooses some.inter.Face first, because it appears leftmost in the sequence of interfaces you provided to proxy. That's not currently implemented because I'm not sure yet if the order of interfaces reported by a proxy object is reliably stable, and whether it reliably reflects their order in the original proxy expression. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Why not sorted-set-by?
Hi hjlee, there is already a filed issue and a patch from Timothy Pratley which adds sorted-set-by to clojure: http://code.google.com/p/clojure/issues/detail?id=76colspec=ID%20Type%20Status%20Priority%20Reporter%20Owner%20Summary But its priority is set tow low. erik --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Turning a non-standard iterator into a seq
Hi, I am very new to Clojure and I am trying to turn a a href=http:// www.biojava.org/docs/api/org/biojava/bio/seq/SequenceIterator.htmlSequenceIterator/a from the BioJava library into a lazy Clojure seq. The interface has two methods `hasNext()` and `nextSequence()` which have very similar semantics to `hasNext()` and `next()` for the standard Java Iterator interface. I have looked into various seq related commands like `while`, `doseq`, `for` but cannot seem to find the right combination to wrap SequenceIterator so that it will lazily return the next item in a sequence until `hasNext()` is false. The closest I've got is: (repeatedly #(.nextSequence sequenceiterator)) which unfortunately throws when `hasNext()` is false. Any help would be greatly appreciated. Regards, Mark PS. Just so there is no confusion, the word Sequence in Sequence iterator has nothing to do with Clojure's seqs - read SequenceIterator as ThingIterator if it will make it easier. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Trying to get a list of random numbers using repeat
On Mar 24, 12:43 pm, Paul Drummond paul.drumm...@iode.co.uk wrote: Hi all, user= (repeat 10 (rand-int 49)) (4 4 4 4 4 4 4 4 4 4) Can someone please tell me why this doesn't work? I think this explains your problem: http://xkcd.com/221/ ;-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Generic functions again
Could possibly clojure multimethods be enhanced to support more general use cases (enabling to e.g. define generic functions on top of it), while still be fast for the current behavior ? It seems to me that being able to redefine the function that matches the computed dispatch-value of the call to the multifn to the declared dispatch-values, plus the possibility to customize the algorithm used for disambuiating candidate methods could be enough ? (maybe not for the next-method .. stuff, but a basis for finding the next-method could be based on the disambiguaiting algorithm if it is implemented like a comparator ?) Then defmulti could accept two additional arguments (maybe forcing that the default value be also present in this case, for backward compatibility) : (defn clos-like-dispatcher [computed checked] (every? identity (map isa? computed checked))) (defn clos-like-disambiguier [val-1 val-2] (if (every? identity (map isa? val-1 val-2)) val-1 val2)) (defmulti add (partial map type) :default clos-like-dispatcher clos-like-disambiguier) ... Or something more performant by being able to override the global disambiguing function given the list of all candidate values at once ... Could something this be added to multi-methods, with as an optimized default the current behavior ? It seems that it then could be the basis for clos-like generic functions, and a lot more cases (because it then becomes more general) than it is currently (it seems very harcoded currently). -- Laurent 2009/3/25 mikel mev...@mac.com On Mar 24, 10:51 pm, mikel mev...@mac.com wrote: On Mar 24, 5:37 pm, Meikel Brandmeyer m...@kotka.de wrote: [...snip...] I wanted to call out a point that I made before, but that is maybe buried in a little too much verbiage. The point is that there is maybe a way for me to implement an automated and predictable answer to the question you raised: === Suppose the following situation: (define-method foo [x some.inter.Face] ...) (define-method foo [x some.other.Interface] ...) Now suppose you call this function foo with something like (proxy [some.inter.Face some.other.Interface] [] ...). Which magic decides which method to use? The answer I propose is that dispatch chooses some.inter.Face first, because it appears leftmost in the sequence of interfaces you provided to proxy. That's not currently implemented because I'm not sure yet if the order of interfaces reported by a proxy object is reliably stable, and whether it reliably reflects their order in the original proxy expression. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: dynamic member-symbol in (.) form
On Mar 24, 8:48 pm, ninix nitzan@gmail.com wrote: Is there any way to get a dynamic member-symbol for use in the (.) special form? Nope. Your options are 1) use the Java reflection API; or 2) use Clojure's internal reflection methods. I recommend (1), because that's a well-defined API. It wouldn't be too hard to wrap that up in a macro. -Stuart Sierra --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
exposing specific functions via namespace
Hello, I am trying to organise my code in namespaces and needed a little help. Basically I have created the following namespaces similar to the following: src/org/ppm/foo.clj - org.ppm.foo src/org/ppm/foo/ src/org/ppm/foo/bar.clj - org.ppm.foo.bar src/org/ppm/foo/baz.clj - org.ppm.foo.baz foo.clj is an empty file which does nothing but combines bar and baz: == foo.clj == (ns org.ppm.foo (:use [org.ppm.foo bar baz])) After having the jar in classpath, I create a simple test.clj script that I load. == test.clj == (use 'org.ppm.foo) (bar-func) (baz-func) At this point, test.clj does not see the functions defined in bar and baz. Doing a (in-ns 'org.ppm.foo) before function calls makes it work fine. Is there a way to have foo.clj selectively (or all) expose functions from bar and baz to the end user via foo namespace? Do I need to put all exposed functions into foo.clj? I would prefer to keep them in bar and baz if possible as those are logical blocks for me. Thanks. Parth --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Turning a non-standard iterator into a seq
On Mar 25, 1:55 am, Mark Reid mark.r...@gmail.com wrote: I am very new to Clojure and I am trying to turn a a href=http://www.biojava.org/docs/api/org/biojava/bio/seq/SequenceIterator.html;SequenceIterator/a from the BioJava library into a lazy Clojure seq. The interface has two methods `hasNext()` and `nextSequence()` which have very similar semantics to `hasNext()` and `next()` for the standard Java Iterator interface. Hi Mark, You'll need to work at a lower level using cons and lazy-seq. Something like this (untested): (defn bio-iterator-seq [iterator] (lazy-seq (when (.hasNext iterator) (cons (.nextSequence iterator) (bio-iterator-seq iterator) -Stuart Sierra --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Using proxy with new method being added
I want to use proxy to add a new method to a Java class rather than just overriding an existing method in the Java class. Here is what I have: (def #^Object bar (proxy [Object] [ ] (foo [number] (* 3 number (def fooFn ((proxy-mappings bar) foo)) ;; kludge ;; succeeds (def bar4 (fooFn bar 4)) ;; fails with No matching method found: foo for class clojure.proxy.java.lang.Object (def bar7 (.foo bar 7)) Is there a way to do this simply? 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 clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Using proxy with new method being added
(def #^Object bar (proxy [Object] [ ] (foo [number] (* 3 number (def fooFn ((proxy-mappings bar) foo)) ;; kludge ;; succeeds (def bar4 (fooFn bar 4)) ;; fails with No matching method found: foo for class clojure.proxy.java.lang.Object (def bar7 (.foo bar 7)) Is there a way to do this simply? Try: (gen-interface :name org.bar.IFoo :methods [[foo [Integer] void]]) (def bar (proxy [IFoo] (foo [n] (* 3 n Or you can use gen-class instead of gen-interface and implement Foo as concrete class. Proxy will accept any method name you give him, but it will expose only methods in class and interfaces it extends. -- Krešimir Šojat --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Clojure Talk @ Philly ETE
Clojure and The Robot Apocalypse Also, I posed those to hackernews in the hope of increasing advocacy for both that event (which it turns out I can't make) and for Clojure. The main site is: http://www.phillyemergingtech.com/ The hackernews posts are: http://news.ycombinator.com/item?id=531855 http://news.ycombinator.com/item?id=531853 Promoting Clojure in Philly, Kyle -- -- kyle.bur...@gmail.comhttp://asymmetrical-view.com/ -- --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: STM and useful concurrency
A bunch of separate real concerns here: --- On the issue of STM Slowdown: - Clojure is typically slower than Java by an interesting amount when doing Plain Olde Java Stuff, unless great care is taken (it's possible to take great care). Such a slowdown matters less than the ability to quickly produce functioning code in many cases. - STM'd C/C++ code is *typically* slower than normal code by 3x to 10x (depends on the STM) because of the need to track *all* variables. - Clojure does not need to track all variables, just REFs - so it's STM slowdown factor is probably 10x reduced from the typical C/C++ slowdown. This coupled with a typically lower base speed means Clojure XTNs don't slow down Clojure programs just for existing. --- On the issue of 99.9% retry: Clojure's STM suffers from being obstruction free and not lock free (I think; I haven't paid real close attention to the details). This means that conflicting XTN's can obstruct one another when making committing. This problem is typical of STM's, BTW. Basically, I wrote a tiny microbenchmark with endless conflicting transactions. As I add *real CPUs* (not just threads), total throughput *drops*. With a locking implementation, total throughput would drop some, then hit some lower bound and stay there. Note that this is *total* throughput, not just throughput-per-CPU or throughput- per-thread. It's a performance inversion problem: adding more CPUs hurts! Until this is fixed, multi-threaded performance on Clojure will remain fragile. The problem is generic to STMs - so really I'm saying that STMs, in general, have a more fragile performance profile than locks and this is one of the reasons that STMs have had problems getting traction in the Real World. Now, just to be a pessimist I'll point out that the java.util.concurrent Locks are *also* using obstruction-free algorithms and when an Azul box cuts loose with a few hundred threads there's *always* a CPU spare to obstruct somebody, so we hit live- lock real quick. Given 32-way and 64-way X86 boxes rapidly approaching I'm hopeful Doug Lea will finally have to do something about this. Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Trying to get a list of random numbers using repeat
2009/3/25 David Plumpton david.plump...@gmail.com: I think this explains your problem: http://xkcd.com/221/ There is something to be said for that function. At least it has no side-effects ;) -- Iode Software Ltd, registered in England No. 6299803. Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne Wear, DH5 8NE. This message is intended only for the use of the person(s) (the intended recipient(s)) to whom it is addressed. It may contain information which is privileged and confidential within the meaning of applicable law. If you are not the intended recipient, please contact the sender as soon as possible. The views expressed in this communication may not necessarily be the views held by The Company. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Clojure + Java compilation and IntelliJ IDEA plugin
Hello, all. I've just uploaded new version of La Clojure plugin for IntelliJ IDEA. Among several bugfixes and minor changes I have to note several essential moments. 1. Now Clojure support is added as so-called `facet', which may be attached to every module. Creating new module, just choose Clojure among desired technologies. In this case necessary clojure jar will be downloaded automatically and adjusted as a project library unless you point to it manually. 2. If you open existing project, clojure facet will be detected automatically. For now facet serves as a label for clojure-aware modules. In that modules you may invoke create new clojure file action and their clojure files will be compiled. 3. From now IntelliJ IDEA provides support for batch compilation of Clojure files, whose namespace is marked by :gen-calss tag. Compiled classes will be places to the appropriate output directory of a module. One may choose, which sources should be compiled first - Java or Clojure to resolve one-way dependencies. By default Clojure is compiled first. Moreoverm you may to choose whether to copy *.clj files to output path or not (this might be useful if you're going to invoke some functions from *.clj files dynamically). And, of course, automatic detection and compilation of class-labeled clojure files may be switched off. For more details see File - Settings - Compiler - Clojure. For someone these settings might seem not sufficiently flexible. So, all comments and proposals are appreciated. :) With best regards, Ilya Sergey --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure + Java compilation and IntelliJ IDEA plugin
Sounds great :) On Wed, Mar 25, 2009 at 4:42 PM, Ilya Sergey ilyas...@gmail.com wrote: Hello, all. I've just uploaded new version of La Clojure plugin for IntelliJ IDEA. Among several bugfixes and minor changes I have to note several essential moments. 1. Now Clojure support is added as so-called `facet', which may be attached to every module. Creating new module, just choose Clojure among desired technologies. In this case necessary clojure jar will be downloaded automatically and adjusted as a project library unless you point to it manually. 2. If you open existing project, clojure facet will be detected automatically. For now facet serves as a label for clojure-aware modules. In that modules you may invoke create new clojure file action and their clojure files will be compiled. 3. From now IntelliJ IDEA provides support for batch compilation of Clojure files, whose namespace is marked by :gen-calss tag. Compiled classes will be places to the appropriate output directory of a module. One may choose, which sources should be compiled first - Java or Clojure to resolve one-way dependencies. By default Clojure is compiled first. Could you explain the reasoning behind compiling the Clojure code before the Java code? While trying out Daniel Spiewaks Clojure enabled Buildr, which also compiles the Clojure code first, I noticed that I could not access static methods of the classes that were defined in Java code. I have not tested this, but I would assume that type hinting using these classes don't work either. On the other hand, Java works with Clojure through the classes and interfaces defined in clojure.jar, and resolves their Vars at run time. The 'gen-class case stands as an example where you might have to compile Clojure first, but I wonder if this is the typical case? Moreoverm you may to choose whether to copy *.clj files to output path or not (this might be useful if you're going to invoke some functions from *.clj files dynamically). And, of course, automatic detection and compilation of class-labeled clojure files may be switched off. For more details see File - Settings - Compiler - Clojure. For someone these settings might seem not sufficiently flexible. So, all comments and proposals are appreciated. :) With best regards, Ilya Sergey -- Venlig hilsen / Kind regards, Christian Vest Hansen. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: oo
On 25.03.2009, at 10:13, Mark Engelberg wrote: 1. Structs don't inherently have a type. If you want to dispatch on type (a common use-case), you have to make a constructor that inserts the type information as part of the struct. Some have expressed And/or in the metadata. concern that it may be too easy for this type information to be altered, or worse, the data could be changed or removed in a way that makes the struct inconsistent with the type label it carries around. I am one of those who have expressed concerns, but I must also say that until now I have not encountered such a problem in real life. I have come to the conclusion that interfaces and types work differently in Clojure than in other languages that most of us are more familiar with. So perhaps we are expecting problems that really aren't there once you figure out how to do it right. 2. No way to call next-method or super, which limits the ability to reuse related methods. Again, I'd like to see a real-life situation where this is an issue. 3. The dispatch mechanism requires a lot of explicit prefer-methods, or else it may be hard to guarantee you won't get a run-time error from a situation the dispatch system considers ambiguous. This also And there as well. makes code less extensible because to add a method, you must know about all the other methods that have been implemented in order to insert all the appropriate preferences. This would only be an issue in complex hierarchies. As long as each library just adds its types to a hierarchy and implements methods for them, there is no problem. That's why I'd like to see the real-life situation where there is one. Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: file io
I wrote a simple, small configuration file parser and reader that uses the duck-streams library. You might find some of the examples interesting. http://paste.pocoo.org/show/109498/ On Mar 24, 11:20 am, e evier...@gmail.com wrote: is there something as simple as this in clojure? whole python program: of = open(filename,w) of.write(hello) of.close() I checked the api and looked around the wiki and google quickly and saw how to use java's stuff to do it ... but, welll... I noticed slurp in the api for reading ... but only the whole file at once (read() but no readline()). Is there something symmetrical for writing (outputting)? Is there a web page called File IO somewhere? 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 clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Proposed Change to str-utils
Whatever it's worth as a datum, my experience is that I usually find myself writing upcase, downcase, titlecase functions in most applications, because (1) they're prettier more succinct when passed as first-class (downcase vs. #(.toLowerCase %)) (2) I can add type hints once, in the downcase, upcase, etc. functions, instead of doing so at each invocation (#(.toLowerCase #^String %)) I think (2)'s the most compelling reason. The type-hinting situation in Clojure is currently pretty impressive, I've found; a relatively small number of hints strategically placed usually eliminate most or all of the reflection that occurs in my first draft of functions. But many string-processing operations -- for whatever reason -- usually need a manual hint. I agree that it's not desirable to balloon the Clojure API with thin wrappers on the Java APIs, but, like pc, think this might be an exception. I'm less sure about the other proposed changes to str-utils -- the variable-arity versions of re-split, -partition, -sub, -gsub. Maybe a regex-parse lib in contrib would be a better place? 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 clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: oo
Does anybody know of some minimal clos implementation that is easily portable? I suppose that it contain base functions that are implemented in CL, and the rest of clos built on top of that. It might be interesting to try to adapt such a library to clojure. I remember people mentioning PCL and closette as clos implementations, but actualy never looked at them. Regards, Marko Kocić --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure + Java compilation and IntelliJ IDEA plugin
Hi Ilya, I would like to be able to demo the sample code from the book in IDEA. Here are a few things I am seeing so far: (1) When I set a breakpoint, I get a warning icon that says no executable code found at... but the breakpoint does in fact seem to work. (2) The variable window correctly displays collections, but not large/ infinite sequences. If you try to open a variable view on an infinite sequence, it will use all of memory. Can the plugin be modified to respect the *print-length* and *print-depth* variables? (3) I am unable to set a watch on the special variable *print-length*. The entry UI goes wonky when I reach the hyphen character in the name. It's exciting to see the plugin moving forward, thanks for your efforts! Best, Stu Hello, all. I've just uploaded new version of La Clojure plugin for IntelliJ IDEA. Among several bugfixes and minor changes I have to note several essential moments. 1. Now Clojure support is added as so-called `facet', which may be attached to every module. Creating new module, just choose Clojure among desired technologies. In this case necessary clojure jar will be downloaded automatically and adjusted as a project library unless you point to it manually. 2. If you open existing project, clojure facet will be detected automatically. For now facet serves as a label for clojure-aware modules. In that modules you may invoke create new clojure file action and their clojure files will be compiled. 3. From now IntelliJ IDEA provides support for batch compilation of Clojure files, whose namespace is marked by :gen-calss tag. Compiled classes will be places to the appropriate output directory of a module. One may choose, which sources should be compiled first - Java or Clojure to resolve one-way dependencies. By default Clojure is compiled first. Moreoverm you may to choose whether to copy *.clj files to output path or not (this might be useful if you're going to invoke some functions from *.clj files dynamically). And, of course, automatic detection and compilation of class-labeled clojure files may be switched off. For more details see File - Settings - Compiler - Clojure. For someone these settings might seem not sufficiently flexible. So, all comments and proposals are appreciated. :) With best regards, Ilya Sergey --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: oo
On Mar 25, 12:35 pm, Konrad Hinsen konrad.hin...@laposte.net wrote: On 25.03.2009, at 10:13, Mark Engelberg wrote: 1. Structs don't inherently have a type. If you want to dispatch on type (a common use-case), you have to make a constructor that inserts the type information as part of the struct. Some have expressed And/or in the metadata. concern that it may be too easy for this type information to be altered, or worse, the data could be changed or removed in a way that makes the struct inconsistent with the type label it carries around. I am one of those who have expressed concerns, but I must also say that until now I have not encountered such a problem in real life. I have come to the conclusion that interfaces and types work differently in Clojure than in other languages that most of us are more familiar with. So perhaps we are expecting problems that really aren't there once you figure out how to do it right. 2. No way to call next-method or super, which limits the ability to reuse related methods. Again, I'd like to see a real-life situation where this is an issue. 3. The dispatch mechanism requires a lot of explicit prefer-methods, or else it may be hard to guarantee you won't get a run-time error from a situation the dispatch system considers ambiguous. This also And there as well. makes code less extensible because to add a method, you must know about all the other methods that have been implemented in order to insert all the appropriate preferences. This would only be an issue in complex hierarchies. As long as each library just adds its types to a hierarchy and implements methods for them, there is no problem. That's why I'd like to see the real-life situation where there is one. I repeatedly ran into all the problems Mark mentioned when trying to write an extensible set of codecs for serializing and deserializing game data, and for building a extensible set of data structures for representing game state. The game in question is a relatively large multiplayer RPG-style game whose data library needs to describe a large number of different kinds of objects, support transfer of those objects over networks and storage and retrieval on various kinds of repositories, and which needs to be extended by a number of people on an ongoing basis. I need to be able to clearly say what the protocols are for creating existing objects, and for defining new kinds of objects, and for serializing and deserializing them. With a large number of types of objects, name collisions in field- names becomes an issue. I can solve it by providing a mechanism to define the names allowed in a particular kind of object, and a way to declare requirements about the values allowed on those names. Storing type tags in metadata is handy in that the type function then returns the tag you want, and it's easy to make MultFns dispatch on those values. On the other hand, not all objects that one might want to dispatch on support metadata. That leaves storing type tags in the object itself, which is fairly convenient, but as the disadvantages Mark mentions. A partial workaround is to implement a feature for decalring the fields allowed and required in maps, and to implement consistency checking to ensure (to the extent that one can) that no one uses the type-tag field for anything other than type-tags. It's possible to provide a polymorphic API that covers each of the various defined kinds of objects, but building that API involves a lot of prefer-method calls. The inconvenience of that necessity increases, seemingly without bound, as people add new kinds of objects and methods to handle them. Each addition potentially requires its implementor to examine an ever-increasing set of previously-defined data descriptions and methods to determine what the correct prefer- method calls are. There may not always be a correct set. When there isn't, finding the data description and method definition that cause the unsolvable problem isn't necessarily easy. I'm extremely uncomfortable with any library that requires its user to be familiar with all of its internals and all its dependencies; that's exactly what libraries are meant to avoid. Therefore I am even more uncomfortable with library-building tools that guarantee that's the sort of library I'll be building. The set of game data objects describes features of an imaginary world. Those features (creatures, crafted items, factions, and so on) naturally cluster into related taxonomies of shared and specialized features. If you can say this is just like those things except for these features, you save a lot of duplicated code. Type extension is one part of that ability; next-method is the other. This is one real-world situation where all the issues Mark raised are real and pressing issues for development, but it's not a special situation. I've run into these issues many many times over the years. They're why people keep
Re: oo
On Mar 25, 2:51 pm, Marko Kocić marko.ko...@gmail.com wrote: Does anybody know of some minimal clos implementation that is easily portable? I suppose that it contain base functions that are implemented in CL, and the rest of clos built on top of that. It might be interesting to try to adapt such a library to clojure. I remember people mentioning PCL and closette as clos implementations, but actualy never looked at them. Tinyclos is decent, and lots of people have made good use of it. For example, it's a standard extension to Chicken Scheme (insofar as anything to do with Chicken Scheme can be called standard) and has lots of enhancements provided by Felix. The reason I didn't port Tinyclos to Clojure is that CLOS assumes a specific model of classes, and I wanted to concentrate specifically on generic functions, not add yet another typesystem to Clojure. You could make a counterargument that the CLOS typesystem is specifically designed to interoperate seamlessly with legacy typesystems, and you would have a point. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Why not sorted-set-by?
On Wed, Mar 25, 2009 at 7:21 AM, hoeck i_am_wea...@kittymail.com wrote:
there is already a filed issue and a patch from Timothy Pratley which
adds sorted-set-by to clojure:
http://code.google.com/p/clojure/issues/detail?id=76colspec=ID%20Type%20Status%20Priority%20Reporter%20Owner%20Summary
But its priority is set tow low.
Until the patch is included, you could use this:
(import '(clojure.lang PersistentTreeMap APersistentSet Reversible Sorted))
(defn sorted-set-by [cmp items]
((fn mkset [m #^PersistentTreeMap impl]
(proxy [APersistentSet Reversible Sorted] [m impl]
(disjoin [k] (if (contains? impl k) (mkset m (dissoc impl k)) this))
(cons [k] (if (contains? impl k) this (mkset m (assoc impl k k
(empty [] (mkset m (empty impl)))
(rseq [] (.seq this false))
(withMeta [m2] (mkset m2 impl))
(comparator [] (.comparator impl))
(entryKey [e] e)
(seq ([] (keys impl))
([asc] (keys (.seq impl asc
(seqFrom [k asc] (keys (.seqFrom impl k asc)
nil (apply sorted-map-by cmp (interleave items items
user= (sorted-set-by 1 2 3 4 5)
#{5 4 3 2 1}
--Chouser
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Proposed Change to str-utils
Perry, 1. Thanks for the tip on using type hints! I just added them to my code and pushed it to github 2. If you take a close look at my re- * methods, I actually tried to enforce an arity of 2 on as many methods as I could. This way the methods would read like so (re-split input-sting work-instructions) (re-partition input-sting work-instructions) (re-gsub input-sting work-instructions) (re-sub input-sting work-instructions) However, this didn't quite work with the lowest levels of re-gsub and re-sub, and forcing a map at the lowest level didn't feel right. 3. Library location is a slight issue. I agree these methods are in a completely different category than downcase, upcase, etc. The current str-utils.clj file has these methods in it. That is why they started there. There may be a case for creating a separate regex- utils library, and I know I have a few more parsing methods I'd like to propose in the near future. At the current moment, I personally prefer to have everything in one file. We'll see how big things get, though. To Everyone, I'd like to add Perry's type-hinting argument to the list of reasons these changes should be in contrib. Pooling our efforts to create a high performance version of the code does add value beyond a simple wrapper. A *fast*, tested and slick string library is even better than a tested and slick string library. Sean On Mar 25, 3:08 pm, Perry Trolard trol...@gmail.com wrote: Whatever it's worth as a datum, my experience is that I usually find myself writing upcase, downcase, titlecase functions in most applications, because (1) they're prettier more succinct when passed as first-class (downcase vs. #(.toLowerCase %)) (2) I can add type hints once, in the downcase, upcase, etc. functions, instead of doing so at each invocation (#(.toLowerCase #^String %)) I think (2)'s the most compelling reason. The type-hinting situation in Clojure is currently pretty impressive, I've found; a relatively small number of hints strategically placed usually eliminate most or all of the reflection that occurs in my first draft of functions. But many string-processing operations -- for whatever reason -- usually need a manual hint. I agree that it's not desirable to balloon the Clojure API with thin wrappers on the Java APIs, but, like pc, think this might be an exception. I'm less sure about the other proposed changes to str-utils -- the variable-arity versions of re-split, -partition, -sub, -gsub. Maybe a regex-parse lib in contrib would be a better place? 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 clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: file io
ooh - that's precisely why I was looking into duck-streams myself; thanks for that! Mind you, after a while in the Ruby world, I'd highly recommend looking at YAML for config files - it's human readable and fairly easily writeable, and lets you add arrays, nested structures, etc. fairly easily. For simple config, and for Java friendliness, I can also see the value of properties files - I just keep working on java projects that have 200 line property files with hacks to handle nested structures and lists - it gets ugly real soon! - Korny On Thu, Mar 26, 2009 at 5:57 AM, Rayne disciplera...@gmail.com wrote: I wrote a simple, small configuration file parser and reader that uses the duck-streams library. You might find some of the examples interesting. http://paste.pocoo.org/show/109498/ On Mar 24, 11:20 am, e evier...@gmail.com wrote: is there something as simple as this in clojure? whole python program: of = open(filename,w) of.write(hello) of.close() I checked the api and looked around the wiki and google quickly and saw how to use java's stuff to do it ... but, welll... I noticed slurp in the api for reading ... but only the whole file at once (read() but no readline()). Is there something symmetrical for writing (outputting)? Is there a web page called File IO somewhere? Thanks. -- Kornelis Sietsma korny at my surname dot com Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: file io
And why not just use clojure source code literal datastructures as the persistence format ? With the pretty print function released by Tom Faulhaber, it's even possible to painlessly write configuration back while keeping it clear (though not currently possible to maintain things such as comments, I fear), -- Laurent 2009/3/25 Korny Sietsma ko...@sietsma.com ooh - that's precisely why I was looking into duck-streams myself; thanks for that! Mind you, after a while in the Ruby world, I'd highly recommend looking at YAML for config files - it's human readable and fairly easily writeable, and lets you add arrays, nested structures, etc. fairly easily. For simple config, and for Java friendliness, I can also see the value of properties files - I just keep working on java projects that have 200 line property files with hacks to handle nested structures and lists - it gets ugly real soon! - Korny On Thu, Mar 26, 2009 at 5:57 AM, Rayne disciplera...@gmail.com wrote: I wrote a simple, small configuration file parser and reader that uses the duck-streams library. You might find some of the examples interesting. http://paste.pocoo.org/show/109498/ On Mar 24, 11:20 am, e evier...@gmail.com wrote: is there something as simple as this in clojure? whole python program: of = open(filename,w) of.write(hello) of.close() I checked the api and looked around the wiki and google quickly and saw how to use java's stuff to do it ... but, welll... I noticed slurp in the api for reading ... but only the whole file at once (read() but no readline()). Is there something symmetrical for writing (outputting)? Is there a web page called File IO somewhere? Thanks. -- Kornelis Sietsma korny at my surname dot com Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Slime integration
On 24 mar, 05:29, Phil Hagelberg p...@hagelb.org wrote: Vagif Verdi vagif.ve...@gmail.com writes: When i use slime with lisp, it shows me function parameters, when cursor is on a function name. But with clojure it only shows me Evaluation Aborted. Is this because that feature not implemented, or i setup something wrong ? Works for me. Would need more details to diagnose what's wrong with yours though. Generally the simplest way to get going with SLIME and Clojure is to load a recent copy of clojure-mode.el, hit M-x clojure-install, and follow the instructions it gives you. -Phil For me it's showing parameters fine but it breaks when trying to autocomplete on the REPL with TAB (this is fixed by changing namespaces) or in a file pressing C-TAB. The backtrace is the following: Backtrace: 0: java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java: 796) 1: clojure.lang.Namespace.find(Namespace.java:129) 2: clojure.core$find_ns__4309.invoke(core.clj:2373) 3: clojure.core$the_ns__4321.invoke(core.clj:2397) 4: clojure.core$ns_map__4328.invoke(core.clj:2407) 5: swank.commands.contrib.swank_c_p_c $completion_list_var__1189$fn__1191.invoke(swank_c_p_c.clj:64) 6: clojure.lang.Delay.deref(Delay.java:33) 7: clojure.lang.Delay.force(Delay.java:25) 8: clojure.core$force__3266.invoke(core.clj:468) 9: swank.commands.contrib.swank_c_p_c $completion_list_var__1189$fn__1195.invoke(swank_c_p_c.clj:71) 10: clojure.lang.Delay.deref(Delay.java:33) 11: clojure.lang.Delay.force(Delay.java:25) 12: clojure.core$force__3266.invoke(core.clj:468) 13: swank.commands.contrib.swank_c_p_c $completion_list_var__1189.invoke(swank_c_p_c.clj:79) 14: swank.commands.contrib.swank_c_p_c$compound_complete__1202.invoke (swank_c_p_c.clj:88) 15: swank.commands.contrib.swank_c_p_c$completions__1210.invoke (swank_c_p_c.clj:93) 16: clojure.lang.Var.invoke(Var.java:350) 17: user$eval__1430.invoke(Unknown Source) 18: clojure.lang.Compiler.eval(Compiler.java:4522) 19: clojure.core$eval__3969.invoke(core.clj:1738) 20: swank.core$eval_in_emacs_package__310.invoke(core.clj:55) 21: swank.core$eval_for_emacs__385.invoke(core.clj:123) 22: clojure.lang.Var.invoke(Var.java:354) 23: clojure.lang.AFn.applyToHelper(AFn.java:179) 24: clojure.lang.Var.applyTo(Var.java:463) 25: clojure.core$apply__3228.doInvoke(core.clj:408) 26: clojure.lang.RestFn.invoke(RestFn.java:428) 27: swank.core$eval_from_control__313.invoke(core.clj:62) 28: swank.core$spawn_worker_thread__408$fn__437$fn__439.invoke (core.clj:157) 29: clojure.lang.AFn.applyToHelper(AFn.java:171) 30: clojure.lang.AFn.applyTo(AFn.java:164) 31: clojure.core$apply__3228.doInvoke(core.clj:408) 32: clojure.lang.RestFn.invoke(RestFn.java:428) 33: swank.core$spawn_worker_thread__408$fn__437.doInvoke(core.clj: 153) 34: clojure.lang.RestFn.invoke(RestFn.java:402) 35: clojure.lang.AFn.run(AFn.java:37) 36: java.lang.Thread.run(Thread.java:636) I tried the clojure-install but still get the same errors. Using Ubuntu 8.10 with Emacs 22 OpenJDK 6. Cheers, V. Segui --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Proposed Change to str-utils
Hi, I would generally agree with Stuart that wrapping Java functions is not a good idea. However, string functions come up so often that I think that this is one area where the rule should be broken, if only for readablility. I agree, I use these string functions frequently. Maybe these String wrapper functions can be in their own namespace to make it explicit that these are wrapper functions. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: file io
+ 1 for literal using literal Clojure data structures for configuration. On Wed, Mar 25, 2009 at 5:50 PM, Laurent PETIT laurent.pe...@gmail.com wrote: And why not just use clojure source code literal datastructures as the persistence format ? With the pretty print function released by Tom Faulhaber, it's even possible to painlessly write configuration back while keeping it clear (though not currently possible to maintain things such as comments, I fear), -- Laurent 2009/3/25 Korny Sietsma ko...@sietsma.com ooh - that's precisely why I was looking into duck-streams myself; thanks for that! Mind you, after a while in the Ruby world, I'd highly recommend looking at YAML for config files - it's human readable and fairly easily writeable, and lets you add arrays, nested structures, etc. fairly easily. For simple config, and for Java friendliness, I can also see the value of properties files - I just keep working on java projects that have 200 line property files with hacks to handle nested structures and lists - it gets ugly real soon! - Korny On Thu, Mar 26, 2009 at 5:57 AM, Rayne disciplera...@gmail.com wrote: I wrote a simple, small configuration file parser and reader that uses the duck-streams library. You might find some of the examples interesting. http://paste.pocoo.org/show/109498/ On Mar 24, 11:20 am, e evier...@gmail.com wrote: is there something as simple as this in clojure? whole python program: of = open(filename,w) of.write(hello) of.close() I checked the api and looked around the wiki and google quickly and saw how to use java's stuff to do it ... but, welll... I noticed slurp in the api for reading ... but only the whole file at once (read() but no readline()). Is there something symmetrical for writing (outputting)? Is there a web page called File IO somewhere? Thanks. -- Kornelis Sietsma korny at my surname dot com Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Slime integration
Just responding to myself, the issue seems to have been fixed by itself. OTOH compiler errors don't popup like before. I can see them in the *SLIME Compilation* buffer but clicking on them doesn't lead to the source code. The faulty lines are also not highlighted in anyway way now. Is this correct behaviour or is my Slime installation borked beyond recovery? V. Segui --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure + Java compilation and IntelliJ IDEA plugin
If we've already downloaded the first plugin, what's the best way to upgrade? Do you have to delete the first one, or just install the second on top? Is there a way to update the plugin from within the IDE? 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 clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure + Java compilation and IntelliJ IDEA plugin
Hello, Mark. The easiest way to updae plugin from within the idea is to use plugin manager (see File - Settings - Plugins), find Clojure plugin in the list, right-click on it and hit update. AFAIK, you also must see kind of blinking gear in the bottom right corener of IDEA main screen, which assumes, that you have some plugins to update. With best regards, Ilya 2009/3/26 Mark Engelberg mark.engelb...@gmail.com If we've already downloaded the first plugin, what's the best way to upgrade? Do you have to delete the first one, or just install the second on top? Is there a way to update the plugin from within the IDE? 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 clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure + Java compilation and IntelliJ IDEA plugin
Hello, Christian Could you explain the reasoning behind compiling the Clojure code before the Java code? It's very good question, and to be honest I don't know exact question for it. I may imagine both cases from Clojure to Java and vise versa. Making first variant default I was followed by one letter I had received. It was about some project written in IDEA, where Clojure is used for core funcationality whereas al UI is written in Java via UI designer. Untill we have no stub-generation (as it was done in Groovy) or Java code analysis like in Scala only one consistent solution will be to define compilation order explicitly. Tricky project decomposion into modules may help to resolve cross-languge dependencies. With best regards, Ilya 2009/3/25 Christian Vest Hansen karmazi...@gmail.com Sounds great :) On Wed, Mar 25, 2009 at 4:42 PM, Ilya Sergey ilyas...@gmail.com wrote: Hello, all. I've just uploaded new version of La Clojure plugin for IntelliJ IDEA. Among several bugfixes and minor changes I have to note several essential moments. 1. Now Clojure support is added as so-called `facet', which may be attached to every module. Creating new module, just choose Clojure among desired technologies. In this case necessary clojure jar will be downloaded automatically and adjusted as a project library unless you point to it manually. 2. If you open existing project, clojure facet will be detected automatically. For now facet serves as a label for clojure-aware modules. In that modules you may invoke create new clojure file action and their clojure files will be compiled. 3. From now IntelliJ IDEA provides support for batch compilation of Clojure files, whose namespace is marked by :gen-calss tag. Compiled classes will be places to the appropriate output directory of a module. One may choose, which sources should be compiled first - Java or Clojure to resolve one-way dependencies. By default Clojure is compiled first. Could you explain the reasoning behind compiling the Clojure code before the Java code? While trying out Daniel Spiewaks Clojure enabled Buildr, which also compiles the Clojure code first, I noticed that I could not access static methods of the classes that were defined in Java code. I have not tested this, but I would assume that type hinting using these classes don't work either. On the other hand, Java works with Clojure through the classes and interfaces defined in clojure.jar, and resolves their Vars at run time. The 'gen-class case stands as an example where you might have to compile Clojure first, but I wonder if this is the typical case? Moreoverm you may to choose whether to copy *.clj files to output path or not (this might be useful if you're going to invoke some functions from *.clj files dynamically). And, of course, automatic detection and compilation of class-labeled clojure files may be switched off. For more details see File - Settings - Compiler - Clojure. For someone these settings might seem not sufficiently flexible. So, all comments and proposals are appreciated. :) With best regards, Ilya Sergey -- Venlig hilsen / Kind regards, Christian Vest Hansen. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure + Java compilation and IntelliJ IDEA plugin
Hi, Stuart. I would like to be able to demo the sample code from the book in IDEA That's great, I'm really happy to hear it. As for all three issues you've mentioned, all of them have same origin and related to so-called evaluator API. What you can see now using debugger is nothing but vanilla Java stack, some of whose variable may coincide with appropriate Clojure variables. Implmentation of watches, evaluate expression or some specific cases like dealing with lazy structures is _very_ non-trivial problem, cause all clojure constructs, written, say, in 'watches' section should be translated to correct Java code to capture appropriate stack and environment from JVM and being evaluated. For now, we solved this problem partially for Groovy, because Groovy is not so hard to translate to Java and we're working on the same problem for Scala, which is much more dificult because of presence of string typeing. As for Clojure, I don't see an easy way for now to implement such feature. For me such tasks as smart completion and resolve have greater priority. BTW, I'm not sure, that thiss issue was already mentioned in errata for book, but I failed to compile tasklist.clj example from last book version (27 feb), because some function (sort of `lazy-eval') from clojure-contrib raised an error during compilation. Same result was obtained by compilation from command line, so I'm afraid some-thing wrong either with current clojure-contrib version or this example. Kind regards, Ilya 2009/3/25 Stuart Halloway stuart.hallo...@gmail.com Hi Ilya, I would like to be able to demo the sample code from the book in IDEA. Here are a few things I am seeing so far: (1) When I set a breakpoint, I get a warning icon that says no executable code found at... but the breakpoint does in fact seem to work. (2) The variable window correctly displays collections, but not large/ infinite sequences. If you try to open a variable view on an infinite sequence, it will use all of memory. Can the plugin be modified to respect the *print-length* and *print-depth* variables? (3) I am unable to set a watch on the special variable *print-length*. The entry UI goes wonky when I reach the hyphen character in the name. It's exciting to see the plugin moving forward, thanks for your efforts! Best, Stu Hello, all. I've just uploaded new version of La Clojure plugin for IntelliJ IDEA. Among several bugfixes and minor changes I have to note several essential moments. 1. Now Clojure support is added as so-called `facet', which may be attached to every module. Creating new module, just choose Clojure among desired technologies. In this case necessary clojure jar will be downloaded automatically and adjusted as a project library unless you point to it manually. 2. If you open existing project, clojure facet will be detected automatically. For now facet serves as a label for clojure-aware modules. In that modules you may invoke create new clojure file action and their clojure files will be compiled. 3. From now IntelliJ IDEA provides support for batch compilation of Clojure files, whose namespace is marked by :gen-calss tag. Compiled classes will be places to the appropriate output directory of a module. One may choose, which sources should be compiled first - Java or Clojure to resolve one-way dependencies. By default Clojure is compiled first. Moreoverm you may to choose whether to copy *.clj files to output path or not (this might be useful if you're going to invoke some functions from *.clj files dynamically). And, of course, automatic detection and compilation of class-labeled clojure files may be switched off. For more details see File - Settings - Compiler - Clojure. For someone these settings might seem not sufficiently flexible. So, all comments and proposals are appreciated. :) With best regards, Ilya Sergey --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: O-R mapping
On Mar 25, 11:35 pm, Raoul Duke rao...@gmail.com wrote: if one doesn't have to convert the db into objects, then is there less impedance mismatch? what is a nice setup in a functional language for working with a db schema? what is your experience/thought? Somewhat less, at least in my experience. In FP, you can basically view a relation (table) as a function of its key(s) and build your logic from there. Yet, traditional O-R mappers are still giving me a productivity boost because of the low-level mapping of primitive types to DB field types, and because they handle aggregate and composite- structures for me. I'm currently unaware of a mature functional O-R mapper (even a non-clojure or non-lisp one). Most relational systems in the FP world (like the Datalog work going on for Clojure) seem to operate on memory-based databases, not on persistent ones (and seem to focus completely on querying and inference, ignoring the aspect of persistence). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: file io
clojure file sounds good to me, but who am I? now, a JSON file that would sound good to a whole LOT of people . . . .and is compatible with many many languages ... even looks lispy. JSON is a good thing to get behind because it has a chance of killing xml. On Wed, Mar 25, 2009 at 6:19 PM, Mark McGranaghan mmcgr...@gmail.comwrote: + 1 for literal using literal Clojure data structures for configuration. On Wed, Mar 25, 2009 at 5:50 PM, Laurent PETIT laurent.pe...@gmail.com wrote: And why not just use clojure source code literal datastructures as the persistence format ? With the pretty print function released by Tom Faulhaber, it's even possible to painlessly write configuration back while keeping it clear (though not currently possible to maintain things such as comments, I fear), -- Laurent 2009/3/25 Korny Sietsma ko...@sietsma.com ooh - that's precisely why I was looking into duck-streams myself; thanks for that! Mind you, after a while in the Ruby world, I'd highly recommend looking at YAML for config files - it's human readable and fairly easily writeable, and lets you add arrays, nested structures, etc. fairly easily. For simple config, and for Java friendliness, I can also see the value of properties files - I just keep working on java projects that have 200 line property files with hacks to handle nested structures and lists - it gets ugly real soon! - Korny On Thu, Mar 26, 2009 at 5:57 AM, Rayne disciplera...@gmail.com wrote: I wrote a simple, small configuration file parser and reader that uses the duck-streams library. You might find some of the examples interesting. http://paste.pocoo.org/show/109498/ On Mar 24, 11:20 am, e evier...@gmail.com wrote: is there something as simple as this in clojure? whole python program: of = open(filename,w) of.write(hello) of.close() I checked the api and looked around the wiki and google quickly and saw how to use java's stuff to do it ... but, welll... I noticed slurp in the api for reading ... but only the whole file at once (read() but no readline()). Is there something symmetrical for writing (outputting)? Is there a web page called File IO somewhere? Thanks. -- Kornelis Sietsma korny at my surname dot com Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Yet another trace library.
While searching usable trace libray in clojure, I found 3 pieces of codes. - Stuart Sierra's clojure.contrib.trace - Rich Hickey's posting http://groups.google.com/group/clojure/browse_thread/thread/fd315d9dfdb8c32c/7479682cdf3a1b97?lnk=gstq=trace#7479682cdf3a1b97 - Craig McDaniel's trace2.clj http://groups.google.com/group/clojure/browse_thread/thread/3ea8777880231e18/6fd1b352ac1a6744?lnk=gstq=trace#6fd1b352ac1a6744 1st can be used to trace any expression. but it's not for general function tracing. 2nd version works well. 3rd version provide trace-ns, untrace-ns. but no indentation on trace output. So I combined indented output part of the 2nd codes to the 3rd codes. And provided some control vars on output contents. http://groups.google.com/group/clojure/web/trace_fn.clj Any comment? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: exposing specific functions via namespace
On Wed, Mar 25, 2009 at 12:05 PM, Parth parth.malwan...@gmail.com wrote: I have split up the foo namespace across multiple files. So, I have the following now: src/org/ppm/foo.clj - org.ppm.foo src/org/ppm/bar.clj - org.ppm.foo src/org/ppm/baz.clj - org.ppm.foo With foo.clj using the ns :load for loading bar and baz. (ns org.ppm.foo (:load bar baz)) This meets my needs well as the code is split in logical units while exposing the same namespace to the end user. You may want to take a look at compojure.ns-utils/immigrate. http://github.com/weavejester/compojure/tree/master It just creates public vars pointing at all the public vars in the source namespace. -hume. -- http://elhumidor.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Running multiple scripts from the Java realm
On Mar 25, 3:16 am, Berlin Brown berlin.br...@gmail.com wrote:
On Mar 25, 3:12 am, BerlinBrown berlin.br...@gmail.com wrote:
I know it isn't advised but I have my various reasons.
What are some of the best ways to invoke clojure scripts from Java but
still maintain the state of the current session.
For example, if I run a script from Java, is there a way to ensure
that script has already been run...say if I run another script.
I was doing the following.
--
package test.toolkit.clojure;
import clojure.lang.Namespace;
import clojure.lang.RT;
import clojure.lang.Symbol;
import clojure.lang.Var;
public class TestSpringLoadClojure {
final static private Symbol CLOJURE_MAIN = Symbol.create
(clojure.main);
final static private Namespace CLOJURE_MAIN_NS =
Namespace.findOrCreate(CLOJURE_MAIN);
final static private Var REQUIRE = Var.intern(RT.CLOJURE_NS,
Symbol.create(require));
final static private Var LEGACY_REPL = Var.intern(CLOJURE_MAIN_NS,
Symbol.create(legacy-repl));
final static private Var LEGACY_SCRIPT = Var.intern(CLOJURE_MAIN_NS,
Symbol.create(legacy-script));
final static private Var MAIN = Var.intern(CLOJURE_MAIN_NS,
Symbol.create(main));
private static void legacy_script(String[] args) throws Exception {
REQUIRE.invoke(CLOJURE_MAIN);
LEGACY_SCRIPT.invoke(RT.seq(args));
}
private static void invoke_script(String[] args) throws Exception {
LEGACY_SCRIPT.invoke(RT.seq(args));
}
public static void main(final String [] args) throws Exception {
final String [] scripts = { };
final String [] scripts2 = { clj/utils/test_use_utils.clj
};
legacy_script(scripts);
Var.intern(Namespace.findOrCreate(Symbol.create(clojure)),
Symbol.create(*console*), abc);
invoke_script(scripts2);
}
}
But I get an error message:
[java] java.lang.Exception: Unable to resolve symbol: *console*
in this context (test_use_utils.clj:45)
[java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute
(ExecuteJava.java:194)
Nevermind.
(println -- clojure/*console*)
if I do this, I get it
Anyone? Use the Java clojure code directly at all, ever?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Is Clojure's lack of support for forward referencing a feature or a bug?
On Wed, Mar 11, 2009 at 5:18 PM, Timothy Pratley timothyprat...@gmail.com wrote: It is also quite trivial to patch the compiler to auto-def symbols as it finds them instead of throwing an error. I would be interested in knowing how to do such a patch. When I work on code, I like to organize my functions in a way that makes it easy to read and understand what is going on. As I work on longer chunks of Clojure code, I'm finding that shuffling around the functions to avoid a lot of forward declarations is destroying the readability of my code. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure + Java compilation and IntelliJ IDEA plugin
It's very good question, and to be honest I don't know exact question for it. I may imagine both cases from Clojure to Java and vise versa. Making first variant default I was followed by one letter I had received. It was about some project written in IDEA, where Clojure is used for core funcationality whereas al UI is written in Java via UI designer. That may have been my email. Given that there is currently no solid GUI forms designer for Clojure, IDEA will have a strong market niche by developing one. The idea (no pun intended) is that each language should do what it does best. At some point Clojure may have the tools to be best at GUI forms, but not right now. In this scenario, Clojure will presumably need to be compiled first, unless there is some way to invoke the GUI from Clojure (my Java skills are very rusty). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Is Clojure's lack of support for forward referencing a feature or a bug?
Hi Mark, A fuller discussion can be found here: http://groups.google.com/group/clojure/browse_thread/thread/a99b420d5ee0aa40/47f8c2ab6845e9ae Which has links to the simple patch I tried, and discusses the more advanced technique Laurent experimented with. Elena subsequently developed an emacs plugin which looks interesting (I'm a VI ninja though so haven't used it) http://groups.google.com/group/clojure/browse_thread/thread/ca7076f4c6591fdd/cda5cf10b89a3679 My own experience FWIW was that it was great for two weeks coding with autodef, then for about a week I became frustrated with my typos and disabled it. More promising solutions might come from an external tool (such as Knuth's literate programming noweb) or IDE support like Elena described. For now my work flow is write the code backwards (ie: manually move the cursor up) and/or chopping and pasting. Then when I'm happy with it, I re-chop it all in my 'preferred' order and put a declare at the top. That sounds quite inefficient, but VI is really great for re- organizing text blocks so it is not too strenuous. That said, I'm really interested in ways that literate programming style can be followed with the least external support. Regards, Tim. On Mar 26, 4:15 pm, Mark Engelberg mark.engelb...@gmail.com wrote: On Wed, Mar 11, 2009 at 5:18 PM, Timothy Pratley timothyprat...@gmail.com wrote: It is also quite trivial to patch the compiler to auto-def symbols as it finds them instead of throwing an error. I would be interested in knowing how to do such a patch. When I work on code, I like to organize my functions in a way that makes it easy to read and understand what is going on. As I work on longer chunks of Clojure code, I'm finding that shuffling around the functions to avoid a lot of forward declarations is destroying the readability of my code. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Is Clojure's lack of support for forward referencing a feature or a bug?
For what it's worth I'm a big fan of the wishful thinking programming style. I write some functions how I think they should look, declare the functions I haven't defined yet. Then I implement the lower level functions, write some tests- then usually the higher level stuff works without too much tweaking. In a non-functional programming language this doesn't work so well, but it's a good fit for something like Clojure. On Thu, Mar 26, 2009 at 1:42 AM, Timothy Pratley timothyprat...@gmail.comwrote: Hi Mark, A fuller discussion can be found here: http://groups.google.com/group/clojure/browse_thread/thread/a99b420d5ee0aa40/47f8c2ab6845e9ae Which has links to the simple patch I tried, and discusses the more advanced technique Laurent experimented with. Elena subsequently developed an emacs plugin which looks interesting (I'm a VI ninja though so haven't used it) http://groups.google.com/group/clojure/browse_thread/thread/ca7076f4c6591fdd/cda5cf10b89a3679 My own experience FWIW was that it was great for two weeks coding with autodef, then for about a week I became frustrated with my typos and disabled it. More promising solutions might come from an external tool (such as Knuth's literate programming noweb) or IDE support like Elena described. For now my work flow is write the code backwards (ie: manually move the cursor up) and/or chopping and pasting. Then when I'm happy with it, I re-chop it all in my 'preferred' order and put a declare at the top. That sounds quite inefficient, but VI is really great for re- organizing text blocks so it is not too strenuous. That said, I'm really interested in ways that literate programming style can be followed with the least external support. Regards, Tim. On Mar 26, 4:15 pm, Mark Engelberg mark.engelb...@gmail.com wrote: On Wed, Mar 11, 2009 at 5:18 PM, Timothy Pratley timothyprat...@gmail.com wrote: It is also quite trivial to patch the compiler to auto-def symbols as it finds them instead of throwing an error. I would be interested in knowing how to do such a patch. When I work on code, I like to organize my functions in a way that makes it easy to read and understand what is going on. As I work on longer chunks of Clojure code, I'm finding that shuffling around the functions to avoid a lot of forward declarations is destroying the readability of my code. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Is Clojure's lack of support for forward referencing a feature or a bug?
:) I like that description! :) On Mar 26, 4:47 pm, David Nolen dnolen.li...@gmail.com wrote: For what it's worth I'm a big fan of the wishful thinking programming style. I write some functions how I think they should look, declare the functions I haven't defined yet. Then I implement the lower level functions, write some tests- then usually the higher level stuff works without too much tweaking. In a non-functional programming language this doesn't work so well, but it's a good fit for something like Clojure. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
