Re: I've found a constellation of related bugs in primitive function support when type-hinting *return types*.

[Sean Corfield]

I can’t reproduce any of this on Clojure 1.9.0 Alpha 10 – it all works exactly 
as expected.

 

On 8/9/16, 2:50 PM, "Fluid Dynamics"  wrote:

 

=> (defn foo [x] (doto (double-array 1) (aset 0 x)))
=> [(foo 3.0) (type (foo 3.0))]
[[3.0] [D] ; As expected, a double array with the value passed in.
; Maybe a good idea to hint this function as always returning a double array.
=> (defn foo ^doubles [x] (doto (double-array 1) (aset 0 x)))
Reflection warning, NO_SOURCE_PATH:1:24 - call to aset can't be resolved.
=> [(foo 3.0) (type (foo 3.0))]
[[3.0] [D]
; Hmm, that reflection is not going to help performance any. (Why wasn't it 
occurring before?) Maybe hint x as well?
=> (defn foo ^doubles [^double x] (doto (double-array 1) (aset 0 x)))
=> [(foo 3.0) (type (foo 3.0))]
AbstractMethodError Method user$foo.invokePrim(D)Ljava/lang/Object; is abstract
; What the f---?!
=> (defn foo [^double x] (doto (double-array 1) (aset 0 x)))
=> [(foo 3.0) (type (foo 3.0))]
[[3.0] [D]
; OK, now at least we have a primitive function taking a double, and not 
generating a reflection warning, though it's expected to return generic 
objects. Why don't we wrap it with a *second* function that knows it's really 
returning a double array, and hope the JIT inlines it so we won't get doubled 
function call overhead?
=> (defn bar [^double x] (foo x))
=> (bar 3.0)
[3.0]
; So far, so good. Now add the return type hint to bar:
=> (defn bar ^doubles [^double x] (foo x))
=> (bar 3.0)
AbstractMethodError Method user$bar.invokePrim(D)Ljava/lang/Object; is abstract
; WHAT?!?!?!?!?!
; IMPOSSIBLE
; How can changing bar's return type hint introduce the bug back into foo when 
foo was working earlier and we didn't recompile foo?!?!?!?!?!
; WTF WTF WTF!!!
;
; OK so what if we hint foo as a primitive function that takes a double and 
returns an object?
=> (defn bar ^doubles [^clojure.lang.IFn$DO f ^double x] (f x))
=> (bar foo 3.0)
AbstractMethodError Method 
user$bar.invokePrim(Ljava/lang/Object;D)Ljava/lang/Object; is abstract
; Even more impossible! (foo 3.0) continues to work, so the function is intact 
in memory, but passing it to bar magically breaks it?!
; OK, what if we explicitly invoke foo's correct method, which takes a double 
and returns an object?
=> (defn bar ^doubles [^clojure.lang.IFn$DO f ^double x] (.invokePrim f x))
=> (bar foo 3.0)
AbstractMethodError Method 
user$bar.invokePrim(Ljava/lang/Object;D)Ljava/lang/Object; is abstract
; Still not working!
; OK, let's hide it *another level deep*
=> (defn bar [^clojure.lang.IFn$DO f]
=>   (fn ^doubles [^double x]
=> (f x)))
=> ((bar foo) 3.0)
NoSuchMethodError clojure.lang.IFn$DO.invokePrim(D)[D user$bar$fn__9962.invoke 
(NO_SOURCE_PATH:-1)
; ?!?!?!?!?!?!??!?!?!?!?!
; Time to give up and file a bug report.

 

-- 
You 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: Multi-OS Engine | Intel(R) Software

[Colin Fleming]

Looks like MOSE uses Android's ART (from
https://software.intel.com/en-us/node/633226):

Multi-OS Engine Runtime is based on the modern Android ART*, which is the
> runtime component of Android that runs Java apps.
> ART has a list of features that provide optimal performance for apps on
> iOS devices:
>
>- Ahead-of-time (AOT) compilation, which can improve app performance.
>
>
>- Use of the same Java runtime libraries as Android, which simplify
>cross-platform app development.
>
>
>- Enhanced memory management and garbage collection.
>
> A compiled Multi-OS Engine app contains the following components:
>
>- Compiled Java sources.
>
>
>- Resources.
>
>
>- Standard (iOS) library bindings.
>
>
>- Third party native libraries and bindings.
>
>
>- Nat/J native library for the Java to native binding that enables the
>implementation of native classes and functions in pure Java and makes them
>available to the native side.
>
>
>- The specialized ART virtual machine (VM) with Multi-OS Engine ART
>enhancements.
>
> I'm not sure what the state of compiling Clojure to ART is, I guess you
could AOT and then convert the bytecode to Dalvik. It would be an
interesting experiment, for sure.

On 10 August 2016 at 08:25, Daniel Compton 
wrote:

> Following up, it seems like it may be possible to use Clojure with MOSE,
> but it doesn’t look like a well worn path. Also, I suspect if you went down
> this route you may end up writing mostly Java in a funny domain specific
> language with lots of parentheses. All that being said, I’d be happy to be
> proven wrong :)
>
> https://groups.google.com/forum/#!topic/robovm/b3jbTcpq1Xo
> https://software.intel.com/en-us/forums/multi-os-engine/topic/640308
> https://github.com/moe-java-samples/moe-kotlin-samples
>
>
> On Wed, Aug 10, 2016 at 8:09 AM Daniel Compton <
> daniel.compton.li...@gmail.com> wrote:
>
>> I had a look at this a few weeks ago, and it seemed like it would only
>> work with Java code, not JVM bytecode?
>>
>> Internal Overview:
>>
>> Multi-OS Engine facilitates Java* support on iOS* through
>>
>>- Auto Java binding generation from ObjectiveC and C header files
>>from existing libraries or 3rd party packages
>>- Java* annotations and NatJ* runtime library
>>- Eliminating the need to write JNI functions
>>- Prebuilt jar files interfacing iOS* API are provided in the
>>Multi-OS Engine, so you can start coding iOS* app in Java* immediately.
>>
>> I looked around and couldn’t find any lower level details of what they
>> were doing, but all of the documentation seems to suggest you need to write
>> Java. I’d be very happy to be proven wrong though :)
>>
>> On Sat, Aug 6, 2016 at 7:47 AM Gregg Reynolds  wrote:
>>
>>> For those interested in mobile clojure, I just discovered this.  Haven't
>>> tried it but it sounds good:
>>>
>>> https://software.intel.com/en-us/multi-os-engine?utm_source=
>>> Develop+Blog+http://www.develop-online.net/_
>>> medium=Text+Link_campaign=Android_EMEA_Q2-16_Developer-
>>> Blog_Blog-Page?29062016
>>>
>>> --
>>> You 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.
>>>
>> --
>> —
>> Daniel
>>
> --
> —
> Daniel
>
> --
> You 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 

Re: I've found a constellation of related bugs in primitive function support when type-hinting *return types*.

[Alex Miller]

What Clojure version are you using?

On Tuesday, August 9, 2016 at 5:01:21 PM UTC-5, Fluid Dynamics wrote:
>
> => (defn foo [x] (doto (double-array 1) (aset 0 x)))
> => [(foo 3.0) (type (foo 3.0))]
> [[3.0] [D] ; As expected, a double array with the value passed in.
> ; Maybe a good idea to hint this function as always returning a double 
> array.
> => (defn foo ^doubles [x] (doto (double-array 1) (aset 0 x)))
> Reflection warning, NO_SOURCE_PATH:1:24 - call to aset can't be resolved.
>

I don't see that. I'm guessing you did (set! *warn-on-reflection* true) 
prior to the start of this? With reflection warnings on, I see:

Reflection warning, NO_SOURCE_PATH:5:24 - call to static method aset on 
clojure.lang.RT can't be resolved (argument types: [D, int, unknown).

(Note that this message has improved so I am guessing you're using an older 
version). The reflection part here is the "unknown" bit - basically the 
type of x.
 

> => [(foo 3.0) (type (foo 3.0))]
> [[3.0] [D]
> ; Hmm, that reflection is not going to help performance any. (Why wasn't 
> it occurring before?) Maybe hint x as well?
> => (defn foo ^doubles [^double x] (doto (double-array 1) (aset 0 x)))
> => [(foo 3.0) (type (foo 3.0))]
> AbstractMethodError Method user$foo.invokePrim(D)Ljava/lang/Object; is 
> abstract
> ; What the f---?!
>

I don't see this on Clojure 1.8.
 

> => (defn foo [^double x] (doto (double-array 1) (aset 0 x)))
> => [(foo 3.0) (type (foo 3.0))]
> [[3.0] [D]
> ; OK, now at least we have a primitive function taking a double, and not 
> generating a reflection warning, though it's expected to return generic 
> objects. Why don't we wrap it with a *second* function that knows it's 
> really returning a double array, and hope the JIT inlines it so we won't 
> get doubled function call overhead?
> => (defn bar [^double x] (foo x))
> => (bar 3.0)
> [3.0]
>

I see the return of a double array here (prob changes in printing since 
whatever version you're on):

#object["[D" 0x49c2faae "[D@49c2faae"]
 

> ; So far, so good. Now add the return type hint to bar:
> => (defn bar ^doubles [^double x] (foo x))
> => (bar 3.0)
> AbstractMethodError Method user$bar.invokePrim(D)Ljava/lang/Object; is 
> abstract
>

I don't see this in current Clojure. I just see the returned double array 
as before.
 

> ; WHAT?!?!?!?!?!
> ; IMPOSSIBLE
> ; How can changing bar's return type hint introduce the bug back into foo 
> when foo was working earlier and we didn't recompile foo?!?!?!?!?!
> ; WTF WTF WTF!!!
> ;
> ; OK so what if we hint foo as a primitive function that takes a double 
> and returns an object?
> => (defn bar ^doubles [^clojure.lang.IFn$DO f ^double x] (f x))
> => (bar foo 3.0)
> AbstractMethodError Method 
> user$bar.invokePrim(Ljava/lang/Object;D)Ljava/lang/Object; is abstract
>

You shouldn't do this, but it also does not fail for me on 1.8.
 

> ; Even more impossible! (foo 3.0) continues to work, so the function is 
> intact in memory, but passing it to bar magically breaks it?!
> ; OK, what if we explicitly invoke foo's correct method, which takes a 
> double and returns an object?
> => (defn bar ^doubles [^clojure.lang.IFn$DO f ^double x] (.invokePrim f x))
> => (bar foo 3.0)
> AbstractMethodError Method 
> user$bar.invokePrim(Ljava/lang/Object;D)Ljava/lang/Object; is abstract
>

Still works on 1.8.
 

> ; Still not working!
> ; OK, let's hide it *another level deep*
> => (defn bar [^clojure.lang.IFn$DO f]
> =>   (fn ^doubles [^double x]
> => (f x)))
> => ((bar foo) 3.0)
> NoSuchMethodError clojure.lang.IFn$DO.invokePrim(D)[D 
> user$bar$fn__9962.invoke (NO_SOURCE_PATH:-1)
>

Still doesn't fail.
 

> ; ?!?!?!?!?!?!??!?!?!?!?!
> ; Time to give up and file a bug report.
>

Please try Clojure 1.8. 

-- 
You 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: I've found a constellation of related bugs in primitive function support when type-hinting *return types*.

[Timothy Baldridge]

It's impossible to read what you've written here. Can you give us a minimum
failing use case? Thanks.

Timothy

On Tue, Aug 9, 2016 at 3:50 PM, Fluid Dynamics  wrote:

> => (defn foo [x] (doto (double-array 1) (aset 0 x)))
> => [(foo 3.0) (type (foo 3.0))]
> [[3.0] [D] ; As expected, a double array with the value passed in.
> ; Maybe a good idea to hint this function as always returning a double
> array.
> => (defn foo ^doubles [x] (doto (double-array 1) (aset 0 x)))
> Reflection warning, NO_SOURCE_PATH:1:24 - call to aset can't be resolved.
> => [(foo 3.0) (type (foo 3.0))]
> [[3.0] [D]
> ; Hmm, that reflection is not going to help performance any. (Why wasn't
> it occurring before?) Maybe hint x as well?
> => (defn foo ^doubles [^double x] (doto (double-array 1) (aset 0 x)))
> => [(foo 3.0) (type (foo 3.0))]
> AbstractMethodError Method user$foo.invokePrim(D)Ljava/lang/Object; is
> abstract
> ; What the f---?!
> => (defn foo [^double x] (doto (double-array 1) (aset 0 x)))
> => [(foo 3.0) (type (foo 3.0))]
> [[3.0] [D]
> ; OK, now at least we have a primitive function taking a double, and not
> generating a reflection warning, though it's expected to return generic
> objects. Why don't we wrap it with a *second* function that knows it's
> really returning a double array, and hope the JIT inlines it so we won't
> get doubled function call overhead?
> => (defn bar [^double x] (foo x))
> => (bar 3.0)
> [3.0]
> ; So far, so good. Now add the return type hint to bar:
> => (defn bar ^doubles [^double x] (foo x))
> => (bar 3.0)
> AbstractMethodError Method user$bar.invokePrim(D)Ljava/lang/Object; is
> abstract
> ; WHAT?!?!?!?!?!
> ; IMPOSSIBLE
> ; How can changing bar's return type hint introduce the bug back into foo
> when foo was working earlier and we didn't recompile foo?!?!?!?!?!
> ; WTF WTF WTF!!!
> ;
> ; OK so what if we hint foo as a primitive function that takes a double
> and returns an object?
> => (defn bar ^doubles [^clojure.lang.IFn$DO f ^double x] (f x))
> => (bar foo 3.0)
> AbstractMethodError Method user$bar.invokePrim(Ljava/
> lang/Object;D)Ljava/lang/Object; is abstract
> ; Even more impossible! (foo 3.0) continues to work, so the function is
> intact in memory, but passing it to bar magically breaks it?!
> ; OK, what if we explicitly invoke foo's correct method, which takes a
> double and returns an object?
> => (defn bar ^doubles [^clojure.lang.IFn$DO f ^double x] (.invokePrim f x))
> => (bar foo 3.0)
> AbstractMethodError Method user$bar.invokePrim(Ljava/
> lang/Object;D)Ljava/lang/Object; is abstract
> ; Still not working!
> ; OK, let's hide it *another level deep*
> => (defn bar [^clojure.lang.IFn$DO f]
> =>   (fn ^doubles [^double x]
> => (f x)))
> => ((bar foo) 3.0)
> NoSuchMethodError clojure.lang.IFn$DO.invokePrim(D)[D
> user$bar$fn__9962.invoke (NO_SOURCE_PATH:-1)
> ; ?!?!?!?!?!?!??!?!?!?!?!
> ; Time to give up and file a bug report.
>
> --
> You 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.

I've found a constellation of related bugs in primitive function support when type-hinting *return types*.

[Fluid Dynamics]

=> (defn foo [x] (doto (double-array 1) (aset 0 x)))
=> [(foo 3.0) (type (foo 3.0))]
[[3.0] [D] ; As expected, a double array with the value passed in.
; Maybe a good idea to hint this function as always returning a double 
array.
=> (defn foo ^doubles [x] (doto (double-array 1) (aset 0 x)))
Reflection warning, NO_SOURCE_PATH:1:24 - call to aset can't be resolved.
=> [(foo 3.0) (type (foo 3.0))]
[[3.0] [D]
; Hmm, that reflection is not going to help performance any. (Why wasn't it 
occurring before?) Maybe hint x as well?
=> (defn foo ^doubles [^double x] (doto (double-array 1) (aset 0 x)))
=> [(foo 3.0) (type (foo 3.0))]
AbstractMethodError Method user$foo.invokePrim(D)Ljava/lang/Object; is 
abstract
; What the f---?!
=> (defn foo [^double x] (doto (double-array 1) (aset 0 x)))
=> [(foo 3.0) (type (foo 3.0))]
[[3.0] [D]
; OK, now at least we have a primitive function taking a double, and not 
generating a reflection warning, though it's expected to return generic 
objects. Why don't we wrap it with a *second* function that knows it's 
really returning a double array, and hope the JIT inlines it so we won't 
get doubled function call overhead?
=> (defn bar [^double x] (foo x))
=> (bar 3.0)
[3.0]
; So far, so good. Now add the return type hint to bar:
=> (defn bar ^doubles [^double x] (foo x))
=> (bar 3.0)
AbstractMethodError Method user$bar.invokePrim(D)Ljava/lang/Object; is 
abstract
; WHAT?!?!?!?!?!
; IMPOSSIBLE
; How can changing bar's return type hint introduce the bug back into foo 
when foo was working earlier and we didn't recompile foo?!?!?!?!?!
; WTF WTF WTF!!!
;
; OK so what if we hint foo as a primitive function that takes a double and 
returns an object?
=> (defn bar ^doubles [^clojure.lang.IFn$DO f ^double x] (f x))
=> (bar foo 3.0)
AbstractMethodError Method 
user$bar.invokePrim(Ljava/lang/Object;D)Ljava/lang/Object; is abstract
; Even more impossible! (foo 3.0) continues to work, so the function is 
intact in memory, but passing it to bar magically breaks it?!
; OK, what if we explicitly invoke foo's correct method, which takes a 
double and returns an object?
=> (defn bar ^doubles [^clojure.lang.IFn$DO f ^double x] (.invokePrim f x))
=> (bar foo 3.0)
AbstractMethodError Method 
user$bar.invokePrim(Ljava/lang/Object;D)Ljava/lang/Object; is abstract
; Still not working!
; OK, let's hide it *another level deep*
=> (defn bar [^clojure.lang.IFn$DO f]
=>   (fn ^doubles [^double x]
=> (f x)))
=> ((bar foo) 3.0)
NoSuchMethodError clojure.lang.IFn$DO.invokePrim(D)[D 
user$bar$fn__9962.invoke (NO_SOURCE_PATH:-1)
; ?!?!?!?!?!?!??!?!?!?!?!
; Time to give up and file a bug report.

-- 
You 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: Meta-data should be added to deprecated functions?

[Dan Burton]

>
> The second is adding functionality to Clojure core to give you more
> feedback about deprecated functions and that's something I've been trying
> to push through to completion for Clojure 1.9. See:
> http://dev.clojure.org/jira/browse/CLJ-706


Excited to see this being pushed for Clojure 1.9! Nice work.

-- Dan Burton

On Tue, Aug 9, 2016 at 1:49 PM, Alex Miller  wrote:

> There are really two aspects to this - one is actually including the
> metadata in core.async, which can definitely be done.
>
> The second is adding functionality to Clojure core to give you more
> feedback about deprecated functions and that's something I've been trying
> to push through to completion for Clojure 1.9. See:
> http://dev.clojure.org/jira/browse/CLJ-706
>
>
> On Tuesday, August 9, 2016 at 3:05:24 PM UTC-5, Ertuğrul Çetin wrote:
>>
>> I found the *map>* function from *core.async* and it was deprecated(doc
>> says), but there is no meta-data.
>>
>> If we have meta-data for *deprecated* functions our tools(IDEs) would
>> work better, like scratch out the function(Most IDEs do that).
>>
>> Ex:
>>
>> This
>>
>> (defn map>
>>   "."
>>
>>   {:added "1.0"
>>
>>:deprecated true}
>>
>> [f ch]
>> //...)
>>
>>
>> instead of this
>>
>>
>> (defn map>
>>   "Deprecated - this function will be removed. Use transducer instead"
>>   [f ch]
>>   //...)
>>
>>
>>
>> --
> You 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: Multi-OS Engine | Intel(R) Software

[Raoul Duke]

Whatever happened to Defrac, anyway?

-- 
You 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: Meta-data should be added to deprecated functions?

[Alex Miller]

I've added the :deprecated metadata to core.async 
in 
https://github.com/clojure/core.async/commit/103359a11598b556ac21053977e7deda43cea535

On Tuesday, August 9, 2016 at 3:55:04 PM UTC-5, Ertuğrul Çetin wrote:
>
> That will be very useful. Can't wait :)
>
> On Tuesday, August 9, 2016 at 11:49:36 PM UTC+3, Alex Miller wrote:
>>
>> There are really two aspects to this - one is actually including the 
>> metadata in core.async, which can definitely be done. 
>>
>> The second is adding functionality to Clojure core to give you more 
>> feedback about deprecated functions and that's something I've been trying 
>> to push through to completion for Clojure 1.9. See: 
>> http://dev.clojure.org/jira/browse/CLJ-706
>>
>> On Tuesday, August 9, 2016 at 3:05:24 PM UTC-5, Ertuğrul Çetin wrote:
>>>
>>> I found the *map>* function from *core.async* and it was deprecated(doc 
>>> says), but there is no meta-data.
>>>
>>> If we have meta-data for *deprecated* functions our tools(IDEs) would 
>>> work better, like scratch out the function(Most IDEs do that).
>>>
>>> Ex: 
>>>
>>> This
>>>
>>> (defn map>
>>>   "."
>>>
>>>   {:added "1.0"
>>>
>>>:deprecated true}
>>>
>>> [f ch]
>>> //...)
>>>
>>>
>>> instead of this
>>>
>>>
>>> (defn map>
>>>   "Deprecated - this function will be removed. Use transducer instead"
>>>   [f ch]
>>>   //...)
>>>
>>>
>>>
>>>

-- 
You 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: Meta-data should be added to deprecated functions?

[Ertuğrul Çetin]

That will be very useful. Can't wait :)

On Tuesday, August 9, 2016 at 11:49:36 PM UTC+3, Alex Miller wrote:
>
> There are really two aspects to this - one is actually including the 
> metadata in core.async, which can definitely be done. 
>
> The second is adding functionality to Clojure core to give you more 
> feedback about deprecated functions and that's something I've been trying 
> to push through to completion for Clojure 1.9. See: 
> http://dev.clojure.org/jira/browse/CLJ-706
>
> On Tuesday, August 9, 2016 at 3:05:24 PM UTC-5, Ertuğrul Çetin wrote:
>>
>> I found the *map>* function from *core.async* and it was deprecated(doc 
>> says), but there is no meta-data.
>>
>> If we have meta-data for *deprecated* functions our tools(IDEs) would 
>> work better, like scratch out the function(Most IDEs do that).
>>
>> Ex: 
>>
>> This
>>
>> (defn map>
>>   "."
>>
>>   {:added "1.0"
>>
>>:deprecated true}
>>
>> [f ch]
>> //...)
>>
>>
>> instead of this
>>
>>
>> (defn map>
>>   "Deprecated - this function will be removed. Use transducer instead"
>>   [f ch]
>>   //...)
>>
>>
>>
>>

-- 
You 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: Meta-data should be added to deprecated functions?

[Alex Miller]

There are really two aspects to this - one is actually including the 
metadata in core.async, which can definitely be done. 

The second is adding functionality to Clojure core to give you more 
feedback about deprecated functions and that's something I've been trying 
to push through to completion for Clojure 1.9. 
See: http://dev.clojure.org/jira/browse/CLJ-706

On Tuesday, August 9, 2016 at 3:05:24 PM UTC-5, Ertuğrul Çetin wrote:
>
> I found the *map>* function from *core.async* and it was deprecated(doc 
> says), but there is no meta-data.
>
> If we have meta-data for *deprecated* functions our tools(IDEs) would 
> work better, like scratch out the function(Most IDEs do that).
>
> Ex: 
>
> This
>
> (defn map>
>   "."
>
>   {:added "1.0"
>
>:deprecated true}
>
> [f ch]
> //...)
>
>
> instead of this
>
>
> (defn map>
>   "Deprecated - this function will be removed. Use transducer instead"
>   [f ch]
>   //...)
>
>
>
>

-- 
You 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: Multi-OS Engine | Intel(R) Software

[Daniel Compton]

Following up, it seems like it may be possible to use Clojure with MOSE,
but it doesn’t look like a well worn path. Also, I suspect if you went down
this route you may end up writing mostly Java in a funny domain specific
language with lots of parentheses. All that being said, I’d be happy to be
proven wrong :)

https://groups.google.com/forum/#!topic/robovm/b3jbTcpq1Xo
https://software.intel.com/en-us/forums/multi-os-engine/topic/640308
https://github.com/moe-java-samples/moe-kotlin-samples


On Wed, Aug 10, 2016 at 8:09 AM Daniel Compton <
daniel.compton.li...@gmail.com> wrote:

> I had a look at this a few weeks ago, and it seemed like it would only
> work with Java code, not JVM bytecode?
>
> Internal Overview:
>
> Multi-OS Engine facilitates Java* support on iOS* through
>
>- Auto Java binding generation from ObjectiveC and C header files from
>existing libraries or 3rd party packages
>- Java* annotations and NatJ* runtime library
>- Eliminating the need to write JNI functions
>- Prebuilt jar files interfacing iOS* API are provided in the Multi-OS
>Engine, so you can start coding iOS* app in Java* immediately.
>
> I looked around and couldn’t find any lower level details of what they
> were doing, but all of the documentation seems to suggest you need to write
> Java. I’d be very happy to be proven wrong though :)
>
> On Sat, Aug 6, 2016 at 7:47 AM Gregg Reynolds  wrote:
>
>> For those interested in mobile clojure, I just discovered this.  Haven't
>> tried it but it sounds good:
>>
>>
>> https://software.intel.com/en-us/multi-os-engine?utm_source=Develop+Blog+http://www.develop-online.net/_medium=Text+Link_campaign=Android_EMEA_Q2-16_Developer-Blog_Blog-Page?29062016
>>
>> --
>> You 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.
>>
> --
> —
> Daniel
>
-- 
—
Daniel

-- 
You 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: Multi-OS Engine | Intel(R) Software

[Daniel Compton]

I had a look at this a few weeks ago, and it seemed like it would only work
with Java code, not JVM bytecode?

Internal Overview:

Multi-OS Engine facilitates Java* support on iOS* through

   - Auto Java binding generation from ObjectiveC and C header files from
   existing libraries or 3rd party packages
   - Java* annotations and NatJ* runtime library
   - Eliminating the need to write JNI functions
   - Prebuilt jar files interfacing iOS* API are provided in the Multi-OS
   Engine, so you can start coding iOS* app in Java* immediately.

I looked around and couldn’t find any lower level details of what they were
doing, but all of the documentation seems to suggest you need to write
Java. I’d be very happy to be proven wrong though :)

On Sat, Aug 6, 2016 at 7:47 AM Gregg Reynolds  wrote:

> For those interested in mobile clojure, I just discovered this.  Haven't
> tried it but it sounds good:
>
>
> https://software.intel.com/en-us/multi-os-engine?utm_source=Develop+Blog+http://www.develop-online.net/_medium=Text+Link_campaign=Android_EMEA_Q2-16_Developer-Blog_Blog-Page?29062016
>
> --
> You 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.
>
-- 
—
Daniel

-- 
You 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.

Meta-data should be added to deprecated functions?

[Ertuğrul Çetin]

I found the *map>* function from *core.async* and it was deprecated(doc 
says), but there is no meta-data.

If we have meta-data for *deprecated* functions our tools(IDEs) would work 
better, like scratch out the function(Most IDEs do that).

Ex: 

This

(defn map>
  "."

  {:added "1.0"

   :deprecated true}

[f ch]
//...)


instead of this


(defn map>
  "Deprecated - this function will be removed. Use transducer instead"
  [f ch]
  //...)



-- 
You 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 Y combinator] Lambda Calculus: Interactive Y combinator running in the browser

[Yehonathan Sharvit]

http://blog.klipse.tech/lambda/2016/08/07/pure-y-combinator-clojure.html

This article

is an attempt to share in an interactive way, one of the most aesthetic
idea of computer science: the Y combinator.

The Y combinator allows to write recursive functions without names.

Hope you will enjoy reading as much as I enjoyed writing about the Y
combinator.

-- 
You 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: can clojure java.jdbc function 'result-set-seq' add option tosupportcustom 'result-set-read-column' ?

[Sean Corfield]

I’m not clear what you’re suggesting those should do…?

 

Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

 

On 8/8/16, 11:28 PM, "Isaac Zeng"  wrote:

 

That good suggestion @ Xiangtao Zhou

I think we also can define customized reader/writer in `(create-table-ddl table 
spec)`

```clojure

(create-table-ddl :user [[:name "VARCHAR(32)" {:read identity :wirte 
identity}]])

```


On Monday, August 8, 2016 at 6:15:24 AM UTC+8, Sean Corfield wrote:

Thank you! I’ll take a look at this while I’m back at work this week. 

 

 

-- 
You 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: diehard 0.3.0

[Ning Sun]

Thank you, Richard. I hope this library will be helpful to you.
Feel free to report any issue you have with it.

On 08/08/2016 11:37 AM, Richard Möhn wrote:
> Great! I was just going go implement a primitive retry myself, when I
> found this by chance. Thanks for contributing!
> 
> -- 
> You 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.


signature.asc
Description: OpenPGP digital signature

ANN: iapetos 0.1.0 - A Clojure Prometheus Client

[Yannick Scherer]

I'm pleased to announce the initial release of iapetos, a Prometheus [1] 
client for Clojure, wrapping
the respective Java library [2].

Its main goal is to provide elegant access to the underlying functionality, 
as well as appropriate
assistance when tackling common tasks in Clojure-land (like function and 
Ring handler instrumentation).

The project can be found on Github (https://github.com/xsc/iapetos) with 
auto-generated documentation
being available there as well (https://xsc.github.io/iapetos/).

[1] https://prometheus.io
[2] https://github.com/prometheus/client_java

-- 
You 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: can clojure java.jdbc function 'result-set-seq' add option tosupportcustom 'result-set-read-column' ?

[Isaac Zeng]

That good suggestion @ Xiangtao Zhou
I think we also can define customized reader/writer in `(create-table-ddl 
table spec)`
```clojure
(create-table-ddl :user [[:name "VARCHAR(32)" {:read identity :wirte 
identity}]])
```

On Monday, August 8, 2016 at 6:15:24 AM UTC+8, Sean Corfield wrote:
>
> Thank you! I’ll take a look at this while I’m back at work this week. 
>
>  
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org
>
>  
>
> *From: *Xiangtao Zhou 
> *Sent: *Sunday, August 7, 2016 12:36 AM
> *To: *Clojure 
> *Subject: *Re: can clojure java.jdbc function 'result-set-seq' add option 
> tosupportcustom 'result-set-read-column' ?
>
>  
>
> hi Sean,
>
>  
>
> Done. see http://dev.clojure.org/jira/browse/JDBC-137
>
>  
>
> Joe.
>
> On Sunday, August 7, 2016 at 1:33:10 PM UTC+8, Sean Corfield wrote:
>
> Hi Joe,
>
>  
>
> I’m starting to see more requests for per-database customization in a 
> multi-database environment so this is definitely something I’d consider. 
> Could you create a JIRA issue for tracking purposes, along with any 
> suggestions you have about how this might work – and remain performant? 
> http://dev.clojure.org/jira/browse/JDBC
>
>  
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org
>
>  
>
> *From: *Xiangtao Zhou
> *Sent: *Saturday, August 6, 2016 7:15 PM
> *To: *Clojure
> *Subject: *can clojure java.jdbc function 'result-set-seq' add option to 
> supportcustom 'result-set-read-column' ?
>
>  
>
> Hello the contributor of jdbc,
>
>  
>
> Using java.jdbc with postgres composite type,  the common way is extend 
> the IResultSetReadColumn protocol. When there are multiple databases in 
> use, every database should specify it's own column reader. 
>
> Add option to 'result-set-seq' support custom function to replace 
> IResultSetReadColumn may be a solution for this situation.
>
>  
>
> any other idea to solve this?
>
>  
>
> Joe.
>
> -- 
> 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 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.