Re: [BLOG] Understanding Meyvn

2020-09-10 Thread daniel szmulewicz 
*Leiningen versus the Ants* tells the story of a settler determined to
fight an oncoming invasion of soldier ants when all the odds are stacked
against him. The short story regularly features in anthologies alongside
Jack London's survival stories. It conveys the notion that nothing can stop
a colonial master if he is of strong enough character, not even the
calamities of nature. In the classroom, the reading assignment often serves
as preamble to discuss man versus nature, narrative structure and
characterization. The colonial ideology that underpins it? Not so much.

It is not easy for the average person to imagine that an animal, not to
> mention an insect, can think. But now both the European brain of Leiningen
> and the primitive brains of the Indians began to stir with the unpleasant
> foreboding that inside every single one of that deluge of insects dwelt a
> thought. And that thought was: Ditch or no ditch, we'll get to your flesh!


Critical situations first become crises, he explained to his men, when oxen
> or women get excited.


Apologists will demand examination of the text in the context of its time,
its society. Undoubtedly, those were times of euro-centrism, misogyny and
self-professed superiority. But those were also times of dissenting,
progressive voices demanding change, equality, a better world. Those voices
need to be anthologized and discussed in the classroom, too. The empires
may have been undone, but their ideology lingers on, oftentimes implicit
and rampant.

On Fri, Sep 11, 2020 at 12:48 AM movie gique 
wrote:

> I came across "Leiningen vs. the Ants" in a collection of short stories I
> have. Highly recommended!
>
> On Thu, Sep 3, 2020 at 6:44 AM Daniel Szmulewicz <
> daniel.szmulew...@gmail.com> wrote:
>
>> I hope you'll enjoy reading my latest blog post on Meyvn, if only for the
>> historical tidbits around Clojure tooling.
>>
>> "When we we say that Clojure is hosted on the JVM, we often forget the
>> corollary, that Clojure tooling is built on Maven. We'd be forgiven for the
>> oversight: the tooling is good at keeping Maven out of sight. But Maven is
>> everywhere: in Clojars as the repository format, in Boot where Pomegranate
>> is used as the interface for the Maven resolver, in tools.deps which
>> harnesses the Maven resolver directly... Meyvn takes the ubiquity of Maven
>> to its logical conclusion, delegating all tasks to Maven's execution
>> engine."
>>
>> Oh, and did you ever wonder where Leiningen gets its name from? Read on
>> .
>>
>> --
>> 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/21af7406-d013-4846-9f4b-6d1eab0b00aan%40googlegroups.com
>> 
>> .
>>
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/ESdRNo6nL1A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/CAJAnwPkoNneMTYZYu-w_pD3b%3D7gqbx%2BDj5RaOAY%3D3BjCsqr5Gg%40mail.gmail.com
> 
> .
>

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

Re: [BLOG] Understanding Meyvn

2020-09-10 Thread movie gique 
I came across "Leiningen vs. the Ants" in a collection of short stories I
have. Highly recommended!

On Thu, Sep 3, 2020 at 6:44 AM Daniel Szmulewicz <
daniel.szmulew...@gmail.com> wrote:

> I hope you'll enjoy reading my latest blog post on Meyvn, if only for the
> historical tidbits around Clojure tooling.
>
> "When we we say that Clojure is hosted on the JVM, we often forget the
> corollary, that Clojure tooling is built on Maven. We'd be forgiven for the
> oversight: the tooling is good at keeping Maven out of sight. But Maven is
> everywhere: in Clojars as the repository format, in Boot where Pomegranate
> is used as the interface for the Maven resolver, in tools.deps which
> harnesses the Maven resolver directly... Meyvn takes the ubiquity of Maven
> to its logical conclusion, delegating all tasks to Maven's execution
> engine."
>
> Oh, and did you ever wonder where Leiningen gets its name from? Read on
> .
>
> --
> 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/21af7406-d013-4846-9f4b-6d1eab0b00aan%40googlegroups.com
> 
> .
>

-- 
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/CAJAnwPkoNneMTYZYu-w_pD3b%3D7gqbx%2BDj5RaOAY%3D3BjCsqr5Gg%40mail.gmail.com.

Re: core.async buffers alternative backend

2020-09-10 Thread Alex Miller 
I don't actually remember now, but it's possible that when core.async was 
created we were still trying to accommodate an older version of Java before 
some of those existed. That's not an issue now as we only need to support 
Java 1.8+. So, I don't know of any reason these wouldn't be an option. 
Would be happy to see a core.async issue and/or patch (may need to sign the 
CA and become the contributor first).

On Thursday, September 10, 2020 at 8:14:53 AM UTC-5 Jim foo.bar wrote:

> Hi folks, 
>
> `LinkedList` is used as the underlying data-structure for all core.async 
> buffers. However, looking closer reveals that what is really needed is a 
> `Deque` (for its .addFirst/.removeLast methods). So naturally then it 
> begs the question - why not `ArrayDeque` [1]? It should offer superior 
> insertion/removal/traversing performance, and in the context of 
> core.async it will never be resized (if initialised with `n`). 
>
> And since we're on the subject, why not even go crazy with a 
> (thread-safe) `ConcurrentLinkedDeque` [2] ? Leaving the counting 
> complication aside for a moment (something which I wouldn't mind 
> feedback on), having a thread-safe buffer opens up the door to safe 
> buffer snapshots. 
>
> Anything wrong with either of those approaches? Many thanks in advance... 
>
> Kind regards, 
>
> Dimitris 
>
> [1]: 
>
> https://github.com/jimpil/asynctopia/blob/master/src/asynctopia/buffers/array.clj
>  
>
> [2]: 
>
> https://github.com/jimpil/asynctopia/blob/master/src/asynctopia/buffers/thread_safe.clj
>  
>
>
>
>

-- 
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/7ab00670-4768-4738-8f18-77406bd1fdcfn%40googlegroups.com.

core.async buffers alternative backend

2020-09-10 Thread dimitris 

Hi folks,

`LinkedList` is used as the underlying data-structure for all core.async 
buffers. However, looking closer reveals that what is really needed is a 
`Deque` (for its .addFirst/.removeLast methods). So naturally then it 
begs the question - why not `ArrayDeque` [1]? It should offer superior 
insertion/removal/traversing performance, and in the context of 
core.async it will never be resized (if initialised with `n`).


And since we're on the subject, why not even go crazy with a 
(thread-safe) `ConcurrentLinkedDeque` [2] ? Leaving the counting 
complication aside for a moment (something which I wouldn't mind 
feedback on), having a thread-safe buffer opens up the door to safe 
buffer snapshots.


Anything wrong with either of those approaches? Many thanks in advance...

Kind regards,

Dimitris

[1]: 
https://github.com/jimpil/asynctopia/blob/master/src/asynctopia/buffers/array.clj


[2]: 
https://github.com/jimpil/asynctopia/blob/master/src/asynctopia/buffers/thread_safe.clj 




--
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/f03d8fcd-05a7-b151-a9dc-9a200a9b5d9d%40gmail.com.