Re: [ANN] alpacas: a new Clojure source viewer
Screenshot added On Tuesday, 4 June 2013 21:14:56 UTC+1, Denis Labaye wrote: > > Idea seems great but no screenshots? Too bad for a visual tool > > > On Tue, Jun 4, 2013 at 10:13 PM, Andrea Chiavazza > > > wrote: > >> Alpacas is an application that displays Clojure source code with forms >> shown as nested boxes, doing away with parenthesis altogether. >> Run it with "lein run" and it will display its own source code. >> There is partial support to navigate the source code by moving a cursor >> with the left and right arrows. >> >> Obviously the idea would be to be able to edit the source rather than >> just viewing it. Some clever key combinations or even the mouse might help >> accomplish that. >> It is still a proof-of-concept and not very useful at the moment, but I >> think it might turn into something useful, or even innovative shall >> somebody decide to put some effort into it. >> >> I didn't work at it in a while but I decided to publish it (under GPL) so >> as to be able to include it in my cv (you can mail me at >> ndrc...@gmail.com for Clojure job offers). >> >> It is hosted at: https://code.google.com/p/alpacas/ >> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com . >> For more options, visit https://groups.google.com/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: [ANN] alpacas: a new Clojure source viewer
Thanks for letting me know, I was not aware of this issue. Google code seems to let you just switch the license, so I switched it to EPL 1.0. On Tuesday, 4 June 2013 21:24:49 UTC+1, Gary Trakhman wrote: > > Just fyi, most clojure libs are published under EPL or Apache licenses, of > course the choice is up to you :-). GPL has some restrictions that would > prevent the lib from being used in many projects. > > from the EPL wikipedia page: 'The EPL 1.0 is not > compatible<http://en.wikipedia.org/wiki/License_compatibility> with > the GPL, and a work created by combining a work licensed under the GPL with > a work licensed under the EPL cannot be lawfully distributed.' > > Since clojure itself is EPL, not sure what the implications are. > > Seems like apache is compatible, but only in one direction. The project > would have to be itself GPL. > > > On Tue, Jun 4, 2013 at 4:14 PM, Denis Labaye > > wrote: > >> Idea seems great but no screenshots? Too bad for a visual tool >> >> >> On Tue, Jun 4, 2013 at 10:13 PM, Andrea Chiavazza >> >> > wrote: >> >>> Alpacas is an application that displays Clojure source code with forms >>> shown as nested boxes, doing away with parenthesis altogether. >>> Run it with "lein run" and it will display its own source code. >>> There is partial support to navigate the source code by moving a cursor >>> with the left and right arrows. >>> >>> Obviously the idea would be to be able to edit the source rather than >>> just viewing it. Some clever key combinations or even the mouse might help >>> accomplish that. >>> It is still a proof-of-concept and not very useful at the moment, but I >>> think it might turn into something useful, or even innovative shall >>> somebody decide to put some effort into it. >>> >>> I didn't work at it in a while but I decided to publish it (under GPL) >>> so as to be able to include it in my cv (you can mail me at >>> ndrc...@gmail.com for Clojure job offers). >>> >>> It is hosted at: https://code.google.com/p/alpacas/ >>> >>> -- >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com . >>> For more options, visit https://groups.google.com/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 clo...@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com . >> For more options, visit https://groups.google.com/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.
[ANN] alpacas: a new Clojure source viewer
Alpacas is an application that displays Clojure source code with forms shown as nested boxes, doing away with parenthesis altogether. Run it with "lein run" and it will display its own source code. There is partial support to navigate the source code by moving a cursor with the left and right arrows. Obviously the idea would be to be able to edit the source rather than just viewing it. Some clever key combinations or even the mouse might help accomplish that. It is still a proof-of-concept and not very useful at the moment, but I think it might turn into something useful, or even innovative shall somebody decide to put some effort into it. I didn't work at it in a while but I decided to publish it (under GPL) so as to be able to include it in my cv (you can mail me at ndrch...@gmail.com for Clojure job offers). It is hosted at: https://code.google.com/p/alpacas/ -- -- 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: clojure.set/intersection can't cope with infinite sets
I can see the points being made, and now I'm also thinking that accepting
infinite sequences wouldn't always work, for example if the infinite
sequence wouldn't contain one of the elements of one of the other
sequences, like:
(clojure.set/intersection #{1 2} (drop 10 (range)))
And I'm not sure it would be acceptable for a function that accepts
sequences to hang depending on the input.
Which also makes me wonder: shouldn't intersection throw a "cannot be cast
to clojure.lang.IPersistentSet" when called with (range), rather than
consume all memory and crash the jvm ?
I still think though that accepting sequences rather then sets could be
worth consideration for other reasons:
- vectors would just work without having to call set on them:
(clojure.set/intersection
[2 3 4] [4 5 6]) (I think duplicate elements shouldn't cause problems)
- it would also work on maps
- sets can be treated as sequences, and operating on sequences whenever
possible is very idiomatic in Clojure
- no previous code would be broken, neither should performance decrease and
maybe increase by removing the calls to count
- the doc would simply change to "Returns a set with the elements in common
between the input seqs."
- the implementation would call contains? if the sequence is a set, for
performance reasons, and would call (some #{el} seq) otherwise
--
--
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.
clojure.set/intersection can't cope with infinite sets
Currently this hangs, makes my machine quickly run out of memory and swap.
(clojure.set/intersection #{1 2} (range))
The problem seems to be that count is called on both arguments to find the
smallest set.
Finding the shortest of 2 seqs lazily shouldn't be a problem, but another
problem I can spot would be that contains? should be used only for some
data structures, like hash-set, otherwise I guess "some" could be used,
which would do the right thing, like in:
(some #{1} (range))
1
(some #{2} (range))
2
At this point execution will stop and return the #{1 2} as all elements of
the smallest set have been tested.
Would it be possible and worth the added complication to fix this ?
There could also be some potential performance improvements, for example
removing count might be slightly more efficient when big sets are involved.
I came up with this while trying to solve 4clojure #108 "find the smallest
single number which appears in all of the sequences".
My approach to the 4clojure problem might be wrong altogether, yet I can
imagine removing this limitation could be useful for some real problems 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: == is not always transitive
>
> I must agree that the behaviour of == is not correct here.
The problem is in this method in Numbers.java:
public boolean equiv(Number x, Number y){
return toBigDecimal(x).equals(toBigDecimal(y));
}
The behaviour we currently have is:
user=> (let [ones [1 1.0 1N 1M 1.0M 1.00M] ] (doseq [a ones b ones]
(println a "==" b \tab (== a b) )))
1 == 1 true
1 == 1.0 true
1 == 1N true
1 == 1M true
1 == 1.0M false
1 == 1.00M false
1.0 == 1 true
1.0 == 1.0 true
1.0 == 1N true
1.0 == 1M true
1.0 == 1.0M true
1.0 == 1.00M true
1N == 1 true
1N == 1.0 true
1N == 1N true
1N == 1M true
1N == 1.0M false
1N == 1.00M false
1M == 1 true
1M == 1.0 true
1M == 1N true
1M == 1M true
1M == 1.0M false
1M == 1.00M false
1.0M == 1 false
1.0M == 1.0 true
1.0M == 1N false
1.0M == 1M false
1.0M == 1.0M true
1.0M == 1.00M false
1.00M == 1 false
1.00M == 1.0 true
1.00M == 1N false
1.00M == 1M false
1.00M == 1.0M false
1.00M == 1.00M true
I propose we change the method to be:
public boolean equiv(Number x, Number y){
return toBigDecimal(x).compareTo(toBigDecimal(y)) == 0;
}
This makes the previous expression return all true, and == should also be
transitive.
In particular, (== 1.0M 1.00M) will be true rather than false, which is
much more in the spirit of ==.
The difference between 1.0M and 1.00M should be checked by calling the
scale() method, which makes sense because it is quite an unusual thing to
do.
I also noticed in test_clojure/numbers.clj the lines:
; TODO:
; ==
; and more...
So I thought of also adding the test:
(deftest equality
(are [x y] (== x y)
4242
4242.0
4242N
4242M
4242.0M
4242.00M
42.0 42
42.0 42.0
42.0 42N
42.0 42M
42.0 42.0M
42.0 42.00M
42N 42
42N 42.0
42N 42N
42N 42M
42N 42.0M
42N 42.00M
42M 42
42M 42.0
42M 42N
42M 42M
42M 42.0M
42M 42.00M
42.0M 42
42.0M 42.0
42.0M 42N
42.0M 42M
42.0M 42.0M
42.0M 42.00M
1.23 1.23
1.23 1.23M
1.23M 1.23
1.23M 1.23M )
(are [x y] (not (== x y))
12 12.1
1.23 123
34 3.4
1.23 1.234
123N 345N
123 345N
123N 345
12.34M 456N
12.34M 4.56
12.34 4.56M
12 4.56M
12M 4.56
12.34M 1.234M ))
I think it would be really nice to get this fixed before the 1.4 release.
The changes above can be found at
https://github.com/andrea-chiavazza/clojure/tree/BigDecimal-equiv-fix
Can anybody defend the current behaviour against the one I propose ?
--
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: New(er) Clojure cheatsheet hot off the presses
Would you consider removing the underlining from all links ? > > I think it would look much better, -- 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
Support for complex numbers added
Hello everyone I had a go at adding support for complex numbers, it's at: https://github.com/andrea-chiavazza/clojure/tree/complex Some repl usage examples: user=> (/ (complex 73 13) (complex 15 25)) # user=> (/ (complex 73 13) (complex 15.0 25.0)) # user=> (+ (complex 13 34) (complex 29 -34)) 42 user=> (require 'clojure.math) user=> (clojure.math/abs (complex -14.94 21)) 25.772147756832375 user=> (clojure.math/sqrt -3) # user=> (clojure.math/sqrt 2) 1.4142135623730951 user=> (clojure.math/sqrt (complex 2 3)) # user=> (= (complex 12 34) (complex 12 34.0)) false user=> (== (complex 12 34) (complex 12 34.0)) true I'm still not sure why #http://groups.google.com/group/clojure?hl=en
