Re: printing self referential data?

2017-07-24 Thread Justin Smith
One important thing to be aware of that I should have mentioned when
suggesting the adjacency list solution is the rationale for using that
representation. When you put atoms in the nodes of your data structure,
it's no longer an immutable data structure and you lose the usage patterns
that clojure provides for other idiomatic data. For example if you call
update or assoc you get a new data structure back that shares the same
mutable atoms under the unmodified keys, which means that any modifications
are reflected in all the other contexts the data is used. Of course you
could (and probably should) also use defensive copying, but then you need
some method of handling the cycles when copying ... in the big picture it's
much simpler to use the adjacency list format which preserves the usage
style we are used to with other clojure data.

On Mon, Jul 24, 2017 at 7:12 AM Rob Nikander  wrote:

> I think in my case here the easiest thing will be to remove the cycles,
> but still I'd like to understand a couple things...
>
>
> On Sunday, July 23, 2017 at 10:12:46 PM UTC-4, Didier wrote:
>>
>> I'm not sure I can fully help without you explaining more what you're
>> doing. It sounds like you've got a collection or container type which has
>> an implementation of print that loops over its elements, and calls print on
>> them. So if you have a cycle, the print will go on forever until memory
>> runs out.
>>
>
> My container type (the tree node) is simply the standard clojure map.
>
> If you're using a standard type, you might be able to limit *print-level*
>> . Most Clojure
>> collections will limit how deep they print based on the value of this
>> global dynamic Var.
>>
>
> Okay, *print-level* works but it looks like I have to call print myself. I
> can't rely on the REPL to print it.
>
> (binding [*print-level* 2] (println (find-route "/reports")))   ; okay
>
> Why does `alter-var-root` here seem to succeed, but have no effect?
>
> (alter-var-root #'*print-level* (constantly 2))
> => 2
> *print-level*
> => nil
> (find-route "/reports")
> stack overflow
>
>
>
> --
> 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.
>

-- 
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] inspectable 0.1.0 Improve your repl experience when using clojure.spec

2017-07-24 Thread Juan Monetta
What?

A couple of tools for Clojure to help you work with clojure.spec in the 
repl with the spirit of improving error
messages.

Where?

[inspectable "0.1.0"]
https://github.com/jpmonettas/inspectable

Summary?

Inspectable 0.1.0 contains two tools

- borwse-spec : A GUI spec registry browser.
- why : A GUI that explains spec fails in a bunch of different situations.

-- 
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: printing self referential data?

2017-07-24 Thread Rob Nikander
I think in my case here the easiest thing will be to remove the cycles, but 
still I'd like to understand a couple things...

On Sunday, July 23, 2017 at 10:12:46 PM UTC-4, Didier wrote:
>
> I'm not sure I can fully help without you explaining more what you're 
> doing. It sounds like you've got a collection or container type which has 
> an implementation of print that loops over its elements, and calls print on 
> them. So if you have a cycle, the print will go on forever until memory 
> runs out.
>

My container type (the tree node) is simply the standard clojure map. 

If you're using a standard type, you might be able to limit *print-level* 
> . Most Clojure 
> collections will limit how deep they print based on the value of this 
> global dynamic Var.
>

Okay, *print-level* works but it looks like I have to call print myself. I 
can't rely on the REPL to print it. 

(binding [*print-level* 2] (println (find-route "/reports")))   ; okay

Why does `alter-var-root` here seem to succeed, but have no effect?

(alter-var-root #'*print-level* (constantly 2))
=> 2
*print-level*
=> nil
(find-route "/reports")
stack overflow

 

-- 
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: int arguments for Java annotations

2017-07-24 Thread Joe Littlejohn
Sorry, to be clear, when I say 'thoughts on how this could be solved in 
Clojure', I mean changes in the core that would allow this to work in a 
future version of Clojure :)


On Sunday, 23 July 2017 21:14:23 UTC+1, Joe Littlejohn wrote:
>
> Hi all,
>
> I recently used Clojure to create a Java interface and class (via 
> definterface/deftype) that both required Java annotations. I was within 
> striking distance of my goal, but was finally caught out by the fact that 
> although Clojure has a nice Java annotation syntax, one cannot currently 
> supply an int argument to a Java annotation.
>
> This same issue is described here:
>
>
> https://stackoverflow.com/questions/18280626/clojure-annotations-and-integers
>
> It seems a shame that the Java annotations support in Clojure is very 
> useful and capable yet has an Achilles' heel.
>
> Does anyone have any thoughts about how this could be solved in Clojure?
>

-- 
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: Reducing Jar file size for AWS Lambda

2017-07-24 Thread Kimmo Koskinen
Hi!

Not yet Clojars -ready so lein install for now. There is also #portkey on 
Clojurians Slack for chatting. Happy hacking! :)

- Kimmo

maanantai 24. heinäkuuta 2017 8.24.29 UTC+3 Jose Trigueros kirjoitti:
>
> This looks like a viable solution! Is Portkey on Clojars or will I have to 
> build myself? Not a problem either way, just making sure I'm doing it 
> right. Thanks Kimmo.
>
> On Sunday, July 23, 2017 at 2:35:37 AM UTC-6, Kimmo Koskinen wrote:
>>
>> Hi!
>>
>> Although still at early stages, check out portkey 
>> https://github.com/cgrand/portkey. 
>>
>> Portkey does tree-shaking by starting from a closure to minimize 
>> resulting jar size. Uses kryo and implementation of var tracing started in 
>> powderkeg project (https://github.com/HCADatalab/powderkeg)
>> . 
>>
>> pk/deploy can lift (an anonymous) function with [in out ctx] args as a 
>> Lambda function. pk/mount can expose a defn through API gateway with query 
>> params mapped to function arguments. 
>>
>> Christophe Grand and I have been working on portkey for now, but we'd 
>> welcome additional help on making it more awesome :) 
>>
>> - Kimmo
>>
>>

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