Re: [ANN] Deploy tokens now required for Clojars

[Arnout Roemers]

Thanks for the heads-up!

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

Re: [ANN] clj-new -- creating new Clojure projects using the clj CLI

[Arnout Roemers]

Nice work! Another addition to the CLI tools ecosystem.

Maybe worth mentioning that a oneliner may suffice, for those just wanting 
to try it out without altering the global deps.edn:

clj -Sdeps '{:deps {seancorfield/clj-new {:git/url 
"https://github.com/seancorfield/clj-new; :sha 
"492bb2e7ad7373a8b5958124a86cddc4c7a123d5"}}}' -m clj-new.create ...


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

Idea: standardised way of packaging docs inside jar

[Arnout Roemers]

Hi all,

This is a copy from the question I posed at codox 
:

I was thinking that maybe a good addition to the Clojure documentation 
ecosystem would be to have a standardised way of including project 
documentation inside the project artefact (JAR). This documentation could 
then be searched and read locally (and offline!), and could also be 
aggregated on any of the community websites. So, in short, a kind of Ruby's 
rdoc for Clojure.

I think the input (and maybe also the output?) of Codox is great for this. 
Maybe a good standard would be to put this in a META-INF/codox directory?

How do others feel about this? Does something like this exist already, and 
did I just miss it? I'd love to hear!


Cheers,


Arnout

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

Re: Library suggestions requested for clojure-toolbox.com

[Arnout Roemers]

{:name "functionalbytes/rmap"
 :description "Define literal lazy, recursive maps - plus extras"
 :URL "https://github.com/aroemers/rmap;
 :category "Data Structures"}

Op maandag 5 oktober 2015 21:41:11 UTC+2 schreef James Reeves:
>
> If you've written or know about a Clojure or ClojureScript library, and 
> it's not already on clojure-toolbox.com , 
> I'd like to hear about it.
>
> Post the name and URL (and an optional category) as reply to this message, 
> and I'll add it to the site.
>
> - James
>

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

Re: [ANN] rmap - define lazy, recursive maps

[Arnout Roemers]

Hi all,

I would like to announce a new version 0.4.0 of rmap.

The library internals have changed to a simpler and more memory efficient 
model (i.e. the LinkedHashMap is gone). This model also allows adding new 
lazy entries to a recursive map and merging them.

In addition to that, this version supports a new realization mode: *structural 
sharing* of the lazy values. When enabled, realizing an entry in a 
recursive map means that all structurally shared recursive maps that still 
have this entry will have it realized as well. This mode has to be enabled 
explicitly. More on this can be read in the API documentation 
https://github.com/aroemers/rmap#the-api.

Cheers,

Arnout Roemers
Functional Bytes http://functionalbytes.nl

Op vrijdag 10 oktober 2014 10:55:53 UTC+2 schreef Arnout Roemers:

 Hi Ben,

 That's pretty nifty indeed! Maybe a tad memory intensive as it retains the 
 head, but if it were a more complex, CPU intensive calculation in :next, 
 that might be very worthwhile. Good stuff.

 Cheers,
 -Arnout

 P.S. The memory consumption will be a little less when I think of a way to 
 efficiently replace the backing LinkedHashMap with an actual persistent 
 map, while keeping track of the evaluation order.

 Op donderdag 9 oktober 2014 02:53:38 UTC+2 schreef Ben:

 This is pretty nifty:

 user= (require '[rmap.core :as rmap])
 nil
 user= (def fibs (rmap/rmap FIBS {:a 0 :b 1 :next (- FIBS (update-in 
 [:a] (constantly (:b FIBS))) (update-in [:b] (constantly (+ (:b FIBS) (:a 
 FIBS)}))
 #'user/fibs
 user= (defn fib [n] (loop [fibs fibs n n] (if (zero? n) (:a fibs) (recur 
 (:next fibs) (dec n)
 #'user/fib
 user= (fib 40)
 102334155



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

Re: [ANN] rmap - define lazy, recursive maps

[Arnout Roemers]

Hi Ben,

That's pretty nifty indeed! Maybe a tad memory intensive as it retains the 
head, but if it were a more complex, CPU intensive calculation in :next, 
that might be very worthwhile. Good stuff.

Cheers,
-Arnout

P.S. The memory consumption will be a little less when I think of a way to 
efficiently replace the backing LinkedHashMap with an actual persistent 
map, while keeping track of the evaluation order.

Op donderdag 9 oktober 2014 02:53:38 UTC+2 schreef Ben:

 This is pretty nifty:

 user= (require '[rmap.core :as rmap])
 nil
 user= (def fibs (rmap/rmap FIBS {:a 0 :b 1 :next (- FIBS (update-in [:a] 
 (constantly (:b FIBS))) (update-in [:b] (constantly (+ (:b FIBS) (:a 
 FIBS)}))
 #'user/fibs
 user= (defn fib [n] (loop [fibs fibs n n] (if (zero? n) (:a fibs) (recur 
 (:next fibs) (dec n)
 #'user/fib
 user= (fib 40)
 102334155



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

Re: [ANN] rmap - define lazy, recursive maps

[Arnout Roemers]

Hi Zach,

Thank you for checking out the library. You were right, some interfaces 
were missing and some methods had not been implemented. Though this was 
documented, they were limitations that could be fixed.

*So, I'd like to announce version 0.2.0.*

This version does implement all the necessary interfaces. Your source of 
def-map-type from Potemkin certainly helped here, although I did not use 
it directly. Nice work by the way. I have tested the current rmap 
implementation with the collection-check library, and it passes. Again, 
nice work, Zach.

I still use a LinkedHashMap as the underlying data structure (as I want to 
keep track of the evaluation order), but I could not break that structure 
like the way you said. It seems to behave fine. Please let me know if you 
do know of a counter example.

P.S. Zach, the README of the collection-check library is not updated with 
the dependency change to test.check.
P.P.S. Still working on a post about the motivation and how it works.

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

Re: [ANN] rmap - define lazy, recursive maps

[Arnout Roemers]

Thank you for your kind responses! I will look into writing a post that 
shows what the motivation was (i.e. how I use it), how it works, and how it 
compares to Prismatic's Graph. 

Cheers,
Arnout

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

[ANN] rmap - define lazy, recursive maps

[Arnout Roemers]

I would like to announce a very little utility library for defining 
recursive maps in Clojure, called rmap.

For example:

(def m
  (rmap X
{:what awesome!
 :clj (str Clojure is  (:what X))})
(:clj m)
;= Clojure is awesome!

An object of type IFn + ILookup + Seqable is currently returned, which 
means it can be used with the core get function, as a function itself 
(taking one or two arguments), with keyword lookups, and all functions 
using seq, such as into. Please let me know (or send a pull request) when 
you need another protocol or interface implemented.

On Clojars: [functionalbytes/rmap 0.1.2]
On Github: https://github.com/aroemers/rmap

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

Re: [ANN] Clojure 1.7.0-alpha2

[Arnout Roemers]

I can understand why something like a clojure.lang.Volatile can be useful 
for some optimizations in the functions of standard library, but do they 
really need to become part of the public core API? Clojure is such a nice 
language because of the way state is handled at a higher level. Whenever I 
use a library, I _know_ the data I'm given is immutable. And whenever I'm 
given a state container such as an atom, I _know_ exactly how I can use it 
and, more importantly, share it. With a volatile container, I don't[1]. 
It's just a plain-old mutable variable, something Clojure rightfully moved 
away from. Sure, an API that returns a volatile should be considered a very 
bad practice, but I think this is still going to happen[2]. Especially by 
those coming to Clojure in the future with a OO background. Understanding 
and maintaining someone else's code might become harder as well.

Having the volatile function as part of the public core API sends the wrong 
message in my opinion. Could you, Cognitect, consider making the volatile 
related functions private, or move them to their own namespace, in order to 
keep Clojure more true to its nature?

[1] This is also a reason why I think the idea of overloading swap! and 
reset! not desirable.
[2] Transients don't have this problem, as they cannot escape their score.

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

Re: Clojure run time isolation with the ability to share data structures

[Arnout Roemers]

Hi Giri,

At my company, we also desired multiple, isolated Clojure runtimes in one 
JVM instance, sharing Clojure data structures/types. So indeed, we also 
created special ClassLoaders in order to do this. We had the same problem 
with some data types being tied to the Clojure runtime somehow. Even more, 
there is also the problem with package protected fields in some of those 
data structure/type classes, causing issues when an isolated 
clojure.lang.RT tries to access a commonly loaded data structure/type. 

Our solution: patch the Clojure runtime. For us, the result is that we can 
share almost anything, including keywords, functions and vars. Our patched 
Clojure can be found at http://github.com/touch/clojure. It is not a tidy 
patch (as the diff shows many whitespace/indent changes), but maybe it is 
of some use to you.

In the long run, we plan to make a tidy patch, and also release our Clojure 
runtime container software as an open source project.

-Arnout

-- 
-- 
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] Instaparse 1.0.0

[Arnout Roemers]

Wow, an amazing parser with good documentation indeed. I had a go myself at 
a parser using a BNF-like syntax as well 
(https://github.com/aroemers/crustimoney), but I guess this project 
supersedes it by far (although my parser does use programmatic data 
structures for the grammar, without using macros, instead of a String). 
Will read the GLL papers as well.

-Arnout

Op woensdag 10 april 2013 09:22:39 UTC+2 schreef sesm het volgende:

 Hi Mark,

 Amazing stuff, I didn't know, that such general parsing techniques even 
 exist!

 One minor comment: it would be nice to add direct links to GLL papers and 
 https://github.com/epsil/gll github repo to save people some googling 
 time.



-- 
-- 
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: Clojure 1.5

[Arnout Roemers]

Great news, congratulations on your release!

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