core.async buffers alternative backend

oment (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/asynctop

ANN: jedi-time 0.2.1

open to feedback. See the README/INTRO [1] for more. Kind regards, Dimitris [1]: https://github.com/jimpil/jedi-time -- 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

ANN: jedi-time 0.2.0

, please consider taking two minutes to report it :). Kind regards, Dimitris [1]: https://github.com/jimpil/jedi-time -- 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

Re: ANN: jedi-time 0.1.4

On 10/02/2020 20:45, Sean Corfield wrote: I’m suggesting that if you add certain key/value pairs to the datafied Java Time values, nav could recognize those as navigation from data to “stuff”. This gets you much closer to your original concept while staying within the datafy/nav confines. The

Re: ANN: jedi-time 0.1.4

. The datafication wouldn't need to add these keys (although, if you wanted an obvious "default" behavior, you could add some) but the navigation would need to recognize them and do the appropriate calculation/conversion. Does that make sense? On Sun, Feb 9, 2020 at 1:46 PM dimitri

Re: ANN: jedi-time 0.1.4

ities, and makes sure that there is always a navigation path to either upgrade (by making assumptions), or downgrade (by losing information) your datafied representation . As always, thanks in advance... Dimitris On 09/02/2020 19:35, Sean Corfield wrote: Yes, I agree with all of that I think.

Re: ANN: jedi-time 0.1.4

me, :instant That is pretty much it in terms of `nav`... Does that make (more) sense? Many thanks in advance... Dimitris ps:  Sean I can be on slack but with my work email On 04/02/2020 05:18, Sean Corfield wrote: You're misunderstanding me. I'll try again. I'm not saying you

ANN: jedi-time 0.1.4

Hi folks, The first public release of `jedi-time` should be hitting clojars any minute now. I am traveling next week so may be slow to reply to feedback/bugs/PRs... https://github.com/jimpil/jedi-time Kind regards, Dimitris -- You received this message because you are subscribed to the

Re: Feedback on datafy/nav project

Sean, I've already done that ;) I will publish to clojars either this weekend or the next - I just want to add some more tests... On 31/01/2020 21:34, Sean Corfield wrote: Dimitris, As a follow-up to Alex’s comments: if you change your lib to extend the clojure.datafy version,

Re: Feedback on datafy/nav project

arties, and that the protocol extension guidelines don't really apply to it (or perhaps not as strictly)? Thanks for taking the time :) Dimitris On 31/01/2020 01:23, Sean Corfield wrote: If your library is intended specifically to provide the ability to datafy/nav

Re: Feedback on datafy/nav project

r the purpose of open extension by third parties, and that the protocol extension guidelines don't really apply to it (or perhaps not as strictly)? Thanks for taking the time :) Dimitris On 31/01/2020 01:23, Sean Corfield wrote: If your library is intended specifically to provide the

Re: Feedback on datafy/nav project

t. / On 30/01/2020 17:58, dimitris wrote: Well, the official Clojure guidelines are to NOT extend protocols, unless you own either the protocol of the type(s) [1]. In particular these lines:/ / /If you are a library developer, you should not extend if you own neit

Re: Feedback on datafy/nav project

Java // //interfaces. Rest assured if a protocol should extend to it, it will, // //else lobby for it. / On 30/01/2020 17:58, dimitris wrote: Well, the official Clojure guidelines are to NOT extend protocols, unless you own either the protocol of the type(s) [1]. In particular these lines:/ / /If you

Re: Feedback on datafy/nav project

when extending protocols included with Clojure itself./ / / Kind regards, Dimitris [1]: https://clojure.org/reference/protocols#_extend_via_metadata On 30/01/2020 17:50, Sean Corfield wrote: Is there a reason you’ve mirrored those protocols/implementations rather than just use Clojure’s

Feedback on datafy/nav project

ction at the very bottom that describes the approach in 4 short sentences. Many thanks in advance, Dimitris [1]: https://github.com/jimpil/jedi-time -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send e

[ANN] - duratom 0.5.0

generated keys (on the file.io side), two duratoms are needed to make this work (see the README [2]  for more). Cheers ... :) Kind regards, Dimitris [1]: https://www.file.io/ [2]: https://github.com/jimpil/duratom -- You received this message because you are subscribed to the Google Groups

Re: Bizarre issue when calling protocol-fn wrapper from different namespace

to copy/paste the protocol in each impl namespace separately. Many thanks for your insight Carlo :) On 22/11/2019 21:27, dimitris wrote: Hi Carlo thanks for you reply... Quoted from clojure.org/reference/protocols: /Avoid the 'expression problem' by allowing independent extension o

Re: Bizarre issue when calling protocol-fn wrapper from different namespace

11/2019 21:06, Carlo Zancanaro wrote: Hey Dimitris, I think what you're running into here is a fundamental misunderstanding of protocols. Specifically, this is not true: As I understand it, protocol extensions are namespace-specific. In Clojure, protocol extensions are global. If you exte

Re: Bizarre issue when calling protocol-fn wrapper from different namespace

pi.clj Everything works as expected inside the impl namespaces, but not in the api namespace, even though all it does is to delegate to some impl ns. Thanks again... Kind regards, Dimitris ps: this repo is WIP On 21 Nov 2019, at 23:43, Justin Smith wrote: on rereading I've clearly misun

ANN: duratom 0.4.9

. But if you have functional duratom backends today, I would very much appreciate PRs ;). Have a great month :) Kind regards, Dimitris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@google

[ANN]: Duratom 0.4.8

Hi again folks, I promise this is not spam! I just cut 0.4.8 which addresses a small and unnecessary (as it turns out) inefficiency with 0.4.7. I apologise for any inconvenience caused... Kind regards, Dimitris -- You received this message because you are subscribed to the Google Groups

[ANN]: duratom 0.4.7

the relevant section in the README [1] for more details ;). Kind regards, Dimitris [1]: https://github.com/jimpil/duratom -- 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

[ANN]: duratom 0.4.6

h use-cases where the value cannot, under any circumstances, be lost, but other - more relaxed scenarios may find this useful. Cheers and have a good month ;) Kind regards, Dimitris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To pos

Re: gen-class/AOT considered harmful (in libraries)???

torn on whether to actually add Clojure as a proper dependency - I think I will probably end up doing so, but I'm not thrilled about it... Kind regards, Dimitris On 23/08/2019 08:15, dimitris wrote: Why would I write the class in Java, when this below works exactly as expected? (n

Re: gen-class/AOT considered harmful (in libraries)???

boils down to this: Let's say that I used clojure1.10 to compile the above gen-class. Does the project containing it need to specify Clojure 1.10 as a proper dependency, or will the end user be able to provide any version of Clojure greater or equal to 1.10? Thanks in advance... Kind reg

gen-class/AOT considered harmful (in libraries)???

jure now needs to be a proper dependency for things to work)? Many thanks in advance... Kind regards, Dimitris -- 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 t

Re: [ANN]: circuit-breaker-fn 0.1.4

sions of Hystrix* Kind regards, Dimitris [1]: https://github.com/Netflix/Hystrix On 20/08/2019 13:49, Juraj Martinka wrote: Perfect, thanks for that! I was a bit surprised by the statement that Hystrix is deprecated - do you have more details about that? On Monday, 19 August 2019 14:21:59

Re: [ANN]: circuit-breaker-fn 0.1.4

ava lib, or you might prefer API X over API Y - who knows... Kind regards, Dimitris On 19/08/2019 06:24, Juraj Martinka wrote: Hi Dimitris, Thanks for the library. After quickly skimming the README file I'm wondering how does it compare to alternatives you mention at the end and/or Hyst

[ANN]: circuit-breaker-fn 0.1.4

most needs.  Hope you find it useful... Kind regards, Dimitris [1]: https://github.com/jimpil/circuit-breaker-fn -- 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 fr

[ANN] duratom 0.4.3

duratom to pull Clojure in, must be refactored to explicitly pull the desired Clojure version. Kind regards, Dimitris -- 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 po

[ANN] duratom 0.4.2

h non-nil metadata (basically printed/read as a tuple). If you would like to know more, follow the link below. https://github.com/jimpil/duratom Kind regards, Dimitris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, se

[ANN] rapio 0.1.0

Hi all, *rapio* is a tiny library for doing parallel IO against local files. It exposes two functions (*pslurp*/*pspit*), and their /*-big/ counterparts. Follow the link below to read more if you're interested... https://github.com/jimpil/rapio Kind regards, Dimitris -- You received

Re: [ANN]: clambda 0.1.4 - reducible Java Streams

Damn! Here is the correct link: https://github.com/jimpil/clambda On 09/08/18 17:03, dimitris wrote: Hi folks, https://github.com/jimpil/clambda /clambda/ is a little library for working with Java Streams from Clojure, and to a lesser extend, for working with Clojure seqs from Java

[ANN]: clambda 0.1.4 - reducible Java Streams

ways welcome ;) Kind regards, Dimitris ps: I didn't even try to have the misspelled `clamda` removed from clojars as my reason clearly didn't qualify. I did push a new version with the "DEPRECATED" prefix, so hopefully there won't be any confusion. Again, apologies

Re: [ANN] clamda - reducible Java Streams

Ignore my previous post please - I will try to get clamda 0.1.2 removed from clojars as it is misspelled (:facepalm:). There will be a new email eventually. Apologies for the noise... Kind regards, Dimitris On 08/08/18 22:01, dimitris wrote: Hi folks, /clamda/ [1], is a little library

[ANN] clamda - reducible Java Streams

ards, Dimitris [1]: https://github.com/jimpil/clamda -- 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

deps.edn :paths for mixed project?

g with deps.edn? I tried putting both of those under `:paths` but that didn't work (java.lang.ClassNotFoundException) when trying to test (clj -Atest). Kind regards, Dimitris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To po

reducible Java Streams (including parallel)

https://github.com/jimpil/treajure/blob/master/src/treajure/jstreams.clj Feedback is welcome :) Regards, Dimitris -- 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

Re: `lein run` VS `lein uberjar` behaviour

Darn it, i made a typo copying and it may throw some people off. There is a double-deref `@@` in the handler i pasted. Apologies for the slopiness... :( Regards, Dimitris On 19/02/18 16:52, dimitris wrote: Ok, so here is the ns declaration: (ns msnake.gui (:require ...the core game

Re: `lein run` VS `lein uberjar` behaviour

main] :main msnake.main :jvm-opts ["-Dclojure.compiler.direct-linking=true"] ) I should point out that direct-linking is not the culprit here. Exactly the same thing happens with or without direct-linking :(. As you can see I'm playing by the book - i.e. subclassing Applicatio

`lein run` VS `lein uberjar` behaviour

rainstorm ideas. I could even provide the project in a zip if you would like to experience it yourself. Thanks in advance... Kind regards, Dimitris [1]: https://stackoverflow.com/questions/29870368/javafx-mediaplayer-music-stops-after-10-seconds [2]: https://stackoverflow.com/questions/624

rationale for IAtom2 ?

Hi all, This is mainly a question for the Clojure core dev team. I'm trying really hard to understand the thinking behind the new IAtom2 interface. My train of thought is detailed below, but you don't have to read the full thing. The core question is "How come the existing IAtom didn't grow,

[ANN]: clj-bom

g the entirety of apache commons.io solely to access `BOMInputStream`, consider switching to this as a lighter (and more idiomatic) dependency. Kind regards, Dimitris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group

Re: Stack Overflow Question

try the following: |(defmacrodefapihandler [handler-name params & body]`(defn~handler-name ['~passed-param](let[param-keys# (vec(map(comp symbol name :key)~params)){:keysparam-keys#}'~passed-param];; some check~@body))) | Sorry for brevity, I'm on my phone... Dimitris

Re: Stack Overflow Question

you need to use `'~passed-param` in your arg-vector, and the same whenever you use it inside the newly defined fn. HTH, Dimitris On 24/12/16 11:48, Jiacai Liu wrote: how to make correct fn args when create fn using macro http://stackoverflow.com/q/41312963/2163429?sem=2 -- You rec

freqsort

Hi all, I was just playing about with sorting the other day and I came up with the following. I'll say upfront that performance wasn't my goal, however the performance of `freqsort` caught me completely off guard! It's surprisingly decent to say the least... I'm truly amazed given that my gr

Re: clojure.spec gen-testing VS NaN

Alright cool, I'll do that tomorrow :) Thanks, Dimitris On 07/11/16 22:07, Alex Miller wrote: I think it would be reasonable to log a jira enhancement request for the spec any? generator to avoid generating double NaNs. On Monday, November 7, 2016 at 12:30:24 PM UTC-6, Jim foo.bar

Re: clojure.spec gen-testing VS NaN

spec. My workaround is actually working nicely for me, and i can certainly live without NaNs in the tests, but it still feels a bit hacky. Thanks, Dimitris On 07/11/16 18:14, Alex Miller wrote: Please also take a look at s/double-in, which allows you to exclude NaN (and Infinity/-Infinity)

clojure.spec gen-testing VS NaN

eturns the same coll it was passed in when nothing has been removed), which is a possibility in a lot of functions. Have other people encountered this as well, and if yes, how are you guys dealing with it? Thanks in advance... Kind regards, Dimitris [1]: (= [:a Double/NaN] [:a Double

Re: clojure.spec - relationship between :args

Hi Michal, Oh yeah, I've actually improved the spec I shared over the weekend, in a similar direction you're hinting. Basically, i've split the :found & :not-found cases, and using `gen/one-of`. Many thanks :) regards, Dimitris On 07/11/16 11:41, Michał Marczyk wr

clojure.spec predicate generator question

returns true/false randomly, one cannot reliably use it under the :fn spec. Unless, I'm missing something of course...Thanks in advance :) Kind regards, Dimitris -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this g

Re: clojure.spec - relationship between :args

e that my humble 8G-ram laptop can barely deal with the default number of generative tests (1000), but at least it works :). Many thanks again, for redirecting me to Stu's video - it all made much more sense after digesting that. Regards, Dimitris On 04/11/16 00:14, dimitris wrote: HI

Re: clojure.spec - relationship between :args

HI Alex, Many thanks for your response, it was very helpful. I see your point about customizing the generator, and in fact the video in the link does something sort of similar to what I am trying to. So yeah I'll figure it out tomorrow :). Thanks again! Dimitris On 03/11/16 18:53,

clojure.spec - relationship between :args

rafted test-cases? Thanks in advance - any feedback is greatly appreciated :) Kind regards, Dimitris -- 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 ar

Re: [ANN] fudje - unit testing library vaguely resembling midje, but with less 'calories'

per assertion, which sounds cumbersome. I will contemplate this idea of an alternate api where `is` recognises individual checker symbols and if the idea matures i might include it as a separate namepace in fudje...Thanks again! :) Regards, dimitris On 27/01/16 23:40, dimitris wrote: Hi Timot

Re: [ANN] fudje - unit testing library vaguely resembling midje, but with less 'calories'

, there will always be a possibility for some very ugly code. apart from the `=>` symbol, which BTW can be anything you like as it's never evaluated, I don't see where you get the DSL impression from. fudje was specifically designed top to bottom to be as less sugary as possible (even

Re: [ANN] fudje - unit testing library vaguely resembling midje, but with less 'calories'

es, please forgive me for 'misleading'- i will fix asap! Thanks again... Cheers, dimitris On 26/01/16 23:42, Brian Marick wrote: dimitris wrote: This is a small testing library inspired by midje. For what it's worth, I (author of Midje) think this is wonderful. You might co

[ANN] fudje - unit testing library vaguely resembling midje, but with less 'calories'

Hi everyone, This is a small testing library inspired by midje. Before you start pulling your hair, about why do we need yet another unit-testing library, please consider reading the README and/or intro.md. https://github.com/jimpil/fudje TL/DR; Midje comes with some very cool features but