Re: crossclj.info unavailable ???

[Andy Fingerhut]

The creator of the site announced on on 2018-Dec-22 that he would be
shutting it down:
https://www.reddit.com/r/Clojure/comments/a99jwn/crossclj_is_shutting_down/


The issue is not lack of funds, but lack of his time/interest to continue
updating it, and not wanting it to gradually become more and more out of
date.

He has published the source code he used to generate the site, but note
that it is not always a simple push-and-click to update the site to index
later versions of source code -- the analysis programs sometimes require
updating and/or bug fixing in order to work on new code bases.

Anyone sufficiently interested could set up another similar site, perhaps
starting from the existing published code.  I suspect the original
publisher would be willing to transfer the domain if you wanted to use the
same domain name, but you would have to contact them to know for sure.

Andy


On Wed, Feb 6, 2019 at 3:38 PM Alan Thompson  wrote:

> Trying to hit http://crossclj.info (Ubuntu 16.04 + Chrome) yields:
>
>
> This site can’t provide a secure connection
>
> *crossclj.info * sent an invalid response.
> ERR_SSL_PROTOCOL_ERROR
>
> --
> 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.

crossclj.info unavailable ???

[Alan Thompson]

Trying to hit http://crossclj.info (Ubuntu 16.04 + Chrome) yields:


This site can’t provide a secure connection

*crossclj.info * sent an invalid response.
ERR_SSL_PROTOCOL_ERROR

-- 
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] nREPL 0.6

[Rostislav Svoboda]

> I’ve done 0 work on this release

Out of Earth's population 7,682,276,358 there's not more than 10K aof
people being capable of doing the "0 work" on this release.
So: One big and great: Thank You All Guys!

Bost

PS: On the other hand: NOBODY, not even the comrade Stalin is so
great, not fit in a coffin... :)

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

[Q] How to load Clojure as part of Wildfly module?

[henrik42]

Hi,

I'm working on a "proxying JDBC driver" in Clojure [1]. Everything is
working fine. But I had one problem with the way Clojure
(i.e. clojure.lang.RT) manages its classloader.

When Wildfly loads my UBERJAR which contains Clojure and
loads/instanciates my gen-class `buttle.jdbc.Driver` then its static
initializer will load `clojure.lang.RT`. At this point the current
thread's context classloader (TCCL; which is put into place by
Wildfly) does NOT point to the one that is loading my code and the
TCCL in-fact does not "see" my classes.

So when Clojure/RT then tries to find `clojure/core.clj` it fails
because Clojure uses the TCCL for loading [2]. I could try to set
`clojure.core/*use-context-classloader*` to false but this leads to a
chicken-egg-problem since for doing that, `clojure.lang/RT` would have
to be loaded in the first place. 

So my question is: is there a nice way out of this?

The workaround I came up with was to compile a Java class [3] which is
the super class of my gen class [4]. And since static initializers are
called in order super-class->derived-class the static initializer of
the super-class is used to set the TCCL to the one that loads my code
base. After that Clojure finds clojure/core.clj without problems.

Any ideas on how to do without this hack?

Henrik

[1] https://github.com/henrik42/buttle/
[2] 
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L2174
[3] 
https://github.com/henrik42/buttle/blob/master/java/buttle/SetContextClassLoaderInStaticInitializer.java
[4] https://github.com/henrik42/buttle/blob/master/src/buttle/driver.clj#L29

-- 
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, JVM and/or ASM bug?

[Alex Miller]

Without spending more time poking around, it's hard for me to say exactly 
what the problem is, and whether it's a bug, enhancement, or won't fix. 
Having written a lot of Clojure code in the 8 or 9 years, I've run into 
head holding problems a couple times maybe. In general, it's usually not an 
issue (and it's usually pretty obvious that something's wrong). In general, 
I would not be afraid of lazy seqs just because of this. Locals are 
automatically cleared, avoiding head holding, in the vast majority of cases 
you typically run into.

On Wednesday, February 6, 2019 at 12:27:21 PM UTC-6, Lars Rune Nøstdal 
wrote:
>
>
>
> On Wednesday, February 6, 2019 at 5:15:53 PM UTC+2, Alex Miller wrote:
>>
>> I think the condition here means that the loop compilation can't tell 
>> that the s local is definitely out of scope and can be cleared, so you end 
>> up holding the head.
>>
>> While there is some analysis here, we're not doing inference level stuff 
>> on the "if false" to knock out branches etc and generally that's not the 
>> kind of thing we try to do.
>>
>
> I.e. WONTFIX? Using lazy sequences is or can be pretty dangerous without 
> plenty and frequent testing, then -- since "don't hold onto the head" means 
> one will have to take into account whatever code the compiler and/or 
> libraries (c.c.async?) may or may not generate behind the scenes based on 
> subtleties. 
>
> H ...anyway, I'll try to work around this; perhaps by avoiding lazy 
> sequences altogether. For me switching to clojure.core.async and doing 
> something like this *seems* to have worked (perhaps useful for others who 
> find this thread later):
>
>- wrap the range (or infinite or long sequence really) in a *source* 
>chan .
>- do the transformation in a *middle* chan; noting that the chan Fn 
>takes an xform arg.
>- pipe  the *middle* chan 
>to your final *output* chan. something like: *(async/pipe 
>(handle-source-chan (async/chan 1000 xform) ...) output-chan)*
>
> ...it's a bit tricky to setup -- but yeah; no leaks here for now. It's 
> interesting that I have a sort of more explicit buffer in the *middle* chan 
> I can fiddle around with too now!
>
> Mvh, Lars
>
>  
>
>>
>>
>> On Wednesday, February 6, 2019 at 7:57:57 AM UTC-6, Lars Rune Nøstdal 
>> wrote:
>>>
>>> Hi, so I've been staring at this for hours :
>>>
>>>
>>> (defn foo []
>>>   (let [s (range)]
>>> (if false
>>>   nil
>>>   (future
>>> (loop [s s]
>>>   (recur (rest s)))
>>>
>>>
>>> ...if I run this I run out of heap space quite fast on any of these:
>>>
>>>- Clojure: "1.11.0-master-SNAPSHOT", 1.9.0, 1.8.0 or 1.7.0
>>>- OpenJ9 0.12.1 or Oracle 11.0.2 2018-10-16 LTS
>>>
>>>
>>> ..that's what I have at hand for testing for now. If I remove the FUTURE 
>>> or place it higher up the stack it doesn't happen. I looked at a heap dump 
>>> in MAT and it seems to contain millions of empty stack frames or binding 
>>> frames (conveyor?); all held together by circular references (AFAICT).
>>>
>>> -- 
>>> Mvh, Lars Rune Nøstdal
>>> https://www.quanto.ga/
>>>
>>>

-- 
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, JVM and/or ASM bug?

[Lars Rune Nøstdal]

On Wednesday, February 6, 2019 at 5:15:53 PM UTC+2, Alex Miller wrote:
>
> I think the condition here means that the loop compilation can't tell that 
> the s local is definitely out of scope and can be cleared, so you end up 
> holding the head.
>
> While there is some analysis here, we're not doing inference level stuff 
> on the "if false" to knock out branches etc and generally that's not the 
> kind of thing we try to do.
>

I.e. WONTFIX? Using lazy sequences is or can be pretty dangerous without 
plenty and frequent testing, then -- since "don't hold onto the head" means 
one will have to take into account whatever code the compiler and/or 
libraries (c.c.async?) may or may not generate behind the scenes based on 
subtleties. 

H ...anyway, I'll try to work around this; perhaps by avoiding lazy 
sequences altogether. For me switching to clojure.core.async and doing 
something like this *seems* to have worked (perhaps useful for others who 
find this thread later):

   - wrap the range (or infinite or long sequence really) in a *source* chan 
   .
   - do the transformation in a *middle* chan; noting that the chan Fn 
   takes an xform arg.
   - pipe  the *middle* chan 
   to your final *output* chan. something like: *(async/pipe 
   (handle-source-chan (async/chan 1000 xform) ...) output-chan)*

...it's a bit tricky to setup -- but yeah; no leaks here for now. It's 
interesting that I have a sort of more explicit buffer in the *middle* chan 
I can fiddle around with too now!

Mvh, Lars

 

>
>
> On Wednesday, February 6, 2019 at 7:57:57 AM UTC-6, Lars Rune Nøstdal 
> wrote:
>>
>> Hi, so I've been staring at this for hours :
>>
>>
>> (defn foo []
>>   (let [s (range)]
>> (if false
>>   nil
>>   (future
>> (loop [s s]
>>   (recur (rest s)))
>>
>>
>> ...if I run this I run out of heap space quite fast on any of these:
>>
>>- Clojure: "1.11.0-master-SNAPSHOT", 1.9.0, 1.8.0 or 1.7.0
>>- OpenJ9 0.12.1 or Oracle 11.0.2 2018-10-16 LTS
>>
>>
>> ..that's what I have at hand for testing for now. If I remove the FUTURE 
>> or place it higher up the stack it doesn't happen. I looked at a heap dump 
>> in MAT and it seems to contain millions of empty stack frames or binding 
>> frames (conveyor?); all held together by circular references (AFAICT).
>>
>> -- 
>> Mvh, Lars Rune Nøstdal
>> https://www.quanto.ga/
>>
>>

-- 
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, JVM and/or ASM bug?

[Alex Miller]

I think the condition here means that the loop compilation can't tell that 
the s local is definitely out of scope and can be cleared, so you end up 
holding the head.

While there is some analysis here, we're not doing inference level stuff on 
the "if false" to knock out branches etc and generally that's not the kind 
of thing we try to do.


On Wednesday, February 6, 2019 at 7:57:57 AM UTC-6, Lars Rune Nøstdal wrote:
>
> Hi, so I've been staring at this for hours :
>
>
> (defn foo []
>   (let [s (range)]
> (if false
>   nil
>   (future
> (loop [s s]
>   (recur (rest s)))
>
>
> ...if I run this I run out of heap space quite fast on any of these:
>
>- Clojure: "1.11.0-master-SNAPSHOT", 1.9.0, 1.8.0 or 1.7.0
>- OpenJ9 0.12.1 or Oracle 11.0.2 2018-10-16 LTS
>
>
> ..that's what I have at hand for testing for now. If I remove the FUTURE 
> or place it higher up the stack it doesn't happen. I looked at a heap dump 
> in MAT and it seems to contain millions of empty stack frames or binding 
> frames (conveyor?); all held together by circular references (AFAICT).
>
> -- 
> Mvh, Lars Rune Nøstdal
> https://www.quanto.ga/
>
>

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

Clojure, JVM and/or ASM bug?

[Lars Rune Nøstdal]

Hi, so I've been staring at this for hours :


(defn foo []
  (let [s (range)]
(if false
  nil
  (future
(loop [s s]
  (recur (rest s)))


...if I run this I run out of heap space quite fast on any of these:

   - Clojure: "1.11.0-master-SNAPSHOT", 1.9.0, 1.8.0 or 1.7.0
   - OpenJ9 0.12.1 or Oracle 11.0.2 2018-10-16 LTS


..that's what I have at hand for testing for now. If I remove the FUTURE or 
place it higher up the stack it doesn't happen. I looked at a heap dump in 
MAT and it seems to contain millions of empty stack frames or binding 
frames (conveyor?); all held together by circular references (AFAICT).

-- 
Mvh, Lars Rune Nøstdal
https://www.quanto.ga/

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

trying a functional solution for a recurrent problem

[Pierpaolo Tofani]

Hi
I am trying a functional solution for a recurrent problem.
I must balance 2 vectors :

I must pass from A1 to A2 with following  priority: assign aval qty first 
for records with the same :cat , then to needs in early :day.
Thanking in advance for any kind of help.
PS
:day in format AAAMMDD

(def A1
  {:avail [
   {:day 20190101 :qty  10  :mkey "AAABB" :cat "CO1"}
   {:day 20190101 :qty  20  :mkey "OS100" :cat "CO1"}
   {:day 20190102 :qty  50  :mkey "OS200" :cat "   "}
   {:day 20190103 :qty  50  :mkey "OS300" :cat "   "}
   {:day 20190104 :qty  40  :mkey "OS400" :cat "   "}
   ]
   :needs [
   {:day 20190107 :qty -100 :mkey "OS200" :cat "   "}
   {:day 20190108 :qty  -50 :mkey "OS300" :cat "   "}
   {:day 20190109 :qty -100 :mkey "OS400" :cat "   "}
   {:day 20190217 :qty -100 :mkey "OS100" :cat "CO1"}
   ]
   }
  )

after

(def A2
  {:avail [
   {:day 20190101 :qty  0   :mkey "AAABB" :cat "CO1"}
   {:day 20190101 :qty  0   :mkey "OS100" :cat "CO1"}
   {:day 20190102 :qty  0   :mkey "OS200" :cat "   "}
   {:day 20190103 :qty  0   :mkey "OS300" :cat "   "}
   {:day 20190104 :qty  0   :mkey "OS400" :cat "   "}
   ]
   :needs [
   {:day 20190107 :qty 0:mkey "OS200" :cat "   "}
   {:day 20190108 :qty -10  :mkey "OS300" :cat "   "}
   {:day 20190109 :qty -100 :mkey "OS400" :cat "   "}
   {:day 20190217 :qty -70  :mkey "OS100" :cat "CO1"}
   ]
   }
  )



-- 
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] nREPL 0.6

[Bozhidar Batsov]

Good news, everyone!

We’ve just released nREPL 0.6 and it’s going to rock your REPL world! :-)


It’s a really important release that brings a simplified and more robust
code evaluation model, support for streaming output (that’s extremely
big!), a new way to hook into evaluation errors and many more small tweaks
and improvements. Special thanks to Christophe Grand and Michael Griffiths
who carried out the bulk of the work in this release! You can find the
complete release notes here
https://github.com/nrepl/nrepl/releases/tag/0.6.0 The project’s website
https://nrepl.org will very soon be updated to reflect the new release as
well.


This release is the perfect embodiment of the beautiful OSS idea that when
you’ve got a great community everything is possible. I’ve done 0 work on
this release other that writing this announcement and reviewing a few PRs.
:-) As far as I’m concerned we’re moving in the right direction!

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