Re: Pesky java interop bug with 0xFFFFFFF error in BuferredReader
This is embarassing. ;-) Thanks -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/3a4fb35a-a282-4762-bf08-4f891447b7b9n%40googlegroups.com.
Re: Pesky java interop bug with 0xFFFFFFF error in BuferredReader
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/310d27b9-1f6e-4017-9465-14ee8c7a4e15n%40googlegroups.com.
Re: Pesky java interop bug with 0xFFFFFFF error in BuferredReader
Hi -- Thanks so much, Laurent! I was actually kind of close (you told me not to peep, so I didn't hehe). (defn pt30 [file] (def ^:dynamic *asb* (StringBuilder.)) (let [afr (FileReader. file) bfr (BufferedReader. afr)] (loop [x (.read bfr) *asb* (StringBuilder.)] (when (not (= x -1)) (recur (.read bfr) (.append *asb* (java.lang.Character/toChars x))) with (def ribs "/path/to/ribs.txt") which looks similar. But, for some reason, the *asb* variable didn't populate with rib advertisements: user> (pt30 ribs) nil user> *asb* #object[java.lang.StringBuilder 0x29f4eb0c ""] When I convert this practically to the same you did, user> (defn pt34 [file] (let [afr (FileReader. file) bfr (BufferedReader. afr)] (loop [x (.read bfr) sb (StringBuilder.)] (if (not (= x -1)) (.toString sb1) (recur (.read bfr) (.append sb (char x))) #'user/pt34 user> (pt34 ribs) "" I still get no beef (err, ribs). Doesn't print anything either. Weird. Just weird. -- 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/3c1312f9-619b-4056-a54d-d880fcf80cf4n%40googlegroups.com.
Re: What is this notation? "-a"
Thanks! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/d46da6c5-9409-4994-83eb-6cb13aefe7f7n%40googlegroups.com.
Re: Pesky java interop bug with 0xFFFFFFF error in BuferredReader
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 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/d3510982-bcaa-43c2-9461-aaae7be11f49n%40googlegroups.com.
Re: Pesky java interop bug with 0xFFFFFFF error in BuferredReader
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/c293ceb0-d187-41f9-b0a4-68860cb55bd2n%40googlegroups.com.
Re: Pesky java interop bug with 0xFFFFFFF error in BuferredReader
Thanks, Harold. You see, that was an exercise in Java interop - I know about slurp, but I was trying to understand what was going on there. -- 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/dc222f28-0f21-4f02-b79c-1d0f4db4f95bn%40googlegroups.com.
Re: Pesky java interop bug with 0xFFFFFFF error in BuferredReader
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/17bab821-c47d-4791-b3ad-c56df51757a1n%40googlegroups.com.
What is this notation? "-a"
Hello -- Sometimes I see a notation that uses a prefix "-", as in: user> (def -a (atom [])) #'user/-a Is there a special meaning/convention regarding this use of a hyphen prefix? TIA -- 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/7512b9ae-2119-43d8-9595-41bcc38caae5n%40googlegroups.com.
Pesky java interop bug with 0xFFFFFFF error in BuferredReader
inns inga konkre 0180: 7461 2064 6566 696e 6974 696f 6e65 7220 ta definitioner 0190: 70c3 a520 6465 6e6e 6120 6772 7570 702c p.. denna grupp, 01a0: 206f 6368 2068 656c 6c65 7220 696e 6765 och heller inge 01b0: 6e20 6769 7665 6e20 6176 6772 c3a4 6e73 n given avgr..ns 01c0: 6e69 6e67 2061 7620 6465 6e2e 2041 7474 ning av den. Att 01d0: 2064 6520 6669 6e6e 732c 2072 c3a5 6465 de finns, r..de 01e0: 7220 6465 7420 656d 656c 6c65 7274 6964 r det emellertid 01f0: 2069 6e67 656e 2074 7665 6b61 6e20 6f6d ingen tvekan om 0200: 2c20 7661 726b 656e 2070 c3a5 2073 6a75 , varken p.. sju 0210: 6b68 7573 656e 7320 616b 7574 6d6f 7474 khusens akutmott 0220: 6167 6e69 6e67 6172 2065 6c6c 6572 2069 agningar eller i 0230: 2066 c3b6 7273 c3a4 6b72 696e 6773 6272 f..rs..kringsbr 0240: 616e 7363 6865 6e0a anschen. Any ideas? TIA -- 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/46a1af62-833a-4018-a22c-1c7c26c170aan%40googlegroups.com.
Re: ANN: Pulsar 0.2.0 Released
Ok I just discovered there's a separate Google Group for this so I'll be re-posting there: https://groups.google.com/forum/?fromgroups#!forum/quasar-pulsar-user Anyone wanting to reply, please don't reply to this here, reply in the other group instead. On Friday, September 27, 2013 8:38:28 PM UTC+10, Hank wrote: Hi Ron, Different concern from the above so another post. :) Do you think Pulsar can help make Oz-style dataflow concurrencyhttp://en.wikipedia.org/wiki/Oz_(programming_language)#Dataflow_variables_and_declarative_concurrencya reality on the JVM? As discussed in the popular Concepts, Techniques Models of Programminghttp://www.info.ucl.ac.be/~pvr/book.html, e.g. chapter 4.5 See the Ozma effort on bringing this to the JVMhttp://www.infoq.com/presentations/Ozma-- yes I know the talk is about Scala but Clojure would equally benefit from such an extension -- the key takeaway being that a lack of lightweight threads on the JVM doesn't make this feasible just yet. Cheers -- hank On Saturday, July 20, 2013 1:49:55 AM UTC+10, pron wrote: Featuring: distributed actors, supervisors, fiber-blocking IO, and an implementation of core.async. Read the announcement herehttp://blog.paralleluniverse.co/post/55876031297/quasar-pulsar-0-2-0-distributed-actors-supervisors . Imagine running an entire Ring handler inside a go-block... -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: Pulsar 0.2.0 Released
Hi Ron, Does this have any chance of running on Android at all? There is no java agent on Android's VM Dalvik so the byte code instrumentation would have to be plugged in elsewhere. Clojure on Android already involves byte code manipulation as JVM byte code generated by Clojure's compiler has to be passed through a second step called Dex to turn it into Dalvik byte code. Currently this is done by (a) AOT-compiling the Clojure application as much as possible and doing the Dex as part of your build process and (b) using custom class loader that instruments byte code generated at runtime through eval. If only application generated byte code has to be instrumented in order for Pulsar to work, then Pulsar's instrumentation could be plugged into the same places one step before the Dex step. However you can't reach byte code from system classes/the run time library this way. Does Pulsar need to instrument system classes/the runtime library to do its thing? Cheers -- hank On Saturday, July 20, 2013 1:49:55 AM UTC+10, pron wrote: Featuring: distributed actors, supervisors, fiber-blocking IO, and an implementation of core.async. Read the announcement herehttp://blog.paralleluniverse.co/post/55876031297/quasar-pulsar-0-2-0-distributed-actors-supervisors . Imagine running an entire Ring handler inside a go-block... -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: Pulsar 0.2.0 Released
Hi Ron, Different concern from the above so another post. :) Do you think Pulsar can help make Oz-style dataflow concurrencyhttp://en.wikipedia.org/wiki/Oz_(programming_language)#Dataflow_variables_and_declarative_concurrencya reality on the JVM? As discussed in the popular Concepts, Techniques Models of Programminghttp://www.info.ucl.ac.be/~pvr/book.html, e.g. chapter 4.5 See the Ozma effort on bringing this to the JVMhttp://www.infoq.com/presentations/Ozma-- yes I know the talk is about Scala but Clojure would equally benefit from such an extension -- the key takeaway being that a lack of lightweight threads on the JVM doesn't make this feasible just yet. Cheers -- hank On Saturday, July 20, 2013 1:49:55 AM UTC+10, pron wrote: Featuring: distributed actors, supervisors, fiber-blocking IO, and an implementation of core.async. Read the announcement herehttp://blog.paralleluniverse.co/post/55876031297/quasar-pulsar-0-2-0-distributed-actors-supervisors . Imagine running an entire Ring handler inside a go-block... -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Javelin, spreadsheet-like FRP for ClojureScript
Hi Alan, Only saw your answer now, somehow Google groups didn't notify me. Thanks for clarifying. -- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Javelin, spreadsheet-like FRP for ClojureScript
Hi Alan, I'm looking forward to viewing your Clojure/West talk as soon as it comes out on video. In the meantime, I don't think javelin qualifies as functional reactive. It is just reactive. State like this: https://github.com/tailrecursion/javelin/blob/master/src/cljs/tailrecursion/javelin/core.cljs#L64 is place-oriented computing vs. the value-oriented computing that FP is aiming for. The functional qualifier would require that producers output some immutable data structure that consumers read. This is important for concurrency, so that each producing/consuming task can run in separate thread and be scheduled at will, decoupled from any other task. This is a Hard Problem (tm). Infinite sequences are a popular data structure for decoupling consumers from producers, but naive implementations lead to uncontrolled resource usage esp. when it gets more complicated with higher order functions. In the JavaScript world, Elm tries to tackle this. They have the right goals but not yet the right implementation if I understand correctly. E.g. see this discussion: https://groups.google.com/d/msg/elm-discuss/7oFhwuIX0Go/OA3rvEh-lcIJ On a meta note, I am glad every time FRP comes up in Clojure circles. The reactive space is populated by naive implementations that don't scale and fail at concurrency on the one side, and academic Haskell-types that conjure up unimplementable pie-in-the-sky schemes on the other side. The hope is that Clojure folks are ambitious enough to produce something that scales in complexity and performance while having plenty real-world scenarios to test their schemes against at their disposal. Cheers -- hank On Wednesday, February 20, 2013 6:33:56 PM UTC+11, Alan Dipert wrote: Hi all, We recently released a ClojureScript library for FRP called Javelin. Links of interest: * Release announcement: http://tailrecursion.com/blog/2013/02/15/introducing-javelin-an-frp-library-for-clojurescript/ * Demos (more on the way): http://tailrecursion.com/~alan/javelin-demos/ * GitHub project: https://github.com/tailrecursion/javelin In a nutshell, Javelin is an abstract spreadsheet that encourages working with concrete values instead of abstract event streams a la FRP. It supports discrete propagation, which most FRP implementations provide as the event stream, via the ability to toggle cells between discrete/continuous propagation modes. Cell mutation semantics are those of ClojureScript atoms. We have ported Javelin's core to a ref-based Clojure implementation capable of parallel propagation and hope to release it soon. Among other things, our hope is to use it to process Prismatic graph [1] -compatible workflows reactively. If you are using graph or flow [2] and are interested in reactive processing, and wouldn't mind helping us with performance testing, drop me a line. Thanks for giving Javelin a look! I look forward to your feedback and collaboration. Alan 1. https://github.com/Prismatic/plumbing 2. https://github.com/stuartsierra/flow -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: exception in 'map' mutates result to nil -- bug?
I opened a bug report, let's see what the pros have to say on this: http://dev.clojure.org/jira/browse/CLJ-1119 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: exception in 'map' mutates result to nil -- bug?
Ah thanks many times. I saw 457 when I searched the issue list before opening a new one but it wasn't clear to me they were related. I shall use your patch in my private fork. On Tuesday, 4 December 2012 01:06:03 UTC+11, Christophe Grand wrote: This behavior has the same source as CLJ-457. Applying my patch for CL-457, I get: user= (def mapped (map (fn [_] (throw (Exception.))) [1 2 3])) #'user/mapped user= mapped Exception user/fn--1 (NO_SOURCE_FILE:1) (user= mapped RuntimeException Recursive seq realization clojure.lang.LazySeq.sval (LazySeq.java:64) (user= mapped RuntimeException Recursive seq realization clojure.lang.LazySeq.sval (LazySeq.java:64) and lazy: (#Exception java.lang.Exception lazy, again: (#RuntimeException java.lang.RuntimeException: Recursive seq realization for the other example. So the error message may be more generic. Christophe On Mon, Dec 3, 2012 at 10:37 AM, Hank ha...@123mail.org wrote: I opened a bug report, let's see what the pros have to say on this: http://dev.clojure.org/jira/browse/CLJ-1119 -- 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 -- On Clojure http://clj-me.cgrand.net/ Clojure Programming http://clojurebook.com Training, Consulting Contracting http://lambdanext.eu/ -- 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
exception in 'map' mutates result to nil -- bug?
I'm mapping a function that throws an exception over a collection: = (def mapped (map (fn [_] (throw (Exception.))) [1 2 3])) #'user/mapped 'map' is lazy so we're not expecting to see the exception until we're trying to access the result: = mapped Exception user/fn--709 (NO_SOURCE_FILE:1) All good, let's do that again: = mapped () Whoops! Is this by design? Why? Where does that empty sequence come from? 'map' is really just calling the lazy-seq macro but doing this with lazy seq works just fine: = (def lazy (lazy-seq (throw (Exception. #'user/lazy = lazy Exception user/fn--733 (NO_SOURCE_FILE:1) = lazy Exception user/fn--733 (NO_SOURCE_FILE:1) Same exception over and over again as it should be. I stared at the implementations of 'map' and lazy-seq/LazySeq for some hours but I really can't see it. Cheers -- 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
Re: exception in 'map' mutates result to nil -- bug?
I've got this narrowed down to what seems an interaction issue between macros and closures in lazy-seq. Run this code: (defn gen-lazy [] (let [coll [1 2 3]] (lazy-seq (when-let [s (seq coll)] (throw (Exception.)) ) ) ) ) (def lazy (gen-lazy)) (try (println lazy: lazy) (catch Exception ex (println ex)) ) (try (println lazy, again: lazy) (catch Exception ex (println ex)) ) ... and explain to me what you see there. The first time, exception, the second time, empty list. Now if you either a) remove the let statement and put the sequence [1 2 3] directly into where it says coll then it works = same exception in both cases. (defn gen-lazy [] (lazy-seq (when-let [s (seq [1 2 3])] (throw (Exception.)) ) ) ) Or if you take out the when-let macro it works, too: (defn gen-lazy [] (let [coll [1 2 3]] (lazy-seq (seq coll) (throw (Exception.)) ) ) ) Only the combination of closure + when-let macro breaks thigs. I know clojure does some funky things to closures in lazy-seq (see ... perform closed-over local clearing on the tail call of their body on this page: http://clojure.org/lazy), this is related to the undocumented :once keyword on function calls. Maybe that interferes with macros? Or maybe I'm barking up the wrong tree. -- hank On Monday, 3 December 2012 00:58:08 UTC+11, Hank wrote: I'm mapping a function that throws an exception over a collection: = (def mapped (map (fn [_] (throw (Exception.))) [1 2 3])) #'user/mapped 'map' is lazy so we're not expecting to see the exception until we're trying to access the result: = mapped Exception user/fn--709 (NO_SOURCE_FILE:1) All good, let's do that again: = mapped () Whoops! Is this by design? Why? Where does that empty sequence come from? 'map' is really just calling the lazy-seq macro but doing this with lazy seq works just fine: = (def lazy (lazy-seq (throw (Exception. #'user/lazy = lazy Exception user/fn--733 (NO_SOURCE_FILE:1) = lazy Exception user/fn--733 (NO_SOURCE_FILE:1) Same exception over and over again as it should be. I stared at the implementations of 'map' and lazy-seq/LazySeq for some hours but I really can't see it. Cheers -- 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
Re: exception in 'map' mutates result to nil -- bug?
Julian, see my other post, it has nothing to do with map per se. Apart from philosophical questions, the reason I need this to consistently raise an exception, is that I want to interrupt the map evaluation when it is slow, throwing an InteruptedException. I then want to recommence evaluation later. rinse, repeat. I can't recommence it if the sequence has been 'closed' with a final nil. Sounds like a fair use case? On Monday, 3 December 2012 16:35:39 UTC+11, julianrz wrote: Hmm.. I think you are raising both a technical and a philosophical issue - what exactly should a higher-order function return when some application of the supplied function throws exception... The behaviors could be: 1) throw 2) return null 3) return an empty collection (do not continue after 1st failure) 4) same, but continue through all failures 5) return collection with valid applications only What is good behavior? We should have as little uncertainly as possible... I have to admit my first thought is 'just don't allow it to throw, return null instead'. This would allow to still collect results (where it does not throw), and they will be at the matching index locations... Now the technicality. The map code I see for 1.4 is trying to append result of all invocations to a buffer upfront. And each time it will fail, and the buffer will be empty, hence empty result Source is a chunked collection and there is only one chunk, it will be done immediately, and not on subsequent calls - laziness has not started yet Please contrast it with mapv, which results in a vector, not sequence user= (def mapped (mapv (fn [_] (throw (Exception.))) [1 2 3])) Exception user/fn--1 (NO_SOURCE_FILE:1) user= mapped #Unbound Unbound: #'user/mapped Now the lazy-seq example - maybe the difference in behavior can be explained by the fact that lazy-seq caches the result of body evaluation and will keep returning it. Since there is an exception during each evaluation, the caching does not quite happen, and it is re-evaluated? Should the behavior be the same in all 3 cases? I think so, at least for consistency (unsure it can be achieved, though). But throwing in function passed to map really is something you should not do, and I would recommend to change map function to return a null or throw -- to let you know that your code can cause odd behavior. BTW I am not aware of any clojure book that alerts you to that. Also, maybe the implementation of map function should catch your exception internally and produce a null, and return a sequence of nulls? -Julian On Sunday, December 2, 2012 5:58:08 AM UTC-8, Hank wrote: I'm mapping a function that throws an exception over a collection: = (def mapped (map (fn [_] (throw (Exception.))) [1 2 3])) #'user/mapped 'map' is lazy so we're not expecting to see the exception until we're trying to access the result: = mapped Exception user/fn--709 (NO_SOURCE_FILE:1) All good, let's do that again: = mapped () Whoops! Is this by design? Why? Where does that empty sequence come from? 'map' is really just calling the lazy-seq macro but doing this with lazy seq works just fine: = (def lazy (lazy-seq (throw (Exception. #'user/lazy = lazy Exception user/fn--733 (NO_SOURCE_FILE:1) = lazy Exception user/fn--733 (NO_SOURCE_FILE:1) Same exception over and over again as it should be. I stared at the implementations of 'map' and lazy-seq/LazySeq for some hours but I really can't see it. Cheers -- 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
explicit progression-of-time constructs? (wikipedia)
According to Wikipedia, Clojure provides explicit progression-of-time constructs: http://en.wikipedia.org/wiki/Clojure Anyone any clue which constructs are meant by that? The term doesn't even resolve on Google outside the Clojure context. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: datomic has been announced
From watching the presentation, it seems to include (but not be limited to!) the some of the good parts of Prevayler and CouchDB, so anyone familiar with those will find the Datomic concept familiar, too. Prevayler (www.prevayler.org) was announced on Slashdot in 2003 (!) and they basically made the point that RAM had gotten cheap enough to keep most working data in RAM that you could have your data just be POJOs and run your queries on in RAM using some in-language query mechanism that runs on the object graph. Near the start of the above presentation Rich talks about hardware and architectures have changed substantially which is what this is talking about. BTW, even back then before NoSQL became a meme this unmasked some of the SQL fanbois who saw their consulting revenues in jeopardy. :) Prevayler asks you to express all your changes to the object graph in transactions reified as Java objects, there called 'commands' from what I remember, and pass them through this bottleneck that serializes them to disk. This is similar to the transactor that Datomic seems to have. On the disk side of things, Prevayler would use a logging and snapshot combination that was a known design pattern before ( http://www.ibm.com/developerworks/library/wa-objprev/) but popularized by Prevayler. CouchDB exists since 2005 or so and offers the following concepts similar to Datomic: Replication across peers, except CouchDB also persists to disk on peers. The receive queue of transactions that can be filtered and reactive, no polling application design that Datomic offers its peers is similar to the CouchDB _changes stream of updates. CouchDB can filter _changes server-side to reduce load on the network, not sure Datomic can do that. CouchDB also implements the add facts, don't change data in place idea by keeping revisions of the data structures. All in all very exciting to see this confluence of ideas. -- hank On Tuesday, 6 March 2012 05:46:12 UTC+11, kovasb wrote: Since not everyone reads twitter or hacker news, http://datomic.com/ has been updated with an unveiling of Rich's new project. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: producing Blub code and vv.
Thanks for writing, I think this here sums it up nicely: Maybe all of this is possible. After all an human can do it manually. I have a background in machine learning/artificial intelligence ... and yes I can see those things come in handy here. But I see it as more a research topic than engineering topic. With low probability of sucess. Well, some people are enticed by research and high risk. :) -- 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
producing Blub code and vv.
Hi, I'd like to check the interest in the community for a comprehensive Clojure library/framework/whathaveyou that helps produce Java/Python/ Ruby/... a.k.a. Blub (http://www.paulgraham.com/avg.html) code, i.e. instead of writing a Clojure program that e.g. produces web pages, writing a Clojure program that produces a Blub program that produces web pages. A Blub program in idiomatic, maintainable, efficient Blub code that is. This is obviously to enable cooperation on shared domain knowledge/business logic across communities with mixed Clojure/Blub language preferences that I expect will continue to exist for decades. Full cooperation would then also require the framework to produce Clojure code that embodies functionality embodied in Blub code. I'd expect that bit to be harder to realize but also more valuable, as it would allow drawing not only on the body of work done in Blub for reasons of preference but also on legacy code from the dark ages when there was no Clojure. I'm asking this especially in light of the upcoming Clojure Conj where there would be an opportunity to discuss this complex subject in a high bandwidth :) kind of way. Searching this group I haven't found much along those lines other than isolated problems being tackled -- the question here rather being: What's the furthest the the envelope can be pushed in terms of co- opting the Blub world? 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
Re: producing Blub code and vv.
Mauve has more RAM? :) On Sep 29, 9:46 pm, David Nolen dnolen.li...@gmail.com wrote: ClojureScript? David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Using Clojure to Generate Java Source?
There isn't an easy solution right now but I think it's worth the effort producing something there. You might want to join the discussion over here: http://groups.google.com/group/clojure/t/5da63583815b6102 -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: producing Blub code and vv.
On Sep 30, 8:35 am, Nicolas bousque...@gmail.com wrote: Clojure has native interoperability with JVM CLR. Right, this is machine interop. What about people interop? How can a Clojure programmer interoperate with a Ruby programmer? Can I chuck some Clojure code into Google translate (http://google.com/translate) and out comes Ruby code or vice versa? That would be nice. And from my understanding, I see no other language that bring such support you ask for. This is not a feature that clojure lack. That's right, if your idea of a lacking feature is one that other langauges have and therefore Clojure should have, too, this isn't the case here. It is a feature that's lacking just because it would be useful. Maybe its me, but I do not see it as a a top priority for clojure language. That's why I posted this, to find out what the need is, how many Clojure programmers live in inhomogeneous programming environments? Someone just posted something like that a few hours later (http:// groups.google.com/group/clojure/browse_thread/thread/ 18b13c222163dda0), though I was more thinking of the open source communities out there and the vast amounts of code they produce, they are easier to observe and interact with since stuff doesn't happen behind closed doors like in the corporate world. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: producing Blub code and vv.
No. Maintanable and idiomatic code weren't its goals, efficient maybe. If it did in fact produce maintainable and idiomatic code that would be an accidental byproduct. Does it? The ClojureScript compiler was also, from what I understand, designed to produce small programs, i.e. one web page's worth of JavaScript code. I wouldn't assume that this easily scales up especially maintainability wise. On Sep 30, 9:45 am, David Nolen dnolen.li...@gmail.com wrote: Have you actually looked at the ClojureScript compiler? In what way is its design unsuitable for what you're proposing? David On Sep 29, 9:11 am, Hank h...@123mail.org wrote: Mauve has more RAM? :) On Sep 29, 9:46 pm, David Nolen dnolen.li...@gmail.com wrote: ClojureScript? David -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: producing Blub code and vv.
Just replying to my own post here: Something like Linj (https://github.com/xach/linj / http://www.doiserbia.nb.rs/img/doi/1820-0214/2008/1820-02140802019L.pdf) and the corresponding Jnil go into the right direction. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: producing Blub code and vv.
Thanks, but from what I can see, they enable machine interop, not people interop. Instead of cross-platform, can you do cross-community? On Sep 30, 10:00 am, Raoul Duke rao...@gmail.com wrote: Hank, it ain't Clojure so this might be irrelevant to you, but some interesting cross-platform languages are: (a)www.haxe.orgwhich is mature, and (b) Shenhttp://preview.tinyurl.com/6hnjpb2which is still young. sincerely. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: producing Blub code and vv.
I think the major obstacle is likely to be the difference in idioms. Any substantial idiomatic piece of Clojure is going to be almost impossible to automatically translate to _idiomatic_ code in another high-level language that uses different idioms. That could very well turn out to be the case. In the spectrum between fully manual and fully automated I can picture scenarios like: - Mostly manual but with some automatic assistance from the IDE: E.g. the way Eclipse assists you in coding Java, when you press Ctrl+Space. It doesn't automatically write code for you but it can narrow down the choice as to what to type next. - Most automatic but with some manual assistance from the coder: E.g. annotate the Clojure code with hints about the idioms to translate to in the target language. Right now in Clojure we use annotations like :exposes-methods that aren't strictly for the Clojure functionality itself but for Java interop. So there could be annotations like :use-design-pattern-x that dictate the choice of idiom/design pattern in the compilation to the target language. You'd also probably have to introduce a number of coding conventions to constrain your Clojure code in order to avoid holes in the translation. It's probably a question of how unwieldy the produced code is allowed to get. If you express the goal of maintainability in terms of some metric like lines of code or whatever then I can see hard limits being reached. If you don't put a limit on that then I don't see any danger of holes. Some questions: * How do you translate Clojure functions in namespaces spread across multiple files into a Java class? [...] Those are very good questions and I'd have to think about it. Maybe I'll start a wiki somewhere so we can start collecting translation recipes. Generally, if the answer isn't obvious from staring at the Clojure code, it helps to think about the problems in terms of the bigger picture, i.e. the business logic/domain knowledge, and then translate to Blub in the head. E.g. I want to cache generated web pages on the disk, how would I do this in Java? * How would code that uses STM translate to a Blub without it? I like this one in particular. People have written concurrent code before STM. I do it in my job every day. :) How did that work with explicit locks again?? * How idiomatic would Blub code be when Clojure uses immutable data by default? A good source for this is the O'Reilly book Functional Programming in Java. There you can see how idioms from one language can be applied to another. I think Java code that uses a lot of immutable data, i.e. final variables all around, would still be accepted by the Java community. The produced code could even leave out the final keyword in order to not cause too much clutter but still not modify the variables. It violates the principle of least authority but I see that in real-world code everywhere. I think it's a fascinating problem to try to solve for any given target Blub but I'm not sure how practical it would be, i.e., how readable the generated Blub code would be to an average Blub programmer...? The problem may have to be solved first in order to judge the value of the solution. My day-to-day experience and my guts tell me it's worth it. :D You weren't going to the Conj by any chance, were you? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: producing Blub code and vv.
Addendum: Just as an example, for this here ... Would it even be idiomatic Java to always have classes full of only static methods? ... the Java-ists have an idiom (design pattern) called singleton. They're not static methods but once-instance classes. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: producing Blub code and vv.
On Sep 30, 2:58 pm, Sean Corfield seancorfi...@gmail.com wrote: On Thu, Sep 29, 2011 at 11:24 PM, Hank h...@123mail.org wrote: Would it even be idiomatic Java to always have classes full of only static methods? ... the Java-ists have an idiom (design pattern) called singleton. They're not static methods but once-instance classes. Doesn't that kind of prove my point? :) Uh not sure. Let's argue about it in person in November. And, after all, isn't the Singleton design pattern only a workaround for the fact that languages like Java don't have a built-in construct for creating a memoized global variable? :) http://c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: The API docs are gone!
If Rich wants to keep his stuff there because it meets his needs and he is fully aware of what they do and how they do it then all of this is irrelevant. In any case security risk is really a overblown term for even the worst case scenario of what could happen to documentation pages. If you are scared of what might happen, you are free to use a language with more secure documentation pages. Seesh. Hank On Sat, Jun 27, 2009 at 7:55 PM, Four of Seventeenfsevent...@gmail.com wrote: On Jun 27, 6:32 pm, J. McConnell jdo...@gmail.com wrote: On Jun 27, 2009, at 12:28 PM, Four of Seventeen fsevent...@gmail.com wrote: Regardless, it's a security problem that someone other than Rich was able to bring clojure.org down for tens of minutes last night at the push of a button. No, it's not, whatsoever. Yes, it is. It's Rich's site. If someone else is able to substitute arbitrary replacement content for the pages he wrote, that's a huge security vulnerability, no matter who can do it and why. It goes beyond being able to take down someone else's site without cause; whoever it is can put words in Rich's mouth too. What if he'd changed the pages not to an obviously bogus message but to a subtly-altered version of the Clojure pages, perhaps full of errors or snide asides aimed at Common Lisp or at Java or something? Clearly, whoever did this had the capability. We're not talking a simple case of the ISP goes down, the page simply becomes unreachable for a while, which would be unpleasant but not very avoidable or worse than a denial of service if done intentionally. Here we're talking keeping the server up but changing what it serves for various URLs. That's a whole different kettle of fish entirely. For starters, the server was still capable of serving HTML over the net, and so there was no reason for it not to continue serving the CORRECT HTML. Unlike if it was actually, genuinely down. Furthermore, there's this quiet-substitution thing. Whoever did this could replace the Clojure site with a mockery of itself, as described. Or add a 1x1 iframe that tries to hack browsers and install malware. With Rich's reputation, and Clojure's, on the line instead of the reputation of the actual responsible party. If the HTML content displayed at clojure.org is NOT in fact 100% controlled by Rich, and for some reason he can't fix that, then he should change the site's name to make this clear. That will help protect his own reputation in the event of something like the above happening. As things stand, since it just says it's clojure.org, Rich is implicitly assuming full responsibility for everything that appears under that domain name. While apparently, at least for the time being, NOT having full control over what appears there. And that's a dangerous position to be in. -- blog: whydoeseverythingsuck.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Oracle and Clojure
On Mon, Apr 20, 2009 at 9:13 AM, Sean Devlin francoisdev...@gmail.com wrote: Okay, I'm willing to bet this crowd has already seen this: http://www.sun.com/third-party/global/oracle/index.jsp Any thoughts on how this affects Clojure? No effect. -- blog: whydoeseverythingsuck.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Clojure + Terracotta = Yeah, Baby!
Writing a TIM is definitely the way to go, It's a place to hide the glue until both Terracotta and Clojure catches up with each other. uhhh what is a TIM? Thanks Hank -- blog: whydoeseverythingsuck.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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 -~--~~~~--~~--~--~---
building a class or jar file from clojure
How does one make a standard clojure based class file or jar file without embedding clojure source files. Hank -- blog: whydoeseverythingsuck.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Distributed Clojure
On Thu, Jan 29, 2009 at 7:28 PM, Greg Harman ghar...@gmail.com wrote: Hank: I have looked at TC in the past, and took another look today at your suggestion. Terracotta certainly seems to have promise feature-wise, but I have to admit it's a heavier solution than I had been thinking of, and there are probably all sorts of gotchas (and reviewing old threads on the topic, a few are hinted at) when it comes to distributing some of Clojure's concurrency data structures in the shared-memory approach. Of course until someone tries we won't know where the limitations are for sure. But my thought is that even if terracotta turns out not to be ideal as a mechanism to implement everything, as I see it, the terracotta feature set (or hazelcast) is critical to anything like this, and I can't see re-engineering all that work because you need/want certain things that may need to be done outside it. Regarding it being heavier, my feeling is that for what is really needed, it really is a heavy problem. Hank Kevin: I hadn't heard of Hadoop before, but at first glance it's exactly what I'm looking for. (Thanks!) The problem I am working on is a processing pipeline for massive data sets, and that seems to be the advertised use case for Hadoop. On Jan 29, 7:14 pm, Kevin Downey redc...@gmail.com wrote: have you looked at the available java frameworks like hadoop? there is also some kind of java interface to erlang instead of reinventing the wheel again... On Thu, Jan 29, 2009 at 6:15 AM, Greg Harman ghar...@gmail.com wrote: One of Clojure's big selling points (obviously) is the support for concurrent programming. However, the performance gains you get with this concurrency hits a scalability wall once you're fully utilizing all the cores available in your server. The next step, of course, is to add additional servers. So, I've been mulling over the idea of putting together a framework for distributed applications. I think it should deal with issues such as: * Locating, assessing, and registering CPUs * Division of large jobs into smaller sub-jobs * Dispatching of jobs, including optimization planning (send more jobs to faster CPUs) * Failure recovery * Seamless code integration (so that this can be retrofit as an optimization) both horizontally and vertically * Horizontal = take one time-consuming task and parallelize it * Vertical = take two sequential tasks and pipeline them across different servers Is anybody already working on something similar? Is this already on the Clojure language roadmap as something to be added after 1.0? Any design advice or feature requests if I were to put something like this together? -Greg -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- blog: whydoeseverythingsuck.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Distributed Clojure
As has been discussed on this list before, it seems to me the basis for this should be terracotta, which handles much (most?) of the heavy lifiting required for this kind of task. Have you looked at it? On Thu, Jan 29, 2009 at 9:15 AM, Greg Harman ghar...@gmail.com wrote: One of Clojure's big selling points (obviously) is the support for concurrent programming. However, the performance gains you get with this concurrency hits a scalability wall once you're fully utilizing all the cores available in your server. The next step, of course, is to add additional servers. So, I've been mulling over the idea of putting together a framework for distributed applications. I think it should deal with issues such as: * Locating, assessing, and registering CPUs * Division of large jobs into smaller sub-jobs * Dispatching of jobs, including optimization planning (send more jobs to faster CPUs) * Failure recovery * Seamless code integration (so that this can be retrofit as an optimization) both horizontally and vertically * Horizontal = take one time-consuming task and parallelize it * Vertical = take two sequential tasks and pipeline them across different servers Is anybody already working on something similar? Is this already on the Clojure language roadmap as something to be added after 1.0? Any design advice or feature requests if I were to put something like this together? -Greg -- blog: whydoeseverythingsuck.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Multi-CPU on Mac Not Exploited?
hmm... I'm confused. From the numbers in your example it looks like server has an advantage by a factor of about 2x. But in your text you say that the client version has an advantage with complicated code. What am I missing? Does one JVM have the advantage in one situation and one in others? Hank On Tue, Jan 27, 2009 at 3:20 PM, dreish dresweng...@dreish.org wrote: java -server is not the default on Macs. It makes a huge difference for Clojure. % java -jar clojure.jar Clojure user= (time (reduce #(+ %1 %2 (if (odd? %1) -1 0)) (range 1000))) Elapsed time: 11793.18 msecs 499001 % java -server -jar clojure.jar Clojure user= (time (reduce #(+ %1 %2 (if (odd? %1) -1 0)) (range 1000))) Elapsed time: 6757.651 msecs 499001 The rough rule I've noticed is that the more complicated the Clojure code, the bigger the advantage -client has over -server. On Jan 27, 3:04 am, Keith Bennett keithrbenn...@gmail.com wrote: All - I tried testing the code athttp://clojure.org/Refsto see what the benefit of multicore processing would be. To my surprise, the my-pmap function took *more* time, not less, than the map function. Whereas the times listed in the article were approximately 3.1 and 1.7 seconds, on my MacBookPro 2.33 GHz Intel Core 2 Duo laptop, my times were 14.9 and 15.1 seconds. What is the correct interpretation of these results? Does one need more than 2 CPU's to see a benefit? Or is the Mac JVM only using one CPU instead of two? Or...? ...and is there something wrong with my setup that both took so long? Thanks for any enlightenment. - Keith Bennett -- blog: whydoeseverythingsuck.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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 -~--~~~~--~~--~--~---
