This is the first alpha release of my new library! Comments welcome.
Clojure has an extensive system for dealing with numbers, including
error on overflow, or auto-promotion, defaulting to long and double data
types.
This is all well and good, but irritating if you need to implement an
algorith
Hi Phillip,
I've had a very quick look at the code and I've spotted a few issues, here's my
feedback:
1- all your functions will cause input args and return value to be boxed.
There's a few ways to avoid it, none of which are particularly pretty. If your
library is not worried about performanc
This seems quite similar to https://github.com/ztellman/primitive-math. Did
you know about it?
On Monday, July 3, 2017 at 11:44:40 AM UTC+2, Phillip Lord wrote:
>
>
>
> This is the first alpha release of my new library! Comments welcome.
>
> Clojure has an extensive system for dealing with numbe
Hi all,
How to maintain an internal tools library parallel to writing a Clojure
app? Having a separate Emacs open with that project + releasing +
installing it after every small change seems to be a big hassle to me. What
are the best practices of this? For example adding the source path of the
this article may be helpful:
http://insideclojure.org/2014/12/15/warn-on-boxed/
On 3 July 2017 at 13:36, Tomasz Sulej wrote:
> When you decide to work with longs and doubles you can achieve the same in
> pure clojure
> Just add primitive type hints and (set! *unchecked-math* true).
> (to see if
Nicola Mometto writes:
> Hi Phillip,
>
> I've had a very quick look at the code and I've spotted a few issues,
> here's my feedback:
>
> 1- all your functions will cause input args and return value to be
> boxed. There's a few ways to avoid it, none of which are particularly
> pretty. If your lib
Nicola Mometto writes:
> Hi Phillip,
>
> I've had a very quick look at the code and I've spotted a few issues,
> here's my feedback:
>
> 1- all your functions will cause input args and return value to be
> boxed. There's a few ways to avoid it, none of which are particularly
> pretty. If your lib
Yes, but it doesn't supoort ints for all the operators, as far as I can
tell.
You are right, though, perhaps I should look at this also.
Phil
Max Penet writes:
> This seems quite similar to https://github.com/ztellman/primitive-math. Did
> you know about it?
>
> On Monday, July 3, 2017 at 11
https://github.com/metosin/spec-tools
spec-tools is is a small Clojure(Script) library adding some batteries for
clojure.spec, including: Schema-like runtime coercion, Spec visitors, JSON
Schema generation and macro-free data-specs.
0.3.0 adds support for Swagger2 Schema generation, merged from
The checkouts feature of Leiningen exists to support this scenario.
https://github.com/technomancy/leiningen/blob/master/doc/TUTORIAL.md#checkout-dependencies
On Sun, Jul 2, 2017 at 11:40 AM, István Dévai
wrote:
> Hi all,
>
> How to maintain an internal tools library parallel to writing a Cloju
Leningen has checkout dependencies for this purpose:
https://github.com/technomancy/leiningen/blob/master/doc/TUTORIAL.md#checkout-dependencies
Vitalie
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to cloju
Hi,
Async/close! causes deadlocks if its reducer is stalled (e.g. waits for an
event from
another chan).
Consider:
(let [d (chan)
s (chan 1 (map (fn [v]
(println "this:" v)
(println "from d:" (! s 1))
(Thread/sleep 100)
(pri
Transducers on channels lock the channel while they are running. This is by
design. So yes, the side-effect of this means that no other operation
(puts, takes or closes) can succeed while the transducer is running.
So the short answer is: If you have code that can take awhile to run, don't
put it
On 07/03/2017 11:03 AM, Vitalie Spinu wrote:
Hi,
Async/close! causes deadlocks if its reducer is stalled (e.g. waits for
an event from
another chan).
Consider:
(let [d (chan)
s (chan 1 (map (fn [v]
(println "this:" v)
(printl
> the side-effect of this means that no other operation (puts, takes or
closes)
Is there a deeper reason for this beside the ease of implementation?
If chan is buffered I still fail to see why should close and take block.
--
You received this message because you are subscribed to the Googl
On Monday, 3 July 2017 22:48:40 UTC+2, red...@gmail.com wrote:
>
>
> Discussion of locks aside, doing blocking operations like io or >!! or basically anything that looks like it blocks and isn't >! or is a very bad idea in a transducer on a channel. You will (eventually)
> block the threadpo
On 07/03/2017 03:12 PM, Vitalie Spinu wrote:
On Monday, 3 July 2017 22:48:40 UTC+2, red...@gmail.com wrote:
Discussion of locks aside, doing blocking operations like io or !! or basically anything that looks like it blocks and isn't >!
or Is this the limitation in general or only whe
I ran a short survey for java.jdbc users to gauge feeling about dropping
support for Clojure versions prior to 1.7 (so I could add reducible queries
without worrying about CollReduce vs IReduceInit vs IReduce).
So far, 68 people have taken the survey and the results are overwhelmingly in
fav
A big reason they have to be run inside the lock is that they have to
operate in the context of the channel.
For example:
(chan (take 10))
Firstly we must recognize that transducer instances are *not* thread safe.
They should only ever be executed by one thread at a time. But channels
allow mult
By the way, if you do use checkouts with Figwheel, be aware of
https://github.com/bhauman/lein-figwheel/issues/9. Currently you need to
add the path to the checkout project into your cljsbuild :source-paths.
On Tue, Jul 4, 2017 at 8:16 AM Vitalie Spinu wrote:
>
> Leningen has checkout dependenci
20 matches
Mail list logo
