This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-28
Channels
Could allow the person using the macro to choose expanssion order, maybe if you prefixed the macro name with a ^ it should expand inside out
I think you would more likely see the introduction of a hygenic macro system (which actually restricts what macros can do) over something that expands it
gfredricks: have you looked at using tools.analyzer similar to what core.async does?
@hiredman: yeah, I assume that would work fine if you don't mind having that dependency
I thought Clojue's guaranteed unique binding names gave you all the benefits of hygene
clojure's macro system is unhygenic, but the syntax quoting stuff is like an assist to help make macros hygenic
but you can write macros without using syntax quote, or using any kind of quoting at all
Right, I see what you mean. The guarantees aren't there in Clojure, you just need to hope the designer of the macro made it hygenic
@gfredericks: two paths, one is to get that functionality or something like it in to the compiler, so you don't need a dependency, the other is to reduce the drag of the dependency, so you don't mind having it. the main way to reduce the drag of dependency seems like it would be some kind of isolating dependency module system, because the big down side is if everyone depends on and uses tools.analyzer, but everyone is using a different version, that is going to be painful
@hiredman bronsa said he could split it up into separate libs, but also alex thinks my macro idea is dumb, so maybe it's a wash
@hiredman I'm curious if you agree with all these people: https://twitter.com/gfredericks_/status/762311329470447616
well I guess that's unanimous then
except I haven't checked if @alexmiller hates it
I think the map syntax is tied to an intuitive understanding of a reader returning datastructures, which people can struggle with, but on the other hand, other lisps have different forms of let for parallel and sequential binding, so having the map has just a syntactic marker of using a different kind of let without worrying about why it makes sense because it is a map out of the reader seems ok
let* would be sort of an obvious candidate for the name of an alternative form of let, except that the relationship of test.check's let
to let*
would be more like common lisp's than clojure's; but maybe that would be fine, because who cares about clojure's let*?
Alex said he didn't like a variant name
I like :parallel because it lets you mix things
Hard to say, I would even consider just leaving it, which is easy for me to say since I haven't felt the pain.
that's super hard
if you can come up with a good general solution to that problem I will give you twenty seven genuine north american dollars
most default to something sane like postgresql, and build it out as the requirements change
Hi guys, happy to announce Lym is on apple store now! It's for learning different cultures, languages. Completely written by Clojure and Clojurescript, thank you so much! http://lymchat.com https://itunes.apple.com/us/app/lym/id1134985541?ls=1&mt=8
@lmergen: Do you serialize clojure data in one column? How did you implement the order of messages? What about idempotent message handling and rerunning some of them? Any integration with Kafka and the like?
yes, we do those of those kind of things. usually, ordering is something that should be used by the message broken (such as kafka), and idempotence is something that you need to take into account in your application logic.
i am not a fan of serialization of cojure data into one column, and if i need to do so, i usually use json
it’s a balance. nowadays, schema’s are non-strict, but you do want your data store to “understand” what is stored, so you can e.g. query on it
other than aleph, are there any good async clojure http client libraries ? i find aleph’s http client to be very, very buggy
but in other ways it’s a really nice library, so i’m trying to see what the alternatives are
Are those being tracked in the issue tracker somewhere? The issue you mentioned appears to be submitted, but only 16 minutes ago 🙂
Having dealt with other libraries I’ve fairly happily moved everything to aleph, so I’d much rather go bug fixing there
but it’s a lot of work fixing these issues, and i didn’t expect this from such a well-recommended library
I suppose for most people the consequences of worse asynchrony management (i.e. not having manifold) is more serious than these issues I guess — just never had those problems in particular 🙂
e.g. we care about things like fairly extensive TLS management where other libraries fall short from the just-go-talk-to-netty part
not trying to convince you, just making sure we have those issues tracked so at least someone can go fix them maybe 🙂
I wonder if Zach would consider extra maintainers; a big part of the problem seems to be the bus number and lack of time on his part 🙂
i think that would be a good thing, it takes him weeks/months to respond to some issues, if at all
As much as I use and like aleph and have libraries around manifold (i.e. banach) I’ve just become the maintainer for cloverage so maybe I should say “no” more often
I feel a big part of the problem is the fact that there’s so many, but it’s sufficiently treated like commons that its outcome is bound to be tragic
aleph’s http client middleware is pretty much copy/pasted from clj-http, but aleph uses 3 different types of middleware, which are not compatible
also not really sure how to do any better without some crazy macros that rewrite the fn a-la go
/ <!
I think the biggest issue is person-power — we could solve e.g. the ring middleware problem a lot better upstream by manually splitting up the pre- and post- work, separating out juuuust the let vs let-flow bit
Anyone here familiar with the inner workings of test.check? I have some clojure.spec
definitions working, but test.check
is having a very difficult time testing them. Specifically, I'm playing with some maze generation and pathfinding algorithms. A core construct is a "grid", a two-dimensional vector of cells. Here's a spec and a function:
(spec/def ::x integer?)
(spec/def ::y integer?)
(spec/def ::direction #{::n ::ne ::e ::se ::s ::sw ::w ::nw})
(spec/def ::exits (spec/coll-of ::direction :kind set?))
(spec/def ::cell (spec/keys :req [::x ::y ::exits]))
(spec/def ::row (spec/coll-of ::cell :kind vector?))
(spec/def ::grid (spec/coll-of ::row :kind vector?))
(defn grid-contains?
"True if the supplied x and y coordinates fall within the grid boundaries."
[grid x y]
(and (<= 0 y)
(<= 0 x)
(< y (count grid))
(< x (count (grid y)))))
(spec/fdef grid-contains?
:args (spec/cat :grid ::grid :x ::x :y ::y)
:ret boolean?)
I can verify, using spec/valid?
and spec/exercise
, that the ::grid
spec is correct, and that clojure.spec
knows how to generate examples of it. But when I run clojure.spec.test/check
on the grid-contains?
function, Java maxes all cores and then runs out of memory.
#'user/grid-contains?
user=> (stest/check `grid-contains? {:num-tests 1})
"grid-contains? grid 0 0"
OutOfMemoryError GC overhead limit exceeded clojure.lang.PersistentVector$TransientVector.persistent (PersistentVector.java:568)
Am I doing something wrong here?My first guess is that test.check
is generating vectors so large that they crash Java, but when I altered the specs such that the grid vectors could not be larger than 1000 items, I got the same results.
@lmergen FYI Zach is a really nice and very reasonable guy; so I think if you’re interested in doing some work he’ll be receptive to your suggestions 🙂 I can volunteer some time to weed through the issue tracker, but I definitely can’t take on another maintenance project
what's an elegant way to avoid evaluating or calling things like reverse
or last
on an infinite lazy seq?
@meta-meta: interesting question, but I can't see an obvious solution either. what problem are you trying to solve ? I assume you're exposing some logic as a lazy seq ?
Hi All -- Of the folks here who have used Onyx, has anyone written a k-means (or ideally, a k-means||) implementation? Was considering writing my own but don't want to reinvent the wheel 🙂
I am familiar with the inner workings of test.check
I can't tell what your problem is based on your description though
Oh hey, author of test.chuck! Hi! I'm afraid I can't give a lot more context, because, well, I don't know where to start. If you feed my above code into a REPL, you may get the same result, though. Just be ready to kill the java process. And if you don't, well, the mystery deepens.
Especially OOM on a single test suggests it has nothing to do with sizing subtleties
I'm dipping my toe in the waters of generative testing for the first time, so I don't really know what I should expect.
I don't have a repl on hand
I can try it when I get home
You're on alpha11?
alpha10, but let me see what happens if I bump it.
You could also debug by creating the generators for each of the arg types and sampling them to see if anything is weird
I'll try that out. spec/exercise
generated reasonable output for the largest composite type (the grid)—is that the same thing?
It should be
...interesting. I put print statements so I could see what values the system is generating for the arguments, and it seems to be doing reasonable stuff now. Maybe something just got fixed in the latest alpha.
"grid-contains? 12 x 10 grid; -611476993305, -240027313508"
...reasonable enough for me!
Not sure how to restrict the number of tests, though. The code seems to say that clojure.spec.test/check
takes an options hash, of which one key can be :clojure.spec.test/opts
, whose values can be a hash which is passed through to test.check
... but {:num-tests 1}
and {:clojure.spec.test/opts {:num-tests 1}}
both have my system running... well, who knows how many tests? It's been going for a while now.
(Update: fixed it. I needed (stest/check 'grid-contains? {:clojure.spec.test.check/opts {:num-tests 1}})
.)
I wonder if my code is having a hard time testing the boundary status of the coordinates -72927184749070415, -21020661
, or if that's just a totally normal number to have trouble with.
@amacdougall you're looking at a matrix of (x,y) pairs?
A two-dimensional vector of maps, if that makes a difference.
That should mean that (count coll)
is O(1), so I can't see why the grid-contains
check would run slow even when given an extremely large input value.
But then test.check is calling the function with (according to my print statement) "grid-contains? 7 x 6 grid; -490, 7232120168103"
...
And it's taking many seconds for my computer to come up with the answer.
Whoa, and it just ran out of memory again! What gives?
Anyway, at the REPL, it returns instantly, as I would expect.
mazes.grid=> (grid-contains? (create-grid 8 8) -490 7232120168103)
false
So somewhere at the interface of test.check and clojure.spec.test, something is going very wrong.
This stuff is in alpha, after all; I'm not going to sweat it for now.
@amacdougall I don't know how you are generating matrices, but I'm wondering if the memory issues are there. Are you using an optimized implementation?
If the issue were in the implementation, I would expect to see it every time I call the function with the same values, regardless of whether test.check is running it, right?
Got to head out; don't worry too much about me! I'm sidestepping the test.check thing and just doing stuff the old-fashioned way.
Not sure, but may be worth playing around with something like https://github.com/mikera/vectorz-clj.
I'll take a look! I have a feeling it won't do the trick for me, though. My grid is going to eventually be a game board, so instead of doing math on it, I'm going to be carving rooms out of it, placing entities on it, etc.