Re: Step by step debugging
On Thursday, November 7, 2013 6:32:29 PM UTC+1, Lee wrote: > > > In Common Lisp when you hit an error you're thrown into a break loop REPL > in which you can view locals, move up and down the stack, and do lots of > other fancier things (re-binding things, restarting...) that are probably > useful in some situations, but just being able to see the locals is, in my > experience, the really huge win. > inc -- -- 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.
StackOverflowError
Dear clojure-users, StackOverflowError clojure.lang.RT.nthFrom (RT.java:789) I got this error message during evaluation of "count" function call on a quite short list (about 200 elements). What can be reasons of the error. Any hints would be greatly appreciated. Sincerely, Ru -- -- 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: StackOverflowError
I cannot reproduce your result: user=> (-> 500 range doall count) 500 user=> (-> 500 range count) 500 Could you provide more details? How exactly are you calling 'count' ? Jim On 08/11/13 09:17, ru wrote: Dear clojure-users, StackOverflowError clojure.lang.RT.nthFrom (RT.java:789) I got this error message during evaluation of "count" function call on a quite short list (about 200 elements). What can be reasons of the error. Any hints would be greatly appreciated. Sincerely, Ru -- -- 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. -- -- 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: StackOverflowError
Hi Jim, I forget to say that call to count have been done in not a bare repl, but inside a quite complex program after it did a lot of work on a quite big data. But, after long and profound analysis of source code I did not found any places with deep recursive calls :( Something like stack is filling against my will...? пятница, 8 ноября 2013 г., 13:17:28 UTC+4 пользователь ru написал: > > Dear clojure-users, > > StackOverflowError clojure.lang.RT.nthFrom (RT.java:789) > > I got this error message during evaluation of "count" function call on a > quite short list (about 200 elements). What can be reasons of the error. > Any hints would be greatly appreciated. > > Sincerely, > Ru > -- -- 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: StackOverflowError
On 08/11/13 10:11, ru wrote: I forget to say that call to count have been done in not a bare repl, but inside a quite complex program after it did a lot of work on a quite big data. so your problem does not lie with 'count' but with something else...actually 'count' doesn't hold on to the head of the seq so even tough sometimes it will take a long time (for large seqs), it will never StackOverflow: user=> (-> 5 range count) ;;after quite some time 5 user=> But, after long and profound analysis of source code I did not found any places with deep recursive calls :( Something like stack is filling against my will...? there must be something else causing this...have you tried (clojure.stacktrace/e) right after the exception? Jim -- -- 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: StackOverflowError
I tryed to add a call (clojure.stacktrace/e) to the code after the call to count like this: ... (if TRACE (println [:ЩАС])) (if TRACE (do (println [:OFACTS (count ofacts)]) (clojure.stacktrace/e))) And what a result I have got: ... [:ЩАС] StackOverflowError clojure.lang.RT.nth (RT.java:764) rete.core=> I am afraid, that I am not sure where to put (clojure.stacktrace/e) to make it work :( Or, may be this is not an exception? пятница, 8 ноября 2013 г., 13:17:28 UTC+4 пользователь ru написал: > > Dear clojure-users, > > StackOverflowError clojure.lang.RT.nthFrom (RT.java:789) > > I got this error message during evaluation of "count" function call on a > quite short list (about 200 elements). What can be reasons of the error. > Any hints would be greatly appreciated. > > Sincerely, > Ru > -- -- 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: StackOverflowError
On Fri, Nov 8, 2013 at 5:11 AM, ru wrote: > Hi Jim, > > I forget to say that call to count have been done in not a bare repl, but > inside a quite complex program after it did a lot of work on a quite big > data. But, after long and profound analysis of source code I did not found > any places with deep recursive calls :( Something like stack is filling > against my will...? Are you using concat, remove, or filter to build or modify a sequence? If so, you can run into a StackOverflow error if you build a long chain of operations and then try to process the whole sequence. -John -- -- 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: confused over meta on var
Yes, I fear that you are right. I had a hack through the code last night.
It looks to me like the metadata is set in the
Compiler.load(Reader,String,String) method. This is called from only a
couple of places. From within Compiler, it's called from loadFile.
public static Object loadFile(String file) throws IOException{
// File fo = new File(file);
// if(!fo.exists())
// return null;
FileInputStream f = new FileInputStream(file);
try
{
return load(new InputStreamReader(f, RT.UTF8), new
File(file).getAbsolutePath(), (new File(file)).getName());
}
finally
{
f.close();
}
}
Here the string file name is absolute using the File class.
However, it's also called from
RT.loadResourceScript(Class c, String name, boolean failIfNotFound)
Which gets the file metadata like so...
int slash = name.lastIndexOf('/');
String file = slash >= 0 ? name.substring(slash + 1) : name;
And reads the input stream through the classloader.
This is a bit messy; it should be consistent I think!
Phil
Michael Wood writes:
> Just s guess: Maybe the classpath is absolute in one case and relative in
> the other.
>
> On 07 Nov 2013 7:15 PM, "Phillip Lord" wrote:
>>
>>
>> I find myself confused by the metadata on a var. Consider this code:
>>
>> (def a-test-var 10)
>>
>> (pritnln (meta #'a-test-var))
>>
>> Now when run under "lein test" (by stuffing it into a test namespace), I
>> get this
>>
>>
>> {:ns #, :name a-test-var, :column 1, :line
> 102, :file tawny/util_test.clj}
>>
>>
>> But, when evaled in a live REPL I get this...
>>
>>
>> {:ns #, :name a-test-var, :column 1, :line
> 102, :file
> "/home/phillord/src/knowledge/tawny-owl/test/tawny/util_test.clj"}
>>
>>
>> So, how come the :file is fully qualified in one case, and relative in
>> the other?
>>
>> Phil
>>
>> --
>> --
>> 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.
>
> --
--
Phillip Lord, Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower, skype: russet_apples
Newcastle University, twitter: phillord
NE1 7RU
--
--
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: StackOverflowError
On 08/11/13 10:46, ru wrote: I am afraid, that I am not sure where to put (clojure.stacktrace/e) to make it work :( Or, may be this is not an exception? use (clojure.stacktrace/e) after the exception has been thrown to get some more information than just a line. Don't put it in your code, but rather call it on the repl right after the error. It will probably point you to some more places to have a look. Also, as John suggested, if you've got a lot of lazy operations that might be the cause. Have you looked at reducers? Jim -- -- 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: StackOverflowError
In this line: (if TRACE (do (println [:OFACTS (count ofacts)]) (clojure.stacktrace/e))) the StackOverflowError must be occurring in the evaluation of ofacts. The error breaks out of the evaluation, preventing (clojure.stacktrace/e) from being evaluated. The error sends you back to the Clojure repl prompt, as you showed: StackOverflowError clojure.lang.RT.nth (RT.java:764) rete.core=> Here, at the "rete.core=>" prompt after the error, is where you want to call (clojure.stacktrace/e). - Bruce On Fri, Nov 8, 2013, at 06:10 AM, Jim wrote: > On 08/11/13 10:46, ru wrote: > > > > I am afraid, that I am not sure where to put (clojure.stacktrace/e) to > > make it work :( > > Or, may be this is not an exception? > > use (clojure.stacktrace/e) after the exception has been thrown to get > some more information than just a line. Don't put it in your code, but > rather call it on the repl right after the error. It will probably point > you to some more places to have a look. Also, as John suggested, if > you've got a lot of lazy operations that might be the cause. Have you > looked at reducers? > > Jim -- -- 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: StackOverflowError
On Friday, November 8, 2013 11:11:14 AM UTC+1, ru wrote: > > Hi Jim, > > I forget to say that call to count have been done in not a bare repl, but > inside a quite complex program after it did a lot of work on a quite big > data. But, after long and profound analysis of source code I did not found > any places with deep recursive calls :( Something like stack is filling > against my will...? > > Recursion happens kinda invisibly with lazy seqs and may blow your stack if you "hold on to your head" (search for that term). So that would be something to analyze, too. -- -- 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: Step by step debugging
As far as I can see, though ritz is not Emacs specific per se. It's a set of middleware for nrepl. So you should be able to build clients against it for different environments, including a textual one. There's no reason that a debugger shouldn't be part of lein. I think making it work with java -jar clojure.jar would be harder because you need two JVMs (one running the clojure process, and one the debugger). Phil Lee Spector writes: > Not as good as having it work everywhere with whatever you're already > using, of course, but certainly better than (for example) requiring > that you figure out how to install and use an Emacs-based environment > just to figure out what values your locals have when you crash. > > Would what you have in mind work from "lein run" as well as "lein repl"? FWIW > I (and my students) do a lot via "lein run". > > -Lee > > On Nov 7, 2013, at 2:47 PM, Andy Fingerhut wrote: > >> Lee, I am curious whether you would consider it "too tied to a particular >> dev environment" if the kind of minimal debugging features you wish for >> worked from Leiningen's REPL? i.e. 'lein repl' >> >> I do not know if Ritz can work in such an environment or not, but I am >> guessing it might be easier to get a subset of it working there than from a >> REPL started via 'java -cp clojure.jar clojure.main' >> >> Andy > > -- -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- -- 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: StackOverflowError
Thank you, all, for the very useful information. Stacktrace after StackOverflowError turns out: StackOverflowError clojure.lang.RT.nth (RT.java:764) rete.core=> (clojure.stacktrace/e) java.lang.StackOverflowError: null at clojure.lang.RT.nth (RT.java:764) rete.core$fact_id.invoke (core.clj:403) rete.core$retract_fact$fn__1902.invoke (core.clj:633) clojure.core$complement$fn__4048.invoke (core.clj:1357) clojure.core$filter$fn__4226.invoke (core.clj:2533) clojure.lang.LazySeq.sval (LazySeq.java:42) clojure.lang.LazySeq.seq (LazySeq.java:60) clojure.lang.RT.seq (RT.java:484) nil rete.core=> This list with a problem *ofacts* was been intensively updated by *cons* and *remove* operations (more precisely, *rete.core/retract-fact* function visible in stacktrace contains a call to *remove*). Thus, probably, John is nearer then others to solution. So, the question is: What can I do to avoid recursive *remove* operation? May be I should rewrite it using *loop*? Does this help? Or recursion remains inside *loop*? пятница, 8 ноября 2013 г., 13:17:28 UTC+4 пользователь ru написал: > > Dear clojure-users, > > StackOverflowError clojure.lang.RT.nthFrom (RT.java:789) > > I got this error message during evaluation of "count" function call on a > quite short list (about 200 elements). What can be reasons of the error. > Any hints would be greatly appreciated. > > Sincerely, > Ru > -- -- 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: StackOverflowError
ok we are getting somewhere...is it easy to post the source of your 'retract-fact' & 'fact_id' fns? Jim On 08/11/13 13:17, ru wrote: Thank you, all, for the very useful information. Stacktrace after StackOverflowError turns out: StackOverflowError clojure.lang.RT.nth (RT.java:764) rete.core=> (clojure.stacktrace/e) java.lang.StackOverflowError: null at clojure.lang.RT.nth (RT.java:764) rete.core$fact_id.invoke (core.clj:403) rete.core$retract_fact$fn__1902.invoke (core.clj:633) clojure.core$complement$fn__4048.invoke (core.clj:1357) clojure.core$filter$fn__4226.invoke (core.clj:2533) clojure.lang.LazySeq.sval (LazySeq.java:42) clojure.lang.LazySeq.seq (LazySeq.java:60) clojure.lang.RT.seq (RT.java:484) nil rete.core=> This list with a problem *ofacts* was been intensively updated by *cons* and *remove* operations (more precisely, *rete.core/retract-fact* function visible in stacktrace contains a call to *remove*). Thus, probably, John is nearer then others to solution. So, the question is: What can I do to avoid recursive *remove* operation? May be I should rewrite it using *loop*? Does this help? Or recursion remains inside *loop*? пятница, 8 ноября 2013 г., 13:17:28 UTC+4 пользователь ru написал: Dear clojure-users, StackOverflowError clojure.lang.RT.nthFrom (RT.java:789) I got this error message during evaluation of "count" function call on a quite short list (about 200 elements). What can be reasons of the error. Any hints would be greatly appreciated. Sincerely, Ru -- -- 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. -- -- 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: StackOverflowError
Solution have found:
(remove ...) => (doall (remove ...))
Full source of 'retract-fact' function is:
(defn retract-fact [fid]
"Retract fact for given fact-id by removing it from alpha, beta and fact
memory,
and also by removing from conflict set activations, containing this
fact-id"
;;(println [:RETRACT-FACT fid])
(if-let [frame (remove-fmem fid)]
(let [[typ mp] frame
ais (a-indices typ mp)]
(if TRACE (println [:<== [typ mp] :id fid]))
(doseq [ai ais]
(set-amem ai (doall (remove #(= (fact-id %) fid) (amem ai)) ) ))
(retract-b fid (.get =FIDS= fid))
(def =CFSET=
(filter #(not (some #{fid} (:FIDS (second % =CFSET=))
(.remove =FIDS= fid)
frame)))
Thank you very much once more!
Best regards,
Ru
пятница, 8 ноября 2013 г., 13:17:28 UTC+4 пользователь ru написал:
>
> Dear clojure-users,
>
> StackOverflowError clojure.lang.RT.nthFrom (RT.java:789)
>
> I got this error message during evaluation of "count" function call on a
> quite short list (about 200 elements). What can be reasons of the error.
> Any hints would be greatly appreciated.
>
> Sincerely,
> Ru
>
--
--
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: StackOverflowError
Did I see a def inside a defn? This is weird... glad you solved your
problem though...
On Nov 8, 2013 1:51 PM, "ru" wrote:
> Solution have found:
>
> (remove ...) => (doall (remove ...))
>
> Full source of 'retract-fact' function is:
>
> (defn retract-fact [fid]
> "Retract fact for given fact-id by removing it from alpha, beta and fact
> memory,
> and also by removing from conflict set activations, containing this
> fact-id"
> ;;(println [:RETRACT-FACT fid])
> (if-let [frame (remove-fmem fid)]
> (let [[typ mp] frame
> ais (a-indices typ mp)]
> (if TRACE (println [:<== [typ mp] :id fid]))
> (doseq [ai ais]
> (set-amem ai (doall (remove #(= (fact-id %) fid) (amem ai)) ) ))
> (retract-b fid (.get =FIDS= fid))
> (def =CFSET=
> (filter #(not (some #{fid} (:FIDS (second % =CFSET=))
> (.remove =FIDS= fid)
> frame)))
>
> Thank you very much once more!
>
> Best regards,
> Ru
>
> пятница, 8 ноября 2013 г., 13:17:28 UTC+4 пользователь ru написал:
>>
>> Dear clojure-users,
>>
>> StackOverflowError clojure.lang.RT.nthFrom (RT.java:789)
>>
>> I got this error message during evaluation of "count" function call on a
>> quite short list (about 200 elements). What can be reasons of the error.
>> Any hints would be greatly appreciated.
>>
>> Sincerely,
>> Ru
>>
> --
> --
> 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.
>
--
--
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: StackOverflowError
On Fri, Nov 8, 2013 at 8:51 AM, ru wrote: > Solution have found: > > (remove ...) => (doall (remove ...)) Be careful with this technique. It can easily make your O(n) algorithm O(n^2). It may be better to use data structures that you can use with conj and disj if you need to maintain performance. -John -- -- 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: StackOverflowError
Jim, please, recommend a correct solution for global variable assignment. John, Indeed I would prefere technique with better performance. But, as I understand from scarce documentation, disj works with sets. And doesn't it recursive? пятница, 8 ноября 2013 г., 13:17:28 UTC+4 пользователь ru написал: > > Dear clojure-users, > > StackOverflowError clojure.lang.RT.nthFrom (RT.java:789) > > I got this error message during evaluation of "count" function call on a > quite short list (about 200 elements). What can be reasons of the error. > Any hints would be greatly appreciated. > > Sincerely, > Ru > -- -- 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: StackOverflowError
You don't generally do global variable assignment in Clojure...it is seriously frowned upon and goes against the functional paradigm... I need to run now and I will be busy for the next 2 hours... perhaps someone else can explain if you are in a hurry? On Nov 8, 2013 2:34 PM, "ru" wrote: > Jim, please, recommend a correct solution for global variable assignment. > > John, Indeed I would prefere technique with better performance. But, as I > understand from scarce documentation, disj works with sets. And doesn't it > recursive? > > пятница, 8 ноября 2013 г., 13:17:28 UTC+4 пользователь ru написал: >> >> Dear clojure-users, >> >> StackOverflowError clojure.lang.RT.nthFrom (RT.java:789) >> >> I got this error message during evaluation of "count" function call on a >> quite short list (about 200 elements). What can be reasons of the error. >> Any hints would be greatly appreciated. >> >> Sincerely, >> Ru >> > -- > -- > 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. > -- -- 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: StackOverflowError
No, I am not in a hurry :) Thanks in advance. пятница, 8 ноября 2013 г., 13:17:28 UTC+4 пользователь ru написал: > > Dear clojure-users, > > StackOverflowError clojure.lang.RT.nthFrom (RT.java:789) > > I got this error message during evaluation of "count" function call on a > quite short list (about 200 elements). What can be reasons of the error. > Any hints would be greatly appreciated. > > Sincerely, > Ru > -- -- 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.
ANN: ClojureScript 0.0-2024
ClojureScript, the Clojure compiler that emits JavaScript source code. README and source code: https://github.com/clojure/clojurescript New release version: 0.0-2024 Leiningen dependency information: [org.clojure/clojurescript "0.0-2024"] The main change was fixing a regression introduced by relative source maps where ClojureScript source files would be copied over to the output directory only once. Enhancements: * The data structure construction fns are now inlined, this avoids the overhead of a variadic call. Bug fixes: * CLJS-528: warn on protocol extension of basic JavaScript natives -- -- 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: [ClojureScript] Re: ANN: ClojureScript 0.0-2014 - source maps, incremental compilation, and internal changes
Thanks for the report, fixed in 0.0-2024. On Thu, Nov 7, 2013 at 5:14 PM, Geraldo Lopes de Souza wrote: > David, > > Using relative source maps is not updating .cljs equivalents when the > original source is updated. If you delete it'll be created. If you update > the .cljs it remains stalled. > > Using lein-cljsbuild "1.0.0-alpha2". > > Regards, > > Geraldo > > On Wednesday, November 6, 2013 6:09:09 PM UTC-2, David Nolen wrote: > > ClojureScript, the Clojure compiler that emits JavaScript source code. > > > > > > README and source code: https://github.com/clojure/clojurescript > > > > > > > > New release version: 0.0-2014 > > > > > > Leiningen dependency information: > > > > > > [org.clojure/clojurescript "0.0-2014"] > > > > > > There are a number of significant enhancements in this > > > > release. We finally have relative source maps! This should be big > > for people integrating ClojureScript with existing web > > based workflows. > > > > > > Under the hood Chas Emerick has improved how the analyzer works making > > > > it thread safe. This make the compiler considerably more robust and > > eliminates some race conditions in the browser REPL support. > > > > > > Incremental compilation is enhanced both with and without source > > > > maps. In particular we now tag ClojureScript compiled JavaScript files > > with the version of the compiler used - this should make transitioning > > to a new version of the compiler considerably less frustrating - stale > > > > files will get compiled. > > > > > > For those people using the compiler internals directly you will likely > > encounter breakage. If anyone feels inclined to outline a more stable > > interface to internals please get involved in leading an incremental > > > > process towards a stable and flexible API for tool builders. > > > > > > Enhancements: > > * relative source map paths, all original sources will be copied to > > :ouput-dir this should make integrating with web workflow much simpler. > > > > * runtime obtainable compiler version number, *clojurescript-version* now > > available at runtime as a string > > > > > > Bug fixes: > > * CLJS-643: make the ClojureScript compiler (more) idempotent > > > > * CLJS-662: CLJS files compiled from JARs get lost from source map > > * CLJS-661: (try ... (catch :default e ...) ...) > > * CLJS-627: Add warnings on function arity problems > > * CLJS-654: Quit repljs on ^D, don't loop on nil > > > > * CLJS-659: tag compiled files with compiler version > > * CLJS-642: deftype/record should not emit goog.provide > > * CLJS-648: persistent assoc/conj on a transient-created collision node > > * CLJS-631: Use ana/namespaces for shadowing vars > > > > * CLJS-641: js* overflow for large inputs > > * CLJS-645: parse-ns needs to include 'constants-table as a dep > > * CLJS-646: single segment namespaces and reify don't work > > * CLJS-521: pass along entire repl environment when loading dependencies > > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojurescript+unsubscr...@googlegroups.com. > To post to this group, send email to clojurescr...@googlegroups.com. > Visit this group at http://groups.google.com/group/clojurescript. > -- -- 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: Does Pedestal have a future in the long run
Shhh! Don't spill the beans. On Friday, November 8, 2013 1:02:36 AM UTC-5, Daniel wrote: > > I suspect Pedestal adoption will really take off once it has a well > designed and advertised widget/ui toolkit. Just my two cents. -- -- 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.
gemacl: Scientific computing application written in Clojure
Hello everyone: This is my first post here. I'm a researcher writing a numerical simulation software in Clojure. Actually, I'm porting an app a coworker and I wrote in C/Python (called GEMA) to Clojure: The app has been in use for a while at our group, but became very difficult to maintain due to outgrowing its initial design and being very monolithic and at the same time I wanted to learn Functional Programming, so I've been working in the port for a few weeks. The simulations are embarrassingly parallel Random Walk calculations used to study gas diffusion and Helium-3 Magnetic Resonance diffusion measurements in the lungs. At the core of the simulations we do there is a 3D geometrical model of the pulmonary acinus. The new application is designed in a modular fashion, I'm including part of the current README file with :browse confirm wa a description. I've approached my institution's Technology Transfer Office to request authorization to release the software under an Open Source license, and if everything goes well the code will be published soon. I'm very happy in my Clojure trip so far and all the things I'm learning in the process. One of the things I've observed is poor scaling with the number of threads for more than 4 threads in an 8-core Intel i7 CPU, as follows: NTTime cpu%x8 1 101.9 108 2 54.9 220 4 36.0 430 6 33.9 570 8 32.5 700 10 32.5 720 Computing times reported are just the time spent in the computation of the NT futures (not total program execution time). CPU x8 percent is measured with "top" in Linux and the % values are approximate, just to give an idea. I'm running on Debian Wheezy with the following Java platform: JRE: OpenJDK Runtime Environment 1.6.0_27-b27 on Linux 3.2.0-4-amd64 (amd64) JVM: OpenJDK 64-Bit Server VM (build 20.0-b12 mixed mode) I'll try in a 16 core (4-way Opteron) soon and see what happens there. The computing happens over an infinite lazy sequence of random walk steps generated with "(iterate move particle)", when an "extraction function" gets values from zero to the highest number of random walk steps and adds (conj) the values to be kept to a vector. The resulting vector for each particle is then added (conj) to a global vector for latter storage. I've read the previous post about concurrent performance in AMD processors: https://groups.google.com/forum/#!topic/clojure/48W2eff3caU%5B1-25-false%5D. Have to do it again with more time though, to check whether any of the explanations presented there applies to my application. Best regards, Jose Manuel. -- -- 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. README-brief.md Description: Binary data
Re: Does Pedestal have a future in the long run
Will there by any presentation on Pedestal, or just announcements? On Fri, Nov 8, 2013 at 1:38 AM, Ryan Neufeld wrote: > Speaking as a core Pedestal team member and engineer at Cognitect I can > say we are *very* serious about continuing to grow and support Pedestal. > It may be quiet, but we're using the entirety of Pedestal with a number of > client and are fervently preparing a number of new features and > improvements we plan to announce at the Conj next week. Further, we've even > begun selling commercial support that includes Pedestal[1]. > > ClojureScript One was a huge influence on pedestal-app, but you're > completely right that we've abandoned it and should probably wind things > down there. > > Are there any other questions I can field while I'm here? > > -Ryan > > [1]: http://cognitect.com/Cognitect-Support-Services.pdf > > > On Thursday, November 7, 2013 5:30:59 PM UTC-5, Marko Kocić wrote: >> >> Hi all, >> >> I'd like to hear opinions about Pedestal from the people that have been >> playing more with it. Right now I started looking at it, and like some of >> the things, but not sure should I invest more time learning it. While I do >> like some concepts, I'm not sure is it going to became abandonware like >> Clojurescript One (does anyone reemembers it anymore). >> >> So far, after initial splash, I haven't seen large community interest in >> it. The number of aproachable getting started guides and hands on tutorials >> is missing. That might change over time, but I'm afraid that next year this >> time we'll get another Clojurescript one page application framework not >> much related with Pedestal. How serious Cognitect/Relevance is about it? >> >> Best regards, >> Marko >> >> -- > -- > 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. > -- -- 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: gemacl: Scientific computing application written in Clojure
Jose: I am not aware of any conclusive explanation for the issue, and would love to know one if anyone finds out. At least in the case of that program mentioned in the other discussion thread, much better speedup was achieved running N different JVM processes, each single-threaded, on a machine with N CPU cores. If you are willing to try an experiment like that and see whether you get similar results, that would indicate that the issue is due to multiple threads within a single JVM, as opposed to some OS or hardware performance limitation. Below are a list of possible explanations that seem most likely to me, but again, no conclusive evidence for any of them yet: 1. JVM object allocation and/or garbage collector using locks or other multi-threading performance killers 2. CPU core cache thrashing when the thread scheduler causes threads to frequently be scheduled on different CPU cores (I haven't aired that guess before, but it is related to the guess I made near the end of the conversation you link to). 3. CPU core cache thrashing because single-threaded versions have working sets that fit in caches close to CPU cores, but this working set is multiplied by N when running N threads. 4. Some subtle area of Clojure implementation that you are using that is limiting parallelism Andy On Fri, Nov 8, 2013 at 1:42 PM, Jose M. Perez Sanchez wrote: > Hello everyone: > > This is my first post here. I'm a researcher writing a numerical > simulation software in Clojure. Actually, I'm porting an app a coworker and > I wrote in C/Python (called GEMA) to Clojure: The app has been in use for a > while at our group, but became very difficult to maintain due to outgrowing > its initial design and being very monolithic and at the same time I wanted > to learn Functional Programming, so I've been working in the port for a few > weeks. > > The simulations are embarrassingly parallel Random Walk calculations used > to study gas diffusion and Helium-3 Magnetic Resonance diffusion > measurements in the lungs. At the core of the simulations we do there is a > 3D geometrical model of the pulmonary acinus. The new application is > designed in a modular fashion, I'm including part of the current README > file with :browse confirm wa > a description. > > I've approached my institution's Technology Transfer Office to request > authorization to release the software under an Open Source license, and if > everything goes well the code will be published soon. I'm very happy in my > Clojure trip so far and all the things I'm learning in the process. > > One of the things I've observed is poor scaling with the number of threads > for more than 4 threads in an 8-core Intel i7 CPU, as follows: > > NTTime cpu%x8 > 1 101.9 108 > 2 54.9 220 > 4 36.0 430 > 6 33.9 570 > 8 32.5 700 > 10 32.5 720 > > Computing times reported are just the time spent in the computation of the > NT futures (not total program execution time). CPU x8 percent is measured > with "top" in Linux and the % values are approximate, just to give an idea. > I'm running on Debian Wheezy with the following Java platform: > > JRE: OpenJDK Runtime Environment 1.6.0_27-b27 on Linux 3.2.0-4-amd64 > (amd64) > JVM: OpenJDK 64-Bit Server VM (build 20.0-b12 mixed mode) > > I'll try in a 16 core (4-way Opteron) soon and see what happens there. The > computing happens over an infinite lazy sequence of random walk steps > generated with "(iterate move particle)", when an "extraction function" > gets values from zero to the highest number of random walk steps and adds > (conj) the values to be kept to a vector. The resulting vector for each > particle is then added (conj) to a global vector for latter storage. > > I've read the previous post about concurrent performance in AMD > processors: > https://groups.google.com/forum/#!topic/clojure/48W2eff3caU%5B1-25-false%5D. > Have to do it again with more time though, to check whether any of the > explanations presented there applies to my application. > > Best regards, > > Jose Manuel. > > -- > -- > 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. > -- -- 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 m
Re: [ClojureScript] Re: ANN: ClojureScript 0.0-2014 - source maps, incremental compilation, and internal changes
Thank you David! On Friday, November 8, 2013 2:46:03 PM UTC-2, David Nolen wrote: > Thanks for the report, fixed in 0.0-2024. > > > > On Thu, Nov 7, 2013 at 5:14 PM, Geraldo Lopes de Souza > wrote: > > David, > > > > Using relative source maps is not updating .cljs equivalents when the > original source is updated. If you delete it'll be created. If you update the > .cljs it remains stalled. > > > > Using lein-cljsbuild "1.0.0-alpha2". > > > > Regards, > > > > Geraldo > > > > > > On Wednesday, November 6, 2013 6:09:09 PM UTC-2, David Nolen wrote: > > > ClojureScript, the Clojure compiler that emits JavaScript source code. > > > > > > > > > README and source code: https://github.com/clojure/clojurescript > > > > > > > > > > > > New release version: 0.0-2014 > > > > > > > > > Leiningen dependency information: > > > > > > > > > [org.clojure/clojurescript "0.0-2014"] > > > > > > > > > There are a number of significant enhancements in this > > > > > > release. We finally have relative source maps! This should be big > > > for people integrating ClojureScript with existing web > > > based workflows. > > > > > > > > > Under the hood Chas Emerick has improved how the analyzer works making > > > > > > it thread safe. This make the compiler considerably more robust and > > > eliminates some race conditions in the browser REPL support. > > > > > > > > > Incremental compilation is enhanced both with and without source > > > > > > maps. In particular we now tag ClojureScript compiled JavaScript files > > > with the version of the compiler used - this should make transitioning > > > to a new version of the compiler considerably less frustrating - stale > > > > > > files will get compiled. > > > > > > > > > For those people using the compiler internals directly you will likely > > > encounter breakage. If anyone feels inclined to outline a more stable > > > interface to internals please get involved in leading an incremental > > > > > > process towards a stable and flexible API for tool builders. > > > > > > > > > Enhancements: > > > * relative source map paths, all original sources will be copied to > > > :ouput-dir this should make integrating with web workflow much simpler. > > > > > > * runtime obtainable compiler version number, *clojurescript-version* now > > > available at runtime as a string > > > > > > > > > Bug fixes: > > > * CLJS-643: make the ClojureScript compiler (more) idempotent > > > > > > * CLJS-662: CLJS files compiled from JARs get lost from source map > > > * CLJS-661: (try ... (catch :default e ...) ...) > > > * CLJS-627: Add warnings on function arity problems > > > * CLJS-654: Quit repljs on ^D, don't loop on nil > > > > > > * CLJS-659: tag compiled files with compiler version > > > * CLJS-642: deftype/record should not emit goog.provide > > > * CLJS-648: persistent assoc/conj on a transient-created collision node > > > * CLJS-631: Use ana/namespaces for shadowing vars > > > > > > * CLJS-641: js* overflow for large inputs > > > * CLJS-645: parse-ns needs to include 'constants-table as a dep > > > * CLJS-646: single segment namespaces and reify don't work > > > * CLJS-521: pass along entire repl environment when loading dependencies > > > > > > -- > > Note that posts from new members are moderated - please be patient with your > first post. > > --- > > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > > To unsubscribe from this group and stop receiving emails from it, send an > email to clojurescrip...@googlegroups.com. > > To post to this group, send email to clojur...@googlegroups.com. > > Visit this group at http://groups.google.com/group/clojurescript. -- -- 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.
ANN: ClojureScript 0.0-2030, core.async compatibility
ClojureScript, the Clojure compiler that emits JavaScript source code. README and source code: https://github.com/clojure/clojurescript New release version: 0.0-2030 Leiningen dependency information: [org.clojure/clojurescript "0.0-2030"] This release is mostly to address compatability issues with the latest release of core.async. Bug fixes: * CLJS-663: keyword too permissive on inputs * CLJS-660: keyword fn behavior inconsistent with Clojure * CLJS-528: Warns on any attempted extension of protocols to base JavaScript types, using the new warning system. -- -- 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: [ClojureScript] ANN: ClojureScript 0.0-2030, core.async compatibility
Thanks- addresses my duplicate bug! --- Joseph Smith j...@uwcreations.com @solussd On Nov 8, 2013, at 5:11 PM, David Nolen wrote: > ClojureScript, the Clojure compiler that emits JavaScript source code. > > README and source code: https://github.com/clojure/clojurescript > > New release version: 0.0-2030 > > Leiningen dependency information: > > [org.clojure/clojurescript "0.0-2030"] > > This release is mostly to address compatability issues with the latest > release of core.async. > > Bug fixes: > * CLJS-663: keyword too permissive on inputs > * CLJS-660: keyword fn behavior inconsistent with Clojure > * CLJS-528: Warns on any attempted extension of protocols > to base JavaScript types, using the new warning system. > > > -- > Note that posts from new members are moderated - please be patient with your > first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojurescript+unsubscr...@googlegroups.com. > To post to this group, send email to clojurescr...@googlegroups.com. > Visit this group at http://groups.google.com/group/clojurescript. -- -- 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.
Multi-arity protocol methods implemented in different maps
I'm guessing this is either impossible or I'm missing something obvious.
Say I have this:
(defprotocol X
(foo [x] [x y]))
For the sake of implementation inheritance, I'd like to define one of the
arities in map x1:
(def x1 {:foo (fn [x] "x1")})
And the other arity in x2:
(def x2 {:foo (fn [x y] "x2")})
Is there any way I can merge those two guys to extend them both to type T?
(extend T
X
(merge-with ??? x1 x2))
Or something else?
Thanks,
Jim
--
--
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: Does Pedestal have a future in the long run
Pedestal-app and pedestal-service seem like they have a lot of solid design behind them and there's quite a few bright people that have put time into development and documentation. I don't doubt Cognitect's dedication to the project or their ability to derive productivity from it. I program in clojure on a part-time basis and when I first learned about pedestal (specifically pedestal-app) it was very promising. I wanted to see if the next website I made (using clojurescript in the browser and clojure on the server) would be a good match for pedestal and I've spent the past couple months reading (and re-reading ... and re-reading ...) the available pedestal-app documentation, pedestal sample apps and especially the app-tutorial. After many hours I've decided to move away from pedestal-app, at least for the time being. Earlier I had done some proof-of-concept UI stuff with C2 (think moving an array of images a la google maps) which went pretty well. It was my first time learning and using clojurescript and C2; cljsbuild was a delight. I decided the next step was to try to take what I had and translate that into pedestal-app. The message oriented communication between different parts of the app, the ability to build client-server communication without a server, the ability to step through recordings of app interactions for testing, shared clojure / clojurescript code, etc. were all very appealing. Especially compared to plain javascript in a browser, there's the ability to use clojurescript (a win), the ability to avoid callback mess (which can also be avoided through FRP stuff like javelin), and a message oriented architecture (which seems superior to FRP?) which all made pedestal very compelling. Each time I worked with pedestal-app I would make some progress but progress was slow. I was wading through a swamp of maybe strange convention and overcomplication. app-tutorial was at times illuminating and cryptic; each read through would teach me something that I thought could have been, perhaps, better explained than it was. I wanted to re-write the whole of app-tutorial and offer it up as supplemental documentation but I wanted to work on my website more. Another aspect to my story is that I don't know of anyone else that uses any of this stuff so outlets for questions are limited to mailings lists and IRC and I try to keep myself from asking bad or 'obvious' questions to that helpful crowd ; ) I've since moved on to looking at using a collection of libraries like hiccup/domina/dommy/whatever for DOM stuff (I don't care - they would all work for my needs) and - *crucially* - using core.async as the glue that will facilitate the interactions between all the pieces of the UI stuff. I have renewed excitement for the project that I'm working on because I'm no longer stuck in slow motion. Again, I only essentially have "hobby time" to work on this but in one week of learning core.async, with special thanks to David Nolen's tutorials and example code, I know how to proceed. I'll have to write some additional stuff that pedestal-app would have provided out of the gate but it's nothing daunting. And it's exciting. Pedestal-app was too cumbersome for me, overly complicated and/or not the kind of documentation I wanted but there's still a lot of great ideas behind it. I'm interested to see what pedestal-app's rate of adoption and new developments will be, too, and it might be something I would return to in the future. On Fri, Nov 8, 2013 at 4:39 PM, Andreas Liljeqvist wrote: > Will there by any presentation on Pedestal, or just announcements? > > > On Fri, Nov 8, 2013 at 1:38 AM, Ryan Neufeld wrote: > >> Speaking as a core Pedestal team member and engineer at Cognitect I can >> say we are *very* serious about continuing to grow and support Pedestal. >> It may be quiet, but we're using the entirety of Pedestal with a number of >> client and are fervently preparing a number of new features and >> improvements we plan to announce at the Conj next week. Further, we've even >> begun selling commercial support that includes Pedestal[1]. >> >> ClojureScript One was a huge influence on pedestal-app, but you're >> completely right that we've abandoned it and should probably wind things >> down there. >> >> Are there any other questions I can field while I'm here? >> >> -Ryan >> >> [1]: http://cognitect.com/Cognitect-Support-Services.pdf >> >> >> On Thursday, November 7, 2013 5:30:59 PM UTC-5, Marko Kocić wrote: >>> >>> Hi all, >>> >>> I'd like to hear opinions about Pedestal from the people that have been >>> playing more with it. Right now I started looking at it, and like some of >>> the things, but not sure should I invest more time learning it. While I do >>> like some concepts, I'm not sure is it going to became abandonware like >>> Clojurescript One (does anyone reemembers it anymore). >>> >>> So far, after initial splash, I haven't seen large community interest in >>> it. The number of aproach
Re: Does Pedestal have a future in the long run
On Thu, Nov 7, 2013 at 5:30 PM, Marko Kocić wrote: > related with Pedestal. How serious Cognitect/Relevance is about it? There is a ton of activity in the repo. Looking forward to v3. -- -- 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.
[ANN] Brambling: Datomic (Schema) Migration library/toolkit for Clojure
https://github.com/bitemyapp/brambling/ This is a very early point in time for the library, (alpha), but it has already been useful at work so I figured I would get it out there to see what bits people did and didn't care about. Why this exists: As with any historical database you have to migrate the transaction log in addition to the "current" state of the universe. Conveniently, Datomic makes querying at arbitrary points of time rather easily. Less conveniently, there's no map/reduce sugar for performing migrations so I needed to put together a toolkit to handle reducing over the origin tx-log, carrying over entity identities consistently (old -> tempid -> new), and translating the transactions with the new schema being first at the head of the destination. There are some pretty serious limitations (incremental migrations principally) but I don't think they're showstoppers, and like I said, this has already been useful for migrating production data. Let me know if you have any questions! --- Chris -- -- 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: Step by step debugging
One quick clarification about -Dclojure.compile.disable-locals-clearing=true which bit me - this is actually read in clojure.main, which uses it to initialise the *compiler-options* var. This means that if you start your app in any other way (I'm not sure if lein duplicates the clojure.main functionality) setting this system property doesn't do anything. On 8 November 2013 10:22, Alex Miller wrote: > I believe the locals are actually *not* available because they are > proactively cleared to help GC. > > Setting the *compiler-options* var with :disable-locals-clearing can turn > that off. Which is probably what you often want in dev, but is not the > default. You can also set this via command line with > -Dclojure.compile.disable-locals-clearing=true > > > On Thursday, November 7, 2013 11:32:29 AM UTC-6, Lee wrote: > >> >> I'd like to chime in here from a background that involved a lot of Common >> Lisping back in the day. >> >> I have been continually dismayed, as I've moved further from Common Lisp, >> that debugging facilities that are so basic and ubiquitous and helpful in >> that world are considered exotic or specialized or necessarily tied to >> particular IDEs or tool chains in other language ecosystems. >> >> Even more basic (and useful, in my experience) than things like steppers >> or the ability to set break points is the ability just to see the values of >> locals when an error occurs. This is so obviously useful, and so obviously >> doable (for decades), that I'm really quite stunned that it's so >> complicated to do in Clojure and tied to a particular toolset if you can do >> it at all. >> >> In Common Lisp when you hit an error you're thrown into a break loop REPL >> in which you can view locals, move up and down the stack, and do lots of >> other fancier things (re-binding things, restarting...) that are probably >> useful in some situations, but just being able to see the locals is, in my >> experience, the really huge win. It doesn't matter what IDE you're using or >> if you're running it from a command line or whatever -- it's part of the >> language and easy to access no matter how you write and run your code. And >> my guess is that every Common Lisper takes advantage of this frequently. >> Different implementations/environments provide different modes of access to >> this information (e.g. some are GUI-based, and in emacs you can have >> interactive access to it using interaction conventions that seemed like a >> good idea in the 1970s :-), but there's always some way to get the >> information. >> >> By contrast in Clojure this information seems really hard to come by. I >> saw and was excited by a Ritz video -- and I note the enthusiastic applause >> from the crowd when it was shown that you could see locals (gasp!) -- but >> my understanding is that this functionality requires commitment to an >> Emacs-based tool set with all that that implies (which is a lot, IMHO). >> >> When I hit an error running my code from "lein run" or from Clooj or from >> Eclipse/CCW (or I think from any other way that I might run it) I get (or >> can easily get) a backtrace that shows the function call stack at the time >> of the error... which is good, but surely (?) the locals are also available >> when the backtrace is produced and I really also want to see those. The >> ability to browse and navigate this information dynamically, as in a Common >> Lisp break loop, is cool but I can understand that something about the >> Clojure/JVM execution architecture might make that difficult -- maybe that >> really would have to be tied to a particular IDE? However, if it would just >> dump all of the values of the locals to standard output, just like it does >> already with the trace, then I'd be plenty happy since I could dig through >> that output to find what I need but can't currently get. (Yes, dumping the >> values of all of the locals might produce a lot of output and yes, one >> might want to make this an option that could be turned off or on, maybe >> including options re: limits on how much of sequences to print, etc.) >> >> I guess the bottom line of this long message (sorry) is that I hope that >> some of the great tool developers in this community will continue to >> consider providing things like debugging tools that are as untethered as >> possible from particular IDEs. My impression is that nrepl (and maybe other >> projects) are intended to help "untether" things in this way, but it still >> seems like a lot of people assume that something like access to locals >> should naturally be tied to a specific IDE. From my perspective that seems >> like a really unfortunate assumption. I realize that debugging tools are >> unlikely to become "part of the language" in Clojure as they are in Common >> Lisp, but I think there's an important middle ground between that and being >> available only within some specific IDE. >> >> Thanks, >> >> -Lee >> >> >> > philli...@newcastle.ac.uk (Phillip Lord) writ
Re: Step by step debugging
Cedric, you're right in both your assessment of the potential solution (this could definitely be done) and also the problems. You'd need an additional line number mapping of original source line to expanded-lines source line to be able to make any sense of stack traces, thread dumps etc, and of course your debugger would need to use it to correctly highlight the current line. It's a nice idea but I fear it's not very practical. I'll think about it a bit, though, and see if I can take advantage of it in some way. I thought there was an additional line limit per class that might have been problematic but I was wrong, it's a bytecode size limit per method. On 8 November 2013 19:24, Cedric Greevey wrote: > This JVMTI doesn't know Clojure source code from parsnip soup, I expect, > so can't it be fooled into "thinking" that the bytecode it's interpreting > came from a source with many more, shorter lines? So > > (defn x [y z] > (a (b (c)) > ((d) e (f g > > could be passed off to it as if it were > > (defn x [y z] (a (b > (c)) > ((d) > e (f g > > with breakpoints on (defn ...), (a ...), a, (b (c)), or b being passed to > JVMTI as breakpoints on the first line of the latter formatting of the > code; breakpoints on (c) or c the second line; breakpoints on (d) or d the > third line; and breakpoints on e, (f g), f, or g the fourth line. Execution > would halt at the breakpoint with the correct amount of evaluation done. > (The bare letters are presumed to be self-evaluating literals or var > lookups here, and the operators, other than defn, to be functions.) > > Breakpoints on a macro sexp would need to halt on the first evaluation of > any of the expansion, and breakpoints on a macro argument would need to be > carried through into the expansion. The special forms are mostly fairly > obvious -- break on an if or its condition, for example, breaks before > evaluating the condition; break on the then clause breaks after evaluating > the condition, before evaluating the then clause, only if the condition was > true; etc. Combined, those rules mean a breakpoint on a particular (cond > ...) condition X would only trip if all the previous conditions were false, > before evaluating condition X, and a breakpoint on the corresponding then > clause only if all the preceding conditions were false but condition X was > true, after evaluating X but before evaluating X's then clause, because it > would end up attached to X's corresponding conditional or then clause > (respectively) in the macro-expanded if-tree (>(sexp)< indicates breakpoint > target): > > (cond > (thing1) (dothis) > (thing2) (dothat) > >(thing3)< (dosomethingelse) > :else (default)) > > should macroexpand to > > (if (thing1) > (dothis) > (if (thing2) > (dothat) > (if >(thing3)< > (dosomethingelse) > (if :else > (default) > (throw ( ... no matching clause blah blah ... [never actually > executes in this case])) > > so the "(if >(thing3)<" line would be what JVMTI "thinks" is the > breakpointed line in this case. > > The real issue I can foresee here would be if there's no way to make the > "lines" seen by the breakpoint/debugging stuff be different from the > "lines" used for error reporting (e.g. in stacktraces), as then *either* > the "line" granularity for breakpoints is whole lines of your actual source > code *or* stacktrace line numbers won't always correspond to what your > editor shows for the problem line in your source code, for example if > (default) threw a ClassCastException because "default" did not implement > IFn in the above the stacktrace might point to line 8 when it was really > line 5 of your (cond ...) expression (but line 8 of the (if ...) it > macroexpanded to, and which was vertically spread out to put each distinct > (as to what nontrivial evaluation has happened yet) sexp-based breakpoint > position on its own line to please JVMTI). > > > > > On Fri, Nov 8, 2013 at 12:53 AM, Colin Fleming < > colin.mailingl...@gmail.com> wrote: > >> Right, sadly I believe this is impossible using JVMTI, although I'm far >> from an expert. >> >> >> On 8 November 2013 18:51, Cedric Greevey wrote: >> >>> Ideally, in a Lisp I'd think the unit of breakpoints would not be a line >>> but instead an s-expression, tripping before evaluating the body of the >>> expression. >>> >>> >>> On Fri, Nov 8, 2013 at 12:24 AM, Colin Fleming < >>> colin.mailingl...@gmail.com> wrote: >>> I'm slightly late to the discussion, sorry - currently moving cities. Cursive does indeed have a stepping debugger which works well with Clojure, although it's quite slow (I haven't been able to figure out why, yet - I suspect Clojure adds a lot of line information to the bytecode). There have also been some fairly annoying bugs with it which will be fixed in the next drop. Here's more or less what it can do: 1
