Re: Pesky java interop bug with 0xFFFFFFF error in BuferredReader

[LaurentJ]

Hank,

Your last version does not work because your `if` condition is wrong, your 
code stops on the first read ;)

Laurent

Le lundi 27 décembre 2021 à 21:34:05 UTC+1, hank@gmail.com a écrit :

> Ooops my bad, there's a typo in '(.toString sb1)' which sould be 'sb'.
> It doesn't change anything, it still won't work, only Laurent's version 
> works. 
>
> user> (defn pt%% [file]
>
> (let [afr (FileReader. file)
>  bfr (BufferedReader. afr)]
>(loop [x (.read bfr)
>   sb (StringBuilder.)]
>  (if (not (= x -1))
>  (.toString sb)
>  (recur  (.append sb (char x)) (.read bfr))
>
> #'user/pt%%
> user> (pt%% ribs)
> ""
>
> Which makes no sense to me...
> -- Hank
>
>

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

Re: Pesky java interop bug with 0xFFFFFFF error in BuferredReader

[LaurentJ]

Hank,

Just a message to give you the solution [spoiler alert]
Don't read it, if you still want to search :)






SPOILER












SPOILER





  ;; ugly version using the fact that java objects are mutable in place
  (defn ugly-read-chars-one-by-one
[reader]
(let [sb (StringBuilder.)]
  (loop []
(let [v (.read reader)]
  (if (neg? v)
(.toString sb)
(do (.append sb (char v))
  (recur)))


  ;; "better" version using loop bindings
  (defn read-chars-one-by-one
[reader]
(loop [sb (StringBuilder.)
  v (.read reader)]
  (if (neg? v)
(.toString sb)
(recur (.append sb (char v))
  (.read reader)


  ;; usage
  (require '[clojure.java.io :as io])
  (with-open [rdr (io/reader "some-file.txt")]
(read-chars-one-by-one rdr))



Regards,
Laurent
Le dimanche 26 décembre 2021 à 18:12:56 UTC+1, hank@gmail.com a écrit :

> Hi --
> Thanks for taking the time to help me.
> As far as I understand the examples, loop has this template:
>
> loop [binding]
>   (condition
>  (statement)
>  (recur (binding)))
> And in 'recur' the loop is re-executed with new bindings.
>
> There was indeed an issue with the 'recur' outside 'when'. Thanks for 
> pointing that out.
> I corrected that in the version below.
>
> I also changed to a smaller file (UTF-8 encoded in Linux), called 
> 'ribs.txt', with the following content:
>
> source/txt on  master [!?] 
> ❯ cat ribs.txt
> Try my delicious pork-chop ribs!
>
> source/txt on  master [!?] 
> ❯ cat ribs.hexdump 
> : 54 72 79 20 6d 79 20 64 65 6c 69 63 69 6f 75 73  Try my delicious
> 0010: 20 70 6f 72 6b 2d 63 68 6f 70 20 72 69 62 73 21   pork-chop ribs!
> 0020: 0a   .
>
>
> (defn pt8 [file]
>(let [afr (FileReader. file); instances of FileReader, BufferedReader, 
> StringBuffer
>  bfr (BufferedReader. afr)
>  ct (StringBuilder.)
>  this-list (list afr bfr ct)]
>  ; (apply println this-list)
>  ; put recur INSIDE THE WHEN
>  (loop [val (.read bfr)]
>(when (not (= val -1))
>  (.append ct (Character/toChars (.read bfr)))
>(recur [val (.read bfr)])))
> ; when finished...
> (.toString ct)))
>
> I think this fixed the 'recur', because it does rebinding to a new call to 
> "read()".
> However, the errors remains.
> 
> user> (pt8 ribs)
> Execution error (IllegalArgumentException) at java.lang.Character/toChars 
> (Character.java:8572).
> Not a valid Unicode code point: 0x
>
> The file used is sufficiently small so that we can walk the bytes using 
> jshell:
>
> jshell> FileReader afr = new FileReader("/home/hank/source/txt/ribs.txt/")
> afr ==> java.io.FileReader@1698c449
>
> jshell> BufferedReader bfr = new BufferedReader(afr)
> bfr ==> java.io.BufferedReader@5ef04b5
>
> jshell> StringBuilder ct = new StringBuilder()
> ct ==> 
>
> FileReader reads 2 bytes per character so, to get to the end, of the first 
> hexdump line, let's walk 32 bytes:
>
> jshell> for (int i=0; i < 31; i++) {
>...> if ((value = bfr.read()) != -1) { ct.append((char) value); }
>...> i++;
>...> }
>
> jshell> ct
> ct ==> Try my delicious
>
> : 54 72 79 20 6d 79 20 64 65 6c 69 63 69 6f 75 73  Try my delicious
>   T  r  y  SP m  y  SP d  e  l  i  c  i  o  u  s  (< YOU ARE 
> HERE)
>
> : 54 72 79 20 6d 79 20 64 65 6c 69 63 69 6f 75 73  Try my delicious
> 0010: 20 70 6f 72 6b 2d 63 68 6f 70 20 72 69 62 73 21   pork-chop ribs!
> 0020: 0a   .
>
> Now we iterate 31 more bytes, stopping short of the last character:
> jshell> for (int i=0; i < 30; i++) {
>...> if ((value = bfr.read()) != -1) { ct.append((char) value); }
>...> i++;
>...> }
>
> jshell> ct
> ct ==> Try my delicious pork-chop ribs
>
> : 54 72 79 20 6d 79 20 64 65 6c 69 63 69 6f 75 73  Try my delicious
> 0010: 20 70 6f 72 6b 2d 63 68 6f 70 20 72 69 62 73 21   pork-chop ribs!
> ^ we stopped here  
>
> We just advance one more:
>
> jshell> if ((value = bfr.read()) != -1) { ct.append((char) value); }
>...> 
>
> jshell> ct
> ct ==> Try my delicious pork-chop ribs!
>
> And one more time, to see if it borks:
> jshell> if ((value = bfr.read()) != -1) { ct.append((char) value); }
>
> jshell> ct
> ct ==> Try my delicious pork-chop ribs!
>
> Nope, everything looks fine. Now where does that '0xFFF" come from?!
> -- Hank

-- 
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: Pesky java interop bug with 0xFFFFFFF error in BuferredReader

[LaurentJ]

Hi Hank,

That loop/recur is still wrong because `loop` set bindings to define names 
and gives initial values but `recur` does *not set bindings*, it just 
provides new values.
So `recur` does not need a vector of bindings like `loop`

The pattern is as follow:
  (loop [a-local-var "initial-value"]
(if (should-stop-looping? a-local-var)
  (execute-last-expression a-local-var)
  (recur a-new-local-var)))

In your pt8 function, you are reading your stream to many times in a loop, 
if I write your pt8 function in procedural pseudo-code, this is what I get: 

bfr = input-stream()
ct = string-buffer()

set loop-start   // set loop point
with val,   // set loop args
val = read(bfr) // set args initial value, first read

if !(val == -1) {
ct.append(char(read(bfr)))  // read again! and lose previous byte!!
goto loop-start
 with val = vector(val, read(bfr))  // read again! this byte will 
be lost soon :(
}
ct.toString()


Regards,
Laurent


Le dimanche 26 décembre 2021 à 18:12:56 UTC+1, hank@gmail.com a écrit :

> Hi --
> Thanks for taking the time to help me.
> As far as I understand the examples, loop has this template:
>
> loop [binding]
>   (condition
>  (statement)
>  (recur (binding)))
> And in 'recur' the loop is re-executed with new bindings.
>
> There was indeed an issue with the 'recur' outside 'when'. Thanks for 
> pointing that out.
> I corrected that in the version below.
>
> I also changed to a smaller file (UTF-8 encoded in Linux), called 
> 'ribs.txt', with the following content:
>
> source/txt on  master [!?] 
> ❯ cat ribs.txt
> Try my delicious pork-chop ribs!
>
> source/txt on  master [!?] 
> ❯ cat ribs.hexdump 
> : 54 72 79 20 6d 79 20 64 65 6c 69 63 69 6f 75 73  Try my delicious
> 0010: 20 70 6f 72 6b 2d 63 68 6f 70 20 72 69 62 73 21   pork-chop ribs!
> 0020: 0a   .
>
>
> (defn pt8 [file]
>(let [afr (FileReader. file); instances of FileReader, BufferedReader, 
> StringBuffer
>  bfr (BufferedReader. afr)
>  ct (StringBuilder.)
>  this-list (list afr bfr ct)]
>  ; (apply println this-list)
>  ; put recur INSIDE THE WHEN
>  (loop [val (.read bfr)]
>(when (not (= val -1))
>  (.append ct (Character/toChars (.read bfr)))
>(recur [val (.read bfr)])))
> ; when finished...
> (.toString ct)))
>
> I think this fixed the 'recur', because it does rebinding to a new call to 
> "read()".
> However, the errors remains.
> 
> user> (pt8 ribs)
> Execution error (IllegalArgumentException) at java.lang.Character/toChars 
> (Character.java:8572).
> Not a valid Unicode code point: 0x
>
> The file used is sufficiently small so that we can walk the bytes using 
> jshell:
>
> jshell> FileReader afr = new FileReader("/home/hank/source/txt/ribs.txt/")
> afr ==> java.io.FileReader@1698c449
>
> jshell> BufferedReader bfr = new BufferedReader(afr)
> bfr ==> java.io.BufferedReader@5ef04b5
>
> jshell> StringBuilder ct = new StringBuilder()
> ct ==> 
>
> FileReader reads 2 bytes per character so, to get to the end, of the first 
> hexdump line, let's walk 32 bytes:
>
> jshell> for (int i=0; i < 31; i++) {
>...> if ((value = bfr.read()) != -1) { ct.append((char) value); }
>...> i++;
>...> }
>
> jshell> ct
> ct ==> Try my delicious
>
> : 54 72 79 20 6d 79 20 64 65 6c 69 63 69 6f 75 73  Try my delicious
>   T  r  y  SP m  y  SP d  e  l  i  c  i  o  u  s  (< YOU ARE 
> HERE)
>
> : 54 72 79 20 6d 79 20 64 65 6c 69 63 69 6f 75 73  Try my delicious
> 0010: 20 70 6f 72 6b 2d 63 68 6f 70 20 72 69 62 73 21   pork-chop ribs!
> 0020: 0a   .
>
> Now we iterate 31 more bytes, stopping short of the last character:
> jshell> for (int i=0; i < 30; i++) {
>...> if ((value = bfr.read()) != -1) { ct.append((char) value); }
>...> i++;
>...> }
>
> jshell> ct
> ct ==> Try my delicious pork-chop ribs
>
> : 54 72 79 20 6d 79 20 64 65 6c 69 63 69 6f 75 73  Try my delicious
> 0010: 20 70 6f 72 6b 2d 63 68 6f 70 20 72 69 62 73 21   pork-chop ribs!
> ^ we stopped here  
>
> We just advance one more:
>
> jshell> if ((value = bfr.read()) != -1) { ct.append((char) value); }
>...> 
>
> jshell> ct
> ct ==> Try my delicious pork-chop ribs!
>
> And one more time, to see if it borks:
> jshell> if ((value = bfr.read()) != -1) { ct.append((char) value); }
>
> jshell> ct
> ct ==> Try my delicious pork-chop ribs!
>
> Nope, everything looks fine. Now where does that '0xFFF" come from?!
> -- Hank

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

Re: Pesky java interop bug with 0xFFFFFFF error in BuferredReader

[LaurentJ]

Hank

Your loop/recur in your pt5 function is still not good. Take the time to 
read the loop/recur documentation and to understand examples.

A Clojure loop/recur is not really a loop like in other procedural 
languages.
It is more akin to a new function call at the `loop` point with new args 
provided by the `recur` call.

If you continue with the function call metaphor
The `loop` call defines 3 things:
  - the starting point of the function
  - the argument name of the function
  - the **initial values** of those arguments

When you need to call again that function with new arguments, you use 
`recur` with **new values**.
When you don't need to recur, well... dont call `recur` :) and just 
evaluate a last expression which is the result of the `loop` expression.

regards
Laurent


Le dimanche 26 décembre 2021 à 02:35:47 UTC+1, hank@gmail.com a écrit :

> Thank for the answers.
> Trying to recur with '(recur (.read bfr))' resulted in a:
> Syntax error (UnsupportedOperationException) compiling recur at 
> (*cider-repl ~:localhost:41097(clj)*:237:9).
> Can only recur from tail position
> So I changed the code (see below). 
>
> And now it complains that a previous form that was working '(.append 
> etc..') doesn't and the same error remains. 
>
> user> (pt5 myfile)
>
> Execution error (IllegalArgumentException) at java.lang.Character/toChars 
> (Character.java:8572).
> Not a valid Unicode code point: 0x
>
> (defn pt5 [file]
>
>(let [afr (FileReader. file); instances of FileReader, BufferedReader, 
> StringBuffer
>  bfr (BufferedReader. afr)
>  ct (StringBuilder.)
>  this-list (list afr bfr ct)]
>  ; (apply println this-list)
>  (loop [val (.read bfr)]
>(when (not (= val -1))
>  (.append ct (Character/toChars (.read bfr
>(recur val))
> ; when finished...
> (.toString ct)))
>
> Harder then it seemed at first sight...
> -- Hank
>
>
>

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

Re: Pesky java interop bug with 0xFFFFFFF error in BuferredReader

[LaurentJ]

Hi,

In the quoted example the `recur` call is *inside* the `when` which is a 
huge difference because there is in this case an halting condition to get 
out of the loop ;)

regards
Laurent
Le dimanche 26 décembre 2021 à 14:41:15 UTC+1, hank@gmail.com a écrit :

> 2021-12-25, 21:11:46 UTC-3, LaurentJ wrote:
> "Hi,
>
> Your loop/recur usage is wrong, your error may be because your loop has no 
> halting condition."
>
> Hi Laurent --
> I actually took inspiration from one of the sources you posted:
> (import '(javax.sound.sampled AudioSystem AudioFormat$Encoding))
>
> (let [mp3-file (java.io.File. "tryout.mp3")
>   audio-in (AudioSystem/getAudioInputStream mp3-file)
>   audio-decoded-in (AudioSystem/getAudioInputStream 
> AudioFormat$Encoding/PCM_SIGNED audio-in)
>   buffer (make-array Byte/TYPE 1024)]
>   (loop []
> (let [size (.read audio-decoded-in buffer)]
>   (when (> size 0)
> ;do something with PCM data
> (recur)
>
>
>

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

Re: Pesky java interop bug with 0xFFFFFFF error in BuferredReader

[LaurentJ]

Hi,

Your loop/recur usage is wrong, your error may be because your loop has no 
halting condition.

https://clojure.org/reference/special_forms#loop
https://clojuredocs.org/clojure.core/loop

Regards
Laurent

Le samedi 25 décembre 2021 à 20:23:37 UTC+1, hank@gmail.com a écrit :

>
> Hello --
>
> I'm learning Clojure and its Java interop stuff. I am trying to emulate 
> this function:
>
>  public String readAllCharsOneByOne(BufferedReader bufferedReader) throws 
> IOException {
> StringBuilder content = new StringBuilder();
> 
> int value;
> while ((value = bufferedReader.read()) != -1) {
> content.append((char) value);
> }
> 
> return content.toString();
> }
>
>
> So far, I've been able to reason that the parts I need are:
>
>
> (def myfile "/path/to/svenska_sample.txt")
> (import java.io.BufferedReader)
> (import java.io.FileReader) 
> (import java.lang.StringBuilder)
> (import java.lang.Character)
>  
> (def a-FileReader (FileReader. myfile))
> (def bufferedReader (BufferedReader. a-FileReader))
> (def content (StringBuilder.))
>
> which works
>
> user> (.append content (Character/toChars (.read bufferedReader)))
> #object[java.lang.StringBuilder 0x490447d0 "\nDe"]
> user> (.append content (Character/toChars (.read bufferedReader)))
> #object[java.lang.StringBuilder 0x490447d0 "\nDen"]
> user> (.append content (Character/toChars (.read bufferedReader)))
> #object[java.lang.StringBuilder 0x490447d0 "\nDen "]
> user> (.append content (Character/toChars (.read bufferedReader)))
> #object[java.lang.StringBuilder 0x490447d0 "\nDen t"]
> user> (.append content (Character/toChars (.read bufferedReader)))
> #object[java.lang.StringBuilder 0x490447d0 "\nDen ty"]
> user> (.append content (Character/toChars (.read bufferedReader)))
> #object[java.lang.StringBuilder 0x490447d0 "\nDen typ"]
> user> (.append content (Character/toChars (.read bufferedReader)))
> #object[java.lang.StringBuilder 0x490447d0 "\nDen typi"]
>
> The file is a small text file UTF-8 encoded in Linux with the following 
> content:
>
> ❯ cat svenska_sample.txt 
>
> Den typiska impulsiva olycksfågeln är en ung man som kraschar flera bilar, 
> och ofta skryter lite med det, i varje fall när han är tillsammans med sina 
> vänner._. För dem har otur i det närmaste blivit en livsstil, och de råkar 
> konstant ut för olyckor, stora som små. Olycksfåglar kallar vi dem. Hur 
> många det finns kan ingen med säkerhet säga, för det finns inga konkreta 
> definitioner på denna grupp, och heller ingen given avgränsning av den. Att 
> de finns, råder det emellertid ingen tvekan om, varken på sjukhusens 
> akutmottagningar eller i försäkringsbranschen
>
> I wrote a function, with my brand new Clojure Java interop chops, that 
> looks like this:
>
> ;; COMPILES  - BUT CAN'T GET AROUND THE 0XFFF BUG
> (defn pt%% [file]
>(let [afr (FileReader. file); instances of FileReader, BufferedReader, 
> StringBuffer
>  bfr (BufferedReader. afr)
>  ct (StringBuilder.)
>  val (.read bfr)
>  this-list (list afr bfr ct)]
>  ; (apply println this-list)
>  (loop []
>(when (not (= val -1))
>  (.append ct (Character/toChars (.read bfr
>(recur))
> ; when finished...
>  (.toString ct)))
>  
> but it borks with the following error:
>
> user> (pt%% myfile)
> Execution error (IllegalArgumentException) at java.lang.Character/toChars 
> (Character.java:8572).
> Not a valid Unicode code point: 0x
>
> What in the world could be causing this (NOTE: I am not a Java 
> programmer)? 
> Here is the hex dump of the file text file:
>
> ❯ cat svenska_sample.hexdump 
> : 0a44 656e 2074 7970 6973 6b61 2069 6d70  .Den typiska imp
> 0010: 756c 7369 7661 206f 6c79 636b 7366 c3a5  ulsiva olycksf..
> 0020: 6765 6c6e 20c3 a472 2065 6e20 756e 6720  geln ..r en ung 
> 0030: 6d61 6e20 736f 6d20 6b72 6173 6368 6172  man som kraschar
> 0040: 2066 6c65 7261 2062 696c 6172 2c20 6f63   flera bilar, oc
> 0050: 6820 6f66 7461 2073 6b72 7974 6572 206c  h ofta skryter l
> 0060: 6974 6520 6d65 6420 6465 742c 2069 2076  ite med det, i v
> 0070: 6172 6a65 2066 616c 6c20 6ec3 a472 2068  arje fall n..r h
> 0080: 616e 20c3 a472 2074 696c 6c73 616d 6d61  an ..r tillsamma
> 0090: 6e73 206d 6564 2073 696e 6120 76c3 a46e  ns med sina v..n
> 00a0: 6e65 722e 5f2e 2046 c3b6 7220 6465 6d20  ner._. F..r dem 
> 00b0: 6861 7220 6f74 7572 2069 2064 6574 206e  har otur i det n
> 00c0: c3a4 726d 6173 7465 2062 6c69 7669 7420  ..rmaste blivit 
> 00d0: 656e 206c 6976 7373 7469 6c2c 206f 6368  en livsstil, och
> 00e0: 2064 6520 72c3 a56b 6172 206b 6f6e 7374   de r..kar konst
> 00f0: 616e 7420 7574 2066 c3b6 7220 6f6c 7963  ant ut f..r olyc
> 0100: 6b6f 722c 2073 746f 7261 2073 6f6d 2073  kor, stora som s
> 0110: 6dc3 a52e 204f 6c79 636b 7366 c3a5 676c  m... Olycksf..gl
> 

Re: Blocking behavior of >!! ?

[LaurentJ]

...waiting -offers +takers

Le lundi 20 mai 2019 18:30:36 UTC+2, LaurentJ a écrit :
>
> You are not wrong.
>
> I think it was obvious for the author to consider that >!! will not block 
> if there are waiting offers.
>
> You can see it in the code, if no buffer is set the write method will 
> iterate over takers ready to consume the value.
>
> https://github.com/clojure/core.async/blob/91e6971a05fa49ca639fc1b7793141dd5f3d32ce/src/main/clojure/clojure/core/async/impl/channels.clj#L116
>
>
>
> Le lundi 20 mai 2019 15:18:17 UTC+2, Brian Beckman a écrit :
>>
>> Thanks, Thomas. I shouldn't have included the quoted code about (> in my question because it distracts from what I really want to know, and 
>> what I want to know is all about how (go (> available" so that (>!! c 42) doesn't block. 
>>
>> The following is an attempt to clarify my question. I first (go (> and give the name d to the result, which is a channel that I am going 
>> read-from later. Channel d is "connected to" or "relayed from" c. I then 
>> (>!! c 42), and then (> works. I wasted your attention by writing some code that would block (> c) if it weren't quoted.
>>
>> Here is the part I don't understand: the documentation says that (>!! c 
>> 42) will block "if there is no buffer space available," and the 
>> documentation does not specify any other conditions. Well, I created c with 
>> no buffer space, so, (>!! c 42) must block unless something else "makes 
>> buffer space available," assuming the documentation is correct. The only 
>> other interaction with c that could possibly be alive at the time when I do 
>> (>!! c 42), is (go (> available," assuming the documentation is correct. My understanding of (> c) (and I am suspicious of my understanding), is that (> rendezvous available, not a buffer. If that understanding is correct, then 
>> (>!! c 42) should block because there is no buffer available. 
>>
>> On Sunday, May 19, 2019 at 1:48:16 PM UTC-7, Thomas Heller wrote:
>>>
>>> (>> taken by the first go (running in a different thread). So it is blocking 
>>> until something puts another value into c. Since nothing ever does your 
>>> program hangs.
>>>
>>> If it helps you can read "go" as "please run this somewhere else, 
>>> possibly at a different time" and let the current thread continue after the 
>>> go.
>>>
>>> I can't explain this very well but the documentation aspect is accurate.
>>>
>>> On Sunday, May 19, 2019 at 7:33:07 PM UTC+2, Brian Beckman wrote:
>>>>
>>>> The documentation for >!! reads:
>>>>
>>>> -
>>>> clojure.core.async/>!!
>>>> ([port val])
>>>>   puts a val into port. nil values are not allowed. Will block if no
>>>>   buffer space is available. Returns true unless port is already closed.
>>>>
>>>>
>>>> I have a case where I believe that the channel has no buffer, I park a 
>>>> "pseudothread" in a go block reading off that channel via >>> (lexically, not temporally), put to the unbuffered channel via >!!:
>>>>
>>>> (let [c (chan) ;; NO BUFFER!
>>>>   d (go (>>>   e (>!! c 42)] ;; blocking write to c, will unpark c's 
>>>> pseudothread
>>>> (println {:c-coughs-up '(this will hang (>>>   :d-coughs-up (>>>   :what's-ee})
>>>> (close! c) (close! d))
>>>>
>>>> {:c-coughs-up (this will hang (>>>
>>>>
>>>> This case leads me to wonder whether the documentation might read
>>>>
>>>>  >!! will block if there is no buffer space available *and* if there 
>>>> is no *rendezvous *available, that is, no pseudothread parked waiting 
>>>> for >>>
>>>> but it's more likely that I completely misunderstand core.async because 
>>>> I just made up the notion of a pseudothread in my struggle to understand!
>>>>
>>>>
>>>>
>>>>

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

Re: Blocking behavior of >!! ?

[LaurentJ]

You are not wrong.

I think it was obvious for the author to consider that >!! will not block 
if there are waiting offers.

You can see it in the code, if no buffer is set the write method will 
iterate over takers ready to consume the value.
https://github.com/clojure/core.async/blob/91e6971a05fa49ca639fc1b7793141dd5f3d32ce/src/main/clojure/clojure/core/async/impl/channels.clj#L116



Le lundi 20 mai 2019 15:18:17 UTC+2, Brian Beckman a écrit :
>
> Thanks, Thomas. I shouldn't have included the quoted code about ( my question because it distracts from what I really want to know, and what 
> I want to know is all about how (go ( so that (>!! c 42) doesn't block. 
>
> The following is an attempt to clarify my question. I first (go ( and give the name d to the result, which is a channel that I am going 
> read-from later. Channel d is "connected to" or "relayed from" c. I then 
> (>!! c 42), and then ( works. I wasted your attention by writing some code that would block ( c) if it weren't quoted.
>
> Here is the part I don't understand: the documentation says that (>!! c 
> 42) will block "if there is no buffer space available," and the 
> documentation does not specify any other conditions. Well, I created c with 
> no buffer space, so, (>!! c 42) must block unless something else "makes 
> buffer space available," assuming the documentation is correct. The only 
> other interaction with c that could possibly be alive at the time when I do 
> (>!! c 42), is (go ( available," assuming the documentation is correct. My understanding of ( c) (and I am suspicious of my understanding), is that ( rendezvous available, not a buffer. If that understanding is correct, then 
> (>!! c 42) should block because there is no buffer available. 
>
> On Sunday, May 19, 2019 at 1:48:16 PM UTC-7, Thomas Heller wrote:
>>
>> (> by the first go (running in a different thread). So it is blocking until 
>> something puts another value into c. Since nothing ever does your program 
>> hangs.
>>
>> If it helps you can read "go" as "please run this somewhere else, 
>> possibly at a different time" and let the current thread continue after the 
>> go.
>>
>> I can't explain this very well but the documentation aspect is accurate.
>>
>> On Sunday, May 19, 2019 at 7:33:07 PM UTC+2, Brian Beckman wrote:
>>>
>>> The documentation for >!! reads:
>>>
>>> -
>>> clojure.core.async/>!!
>>> ([port val])
>>>   puts a val into port. nil values are not allowed. Will block if no
>>>   buffer space is available. Returns true unless port is already closed.
>>>
>>>
>>> I have a case where I believe that the channel has no buffer, I park a 
>>> "pseudothread" in a go block reading off that channel via >> (lexically, not temporally), put to the unbuffered channel via >!!:
>>>
>>> (let [c (chan) ;; NO BUFFER!
>>>   d (go (>>   e (>!! c 42)] ;; blocking write to c, will unpark c's pseudothread
>>> (println {:c-coughs-up '(this will hang (>>   :d-coughs-up (>>   :what's-ee})
>>> (close! c) (close! d))
>>>
>>> {:c-coughs-up (this will hang (>>
>>>
>>> This case leads me to wonder whether the documentation might read
>>>
>>>  >!! will block if there is no buffer space available *and* if there is 
>>> no *rendezvous *available, that is, no pseudothread parked waiting for 
>>> >>
>>> but it's more likely that I completely misunderstand core.async because 
>>> I just made up the notion of a pseudothread in my struggle to understand!
>>>
>>>
>>>
>>>

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

Re: Proper way to write EDN file, after production bug

[LaurentJ]

I mean just print-dup and print-meta should be enough !

Le vendredi 30 mars 2018 14:31:04 UTC+2, LaurentJ a écrit :
>
> Yes we will set print-dup, print-meta, print-level and print-length to 
> have a properly formatted edn file.
>
> Le vendredi 30 mars 2018 05:55:50 UTC+2, Didier a écrit :
>>
>> Ya, I'd write a wrapping fn, like ->edn which internally binds everything 
>> to what it should be, maybe even declares some extra print defmethod if you 
>> need custom edn serialization, and returns the edn.
>
>

-- 
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: Proper way to write EDN file, after production bug

[LaurentJ]

Yes we will set print-dup, print-meta, print-level and print-length to have 
a properly formatted edn file.

Le vendredi 30 mars 2018 05:55:50 UTC+2, Didier a écrit :
>
> Ya, I'd write a wrapping fn, like ->edn which internally binds everything 
> to what it should be, maybe even declares some extra print defmethod if you 
> need custom edn serialization, and returns the edn.

-- 
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: Proper way to write EDN file, after production bug

[LaurentJ]

I guess we will do that and provide an helper function in an util namespace 
to write an EDN file safely :/

By the way does binding *print-dup* to true isn't enough to prevent any 
interaction of other options like : *print-length* *print-level* ?



Le jeudi 29 mars 2018 21:16:54 UTC+2, Rick Moynihan a écrit :
>
> I'd suggest wrapping the code that writes via prn to the file with a 
> dynamic binding:
>
> e.g. at a REPL:
>
> user=> (set! *print-length* 5)
> 5
> user=> (prn (range 10))
> (0 1 2 3 4 ...)
> nil
> user=> (binding [*print-length* nil] (prn (range 11)))
> (0 1 2 3 4 5 6 7 8 9 10)
> nil
> user=> (prn (range 10))
> (0 1 2 3 4 ...)
>
> If you don't know how this works (or differs to lexical binding via let) 
> you can read up on vars here:
>
> https://clojure.org/reference/vars
>
> Hope this helps!
>
> R.
>
> On 29 March 2018 at 15:57, LaurentJ <laurent...@gmail.com > 
> wrote:
>
>> Hello,
>>
>> A funny bug today, our pipeline was broken because of an EDN file with 
>> ellipsis in it.
>>
>> It appears that the file was generated from a Clojure env with 
>> *print-length* configured.
>> So as many have asked, do we have a better way to write EDN file other 
>> than using prn ?
>>
>> For the moment what is the best strategy to fix this issue and keep our 
>> coders happy with their local repl configuration ?
>>   - ask them to limit the scope of such configuration, in for example the 
>> lein repl profile ?
>>   - wrap prn calls with rebinding of any dynamic vars modifing the 
>> outpout ?
>>
>> Regards
>> Laurent
>> -- 
>> 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.

Proper way to write EDN file, after production bug

[LaurentJ]

Hello,

A funny bug today, our pipeline was broken because of an EDN file with 
ellipsis in it.

It appears that the file was generated from a Clojure env with 
*print-length* configured.
So as many have asked, do we have a better way to write EDN file other than 
using prn ?

For the moment what is the best strategy to fix this issue and keep our 
coders happy with their local repl configuration ?
  - ask them to limit the scope of such configuration, in for example the 
lein repl profile ?
  - wrap prn calls with rebinding of any dynamic vars modifing the outpout ?

Regards
Laurent

-- 
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] anomalies-tools 0.1.2

[LaurentJ]

Nice !

Definitely have to use those anomalies in my next project.


Le samedi 10 mars 2018 21:18:56 UTC+1, alex a écrit :
>
> Anomalies-tools is a small Clojure utility library on top of 
> cognitect.anomalies (https://github.com/cognitect-labs/anomalies) which 
> provides some useful functions and macros for working with anomalies.
> The library is currently in alpha and subject to change. 
> Next step is to add ClojureScript support.
> Feedback and proposals are very welcome.
> Github: https://github.com/dawcs/anomalies-tools
>
>

-- 
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] Eastwood, the Clojure lint tool, version 0.2.4 released

[LaurentJ]

Hi,

If you dont mind, just use them all  ;)
https://github.com/itang/lein-checkall


Le mardi 23 mai 2017 18:16:01 UTC+2, Travis Daudelin a écrit :
>
>  Hi, thanks for posting this looks great!
>
> Is there any overlap in functionality between Eastwood and Kibit 
> ? It's not clear to me which tool I 
> should prefer nor when.
>

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