Re: Using gen-class to generate methods with same names and arities but different type signatures
On Fri Aug 3 16:50 2012, dgrnbrg wrote:
> I ended up digging deep through gen-class, and I learned about an
> interesting, undocumented feature that solves this problem:
>
> You can, in fact, overload methods of the same arity on type, and here's
> how:
>
> Each method you define in gen-class tries to lookup a corresponding var in
> the impl-ns of the form {impl-ns}/{prefix}{method-name}
>
> However, if the method is overloaded on type, gen-class first looks up a
> var of the form {impl-ns}/{prefix}{method-name}{typesig}, and only if that
> fails does it use the default var.
>
> typesig is constructed in the following way:
>
> (str (interleave (repeat \-) (map typesig-name types))
>
> where types is the vector of types passed to the method declaration.
>
> Finally, here's a way to define typesig-name (and I'm assuming all
> arguments are Classes)
>
> (defn typesig-name [c]
> (cond (.isArray c) (str (typesig-name (.getComponentType c)) "<>")
>(.isPrimitive c) (comment this should give "int", "float",
> "double", "long", etc)
>(.getSimpleName c)))
>
> If you provide vars with those names, you can overload by arity.
>
> To recap, these are the quirks:
> 1) If you don't overload a method, you must provide the implementation in
> the var of the same name.
> 2) If you do overload the arity, you can optionally provide the
> implementation in the specially named vars, but if they don't exist,
> they'll fall back to vars of the same name.
> 3) The overload vars have dash-separated type signatures included in their
> name, where primitives are written like in java, arrays end in "<>", and
> you only include the simple name of the classes.
>
> Whew...
>
> p.s. unfortunately, clojure still boxes the arguments into these function
> no matter what. So this is a dispatch optimization, not a boxing
> optimization (or, in my case, allows me to generate the correct interop
> forms).
You're right. I wasn't aware of this functionality. So, my previous
example can be implemented using:
(defn -foo-boolean<>-boolean [_ _] "booleans")
(defn -foo-char<>-char [_ _] "chars")
(defn -foo-short<>-short [_ _] "shorts")
(defn -foo-int<>-int [_ _] "ints")
(defn -foo-long<>-long [_ _] "longs")
(defn -foo-float<>-float [_ _] "floats")
(defn -foo-double<>-double [_ _] "doubles")
(defn -foo-String<>-String [_ _] "Strings")
(defn -foo-Object<>-Object [_ _] "Objects")
(defn -foo-String<>-int [_ _] "Strings + int")
(defn -foo-boolean [_] "boolean")
(defn -foo-char [_] "char")
(defn -foo-short [_] "short")
(defn -foo-int [_] "int")
(defn -foo-long [_] "long")
(defn -foo-float [_] "float")
(defn -foo-double [_] "double")
(defn -foo-String [_] "String")
(defn -foo-Object [_] "Object")
One interesting difference between this approach and the multimethod
approach is compile-time vs runtime-time dispatching. With a
multimethod, doing something like (StaticTest/foo (Long. 2)) returns
"long" instead of "Object", which may or may not be desirable
behaviour.
On the other hand, it hides some quirks in Clojure's compile-time
resolution. For example, calling (StaticTest/foo \a) actually invokes
StaticTest.foo(Object) instead of StaticTest.foo(char).
Thanks for the extra insight!
Sincerely,
Daniel
signature.asc
Description: Digital signature
Re: Overtone - Live @ Arnolfini
This is fantastic! I just watched several live-coding Impromptu demos yesterday and this definitely takes the cake :) (Also I didn't realize that Overtone had support for graphics now. Good to know!) Really need to dive back in to Overtone some time soon. Keep up the good work. Cheers, Robert On Friday, August 3, 2012 3:47:50 AM UTC-7, Sam Aaron wrote: > > Hi everyone, > > for those interested, I just put up a screencast of a performance I did > with Overtone on Friday the 27th of July at the Arnolfini art gallery in > Bristol, UK: > > https://vimeo.com/46867490 > > The screen resolution is a little odd as I mirrored my display to that of > the projector. Also, the sound starts cutting out for about 20s in the > middle due to some SuperCollider memory issues I managed to run into - it > was a hairy moment, but I managed to recover. > > It was a lot of fun projecting Clojure code on a massive screen to an > audience of interesting art enthusiasts :-) > > Also, the code I used to do the performance is here: > > http://github.com/samaaron/arnold > > Enjoy! > > Sam > > --- > http://sam.aaron.name > > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Using gen-class to generate methods with same names and arities but different type signatures
I ended up digging deep through gen-class, and I learned about an
interesting, undocumented feature that solves this problem:
You can, in fact, overload methods of the same arity on type, and here's
how:
Each method you define in gen-class tries to lookup a corresponding var in
the impl-ns of the form {impl-ns}/{prefix}{method-name}
However, if the method is overloaded on type, gen-class first looks up a
var of the form {impl-ns}/{prefix}{method-name}{typesig}, and only if that
fails does it use the default var.
typesig is constructed in the following way:
(str (interleave (repeat \-) (map typesig-name types))
where types is the vector of types passed to the method declaration.
Finally, here's a way to define typesig-name (and I'm assuming all
arguments are Classes)
(defn typesig-name [c]
(cond (.isArray c) (str (typesig-name (.getComponentType c)) "<>")
(.isPrimitive c) (comment this should give "int", "float",
"double", "long", etc)
(.getSimpleName c)))
If you provide vars with those names, you can overload by arity.
To recap, these are the quirks:
1) If you don't overload a method, you must provide the implementation in
the var of the same name.
2) If you do overload the arity, you can optionally provide the
implementation in the specially named vars, but if they don't exist,
they'll fall back to vars of the same name.
3) The overload vars have dash-separated type signatures included in their
name, where primitives are written like in java, arrays end in "<>", and
you only include the simple name of the classes.
Whew...
p.s. unfortunately, clojure still boxes the arguments into these function
no matter what. So this is a dispatch optimization, not a boxing
optimization (or, in my case, allows me to generate the correct interop
forms).
On Friday, August 3, 2012 10:11:06 AM UTC-4, Daniel Solano Gómez wrote:
>
> On Thu Aug 2 16:41 2012, David Greenberg wrote:
> > Hi Clojurians,
> > I'm finding myself far down the rabbit hole of gen-class. I am trying
> > to generate a class that has a bunch of static methods, and each of
> > those methods has many overloads of arities and types. Unfortunately,
> > there is no interface--this class gets called through reflection in a
> > legacy system.
> >
> > The class's parameter types include primitives, primitive arrays, and
> Objects.
> >
> > I am doing something like:
> >
> > (gen-class
> > :name "my.odd.Class"
> > :main false
> > :methods [^{:static true} [-myfunc ["[Lint;" String] void]
> > ^{:static true} [-myfunc ["[Ldouble;" int] Object]])
> >
> > I found a post explaining that I could define method implementations
> > with overloads by doing -methodName-arg1type-arg2type-arg3type, but
> > when I try that I get an exception that the FileName is too long from
> > the clojure compiler.
> >
> > I can easily generate a map from signatures to implementations, but I
> > need to generate the class with all the overloads.
> >
> > Is there any way to do this? Should I resign myself to writing out a
> > .java file, and compiling that?
>
>
> Hello, David,
>
> Well, gen-class certainly supports creating static methods with type
> hints and overloaded arities. An example using gen-class as part of ns:
>
> (ns gen-class-test.StaticTest
> (:gen-class :methods [^:static [foo [ints int] String]
> ^:static [foo [longs long] String]
> ^:static [foo [chars char] String]
> ^:static [foo [shorts short] String]
> ^:static [foo [booleans boolean] String]
> ^:static [foo [floats float] String]
> ^:static [foo [doubles double] String]
> ^:static [foo ["[Ljava.lang.Object;" Object]
> String]
> ^:static [foo ["[Ljava.lang.String;" String]
> String]
> ^:static [foo ["[Ljava.lang.String;" int] String]
> ^:static [foo [boolean] String]
> ^:static [foo [char] String]
> ^:static [foo [short] String]
> ^:static [foo [int] String]
> ^:static [foo [long] String]
> ^:static [foo [float] String]
> ^:static [foo [double] String]
> ^:static [foo [Object] String]
> ^:static [foo [String] String]]
> :main false))
>
> This will generate a class with the following signature:
>
> public class gen_class_test.StaticTest extends java.lang.Object{
> public static {};
> public gen_class_test.StaticTest();
> public java.lang.Object clone();
> public int hashCode();
> public java.lang.String toString();
> public boolean equals(java.lang.Object);
> public static java.lang.String foo(int[], int);
> public
Re: Can you make Amotoen faster?
On Thu, Jul 19, 2012 at 7:09 AM, David Nolen wrote: > On Wed, Jul 18, 2012 at 10:12 PM, Richard Lyman > wrote: >> All, >> >> There's not much code, and (sadly) not much documentation, but what's >> there needs some performance love. >> >> https://github.com/richard-lyman/amotoen >> >> Notes: >> - jvisualvm doesn't like me this week so help there might be enough >> (I can't see anything other than clojure classes - I'd love to only >> see my code) > > Have you tried profiling with YourKit? They allow free usage for open > source projects. > > David YourKit was fantastic!! I especially loved the 'Hot Spots' functionality--it led me right to the problems. I've sped up Amotoen by several orders of magnitude on some of my tests... I'm into the mid-twenty milliseconds on my self-check. It's funny... I didn't believe it was that much faster - I had to step in and verify that it was still creating the structures it needed to instead of just bailing on an error or something. Turns out that ref and dosync are *really* expensive. I always knew there was a hit, but I never realized how much 'till now. Thanks! -Rich -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureScript reader and timestamps
BG, how come I need to dig so often in the urban dictionary about the acronyms in your emails ? I am starting to worry about my potential obsolescence... :) Luc P > ROFLMAO! > > Sent from phone. Please excuse brevity. > On Aug 3, 2012 6:05 PM, "Michael Fogus" wrote: > > > The revenge of octal! I believe there is a patch for this on master > > and I may have gone out in the latest CLJS push. > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- Softaddicts sent by ibisMail from my ipad! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Using gen-class to generate methods with same names and arities but different type signatures
On Thu Aug 2 16:41 2012, David Greenberg wrote:
> Hi Clojurians,
> I'm finding myself far down the rabbit hole of gen-class. I am trying
> to generate a class that has a bunch of static methods, and each of
> those methods has many overloads of arities and types. Unfortunately,
> there is no interface--this class gets called through reflection in a
> legacy system.
>
> The class's parameter types include primitives, primitive arrays, and Objects.
>
> I am doing something like:
>
> (gen-class
> :name "my.odd.Class"
> :main false
> :methods [^{:static true} [-myfunc ["[Lint;" String] void]
> ^{:static true} [-myfunc ["[Ldouble;" int] Object]])
>
> I found a post explaining that I could define method implementations
> with overloads by doing -methodName-arg1type-arg2type-arg3type, but
> when I try that I get an exception that the FileName is too long from
> the clojure compiler.
>
> I can easily generate a map from signatures to implementations, but I
> need to generate the class with all the overloads.
>
> Is there any way to do this? Should I resign myself to writing out a
> .java file, and compiling that?
Hello, David,
Well, gen-class certainly supports creating static methods with type
hints and overloaded arities. An example using gen-class as part of ns:
(ns gen-class-test.StaticTest
(:gen-class :methods [^:static [foo [ints int] String]
^:static [foo [longs long] String]
^:static [foo [chars char] String]
^:static [foo [shorts short] String]
^:static [foo [booleans boolean] String]
^:static [foo [floats float] String]
^:static [foo [doubles double] String]
^:static [foo ["[Ljava.lang.Object;" Object] String]
^:static [foo ["[Ljava.lang.String;" String] String]
^:static [foo ["[Ljava.lang.String;" int] String]
^:static [foo [boolean] String]
^:static [foo [char] String]
^:static [foo [short] String]
^:static [foo [int] String]
^:static [foo [long] String]
^:static [foo [float] String]
^:static [foo [double] String]
^:static [foo [Object] String]
^:static [foo [String] String]]
:main false))
This will generate a class with the following signature:
public class gen_class_test.StaticTest extends java.lang.Object{
public static {};
public gen_class_test.StaticTest();
public java.lang.Object clone();
public int hashCode();
public java.lang.String toString();
public boolean equals(java.lang.Object);
public static java.lang.String foo(int[], int);
public static java.lang.String foo(long[], long);
public static java.lang.String foo(char[], char);
public static java.lang.String foo(short[], short);
public static java.lang.String foo(boolean[], boolean);
public static java.lang.String foo(float[], float);
public static java.lang.String foo(double[], double);
public static java.lang.String foo(java.lang.Object[], java.lang.Object);
public static java.lang.String foo(java.lang.String[], java.lang.String);
public static java.lang.String foo(java.lang.String[], int);
public static java.lang.String foo(boolean);
public static java.lang.String foo(char);
public static java.lang.String foo(short);
public static java.lang.String foo(int);
public static java.lang.String foo(long);
public static java.lang.String foo(float);
public static java.lang.String foo(double);
public static java.lang.String foo(java.lang.Object);
public static java.lang.String foo(java.lang.String);
}
Now, when it comes to what this class is doing, it is calling the
Clojure function -foo with the arguments from the static method
invocation. In particular:
1. All primitive arguments will be boxed.
2. The number of arguments for -foo must match the number of arguments
for the static method invocation. For multiple arities, you can have
a variadic function or a function with multiple arities.
3. Unfortunately, there is no way to call a different function for each
arity/type.
However, you can make -foo a multimethod. The following works as an
implementation for the above:
(defmulti -foo
(fn [& args]
(apply vector (map class args
; one-arg invocations
(defmethod -foo [Boolean] [_] "boolean")
(defmethod -foo [Character] [_] "char")
(defmethod -foo [Short] [_] "short")
(defmethod -foo [Integer] [_] "int")
(defmethod -foo [Long] [_] "long")
(defmethod -foo [Float] [_] "float")
(defmethod -foo [Double][_] "double")
(defmethod -foo [Object][_] "Object")
(defmethod -foo [String][_] "String")
; two-arg invocations
(defmethod -foo [
Re: binding vs futures bug or feature (or more likely, am I missing the picture?)
On 03/08/12 14:21, Marshall T. Vandegrift wrote: Daniel Silén writes: If I rebind a var's value it receives the new value - but it shouldn't, because it is in another thread, right?! Clojure 1.3 introduced a feature known as "binding conveyance," which causes the functions passed in for futures and agent actions to be wrapped so as to capture the active thread local binding frame at instantiation. You can achieve a similar effect yourself (although the mechanism differs) by using the `bound-fn` macro or wrapping an existing function with `bound-fn*`. I believe the idea was to make the behavior of dynamic vars in these contexts less surprising / more useful, but YMMV. -Marshall aaa ok thanks a lot...I do think this needs to be documented...I can add an example on clojureDocs but the actual documentation needs updating as well... Jim -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: binding vs futures bug or feature (or more likely, am I missing the picture?)
Daniel Silén writes: > If I rebind a var's value it receives the new value - but it shouldn't, > because it is in another thread, right?! Clojure 1.3 introduced a feature known as "binding conveyance," which causes the functions passed in for futures and agent actions to be wrapped so as to capture the active thread local binding frame at instantiation. You can achieve a similar effect yourself (although the mechanism differs) by using the `bound-fn` macro or wrapping an existing function with `bound-fn*`. I believe the idea was to make the behavior of dynamic vars in these contexts less surprising / more useful, but YMMV. -Marshall -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: binding vs futures bug or feature (or more likely, am I missing the picture?)
`future` [https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L6173] uses `binding-conveyor-fn` [https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L1813] inside to keep the original thread binding frame while calling the function in a new thread. Creating a vanilla Java thread is a JVM interop thing and as such Java semantics are preserved. Regards, BG On Fri, Aug 3, 2012 at 1:19 PM, Daniel Silén wrote: > Hi! > > I am new to the language, and at the moment playing around with > concurrent-constructs as presented in a series on Clojure concurrency at > pluralsight.com (by Chraig Andera). > When playing with thread-local redefinitions of vars via the binding-macro, > I found an unexpected behavior: > A future is used to create a background-thread, and I would expect it to > behave the same way as when creating an explicit java thread, however it > doesn't. > If I rebind a var's value it receives the new value - but it shouldn't, > because it is in another thread, right?! > > Example: > (def ^:dynamic foo :fooval) > (def p (promise)) > (def p2 (promise)) > (binding [foo :newval] > (future (deliver p foo)) > (.start (Thread. #(deliver p2 foo))) > (println "in future: " @p) ; expected value of @p :fooval, actual :newval > (println "in java thread: " @p2) > (println "in binding: " foo)) > (println "outside binding: " foo) > > produces (in clojure 1.4.0): > user=> in future: :newval > in java thread: :fooval > in binding: :newval > outside binding: :fooval > nil > > I would expect the future-row to return the same as the java-thread-row, > :fooval. > > I would love to hear an expert-explanation... What did I do wrong? :) > > Kind regards > > Daniel Silén > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- Baishampayan Ghose b.ghose at gmail.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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureScript reader and timestamps
ROFLMAO! Sent from phone. Please excuse brevity. On Aug 3, 2012 6:05 PM, "Michael Fogus" wrote: > The revenge of octal! I believe there is a patch for this on master > and I may have gone out in the latest CLJS push. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureScript reader and timestamps
The revenge of octal! I believe there is a patch for this on master and I may have gone out in the latest CLJS push. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: binding vs futures bug or feature (or more likely, am I missing the picture?)
It looks to me like the future sees the re-binding whereas the native thread does not! Like you, I'd expect the same behaviour from these 2 lines...Can anyone shine some light on this? I'm suspecting it has something to do with the thread pooling that is going on but I've got nothing to base this on... Jim On 03/08/12 08:49, Daniel Silén wrote: Hi! I am new to the language, and at the moment playing around with concurrent-constructs as presented in a series on Clojure concurrency at pluralsight.com (by Chraig Andera). When playing with thread-local redefinitions of vars via the binding-macro, I found an unexpected behavior: A future is used to create a background-thread, and I would expect it to behave the same way as when creating an explicit java thread, however it doesn't. If I rebind a var's value it receives the new value - but it shouldn't, because it is in another thread, right?! Example: (def ^:dynamic foo :fooval) (def p (promise)) (def p2 (promise)) (binding [foo :newval] (future (deliver p foo)) (.start (Thread. #(deliver p2 foo))) (println "in future: " @p) ; expected value of @p :fooval, actual :newval (println "in java thread: " @p2) (println "in binding: " foo)) (println "outside binding: " foo) produces (in clojure 1.4.0): user=> in future: :newval in java thread: :fooval in binding: :newval outside binding: :fooval nil I would expect the future-row to return the same as the java-thread-row, :fooval. I would love to hear an expert-explanation... What did I do wrong? :) Kind regards Daniel Silén -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
binding vs futures bug or feature (or more likely, am I missing the picture?)
Hi! I am new to the language, and at the moment playing around with concurrent-constructs as presented in a series on Clojure concurrency at pluralsight.com (by Chraig Andera). When playing with thread-local redefinitions of vars via the binding-macro, I found an unexpected behavior: A future is used to create a background-thread, and I would expect it to behave the same way as when creating an explicit java thread, however it doesn't. If I rebind a var's value it receives the new value - but it shouldn't, because it is in another thread, right?! Example: (def ^:dynamic foo :fooval) (def p (promise)) (def p2 (promise)) (binding [foo :newval] (future (deliver p foo)) (.start (Thread. #(deliver p2 foo))) (println "in future: " @p) ; expected value of @p :fooval, actual :newval (println "in java thread: " @p2) (println "in binding: " foo)) (println "outside binding: " foo) produces (in clojure 1.4.0): user=> in future: :newval in java thread: :fooval in binding: :newval outside binding: :fooval nil I would expect the future-row to return the same as the java-thread-row, :fooval. I would love to hear an expert-explanation... What did I do wrong? :) Kind regards Daniel Silén -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojurescript One and Websockets
Any updates Kushal Pisavadia on Websockets and Ring jiving? On Monday, March 19, 2012 9:40:20 AM UTC-3, Kushal Pisavadia wrote: > > I am in discussion with James, but it's very high-level at the moment and > no work has been done on integration yet. > > I don't think it'll get into the next tagged release of Ring (1.1) in > time, as that's likely to be released fairly soon once the current set of > issues are cleared up. > > On 19 March 2012 12:19, Jay Fields wrote: > >> I'm not involved (much) with Webbit other than using it in prod for my >> web socket stuff. >> >> I believe Kushal Pisavadia (cc'd) & James Reeves have been talking >> about webbit features that Ring could leverage, but I'm not familiar >> with the details. >> >> Cheers, Jay >> >> On Sat, Mar 17, 2012 at 7:23 PM, Brian Rowe wrote: >> > Hey Jay, >> > >> > Are there any plans to make a ring adapter for webbit? >> > >> > >> > On Friday, March 2, 2012 6:40:27 AM UTC-5, Jay Fields wrote: >> >> >> >> clojure + web sockets, not using >> >> aleph: >> http://blog.jayfields.com/2011/02/clojure-web-socket-introduction.html >> >> >> >> On Mar 1, 2012, at 10:51 PM, Brian Rowe wrote: >> >> >> >> Hi, >> >> >> >> I'm thinking about using clojurescript one a starting point for a web >> >> game. I would like to use websockets as the primary communication >> mechanism >> >> between the browser and the server. As far as I know Zack Tellman's >> Aleph >> >> is the only clojure web server that supports websockets. Is this >> true? If >> >> so, are there any guides showing how to modify clojurescript one to use >> >> Aleph? If there are no guides, how much work would it take to modify >> cljs >> >> one to use aleph? >> >> >> >> 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 >> >> Note that posts from new members are moderated - please be patient with >> >> your first post. >> >> To unsubscribe from this group, send email to >> >> clojure+unsubscr...@googlegroups.com >> >> For more options, visit this group at >> >> http://groups.google.com/group/clojure?hl=en >> >> >> >> >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Clojure" group. >> > To post to this group, send email to clojure@googlegroups.com >> > Note that posts from new members are moderated - please be patient with >> your >> > first post. >> > To unsubscribe from this group, send email to >> > clojure+unsubscr...@googlegroups.com >> > For more options, visit this group at >> > http://groups.google.com/group/clojure?hl=en >> > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: java gui is flashing
I use Ryan solution too with image rendering instead of calling repaint. One remark : the Graphic class display looks better than the Graphic2D class. I have superposition and refreshing, and in my case i got this. Thanks Ryan ! Le dimanche 25 juillet 2010 18:22:45 UTC+2, Mate Toth a écrit : > > Thx guys! > I used double-buffering like in Ryan's code and it worked like a > charm! > > M > > On Jul 25, 4:01 am, Ryan Sattler wrote: > > I've been working on a game with Clojure/Swing lately and the simplest > > way to avoid flashing is to draw to a bufferedImage first, then draw > > that bufferedImage all at once. This means that parts of the screen > > that don't change won't be briefly overwritten by the background > > color, avoiding flashing. Here's some code: > > > > (defn render [game window] > > (let [#^BufferedImage image (.createImage window window-width window- > > height) > > #^Graphics gfx (.createGraphics image) > > #^Graphics2D gfx2 (.getGraphics #^JFrame window)] > > > > (render-background gfx) > > ;draw more stuff on gfx here, eg, your draw-boid would go here > > > > (.drawImage gfx2 image 0 0 window))) ;finally draws the buffered > > image to the screen all at once > > > > -- > > Ryan Sattler -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
ClojureScript reader and timestamps
Hi, I have a strange issue here with certain timestamps: #inst "2012-07-25T17:55:00.000-00:00" does work. #inst "2012-09-25T17:55:00.000-00:00" gives: Error: Assert failed: timestamp month field must be in range 1..12 Failed: 1<=0<=12 (<= low n high) August and September are broken, it seems. Did not test the whole year. What could be wrong? CLJS release is 1443. Kind regards, -- Steffen Beyer -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Labrepl not responding
I've had a devil of a time getting labrepl working in my environment. It is actually working on my macbook pro, but I have had no success getting it to work on my desktop mac. At first I had a ton of trouble getting it to operate on a different port than 8080. Just changing the port number defined in labrepl.clj causes a compiler error as soon as I save the file (I tried changing it to 8088). I have no idea why changing this one thing causes an error, but it has something to do with tools.logging. After wasting too much time with this I gave up and re-downloaded labrepl from Git in my Eclipse environment. Then I changed the port of my existing Apache server to free up 8080. At this point I thought everything would startup. Wrong, I can start the labrepl project in Eclipse, but then nothing much happens. A new REPL window opens, however there is nothing listening at port 8080. I can't get to the webserver that I thought was going to be listening on this port. I see no messages at all in the console window. Any ideas about what might be wrong here? Thanks, Derek -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A succinct & reasonably fast sudoku solver in core.logic
On Tuesday, July 31, 2012 11:48:14 AM UTC-4, David Nolen wrote: > > A much shorter version using an everyo goal I just landed in master: > > http://gist.github.com/3217582 > > David > That is awesome. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
'lein search time' error
Hi, I'm using brew's lein (1.7.1) on Mac OS X and noticed that if I do lein search time the index file http://repo1.maven.org/maven2/.index/nexus-maven-repository-index.zip is looked for but the closest file on that site is http://repo1.maven.org/maven2/.index/nexus-maven-repository-index.gz So the index doesn't get down loaded and cached in ~/.lein/indices/http___repo1.maven.org_maven2/ Is there any reason for the mismatch between the code and the repository?? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Overtone - Live @ Arnolfini
Hi everyone, for those interested, I just put up a screencast of a performance I did with Overtone on Friday the 27th of July at the Arnolfini art gallery in Bristol, UK: https://vimeo.com/46867490 The screen resolution is a little odd as I mirrored my display to that of the projector. Also, the sound starts cutting out for about 20s in the middle due to some SuperCollider memory issues I managed to run into - it was a hairy moment, but I managed to recover. It was a lot of fun projecting Clojure code on a massive screen to an audience of interesting art enthusiasts :-) Also, the code I used to do the performance is here: http://github.com/samaaron/arnold Enjoy! Sam --- http://sam.aaron.name -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Using gen-class to generate methods with same names and arities but different type signatures
David Greenberg writes: > I can easily generate a map from signatures to implementations, but I > need to generate the class with all the overloads. > > Is there any way to do this? Should I resign myself to writing out a > .java file, and compiling that? In my experience just writing a stub Java class for this sort of situation is the simplest solution. I've found that `gen-class` works well for interop when needing to extend an abstract base class or similar scenarios. But when the need is less to interop with the JVM than specifically with Java, it is far easier to wire from Java into Clojure than vice versa. -Marshall -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
