Re: Why does interruptible-eval from tools.nrepl queue evaluations?

[squeegee]

I suspect it's because queuing up operations is a relatively safe increment 
in convenience over the most naive implementation: having to wait for each 
evaluation to complete before submitting the next. 

Attempting to increasing the convenience further by evaluating expressions 
in parallel incurs the risk that a given evaluation might produce a side 
effect (e.g., a state change) that a later evaluation depends on.

--Steve 

On Wednesday, May 2, 2018 at 6:48:46 AM UTC-4, Carlo Zancanaro wrote:
>
> Hey there! 
>
> With tools.nrepl, if you eval two expressions they get queued up 
> and evaluated in sequence. This means that if I evaluate 
> (Thread/sleep 1), and then immediately evaluate (+ 1 2), then 
> I have to wait ten seconds for the result of 3 to come back. 
>
> Is there a particular reason for this? Given that it's quite easy 
> to make it evaluate them in parallel, I figure there's a reason 
> why it was decided to evaluate them in sequence. 
>
> I have a use-case where I would like to be able to run evaluations 
> in parallel without having to wrap everything in (future ...), so 
> I'm considering writing some middleware to redefine 
> clojure.tools.nrepl.middleware.interruptible-eval/queue-eval to 
> just put things straight on the executor. It seems to work from my 
> limited tests, but are there any reasons why this would break 
> horribly? 
>
> Carlo 
>

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

What does the ref *loaded-libs* do?

[squeegee]

It is there to support the “:reload” and “:reload-all” features of “require” 
and to help separate the concern of loading libs from the concern of tracking 
namespaces.

--Steve

-- 
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: Cyclic namespace dependencies!

[squeegee]

On Friday, December 30, 2016 at 8:59:46 PM UTC-5, puzzler wrote:
>
> On Fri, Dec 30, 2016 at 4:55 PM, Timothy Baldridge  > wrote:
>
>> I can see that, and even spec has this use case. In Spec it's solved by 
>> having both A and B in one namespace and using declare to forward-declare 
>> the constructors (or defns in this case).
>>
>> So I guess the way I see it the tradeoff is a declare and 
>> all-in-one-namespace vs a massive complexity addition to the compiler and 
>> the redefinition of compilation units. The declare method seems like the 
>> cleaner route. 
>>
>>
> I wonder whether there could be something like an `external-declare` that 
> would satisfy Rich's concerns about knowing how to intern unencountered 
> vars, while allowing cyclical references when needed.
>

The macros defined in ‘scarlett.core’ here: 
https://github.com/scgilardi/scarlett are an experiment along those lines.

*scarlett*

Provides macros to declare vars in namespaces other than *ns*

To be used sparingly to overcome otherwise cyclic namespace dependencies

*Usage*

  (ns-declare my-module startup shutdown)

declares my-module/startup and my-module/shutdown

  (declare+ module-a/startup module-b/startup)

declares module-a/startup and module-b/startup


They work by using “declare” after switching to the target namespace using 
“in-ns” (and switching back at the end). They have to be issued at the “top 
level” (as is highly recommended for ns, declare, def, etc.) to be 
effective and they contain code to notify with an exception if they are 
used at other than the top level. (The exception is preferable to silent 
failure or a confusing error message.)


The macros rely on the compiler behavior of handling top-level “do” forms 
in a special way: evaluating each of the contained forms sequentially *at 
the top level*, effectively removing the nesting and allowing each 
contained form to be compiled and evaluated before compiling the next one. 
Macro expansion facilities other than the compiler (e.g., in an editor or 
debugger) may not duplicate that subtle behavior so the expansions they 
produce may not accurately reflect the expansion that will be produced and 
seen by the compiler. There may be contexts where that causes trouble at 
development time.


I’m not aware of these being used anywhere in other than experimental/POC 
code.


—Steve 

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