Proxy
The code:
(def app
(proxy [SimpleApplication] []
(simpleInitApp []
(.attachChild (.getRoot this) ball-d)
(.setLocalTranslation ground-d (com.g3d.math.Vector3f. 0
0 0))
(.attachChild (.getRoot this) ground-d))
(simpleUpdate [tpf]
(println tpf)
(flush
In SimpleApplication.java:
...@Override
public void update() {
if (speed == 0)
return;
super.update();
float tpf = timer.getTimePerFrame();
secondCounter += tpf;
int fps = (int) timer.getFrameRate();
if (secondCounter >= 1.0f){
fpsText.setText("Frames per second: "+fps);
secondCounter = 0.0f;
}
simpleUpdate(tpf);
rootNode.updateLogicalState(tpf);
guiNode.updateLogicalState(tpf);
rootNode.updateGeometricState();
guiNode.updateGeometricState();
renderManager.render(tpf);
simpleRender(renderManager);
}
public abstract void simpleInitApp();
public void simpleUpdate(float tpf){
}
...
The error:
INFO Node 2:30:56 AM Child (BitmapFont) attached to this node (Gui
Node)
INFO Node 2:30:56 AM Child (3d-ball) attached to this node (Root Node)
INFO Node 2:30:56 AM Child (3d-ground) attached to this node (Root
Node)
0.14
java.lang.NullPointerException
at
com.g3d.renderer.queue.OpaqueComparator.compare(OpaqueComparator.java:
58)
at
com.g3d.renderer.queue.OpaqueComparator.compare(OpaqueComparator.java:
9)
at java.util.Arrays.mergeSort(Arrays.java:1283)
at java.util.Arrays.mergeSort(Arrays.java:1294)
at java.util.Arrays.mergeSort(Arrays.java:1294)
at java.util.Arrays.mergeSort(Arrays.java:1294)
at java.util.Arrays.sort(Arrays.java:1223)
at com.g3d.renderer.queue.GeometryList.sort(GeometryList.java:73)
at
com.g3d.renderer.queue.RenderQueue.renderGeometryList(RenderQueue.java:
93)
at com.g3d.renderer.queue.RenderQueue.renderQueue(RenderQueue.java:
142)
at com.g3d.renderer.RenderManager.flushQueue(RenderManager.java:313)
at com.g3d.renderer.RenderManager.renderViewPort(RenderManager.java:
415)
at com.g3d.renderer.RenderManager.render(RenderManager.java:427)
at com.g3d.app.SimpleApplication.update(SimpleApplication.java:148)
at user.proxy$com.g3d.app.SimpleApplication$0.update(Unknown Source)
at
com.g3d.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:
120)
at
com.g3d.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:
171)
at java.lang.Thread.run(Thread.java:636)
I've tested a similar app in java and it works. What am I doing wrong?
--
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
Proxy question
Hi folks, I'm trying to use the proxy support to provide a filter to java.io.File#listFiles and am not having any luck: I'm sure I'm doing something stupid, and would appreciate some tips. Here's what I'm doing: (import '(java.io File FilenameFilter)) (def filter (proxy [FilenameFilter] [] (accept [dir name] (. name (endsWith "_2.jpg" (def the-dir (new File "/Users/tree/images")) (map #(. %1 getCanonicalPath) (. the-dir (listFiles filter))) When I evaluate this, I get an IllegalArgumentException: java.lang.IllegalArgumentException: No matching method found: listFiles java.lang.IllegalArgumentException: No matching method found: listFiles at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:62) at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:26) at clojure.lang.Compiler$InstanceMethodExpr.eval(Compiler.java:1087) at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:2568) at clojure.lang.Compiler.eval(Compiler.java:3780) at clojure.lang.Repl.main(Repl.java:75) If I don't include the filter in the call to the listFiles method, then it works fine. Thanks in advance, -tree -- Tom Emerson [EMAIL PROTECTED] http://www.dreamersrealm.net/~tree --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Proxy Bug?
Consider the following code which attempts to redefine clojure/*out*: (ns test (:refer-clojure)) (def output System/out) (def output-stream (let [buffer (new java.io.ByteArrayOutputStream)] (proxy [java.io.OutputStream] [] (flush [] (.append output (.toString buffer "UTF-8")) (.reset buffer)) (write [x] (when (>= (.size buffer) 32) (.flush this)) (.write buffer x)) (write [x off len] (.write buffer x off len) (in-ns 'clojure) (def *out* (new java.io.OutputStreamWriter test/output-stream "UTF-8")) This works, but according to the the documentation of clojure/proxy it seems that "If a method fn is not provided for a class method, the superclass methd will be called." [1] However if I omit the second write method in the proxy definition, I get the following error: user=> (load-file "test.clj") #=(var clojure/*out*) user=> (prn "hello") java.lang.IllegalArgumentException: Wrong number of args passed to: fn--2490$fn (NO_SOURCE_FILE:0) user=> (.printStackTrace *e) java.lang.IllegalArgumentException: Wrong number of args passed to: fn--2490$fn (NO_SOURCE_FILE:0) at clojure.lang.Compiler.eval(Compiler.java:4122) at clojure.lang.Repl.main(Repl.java:91) Caused by: java.lang.IllegalArgumentException: Wrong number of args passed to: fn--2490$fn at clojure.lang.AFn.throwArity(AFn.java:460) at clojure.lang.AFn.invoke(AFn.java:75) at clojure.lang.Proxy__2499.write(Unknown Source) at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202) at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:272) at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:276) at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:122) at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:212) at clojure.flush__906.invoke(boot.clj:1658) at clojure.prn__909.doInvoke(boot.clj:1667) at clojure.lang.RestFn.invoke(RestFn.java:413) at user.eval__2503.invoke(Unknown Source) at clojure.lang.Compiler.eval(Compiler.java:4111) ... 1 more [1] http://clojure.org/java_interop#toc20 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Proxy questions
Hi I'm trying to use Clojure with Apache MINA. I think Clojure it's the ideal language to concurrently handle all the events that arrive into MINA's separate threads. So I tried to port the simplest example, the EchoServer (files here: http://svn.apache.org/viewvc/mina/branches/1.0/example/src/main/java/org/apache/mina/example/echoserver/EchoProtocolHandler.java?view=log and here: http://svn.apache.org/viewvc/mina/branches/1.0/example/src/main/java/org/apache/mina/example/echoserver/Main.java?view=log) This is what I wrote: (import '(org.apache.mina.common ByteBuffer IdleStatus IoHandler IoHandlerAdapter IoSession)) (import '(org.apache.mina.transport.socket.nio SocketAcceptor SocketAcceptorConfig)) (import '(org.apache.mina.filter LoggingFilter)) (import '(java.net InetSocketAddress)) (def echo-handler (proxy [IoHandlerAdapter] [] (sessionCreated [sess] (println (format "Session created: %s" sess))) (sessionIdle [sess status] (println (format "Session idle: %s" sess))) (messageReceived [sess message] (println (format "Received message: %s" message))) ) ) (def acceptor (SocketAcceptor.)) (def config (SocketAcceptorConfig.)) (.. config getFilterChain (addLast "log" (LoggingFilter.))) (. acceptor bind (InetSocketAddress. 1234) echo-handler config) (println "Listening in port 1234") The server starts, but when I connect to it, it doesn't print anything, so I'm guessing that I wrote the proxy wrong. It's supposed to simply be a class that extends IoHandlerAdapter and overwrites the sessionCreated, sessionIdle and messageReceived methods any ideas? thanks --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
proxy and annotation
Hi,
How can I define annotation for a proxy?
For example:
Java code:
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/netty/trunk/src/main/java/org/jboss/netty/example/http/snoop/HttpResponseHandler.java?view=markup
Clojure code:
(def handler
(proxy [SimpleChannelUpstreamHandler] []
(messageReceived [ctx e]
((.println System/out) "hello"
How can I set @ChannelPipelineCoverage("one") for the "handler"
proxy?
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
-~--~~~~--~~--~--~---
reify vs proxy
Hello everyone, I know this is trivial but i just noticed that, unlike proxy, reify demands that at least the return types are consistent. I had a piece of code like this: (defmacro implement-CalculateScore "Consumer convenience for implementing the CalculateScore interface which is needed for genetic and simulated annealing training." [minimize? & body] `(proxy [CalculateScore] [] ;;no base class (calculateScore [this ^MLRegression n#] ~@body) (shouldMinimize [this] ~minimize?))) -- and in order to use reify instead of proxy i had to type hint the return types like this: (defmacro implement-CalculateScore "Consumer convenience for implementing the CalculateScore interface which is needed for genetic and simulated annealing training." [minimize? & body] `(reify CalculateScore (^double calculateScore [this ^MLRegression n#] ~@body) (^boolean shouldMinimize [this] ~minimize?))) Is this something you would all expect?If yes can somebody elaborate as to why that is? Thanks in advance... 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
proxy with dynamic
Hi, Is it possible to give the class as value at runtime to proxy? (defn create-proxy [clazz] (proxy [clazz] )) I know this can be done with a macro, but my question is whether it can be done as function. Thanks, Razvan -- 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
proxy and java.io.Writer
Hi.
I'm trying to create a java.io.Writer proxy (which writes to a
JTextArea) but I can't get it to work.
Here is my clojure code so far:
(def text-area (javax.swing.JTextArea.))
(def frame
(let [f (javax.swing.JFrame.)]
(.. f getContentPane (add text-area))
(.setMinimumSize f (java.awt.Dimension. 200 200))
(.setVisible f true)
f))
(def text-area-writer
(proxy [java.io.Writer] []
(close [])
(flush [])
(write [^chars chrs ^int offs ^int len]
(.append text-area (String. chrs offs len)
When I load the code above I get an "IllegalArgumentException: Unable
to resolve classname: int" so I think I'm not type hinting correctly.
Here is a similar piece of java code which works as expected:
public class Main extends JFrame {
private JTextArea text;
public Writer writer;
public Main() {
text = new JTextArea();
getContentPane().add(text);
setVisible(true);
setMinimumSize(new Dimension(200, 200));
writer = new TextAreaWriter();
}
class TextAreaWriter extends Writer {
public void close() throws IOException {}
public void flush() throws IOException {}
public void write(char[] chrs, int offs, int len) throws IOException {
String str = new String(chrs, offs, len);
text.append(str);
}
}
public static void main(String[] args) throws IOException {
Main m = new Main();
m.writer.write("Hello, World!");
}
}
Any help is much appreciated!
/Jonas
--
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: Proxy question
On Sun, Sep 7, 2008 at 2:55 PM, Tom Emerson <[EMAIL PROTECTED]> wrote: > Hi folks, > I'm trying to use the proxy support to provide a filter to > java.io.File#listFiles and am not having any luck: I'm sure I'm doing > something stupid, and would appreciate some tips. Here's what I'm doing: > > (import '(java.io File FilenameFilter)) > > (def filter (proxy [FilenameFilter] [] > (accept [dir name] > (. name (endsWith "_2.jpg" > > (def the-dir (new File "/Users/tree/images")) > > (map #(. %1 getCanonicalPath) > (. the-dir (listFiles filter))) > > > When I evaluate this, I get an IllegalArgumentException: > > java.lang.IllegalArgumentException: No matching method found: listFiles > java.lang.IllegalArgumentException: No matching method found: listFiles > at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:62) > at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:26) > at clojure.lang.Compiler$InstanceMethodExpr.eval(Compiler.java:1087) > at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:2568) > at clojure.lang.Compiler.eval(Compiler.java:3780) > at clojure.lang.Repl.main(Repl.java:75) > > If I don't include the filter in the call to the listFiles method, then it > works fine. > Did the def of filter succeed for you? When I tried your code, I got an error "Name conflict, can't def filter because namespace: user refers to:#'clojure/filter". Then if I proceed and try to do the map operation, I get the no matching method found error because filter is the fn clojure/filter, not a FilenameFilter. --Shawn --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Proxy question
Hi Shawn, Huh, I *thought* the def worked before, I could have sworn that it did, but now that I try it again I got the same error as you did. Once I renamed it the proxy works as I would expect. Thanks for trying it out, and apologies for the noise. :) -tree On Sun, Sep 7, 2008 at 7:45 PM, Shawn Hoover <[EMAIL PROTECTED]> wrote: > > On Sun, Sep 7, 2008 at 2:55 PM, Tom Emerson <[EMAIL PROTECTED]> wrote: > >> Hi folks, >> I'm trying to use the proxy support to provide a filter to >> java.io.File#listFiles and am not having any luck: I'm sure I'm doing >> something stupid, and would appreciate some tips. Here's what I'm doing: >> >> (import '(java.io File FilenameFilter)) >> >> (def filter (proxy [FilenameFilter] [] >> (accept [dir name] >> (. name (endsWith "_2.jpg" >> >> (def the-dir (new File "/Users/tree/images")) >> >> (map #(. %1 getCanonicalPath) >> (. the-dir (listFiles filter))) >> >> >> When I evaluate this, I get an IllegalArgumentException: >> >> java.lang.IllegalArgumentException: No matching method found: listFiles >> java.lang.IllegalArgumentException: No matching method found: listFiles >> at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:62) >> at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:26) >> at clojure.lang.Compiler$InstanceMethodExpr.eval(Compiler.java:1087) >> at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:2568) >> at clojure.lang.Compiler.eval(Compiler.java:3780) >> at clojure.lang.Repl.main(Repl.java:75) >> >> If I don't include the filter in the call to the listFiles method, then it >> works fine. >> > > Did the def of filter succeed for you? When I tried your code, I got an > error "Name conflict, can't def filter because namespace: user refers > to:#'clojure/filter". Then if I proceed and try to do the map operation, I > get the no matching method found error because filter is the fn > clojure/filter, not a FilenameFilter. > > --Shawn > > > > -- Tom Emerson [EMAIL PROTECTED] http://www.dreamersrealm.net/~tree --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Proxy Bug?
Hi,
On 30 Okt., 00:31, ntupel <[EMAIL PROTECTED]> wrote:
> Consider the following code which attempts to redefine clojure/*out*:
> (def output-stream
> (let [buffer (new java.io.ByteArrayOutputStream)]
> (proxy [java.io.OutputStream] []
> (flush []
> (.append output (.toString buffer "UTF-8"))
> (.reset buffer))
> (write [x]
> (when (>= (.size buffer) 32)
> (.flush this))
> (.write buffer x))
> (write [x off len]
> (.write buffer x off len)
> ...
> However if I omit the second write method in the proxy definition,
> I get the following error:
I think the problem here the second write. The syntax should be the
same as for defns.
(def output-stream
(let [buffer (new java.io.ByteArrayOutputStream)]
(proxy [java.io.OutputStream] []
(flush
[]
(.append output (.toString buffer "UTF-8"))
(.reset buffer))
(write
([x]
(when (>= (.size buffer) 32)
(.flush this))
(.write buffer x))
([x off len]
(.write buffer x off len))
I'm not sure what happens in your case, but my suspicion is, that
the second overwrites the first, or that it may be equivalent to
this form.
However when you new remove the second form, there is still a write
method! However this one takes the wrong number of arguments. Hence
the method of the super class is not called and you get the Exception.
But proxy-super to the rescue: You may try the following snippet
for the write method:
(write
([x]
(when (>= (.size buffer) 32)
(.flush this))
(.write buffer x))
([x off len]
(proxy-super write x off len)))
Since there is a write method, we have to call the super-class'
method explicitely.
Hope this helps.
Sincerely
Meikel
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Proxy Bug?
On Wed, 2008-10-29 at 23:44 -0700, mb wrote: > But proxy-super to the rescue: You may try the following snippet > for the write method: Nice. Never heard of proxy-super before. Would be nice to mention it on the Java interop page and not only on the API page. > >(write > ([x] > (when (>= (.size buffer) 32) > (.flush this)) > (.write buffer x)) > ([x off len] > (proxy-super write x off len))) > > Since there is a write method, we have to call the super-class' > method explicitely. Tried it but it fails with: java.lang.reflect.InvocationTargetException (NO_SOURCE_FILE:0) at clojure.lang.Compiler.eval(Compiler.java:4122) at clojure.lang.Repl.main(Repl.java:91) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:86) at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:28) at test.fn__2490$fn__2492$fn__2495.invoke(test.clj:18) at clojure.proxy_call_with_super__2077.invoke(proxy.clj:264) at test.fn__2490$fn__2492.invoke(test.clj:18) at clojure.lang.Proxy__2503.write(Unknown Source) at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202) at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:272) at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:276) at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:122) at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:212) at clojure.flush__906.invoke(boot.clj:1658) at clojure.prn__909.doInvoke(boot.clj:1667) at clojure.lang.RestFn.invoke(RestFn.java:413) at user.eval__2507.invoke(Unknown Source) at clojure.lang.Compiler.eval(Compiler.java:4111) ... 1 more Caused by: java.lang.AbstractMethodError: java.io.OutputStream.write(I)V at clojure.lang.Proxy__2503.write(Unknown Source) at java.io.OutputStream.write(OutputStream.java:99) at clojure.lang.Proxy__2503.write(Unknown Source) ... 21 more Interestingly java.io.OutputStream.write(I)V is invoked even though this should be covered by the proxy write method. > Hope this helps. Despite the error it did. Thanks! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Proxy Bug?
Hi, On 30 Okt., 08:48, ntupel <[EMAIL PROTECTED]> wrote: > Interestingly java.io.OutputStream.write(I)V is invoked even though this > should be covered by the proxy write method. I lookep up the implementation of proxy-super. It replaces the method temporarily. So proxy-super basically doesn't work for methods with multiple implementations for different arglists, since only the actually called method-arglist combination is then in effect. I think it throws the Exception because now, the first implementation is missing and it is abstract in the superclass. But I might be on the wrong track here. I'm not very familiar with Java. Let alone with reflection and stuff... Sincerely Meikel --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Proxy Bug?
On Thu, 2008-10-30 at 01:37 -0700, mb wrote: > I lookep up the implementation of proxy-super. It replaces the > method temporarily. So proxy-super basically doesn't work for > methods with multiple implementations for different arglists, > since only the actually called method-arglist combination is > then in effect. I think it throws the Exception because now, > the first implementation is missing and it is abstract in the > superclass. Yes, after I looked into proxy-super I came to the the same conclusion. I wonder though what can be done about this limitation of the proxy approach, as according to the documentation of proxy, access to super can not be proxied. What a pity. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Proxy questions
On Dec 2, 12:51 pm, Andrés M. Quijano <[EMAIL PROTECTED]> wrote:
> Hi
>
> I'm trying to use Clojure with ApacheMINA. I think Clojure it's the
> ideal language to concurrently handle all the events that arrive
> intoMINA'sseparate threads.
Hi Andrés,
I bumped into Mina a couple of weeks ago, and was thinking that might
be interesting to use a non-blocking IO library from Clojure. I'm not
sure about the ideal design for coupling the Concurrency features of
Clojure with the effectful NIO Mina classes. I would be happy to
discuss it though if anyone has bright ideas ;-)
Anyway, I've managed to run the 'MinaTimeServer' from
http://mina.apache.org/mina-v20-quick-start-guide.html by implementing
the server and handler in Clojure and using the new (AOT) compile
feature to generate classes.
I've attached a zip with the source together with a 'trace' of me
making it run, which should be easy to follow...
zip: http://groups.google.com/group/clojure/web/echo-mina.zip
Kind Regards,
- Karl
Some source:
;;mina.clj
(ns clojure.examples.mina
(:gen-class)
(:import (org.apache.mina.core.session IdleStatus)
(org.apache.mina.core.service IoAcceptor)
(java.nio.charset Charset)
(java.net InetSocketAddress)
(org.apache.mina.filter.codec ProtocolCodecFilter)
(org.apache.mina.filter.codec.textline TextLineCodecFactory)
(org.apache.mina.filter.logging LoggingFilter)
(org.apache.mina.transport.socket.nio NioSocketAcceptor)))
(defn -main [s]
(doto (NioSocketAcceptor.)
(.. getFilterChain (addLast "logger" (LoggingFilter.)))
(.. getFilterChain (addLast "codec" (ProtocolCodecFilter.
(TextLineCodecFactory. (.forName Charset "UTF-8")
(.setHandler (clojure.examples.timeserverhandler.))
(.. getSessionConfig (setReadBufferSize 2048))
(.. getSessionConfig (setIdleTime (.BOTH_IDLE IdleStatus) 10))
(.bind (InetSocketAddress. 9123
;;timerserverhandler.clj
(ns clojure.examples.timeserverhandler
(:gen-class
:constructors {[] []}
:extends org.apache.mina.core.service.IoHandlerAdapter)
(:import (org.apache.mina.core.session IdleStatus
IoSession)
(org.apache.mina.core.service IoHandlerAdapter)))
(defn -exceptionCaught
[this, ses, cau]
(.printStackTrace cau))
(defn -messageReceived
[this, ses, msg]
(prn msg))
(defn -sessionIdle
[this, ses, stat]
(prn "IDLE"))
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: Proxy questions
Just tried the zip file link. I forgot to put the trace :-( Sry, I've uploaded another zip file hoping it would overwrite the other. Alas, it didn't. So here is the new zip: http://groups.google.com/group/clojure/web/echo-mina%20%282%29.zip --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
[ANN] proxy-plus: Faster and more usable replacement for "proxy"
proxy+ is a replacement for Clojure's proxy that's faster and more usable. proxy has a strange implementation where it overrides every possible method and uses a mutable field to store a map of string -> function for dispatching the methods. This causes it to be unable to handle methods with the same name but different arities. proxy+ fixes these issues with proxy. Usage is like reify, and it's up to 10x faster. *Repository: *https://github.com/redplanetlabs/proxy-plus -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/6d9bf48a-c5b5-417a-9f66-aa494cc38346%40googlegroups.com.
Re: [ANN] proxy-plus: Faster and more usable replacement for "proxy"
Bravo 👏 Are there any differences in behavior to be aware of? AOT, Graal, consuming proxy+ classes from vanilla clojure classes? On Mon, Jan 13, 2020, 11:47 AM Nathan Marz wrote: > proxy+ is a replacement for Clojure's proxy that's faster and more usable. > proxy has a strange implementation where it overrides every possible method > and uses a mutable field to store a map of string -> function for > dispatching the methods. This causes it to be unable to handle methods with > the same name but different arities. > > proxy+ fixes these issues with proxy. Usage is like reify, and it's up to > 10x faster. > > *Repository: *https://github.com/redplanetlabs/proxy-plus > > -- > 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 unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clojure/6d9bf48a-c5b5-417a-9f66-aa494cc38346%40googlegroups.com > <https://groups.google.com/d/msgid/clojure/6d9bf48a-c5b5-417a-9f66-aa494cc38346%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/CAFw7CQJo8fGyqsbpW1YTPT0t10ckiTDkR4%3DN-NL%2B9uR1e1t17A%40mail.gmail.com.
Re: [ANN] proxy-plus: Faster and more usable replacement for "proxy"
No differences in behavior except for API being like reify. It integrates with AOT and can be consumed just like any other class. No idea how it interacts with Graal. On Monday, January 13, 2020 at 12:29:35 PM UTC-5, John Newman wrote: > > Bravo 👏 > > Are there any differences in behavior to be aware of? AOT, Graal, > consuming proxy+ classes from vanilla clojure classes? > > On Mon, Jan 13, 2020, 11:47 AM Nathan Marz > wrote: > >> proxy+ is a replacement for Clojure's proxy that's faster and more >> usable. proxy has a strange implementation where it overrides every >> possible method and uses a mutable field to store a map of string -> >> function for dispatching the methods. This causes it to be unable to handle >> methods with the same name but different arities. >> >> proxy+ fixes these issues with proxy. Usage is like reify, and it's up to >> 10x faster. >> >> *Repository: *https://github.com/redplanetlabs/proxy-plus >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@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 >> clo...@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 unsubscribe from this group and stop receiving emails from it, send an >> email to clo...@googlegroups.com . >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/clojure/6d9bf48a-c5b5-417a-9f66-aa494cc38346%40googlegroups.com >> >> <https://groups.google.com/d/msgid/clojure/6d9bf48a-c5b5-417a-9f66-aa494cc38346%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/a39e0803-2a07-447c-ba8b-7c47f243d83b%40googlegroups.com.
Re: [ANN] proxy-plus: Faster and more usable replacement for "proxy"
I skimmed the code, I don't really understand how it makes it faster over proxy. Is it the generated ASM is better? What's the in-a-nutshell description of how it works? On Monday, January 13, 2020 at 1:28:46 PM UTC-5, Nathan Marz wrote: > > No differences in behavior except for API being like reify. It integrates > with AOT and can be consumed just like any other class. No idea how it > interacts with Graal. > > On Monday, January 13, 2020 at 12:29:35 PM UTC-5, John Newman wrote: >> >> Bravo 👏 >> >> Are there any differences in behavior to be aware of? AOT, Graal, >> consuming proxy+ classes from vanilla clojure classes? >> >> On Mon, Jan 13, 2020, 11:47 AM Nathan Marz wrote: >> >>> proxy+ is a replacement for Clojure's proxy that's faster and more >>> usable. proxy has a strange implementation where it overrides every >>> possible method and uses a mutable field to store a map of string -> >>> function for dispatching the methods. This causes it to be unable to handle >>> methods with the same name but different arities. >>> >>> proxy+ fixes these issues with proxy. Usage is like reify, and it's up >>> to 10x faster. >>> >>> *Repository: *https://github.com/redplanetlabs/proxy-plus >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@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 >>> clo...@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 unsubscribe from this group and stop receiving emails from it, send >>> an email to clo...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/clojure/6d9bf48a-c5b5-417a-9f66-aa494cc38346%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/clojure/6d9bf48a-c5b5-417a-9f66-aa494cc38346%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/1fdbb59a-73b5-4a79-94b1-6769578fe019%40googlegroups.com.
Re: [ANN] proxy-plus: Faster and more usable replacement for "proxy"
The speedup comes from proxy+ directly overriding methods with the provided implementation, while Clojure's proxy has additional indirection. For example, if you do (proxy [Object] [] (toString [] "hello")), the bytecode for toString is: public java.lang.String toString(); 0 aload_0 [this] 1 getfield user.proxy$java.lang.Object$ff19274a.__clojureFnMap : clojure.lang.IPersistentMap [16] 4 ldc [52] 6 invokestatic clojure.lang.RT.get(java.lang.Object, java.lang.Object) : java.lang.Object [36] 9 dup 10 ifnull 28 13 checkcast clojure.lang.IFn [38] 16 aload_0 [this] 17 invokeinterface clojure.lang.IFn.invoke(java.lang.Object) : java.lang.Object [55] [nargs: 2] 22 checkcast java.lang.String [57] 25 goto 33 28 pop 29 aload_0 [this] 30 invokespecial java.lang.Object.toString() : java.lang.String [59] 33 areturn Clojure keeps the implementations in a map, and for every dispatch it does a map lookup by the method name. This is also why it can't handle overriding the same method name with different arities. For (proxy+ [] Object (toString [this] "hello")), the bytecode is: public java.lang.String toString(); 0 aload_0 [this] 1 getfield user.proxy_plus5358.toString5357 : clojure.lang.IFn [19] 4 aload_0 [this] 5 invokeinterface clojure.lang.IFn.invoke(java.lang.Object) : java.lang.Object [30] [nargs: 2] 10 checkcast java.lang.String [32] 13 areturn The implementation function is stored as a field, so the cost of dispatch is a field get rather than a map lookup. Clojure's proxy also overrides *every* available method in all superclasses/interfaces, while proxy+ only overrides what you specify. So proxy+ generates much smaller classes than proxy. On Tuesday, January 14, 2020 at 10:30:32 AM UTC-5, Brent Millare wrote: > > I skimmed the code, I don't really understand how it makes it faster over > proxy. Is it the generated ASM is better? What's the in-a-nutshell > description of how it works? > > On Monday, January 13, 2020 at 1:28:46 PM UTC-5, Nathan Marz wrote: >> >> No differences in behavior except for API being like reify. It integrates >> with AOT and can be consumed just like any other class. No idea how it >> interacts with Graal. >> >> On Monday, January 13, 2020 at 12:29:35 PM UTC-5, John Newman wrote: >>> >>> Bravo 👏 >>> >>> Are there any differences in behavior to be aware of? AOT, Graal, >>> consuming proxy+ classes from vanilla clojure classes? >>> >>> On Mon, Jan 13, 2020, 11:47 AM Nathan Marz wrote: >>> >>>> proxy+ is a replacement for Clojure's proxy that's faster and more >>>> usable. proxy has a strange implementation where it overrides every >>>> possible method and uses a mutable field to store a map of string -> >>>> function for dispatching the methods. This causes it to be unable to >>>> handle >>>> methods with the same name but different arities. >>>> >>>> proxy+ fixes these issues with proxy. Usage is like reify, and it's up >>>> to 10x faster. >>>> >>>> *Repository: *https://github.com/redplanetlabs/proxy-plus >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Clojure" group. >>>> To post to this group, send email to clo...@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 >>>> clo...@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 unsubscribe from this group and stop receiving emails from it, send >>>> an email to clo...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/clojure/6d9bf48a-c5b5-417a-9f66-aa494cc38346%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/clojure/6d9bf48a-c5b5-417a-9f66-aa494cc38346%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/6793548f-0bc9-4c10-8e5c-cf235aaaccce%40googlegroups.com.
Re: [ANN] proxy-plus: Faster and more usable replacement for "proxy"
Thanks this is wonderful! Nice work On Tuesday, January 14, 2020 at 11:58:17 AM UTC-5, Nathan Marz wrote: > > The speedup comes from proxy+ directly overriding methods with the > provided implementation, while Clojure's proxy has additional indirection. > For example, if you do (proxy [Object] [] (toString [] "hello")), the > bytecode for toString is: > > public java.lang.String toString(); > > 0 aload_0 [this] > > 1 getfield user.proxy$java.lang.Object$ff19274a.__clojureFnMap : > clojure.lang.IPersistentMap [16] > > 4 ldc [52] > > 6 invokestatic clojure.lang.RT.get(java.lang.Object, > java.lang.Object) : java.lang.Object [36] > > 9 dup > > 10 ifnull 28 > > 13 checkcast clojure.lang.IFn [38] > > 16 aload_0 [this] > > 17 invokeinterface clojure.lang.IFn.invoke(java.lang.Object) : > java.lang.Object [55] [nargs: 2] > > 22 checkcast java.lang.String [57] > > 25 goto 33 > > 28 pop > > 29 aload_0 [this] > > 30 invokespecial java.lang.Object.toString() : java.lang.String [59] > > 33 areturn > > Clojure keeps the implementations in a map, and for every dispatch it does > a map lookup by the method name. This is also why it can't handle > overriding the same method name with different arities. > > For (proxy+ [] Object (toString [this] "hello")), the bytecode is: > > public java.lang.String toString(); > > 0 aload_0 [this] > > 1 getfield user.proxy_plus5358.toString5357 : clojure.lang.IFn [19] > > 4 aload_0 [this] > > 5 invokeinterface clojure.lang.IFn.invoke(java.lang.Object) : > java.lang.Object [30] [nargs: 2] > > 10 checkcast java.lang.String [32] > > 13 areturn > > The implementation function is stored as a field, so the cost of dispatch > is a field get rather than a map lookup. > > Clojure's proxy also overrides *every* available method in all > superclasses/interfaces, while proxy+ only overrides what you specify. So > proxy+ generates much smaller classes than proxy. > > > On Tuesday, January 14, 2020 at 10:30:32 AM UTC-5, Brent Millare wrote: >> >> I skimmed the code, I don't really understand how it makes it faster over >> proxy. Is it the generated ASM is better? What's the in-a-nutshell >> description of how it works? >> >> On Monday, January 13, 2020 at 1:28:46 PM UTC-5, Nathan Marz wrote: >>> >>> No differences in behavior except for API being like reify. It >>> integrates with AOT and can be consumed just like any other class. No idea >>> how it interacts with Graal. >>> >>> On Monday, January 13, 2020 at 12:29:35 PM UTC-5, John Newman wrote: >>>> >>>> Bravo 👏 >>>> >>>> Are there any differences in behavior to be aware of? AOT, Graal, >>>> consuming proxy+ classes from vanilla clojure classes? >>>> >>>> On Mon, Jan 13, 2020, 11:47 AM Nathan Marz wrote: >>>> >>>>> proxy+ is a replacement for Clojure's proxy that's faster and more >>>>> usable. proxy has a strange implementation where it overrides every >>>>> possible method and uses a mutable field to store a map of string -> >>>>> function for dispatching the methods. This causes it to be unable to >>>>> handle >>>>> methods with the same name but different arities. >>>>> >>>>> proxy+ fixes these issues with proxy. Usage is like reify, and it's up >>>>> to 10x faster. >>>>> >>>>> *Repository: *https://github.com/redplanetlabs/proxy-plus >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Clojure" group. >>>>> To post to this group, send email to clo...@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 >>>>> clo...@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 unsubscribe from this group and stop receiving emails from it, send >>>>> an email to clo...@googlegroups.com.
Re: [ANN] proxy-plus: Faster and more usable replacement for "proxy"
Do you have any idea about the reason that the Clojure implementation was done this way - when it obviously seems a bit limited and also slower than necessary? Just curious if there's some historical context. On Tuesday, January 14, 2020 at 11:58:17 AM UTC-5, Nathan Marz wrote: > > The speedup comes from proxy+ directly overriding methods with the > provided implementation, while Clojure's proxy has additional indirection. > For example, if you do (proxy [Object] [] (toString [] "hello")), the > bytecode for toString is: > > public java.lang.String toString(); > > 0 aload_0 [this] > > 1 getfield user.proxy$java.lang.Object$ff19274a.__clojureFnMap : > clojure.lang.IPersistentMap [16] > > 4 ldc [52] > > 6 invokestatic clojure.lang.RT.get(java.lang.Object, > java.lang.Object) : java.lang.Object [36] > > 9 dup > > 10 ifnull 28 > > 13 checkcast clojure.lang.IFn [38] > > 16 aload_0 [this] > > 17 invokeinterface clojure.lang.IFn.invoke(java.lang.Object) : > java.lang.Object [55] [nargs: 2] > > 22 checkcast java.lang.String [57] > > 25 goto 33 > > 28 pop > > 29 aload_0 [this] > > 30 invokespecial java.lang.Object.toString() : java.lang.String [59] > > 33 areturn > > Clojure keeps the implementations in a map, and for every dispatch it does > a map lookup by the method name. This is also why it can't handle > overriding the same method name with different arities. > > For (proxy+ [] Object (toString [this] "hello")), the bytecode is: > > public java.lang.String toString(); > > 0 aload_0 [this] > > 1 getfield user.proxy_plus5358.toString5357 : clojure.lang.IFn [19] > > 4 aload_0 [this] > > 5 invokeinterface clojure.lang.IFn.invoke(java.lang.Object) : > java.lang.Object [30] [nargs: 2] > > 10 checkcast java.lang.String [32] > > 13 areturn > > The implementation function is stored as a field, so the cost of dispatch > is a field get rather than a map lookup. > > Clojure's proxy also overrides *every* available method in all > superclasses/interfaces, while proxy+ only overrides what you specify. So > proxy+ generates much smaller classes than proxy. > > > On Tuesday, January 14, 2020 at 10:30:32 AM UTC-5, Brent Millare wrote: >> >> I skimmed the code, I don't really understand how it makes it faster over >> proxy. Is it the generated ASM is better? What's the in-a-nutshell >> description of how it works? >> >> On Monday, January 13, 2020 at 1:28:46 PM UTC-5, Nathan Marz wrote: >>> >>> No differences in behavior except for API being like reify. It >>> integrates with AOT and can be consumed just like any other class. No idea >>> how it interacts with Graal. >>> >>> On Monday, January 13, 2020 at 12:29:35 PM UTC-5, John Newman wrote: >>>> >>>> Bravo 👏 >>>> >>>> Are there any differences in behavior to be aware of? AOT, Graal, >>>> consuming proxy+ classes from vanilla clojure classes? >>>> >>>> On Mon, Jan 13, 2020, 11:47 AM Nathan Marz wrote: >>>> >>>>> proxy+ is a replacement for Clojure's proxy that's faster and more >>>>> usable. proxy has a strange implementation where it overrides every >>>>> possible method and uses a mutable field to store a map of string -> >>>>> function for dispatching the methods. This causes it to be unable to >>>>> handle >>>>> methods with the same name but different arities. >>>>> >>>>> proxy+ fixes these issues with proxy. Usage is like reify, and it's up >>>>> to 10x faster. >>>>> >>>>> *Repository: *https://github.com/redplanetlabs/proxy-plus >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Clojure" group. >>>>> To post to this group, send email to clo...@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 >>>>> clo...@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
Re: [ANN] proxy-plus: Faster and more usable replacement for "proxy"
Using vars lets you iterate on the impl functions without invalidating the proxy instances. I'm not sure if that was the reason, but that would be one advantage. On Wednesday, January 15, 2020 at 10:46:36 AM UTC-6, Mike Rodriguez wrote: > > Do you have any idea about the reason that the Clojure implementation was > done this way - when it obviously seems a bit limited and also slower than > necessary? Just curious if there's some historical context. > > On Tuesday, January 14, 2020 at 11:58:17 AM UTC-5, Nathan Marz wrote: >> >> The speedup comes from proxy+ directly overriding methods with the >> provided implementation, while Clojure's proxy has additional indirection. >> For example, if you do (proxy [Object] [] (toString [] "hello")), the >> bytecode for toString is: >> >> public java.lang.String toString(); >> >> 0 aload_0 [this] >> >> 1 getfield user.proxy$java.lang.Object$ff19274a.__clojureFnMap : >> clojure.lang.IPersistentMap [16] >> >> 4 ldc [52] >> >> 6 invokestatic clojure.lang.RT.get(java.lang.Object, >> java.lang.Object) : java.lang.Object [36] >> >> 9 dup >> >> 10 ifnull 28 >> >> 13 checkcast clojure.lang.IFn [38] >> >> 16 aload_0 [this] >> >> 17 invokeinterface clojure.lang.IFn.invoke(java.lang.Object) : >> java.lang.Object [55] [nargs: 2] >> >> 22 checkcast java.lang.String [57] >> >> 25 goto 33 >> >> 28 pop >> >> 29 aload_0 [this] >> >> 30 invokespecial java.lang.Object.toString() : java.lang.String [59] >> >> 33 areturn >> >> Clojure keeps the implementations in a map, and for every dispatch it >> does a map lookup by the method name. This is also why it can't handle >> overriding the same method name with different arities. >> >> For (proxy+ [] Object (toString [this] "hello")), the bytecode is: >> >> public java.lang.String toString(); >> >> 0 aload_0 [this] >> >> 1 getfield user.proxy_plus5358.toString5357 : clojure.lang.IFn [19] >> >> 4 aload_0 [this] >> >> 5 invokeinterface clojure.lang.IFn.invoke(java.lang.Object) : >> java.lang.Object [30] [nargs: 2] >> >> 10 checkcast java.lang.String [32] >> >> 13 areturn >> >> The implementation function is stored as a field, so the cost of dispatch >> is a field get rather than a map lookup. >> >> Clojure's proxy also overrides *every* available method in all >> superclasses/interfaces, while proxy+ only overrides what you specify. So >> proxy+ generates much smaller classes than proxy. >> >> >> On Tuesday, January 14, 2020 at 10:30:32 AM UTC-5, Brent Millare wrote: >>> >>> I skimmed the code, I don't really understand how it makes it faster >>> over proxy. Is it the generated ASM is better? What's the in-a-nutshell >>> description of how it works? >>> >>> On Monday, January 13, 2020 at 1:28:46 PM UTC-5, Nathan Marz wrote: >>>> >>>> No differences in behavior except for API being like reify. It >>>> integrates with AOT and can be consumed just like any other class. No idea >>>> how it interacts with Graal. >>>> >>>> On Monday, January 13, 2020 at 12:29:35 PM UTC-5, John Newman wrote: >>>>> >>>>> Bravo 👏 >>>>> >>>>> Are there any differences in behavior to be aware of? AOT, Graal, >>>>> consuming proxy+ classes from vanilla clojure classes? >>>>> >>>>> On Mon, Jan 13, 2020, 11:47 AM Nathan Marz wrote: >>>>> >>>>>> proxy+ is a replacement for Clojure's proxy that's faster and more >>>>>> usable. proxy has a strange implementation where it overrides every >>>>>> possible method and uses a mutable field to store a map of string -> >>>>>> function for dispatching the methods. This causes it to be unable to >>>>>> handle >>>>>> methods with the same name but different arities. >>>>>> >>>>>> proxy+ fixes these issues with proxy. Usage is like reify, and it's >>>>>> up to 10x faster. >>>>>> >>>>>> *Repository: *https://github.com/redplanetlabs/proxy-plus >>>>>> >>>>>> -- >>>>>> You received this mes
Re: [ANN] proxy-plus: Faster and more usable replacement for "proxy"
Ah yes. I didn't consider that. On Wednesday, January 15, 2020 at 12:31:13 PM UTC-5, Alex Miller wrote: > > Using vars lets you iterate on the impl functions without invalidating the > proxy instances. I'm not sure if that was the reason, but that would be one > advantage. > > On Wednesday, January 15, 2020 at 10:46:36 AM UTC-6, Mike Rodriguez wrote: >> >> Do you have any idea about the reason that the Clojure implementation was >> done this way - when it obviously seems a bit limited and also slower than >> necessary? Just curious if there's some historical context. >> >> On Tuesday, January 14, 2020 at 11:58:17 AM UTC-5, Nathan Marz wrote: >>> >>> The speedup comes from proxy+ directly overriding methods with the >>> provided implementation, while Clojure's proxy has additional indirection. >>> For example, if you do (proxy [Object] [] (toString [] "hello")), the >>> bytecode for toString is: >>> >>> public java.lang.String toString(); >>> >>> 0 aload_0 [this] >>> >>> 1 getfield user.proxy$java.lang.Object$ff19274a.__clojureFnMap : >>> clojure.lang.IPersistentMap [16] >>> >>> 4 ldc [52] >>> >>> 6 invokestatic clojure.lang.RT.get(java.lang.Object, >>> java.lang.Object) : java.lang.Object [36] >>> >>> 9 dup >>> >>> 10 ifnull 28 >>> >>> 13 checkcast clojure.lang.IFn [38] >>> >>> 16 aload_0 [this] >>> >>> 17 invokeinterface clojure.lang.IFn.invoke(java.lang.Object) : >>> java.lang.Object [55] [nargs: 2] >>> >>> 22 checkcast java.lang.String [57] >>> >>> 25 goto 33 >>> >>> 28 pop >>> >>> 29 aload_0 [this] >>> >>> 30 invokespecial java.lang.Object.toString() : java.lang.String >>> [59] >>> >>> 33 areturn >>> >>> Clojure keeps the implementations in a map, and for every dispatch it >>> does a map lookup by the method name. This is also why it can't handle >>> overriding the same method name with different arities. >>> >>> For (proxy+ [] Object (toString [this] "hello")), the bytecode is: >>> >>> public java.lang.String toString(); >>> >>> 0 aload_0 [this] >>> >>> 1 getfield user.proxy_plus5358.toString5357 : clojure.lang.IFn >>> [19] >>> >>> 4 aload_0 [this] >>> >>> 5 invokeinterface clojure.lang.IFn.invoke(java.lang.Object) : >>> java.lang.Object [30] [nargs: 2] >>> >>> 10 checkcast java.lang.String [32] >>> >>> 13 areturn >>> >>> The implementation function is stored as a field, so the cost of >>> dispatch is a field get rather than a map lookup. >>> >>> Clojure's proxy also overrides *every* available method in all >>> superclasses/interfaces, while proxy+ only overrides what you specify. So >>> proxy+ generates much smaller classes than proxy. >>> >>> >>> On Tuesday, January 14, 2020 at 10:30:32 AM UTC-5, Brent Millare wrote: >>>> >>>> I skimmed the code, I don't really understand how it makes it faster >>>> over proxy. Is it the generated ASM is better? What's the in-a-nutshell >>>> description of how it works? >>>> >>>> On Monday, January 13, 2020 at 1:28:46 PM UTC-5, Nathan Marz wrote: >>>>> >>>>> No differences in behavior except for API being like reify. It >>>>> integrates with AOT and can be consumed just like any other class. No >>>>> idea >>>>> how it interacts with Graal. >>>>> >>>>> On Monday, January 13, 2020 at 12:29:35 PM UTC-5, John Newman wrote: >>>>>> >>>>>> Bravo 👏 >>>>>> >>>>>> Are there any differences in behavior to be aware of? AOT, Graal, >>>>>> consuming proxy+ classes from vanilla clojure classes? >>>>>> >>>>>> On Mon, Jan 13, 2020, 11:47 AM Nathan Marz >>>>>> wrote: >>>>>> >>>>>>> proxy+ is a replacement for Clojure's proxy that's faster and more >>>>>>> usable. proxy has a strange implementation where it overrides every >>>>>>> possible method and
Re: [ANN] proxy-plus: Faster and more usable replacement for "proxy"
I tried using proxy+ for one of the proxy implementations in clojure.core, but I ran into an issue where a "too many matching methods" got thrown at macroexpansion time. The proxy I tried to replicate was PrintWriter-on <https://github.com/clojure/clojure/blob/master/src/clj/clojure/core_print.clj#L559-L581>. The exception-data contained two "write" methods that matched arity but didn't match param types. Repro below. (require '[com.rpl.proxy-plus :refer [proxy+]])) (defn ^java.io.PrintWriter proxy+test [flush-fn close-fn] (let [sb (StringBuilder.)] (-> (proxy+ [] java.io.Writer (flush [this] (when (pos? (.length sb)) (flush-fn (.toString sb))) (.setLength sb 0)) (close [this] (.flush this) (when close-fn (close-fn)) nil) (write [this ^chars str-cbuf off len] (when (pos? len) (.append sb str-cbuf ^int off ^int len java.io.BufferedWriter. java.io.PrintWriter.))) On Monday, January 13, 2020 at 11:47:06 AM UTC-5, Nathan Marz wrote: > > proxy+ is a replacement for Clojure's proxy that's faster and more usable. > proxy has a strange implementation where it overrides every possible method > and uses a mutable field to store a map of string -> function for > dispatching the methods. This causes it to be unable to handle methods with > the same name but different arities. > > proxy+ fixes these issues with proxy. Usage is like reify, and it's up to > 10x faster. > > *Repository: *https://github.com/redplanetlabs/proxy-plus > -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/bfd8e45a-4843-4422-b47f-3303ce53364e%40googlegroups.com.
Re: [ANN] proxy-plus: Faster and more usable replacement for "proxy"
Thanks. It doesn't currently use type hints to distinguish between multiple methods of the same arity. Opened an issue: https://github.com/redplanetlabs/proxy-plus/issues/1 On Monday, January 20, 2020 at 11:57:31 AM UTC-5, Ghadi Shayban wrote: > > I tried using proxy+ for one of the proxy implementations in clojure.core, > but I ran into an issue where a "too many matching methods" got thrown at > macroexpansion time. The proxy I tried to replicate was PrintWriter-on > <https://github.com/clojure/clojure/blob/master/src/clj/clojure/core_print.clj#L559-L581>. > > The exception-data contained two "write" methods that matched arity but > didn't match param types. Repro below. > > (require '[com.rpl.proxy-plus :refer [proxy+]])) > > (defn ^java.io.PrintWriter proxy+test > [flush-fn close-fn] > (let [sb (StringBuilder.)] > (-> (proxy+ [] > java.io.Writer > (flush [this] > (when (pos? (.length sb)) >(flush-fn (.toString sb))) > (.setLength sb 0)) > (close [this] > (.flush this) > (when close-fn (close-fn)) > nil) > (write [this ^chars str-cbuf off len] > (when (pos? len) >(.append sb str-cbuf ^int off ^int len > java.io.BufferedWriter. > java.io.PrintWriter.))) > > On Monday, January 13, 2020 at 11:47:06 AM UTC-5, Nathan Marz wrote: >> >> proxy+ is a replacement for Clojure's proxy that's faster and more >> usable. proxy has a strange implementation where it overrides every >> possible method and uses a mutable field to store a map of string -> >> function for dispatching the methods. This causes it to be unable to handle >> methods with the same name but different arities. >> >> proxy+ fixes these issues with proxy. Usage is like reify, and it's up to >> 10x faster. >> >> *Repository: *https://github.com/redplanetlabs/proxy-plus >> > -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/aae86211-1bc6-41db-9122-291b48f81a18%40googlegroups.com.
Doc suggestion: java interop page, proxy section should mention proxy-super
I think the docs at http://clojure.org/java_interop#toc25 should include a description of proxy-super as well as proxy. --Steve smime.p7s Description: S/MIME cryptographic signature
Proxy vs. glue class
Hi, I am trying to understand what the best course of action would be in the following scenario: I have a Java base class that I need to extend. The class is fundamental to my application and will be running fairly hot compared to other bits of code in the application. Therefore I want it to execute as fast as possible. The way I see it there are two options; 1) Use proxy 2) Create a class in Java that provides the glue between Java and Clojure and removes the need for extending the base class in Clojure. I would prefer to use option 1 but I am a little bit worried about the performance implications of doing so, especially adding a level of indirection by using map-lookup for accessing methods so I suspect I will have to go with option 2. Any recommendations or alternatives? 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Calling proxy without reflection
Let's say I have a proxy object: (def p (proxy [MyClass MyInterface] (interfaceMethod [this] ...))) Now, I want to call (.interfaceMethod p). How do I do this without reflection? I would have thought that (.interfaceMethod ^MyInterface p) would work, but this results in an error message that this proxy object cannot be cast to MyInterface. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
ClojureScript repl over proxy
Hi, I'm using a cloud development platform (Gitpod) and it automatically creates proxy from public URL to localhost, so you can develop a web application from cloud and see the result. I'm trying to run cljs REPL, but it fails to connect because it tries to connect to the REPL on `localhost:9090` which is not accessible from outside because I use public URL in a browser. I have looked at the code and looks like HOST and PORT in browser hard-coded https://github.com/clojure/clojurescript/blob/a4673b880756531ac5690f7b4721ad76c0810327/src/main/cljs/clojure/browser/repl.cljs#L31 but still maybe I have missed something, and it's possible to set up REPL for my use case. So would be glad to any response 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/df1f05bc-8810-42ef-9002-66192227e6f0n%40googlegroups.com.
Method overloading & proxy method
Hello there, Iv been trying to implement a proxy on a class ( http://code.google.com/p/javaparser/source/browse/trunk/JavaParser/src/japa/parser/ast/visitor/VoidVisitorAdapter.java?spec=svn77&r=77) that has multiple overloaded methods (same arity different types), trying (defn create-visitor [] (proxy [VoidVisitorAdapter] [] (visit [method, arg] (println method)) (visit [exp, arg] (println type This results with compilation error Caused by: java.lang.IllegalArgumentException: Method 'visit' redefined. Type hints didn't help either: (defn create-visitor [] (proxy [VoidVisitorAdapter] [] (visit [#^MethodDeclaration method, arg] (println method)) (visit [#^AssignExpr exp, arg] (println type Any ideas? Thanx --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
classloading / proxy / JMX issue
I have a failing test in the JMX server code [1]:
(deftest dynamic-mbean
(let [mbean-name "clojure.contrib.test_contrib.test_jmx:name=Foo"]
(jmx/register-mbean
(jmx/dynamic-mbean
(ref {:string-attribute "a-string"}))
mbean-name)
(is (= "a-string" (jmx/read mbean-name :string-attribute)
The weird thing is, the same exact code works from the REPL. The
second weird thing is, the error is a permissions error (and no
SecurityManager is installed).
In the interest of decency, I will show only a fraction of the stack
trace:
actual: java.security.AccessControlException: access denied
(javax.management.MBeanTrustPermission register)
[java] at java.security.AccessControlContext.checkPermission
(AccessControlContext.java:264)
java.lang.SecurityManager.checkPermission (SecurityManager.java:568)
com
.sun
.jmx
.interceptor.DefaultMBeanServerInterceptor.checkMBeanTrustPermission
(DefaultMBeanServerInterceptor.java:1724)
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean
(DefaultMBeanServerInterceptor.java:335)
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean
(JmxMBeanServer.java:497)
sun.reflect.NativeMethodAccessorImpl.invoke0
(NativeMethodAccessorImpl.java:-2)
sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke (Method.java:585)
clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:90)
clojure.lang.Reflector.invokeInstanceMethod (Reflector.java:28)
clojure.contrib.jmx/register_mbean (server.clj:17)
Since the code works at the REPL, I suspect a classloader issue. Am I
right? If so, can I change the classloader used by Clojure's proxy
function?
Stu
[1]
http://github.com/richhickey/clojure-contrib/commit/5c2276dede95163b99327e77c21adf95825e0b51
. Note this is on the jmx branch.
--~--~-~--~~~---~--~~
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: proxy and annotation
Currently clojure doesn't support annotations, which is a huge issue at
times when integrating with some newer java frameworks.
I'm not sure if anyones working on it yet either, and to be honest I'm not
even sure what syntax would work well - something encoded in the metadata
woud be good I guess.
--
On Mon, Aug 24, 2009 at 7:10 PM, ngocdaothanh wrote:
> How can I set @ChannelPipelineCoverage("one") for the "handler"
>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Syntax for proxy methods?
Can someone please advise me if this is possible:
// --- IX.java ---
interface IX
{
void doit();
void doit(int n);
}
; --- x.clj ---
(def prx (proxy [IX][]
(doit
([] (doseq [x someSeq] (doit x))
([y] (print y
When I tried something of this form, it looks like the call of the 1-
arg function from the 0-arg function can't be resolved.
Thanks in advance
--~--~-~--~~~---~--~~
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: reify vs proxy
On 28/05/12 11:48, Jim - FooBar(); wrote: Hello everyone, I know this is trivial but i just noticed that, unlike proxy, reify demands that at least the return types are consistent. I had a piece of code like this: (defmacro implement-CalculateScore "Consumer convenience for implementing the CalculateScore interface which is needed for genetic and simulated annealing training." [minimize? & body] `(proxy [CalculateScore] [] ;;no base class (calculateScore [this ^MLRegression n#] ~@body) (shouldMinimize [this] ~minimize?))) -- and in order to use reify instead of proxy i had to type hint the return types like this: (defmacro implement-CalculateScore "Consumer convenience for implementing the CalculateScore interface which is needed for genetic and simulated annealing training." [minimize? & body] `(reify CalculateScore (^double calculateScore [this ^MLRegression n#] ~@body) (^boolean shouldMinimize [this] ~minimize?))) Is this something you would all expect?If yes can somebody elaborate as to why that is? Thanks in advance... Jim Ooops!!! I know that the proxy version does not need 'this' in the argument list...bad copy-paste error! I apologise... 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
Help with proxy method
I'm porting some code from Java to Clojure but I'm still stuck porting a JComponent. The original code is here: http://github.com/Serabe/RMagick4J/blob/master/Magick4J/src/magick4j/MagickImage.java#L282 It is quite simple, I just need it to display an image. I implemented the JComponent using the proxy method: http://github.com/Serabe/rinzelight/blob/master/src/rinzelight/display_image.clj#L15 it is configured in the method configured-jcomponent which is called in display-fn, adding it to a JFrame. That JFrame is showed but the image is not being displayed. Any tip? Thanks, Serabe -- http://sergio.arbeo.net http://www.serabe.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 To unsubscribe, reply using "remove me" as the subject.
Re: proxy with dynamic
On Dec 25, 12:45 am, Razvan Rotaru wrote: > Hi, > > Is it possible to give the class as value at runtime to proxy? > > (defn create-proxy [clazz] > (proxy [clazz] )) > > I know this can be done with a macro, but my question is whether it > can be done as function. Presumably you just tried it and found it doesn't work, so I'm not sure what more you're looking for here. How would you even fill in the body of the proxy? "I don't know what class this is, but I know exactly what methods I need to override"? Probably you need to rethink some things to get a design that doesn't require something so magical, but eval is always available to you if you have some reason to believe you require magic. -- 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: proxy with dynamic
On Dec 25, 12:01 pm, Alan Malloy wrote: > > Presumably you just tried it and found it doesn't work, so I'm not > sure what more you're looking for here. How would you even fill in the > body of the proxy? "I don't know what class this is, but I know > exactly what methods I need to override"? Probably you need to rethink > some things to get a design that doesn't require something so magical, > but eval is always available to you if you have some reason to believe > you require magic. Yes, eval. I forgot about it. Eval is something I categorized as dangerous in my mind a long time ago, and decided never to use it. It seems that I also erased it from my memory. :) My expectation here is that proxy expects a value which for the base class, which is a java class (an instance of java.lang.Class), and I'd like to pass this value as a function parameter. >From design point of view, my proxy contruct tries to add an interface to a class. (Like a mixin). The interface is always the same (and therefore the methods), but the class can be anything, and i'd like to have it as a parameter to the function. Macros work fine, but I want to try to have it as a function. Razvan -- 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: proxy with dynamic
Hi, Am 25.12.2011 um 11:46 schrieb Razvan Rotaru: > Macros work fine, but I want to try to have it as a function. Wiring to classes happens in the bytecode and hence have to be known at compile time. You either have to use eval or refrain from doing things at runtime. Is the class transferred into your program at runtime without knowing it up-front? If not, macros should sufficient. Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: proxy with dynamic
On Dec 25, 1:17 pm, Meikel Brandmeyer wrote: > Hi, > > Wiring to classes happens in the bytecode and hence have to be known at > compile time. You either have to use eval or refrain from doing things at > runtime. Is the class transferred into your program at runtime without > knowing it up-front? If not, macros should sufficient. > > Sincerely > Meikel I'm not sure I understand your question. The class is known, but it's transfered as an instance of java.lang.Class. I also don't quite understand your argument. Clojure creates classes dynamically (e.g. deftype), so why not create a proxy dynamically? Razvan -- 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: proxy with dynamic
Hi, Am 25.12.2011 um 13:03 schrieb Razvan Rotaru: > I'm not sure I understand your question. The class is known, but it's > transfered as an instance of java.lang.Class. > I also don't quite understand your argument. Clojure creates classes > dynamically (e.g. deftype), so why not create a proxy dynamically? But deftype is a macro. It creates the bytecode required for the new type when the deftype form is run by the compiler. A function is different: it is run at the runtime of the program. Also deftype would not get the class as Class. When you for example implement an interface in your deftype, it does not get that interface as Class, but as Symbol. user=> (defn my-fn [x] (class x)) #'user/my-fn user=> (my-fn String) java.lang.Class user=> (defmacro my-macro [x] (class x)) #'user/my-macro user=> (my-macro String) clojure.lang.Symbol That's why you can't do this. (defn with-dynamic-macro-call [klass] (my-macro klass)) (with-dynamic-macro-call String) (my-macro (class "")) The macro will see the symbol “klass” and not its “contents” – the class String. In the second example it's similar: the macro sees the list containing the symbol “class” and the empty string. Not the result of the function call. Does that clarify things a little? Sincerely Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: proxy with dynamic
Yes, it's more clear now. 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
Re: proxy and java.io.Writer
On Sun, Jan 30, 2011 at 9:26 AM, Jonas Enlund wrote: > Hi. > I'm trying to create a java.io.Writer proxy (which writes to a > JTextArea) but I can't get it to work. > Here is my clojure code so far: > > (def text-area (javax.swing.JTextArea.)) > > (def frame > (let [f (javax.swing.JFrame.)] > (.. f getContentPane (add text-area)) > (.setMinimumSize f (java.awt.Dimension. 200 200)) > (.setVisible f true) > f)) > > (def text-area-writer > (proxy [java.io.Writer] [] > (close []) > (flush []) > (write [^chars chrs ^int offs ^int len] > (.append text-area (String. chrs offs len) > > When I load the code above I get an "IllegalArgumentException: Unable > to resolve classname: int" so I think I'm not type hinting correctly. Indeed. You can't (in 1.2 at least) type hint "int" though you can "ints" (array of int). Note that int is a primitive type while array of int is a reference type. Type hinting as Integer shouldn't throw exceptions, but you can probably omit all but the chars hint and have the correct String constructor overload selected. Also note that while text area .append is safe to call from off the EDT, other Swing methods mostly aren't, and it's something to watch for if you do anything similar to this with other Swing components, and wherever you construct your text area and its surrounds. -- 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: proxy and java.io.Writer
On Sun, Jan 30, 2011 at 7:01 PM, Ken Wesson wrote: > On Sun, Jan 30, 2011 at 9:26 AM, Jonas Enlund wrote: >> Hi. >> I'm trying to create a java.io.Writer proxy (which writes to a >> JTextArea) but I can't get it to work. >> Here is my clojure code so far: >> >> (def text-area (javax.swing.JTextArea.)) >> >> (def frame >> (let [f (javax.swing.JFrame.)] >> (.. f getContentPane (add text-area)) >> (.setMinimumSize f (java.awt.Dimension. 200 200)) >> (.setVisible f true) >> f)) >> >> (def text-area-writer >> (proxy [java.io.Writer] [] >> (close []) >> (flush []) >> (write [^chars chrs ^int offs ^int len] >> (.append text-area (String. chrs offs len) >> >> When I load the code above I get an "IllegalArgumentException: Unable >> to resolve classname: int" so I think I'm not type hinting correctly. > > Indeed. You can't (in 1.2 at least) type hint "int" though you can > "ints" (array of int). Note that int is a primitive type while array > of int is a reference type. > > Type hinting as Integer shouldn't throw exceptions, but you can > probably omit all but the chars hint and have the correct String > constructor overload selected. I tried with 1.3.0-alpha5. With type hints I get "CompilerException java.lang.IllegalArgumentException: Only long and double primitives are supported". If I only keep the ^chars hint I get an ArityException when I do (.write text-area-writer "hello"). Is this problem unsolvable with proxy? Should I look into gen-class and AOT compilation instead? > > Also note that while text area .append is safe to call from off the > EDT, other Swing methods mostly aren't, and it's something to watch > for if you do anything similar to this with other Swing components, > and wherever you construct your text area and its surrounds. > > -- > 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: proxy and java.io.Writer
On Sun, Jan 30, 2011 at 1:35 PM, Jonas Enlund wrote: > On Sun, Jan 30, 2011 at 7:01 PM, Ken Wesson wrote: >> On Sun, Jan 30, 2011 at 9:26 AM, Jonas Enlund wrote: >>> Hi. >>> I'm trying to create a java.io.Writer proxy (which writes to a >>> JTextArea) but I can't get it to work. >>> Here is my clojure code so far: >>> >>> (def text-area (javax.swing.JTextArea.)) >>> >>> (def frame >>> (let [f (javax.swing.JFrame.)] >>> (.. f getContentPane (add text-area)) >>> (.setMinimumSize f (java.awt.Dimension. 200 200)) >>> (.setVisible f true) >>> f)) >>> >>> (def text-area-writer >>> (proxy [java.io.Writer] [] >>> (close []) >>> (flush []) >>> (write [^chars chrs ^int offs ^int len] >>> (.append text-area (String. chrs offs len) >>> >>> When I load the code above I get an "IllegalArgumentException: Unable >>> to resolve classname: int" so I think I'm not type hinting correctly. >> >> Indeed. You can't (in 1.2 at least) type hint "int" though you can >> "ints" (array of int). Note that int is a primitive type while array >> of int is a reference type. >> >> Type hinting as Integer shouldn't throw exceptions, but you can >> probably omit all but the chars hint and have the correct String >> constructor overload selected. > > I tried with 1.3.0-alpha5. With type hints I get "CompilerException > java.lang.IllegalArgumentException: Only long and double primitives > are supported". If I only keep the ^chars hint I get an ArityException > when I do (.write text-area-writer "hello"). Does it work with 1.2? Where exactly is the ArityException being thrown -- for what function or method? -- 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: proxy and java.io.Writer
On Sun, Jan 30, 2011 at 8:39 PM, Ken Wesson wrote: > On Sun, Jan 30, 2011 at 1:35 PM, Jonas Enlund wrote: >> On Sun, Jan 30, 2011 at 7:01 PM, Ken Wesson wrote: >>> On Sun, Jan 30, 2011 at 9:26 AM, Jonas Enlund >>> wrote: >>>> Hi. >>>> I'm trying to create a java.io.Writer proxy (which writes to a >>>> JTextArea) but I can't get it to work. >>>> Here is my clojure code so far: >>>> >>>> (def text-area (javax.swing.JTextArea.)) >>>> >>>> (def frame >>>> (let [f (javax.swing.JFrame.)] >>>> (.. f getContentPane (add text-area)) >>>> (.setMinimumSize f (java.awt.Dimension. 200 200)) >>>> (.setVisible f true) >>>> f)) >>>> >>>> (def text-area-writer >>>> (proxy [java.io.Writer] [] >>>> (close []) >>>> (flush []) >>>> (write [^chars chrs ^int offs ^int len] >>>> (.append text-area (String. chrs offs len) >>>> >>>> When I load the code above I get an "IllegalArgumentException: Unable >>>> to resolve classname: int" so I think I'm not type hinting correctly. >>> >>> Indeed. You can't (in 1.2 at least) type hint "int" though you can >>> "ints" (array of int). Note that int is a primitive type while array >>> of int is a reference type. >>> >>> Type hinting as Integer shouldn't throw exceptions, but you can >>> probably omit all but the chars hint and have the correct String >>> constructor overload selected. >> >> I tried with 1.3.0-alpha5. With type hints I get "CompilerException >> java.lang.IllegalArgumentException: Only long and double primitives >> are supported". If I only keep the ^chars hint I get an ArityException >> when I do (.write text-area-writer "hello"). > > Does it work with 1.2? Where exactly is the ArityException being > thrown -- for what function or method? It didn't work in 1.2 either. Here is some more info on the exception thrown (this is with 1.3.0-alpha5) user=> (.write text-area-writer "Hello, World!") ArityException Wrong number of args (2) passed to: user$fn--38$fn clojure.lang.AFn.throwArity (AFn.java\ :439) user=> (pst) ArityException Wrong number of args (2) passed to: user$fn--38$fn user.proxy$java.io.Writer$0.write (:-1) sun.reflect.NativeMethodAccessorImpl.invoke0 (NativeMethodAccessorImpl.java:-2) sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:57) sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke (Method.java:616) clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:90) clojure.lang.Reflector.invokeInstanceMethod (Reflector.java:28) user/eval47 (NO_SOURCE_FILE:4) clojure.lang.Compiler.eval (Compiler.java:6223) clojure.lang.Compiler.eval (Compiler.java:6190) clojure.core/eval (core.clj:2680) clojure.main/repl/read-eval-print--5617 (main.clj:180) nil user=> Thanks for helping out with this Ken! > > -- > 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: proxy and java.io.Writer
On Sun, Jan 30, 2011 at 1:47 PM, Jonas Enlund wrote: > user=> (.write text-area-writer "Hello, World!") > ArityException Wrong number of args (2) passed to: user$fn--38$fn > clojure.lang.AFn.throwArity (AFn.java\ > :439) > user=> (pst) > ArityException Wrong number of args (2) passed to: user$fn--38$fn > user.proxy$java.io.Writer$0.write (:-1) > sun.reflect.NativeMethodAccessorImpl.invoke0 > (NativeMethodAccessorImpl.java:-2) > sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:57) > sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:43) > java.lang.reflect.Method.invoke (Method.java:616) > clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:90) > clojure.lang.Reflector.invokeInstanceMethod (Reflector.java:28) > user/eval47 (NO_SOURCE_FILE:4) > clojure.lang.Compiler.eval (Compiler.java:6223) > clojure.lang.Compiler.eval (Compiler.java:6190) > clojure.core/eval (core.clj:2680) > clojure.main/repl/read-eval-print--5617 (main.clj:180) > nil > user=> The proxy documentation says If a method fn is not provided for a class method, the superclass methd will be called. This doesn't seem to work if you override one of several overloads of a method. The documentation should probably be clarified to reflect that this isn't the case for overloads of a method you have overridden; it seems you have to supply one function (overloaded for arity) that implements all of the overloads, as that one function will be called for all of the overloads. This proxy works: (proxy [java.io.Writer] [] (close []) (flush []) (write ([chrs offs len] (if (string? chrs) (.append text-area (subs chrs offs (+ offs len))) (.append text-area (String. ^chars chrs offs len ([thing] (.append text-area (str thing)) The second arity handles all the overloaded .write methods with only one parameter, and the first handles the String offset length and Char-Array offset length overloads. > Thanks for helping out with this Ken! You're welcome. -- 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
Is proxy the right tool for this job ? Cyclic vector ? Proxy bug ?
I was playing around with some project euler problems, and I was thinking that the cycle function has an analog for vectors. I implemented a short simple method with the right behavior (at a simple surface level): (defn cyclic-vector [v] (fn [x] (v (mod x (count v) However, this obviously does not implement IPersistentVector. Is there any easy way to implement something like this, and delegate the rest of the behaviors to the base vector object ? I realize this is probably possible with proxy, but I have not successfully made it work yet - proxying the IPersistentVector interface results in the following for me: (proxy [clojure.lang.IPersistentVector] []) java.lang.ClassFormatError: Duplicate method name&signature in class file clojure/proxy/java/lang/Object$IPersistentVector (NO_SOURCE_FILE: 2) Is this an issue with proxy, or am I using it incorrectly ? I removed any extraneous code of my own, since the error occurs with just the minimal proxy usage shown above. I'm on trunk, revision 1326. --~--~-~--~~~---~--~~ 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 proxy the right tool for this job ? Cyclic vector ? Proxy bug ?
For your eueler problem consider using lazy functions cycle and range: user=> (take 15 (cycle (range 5))) (0 1 2 3 4 0 1 2 3 4 0 1 2 3 4) Or is there some other behavior you need to create? Regarding proxy your main problem is that IPersistentVector is an Interface (no implementation) so you would have to specify every method. More sensibly you could proxy the concrete implementation PersistentVector, however it does not have an empty constructor so you would need to figure out exactly what you want to do. user=> (proxy [clojure.lang.PersistentVector] []) java.lang.IllegalArgumentException: No matching ctor found for class clojure.proxy.clojure.lang.PersistentVector I would advise against proxying for this problem as it is complex and not in the spirit of solving the problem in Clojure. Regards. Tim. On Mar 9, 9:13 am, Paul Mooser wrote: > I was playing around with some project euler problems, and I was > thinking that the cycle function has an analog for vectors. I > implemented a short simple method with the right behavior (at a simple > surface level): > > (defn cyclic-vector [v] > (fn [x] > (v (mod x (count v) > > However, this obviously does not implement IPersistentVector. > > Is there any easy way to implement something like this, and delegate > the rest of the behaviors to the base vector object ? I realize this > is probably possible with proxy, but I have not successfully made it > work yet - proxying the IPersistentVector interface results in the > following for me: > > (proxy [clojure.lang.IPersistentVector] []) > > java.lang.ClassFormatError: Duplicate method name&signature in class > file clojure/proxy/java/lang/Object$IPersistentVector (NO_SOURCE_FILE: > 2) > > Is this an issue with proxy, or am I using it incorrectly ? I removed > any extraneous code of my own, since the error occurs with just the > minimal proxy usage shown above. I'm on trunk, revision 1326. --~--~-~--~~~---~--~~ 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 proxy the right tool for this job ? Cyclic vector ? Proxy bug ?
I actually mentioned the cycle function in my message, and that's what I was using, but the original question came up because accessing the nth item in a list takes linear rather than constant time. I'd be interested to hear how what I was attempting violates the spirit of clojure. I was trying to work within the bounds of an existing abstraction, and to implement my changes in such a way as to not break other things that consume that abstraction. Incidentally, I don't believe the error I'm getting from proxy has anything to do with IPersistentVector being an interface, since you can clearly do: (proxy [clojure.lang.IFn] []) and that works fine (although obviously is not related to solving my particular problem). On Mar 8, 5:20 pm, Timothy Pratley wrote: > For your eueler problem consider using lazy functions cycle and range: > user=> (take 15 (cycle (range 5))) > (0 1 2 3 4 0 1 2 3 4 0 1 2 3 4) > Or is there some other behavior you need to create? > > Regarding proxy your main problem is that IPersistentVector is an > Interface (no implementation) so you would have to specify every > method. More sensibly you could proxy the concrete implementation > PersistentVector, however it does not have an empty constructor so you > would need to figure out exactly what you want to do. > user=> (proxy [clojure.lang.PersistentVector] []) > java.lang.IllegalArgumentException: No matching ctor found for class > clojure.proxy.clojure.lang.PersistentVector > > I would advise against proxying for this problem as it is complex and > not in the spirit of solving the problem in Clojure. > > Regards. > Tim. > > On Mar 9, 9:13 am, Paul Mooser wrote: > > > > > I was playing around with some project euler problems, and I was > > thinking that the cycle function has an analog for vectors. I > > implemented a short simple method with the right behavior (at a simple > > surface level): > > > (defn cyclic-vector [v] > > (fn [x] > > (v (mod x (count v) > > > However, this obviously does not implement IPersistentVector. > > > Is there any easy way to implement something like this, and delegate > > the rest of the behaviors to the base vector object ? I realize this > > is probably possible with proxy, but I have not successfully made it > > work yet - proxying the IPersistentVector interface results in the > > following for me: > > > (proxy [clojure.lang.IPersistentVector] []) > > > java.lang.ClassFormatError: Duplicate method name&signature in class > > file clojure/proxy/java/lang/Object$IPersistentVector (NO_SOURCE_FILE: > > 2) > > > Is this an issue with proxy, or am I using it incorrectly ? I removed > > any extraneous code of my own, since the error occurs with just the > > minimal proxy usage shown above. I'm on trunk, revision 1326. --~--~-~--~~~---~--~~ 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 proxy the right tool for this job ? Cyclic vector ? Proxy bug ?
I feel I should clarify that I'm not trying to argue that a cyclic
vector is a great idea - it is something something I was playing with
in the midst of solving an euler problem. What I'm more interested in
is the question of how to accomplish this sort of thing ("proxying" an
existing instance, if I can call it that) in a straightforward way, if
possible, and also to understand the error message I saw upon trying
to use proxy.
--~--~-~--~~~---~--~~
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 proxy the right tool for this job ? Cyclic vector ? Proxy bug ?
Hi Paul, > I actually mentioned the cycle function in my message, and that's what > I was using, but the original question came up because accessing the > nth item in a list takes linear rather than constant time. Apologies for not reading your post carefully. Indeed I think your cyclic-vector solution is great. > I'd be interested to hear how what I was attempting violates the > spirit of clojure. I was trying to work within the bounds of an > existing abstraction, and to implement my changes in such a way as to > not break other things that consume that abstraction. Interop with Java is a real strength of Clojure. But doing so is less useful for learning Clojure and more useful for learning Java. Feel free to pursue it, Java interop is certainly not wasted effort/ knowledge. It certainly doesn't violate the spirit of Clojure, my words were intended in relation to writing Euler solutions in a non- Java way. > Incidentally, I don't believe the error I'm getting from proxy has > anything to do with IPersistentVector being an interface, since you > can clearly do: > > (proxy [clojure.lang.IFn] []) Indeed you can, but you've really just created an empty object: user=> ((proxy [clojure.lang.IFn] [])) java.lang.UnsupportedOperationException: invoke (NO_SOURCE_FILE:0) Now back to IPersistentVector for a moment: This class extends lots of interfaces. There is a name overlap between some of those Interfaces resulting in a very valid error "Duplicate method name&signature". Not a bug with proxy. Regards, Tim. --~--~-~--~~~---~--~~ 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 proxy the right tool for this job ? Cyclic vector ? Proxy bug ?
I'd suggest playing with much less complex classes for proxy first. A
very good place to start are ActionListeners from swing. This is a
really useful application of proxy - very necessary and practical...
and you only need to implement one function.
Regards,
Tim.
On Mar 9, 6:17 pm, Paul Mooser wrote:
> I feel I should clarify that I'm not trying to argue that a cyclic
> vector is a great idea - it is something something I was playing with
> in the midst of solving an euler problem. What I'm more interested in
> is the question of how to accomplish this sort of thing ("proxying" an
> existing instance, if I can call it that) in a straightforward way, if
> possible, and also to understand the error message I saw upon trying
> to use proxy.
--~--~-~--~~~---~--~~
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 proxy the right tool for this job ? Cyclic vector ? Proxy bug ?
On Mar 9, 5:04 am, Timothy Pratley wrote: > Hi Paul, > > > I actually mentioned the cycle function in my message, and that's what > > I was using, but the original question came up because accessing the > > nth item in a list takes linear rather than constant time. > > Apologies for not reading your post carefully. Indeed I think your > cyclic-vector solution is great. > > > I'd be interested to hear how what I was attempting violates the > > spirit of clojure. I was trying to work within the bounds of an > > existing abstraction, and to implement my changes in such a way as to > > not break other things that consume that abstraction. > > Interop with Java is a real strength of Clojure. But doing so is less > useful for learning Clojure and more useful for learning Java. Feel > free to pursue it, Java interop is certainly not wasted effort/ > knowledge. It certainly doesn't violate the spirit of Clojure, my > words were intended in relation to writing Euler solutions in a non- > Java way. > > > Incidentally, I don't believe the error I'm getting from proxy has > > anything to do with IPersistentVector being an interface, since you > > can clearly do: > > > (proxy [clojure.lang.IFn] []) > > Indeed you can, but you've really just created an empty object: > user=> ((proxy [clojure.lang.IFn] [])) > java.lang.UnsupportedOperationException: invoke (NO_SOURCE_FILE:0) > > Now back to IPersistentVector for a moment: > This class extends lots of interfaces. There is a name overlap between > some of those Interfaces resulting in a very valid error "Duplicate > method name&signature". Not a bug with proxy. > I really don't know why you are trying to dissuade Paul in all this. What he is trying to do is perfectly fine and it does in fact look like a bug in proxy. It is not an error to inherit a same-sig method from more than one interface, but proxy is probably generating more than one stub method, which is the error. I'm prepping for my London QCon trip and don't have time to chase this, but would appreciate it if a contributor could please file an issue and look into this. Thanks, Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Is proxy the right tool for this job ? Cyclic vector ? Proxy bug ?
Ok, working on it. Rich Hickey a écrit : > > On Mar 9, 5:04 am, Timothy Pratley wrote: > >> Hi Paul, >> >> >>> I actually mentioned the cycle function in my message, and that's what >>> I was using, but the original question came up because accessing the >>> nth item in a list takes linear rather than constant time. >>> >> Apologies for not reading your post carefully. Indeed I think your >> cyclic-vector solution is great. >> >> >>> I'd be interested to hear how what I was attempting violates the >>> spirit of clojure. I was trying to work within the bounds of an >>> existing abstraction, and to implement my changes in such a way as to >>> not break other things that consume that abstraction. >>> >> Interop with Java is a real strength of Clojure. But doing so is less >> useful for learning Clojure and more useful for learning Java. Feel >> free to pursue it, Java interop is certainly not wasted effort/ >> knowledge. It certainly doesn't violate the spirit of Clojure, my >> words were intended in relation to writing Euler solutions in a non- >> Java way. >> >> >>> Incidentally, I don't believe the error I'm getting from proxy has >>> anything to do with IPersistentVector being an interface, since you >>> can clearly do: >>> >>> (proxy [clojure.lang.IFn] []) >>> >> Indeed you can, but you've really just created an empty object: >> user=> ((proxy [clojure.lang.IFn] [])) >> java.lang.UnsupportedOperationException: invoke (NO_SOURCE_FILE:0) >> >> Now back to IPersistentVector for a moment: >> This class extends lots of interfaces. There is a name overlap between >> some of those Interfaces resulting in a very valid error "Duplicate >> method name&signature". Not a bug with proxy. >> >> > > I really don't know why you are trying to dissuade Paul in all this. > What he is trying to do is perfectly fine and it does in fact look > like a bug in proxy. It is not an error to inherit a same-sig method > from more than one interface, but proxy is probably generating more > than one stub method, which is the error. > > I'm prepping for my London QCon trip and don't have time to chase > this, but would appreciate it if a contributor could please file an > issue and look into this. > > Thanks, > > Rich > > > > > > -- Professional: http://cgrand.net/ (fr) On Clojure: http://clj-me.blogspot.com/ (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 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 proxy the right tool for this job ? Cyclic vector ? Proxy bug ?
Timothy, thanks for explaining - I respond to one specific part below: > Interop with Java is a real strength of Clojure. But doing so is less > useful for learning Clojure and more useful for learning Java. Feel > free to pursue it, Java interop is certainly not wasted effort/ > knowledge. It certainly doesn't violate the spirit of Clojure, my > words were intended in relation to writing Euler solutions in a non- > Java way. The fact that IPersistentVector is a Java interface is rather incidental. To me, dealing with the core abstractions provided by clojure (which are sometimes codified as Java interfaces), and learning how to extend them in certain circumstances, is not only germane, but it's actually vital to using the language effectively. With regard to writing Euler solutions in a non-Java way, I'm just trying to write them in "my" clojure way. :) In any case, I appreciate the help and insights. --~--~-~--~~~---~--~~ 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 proxy the right tool for this job ? Cyclic vector ? Proxy bug ?
http://code.google.com/p/clojure/issues/detail?id=93 Paul, you can experiment with the patch if you wish. Christophe Christophe Grand a écrit : > Ok, working on it. > > Rich Hickey a écrit : > >> On Mar 9, 5:04 am, Timothy Pratley wrote: >> >> >>> Hi Paul, >>> >>> >>> >>>> I actually mentioned the cycle function in my message, and that's what >>>> I was using, but the original question came up because accessing the >>>> nth item in a list takes linear rather than constant time. >>>> >>>> >>> Apologies for not reading your post carefully. Indeed I think your >>> cyclic-vector solution is great. >>> >>> >>> >>>> I'd be interested to hear how what I was attempting violates the >>>> spirit of clojure. I was trying to work within the bounds of an >>>> existing abstraction, and to implement my changes in such a way as to >>>> not break other things that consume that abstraction. >>>> >>>> >>> Interop with Java is a real strength of Clojure. But doing so is less >>> useful for learning Clojure and more useful for learning Java. Feel >>> free to pursue it, Java interop is certainly not wasted effort/ >>> knowledge. It certainly doesn't violate the spirit of Clojure, my >>> words were intended in relation to writing Euler solutions in a non- >>> Java way. >>> >>> >>> >>>> Incidentally, I don't believe the error I'm getting from proxy has >>>> anything to do with IPersistentVector being an interface, since you >>>> can clearly do: >>>> >>>> (proxy [clojure.lang.IFn] []) >>>> >>>> >>> Indeed you can, but you've really just created an empty object: >>> user=> ((proxy [clojure.lang.IFn] [])) >>> java.lang.UnsupportedOperationException: invoke (NO_SOURCE_FILE:0) >>> >>> Now back to IPersistentVector for a moment: >>> This class extends lots of interfaces. There is a name overlap between >>> some of those Interfaces resulting in a very valid error "Duplicate >>> method name&signature". Not a bug with proxy. >>> >>> >>> >> I really don't know why you are trying to dissuade Paul in all this. >> What he is trying to do is perfectly fine and it does in fact look >> like a bug in proxy. It is not an error to inherit a same-sig method >> from more than one interface, but proxy is probably generating more >> than one stub method, which is the error. >> >> I'm prepping for my London QCon trip and don't have time to chase >> this, but would appreciate it if a contributor could please file an >> issue and look into this. >> >> Thanks, >> >> Rich >> >> >> >> >> > > > -- Professional: http://cgrand.net/ (fr) On Clojure: http://clj-me.blogspot.com/ (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 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 proxy the right tool for this job ? Cyclic vector ? Proxy bug ?
Thanks, Christophe. Hopefully I'll have a chance to check it out this evening. On Mar 9, 10:29 am, Christophe Grand wrote: > http://code.google.com/p/clojure/issues/detail?id=93 > > Paul, you can experiment with the patch if you wish. > > Christophe > > Christophe Grand a écrit : > > > > > > > Ok, working on it. > > > Rich Hickey a écrit : > > >> On Mar 9, 5:04 am, Timothy Pratley wrote: > > >>> Hi Paul, > > >>>> I actually mentioned the cycle function in my message, and that's what > >>>> I was using, but the original question came up because accessing the > >>>> nth item in a list takes linear rather than constant time. > > >>> Apologies for not reading your post carefully. Indeed I think your > >>> cyclic-vector solution is great. > > >>>> I'd be interested to hear how what I was attempting violates the > >>>> spirit of clojure. I was trying to work within the bounds of an > >>>> existing abstraction, and to implement my changes in such a way as to > >>>> not break other things that consume that abstraction. > > >>> Interop with Java is a real strength of Clojure. But doing so is less > >>> useful for learning Clojure and more useful for learning Java. Feel > >>> free to pursue it, Java interop is certainly not wasted effort/ > >>> knowledge. It certainly doesn't violate the spirit of Clojure, my > >>> words were intended in relation to writing Euler solutions in a non- > >>> Java way. > > >>>> Incidentally, I don't believe the error I'm getting from proxy has > >>>> anything to do with IPersistentVector being an interface, since you > >>>> can clearly do: > > >>>> (proxy [clojure.lang.IFn] []) > > >>> Indeed you can, but you've really just created an empty object: > >>> user=> ((proxy [clojure.lang.IFn] [])) > >>> java.lang.UnsupportedOperationException: invoke (NO_SOURCE_FILE:0) > > >>> Now back to IPersistentVector for a moment: > >>> This class extends lots of interfaces. There is a name overlap between > >>> some of those Interfaces resulting in a very valid error "Duplicate > >>> method name&signature". Not a bug with proxy. > > >> I really don't know why you are trying to dissuade Paul in all this. > >> What he is trying to do is perfectly fine and it does in fact look > >> like a bug in proxy. It is not an error to inherit a same-sig method > >> from more than one interface, but proxy is probably generating more > >> than one stub method, which is the error. > > >> I'm prepping for my London QCon trip and don't have time to chase > >> this, but would appreciate it if a contributor could please file an > >> issue and look into this. > > >> Thanks, > > >> Rich > > -- > Professional:http://cgrand.net/(fr) > On Clojure:http://clj-me.blogspot.com/(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 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 proxy the right tool for this job ? Cyclic vector ? Proxy bug ?
I haven't done much beyond verify that the error is gone, but it appears that your patch solved my immediate issue. Thanks for the quick fix, Christophe! --~--~-~--~~~---~--~~ 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 proxy the right tool for this job ? Cyclic vector ? Proxy bug ?
> I really don't know why you are trying to dissuade Paul in all this. I was (stupidly) wrong. Sorry Paul for the misinformation. --~--~-~--~~~---~--~~ 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 Friend with a proxy
hi, I'm using Friend, and it works very well, except now I've got things set up in production my app server has a reverse-proxy in front and the redirects no longer work for my protected routes. I tried using requires-scheme-with-proxy but without success...am playing around with it now, don't really know what I'm doing...I know that the proxy is Apache, is there anything else I need to know ? Cheers, and BTW thanks for Friend - yet another Clojure Gem that's made my life much 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 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Proxy vs. glue class
Anvar Karimson writes: > I am trying to understand what the best course of action would be in the > following scenario: > > I have a Java base class that I need to extend. The class is fundamental to > my application and will be running fairly hot compared to other bits of > code in the application. Therefore I want it to execute as fast as > possible. The way I see it there are two options; > > 1) Use proxy > 2) Create a class in Java that provides the glue between Java and Clojure > and removes the need for extending the base class in Clojure. > > I would prefer to use option 1 but I am a little bit worried about the > performance implications of doing so, especially adding a level of > indirection by using map-lookup for accessing methods so I suspect I will > have to go with option 2. > > Any recommendations or alternatives? Or Option 3, create a class in Clojure which extends the Java. My suggestion, try number 1 which is easy, then performance test it. Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Proxy vs. glue class
Is that via gen-class? I have to admit that I am not very familiar with gen-class, is it still possible to use the class from Clojure? Yes, that is probably the most pragmatic choice, premature optimization and all that. On Friday, 4 April 2014 15:03:00 UTC+1, Phillip Lord wrote: > > Anvar Karimson > writes: > > I am trying to understand what the best course of action would be in the > > following scenario: > > > > I have a Java base class that I need to extend. The class is fundamental > to > > my application and will be running fairly hot compared to other bits of > > code in the application. Therefore I want it to execute as fast as > > possible. The way I see it there are two options; > > > > 1) Use proxy > > 2) Create a class in Java that provides the glue between Java and > Clojure > > and removes the need for extending the base class in Clojure. > > > > I would prefer to use option 1 but I am a little bit worried about the > > performance implications of doing so, especially adding a level of > > indirection by using map-lookup for accessing methods so I suspect I > will > > have to go with option 2. > > > > Any recommendations or alternatives? > > Or Option 3, create a class in Clojure which extends the Java. > > My suggestion, try number 1 which is easy, then performance test it. > > Phil > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Proxy vs. glue class
Yeah, gen-class is the thing. Proxy, well, proxies, but genclass produces a statically compiled ahead of time class. It's a real Java class, so yes, you can use it from Clojure like any other Java class. Genclass is a little more painful than proxy, but probably a little less painful than having a combined Java/Clojure build. Phil Anvar Karimson writes: > Is that via gen-class? I have to admit that I am not very familiar with > gen-class, is it still possible to use the class from Clojure? > > Yes, that is probably the most pragmatic choice, premature optimization and > all that. > > On Friday, 4 April 2014 15:03:00 UTC+1, Phillip Lord wrote: >> >> Anvar Karimson > writes: >> > I am trying to understand what the best course of action would be in the >> > following scenario: >> > >> > I have a Java base class that I need to extend. The class is fundamental >> to >> > my application and will be running fairly hot compared to other bits of >> > code in the application. Therefore I want it to execute as fast as >> > possible. The way I see it there are two options; >> > >> > 1) Use proxy >> > 2) Create a class in Java that provides the glue between Java and >> Clojure >> > and removes the need for extending the base class in Clojure. >> > >> > I would prefer to use option 1 but I am a little bit worried about the >> > performance implications of doing so, especially adding a level of >> > indirection by using map-lookup for accessing methods so I suspect I >> will >> > have to go with option 2. >> > >> > Any recommendations or alternatives? >> >> Or Option 3, create a class in Clojure which extends the Java. >> >> My suggestion, try number 1 which is easy, then performance test it. >> >> Phil >> -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Proxy vs. glue class
Ok, thanks! I will have a look! On Friday, 4 April 2014 16:43:20 UTC+1, Phillip Lord wrote: > > > Yeah, gen-class is the thing. Proxy, well, proxies, but genclass > produces a statically compiled ahead of time class. It's a real Java > class, so yes, you can use it from Clojure like any other Java class. > > Genclass is a little more painful than proxy, but probably a little less > painful than having a combined Java/Clojure build. > > Phil > > Anvar Karimson > writes: > > > Is that via gen-class? I have to admit that I am not very familiar with > > gen-class, is it still possible to use the class from Clojure? > > > > Yes, that is probably the most pragmatic choice, premature optimization > and > > all that. > > > > On Friday, 4 April 2014 15:03:00 UTC+1, Phillip Lord wrote: > >> > >> Anvar Karimson > writes: > >> > I am trying to understand what the best course of action would be in > the > >> > following scenario: > >> > > >> > I have a Java base class that I need to extend. The class is > fundamental > >> to > >> > my application and will be running fairly hot compared to other bits > of > >> > code in the application. Therefore I want it to execute as fast as > >> > possible. The way I see it there are two options; > >> > > >> > 1) Use proxy > >> > 2) Create a class in Java that provides the glue between Java and > >> Clojure > >> > and removes the need for extending the base class in Clojure. > >> > > >> > I would prefer to use option 1 but I am a little bit worried about > the > >> > performance implications of doing so, especially adding a level of > >> > indirection by using map-lookup for accessing methods so I suspect I > >> will > >> > have to go with option 2. > >> > > >> > Any recommendations or alternatives? > >> > >> Or Option 3, create a class in Clojure which extends the Java. > >> > >> My suggestion, try number 1 which is easy, then performance test it. > >> > >> Phil > >> > > -- > Phillip Lord, Phone: +44 (0) 191 222 7827 > Lecturer in Bioinformatics, Email: > philli...@newcastle.ac.uk > School of Computing Science, > http://homepages.cs.ncl.ac.uk/phillip.lord > Room 914 Claremont Tower, skype: russet_apples > Newcastle University, twitter: phillord > NE1 7RU > -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Proxy vs. glue class
FWIW, in Cursive, which is a big ball of mixed Clojure + Java, I've given up trying to use gen-class and have started using Java shims for everything. I like it a lot more than gen-class, which I always feel like I'm fighting. With the new Java->Clojure API in 1.6 (or the equivalent using RT.var() and friends for earlier versions) it's really not that hard, tool support is much better and IMO it's much cleaner. gen-class will always indirect method calls through a var but if you're worried about performance you can get the underlying function object with Java and call it directly, with the caveat that you then lose the ability to update it dynamically at the REPL. I'd dearly love a deftype-style extend-type or similar which would allow base class extension. I know it's not encouraged in Clojure but one of Clojure's fundamental principles is exposing the host where it's pragmatic to do so, and both proxy and gen-class have some pretty serious warts for this purpose. On 5 April 2014 04:47, Anvar Karimson wrote: > Ok, thanks! I will have a look! > > > On Friday, 4 April 2014 16:43:20 UTC+1, Phillip Lord wrote: > >> >> Yeah, gen-class is the thing. Proxy, well, proxies, but genclass >> produces a statically compiled ahead of time class. It's a real Java >> class, so yes, you can use it from Clojure like any other Java class. >> >> Genclass is a little more painful than proxy, but probably a little less >> painful than having a combined Java/Clojure build. >> >> Phil >> >> Anvar Karimson writes: >> >> > Is that via gen-class? I have to admit that I am not very familiar with >> > gen-class, is it still possible to use the class from Clojure? >> > >> > Yes, that is probably the most pragmatic choice, premature optimization >> and >> > all that. >> > >> > On Friday, 4 April 2014 15:03:00 UTC+1, Phillip Lord wrote: >> >> >> >> Anvar Karimson > writes: >> >> > I am trying to understand what the best course of action would be in >> the >> >> > following scenario: >> >> > >> >> > I have a Java base class that I need to extend. The class is >> fundamental >> >> to >> >> > my application and will be running fairly hot compared to other bits >> of >> >> > code in the application. Therefore I want it to execute as fast as >> >> > possible. The way I see it there are two options; >> >> > >> >> > 1) Use proxy >> >> > 2) Create a class in Java that provides the glue between Java and >> >> Clojure >> >> > and removes the need for extending the base class in Clojure. >> >> > >> >> > I would prefer to use option 1 but I am a little bit worried about >> the >> >> > performance implications of doing so, especially adding a level of >> >> > indirection by using map-lookup for accessing methods so I suspect I >> >> will >> >> > have to go with option 2. >> >> > >> >> > Any recommendations or alternatives? >> >> >> >> Or Option 3, create a class in Clojure which extends the Java. >> >> >> >> My suggestion, try number 1 which is easy, then performance test it. >> >> >> >> Phil >> >> >> >> -- >> Phillip Lord, Phone: +44 (0) 191 222 7827 >> Lecturer in Bioinformatics, Email: philli...@newcastle.ac.uk >> School of Computing Science,http://homepages.cs.ncl.ac. >> uk/phillip.lord >> Room 914 Claremont Tower, skype: russet_apples >> Newcastle University, twitter: phillord >> NE1 7RU >> > -- > 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 unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Proxy vs. glue class
On Saturday, 5 April 2014 08:08:13 UTC+8, Colin Fleming wrote: > > FWIW, in Cursive, which is a big ball of mixed Clojure + Java, I've given > up trying to use gen-class and have started using Java shims for > everything. I like it a lot more than gen-class, which I always feel like > I'm fighting. With the new Java->Clojure API in 1.6 (or the equivalent > using RT.var() and friends for earlier versions) it's really not that hard, > tool support is much better and IMO it's much cleaner. gen-class will > always indirect method calls through a var but if you're worried about > performance you can get the underlying function object with Java and call > it directly, with the caveat that you then lose the ability to update it > dynamically at the REPL. > > I'd dearly love a deftype-style extend-type or similar which would allow > base class extension. I know it's not encouraged in Clojure but one of > Clojure's fundamental principles is exposing the host where it's pragmatic > to do so, and both proxy and gen-class have some pretty serious warts for > this purpose. > +LOTS for this. I have wanted to extend a Java abstract base class *many* times in Clojure. It's a real pain point, right now. Especially for interop with Java libraries that expect you to extend base classes in order to write plugins etc. Currently when this comes up I just forget about Clojure and write this stuff in Java. IMHO extending reify to support abstract base classes as well as interfaces would be the simplest way to achieve this. FWIW here's the (as yet unaddressed) issue I raised about this on JIRA: http://dev.clojure.org/jira/browse/CLJ-1255 -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Proxy vs. glue class
Yeah, it's annoying, no doubt. I have a bunch of classes that do nothing but override a protected method with a public one so I can proxy without warnings, some that I have to use because I can't create a non-trivial constructor, and so forth. Re: your proposal, I think I'd prefer to leave reify et al as they were now, and that continue to be the "encouraged" path. I prefer the idea of having a separate interop form (extend-type, or whatever) although I think it should be able to natively reify protocols etc. Such a form would get pretty complicated if you wanted to be able to do everything a Java class can (create arbitrary constructors or whatever), but a form that works like deftype but: a) can extend a concrete class b) allows me to call supertype methods, including protected ones c) has the generated code inline in the method body (I'll delegate through a var if I want to) d) can reify protocols directly e) can optionally cause its namespace to be require'd in a static initialiser (so the class can be used in IoC containers etc) would be fantastic. I don't think it's unreasonable to expect people to write some Java for more esoteric things (multiple constructors, non-public class access, non-Clojuresque fields, static methods etc), but simple class extension along the lines of the existing interop support doesn't seem like such a bad idea. On 5 April 2014 20:20, Mikera wrote: > On Saturday, 5 April 2014 08:08:13 UTC+8, Colin Fleming wrote: >> >> FWIW, in Cursive, which is a big ball of mixed Clojure + Java, I've given >> up trying to use gen-class and have started using Java shims for >> everything. I like it a lot more than gen-class, which I always feel like >> I'm fighting. With the new Java->Clojure API in 1.6 (or the equivalent >> using RT.var() and friends for earlier versions) it's really not that hard, >> tool support is much better and IMO it's much cleaner. gen-class will >> always indirect method calls through a var but if you're worried about >> performance you can get the underlying function object with Java and call >> it directly, with the caveat that you then lose the ability to update it >> dynamically at the REPL. >> >> I'd dearly love a deftype-style extend-type or similar which would allow >> base class extension. I know it's not encouraged in Clojure but one of >> Clojure's fundamental principles is exposing the host where it's pragmatic >> to do so, and both proxy and gen-class have some pretty serious warts for >> this purpose. >> > > +LOTS for this. I have wanted to extend a Java abstract base class *many* > times in Clojure. It's a real pain point, right now. Especially for interop > with Java libraries that expect you to extend base classes in order to > write plugins etc. Currently when this comes up I just forget about Clojure > and write this stuff in Java. > > IMHO extending reify to support abstract base classes as well as > interfaces would be the simplest way to achieve this. > > FWIW here's the (as yet unaddressed) issue I raised about this on JIRA: > http://dev.clojure.org/jira/browse/CLJ-1255 > > -- > 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 unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Proxy vs. glue class
Mikera writes: > +LOTS for this. I have wanted to extend a Java abstract base class *many* > times in Clojure. It's a real pain point, right now. Especially for interop > with Java libraries that expect you to extend base classes in order to > write plugins etc. Currently when this comes up I just forget about Clojure > and write this stuff in Java. Having said that I would use proxies, actually, I think you have a point. The last time I wanted to build a plugin, I did it in Java and invoked clojure from within that. In that case, I needed a two part build anyway. The plugin uses OSGI, and came with a sample mvn script. So, in the end, I build the plugin in Java and pull in the clojure as a maven dependencies, with a tiny bit of glue to make launch leiningen. Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Calling proxy without reflection
That's exactly what you should do and it does work, e.g.:
user=> (set! *warn-on-reflection* true)
true
user=> (.meta ^clojure.lang.IMeta (proxy [clojure.lang.IMeta] [] (meta [] {:a
1})))
{:a 1}
In your small example you have two errors that might be fishy: a missing arg
vector to pass to the super ctor and an extra `this` parameter in the method
impl (proxy, unlike reify, is anaphoric and binds `this` for you)
> On 30 Jul 2018, at 10:56, Mark Engelberg wrote:
>
> Let's say I have a proxy object:
>
> (def p (proxy [MyClass MyInterface] (interfaceMethod [this] ...)))
>
> Now, I want to call (.interfaceMethod p). How do I do this without
> reflection?
> I would have thought that (.interfaceMethod ^MyInterface p) would work, but
> this results in an error message that this proxy object cannot be cast to
> MyInterface.
>
>
>
> --
> 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
> <http://groups.google.com/group/clojure?hl=en>
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> <mailto:clojure+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Calling proxy without reflection
Those fishy things were errors I made when simplifying and transcribing the
proxy to post, but I have it correct in my own code.
Here's a more precise, tested minimal example:
(definterface Interface (test []))
(def p (proxy [Object Interface] [] (test [] 1)))
(defn get-test [o] (.test ^Interface o))
=> (get-test p)
This throws an error that it can't cast the proxy to Interface.
If you remove the ^Interface type hint, then get-test will work but will
trigger reflection.
Thanks for looking at this. It seems like it should work, but it doesn't.
On Mon, Jul 30, 2018 at 3:06 AM, Nicola Mometto wrote:
> That's exactly what you should do and it does work, e.g.:
>
> user=> (set! *warn-on-reflection* true)
> true
> user=> (.meta ^clojure.lang.IMeta (proxy [clojure.lang.IMeta] [] (meta []
> {:a 1})))
> {:a 1}
>
> In your small example you have two errors that might be fishy: a missing
> arg vector to pass to the super ctor and an extra `this` parameter in the
> method impl (proxy, unlike reify, is anaphoric and binds `this` for you)
>
>
> On 30 Jul 2018, at 10:56, Mark Engelberg wrote:
>
> Let's say I have a proxy object:
>
> (def p (proxy [MyClass MyInterface] (interfaceMethod [this] ...)))
>
> Now, I want to call (.interfaceMethod p). How do I do this without
> reflection?
> I would have thought that (.interfaceMethod ^MyInterface p) would work,
> but this results in an error message that this proxy object cannot be cast
> to MyInterface.
>
>
>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Calling proxy without reflection
Which version of clojure? This works fine in 1.10
Clojure 1.10.0-master-SNAPSHOT
user=> (set! *warn-on-reflection* true)
true
user=> (definterface Interface (test []))
user.Interface
user=> (def p (proxy [Object Interface] [] (test [] 1)))
#'user/p
user=> (defn get-test [o] (.test ^Interface o))
#'user/get-test
user=> (get-test p)
1
> On 30 Jul 2018, at 11:26, Mark Engelberg wrote:
>
> Those fishy things were errors I made when simplifying and transcribing the
> proxy to post, but I have it correct in my own code.
>
> Here's a more precise, tested minimal example:
>
> (definterface Interface (test []))
> (def p (proxy [Object Interface] [] (test [] 1)))
> (defn get-test [o] (.test ^Interface o))
>
> => (get-test p)
> This throws an error that it can't cast the proxy to Interface.
>
> If you remove the ^Interface type hint, then get-test will work but will
> trigger reflection.
>
> Thanks for looking at this. It seems like it should work, but it doesn't.
>
>
> On Mon, Jul 30, 2018 at 3:06 AM, Nicola Mometto <mailto:brobro...@gmail.com>> wrote:
> That's exactly what you should do and it does work, e.g.:
>
> user=> (set! *warn-on-reflection* true)
> true
> user=> (.meta ^clojure.lang.IMeta (proxy [clojure.lang.IMeta] [] (meta [] {:a
> 1})))
> {:a 1}
>
> In your small example you have two errors that might be fishy: a missing arg
> vector to pass to the super ctor and an extra `this` parameter in the method
> impl (proxy, unlike reify, is anaphoric and binds `this` for you)
>
>
>> On 30 Jul 2018, at 10:56, Mark Engelberg > <mailto:mark.engelb...@gmail.com>> wrote:
>>
>> Let's say I have a proxy object:
>>
>> (def p (proxy [MyClass MyInterface] (interfaceMethod [this] ...)))
>>
>> Now, I want to call (.interfaceMethod p). How do I do this without
>> reflection?
>> I would have thought that (.interfaceMethod ^MyInterface p) would work, but
>> this results in an error message that this proxy object cannot be cast to
>> MyInterface.
>>
>>
>>
>> --
>> 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
>> <mailto: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
>> <mailto:clojure+unsubscr...@googlegroups.com>
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> <http://groups.google.com/group/clojure?hl=en>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com
>> <mailto:clojure+unsubscr...@googlegroups.com>.
>> For more options, visit https://groups.google.com/d/optout
>> <https://groups.google.com/d/optout>.
>
>
> --
> 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
> <mailto: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
> <mailto:clojure%2bunsubscr...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> <http://groups.google.com/group/clojure?hl=en>
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> <mailto:clojure+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
>
> --
> 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
> <http://
Re: Calling proxy without reflection
I'm using 1.9.0. Is this a behavior that recently changed?
On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto wrote:
> Which version of clojure? This works fine in 1.10
>
> Clojure 1.10.0-master-SNAPSHOT
> user=> (set! *warn-on-reflection* true)
> true
> user=> (definterface Interface (test []))
> user.Interface
> user=> (def p (proxy [Object Interface] [] (test [] 1)))
> #'user/p
> user=> (defn get-test [o] (.test ^Interface o))
> #'user/get-test
> user=> (get-test p)
> 1
>
>
> On 30 Jul 2018, at 11:26, Mark Engelberg wrote:
>
> Those fishy things were errors I made when simplifying and transcribing
> the proxy to post, but I have it correct in my own code.
>
> Here's a more precise, tested minimal example:
>
> (definterface Interface (test []))
> (def p (proxy [Object Interface] [] (test [] 1)))
> (defn get-test [o] (.test ^Interface o))
>
> => (get-test p)
> This throws an error that it can't cast the proxy to Interface.
>
> If you remove the ^Interface type hint, then get-test will work but will
> trigger reflection.
>
> Thanks for looking at this. It seems like it should work, but it doesn't.
>
>
> On Mon, Jul 30, 2018 at 3:06 AM, Nicola Mometto
> wrote:
>
>> That's exactly what you should do and it does work, e.g.:
>>
>> user=> (set! *warn-on-reflection* true)
>> true
>> user=> (.meta ^clojure.lang.IMeta (proxy [clojure.lang.IMeta] [] (meta []
>> {:a 1})))
>> {:a 1}
>>
>> In your small example you have two errors that might be fishy: a missing
>> arg vector to pass to the super ctor and an extra `this` parameter in the
>> method impl (proxy, unlike reify, is anaphoric and binds `this` for you)
>>
>>
>> On 30 Jul 2018, at 10:56, Mark Engelberg
>> wrote:
>>
>> Let's say I have a proxy object:
>>
>> (def p (proxy [MyClass MyInterface] (interfaceMethod [this] ...)))
>>
>> Now, I want to call (.interfaceMethod p). How do I do this without
>> reflection?
>> I would have thought that (.interfaceMethod ^MyInterface p) would work,
>> but this results in an error message that this proxy object cannot be cast
>> to MyInterface.
>>
>>
>>
>> --
>> 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 unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> 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 unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received th
Re: Calling proxy without reflection
No, I just tested this on 1.9.0 and 1.8.0 and I get no reflection, as I'd
expect.
Are you testing this in a fresh environment?
> On 30 Jul 2018, at 11:31, Mark Engelberg wrote:
>
> I'm using 1.9.0. Is this a behavior that recently changed?
>
> On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto <mailto:brobro...@gmail.com>> wrote:
> Which version of clojure? This works fine in 1.10
>
> Clojure 1.10.0-master-SNAPSHOT
> user=> (set! *warn-on-reflection* true)
> true
> user=> (definterface Interface (test []))
> user.Interface
> user=> (def p (proxy [Object Interface] [] (test [] 1)))
> #'user/p
> user=> (defn get-test [o] (.test ^Interface o))
> #'user/get-test
> user=> (get-test p)
> 1
>
>
>> On 30 Jul 2018, at 11:26, Mark Engelberg > <mailto:mark.engelb...@gmail.com>> wrote:
>>
>> Those fishy things were errors I made when simplifying and transcribing the
>> proxy to post, but I have it correct in my own code.
>>
>> Here's a more precise, tested minimal example:
>>
>> (definterface Interface (test []))
>> (def p (proxy [Object Interface] [] (test [] 1)))
>> (defn get-test [o] (.test ^Interface o))
>>
>> => (get-test p)
>> This throws an error that it can't cast the proxy to Interface.
>>
>> If you remove the ^Interface type hint, then get-test will work but will
>> trigger reflection.
>>
>> Thanks for looking at this. It seems like it should work, but it doesn't.
>>
>>
>> On Mon, Jul 30, 2018 at 3:06 AM, Nicola Mometto > <mailto:brobro...@gmail.com>> wrote:
>> That's exactly what you should do and it does work, e.g.:
>>
>> user=> (set! *warn-on-reflection* true)
>> true
>> user=> (.meta ^clojure.lang.IMeta (proxy [clojure.lang.IMeta] [] (meta []
>> {:a 1})))
>> {:a 1}
>>
>> In your small example you have two errors that might be fishy: a missing arg
>> vector to pass to the super ctor and an extra `this` parameter in the method
>> impl (proxy, unlike reify, is anaphoric and binds `this` for you)
>>
>>
>>> On 30 Jul 2018, at 10:56, Mark Engelberg >> <mailto:mark.engelb...@gmail.com>> wrote:
>>>
>>> Let's say I have a proxy object:
>>>
>>> (def p (proxy [MyClass MyInterface] (interfaceMethod [this] ...)))
>>>
>>> Now, I want to call (.interfaceMethod p). How do I do this without
>>> reflection?
>>> I would have thought that (.interfaceMethod ^MyInterface p) would work, but
>>> this results in an error message that this proxy object cannot be cast to
>>> MyInterface.
>>>
>>>
>>>
>>> --
>>> 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
>>> <mailto: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
>>> <mailto:clojure+unsubscr...@googlegroups.com>
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> <http://groups.google.com/group/clojure?hl=en>
>>> ---
>>> You received this message because you are subscribed to the Google Groups
>>> "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to clojure+unsubscr...@googlegroups.com
>>> <mailto:clojure+unsubscr...@googlegroups.com>.
>>> For more options, visit https://groups.google.com/d/optout
>>> <https://groups.google.com/d/optout>.
>>
>>
>> --
>> 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
>> <mailto: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
>> <mailto:clojure%2bunsubscr...@googlegroups.com>
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> <http://groups.google.com/group/clojure?hl=en>
>> ---
>> You received this message because you are subscribed to the Google Gr
Re: Calling proxy without reflection
Yes, it is in a fresh environment.
I find that the problematic example *does* work in the user namespace, but
it doesn't work in my segmented namespace (ns mister-rogers.wrappers, to be
really specific).
On Mon, Jul 30, 2018 at 3:34 AM, Nicola Mometto wrote:
> No, I just tested this on 1.9.0 and 1.8.0 and I get no reflection, as I'd
> expect.
>
> Are you testing this in a fresh environment?
>
>
> On 30 Jul 2018, at 11:31, Mark Engelberg wrote:
>
> I'm using 1.9.0. Is this a behavior that recently changed?
>
> On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto
> wrote:
>
>> Which version of clojure? This works fine in 1.10
>>
>> Clojure 1.10.0-master-SNAPSHOT
>> user=> (set! *warn-on-reflection* true)
>> true
>> user=> (definterface Interface (test []))
>> user.Interface
>> user=> (def p (proxy [Object Interface] [] (test [] 1)))
>> #'user/p
>> user=> (defn get-test [o] (.test ^Interface o))
>> #'user/get-test
>> user=> (get-test p)
>> 1
>>
>>
>> On 30 Jul 2018, at 11:26, Mark Engelberg
>> wrote:
>>
>> Those fishy things were errors I made when simplifying and transcribing
>> the proxy to post, but I have it correct in my own code.
>>
>> Here's a more precise, tested minimal example:
>>
>> (definterface Interface (test []))
>> (def p (proxy [Object Interface] [] (test [] 1)))
>> (defn get-test [o] (.test ^Interface o))
>>
>> => (get-test p)
>> This throws an error that it can't cast the proxy to Interface.
>>
>> If you remove the ^Interface type hint, then get-test will work but will
>> trigger reflection.
>>
>> Thanks for looking at this. It seems like it should work, but it doesn't.
>>
>>
>> On Mon, Jul 30, 2018 at 3:06 AM, Nicola Mometto
>> wrote:
>>
>>> That's exactly what you should do and it does work, e.g.:
>>>
>>> user=> (set! *warn-on-reflection* true)
>>> true
>>> user=> (.meta ^clojure.lang.IMeta (proxy [clojure.lang.IMeta] [] (meta
>>> [] {:a 1})))
>>> {:a 1}
>>>
>>> In your small example you have two errors that might be fishy: a missing
>>> arg vector to pass to the super ctor and an extra `this` parameter in the
>>> method impl (proxy, unlike reify, is anaphoric and binds `this` for you)
>>>
>>>
>>> On 30 Jul 2018, at 10:56, Mark Engelberg
>>> wrote:
>>>
>>> Let's say I have a proxy object:
>>>
>>> (def p (proxy [MyClass MyInterface] (interfaceMethod [this] ...)))
>>>
>>> Now, I want to call (.interfaceMethod p). How do I do this without
>>> reflection?
>>> I would have thought that (.interfaceMethod ^MyInterface p) would work,
>>> but this results in an error message that this proxy object cannot be cast
>>> to MyInterface.
>>>
>>>
>>>
>>> --
>>> 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 unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>> --
>>> 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 unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups
Re: Calling proxy without reflection
Can you paste an entire repl session, starting from how you launch it (e.g.
lein repl vs clj -- ideally not from a project) reproducing this?
I'm interested in taking a look but I simply cannot repro :/
> On 30 Jul 2018, at 11:40, Mark Engelberg wrote:
>
> Yes, it is in a fresh environment.
>
> I find that the problematic example does work in the user namespace, but it
> doesn't work in my segmented namespace (ns mister-rogers.wrappers, to be
> really specific).
>
> On Mon, Jul 30, 2018 at 3:34 AM, Nicola Mometto <mailto:brobro...@gmail.com>> wrote:
> No, I just tested this on 1.9.0 and 1.8.0 and I get no reflection, as I'd
> expect.
>
> Are you testing this in a fresh environment?
>
>
>> On 30 Jul 2018, at 11:31, Mark Engelberg > <mailto:mark.engelb...@gmail.com>> wrote:
>>
>> I'm using 1.9.0. Is this a behavior that recently changed?
>>
>> On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto > <mailto:brobro...@gmail.com>> wrote:
>> Which version of clojure? This works fine in 1.10
>>
>> Clojure 1.10.0-master-SNAPSHOT
>> user=> (set! *warn-on-reflection* true)
>> true
>> user=> (definterface Interface (test []))
>> user.Interface
>> user=> (def p (proxy [Object Interface] [] (test [] 1)))
>> #'user/p
>> user=> (defn get-test [o] (.test ^Interface o))
>> #'user/get-test
>> user=> (get-test p)
>> 1
>>
>>
>>> On 30 Jul 2018, at 11:26, Mark Engelberg >> <mailto:mark.engelb...@gmail.com>> wrote:
>>>
>>> Those fishy things were errors I made when simplifying and transcribing the
>>> proxy to post, but I have it correct in my own code.
>>>
>>> Here's a more precise, tested minimal example:
>>>
>>> (definterface Interface (test []))
>>> (def p (proxy [Object Interface] [] (test [] 1)))
>>> (defn get-test [o] (.test ^Interface o))
>>>
>>> => (get-test p)
>>> This throws an error that it can't cast the proxy to Interface.
>>>
>>> If you remove the ^Interface type hint, then get-test will work but will
>>> trigger reflection.
>>>
>>> Thanks for looking at this. It seems like it should work, but it doesn't.
>>>
>>>
>>> On Mon, Jul 30, 2018 at 3:06 AM, Nicola Mometto >> <mailto:brobro...@gmail.com>> wrote:
>>> That's exactly what you should do and it does work, e.g.:
>>>
>>> user=> (set! *warn-on-reflection* true)
>>> true
>>> user=> (.meta ^clojure.lang.IMeta (proxy [clojure.lang.IMeta] [] (meta []
>>> {:a 1})))
>>> {:a 1}
>>>
>>> In your small example you have two errors that might be fishy: a missing
>>> arg vector to pass to the super ctor and an extra `this` parameter in the
>>> method impl (proxy, unlike reify, is anaphoric and binds `this` for you)
>>>
>>>
>>>> On 30 Jul 2018, at 10:56, Mark Engelberg >>> <mailto:mark.engelb...@gmail.com>> wrote:
>>>>
>>>> Let's say I have a proxy object:
>>>>
>>>> (def p (proxy [MyClass MyInterface] (interfaceMethod [this] ...)))
>>>>
>>>> Now, I want to call (.interfaceMethod p). How do I do this without
>>>> reflection?
>>>> I would have thought that (.interfaceMethod ^MyInterface p) would work,
>>>> but this results in an error message that this proxy object cannot be cast
>>>> to MyInterface.
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>> <mailto: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
>>>> <mailto:clojure+unsubscr...@googlegroups.com>
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/clojure?hl=en
>>>> <http://groups.google.com/group/clojure?hl=en>
>>>> ---
>>>> You received this message because you are subscribed to the Google Groups
>>>> "Clojure" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an
>>>>
Re: Calling proxy without reflection
OK, I just pushed the repo (work in progress) to github.
https://github.com/Engelberg/mister-rogers
At the bottom of mister-rogers.wrappers I tacked on the three lines we've
been discussing.
https://github.com/Engelberg/mister-rogers/blob/523fc29f8827193fa9ea6ae2e82649e2933e6ae3/src/clj/mister_rogers/wrappers.clj#L80
Here's a REPL interaction:
C:\devel\Clojure\mister-rogers>lein repl
recompiling all files in ["C:\\devel\\Clojure\\mister-rogers\\src\\java"]
:reloading (mister-rogers.core mister-rogers.protocols
mister-rogers.problem mister-rogers.wrappers mister-rogers.core-test)
recompiling all files in ["C:\\devel\\Clojure\\mister-rogers\\src\\java"]
:reloading (mister-rogers.core mister-rogers.protocols
mister-rogers.problem mister-rogers.wrappers mister-rogers.core-test)
nREPL server started on port 49492 on host 127.0.0.1 - nrepl://
127.0.0.1:49492
REPL-y 0.3.7, nREPL 0.2.12
Clojure 1.9.0
Java HotSpot(TM) 64-Bit Server VM 1.8.0_66-b18
Docs: (doc function-name-here)
(find-doc "part-of-name-here")
Source: (source function-name-here)
Javadoc: (javadoc java-object-or-class-here)
Exit: Control+D or (exit) or (quit)
Results: Stored in vars *1, *2, *3, an exception in *e
user=> (in-ns 'mister-rogers.wrappers)
#namespace[mister-rogers.wrappers]
mister-rogers.wrappers=> (get-test p)
ClassCastException
mister_rogers.wrappers.proxy$java.lang.Object$Interface$7e434bc9
cannot be cast to mister_rogers.wrappers.Interface
mister-rogers.wrappers/get-test (wrappers.clj:82)
Thanks for looking at this.
On Mon, Jul 30, 2018 at 3:43 AM, Nicola Mometto wrote:
> Can you paste an entire repl session, starting from how you launch it
> (e.g. lein repl vs clj -- ideally not from a project) reproducing this?
> I'm interested in taking a look but I simply cannot repro :/
>
> On 30 Jul 2018, at 11:40, Mark Engelberg wrote:
>
> Yes, it is in a fresh environment.
>
> I find that the problematic example *does* work in the user namespace,
> but it doesn't work in my segmented namespace (ns mister-rogers.wrappers,
> to be really specific).
>
> On Mon, Jul 30, 2018 at 3:34 AM, Nicola Mometto
> wrote:
>
>> No, I just tested this on 1.9.0 and 1.8.0 and I get no reflection, as I'd
>> expect.
>>
>> Are you testing this in a fresh environment?
>>
>>
>> On 30 Jul 2018, at 11:31, Mark Engelberg
>> wrote:
>>
>> I'm using 1.9.0. Is this a behavior that recently changed?
>>
>> On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto
>> wrote:
>>
>>> Which version of clojure? This works fine in 1.10
>>>
>>> Clojure 1.10.0-master-SNAPSHOT
>>> user=> (set! *warn-on-reflection* true)
>>> true
>>> user=> (definterface Interface (test []))
>>> user.Interface
>>> user=> (def p (proxy [Object Interface] [] (test [] 1)))
>>> #'user/p
>>> user=> (defn get-test [o] (.test ^Interface o))
>>> #'user/get-test
>>> user=> (get-test p)
>>> 1
>>>
>>>
>>> On 30 Jul 2018, at 11:26, Mark Engelberg
>>> wrote:
>>>
>>> Those fishy things were errors I made when simplifying and transcribing
>>> the proxy to post, but I have it correct in my own code.
>>>
>>> Here's a more precise, tested minimal example:
>>>
>>> (definterface Interface (test []))
>>> (def p (proxy [Object Interface] [] (test [] 1)))
>>> (defn get-test [o] (.test ^Interface o))
>>>
>>> => (get-test p)
>>> This throws an error that it can't cast the proxy to Interface.
>>>
>>> If you remove the ^Interface type hint, then get-test will work but will
>>> trigger reflection.
>>>
>>> Thanks for looking at this. It seems like it should work, but it doesn't.
>>>
>>>
>>> On Mon, Jul 30, 2018 at 3:06 AM, Nicola Mometto
>>> wrote:
>>>
>>>> That's exactly what you should do and it does work, e.g.:
>>>>
>>>> user=> (set! *warn-on-reflection* true)
>>>> true
>>>> user=> (.meta ^clojure.lang.IMeta (proxy [clojure.lang.IMeta] [] (meta
>>>> [] {:a 1})))
>>>> {:a 1}
>>>>
>>>> In your small example you have two errors that might be fishy: a
>>>> missing arg vector to pass to the super ctor and an extra `this` parameter
>>>> in the method impl (proxy, unlike reify, is anaphoric and binds `this` for
>>>> you)
>>>>
>>>>
>>>> On 30 Jul 2018, at 10:56, Mark Engelberg
>>>> wrote:
>>>>
>>>
Re: Calling proxy without reflection
Ok, just taking a cursory look and what you're seeing might be related to double-loading. It might be that the fixes that went in around ~1.5/1.6 missed some edge-cases related to `proxy`, I'll investigate more this evening > On 30 Jul 2018, at 11:50, Mark Engelberg wrote: > > OK, I just pushed the repo (work in progress) to github. > https://github.com/Engelberg/mister-rogers > <https://github.com/Engelberg/mister-rogers> > At the bottom of mister-rogers.wrappers I tacked on the three lines we've > been discussing. > https://github.com/Engelberg/mister-rogers/blob/523fc29f8827193fa9ea6ae2e82649e2933e6ae3/src/clj/mister_rogers/wrappers.clj#L80 > > <https://github.com/Engelberg/mister-rogers/blob/523fc29f8827193fa9ea6ae2e82649e2933e6ae3/src/clj/mister_rogers/wrappers.clj#L80> > > Here's a REPL interaction: > > C:\devel\Clojure\mister-rogers>lein repl > > recompiling all files in ["C:\\devel\\Clojure\\mister-rogers\\src\\java"] > :reloading (mister-rogers.core mister-rogers.protocols mister-rogers.problem > mister-rogers.wrappers mister-rogers.core-test) > > recompiling all files in ["C:\\devel\\Clojure\\mister-rogers\\src\\java"] > :reloading (mister-rogers.core mister-rogers.protocols mister-rogers.problem > mister-rogers.wrappers mister-rogers.core-test) > nREPL server started on port 49492 on host 127.0.0.1 - > nrepl://127.0.0.1:49492 <http://127.0.0.1:49492/> > REPL-y 0.3.7, nREPL 0.2.12 > Clojure 1.9.0 > Java HotSpot(TM) 64-Bit Server VM 1.8.0_66-b18 > Docs: (doc function-name-here) > (find-doc "part-of-name-here") > Source: (source function-name-here) > Javadoc: (javadoc java-object-or-class-here) > Exit: Control+D or (exit) or (quit) > Results: Stored in vars *1, *2, *3, an exception in *e > > user=> (in-ns 'mister-rogers.wrappers) > #namespace[mister-rogers.wrappers] > mister-rogers.wrappers=> (get-test p) > > ClassCastException > mister_rogers.wrappers.proxy$java.lang.Object$Interface$7e434bc9 cannot be > cast to mister_rogers.wrappers.Interface mister-rogers.wrappers/get-test > (wrappers.clj:82) > > > Thanks for looking at this. > > > On Mon, Jul 30, 2018 at 3:43 AM, Nicola Mometto <mailto:brobro...@gmail.com>> wrote: > Can you paste an entire repl session, starting from how you launch it (e.g. > lein repl vs clj -- ideally not from a project) reproducing this? > I'm interested in taking a look but I simply cannot repro :/ > >> On 30 Jul 2018, at 11:40, Mark Engelberg > <mailto:mark.engelb...@gmail.com>> wrote: >> >> Yes, it is in a fresh environment. >> >> I find that the problematic example does work in the user namespace, but it >> doesn't work in my segmented namespace (ns mister-rogers.wrappers, to be >> really specific). >> >> On Mon, Jul 30, 2018 at 3:34 AM, Nicola Mometto > <mailto:brobro...@gmail.com>> wrote: >> No, I just tested this on 1.9.0 and 1.8.0 and I get no reflection, as I'd >> expect. >> >> Are you testing this in a fresh environment? >> >> >>> On 30 Jul 2018, at 11:31, Mark Engelberg >> <mailto:mark.engelb...@gmail.com>> wrote: >>> >>> I'm using 1.9.0. Is this a behavior that recently changed? >>> >>> On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto >> <mailto:brobro...@gmail.com>> wrote: >>> Which version of clojure? This works fine in 1.10 >>> >>> Clojure 1.10.0-master-SNAPSHOT >>> user=> (set! *warn-on-reflection* true) >>> true >>> user=> (definterface Interface (test [])) >>> user.Interface >>> user=> (def p (proxy [Object Interface] [] (test [] 1))) >>> #'user/p >>> user=> (defn get-test [o] (.test ^Interface o)) >>> #'user/get-test >>> user=> (get-test p) >>> 1 >>> >>> >>>> On 30 Jul 2018, at 11:26, Mark Engelberg >>> <mailto:mark.engelb...@gmail.com>> wrote: >>>> >>>> Those fishy things were errors I made when simplifying and transcribing >>>> the proxy to post, but I have it correct in my own code. >>>> >>>> Here's a more precise, tested minimal example: >>>> >>>> (definterface Interface (test [])) >>>> (def p (proxy [Object Interface] [] (test [] 1))) >>>> (defn get-test [o] (.test ^Interface o)) >>>> >>>> => (get-test p) >>>> This throws an error that it can't cast the proxy to Interface. >>>&g
Re: Calling proxy without reflection
Hey Mark, it's lein-virgil interfering. As of why, better opening an issue
there.
Renzo
> On 30 Jul 2018, at 11:50, Mark Engelberg wrote:
>
> OK, I just pushed the repo (work in progress) to github.
> https://github.com/Engelberg/mister-rogers
> At the bottom of mister-rogers.wrappers I tacked on the three lines we've
> been discussing.
> https://github.com/Engelberg/mister-rogers/blob/523fc29f8827193fa9ea6ae2e82649e2933e6ae3/src/clj/mister_rogers/wrappers.clj#L80
>
>
> Here's a REPL interaction:
>
> C:\devel\Clojure\mister-rogers>lein repl
>
> recompiling all files in ["C:\\devel\\Clojure\\mister-rogers\\src\\java"]
> :reloading (mister-rogers.core mister-rogers.protocols mister-rogers.problem
> mister-rogers.wrappers mister-rogers.core-test)
>
> recompiling all files in ["C:\\devel\\Clojure\\mister-rogers\\src\\java"]
> :reloading (mister-rogers.core mister-rogers.protocols mister-rogers.problem
> mister-rogers.wrappers mister-rogers.core-test)
> nREPL server started on port 49492 on host 127.0.0.1 - nrepl://127.0.0.1:49492
> REPL-y 0.3.7, nREPL 0.2.12
> Clojure 1.9.0
> Java HotSpot(TM) 64-Bit Server VM 1.8.0_66-b18
> Docs: (doc function-name-here)
> (find-doc "part-of-name-here")
> Source: (source function-name-here)
> Javadoc: (javadoc java-object-or-class-here)
> Exit: Control+D or (exit) or (quit)
> Results: Stored in vars *1, *2, *3, an exception in *e
>
> user=> (in-ns 'mister-rogers.wrappers)
> #namespace[mister-rogers.wrappers]
> mister-rogers.wrappers=> (get-test p)
>
> ClassCastException
> mister_rogers.wrappers.proxy$java.lang.Object$Interface$7e434bc9 cannot be
> cast to mister_rogers.wrappers.Interface mister-rogers.wrappers/get-test
> (wrappers.clj:82)
>
>
> Thanks for looking at this.
>
>
> On Mon, Jul 30, 2018 at 3:43 AM, Nicola Mometto wrote:
> Can you paste an entire repl session, starting from how you launch it (e.g.
> lein repl vs clj -- ideally not from a project) reproducing this?
> I'm interested in taking a look but I simply cannot repro :/
>
>> On 30 Jul 2018, at 11:40, Mark Engelberg wrote:
>>
>> Yes, it is in a fresh environment.
>>
>> I find that the problematic example does work in the user namespace, but it
>> doesn't work in my segmented namespace (ns mister-rogers.wrappers, to be
>> really specific).
>>
>> On Mon, Jul 30, 2018 at 3:34 AM, Nicola Mometto wrote:
>> No, I just tested this on 1.9.0 and 1.8.0 and I get no reflection, as I'd
>> expect.
>>
>> Are you testing this in a fresh environment?
>>
>>
>>> On 30 Jul 2018, at 11:31, Mark Engelberg wrote:
>>>
>>> I'm using 1.9.0. Is this a behavior that recently changed?
>>>
>>> On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto wrote:
>>> Which version of clojure? This works fine in 1.10
>>>
>>> Clojure 1.10.0-master-SNAPSHOT
>>> user=> (set! *warn-on-reflection* true)
>>> true
>>> user=> (definterface Interface (test []))
>>> user.Interface
>>> user=> (def p (proxy [Object Interface] [] (test [] 1)))
>>> #'user/p
>>> user=> (defn get-test [o] (.test ^Interface o))
>>> #'user/get-test
>>> user=> (get-test p)
>>> 1
>>>
>>>
>>>> On 30 Jul 2018, at 11:26, Mark Engelberg wrote:
>>>>
>>>> Those fishy things were errors I made when simplifying and transcribing
>>>> the proxy to post, but I have it correct in my own code.
>>>>
>>>> Here's a more precise, tested minimal example:
>>>>
>>>> (definterface Interface (test []))
>>>> (def p (proxy [Object Interface] [] (test [] 1)))
>>>> (defn get-test [o] (.test ^Interface o))
>>>>
>>>> => (get-test p)
>>>> This throws an error that it can't cast the proxy to Interface.
>>>>
>>>> If you remove the ^Interface type hint, then get-test will work but will
>>>> trigger reflection.
>>>>
>>>> Thanks for looking at this. It seems like it should work, but it doesn't.
>>>>
>>>>
>>>> On Mon, Jul 30, 2018 at 3:06 AM, Nicola Mometto
>>>> wrote:
>>>> That's exactly what you should do and it does work, e.g.:
>>>>
>>>> user=> (set! *warn-on-reflection* true)
>>>> true
>>>> user=> (.meta ^clojure.lang.IMeta (proxy [clojure.lang.IMeta] [] (meta []
>>>> {:
Re: Calling proxy without reflection
That's surprising, but good to know. Thanks. On Tue, Jul 31, 2018 at 9:56 AM, Renzo Borgatti wrote: > Hey Mark, it's lein-virgil interfering. As of why, better opening an issue > there. > > Renzo > > > On 30 Jul 2018, at 11:50, Mark Engelberg > wrote: > > > > OK, I just pushed the repo (work in progress) to github. > https://github.com/Engelberg/mister-rogers > > At the bottom of mister-rogers.wrappers I tacked on the three lines > we've been discussing. > > https://github.com/Engelberg/mister-rogers/blob/ > 523fc29f8827193fa9ea6ae2e82649e2933e6ae3/src/clj/mister_ > rogers/wrappers.clj#L80 > > > > > > Here's a REPL interaction: > > > > C:\devel\Clojure\mister-rogers>lein repl > > > > recompiling all files in ["C:\\devel\\Clojure\\mister- > rogers\\src\\java"] > > :reloading (mister-rogers.core mister-rogers.protocols > mister-rogers.problem mister-rogers.wrappers mister-rogers.core-test) > > > > recompiling all files in ["C:\\devel\\Clojure\\mister- > rogers\\src\\java"] > > :reloading (mister-rogers.core mister-rogers.protocols > mister-rogers.problem mister-rogers.wrappers mister-rogers.core-test) > > nREPL server started on port 49492 on host 127.0.0.1 - nrepl:// > 127.0.0.1:49492 > > REPL-y 0.3.7, nREPL 0.2.12 > > Clojure 1.9.0 > > Java HotSpot(TM) 64-Bit Server VM 1.8.0_66-b18 > > Docs: (doc function-name-here) > > (find-doc "part-of-name-here") > > Source: (source function-name-here) > > Javadoc: (javadoc java-object-or-class-here) > > Exit: Control+D or (exit) or (quit) > > Results: Stored in vars *1, *2, *3, an exception in *e > > > > user=> (in-ns 'mister-rogers.wrappers) > > #namespace[mister-rogers.wrappers] > > mister-rogers.wrappers=> (get-test p) > > > > ClassCastException mister_rogers.wrappers.proxy$ > java.lang.Object$Interface$7e434bc9 cannot be cast to > mister_rogers.wrappers.Interface mister-rogers.wrappers/get-test > (wrappers.clj:82) > > > > > > Thanks for looking at this. > > > > > > On Mon, Jul 30, 2018 at 3:43 AM, Nicola Mometto > wrote: > > Can you paste an entire repl session, starting from how you launch it > (e.g. lein repl vs clj -- ideally not from a project) reproducing this? > > I'm interested in taking a look but I simply cannot repro :/ > > > >> On 30 Jul 2018, at 11:40, Mark Engelberg > wrote: > >> > >> Yes, it is in a fresh environment. > >> > >> I find that the problematic example does work in the user namespace, > but it doesn't work in my segmented namespace (ns mister-rogers.wrappers, > to be really specific). > >> > >> On Mon, Jul 30, 2018 at 3:34 AM, Nicola Mometto > wrote: > >> No, I just tested this on 1.9.0 and 1.8.0 and I get no reflection, as > I'd expect. > >> > >> Are you testing this in a fresh environment? > >> > >> > >>> On 30 Jul 2018, at 11:31, Mark Engelberg > wrote: > >>> > >>> I'm using 1.9.0. Is this a behavior that recently changed? > >>> > >>> On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto > wrote: > >>> Which version of clojure? This works fine in 1.10 > >>> > >>> Clojure 1.10.0-master-SNAPSHOT > >>> user=> (set! *warn-on-reflection* true) > >>> true > >>> user=> (definterface Interface (test [])) > >>> user.Interface > >>> user=> (def p (proxy [Object Interface] [] (test [] 1))) > >>> #'user/p > >>> user=> (defn get-test [o] (.test ^Interface o)) > >>> #'user/get-test > >>> user=> (get-test p) > >>> 1 > >>> > >>> > >>>> On 30 Jul 2018, at 11:26, Mark Engelberg > wrote: > >>>> > >>>> Those fishy things were errors I made when simplifying and > transcribing the proxy to post, but I have it correct in my own code. > >>>> > >>>> Here's a more precise, tested minimal example: > >>>> > >>>> (definterface Interface (test [])) > >>>> (def p (proxy [Object Interface] [] (test [] 1))) > >>>> (defn get-test [o] (.test ^Interface o)) > >>>> > >>>> => (get-test p) > >>>> This throws an error that it can't cast the proxy to Interface. > >>>> > >>>> If you remove the ^Interface type hint, then get-test will work b
Re: Calling proxy without reflection
I am seeing the same behavior when I remove the lein-virgil plugin. On Tue, Jul 31, 2018 at 11:38 AM, Mark Engelberg wrote: > That's surprising, but good to know. Thanks. > > On Tue, Jul 31, 2018 at 9:56 AM, Renzo Borgatti > wrote: > >> Hey Mark, it's lein-virgil interfering. As of why, better opening an >> issue there. >> >> Renzo >> >> > On 30 Jul 2018, at 11:50, Mark Engelberg >> wrote: >> > >> > OK, I just pushed the repo (work in progress) to github. >> https://github.com/Engelberg/mister-rogers >> > At the bottom of mister-rogers.wrappers I tacked on the three lines >> we've been discussing. >> > https://github.com/Engelberg/mister-rogers/blob/523fc29f8827 >> 193fa9ea6ae2e82649e2933e6ae3/src/clj/mister_rogers/wrappers.clj#L80 >> > >> > >> > Here's a REPL interaction: >> > >> > C:\devel\Clojure\mister-rogers>lein repl >> > >> > recompiling all files in ["C:\\devel\\Clojure\\mister-r >> ogers\\src\\java"] >> > :reloading (mister-rogers.core mister-rogers.protocols >> mister-rogers.problem mister-rogers.wrappers mister-rogers.core-test) >> > >> > recompiling all files in ["C:\\devel\\Clojure\\mister-r >> ogers\\src\\java"] >> > :reloading (mister-rogers.core mister-rogers.protocols >> mister-rogers.problem mister-rogers.wrappers mister-rogers.core-test) >> > nREPL server started on port 49492 on host 127.0.0.1 - nrepl:// >> 127.0.0.1:49492 >> > REPL-y 0.3.7, nREPL 0.2.12 >> > Clojure 1.9.0 >> > Java HotSpot(TM) 64-Bit Server VM 1.8.0_66-b18 >> > Docs: (doc function-name-here) >> > (find-doc "part-of-name-here") >> > Source: (source function-name-here) >> > Javadoc: (javadoc java-object-or-class-here) >> > Exit: Control+D or (exit) or (quit) >> > Results: Stored in vars *1, *2, *3, an exception in *e >> > >> > user=> (in-ns 'mister-rogers.wrappers) >> > #namespace[mister-rogers.wrappers] >> > mister-rogers.wrappers=> (get-test p) >> > >> > ClassCastException mister_rogers.wrappers.proxy$j >> ava.lang.Object$Interface$7e434bc9 cannot be cast to >> mister_rogers.wrappers.Interface mister-rogers.wrappers/get-test >> (wrappers.clj:82) >> > >> > >> > Thanks for looking at this. >> > >> > >> > On Mon, Jul 30, 2018 at 3:43 AM, Nicola Mometto >> wrote: >> > Can you paste an entire repl session, starting from how you launch it >> (e.g. lein repl vs clj -- ideally not from a project) reproducing this? >> > I'm interested in taking a look but I simply cannot repro :/ >> > >> >> On 30 Jul 2018, at 11:40, Mark Engelberg >> wrote: >> >> >> >> Yes, it is in a fresh environment. >> >> >> >> I find that the problematic example does work in the user namespace, >> but it doesn't work in my segmented namespace (ns mister-rogers.wrappers, >> to be really specific). >> >> >> >> On Mon, Jul 30, 2018 at 3:34 AM, Nicola Mometto >> wrote: >> >> No, I just tested this on 1.9.0 and 1.8.0 and I get no reflection, as >> I'd expect. >> >> >> >> Are you testing this in a fresh environment? >> >> >> >> >> >>> On 30 Jul 2018, at 11:31, Mark Engelberg >> wrote: >> >>> >> >>> I'm using 1.9.0. Is this a behavior that recently changed? >> >>> >> >>> On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto >> wrote: >> >>> Which version of clojure? This works fine in 1.10 >> >>> >> >>> Clojure 1.10.0-master-SNAPSHOT >> >>> user=> (set! *warn-on-reflection* true) >> >>> true >> >>> user=> (definterface Interface (test [])) >> >>> user.Interface >> >>> user=> (def p (proxy [Object Interface] [] (test [] 1))) >> >>> #'user/p >> >>> user=> (defn get-test [o] (.test ^Interface o)) >> >>> #'user/get-test >> >>> user=> (get-test p) >> >>> 1 >> >>> >> >>> >> >>>> On 30 Jul 2018, at 11:26, Mark Engelberg >> wrote: >> >>>> >> >>>> Those fishy things were errors I made when simplifying and >> transcribing the proxy to post, but I have it correct in my own code. >> >>&g
Re: Calling proxy without reflection
Commented in pull request https://github.com/Engelberg/mister-rogers/pull/1 > On 1 Aug 2018, at 02:38, Mark Engelberg wrote: > > I am seeing the same behavior when I remove the lein-virgil plugin. > > On Tue, Jul 31, 2018 at 11:38 AM, Mark Engelberg > wrote: > That's surprising, but good to know. Thanks. > > On Tue, Jul 31, 2018 at 9:56 AM, Renzo Borgatti wrote: > Hey Mark, it's lein-virgil interfering. As of why, better opening an issue > there. > > Renzo > > > On 30 Jul 2018, at 11:50, Mark Engelberg wrote: > > > > OK, I just pushed the repo (work in progress) to github. > > https://github.com/Engelberg/mister-rogers > > At the bottom of mister-rogers.wrappers I tacked on the three lines we've > > been discussing. > > https://github.com/Engelberg/mister-rogers/blob/523fc29f8827193fa9ea6ae2e82649e2933e6ae3/src/clj/mister_rogers/wrappers.clj#L80 > > > > > > Here's a REPL interaction: > > > > C:\devel\Clojure\mister-rogers>lein repl > > > > recompiling all files in ["C:\\devel\\Clojure\\mister-rogers\\src\\java"] > > :reloading (mister-rogers.core mister-rogers.protocols > > mister-rogers.problem mister-rogers.wrappers mister-rogers.core-test) > > > > recompiling all files in ["C:\\devel\\Clojure\\mister-rogers\\src\\java"] > > :reloading (mister-rogers.core mister-rogers.protocols > > mister-rogers.problem mister-rogers.wrappers mister-rogers.core-test) > > nREPL server started on port 49492 on host 127.0.0.1 - > > nrepl://127.0.0.1:49492 > > REPL-y 0.3.7, nREPL 0.2.12 > > Clojure 1.9.0 > > Java HotSpot(TM) 64-Bit Server VM 1.8.0_66-b18 > > Docs: (doc function-name-here) > > (find-doc "part-of-name-here") > > Source: (source function-name-here) > > Javadoc: (javadoc java-object-or-class-here) > > Exit: Control+D or (exit) or (quit) > > Results: Stored in vars *1, *2, *3, an exception in *e > > > > user=> (in-ns 'mister-rogers.wrappers) > > #namespace[mister-rogers.wrappers] > > mister-rogers.wrappers=> (get-test p) > > > > ClassCastException > > mister_rogers.wrappers.proxy$java.lang.Object$Interface$7e434bc9 cannot be > > cast to mister_rogers.wrappers.Interface mister-rogers.wrappers/get-test > > (wrappers.clj:82) > > > > > > Thanks for looking at this. > > > > > > On Mon, Jul 30, 2018 at 3:43 AM, Nicola Mometto wrote: > > Can you paste an entire repl session, starting from how you launch it (e.g. > > lein repl vs clj -- ideally not from a project) reproducing this? > > I'm interested in taking a look but I simply cannot repro :/ > > > >> On 30 Jul 2018, at 11:40, Mark Engelberg wrote: > >> > >> Yes, it is in a fresh environment. > >> > >> I find that the problematic example does work in the user namespace, but > >> it doesn't work in my segmented namespace (ns mister-rogers.wrappers, to > >> be really specific). > >> > >> On Mon, Jul 30, 2018 at 3:34 AM, Nicola Mometto > >> wrote: > >> No, I just tested this on 1.9.0 and 1.8.0 and I get no reflection, as I'd > >> expect. > >> > >> Are you testing this in a fresh environment? > >> > >> > >>> On 30 Jul 2018, at 11:31, Mark Engelberg wrote: > >>> > >>> I'm using 1.9.0. Is this a behavior that recently changed? > >>> > >>> On Mon, Jul 30, 2018 at 3:28 AM, Nicola Mometto > >>> wrote: > >>> Which version of clojure? This works fine in 1.10 > >>> > >>> Clojure 1.10.0-master-SNAPSHOT > >>> user=> (set! *warn-on-reflection* true) > >>> true > >>> user=> (definterface Interface (test [])) > >>> user.Interface > >>> user=> (def p (proxy [Object Interface] [] (test [] 1))) > >>> #'user/p > >>> user=> (defn get-test [o] (.test ^Interface o)) > >>> #'user/get-test > >>> user=> (get-test p) > >>> 1 > >>> > >>> > >>>> On 30 Jul 2018, at 11:26, Mark Engelberg > >>>> wrote: > >>>> > >>>> Those fishy things were errors I made when simplifying and transcribing > >>>> the proxy to post, but I have it correct in my own code. > >>>> > >>>> Here's a more precise, tested minimal example: > >>>> > >>>> (definterface Interf
Re: Calling proxy without reflection
For those following along at home, it turned out not to be a problem with the lein-virgil plugin. It's apparently a bug in Clojure. Renzo and I distilled it down to the following steps: user=> (definterface Interface (test [])) user.Interface user=> (def p (proxy [Object Interface] [] (test [] 1))) #'user/p user=> (defn get-test [o] (.test ^Interface o)) #'user/get-test user=> (get-test p) 1 user=> (definterface Interface (test [])) user.Interface user=> (def p (proxy [Object Interface] [] (test [] 1))) #'user/p user=> (defn get-test [o] (.test ^Interface o)) #'user/get-test user=> (get-test p) ClassCastException user.proxy$java.lang.Object$Interface$936446c6 cannot be cast to user.Interface user/get-test (form-init7484886365563813996.clj:1) -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Calling proxy without reflection
And there's less! It's not necessary to issue the first (defn... or (get-test... (I tried in Clojure 1.8 only) -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Calling proxy without reflection
yes, the problem is with `proxy` and redefinition, I'm working on a patch to fix this > On 2 Aug 2018, at 07:55, Mark Engelberg wrote: > > For those following along at home, it turned out not to be a problem with the > lein-virgil plugin. It's apparently a bug in Clojure. Renzo and I distilled > it down to the following steps: > > user=> (definterface Interface (test [])) > user.Interface > user=> (def p (proxy [Object Interface] [] (test [] 1))) > #'user/p > user=> (defn get-test [o] (.test ^Interface o)) > #'user/get-test > user=> (get-test p) > 1 > user=> (definterface Interface (test [])) > user.Interface > user=> (def p (proxy [Object Interface] [] (test [] 1))) > #'user/p > user=> (defn get-test [o] (.test ^Interface o)) > #'user/get-test > user=> (get-test p) > > ClassCastException user.proxy$java.lang.Object$Interface$936446c6 cannot be > cast to user.Interface user/get-test (form-init7484886365563813996.clj:1) > > > > -- > 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 > <http://groups.google.com/group/clojure?hl=en> > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com > <mailto:clojure+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Calling proxy without reflection
https://dev.clojure.org/jira/browse/CLJ-2379 > On 2 Aug 2018, at 10:22, Nicola Mometto wrote: > > yes, the problem is with `proxy` and redefinition, I'm working on a patch to > fix this > >> On 2 Aug 2018, at 07:55, Mark Engelberg > <mailto:mark.engelb...@gmail.com>> wrote: >> >> For those following along at home, it turned out not to be a problem with >> the lein-virgil plugin. It's apparently a bug in Clojure. Renzo and I >> distilled it down to the following steps: >> >> user=> (definterface Interface (test [])) >> user.Interface >> user=> (def p (proxy [Object Interface] [] (test [] 1))) >> #'user/p >> user=> (defn get-test [o] (.test ^Interface o)) >> #'user/get-test >> user=> (get-test p) >> 1 >> user=> (definterface Interface (test [])) >> user.Interface >> user=> (def p (proxy [Object Interface] [] (test [] 1))) >> #'user/p >> user=> (defn get-test [o] (.test ^Interface o)) >> #'user/get-test >> user=> (get-test p) >> >> ClassCastException user.proxy$java.lang.Object$Interface$936446c6 cannot be >> cast to user.Interface user/get-test (form-init7484886365563813996.clj:1) >> >> >> >> -- >> 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 >> <mailto: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 >> <mailto:clojure+unsubscr...@googlegroups.com> >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> <http://groups.google.com/group/clojure?hl=en> >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com >> <mailto:clojure+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: ClojureScript repl over proxy
Hi, I would stick with SSH tunnels for this tbh.. Because once you fix this particular issue right here, there's 2-3 similar issues showing up in 2-4 months; who knows. I use a tiny bash script in each project that deals with the particular ports needed. mvh, L On Wednesday, April 21, 2021 at 8:40:35 PM UTC+3 rv.m...@gmail.com wrote: > Hi, > > I'm using a cloud development platform (Gitpod) and it automatically > creates proxy from public URL to localhost, so you can develop a web > application from cloud and see the result. I'm trying to run cljs REPL, but > it fails to connect because it tries to connect to the REPL on > `localhost:9090` which is not accessible from outside because I use public > URL in a browser. > > I have looked at the code and looks like HOST and PORT in browser > hard-coded > > https://github.com/clojure/clojurescript/blob/a4673b880756531ac5690f7b4721ad76c0810327/src/main/cljs/clojure/browser/repl.cljs#L31 > > but still maybe I have missed something, and it's possible to set up REPL > for my use case. So would be glad to any response > > 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/f258d0ee-fcbe-4918-8426-673fe28054a0n%40googlegroups.com.
Re: ClojureScript repl over proxy
Thanks, but how SSH tunnel would help here? Currently, I see that ClojureScript hard coded localhost HOST and PORT in the JavaScript code which would send a request from the browser to establish REPL connection. Or you suggest setup forwarding localhost:9090 from local machine to the cloud? :) In this case it removes all advantages of cloud development because I should set up local environment before and in some cases I even could not do it at all On Thursday, April 22, 2021 at 1:58:01 PM UTC+3 larsn...@gmail.com wrote: > Hi, > I would stick with SSH tunnels for this tbh.. Because once you fix this > particular issue right here, there's 2-3 similar issues showing up in 2-4 > months; who knows. I use a tiny bash script in each project that deals with > the particular ports needed. > > mvh, L > > On Wednesday, April 21, 2021 at 8:40:35 PM UTC+3 rv.m...@gmail.com wrote: > >> Hi, >> >> I'm using a cloud development platform (Gitpod) and it automatically >> creates proxy from public URL to localhost, so you can develop a web >> application from cloud and see the result. I'm trying to run cljs REPL, but >> it fails to connect because it tries to connect to the REPL on >> `localhost:9090` which is not accessible from outside because I use public >> URL in a browser. >> >> I have looked at the code and looks like HOST and PORT in browser >> hard-coded >> >> https://github.com/clojure/clojurescript/blob/a4673b880756531ac5690f7b4721ad76c0810327/src/main/cljs/clojure/browser/repl.cljs#L31 >> >> but still maybe I have missed something, and it's possible to set up REPL >> for my use case. So would be glad to any response >> >> 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/0d83b21a-745e-4b12-b27d-d9566bf748b2n%40googlegroups.com.
Re: Method overloading & proxy method
On Mar 21, 6:13 pm, ronen wrote: > Hello there, > Iv been trying to implement a proxy on a class > (http://code.google.com/p/javaparser/source/browse/trunk/JavaParser/sr...) > that has multiple overloaded methods (same arity different types), > trying > > (defn create-visitor [] > (proxy [VoidVisitorAdapter] [] > (visit [method, arg] > (println method)) > (visit [exp, arg] > (println type > > This results with compilation error Caused by: > java.lang.IllegalArgumentException: Method 'visit' redefined. > > Type hints didn't help either: Proxy doesn't care about argument types. You need one method with a conditional: (defn create-visitor [] (proxy [VoidVisitorAdapter] [] (visit [arg1 arg2] (if (instance? MethodDeclaration arg1) ... You could also define a multimethod and call it from the proxy. -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 -~--~~~~--~~--~--~---
Re: Method overloading & proxy method
Well it seems to be more complicated than that, defining a visit method overrides the call to the visit(CompilationUnit n, A arg) method which contains the basic visitation logic, what that I actually need is a way of overriding specific methods (like the visit (MethodDeclaration n, A arg) and not all of them. My best guess is that I should somehow manually map the proxy methods. On Mar 22, 6:19 pm, Stuart Sierra wrote: > On Mar 21, 6:13 pm, ronen wrote: > > > > > Hello there, > > Iv been trying to implement a proxy on a class > > (http://code.google.com/p/javaparser/source/browse/trunk/JavaParser/sr...) > > that has multiple overloaded methods (same arity different types), > > trying > > > (defn create-visitor [] > > (proxy [VoidVisitorAdapter] [] > > (visit [method, arg] > > (println method)) > > (visit [exp, arg] > > (println type > > > This results with compilation error Caused by: > > java.lang.IllegalArgumentException: Method 'visit' redefined. > > > Type hints didn't help either: > > Proxy doesn't care about argument types. You need one method with a > conditional: > > (defn create-visitor [] > (proxy [VoidVisitorAdapter] [] > (visit [arg1 arg2] > (if (instance? MethodDeclaration arg1) > ... > > You could also define a multimethod and call it from the proxy. > > -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 -~--~~~~--~~--~--~---
Re: Method overloading & proxy method
On Mar 23, 9:55 am, ronen wrote: > [... what] I actually need is a way of overriding specific methods (like the > visit > (MethodDeclaration n, A arg) and not all of them. I keep running into this problem again and again myself, so I thought I might post some notes. The short of it: doing anything fancy with proxy gets hard fast but there is a way to do it with gen-class. In my case I'd like to subclass java.io.InputStream and implement the abstract read() method but NOT override the non-abstract read(byte[] b) and read(byte[] b, int off, int len). So what I really want to do is something like this: (def is (proxy [java.io.InputStream] [] (read [] (int \a Which works okay for this: (.read is) => 97 But if anything calls the other overloaded methods like this: (.read is (make-array (. Byte TYPE) 10)) We get a: java.lang.IllegalArgumentException: Wrong number of args passed to: user$fn--1844$fn So it seems as Stuart explained, proxy overrdes all the "read" methods, not just the zero-arity one. So my next attempt was to use proxy-super. This was also the suggestion from my friendly neighbourhood Clojure guru, Mark Triggs: (def is (proxy [java.io.InputStream] [] (read [& args] (println args) (cond (= (count args) 0) (int \a) (= (count args) 1) (proxy-super read (first args)) (= (count args) 3) (proxy-super read (first args) (second args) (nth args 3)) (.read is) => 97 (.read is (make-array (. Byte TYPE) 10)) => java.lang.AbstractMethodError: java.io.InputStream.read()I 0: clojure.proxy.java.io.InputStream.read(Unknown Source) 1: java.io.InputStream.read(InputStream.java:154) 2: clojure.proxy.java.io.InputStream.read(Unknown Source) 3: java.io.InputStream.read(InputStream.java:85) 4: clojure.proxy.java.io.InputStream.read(Unknown Source) So what's going on here? Well, my (.read is bytes) is doing (proxy- super read bytes) okay. The java code then does a this.read(bytes, 0, bytes.size). So my code passes this through to the super-class again which finally does a this.read(). Unfortunately, as Mark explains "[proxy-super] works by temporarily hiding your overriding implementation of a method. For abstract classes that freaks out the JVM because it looks like you haven't implemented everything." So since read has been hidden, the java code attempting to call it just sees it's own abstract method which it obviously can't execute. In this case I can obviously resort to just reimplementing the other two methods, but it's a bit frustrating. This is a fairly common pattern in Java code, needing to subclass something and define one method foo() where there's a bunch of other overloaded convenience versions of it in the superclass which call the one you've overriden. Thankfully, Mark managed to figure out a way of doing it with with gen- class by using an undocumented (?) feature where you can put types into the method names so as to pick the exact one you want to override: (ns org.example.FancyInputStream (:gen-class :extends java.io.InputStream)) (defn -read-void [this] (int \a)) This now works as expected. Mark's notes on this are here: http://dishevelled.net/Tricky-uses-of-Clojure-gen-class-and-AOT-compilation.html --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Method overloading & proxy method
On May 4, 11:52 pm, Alex Osborne wrote: > Thankfully, Mark managed to figure out a way of doing it with with gen- > class by using an undocumented (?) feature where you can put types > into the method names so as to pick the exact one you want to > override: > > (ns org.example.FancyInputStream > (:gen-class :extends java.io.InputStream)) > (defn -read-void [this] > (int \a)) Related: You can also use the :exposes-methods argument to gen-class to access superclass methods. -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 -~--~~~~--~~--~--~---
Re: Method overloading & proxy method
Well the solution in my case was to create a map from visited types to visited members (http://tinyurl.com/poq5e2) the visitation logic uses this map in order to invoke the next visit (http://tinyurl.com/ pkugra). This "pattern" enables visitors to be implemented in Clojure for pure Java based frameworks (like AST visitors). On May 5, 6:00 pm, Stuart Sierra wrote: > On May 4, 11:52 pm, Alex Osborne wrote: > > > Thankfully, Mark managed to figure out a way of doing it with with gen- > > class by using an undocumented (?) feature where you can put types > > into the method names so as to pick the exact one you want to > > override: > > > (ns org.example.FancyInputStream > > (:gen-class :extends java.io.InputStream)) > > (defn -read-void [this] > > (int \a)) > > Related: You can also use the :exposes-methods argument to gen-class > to access superclass methods. > > -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 -~--~~~~--~~--~--~---
Re: classloading / proxy / JMX issue
On Wed, Jul 22, 2009 at 10:45 PM, Stuart
Halloway wrote:
>
> I have a failing test in the JMX server code [1]:
>
> (deftest dynamic-mbean
> (let [mbean-name "clojure.contrib.test_contrib.test_jmx:name=Foo"]
> (jmx/register-mbean
> (jmx/dynamic-mbean
> (ref {:string-attribute "a-string"}))
> mbean-name)
> (is (= "a-string" (jmx/read mbean-name :string-attribute)
>
>
> The weird thing is, the same exact code works from the REPL. The
> second weird thing is, the error is a permissions error (and no
> SecurityManager is installed).
>
> In the interest of decency, I will show only a fraction of the stack
> trace:
>
> actual: java.security.AccessControlException: access denied
> (javax.management.MBeanTrustPermission register)
> [java] at java.security.AccessControlContext.checkPermission
> (AccessControlContext.java:264)
> java.lang.SecurityManager.checkPermission (SecurityManager.java:568)
>
> com
> .sun
> .jmx
> .interceptor.DefaultMBeanServerInterceptor.checkMBeanTrustPermission
> (DefaultMBeanServerInterceptor.java:1724)
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean
> (DefaultMBeanServerInterceptor.java:335)
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean
> (JmxMBeanServer.java:497)
> sun.reflect.NativeMethodAccessorImpl.invoke0
> (NativeMethodAccessorImpl.java:-2)
> sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke (Method.java:585)
> clojure.lang.Reflector.invokeMatchingMethod (Reflector.java:90)
> clojure.lang.Reflector.invokeInstanceMethod (Reflector.java:28)
> clojure.contrib.jmx/register_mbean (server.clj:17)
>
> Since the code works at the REPL, I suspect a classloader issue. Am I
> right? If so, can I change the classloader used by Clojure's proxy
> function?
>
I took a quick look at the lib, and yes, it could be a classloader
thing. But I wonder if your plan is destined for success. If
registerMBean is capturing the actual class of a proxy there are a few
issues. One is that proxy doesn't guarantee a unique class per usage,
in fact, currently it will reuse the same class for any invocation
with the same set of superclasses.
The second has to do with visibility. There simply is no way to
dynamically generate a class accessible by name from every other class
in an app, due at least to classloader hierarchy in the basic Java
case, and modularity systems like OSGi make it less possible, since
they are working to prevent exactly that.
Even if proxy did generate a unique class per call site _and_ you
could establish a classloader of your choice with context classloader
or something, you'd still have a problem in that there is no standard
root classloader that will load classes for you from bytecode, so such
a classloader has to be a child of another, and thus the classes it
loads not universally visible.
The bottom line is that the instances generated by proxy are meant to
be manipulated via the interfaces they implement. The specific classes
of which they are instances is an implementation detail.
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: classloading / proxy / JMX issue
I am learning JMX as a I go here (by writing tests) and was hoping that registerMBean doesn't depend on the actual class (or its name). What's the point of interfaces if you write APIs that require classes? I am still hoping to make this work with a proxy, but I will try out a genclass-based approach and see if that fixes things. Maybe a better way to summarize my position is that I understand class loaders, and I am wondering how poorly-behaved the JMX API is. Stu > I took a quick look at the lib, and yes, it could be a classloader > thing. But I wonder if your plan is destined for success. If > registerMBean is capturing the actual class of a proxy there are a few > issues. One is that proxy doesn't guarantee a unique class per usage, > in fact, currently it will reuse the same class for any invocation > with the same set of superclasses. > > The second has to do with visibility. There simply is no way to > dynamically generate a class accessible by name from every other class > in an app, due at least to classloader hierarchy in the basic Java > case, and modularity systems like OSGi make it less possible, since > they are working to prevent exactly that. > > Even if proxy did generate a unique class per call site _and_ you > could establish a classloader of your choice with context classloader > or something, you'd still have a problem in that there is no standard > root classloader that will load classes for you from bytecode, so such > a classloader has to be a child of another, and thus the classes it > loads not universally visible. > > The bottom line is that the instances generated by proxy are meant to > be manipulated via the interfaces they implement. The specific classes > of which they are instances is an implementation detail. > > 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: Syntax for proxy methods?
On Oct 1, 9:18 pm, timc wrote: > (def prx (proxy [IX][] > (doit > ([] (doseq [x someSeq] (doit x)) > ([y] (print y > > When I tried something of this form, it looks like the call of the 1- > arg function from the 0-arg function can't be resolved. > > Thanks in advance I'm not certain, but since it's a java method, shouldn't you call it like (.doit this x)? --~--~-~--~~~---~--~~ 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: Syntax for proxy methods?
No, its a proxy for an interface. On Oct 1, 7:22 pm, Jarkko Oranen wrote: > On Oct 1, 9:18 pm, timc wrote: > > > > (def prx (proxy [IX][] > > (doit > > ([] (doseq [x someSeq] (doit x)) > > ([y] (print y > > > When I tried something of this form, it looks like the call of the 1- > > arg function from the 0-arg function can't be resolved. > > > Thanks in advance > > I'm not certain, but since it's a java method, shouldn't you call it > like (.doit this x)? --~--~-~--~~~---~--~~ 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: Syntax for proxy methods?
Oops, I spoke too hastily -- thank you Jarkko. On Oct 1, 8:38 pm, timc wrote: > No, its a proxy for an interface. > > On Oct 1, 7:22 pm, Jarkko Oranen wrote: > > > On Oct 1, 9:18 pm, timc wrote: > > > > > > (def prx (proxy [IX][] > > > (doit > > > ([] (doseq [x someSeq] (doit x)) > > > ([y] (print y > > > > When I tried something of this form, it looks like the call of the 1- > > > arg function from the 0-arg function can't be resolved. > > > > Thanks in advance > > > I'm not certain, but since it's a java method, shouldn't you call it > > like (.doit this x)? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Replacing proxy with reify/deftype
As has been discussed here previously, one way to generate an uncached stream of numbers is: (defn incs [i] (proxy [clojure.lang.ASeq] [] (first [] i) (next [] (incs (inc i) ASeq implements most of the machinery of sequences, so you can just implement the parts that differ. I'd like to replace some of my proxies with the new reify or deftype constructs in order to benefit from the improved performance. But as far as I can tell, there's no way to do that and leverage default implementations provided by ASeq. Has anyone here rewritten ASeq as a mixin-map of functions to be used with extend and reify to avoid the dependence on a base class? Is there another approach I'm missing? -- 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
