Re: Exploring the (tap>) functions

2019-03-02 Thread Alex Miller 


On Saturday, March 2, 2019 at 1:23:21 PM UTC-6, Glen Mailer wrote:
>
> Hello All
>
> I was wondering if there is an annoucement or a rationale doc coming for 
> (tap>) and it's related functions? The current docstrings do a good job of 
> telling you what they do and how to use them, but the docs on the homepage 
>  seem quite open-ended. 
> Was there a particular motivating case which led to their inclusion in core?
>

tap is primarily intended for pr-style debugging. When you need that kind 
of debugging, you don't want to include an additional library or muck with 
your requires, so tap> is in core.
 

>
> I've been playing around with them a bit, a colleague of mine was using 
> them for local debugging, but then we were unsure whether it made sense to 
> leave them committed when the code shipped to production. I've also been 
> experimenting with extending our logging protocol to send all of the 
> application logs to tap, where they can be siphoned off elsewhere.
>

I don't think you should send stuff to tap> willy-nilly, but might make 
sense to have that as an option.
 

> One thing I did find a bit unusual was that although these are somewhat 
> similar to `add-watch` and `remove-watch`, there is no `reference` 
> argument, so if a function is re-evaled then it can be easy to lose the 
> original and be unable to `remove-tap` without reaching into the private 
> set. Is there a reason for this omission? I'm fairly confident that a 
> backwards-compatible extension to take an optional reference could be added 
> if not, defaulting to the fn itself. Failing that, a `clear-taps` fn might 
> be desirable.
>

Again, in a debug mode, you're generally dynamically adding and removing a 
tap function dynamically so it's not really an issue. That said, feel free 
to file an issue on the problem here (losing the function reference via 
re-eval).
 

>
> Thanks
> Glen
>
>
>

-- 
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: Clojure 1.10 "Illegal Reflective Access Operation"

2019-03-02 Thread Matching Socks 
Does this need adjusting in clojure.xml too?  The code looks pretty similar:

(defn startparse-sax [s ch]
  (.. SAXParserFactory (newInstance) (newSAXParser) (parse s ch)))

The reflection on "parse" is convenient. There are multiple SaxParser.parse 
methods with unique capabilities. The String method allows you not to know 
how the data is encoded.  To open an InputStream, you have to know the 
encoding.  It's pretty hard to open an XML instance correctly!  And the 
InputSource method allows you to parse from a Reader, e.g., a StringReader.

-- 
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: Clojure 1.10 "Illegal Reflective Access Operation"

2019-03-02 Thread Alan Thompson 
I was deceived by the error message.  Since I had only changed the Clojure
version 1.9 => 1.10, and since the warning mentioned only Clojure code:

WARNING: Illegal reflective access by
clojure.lang.InjectedInvoker/0x000800231c40

 (file:/home/alan/.m2/repository/org/clojure/clojure/1.10.0/clojure-1.10.0.jar)


I thought the problem was within the Clojure source.  After investigating
further, the problem was indeed a lack of type-hinting in a dependent
library (Enlive).  The fix was to add 2 type hints to a function call:

   (.parse
 ^java.io.InputStreams ; actual type =>
java.io.BufferedInputStream
 ^org.xml.sax.helpers.DefaultHandler ch; actual type =>
net.cgrand.xml.proxy$org.xml.sax.ext.DefaultHandler2
   )


A Pull Request has been filed.  Much thanks to Andy Fingerhut for pointing
me in the right direction.
Alan Thompson


On Sun, Feb 24, 2019 at 5:53 PM Andy Fingerhut 
wrote:

> I believe this FAQ entry covers what is known about this issue, which many
> others have also seen: https://clojure.org/guides/faq#illegal_access
>
> Andy
>
> On Sun, Feb 24, 2019 at 4:48 PM Alan Thompson  wrote:
>
>> Upgrading from Clojure 1.9 to 1.10, I am getting a new warning:
>>
>> WARNING: An illegal reflective access operation has occurred
>> WARNING: Illegal reflective access by
>> clojure.lang.InjectedInvoker/0x000800231c40
>> (file:/home/alan/.m2/repository/org/clojure/clojure/1.10.0/clojure-1.10.0.jar)
>> to method
>> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(org.xml.sax.InputSource,org.xml.sax.HandlerBase)
>> WARNING: Please consider reporting this to the maintainers of
>> clojure.lang.InjectedInvoker/0x000800231c40
>> WARNING: Use --illegal-access=warn to enable warnings of further illegal
>> reflective access operations
>> WARNING: All illegal access operations will be denied in a future release
>>
>>
>> Using Java 11 on Ubuntu 16.04.  Should I file an issue for this?
>> Alan
>>
>> --
>
>

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

Exploring the (tap>) functions

2019-03-02 Thread Glen Mailer 
Hello All

I was wondering if there is an annoucement or a rationale doc coming for 
(tap>) and it's related functions? The current docstrings do a good job of 
telling you what they do and how to use them, but the docs on the homepage 
 seem quite open-ended. 
Was there a particular motivating case which led to their inclusion in core?

I've been playing around with them a bit, a colleague of mine was using 
them for local debugging, but then we were unsure whether it made sense to 
leave them committed when the code shipped to production. I've also been 
experimenting with extending our logging protocol to send all of the 
application logs to tap, where they can be siphoned off elsewhere.

One thing I did find a bit unusual was that although these are somewhat 
similar to `add-watch` and `remove-watch`, there is no `reference` 
argument, so if a function is re-evaled then it can be easy to lose the 
original and be unable to `remove-tap` without reaching into the private 
set. Is there a reason for this omission? I'm fairly confident that a 
backwards-compatible extension to take an optional reference could be added 
if not, defaulting to the fn itself. Failing that, a `clear-taps` fn might 
be desirable.

Thanks
Glen


-- 
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: Inside Clojure Journal

2019-03-02 Thread Colin Fleming 
I for one would appreciate it if you fixed it rather than removing it :-)

On Wed, 30 Jan 2019 at 20:07, Alex Miller  wrote:

> That's never actually worked. I keep meaning to remove it. :)
>
> On Wednesday, January 30, 2019 at 1:41:16 PM UTC-6, puzzler wrote:
>>
>> +1.
>>
>> I can't seem to subscribe my email to Alex's blog using the form at the
>> bottom of the blog. Clicking the button does nothing. Anyone else having
>> that problem?
>>
>> On Tue, Jan 29, 2019 at 9:03 PM Shaun Parker 
>> wrote:
>>
>>> I just wanted to say thanks to Alex for taking the time to journal all
>>> the Clojure things he's working on (and the non-Clojure things as well).
>>> They're enjoyable to read and eye-opening. It's a great window into the
>>> effort that he and others are putting into Clojure. It's been fun to follow
>>> the spec-alpha2 commits and get to read the thoughts/direction in the
>>> journal. Great work Alex!
>>>
>>> You can find them on the Inside Clojure blog: http://insideclojure.org/
>>>
>>> Shaun
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.