book [clojure programming] confuse
pdf version page 165: " Promises don’t detect cyclic dependencies This means that (deliver p @p), where p is a promise, will block indefinitely. However, such blocked promises are not locked down, and the situation can be resolved: (def a (promise)) (def b (promise)) (future (deliver a @b)) ;---1 (future (deliver b @a)) ;2 (realized? a) ;= false (realized? b) ;= false (deliver a 42) ;3 ;= # @a ;= 42 @b ;= 42 1Futures are used there to not block the REPL. 2-a and b are not delivered yet. 3-Delivering a allows the blocked deliveries to resume—obviously (deliver a @b) is going to fail (to return nil) but (deliver b @a) proceeds happily. " why " deliver a @b is going to fail " ? 1 and 2 are just two independent threads , "deliver a 42" will unblock thread 2 , and then thread 1 will be unblocked . pdf version page 165: " An immediately practical application of promises is in easily making callback-based APIs synchronous. Say you have a function that takes another function as a callback: (defn call-service [arg1 arg2 callback-fn] ; ...perform service call, eventually invoking callback-fn with results... (future (callback-fn (+ arg1 arg2) (- arg1 arg2 Using this function’s results in a synchronous body of code requires providing a call- back, and then using any number of different (relatively unpleasant) techniques to wait for the callback to be invoked with the results. Alternatively, you can write a simple wrapper on top of the asynchronous, callback-based API that uses a promise’s blocking behavior on deref to enforce the synchronous semantics for you. Assuming for the moment that all of the asynchronous functions you’re interested in take the callback as their last argument, this can be implemented as a general-purpose higher-order function: (defn sync-fn [async-fn] (fn [& args] (let [result (promise)] (apply async-fn (conj (vec args) #(deliver result %&))) @result))) ((sync-fn call-service) 8 7) ;= (15 1) " what is the pointer of function sync-fn ? what is the execution sequence of functions such as sync-fn,call-servervice, and callback-fn ? statement "((sync-fn call-service) 8 7) ", where is the callback-fn parameter ? -- You 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: Just found out about Elixirs function argument pattern matching...
I don't use schema/core.typed much in my actual projects, while I have done
many attempts it just never worked out. I like the idea and should
definitely use them more but it is just too much of a moving system and not
stable enough yet (eg. didn't even know s/either is deprecated).
If you look at these implementations
(def OneOff [(s/one s/Str 'name) (s/one s/Str 'email)])
(s/defrecord OneOff
[name :- s/Str
email :- s/Str])
(defrecord OneOff [name email])
All of them do more or less the same thing, just different. Clojure has
really good support for records and they feel natural to me. I don't need
to remember that :email is the second field. So I can do (:email one-off)
instead of (get one-off 1). Remembering the positions can get tedious and
very error prone over time. Always remember that software evolves over time.
(:email one-off) still works if my data changes to (defrecord OneOff [name
note email]), the vector version doesn't. Referring to things by name is a
good thing.
I do not know Elixir but in Erlang you very rarely use tuples for actual
data, usually just messages and return values. Data is all Records, maybe
maps these days but I left before R15B so can't say.
I usually only do data validation on the system boundary and trust in it
after. Otherwise you might end up validating the same data over and over
again. So if I get something from a user (eg. HTTP) I validate that it is
what I expect and transform if needed. I have an explicit (if
(is-this-what-i-expect? data) ...) and not something hidden in a {:pre ...}
or some macro magic. I expect the data to be wrong (never trust the user)
and want to test that assumption ASAP. I don't like to use exception for
validation errors. Writing validation functions is not fun but it is very
simple.
YMMV, do what feels right.
Keep it simple.
/thomas
On Tue, Sep 8, 2015 at 4:42 AM, Amith George wrote:
> >> I probably wouldn't use protocols since I doubt there is a function
> signature that is exactly identical for all branches. Each branch probably
> needs access to different parts of your system (eg. database) and always
> passing everything to everything is not ideal.
>
> >> Multi-Method is great if you want something openly extensible but that
> again seems unlikely here and also assumes that everything requires the
> same arguments.
>
> I had the same concerns and wanted to use a simple function with
> pattern/condition matching to dispatch to the appropriate function. I had
> considered using Records as synonymous with using polymorphic calls (multi
> methods, protocols). Its good to know the alarm bells ringing in my head
> had merit :). Thanks for that.
>
> Thinking out loud, if we are not using Records for polymorphism, are we
> using it to guarantee structure? If you could indulge me a little more,
> consider the following two implementations.
>
>
> (def OneOff [(s/one s/Str 'name) (s/one s/Str 'email)])
>
> (defn send-one-off
> [something thing [name email :as data]]
> {:pre [(s/validate OneOff data)]}
> ,,,)
>
> (defn send
> [app thing recipient]
> (match [recipient]
> [[:one-off & data]] (send-one-off (:something app) thing data)))
>
>
>
>
> Individual schema are created for each variant case and are checked
> against by the respective functions. The dispatch function only needs to
> know how to check for individual cases of the variant.
>
>
> (def OneOffMap {:type (s/eq :one-off) :name s/Str :email s/Str})
> (def ExistingContactMap {:type (s/eq :existing) :contact-id s/Int})
>
> (def Recipient (s/either ExistingContactMap OneOffMap))
> ;; s/either is deprecated and s/cond-pre is recommended
> ;; however, validating valid OneOffMap data using the following
> ;; still throws an error.
> ;; (def Recipient (s/cond-pre ExistingContactMap OneOffMap))
>
> (defn send-one-off
> [something thing {:keys [name email] :as data}]
> ,,,)
>
> (defn send
> [app thing recipient]
> {:pre [(s/validate Recipient recipient)]}
> (match [(:type recipient)]
> [:one-off] (send-one-off (:something app) thing recipient)))
>
> This reverts to using a map with a :type key. Individuals schema for each
> :type value. A combined schema to represent a recipient. The dispatch
> function only needs to know about the existence of the :type key and the
> values it can handle.
>
>
> Whether we use records or maps or variants, the dispatch function needs to
> know what contract is implemented by recipient. Whether it will be an
> instance of something, or a variant or a map with type keys. Neither
> versions care for any other data present in recipient or its structure.
>
> At this point I am confused, what makes one version better than the other.
> Creating schema definitions for the records seemed a lot easier than for
> the other two. Also I am assuming that if records are created using
> s/defrecord, the factory functions (->, map->) will automatically validate
> them?
>
> I really appreciate you taking the time to clarify th
Re: Just found out about Elixirs function argument pattern matching...
On 8 September 2015 at 11:38, Thomas Heller wrote:
>
> If you look at these implementations
>
> (def OneOff [(s/one s/Str 'name) (s/one s/Str 'email)])
>
> (s/defrecord OneOff
> [name :- s/Str
> email :- s/Str])
>
> (defrecord OneOff [name email])
>
> All of them do more or less the same thing, just different. Clojure has
> really good support for records and they feel natural to me. I don't need
> to remember that :email is the second field. So I can do (:email one-off)
> instead of (get one-off 1). Remembering the positions can get tedious and
> very error prone over time. Always remember that software evolves over time.
>
> (:email one-off) still works if my data changes to (defrecord OneOff [name
> note email]), the vector version doesn't. Referring to things by name is a
> good thing.
>
I think everyone agrees that in the above example, a map or record would be
better than a vector. The discussion is more is how to represent what's
loosely analogous to a single key and value pair.
For instance, which one of these to you consider to be the best
representation of a event to set the expiry time:
[:cache/expire #inst "2015-09-08T12:00:00Z"]
{:type :cache/expire, :value #inst "2015-09-08T12:00:00Z"}
#cache.Expire [#inst "2015-09-08T12:00:00Z"]
#cache.Expire {:value #inst "2015-09-08T12:00:00Z"}
- James
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
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: Just found out about Elixirs function argument pattern matching...
>
>
> For instance, which one of these to you consider to be the best
> representation of a event to set the expiry time:
>
>[:cache/expire #inst "2015-09-08T12:00:00Z"]
>
>{:type :cache/expire, :value #inst "2015-09-08T12:00:00Z"}
>
>#cache.Expire [#inst "2015-09-08T12:00:00Z"]
>
>#cache.Expire {:value #inst "2015-09-08T12:00:00Z"}
>
None of those, well the {:type ... :value ...} one is closest.
I tried to stay away from the Type/Variant discussion since I'm not
familiar enough with all the theory behind it and generally like to be more
practical. Also there isn't enough context in your question to give an
acceptable answer. Generally I'd have something like (set-expiration-time
thing time) but since you said "event" I assume you have some kind of
messaging system. So I'd abstract the usual message patterns and use a
message "envelope".
(defrecord Message [type payload])
type would probably be a Keyword and payload probably Any.
So to write it as edn:
#my.app/message [:cache/expire #inst "2015-09-08T12:00:00Z"]
#my.app/message {:type :cache/expire, :payload ...}
Note that this is ONLY the representation on-the-wire which you generally
want to be compact as possible, so I'd choose the vector variant since it
is more compact and doesn't encode the keys.
What I get when I "read" this data is not tied to the data format used on
the wire though, don't mix those up. The wire-format has totally different
requirements than your code.
/thomas
--
You 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: book [clojure programming] confuse
Johnny, On Tue, Sep 8, 2015 at 11:32 AM, Johnny Wong wrote: > > why " deliver a @b is going to fail " ? 1 and 2 are just two > independent threads , "deliver a 42" will unblock thread 2 , and then > thread 1 will be unblocked . > Thread 1 is waiting on delivering a result to "a", though, which has already happened with the outer (deliver a 42) - one result per promise. > what is the pointer of function sync-fn ? what is the execution sequence > of functions such as sync-fn,call-servervice, and callback-fn ? > statement "((sync-fn call-service) 8 7) ", where is the callback-fn > parameter ? > After the apply, call-service ends up being invoked as (call-service 8 7 #(deliver result %&)) - the callback-fn is that final anonymous function which delivers the "result" promise a sequence of its arguments (%&). sync-fn is geared towards multiple invocations - a named example may be very slightly clearer: (def call-service-sync (sync-fn call-service)) (call-service-sync 8 7) ;; => (15 1) The sequence is: - Invoke (sync-fn call-service), which returns a wrapper around call-service, using a callback-fn which is internal to the wrapper (consumers of sync-fn are trying to ignore callback-fn) - Invoke the returned function/wrapper with the arguments to the wrapped (call-service) function (8 7), minus callback-fn - The wrapper forwards these arguments to call-service, plus a callback-fn which delivers its arguments to a promise - The wrapper blocks on dereferencing the promise - The outermost caller receives the value delivered to the promise Take care, Moe -- You 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: Type hint using protocol
I'm finally looking at warn on reflection. Everything is going fine except in the nodes.clj file where I define a protocol, INode, with a method, new-node and then try to call that method from a function, revise. I'm using Clojure 1.7.0 and the file is https://github.com/laforge49/aatree/blob/master/src/aatree/nodes.clj The reflection warning occurs on line 51. Depending on what I try, either I get a class not found compiler error for file nodes.cli or a runtime error that new-node is NOT a member of the record that implements INode. I've spent hours on this and have tried many different things to no avail. My reason for using a method in a protocol is that I have several records that implement it and I'm trying to not duplicate functions which take the protocol as an argument. Oh yes, because I'm also using genclass, I have no option but to use AOT. On Sunday, January 12, 2014 at 8:52:14 AM UTC-5, Jim foo.bar wrote: > > there you go: > > (defprotocol IBark > (bark [this])) > > (in-ns 'other) > (set! user/*warn-on-reflection* true) > > (clojure.core/defrecord Dog [] > user/IBark > (bark [_] (clojure.core/println "WOOF!"))) > > (def d (Dog.)) > > (user/bark d) ;;NO reflection > > (.bark d) ;;reflection > > it should be obvious now :) > > Jim > > > On 12/01/14 13:38, Jim - FooBar(); wrote: > > It is not compiling because it cannot find the function...either fully > qualify it like in my previous email or change your ns declaration to > something like: > > [cqrs.storage :as stora] > > and then simply use stora/ret-value, stora/write, stora/write-batch > > Jim > > > > On 12/01/14 13:26, bob wrote: > > If I remove the dot, it cannot be compiled. can you give an example? > > On Sunday, January 12, 2014 9:22:00 PM UTC+8, Jim foo.bar wrote: >> >> I am suspecting you are calling the protocol implementations via the `.` >> form, whereas you should be going via the protocol itself (whatever >> namespace that may be in). >> >> Jim >> >> -- > -- > 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 > clojure+u...@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+u...@googlegroups.com . > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- You 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: Type hint using protocol
On Tue, Sep 8, 2015 at 9:31 PM, William la Forge wrote: > I'm finally looking at warn on reflection. Everything is going fine except > in the nodes.clj file where I define a protocol, INode, with a method, > new-node and then try to call that method from a function, revise. > > I'm using Clojure 1.7.0 and the file is > https://github.com/laforge49/aatree/blob/master/src/aatree/nodes.clj > The reflection warning occurs on line 51. > This is because you are using the "method" access. That is only available when the protocol is extended as interface. As example you can not use this way (a method access to the protocol) if you extend the type/class using `extend` or `extend-protocol`. For remove reflection, you should add the appropriate type hint with the `aatree.nodes.INode` interface (generated automatically when you are defining the protocol). If you have plans for using it always as interface (by method access), maybe you should use `definterface` instead. > > Depending on what I try, either I get a class not found compiler error for > file nodes.cli or a runtime error that new-node is NOT a member of the > record that implements INode. I've spent hours on this and have tried many > different things to no avail. > > My reason for using a method in a protocol is that I have several records > that implement it and I'm trying to not duplicate functions which take the > protocol as an argument. > > > Oh yes, because I'm also using genclass, I have no option but to use AOT. > > On Sunday, January 12, 2014 at 8:52:14 AM UTC-5, Jim foo.bar wrote: >> >> there you go: >> >> (defprotocol IBark >> (bark [this])) >> >> (in-ns 'other) >> (set! user/*warn-on-reflection* true) >> >> (clojure.core/defrecord Dog [] >> user/IBark >> (bark [_] (clojure.core/println "WOOF!"))) >> >> (def d (Dog.)) >> >> (user/bark d) ;;NO reflection >> >> (.bark d) ;;reflection >> >> it should be obvious now :) >> >> Jim >> >> >> On 12/01/14 13:38, Jim - FooBar(); wrote: >> >> It is not compiling because it cannot find the function...either fully >> qualify it like in my previous email or change your ns declaration to >> something like: >> >> [cqrs.storage :as stora] >> >> and then simply use stora/ret-value, stora/write, stora/write-batch >> >> Jim >> >> >> >> On 12/01/14 13:26, bob wrote: >> >> If I remove the dot, it cannot be compiled. can you give an example? >> >> On Sunday, January 12, 2014 9:22:00 PM UTC+8, Jim foo.bar wrote: >>> >>> I am suspecting you are calling the protocol implementations via the `.` >>> form, whereas you should be going via the protocol itself (whatever >>> namespace that may be in). >>> >>> Jim >>> >>> -- >> -- >> 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 >> clojure+u...@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+u...@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> >> -- > You 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. > -- Andrey Antukh - Андрей Антух - http://www.niwi.nz https://github.com/niwinz -- You 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: Type hint using protocol
I don't quite understand why you are not calling the Protocol method as a function, i.e. (new-node this t-2 lev l r c) (no leading dot on new-node). I also don't see anything which actually *implements* INode. Note that the meaning of "method" in "Protocol method" is not the same as in "Java method": i.e. these are not Java methods called via Java interop, although protocol implementations may create java methods on the class that implements them in some cases (i.e. inline implementations using deftype or defrecord) or a Java class may implement the protocol via the auto-generated interface of the same name. You are trying to call the "new_node" Java method directly on whatever "this" is in that context, which requires reflection on "this" to find the implementation. On Tuesday, September 8, 2015 at 1:31:10 PM UTC-5, William la Forge wrote: > > I'm finally looking at warn on reflection. Everything is going fine except > in the nodes.clj file where I define a protocol, INode, with a method, > new-node and then try to call that method from a function, revise. > > I'm using Clojure 1.7.0 and the file is > https://github.com/laforge49/aatree/blob/master/src/aatree/nodes.clj > The reflection warning occurs on line 51. > > Depending on what I try, either I get a class not found compiler error for > file nodes.cli or a runtime error that new-node is NOT a member of the > record that implements INode. I've spent hours on this and have tried many > different things to no avail. > > My reason for using a method in a protocol is that I have several records > that implement it and I'm trying to not duplicate functions which take the > protocol as an argument. > > Oh yes, because I'm also using genclass, I have no option but to use AOT. > > On Sunday, January 12, 2014 at 8:52:14 AM UTC-5, Jim foo.bar wrote: >> >> there you go: >> >> (defprotocol IBark >> (bark [this])) >> >> (in-ns 'other) >> (set! user/*warn-on-reflection* true) >> >> (clojure.core/defrecord Dog [] >> user/IBark >> (bark [_] (clojure.core/println "WOOF!"))) >> >> (def d (Dog.)) >> >> (user/bark d) ;;NO reflection >> >> (.bark d) ;;reflection >> >> it should be obvious now :) >> >> Jim >> >> >> On 12/01/14 13:38, Jim - FooBar(); wrote: >> >> It is not compiling because it cannot find the function...either fully >> qualify it like in my previous email or change your ns declaration to >> something like: >> >> [cqrs.storage :as stora] >> >> and then simply use stora/ret-value, stora/write, stora/write-batch >> >> Jim >> >> >> >> On 12/01/14 13:26, bob wrote: >> >> If I remove the dot, it cannot be compiled. can you give an example? >> >> On Sunday, January 12, 2014 9:22:00 PM UTC+8, Jim foo.bar wrote: >>> >>> I am suspecting you are calling the protocol implementations via the `.` >>> form, whereas you should be going via the protocol itself (whatever >>> namespace that may be in). >>> >>> Jim >>> >>> -- >> -- >> 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 >> clojure+u...@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+u...@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> >> -- You 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: Type hint using protocol
aatree.nodes.INode always gives me a class not found. But switching to definterface does it for me. Many thanks! On Tuesday, September 8, 2015 at 3:16:56 PM UTC-4, Andrey Antukh wrote: > > > > On Tue, Sep 8, 2015 at 9:31 PM, William la Forge > wrote: > >> I'm finally looking at warn on reflection. Everything is going fine >> except in the nodes.clj file where I define a protocol, INode, with a >> method, new-node and then try to call that method from a function, revise. >> >> I'm using Clojure 1.7.0 and the file is >> https://github.com/laforge49/aatree/blob/master/src/aatree/nodes.clj >> The reflection warning occurs on line 51. >> > > This is because you are using the "method" access. That is only available > when the protocol is extended as interface. As example you can not use this > way (a method access to the protocol) if you extend the type/class using > `extend` or `extend-protocol`. > > For remove reflection, you should add the appropriate type hint with the > `aatree.nodes.INode` interface (generated automatically when you are > defining the protocol). > > If you have plans for using it always as interface (by method access), > maybe you should use `definterface` instead. > > >> >> Depending on what I try, either I get a class not found compiler error >> for file nodes.cli or a runtime error that new-node is NOT a member of the >> record that implements INode. I've spent hours on this and have tried many >> different things to no avail. >> >> My reason for using a method in a protocol is that I have several records >> that implement it and I'm trying to not duplicate functions which take the >> protocol as an argument. >> > > > >> >> Oh yes, because I'm also using genclass, I have no option but to use AOT. >> >> On Sunday, January 12, 2014 at 8:52:14 AM UTC-5, Jim foo.bar wrote: >>> >>> there you go: >>> >>> (defprotocol IBark >>> (bark [this])) >>> >>> (in-ns 'other) >>> (set! user/*warn-on-reflection* true) >>> >>> (clojure.core/defrecord Dog [] >>> user/IBark >>> (bark [_] (clojure.core/println "WOOF!"))) >>> >>> (def d (Dog.)) >>> >>> (user/bark d) ;;NO reflection >>> >>> (.bark d) ;;reflection >>> >>> it should be obvious now :) >>> >>> Jim >>> >>> >>> On 12/01/14 13:38, Jim - FooBar(); wrote: >>> >>> It is not compiling because it cannot find the function...either fully >>> qualify it like in my previous email or change your ns declaration to >>> something like: >>> >>> [cqrs.storage :as stora] >>> >>> and then simply use stora/ret-value, stora/write, stora/write-batch >>> >>> Jim >>> >>> >>> >>> On 12/01/14 13:26, bob wrote: >>> >>> If I remove the dot, it cannot be compiled. can you give an example? >>> >>> On Sunday, January 12, 2014 9:22:00 PM UTC+8, Jim foo.bar wrote: I am suspecting you are calling the protocol implementations via the `.` form, whereas you should be going via the protocol itself (whatever namespace that may be in). Jim -- >>> -- >>> 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 >>> clojure+u...@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+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >>> -- >> 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 >> clojure+u...@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+u...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Andrey Antukh - Андрей Антух - > > http://www.niwi.nz > https://github.com/niwinz > -- You 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?
Re: Type hint using protocol
Frances, I have two implementations of INode, record MapNode and record VectorNode, which are defined in other files. Also, I get a syntax method when calling new-node without the leading dot when using defprotocol: java.lang.IllegalArgumentException: No single method: newNode of interface: aatree.nodes.INode found for function: newNode of protocol: INode, compiling:(aatree/nodes.clj:51:7) On Tuesday, September 8, 2015 at 3:29:38 PM UTC-4, Francis Avila wrote: > > I don't quite understand why you are not calling the Protocol method as a > function, i.e. > > (new-node this t-2 lev l r c) > > (no leading dot on new-node). > > I also don't see anything which actually *implements* INode. > > Note that the meaning of "method" in "Protocol method" is not the same as > in "Java method": i.e. these are not Java methods called via Java interop, > although protocol implementations may create java methods on the class that > implements them in some cases (i.e. inline implementations using deftype or > defrecord) or a Java class may implement the protocol via the > auto-generated interface of the same name. You are trying to call the > "new_node" Java method directly on whatever "this" is in that context, > which requires reflection on "this" to find the implementation. > > > On Tuesday, September 8, 2015 at 1:31:10 PM UTC-5, William la Forge wrote: >> >> I'm finally looking at warn on reflection. Everything is going fine >> except in the nodes.clj file where I define a protocol, INode, with a >> method, new-node and then try to call that method from a function, revise. >> >> I'm using Clojure 1.7.0 and the file is >> https://github.com/laforge49/aatree/blob/master/src/aatree/nodes.clj >> The reflection warning occurs on line 51. >> >> Depending on what I try, either I get a class not found compiler error >> for file nodes.cli or a runtime error that new-node is NOT a member of the >> record that implements INode. I've spent hours on this and have tried many >> different things to no avail. >> >> My reason for using a method in a protocol is that I have several records >> that implement it and I'm trying to not duplicate functions which take the >> protocol as an argument. >> >> Oh yes, because I'm also using genclass, I have no option but to use AOT. >> >> On Sunday, January 12, 2014 at 8:52:14 AM UTC-5, Jim foo.bar wrote: >>> >>> there you go: >>> >>> (defprotocol IBark >>> (bark [this])) >>> >>> (in-ns 'other) >>> (set! user/*warn-on-reflection* true) >>> >>> (clojure.core/defrecord Dog [] >>> user/IBark >>> (bark [_] (clojure.core/println "WOOF!"))) >>> >>> (def d (Dog.)) >>> >>> (user/bark d) ;;NO reflection >>> >>> (.bark d) ;;reflection >>> >>> it should be obvious now :) >>> >>> Jim >>> >>> >>> On 12/01/14 13:38, Jim - FooBar(); wrote: >>> >>> It is not compiling because it cannot find the function...either fully >>> qualify it like in my previous email or change your ns declaration to >>> something like: >>> >>> [cqrs.storage :as stora] >>> >>> and then simply use stora/ret-value, stora/write, stora/write-batch >>> >>> Jim >>> >>> >>> >>> On 12/01/14 13:26, bob wrote: >>> >>> If I remove the dot, it cannot be compiled. can you give an example? >>> >>> On Sunday, January 12, 2014 9:22:00 PM UTC+8, Jim foo.bar wrote: I am suspecting you are calling the protocol implementations via the `.` form, whereas you should be going via the protocol itself (whatever namespace that may be in). Jim -- >>> -- >>> 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 >>> clojure+u...@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+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >>> -- You 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.
[ANN] paren-soup 0.1.1, a browser-based editor for CLJS
This is a ClojureScript viewer and editor you can embed in any website. I hope to make it better than CodeMirror for those who don't need polyglot support. I announced it last week but it was pretty much unusable because it didn't have paren completion. Now it is slightly more usable. Here are the features: - Syntax highlighting - Rainbow delimiters - Automatic indentation - InstaREPL (à la Light Table) Code: https://github.com/oakes/paren-soup Demo: http://oakes.github.io/paren-soup I use the new ClojureScript eval capability for the instarepl, and the new CLJS version of tools.reader to provide highlighting and indentation. The downside to using tools.reader is that reader errors break both of those things, which is why paren completion was strictly necessary! It is still pretty flawed, but hopefully I'll be able to make this production-ready eventually. -- You 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: [ANN] paren-soup 0.1.1, a browser-based editor for CLJS
For me, the instarepl column seems to be unreadable because all the results have horizontal scrollbars that entirely obscure the results. On Tue, Sep 8, 2015 at 4:38 PM, Zach Oakes wrote: > This is a ClojureScript viewer and editor you can embed in any website. I > hope to make it better than CodeMirror for those who don't need polyglot > support. I announced it last week but it was pretty much unusable because > it didn't have paren completion. Now it is slightly more usable. Here are > the features: > >- Syntax highlighting >- Rainbow delimiters >- Automatic indentation >- InstaREPL (à la Light Table) > > Code: https://github.com/oakes/paren-soup > Demo: http://oakes.github.io/paren-soup > > I use the new ClojureScript eval capability for the instarepl, and the new > CLJS version of tools.reader to provide highlighting and indentation. The > downside to using tools.reader is that reader errors break both of those > things, which is why paren completion was strictly necessary! It is still > pretty flawed, but hopefully I'll be able to make this production-ready > eventually. > > -- > You 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.
Using type hints to optimize protocol invocation
My understanding is that invocation of protocol methods incurs about 30% overhead due to the need to look up the appropriate function for the type. I also learned recently that Clojure does not use static type information to do the lookup at compile-time and avoid the overhead. Given that Clojure already does do some type analysis (to optimize Java method invocations), why not do it for protocol invocation as well? Just trying to further my understanding of the Clojure compiler. -- You 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: [ANN] paren-soup 0.1.1, a browser-based editor for CLJS
Yeah I should've tested on a non-Mac. That should just be a CSS change if there is a way to make scrollbars disappear. I'll look into it soon. -- You 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.
[ANN] mixfix syntax for clojure
This library allows using mixfix operators with easy definitions in clojure, so it is possible to write code like this: (defn myfun [x y] (if x < 2 then x + y - 1 else (x + y) * 2)) Or for some EDSL (in this example SQL-like): (exec (select * from table1, table2 where col1 < col2 group by col1, col2)) No extra build steps, leiningen plugins is required, only macros. Check github home for details - https://github.com/awto/mixfix-clj Regards, Vitaliy -- You 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.
[ANN] mixfix syntax for clojure
This library allows using mixfix operators with easy definitions in clojure, so it is possible to write code like this: (defn myfun [x y] (if x < 2 then x + y - 1 else (x + y) * 2)) Or for some EDSL (in this example SQL-like) (exec (select * from table1, table2 where col1 < col2 group by col1, col2)) No extra build steps, leiningen plugins is required, only macros. Check github home for details - https://github.com/awto/mixfix-clj Regards, Vitaliy -- You 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: [ANN] mixfix syntax for clojure
The Readme is excellent and illuminates some of the depth behind the brief example that opened this thread. If it is possible for depth to be behind. In this case I believe it is. -- You 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.
[ANN] Mongologic 0.5.1 – A toolkit to develop MongoDB apps
Mongologic provides several tools to make the development of MongoDB-backed applications easier and faster: - Callbacks in the lifecycle of records (à la Rails' Active Record) - Uniqueness validation - Range-based pagination - History https://github.com/xavi/mongologic I hope you find it useful! Xavi -- You 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: Using type hints to optimize protocol invocation
I'm not an expert on this subject, but two thoughts come to mind: 1. the point of protocols is polymorphism, and if I understand you correctly, the case you're describing is narrowed enough that it is *not* polymorphic -- i.e., if the compiler can statically determine what code to run, it's not polymorphic anymore, and you as the programmer could have just called that code directly (though perhaps for some reason you might not want to write it that way) 2. the previous point notwithstanding, I don't think static type information is enough to pick an implementation, because you could still conceivably encounter (at runtime) subclasses of the annotated type with their own implementations, and have to check for that On Tuesday, September 8, 2015 at 3:59:41 PM UTC-5, Nathan Marz wrote: > > My understanding is that invocation of protocol methods incurs about 30% > overhead due to the need to look up the appropriate function for the type. > I also learned recently that Clojure does not use static type information > to do the lookup at compile-time and avoid the overhead. Given that Clojure > already does do some type analysis (to optimize Java method invocations), > why not do it for protocol invocation as well? Just trying to further my > understanding of the Clojure compiler. > > > -- You 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: Using type hints to optimize protocol invocation
>> My understanding is that invocation of protocol methods incurs about 30% overhead due to the need to look up the appropriate function for the type. I'd like to see some benchmarks on that. Protocols are actually quite fast, and if you create the protocol first, then implement a type using that protocol it should be as fast as any virtual method invocation in Java. So I would first ask for proof of your first assertion. Timothy On Tue, Sep 8, 2015 at 6:11 PM, Gary Fredericks wrote: > I'm not an expert on this subject, but two thoughts come to mind: > > >1. the point of protocols is polymorphism, and if I understand you >correctly, the case you're describing is narrowed enough that it is >*not* polymorphic -- i.e., if the compiler can statically determine >what code to run, it's not polymorphic anymore, and you as the programmer >could have just called that code directly (though perhaps for some reason >you might not want to write it that way) >2. the previous point notwithstanding, I don't think static type >information is enough to pick an implementation, because you could still >conceivably encounter (at runtime) subclasses of the annotated type with >their own implementations, and have to check for that > > > On Tuesday, September 8, 2015 at 3:59:41 PM UTC-5, Nathan Marz wrote: >> >> My understanding is that invocation of protocol methods incurs about 30% >> overhead due to the need to look up the appropriate function for the type. >> I also learned recently that Clojure does not use static type information >> to do the lookup at compile-time and avoid the overhead. Given that Clojure >> already does do some type analysis (to optimize Java method invocations), >> why not do it for protocol invocation as well? Just trying to further my >> understanding of the Clojure compiler. >> >> >> -- > You 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. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- You 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: [ANN] paren-soup 0.1.1, a browser-based editor for CLJS
I'm bad at CSS, but it looks like there isn't a standard way to hide scrollbars in browsers without removing the ability to scroll. Are you using Windows? Maybe I can boot up a VM and try things out to fix this issue. On Tuesday, September 8, 2015 at 5:05:32 PM UTC-4, Zach Oakes wrote: > > Yeah I should've tested on a non-Mac. That should just be a CSS change if > there is a way to make scrollbars disappear. I'll look into it soon. -- You 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: [ANN] paren-soup 0.1.1, a browser-based editor for CLJS
I should have given you that information up front, sorry.
I just tried it in Windows 10 using both Edge and Chrome and both have
scrollbars. Earlier I was using Chrome in Windows 7.
I was able to fix it in the inspector using "overflow: hidden":
.paren-soup .instarepl .result {
position: relative;
overflow: hidden;
background-color: lightgreen;
outline: 1px solid;
}
On Tue, Sep 8, 2015 at 8:46 PM, Zach Oakes wrote:
> I'm bad at CSS, but it looks like there isn't a standard way to hide
> scrollbars in browsers without removing the ability to scroll. Are you
> using Windows? Maybe I can boot up a VM and try things out to fix this
> issue.
>
>
> On Tuesday, September 8, 2015 at 5:05:32 PM UTC-4, Zach Oakes wrote:
>>
>> Yeah I should've tested on a non-Mac. That should just be a CSS change if
>> there is a way to make scrollbars disappear. I'll look into it soon.
>
> --
> You 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: [ANN] paren-soup 0.1.1, a browser-based editor for CLJS
Thanks, I just made the change in both the release zip and the demo. I was
aware of "overflow: hidden", but it prevents you from scrolling with your
mouse/trackpad either, so results that can't fit will just be cut off.
However, I think supporting browsers and OSes that have visible scrollers
is more important so the change is now live.
On Tuesday, September 8, 2015 at 9:08:24 PM UTC-4, Aaron Cohen wrote:
>
> I should have given you that information up front, sorry.
>
> I just tried it in Windows 10 using both Edge and Chrome and both have
> scrollbars. Earlier I was using Chrome in Windows 7.
>
> I was able to fix it in the inspector using "overflow: hidden":
>
> .paren-soup .instarepl .result {
> position: relative;
> overflow: hidden;
> background-color: lightgreen;
> outline: 1px solid;
> }
>
>
> On Tue, Sep 8, 2015 at 8:46 PM, Zach Oakes
> > wrote:
>
>> I'm bad at CSS, but it looks like there isn't a standard way to hide
>> scrollbars in browsers without removing the ability to scroll. Are you
>> using Windows? Maybe I can boot up a VM and try things out to fix this
>> issue.
>>
>>
>> On Tuesday, September 8, 2015 at 5:05:32 PM UTC-4, Zach Oakes wrote:
>>>
>>> Yeah I should've tested on a non-Mac. That should just be a CSS change
>>> if there is a way to make scrollbars disappear. I'll look into it soon.
>>
>> --
>> 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
>> clojure+u...@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+u...@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: Using type hints to optimize protocol invocation
Protocol callsites are already optimized in clojure. Here's the emitted bytecode for a protocol invocation: 0: aload_0 1: aconst_null 2: astore_0 3: dup 4: invokestatic #36 // Method clojure/lang/Util.classOf:(Ljava/lang/Object;)Ljava/lang/Class; 7: getstatic #38 // Field __cached_class__0:Ljava/lang/Class; 10: if_acmpeq 27 13: dup 14: instanceof#40 // class test/p 17: ifne 42 20: dup 21: invokestatic #36 // Method clojure/lang/Util.classOf:(Ljava/lang/Object;)Ljava/lang/Class; 24: putstatic #38 // Field __cached_class__0:Ljava/lang/Class; 27: getstatic #23 // Field const__0:Lclojure/lang/Var; 30: invokevirtual #44 // Method clojure/lang/Var.getRawRoot:()Ljava/lang/Object; 33: swap 34: invokeinterface #49, 2 // InterfaceMethod clojure/lang/IFn.invoke:(Ljava/lang/Object;)Ljava/lang/Object; 39: goto 47 42: invokeinterface #51, 1 // InterfaceMethod test/p.f:()Ljava/lang/Object; 47: areturn Ignoring the class cache, as you can see there's an instanceof check at offset 14 which results in a direct interface method invocation (at offset 42) if the type of the target implements directly the interface which backs the protocol, which is always the case when a deftype implements a protocol inline rather than via extend. Nathan Marz writes: > My understanding is that invocation of protocol methods incurs about 30% > overhead due to the need to look up the appropriate function for the type. > I also learned recently that Clojure does not use static type information > to do the lookup at compile-time and avoid the overhead. Given that Clojure > already does do some type analysis (to optimize Java method invocations), > why not do it for protocol invocation as well? Just trying to further my > understanding of the Clojure compiler. -- -- You 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.
