Re: Is there an apply-able new?

[Brandon Bloom]

The new operation intentionally demands a statically knowable type to 
construct. While this is true of Java as well, it's not true of JavaScript. 
However, it is true of the Google Closure compiler's "type system" for 
advanced compilation. That said, if the library you're using isn't going to 
be optimized with advanced, you can do any typical dynamic metaprogramming 
you'd want to do in JavaScript and call in to that.

mynamespace.make = function(cls) {
  return new (Function.prototype.bind.apply(cls, arguments));
};

Then from ClojureScript:

(apply mynamespace/make qx.ui.mobile.form.Button ["Go!"])



On Friday, May 27, 2016 at 10:24:12 AM UTC-7, hiskennyness wrote:
>
> qooxdoo lets us supply oft-used widget parameters to the constructor. For 
> example, a button can specify its label and icon at new time. And this 
> works fine from cljs:
>
>(new qx.ui.mobile.form.Button "Go!") ;; label is the first arg
>
> But I am wrapping qooxdoo in something more concise and want to be able to 
> code:
>
>(qxia/make (::Button "Go!")
>   ..other init params to be "set"
>
> Unfortunately I cannot even
>
>(new (qx-class qia-type)) ;; computed class
>
> Let alone
>
>(apply new (qx-class qxia-type) make-inits)
>
> Not that I thought I would get away with it. :) I grok new is special.
>
> I can fall back on the qooxdoo API and use setLabel and setIcon, but I 
> like learning so I thought I would ask if there were some way to:
>
>1. compute a class (preferably by first constructing a name) and/or
>2. do the moral equivalent of applying new to parameters
>
> -hk
>
>

-- 
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: IoT: Clojurescript -> Jerryscript?

[Christopher Small]

I imagine this should be possible, as long as JerryScript isn't missing any 
features needed by the js code the cljs compiles to. I'd bet most code 
would be fine, as long as it doesn't depend on OS features. So I would Just 
Try It with a simple hello world app and see how complicated you can get 
from there.

I started a project that was trying to provide a microcontroller computing 
API abstracting over the subtle differences between different targets 
(BeagleBone, Pi, and Arduino over Firmata). The biggest issue with this is 
that JVM Clojure is a sluggard to boot, and for some microcontroller units 
too memory-hungry. And of course having to use Firmata with Arduino is a 
major restriction. In talking with others about this, I thought that 
targeting node would be a perfect solution for BeagleBone or Pi, but being 
able to directly target Arduino (w/o Firmata) would be awesome :-)

I haven't had any time for this project with other open source things on my 
plate, but I'd be happy to provide guidance if you're interested in working 
on implementations of this API targeted at Jerryscript.

https://github.com/clj-bots/pin-ctrl

Cheers :-)

Chris




On Friday, May 27, 2016 at 9:33:17 AM UTC-7, Gregg Reynolds wrote:
>
> Hi folks,
>
> I just came across http://samsung.github.io/jerryscript/ , which Samsung 
> apparently open-sourced last fall.  Jerryscript is a bit of a misnomer, its 
> not a language but a JS engine designed for IoT devices.  Sorta like 
> node.js only smaller, I guess.
>
> Seems to run on Zephyr on Arduino101 
> ,
>  
> believe it or not.
>
> If we can run JS on constrained IoT devices, then we ought to be able to 
> write the code in Clojurescript, no?
>
> Anybody have any further info on this?  I'm going to be looking at the 
> Clojurescript source this weekend to try to get an idea of how hard it 
> would be to target Jerryscript (or iot.js, which is a companion thing).  
> Any advice/help would be appreciated.
>
> Thanks,
>
> Gregg
>

-- 
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.spec guide updated with generators

[Alex Miller]

I've added a new section to the clojure.spec guide for generators. 
Certainly doesn't cover everything yet but hope it helps!

http://clojure.org/guides/spec#_generators

-- 
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: Avoiding nested ifs...

[John Szakmeister]

On Thu, May 26, 2016 at 5:41 PM, Erik Assum  wrote:
> Not being good at reading other peoples mind, I’ll give my guess as to what 
> Timothy was trying to suggest:
>
> If you define your input as a map with keys such as:
>
> {:type :switched ; can be :switched :dual or :something
>  :pos 54}
>
> You can make something like:
>
> (defmulti verify-pos-for :type)

Yes, a multi-method could be used here, but Timothy suggested the data
model might be wrong and that's what I was interested in.  I think I'm
already setup to do the multi-methods with the current data model,
though it feels like a heavy-weight answer to the problem.

Thanks for the suggestion though!

-John

-- 
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: Is there an apply-able new?

[Kenneth Tilton]

Thanks but... Ugh. I guess I should have mentioned this is
Clojure/Javascript. Guessing clojure.reflect does not apply to JS.

Sorry for the trouble.

-kt


On Fri, May 27, 2016 at 1:30 PM, Gary Trakhman 
wrote:

> Here's a complex example using clojure.reflect, the intent of which was to
> create a macro that emits type-hints for the actual constructors that are
> available, to resolve ambiguity when there are multiple constructors with
> the same number of arguments that differ in type.
>
> https://github.com/gtrak/interop/blob/master/src/interop/core.clj
>
> On Fri, May 27, 2016 at 1:25 PM Gary Trakhman 
> wrote:
>
>> Yes, you'll have to use the reflection API to create a class dynamically.
>>
>> https://docs.oracle.com/javase/tutorial/reflect/member/ctorInstance.html
>>
>> On Fri, May 27, 2016 at 1:24 PM hiskennyness  wrote:
>>
>>> qooxdoo lets us supply oft-used widget parameters to the constructor.
>>> For example, a button can specify its label and icon at new time. And this
>>> works fine from cljs:
>>>
>>>(new qx.ui.mobile.form.Button "Go!") ;; label is the first arg
>>>
>>> But I am wrapping qooxdoo in something more concise and want to be able
>>> to code:
>>>
>>>(qxia/make (::Button "Go!")
>>>   ..other init params to be "set"
>>>
>>> Unfortunately I cannot even
>>>
>>>(new (qx-class qia-type)) ;; computed class
>>>
>>> Let alone
>>>
>>>(apply new (qx-class qxia-type) make-inits)
>>>
>>> Not that I thought I would get away with it. :) I grok new is special.
>>>
>>> I can fall back on the qooxdoo API and use setLabel and setIcon, but I
>>> like learning so I thought I would ask if there were some way to:
>>>
>>>1. compute a class (preferably by first constructing a name) and/or
>>>2. do the moral equivalent of applying new to parameters
>>>
>>> -hk
>>>
>>> --
>>> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/4HWF7725JvM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Kenneth Tilton
54 Isle of Venice Dr, Apt 5
Fort Lauderdale, FL 33301

kentil...@gmail.com
646-269-1077

-- 
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: Is there an apply-able new?

[Gary Trakhman]

Here's a complex example using clojure.reflect, the intent of which was to
create a macro that emits type-hints for the actual constructors that are
available, to resolve ambiguity when there are multiple constructors with
the same number of arguments that differ in type.

https://github.com/gtrak/interop/blob/master/src/interop/core.clj

On Fri, May 27, 2016 at 1:25 PM Gary Trakhman 
wrote:

> Yes, you'll have to use the reflection API to create a class dynamically.
>
> https://docs.oracle.com/javase/tutorial/reflect/member/ctorInstance.html
>
> On Fri, May 27, 2016 at 1:24 PM hiskennyness  wrote:
>
>> qooxdoo lets us supply oft-used widget parameters to the constructor. For
>> example, a button can specify its label and icon at new time. And this
>> works fine from cljs:
>>
>>(new qx.ui.mobile.form.Button "Go!") ;; label is the first arg
>>
>> But I am wrapping qooxdoo in something more concise and want to be able
>> to code:
>>
>>(qxia/make (::Button "Go!")
>>   ..other init params to be "set"
>>
>> Unfortunately I cannot even
>>
>>(new (qx-class qia-type)) ;; computed class
>>
>> Let alone
>>
>>(apply new (qx-class qxia-type) make-inits)
>>
>> Not that I thought I would get away with it. :) I grok new is special.
>>
>> I can fall back on the qooxdoo API and use setLabel and setIcon, but I
>> like learning so I thought I would ask if there were some way to:
>>
>>1. compute a class (preferably by first constructing a name) and/or
>>2. do the moral equivalent of applying new to parameters
>>
>> -hk
>>
>> --
>> 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.

Re: Is there an apply-able new?

[Gary Trakhman]

Yes, you'll have to use the reflection API to create a class dynamically.

https://docs.oracle.com/javase/tutorial/reflect/member/ctorInstance.html

On Fri, May 27, 2016 at 1:24 PM hiskennyness  wrote:

> qooxdoo lets us supply oft-used widget parameters to the constructor. For
> example, a button can specify its label and icon at new time. And this
> works fine from cljs:
>
>(new qx.ui.mobile.form.Button "Go!") ;; label is the first arg
>
> But I am wrapping qooxdoo in something more concise and want to be able to
> code:
>
>(qxia/make (::Button "Go!")
>   ..other init params to be "set"
>
> Unfortunately I cannot even
>
>(new (qx-class qia-type)) ;; computed class
>
> Let alone
>
>(apply new (qx-class qxia-type) make-inits)
>
> Not that I thought I would get away with it. :) I grok new is special.
>
> I can fall back on the qooxdoo API and use setLabel and setIcon, but I
> like learning so I thought I would ask if there were some way to:
>
>1. compute a class (preferably by first constructing a name) and/or
>2. do the moral equivalent of applying new to parameters
>
> -hk
>
> --
> 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.

Is there an apply-able new?

[hiskennyness]

qooxdoo lets us supply oft-used widget parameters to the constructor. For 
example, a button can specify its label and icon at new time. And this 
works fine from cljs:

   (new qx.ui.mobile.form.Button "Go!") ;; label is the first arg

But I am wrapping qooxdoo in something more concise and want to be able to 
code:

   (qxia/make (::Button "Go!")
  ..other init params to be "set"

Unfortunately I cannot even

   (new (qx-class qia-type)) ;; computed class

Let alone

   (apply new (qx-class qxia-type) make-inits)

Not that I thought I would get away with it. :) I grok new is special.

I can fall back on the qooxdoo API and use setLabel and setIcon, but I like 
learning so I thought I would ask if there were some way to:

   1. compute a class (preferably by first constructing a name) and/or
   2. do the moral equivalent of applying new to parameters

-hk

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

IoT: Clojurescript -> Jerryscript?

[Gregg Reynolds]

Hi folks,

I just came across http://samsung.github.io/jerryscript/ , which Samsung
apparently open-sourced last fall.  Jerryscript is a bit of a misnomer, its
not a language but a JS engine designed for IoT devices.  Sorta like
node.js only smaller, I guess.

Seems to run on Zephyr on Arduino101
,
believe it or not.

If we can run JS on constrained IoT devices, then we ought to be able to
write the code in Clojurescript, no?

Anybody have any further info on this?  I'm going to be looking at the
Clojurescript source this weekend to try to get an idea of how hard it
would be to target Jerryscript (or iot.js, which is a companion thing).
Any advice/help would be appreciated.

Thanks,

Gregg

-- 
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: vector of chars vs string

[Tassilo Horn]

Camilo Roca  writes:

Hi Camilo,

> Everything is ok with that. The next one on the other hand is what
> puzzles me:
> (identical? \f (first (str "f" "oo")))
> ;;=> true
>
> If what I guess is right, the amount of chars that exist are finite,
> thus Clojure treats them like a "pool of charts". The question is then
> why are not strings implemented as vectors of charts instead of using
> the underlying Java String class?

That wouldn't be better.  Two vectors containing the identical chars in
the same order are still different vectors.

  (map identical? [\f \o \o] [\f \o \o])
  ;=> (true true true)

  (identical? [\f \o \o] [\f \o \o])
  ;=> false

So that's actually exactly the same as with strings.  And as Alex
already explained, strings are more light-weight than vectors, and they
are already highly optimized, e.g., every equal literal string in your
code will usually be represented by the very same string in memory.

Bye,
Tassilo

-- 
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: reader conditional not handling defmacro?

[Nathan Davis]

Alex,

On the Dev list, you mentioned you had discussed this several times with 
Rich and others, but were unable to reach concensus.  May I ask what the 
hangup is (i.e., what reservations / objections were expressed) and what 
other options came out of those discussions?

Nathan Davis

On Friday, May 27, 2016 at 7:39:15 AM UTC-5, Alex Miller wrote:
>
> That is one option and is in the ballpark of 
> http://dev.clojure.org/jira/browse/CLJ-1750.
>
> On Thursday, May 26, 2016 at 11:47:09 PM UTC-5, Nathan Davis wrote:
>>
>> I can't reply to the thread on the Dev list, but here's my take.
>>
>> Unless I'm missing something, it seems to me that most these issues could 
>> be resolved by having a dynamic var that gets set during macro expansion 
>> according to the target platform.  For instance, *compiler-target* is 
>> set to :clj or :cljs, depending on whether we're compiler for the JVM or 
>> Javascript.  If we want to be a little more sophisticated, 
>> *compiler-target* could be a set whose members are the same keywords 
>> that were "active" at read-time.  That would have the additional 
>> convenience that *compiler-target* would act as a predicate, indicating 
>> whether a particular "feature" is available for the target platform.
>>
>> Then if a macro needs to be expanded in a certain way for certain 
>> platforms, it can just consult *compiler-target*.
>>
>> Anyway, that's my 2-cents.
>>
>> Nathan Davis
>>
>>
>> On Sunday, May 22, 2016 at 5:57:14 PM UTC-5, Herwig Hochleitner wrote:
>>>
>>> This thread just came up, while I was in the process of composing a mail 
>>> on this topic to clojure-dev: 
>>> https://groups.google.com/d/msg/clojure-dev/f6ULUVokXrU/3uue5okSAgAJ
>>>
>>> 2016-05-20 23:22 GMT+02:00 Dan Burton :
>>>
 What about something like

 (def obj #?(:clj Object :cljs js/Object))

>>>
>>> Unfortunately, doesn't work for cases, where you need to generate 
>>> different syntax, eg `(try .. (catch Throwable e ...))` vs `(try ... (catch 
>>> :default e ...))`.
>>>
>>>

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

Deconstructing Transducers

[Bobby Eickhoff]

Precondition:  I didn't really understand transducers
Action:  I spent some time tinkering with them
Postcondition:  I've written a blog post about it: Deconstructing 
Transducers 


Constructive feedback is more than welcome.
Thanks!
Bobby

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

how to reuse fspec for fdef?

[Robert Luo]

I already defined a spec for one kind of functions:

(s/def ::my-handler (s/fspec :args ... :ret ...))

Then I define an instance of ::my-handler, e.g. real-handler, which I can 
use s/fdef to register it to registry, but can I just reuse the spec like 
this?

(s/fdef real-handler ::my-handler)

-- 
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: emacs Expectations Mode - can't make it work

[Jason MacLulich]

Just had to add that this emacs binding was awesome! Worked great.

Thanks for posting that Sean.

On Tuesday, January 26, 2016 at 4:47:16 AM UTC+11, Sean Corfield wrote:
>
> Yuri Steinschreiber wrote on Monday, January 25, 2016 at 1:17 AM:
>
> Sadly, Expectations Mode seems to be abandoned. Leaving an FYI to the 
> community.
>
>
> We stopped using expectations-mode a long time ago, instead adding this to 
> our Emacs config:
>
> ;; run expectations
> (defun run-expectations ()
>   (interactive)
>   (cider-insert-in-repl "(expectations/run-tests [*ns*])" t))
> (global-set-key (kbd "C-c C-/") 'run-expectations)
>
> It’s short, simple, addresses our most common use case, and works well 
> with our workflow (C-c C-k, C-c M-n and then write/update a test, C-c C-c 
> to eval it, C-c C-/ to run it, rinse, repeat).
>
> Sean
>
>

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

[Rich Hickey]

You can’t give the same qualified spec name two meanings, that’s a main point 
of spec. However, your actual use case you use unqualified :attack in two 
different contexts. - just don’t map them to the same spec. Note that ::kw is 
just a shorthand in the examples for fully-qualified keys, they need not be in 
the same ns.

e.g. register specs under
 
:my.simple/attack
:my.complex/attack

and then in one context use (keys :req-un [:my.simple/attack …]) and in the 
other (keys :req-un [:my.complex/attack …])



> On May 27, 2016, at 3:36 AM, Pedro Santos  wrote:
> 
> Hello,
> 
> How can I differentiate between the same keyword, but with difference 
> semantics? Example:
> 
> {:attack 100
>  :bonus {:attack {:category {:heavy 100
> 
> I have:
> (s/def ::attack (s/and pos? #(<= 1 1000))
> (s/def ::bonus (s/keys :req-un [::attack ; <--- 
> 
> Is there a way to do this?
> 
> --
> 
> Another question: is there a way to spec a fn that handles channels? 
> Something like:
> 
> (s/fdef some-fn
>  :args (s/cat :ch (s/chan ::unq/model))
>  :ret (s/chan :unq/model))
> 
> --
> 
> And yet another: I have a game project with some test.check scenarios. The 
> test run takes 8s without instrumenting and 22s with instrumentation, and 
> this makes me think on starting to split tests in test suites. Is there 
> something to handle this in clojure.test?
> 
> Thanks!
> 
> 
> On Thu, May 26, 2016 at 7:00 PM Beau Fabry  wrote:
> I'm in a similar position to you Wesley, I'm all for generative testing, but 
> sometimes I prefer not to spec out the full depth of the tree (ie some input 
> leaves with s/Any) and just turn on validation in staging and see what 
> happens. The cpu-time wasted there doesn't matter much to me. Looking forward 
> to seeing where things end up. Spec certainly seems really well thought 
> through.
> 
> Aside: Great work on the docs Alex. Much much more comprehensive and readable 
> than is usually available for an alpha feature in *any* language.
> 
> 
> On Thursday, May 26, 2016 at 6:57:24 AM UTC-7, Wesley Hall wrote:
> Thanks Rich, for this and your work in general. After 15 years of working 
> with Java, it has been a real joy to find clojure (let's face it, that pun 
> alone is pure gold!). 
> 
> I might try my hand at the macrology you describe as an exercise... everybody 
> stand well back
> 
> On Thursday, 26 May 2016 14:43:04 UTC+1, Rich Hickey wrote:
> If you name (register) your (sub)specs with s/def and you can reuse them as 
> much as you like. 
> 
> (s/def ::argi (s/cat :i integer?)) 
> (s/def ::fnii (s/fspec :args ::argi :ret integer?)) 
> (s/conform ::fnii +) 
> (s/valid? ::argi '(42)) 
> 
> However you are talking about calling ‘instrument’ so I don’t think you are 
> in the HOF case. So you shouldn’t be using fspec but fdef: 
> 
> (s/fdef fooi :args (s/cat :i integer?) :ret integer?) 
> 
> (defn fooi [i] 
>   (let [spec (-> `fooi s/fn-specs :args)] 
> (assert (s/valid? spec (list i)) (s/explain-str spec (list i 
>   42) 
> 
> (fooi "42") 
> user=> AssertionError Assert failed: In: [0] val: "42" fails at: [:i] 
> predicate: integer? 
> 
> Obviously some macrology could make this more succinct, as is being discussed 
> elsewhere. 
> 
> > On May 26, 2016, at 9:17 AM, Wesley Hall  wrote: 
> > 
> > spec is not a contract system. 
> > 
> > Forgive me for I am about to sin :). 
> > 
> > I have a little RPC framework that I use to do simple remoting between 
> > clojurescript in the browser and ring based web services. I'm currently 
> > using schema to validate arguments received from clients and return 
> > appropriate exceptions upon non-conforming invocations. 
> > 
> > The idea of being able to perform generative testing against a 
> > specification for these functions is really appealing but if I am using 
> > generative testing to verify that my functions behave properly if invoked 
> > as intended it does feel like there would be some benefit to ensuring that 
> > the conditions under which the function has been tested are enforced at 
> > runtime for those functions on the edges of my API. 
> > 
> > I'd definitely prefer a manual conformity check over instrumentation in 
> > these cases, but it seems like an fspec cannot be used for this purpose 
> > (from within the function itself). I'd rather not define my specs twice. 
> > 
> > Seems like I might be destined to make cheeky instrument calls after each 
> > of these edge functions, in the same was the always-validate metadata is 
> > used in schema. 
> > 
> > Do I have a desperate need to be convinced otherwise? :) 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@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+u...@googlegroups.com 
> > For more options, visit this group at 
> >

Re: clojure.spec

[Pedro Santos]

Thanks Beau and Alex, I ended up using a different namespace and got things
done!

About chans:
I was trying to use the spec mainly as a checker on test/dev. We have a
system that communicates a lot via channels but we lose that extra check at
those boundaries. Didn't think about the transducers, that complicates
things.

About the test timing:
I've only instrumented one namespace and it has a some getter fns that are
heavily used[1]. This may not be a typical scenario, because we test brute
force AI and auto generate battles and play them to the end. But it's a
heavy burden. Our travis build went from 9min to 47 min with that change.
So we may need to re-organize the tests and don't instrument all the
scenarios.

[1]
https://github.com/orionsbelt-battlegrounds/obb-rules/blob/9fa5da24a3844982ba51e17e9adfe49f2aeea445/src/obb_rules/unit.cljc

On Fri, May 27, 2016 at 1:36 PM Alex Miller  wrote:

>
>
> On Friday, May 27, 2016 at 2:36:56 AM UTC-5, Pedro Pereira Santos wrote:
>>
>> Hello,
>>
>> How can I differentiate between the same keyword, but with difference
>> semantics? Example:
>>
>
> If you have different semantics, you should use different keywords (either
> different name or namespace).
>
>
>>
>> {:attack 100
>>  :bonus {:attack {:category {:heavy 100
>>
>> I have:
>> (s/def ::attack (s/and pos? #(<= 1 1000))
>> (s/def ::bonus (s/keys :req-un [::attack ; <---
>>
>> Is there a way to do this?
>>
>> --
>>
>> Another question: is there a way to spec a fn that handles channels?
>> Something like:
>>
>
> Nothing right now but we've talked about this some. You have to keep in
> mind that channels also can have a transducer which means the read and
> write ends of a channel might have different specs. Tim Baldridge pointed
> out that you could use a map transducer that checked s/valid? on it's
> inputs - that could be used at either the beginning and/or end of a
> transducer chain. That's pretty brute force though and would add a lot of
> overhead.
>
>
>>
>> (s/fdef some-fn
>>  :args (s/cat :ch (s/chan ::unq/model))
>>  :ret (s/chan :unq/model))
>>
>> --
>>
>> And yet another: I have a game project with some test.check scenarios.
>> The test run takes 8s without instrumenting and 22s with instrumentation,
>> and this makes me think on starting to split tests in test suites. Is there
>> something to handle this in clojure.test?
>>
>
> That's the first timing report I've seen - pretty interesting! How many
> fns do you have instrumented? clojure.test does not support this directly
> but if you're using leiningen you can use their test selectors on how to do
> this.
>
>
>>
>> Thanks!
>>
>>
>> On Thu, May 26, 2016 at 7:00 PM Beau Fabry  wrote:
>>
>>> I'm in a similar position to you Wesley, I'm all for generative testing,
>>> but sometimes I prefer not to spec out the full depth of the tree (ie some
>>> input leaves with s/Any) and just turn on validation in staging and see
>>> what happens. The cpu-time wasted there doesn't matter much to me. Looking
>>> forward to seeing where things end up. Spec certainly seems really well
>>> thought through.
>>>
>>> Aside: Great work on the docs Alex. Much much more comprehensive and
>>> readable than is usually available for an alpha feature in *any* language.
>>>
>>>
>>> On Thursday, May 26, 2016 at 6:57:24 AM UTC-7, Wesley Hall wrote:

 Thanks Rich, for this and your work in general. After 15 years of
 working with Java, it has been a real joy to find clojure (let's face it,
 that pun alone is pure gold!).

 I might try my hand at the macrology you describe as an exercise...
 everybody stand well back

 On Thursday, 26 May 2016 14:43:04 UTC+1, Rich Hickey wrote:
>
> If you name (register) your (sub)specs with s/def and you can reuse
> them as much as you like.
>
> (s/def ::argi (s/cat :i integer?))
> (s/def ::fnii (s/fspec :args ::argi :ret integer?))
> (s/conform ::fnii +)
> (s/valid? ::argi '(42))
>
> However you are talking about calling ‘instrument’ so I don’t think
> you are in the HOF case. So you shouldn’t be using fspec but fdef:
>
> (s/fdef fooi :args (s/cat :i integer?) :ret integer?)
>
> (defn fooi [i]
>   (let [spec (-> `fooi s/fn-specs :args)]
> (assert (s/valid? spec (list i)) (s/explain-str spec (list i
>   42)
>
> (fooi "42")
> user=> AssertionError Assert failed: In: [0] val: "42" fails at: [:i]
> predicate: integer?
>
> Obviously some macrology could make this more succinct, as is being
> discussed elsewhere.
>
> > On May 26, 2016, at 9:17 AM, Wesley Hall 
> wrote:
> >
> > spec is not a contract system.
> >
> > Forgive me for I am about to sin :).
> >
> > I have a little RPC framework that I use to do simple remoting
> between clojurescript in the browser and ring based web services. I'm
> currently using schema to validate arguments received from clients and
>

Re: Avoiding nested ifs...

[hiskennyness]

On Thursday, May 26, 2016 at 10:50:24 AM UTC-4, John Szakmeister wrote:
>
> I'm very much a fan of bailing out early in imperative 
> programming as it helps to avoid a bunch of nested if conditions 
> that are to follow and read.  This typically comes up when 
> checking arguments to ensure that they're valid (in range, of 
> acceptable values, etc).  One of the major stumbling blocks 
> I've had when writing Clojure is to find a good way to keep code 
> concise, but readable. 
>
>
Food for thought: that is pretty much how folks felt back in the late 70s 
when GOTO became a four-letter word and was deprecated in favor of 
structured programming. So your thought that this might be a transitional 
thing for you seemed right. Even coming from common lisp, I am waiting out 
attitude transitions myself.

I introduced structured programming at my first for-hire programming job 
after watching the senior devs flipping through COBOL printouts back and 
forth trying to follow the GOTOs. When asked to take a stab at improving 
things, I suggested (in part) going structured. My manager liked the idea 
and when I said I was going to throw in the occasional dead obvious GOTO, 
he challenged me to go pure. I did so but with the attitude of showing how 
silly the code would turn out. I ended up convinced. There was an emergent 
property from going pure: if I crashed at line 2042, I knew all the 
conditions that were true, because I knew exactly how I got there. Silly 
had value.

Then another programmer was assigned to me and asked to clone my app for a 
different region. When she got stuck I helped her debug it, and it took 
hours (because compile times were half hours). It turns out the code we 
were staring at was forty lines down from a buggy "GOTO my-proc-end" by 
passing the code we knew had to be working, and monitors were 24x80 back 
then.

btw. I myself am quite fond of Common Lisp return-from, so I am no purist. 
But I am hearing your actual use cases are hairy enough that the semantics 
of a long chain of code chunks each of them free to bail might be hard to 
follow.

btw2, with others, I use COND a lot for these cases. But it only goes so 
far. Often I do some heavy-lifting in a clause that needs repeating in 
another clause if this one decides not to fire.

btw3, yeah, SOME is a great operator.

-hk

 

-- 
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: reader conditional not handling defmacro?

[Alex Miller]

That is one option and is in the ballpark 
of http://dev.clojure.org/jira/browse/CLJ-1750.

On Thursday, May 26, 2016 at 11:47:09 PM UTC-5, Nathan Davis wrote:
>
> I can't reply to the thread on the Dev list, but here's my take.
>
> Unless I'm missing something, it seems to me that most these issues could 
> be resolved by having a dynamic var that gets set during macro expansion 
> according to the target platform.  For instance, *compiler-target* is set 
> to :clj or :cljs, depending on whether we're compiler for the JVM or 
> Javascript.  If we want to be a little more sophisticated, 
> *compiler-target* could be a set whose members are the same keywords that 
> were "active" at read-time.  That would have the additional convenience 
> that *compiler-target* would act as a predicate, indicating whether a 
> particular "feature" is available for the target platform.
>
> Then if a macro needs to be expanded in a certain way for certain 
> platforms, it can just consult *compiler-target*.
>
> Anyway, that's my 2-cents.
>
> Nathan Davis
>
>
> On Sunday, May 22, 2016 at 5:57:14 PM UTC-5, Herwig Hochleitner wrote:
>>
>> This thread just came up, while I was in the process of composing a mail 
>> on this topic to clojure-dev: 
>> https://groups.google.com/d/msg/clojure-dev/f6ULUVokXrU/3uue5okSAgAJ
>>
>> 2016-05-20 23:22 GMT+02:00 Dan Burton :
>>
>>> What about something like
>>>
>>> (def obj #?(:clj Object :cljs js/Object))
>>>
>>
>> Unfortunately, doesn't work for cases, where you need to generate 
>> different syntax, eg `(try .. (catch Throwable e ...))` vs `(try ... (catch 
>> :default e ...))`.
>>
>>

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

[Alex Miller]

On Friday, May 27, 2016 at 2:36:56 AM UTC-5, Pedro Pereira Santos wrote:
>
> Hello,
>
> How can I differentiate between the same keyword, but with difference 
> semantics? Example:
>

If you have different semantics, you should use different keywords (either 
different name or namespace).
 

>
> {:attack 100
>  :bonus {:attack {:category {:heavy 100
>
> I have:
> (s/def ::attack (s/and pos? #(<= 1 1000))
> (s/def ::bonus (s/keys :req-un [::attack ; <--- 
>
> Is there a way to do this?
>
> --
>
> Another question: is there a way to spec a fn that handles channels? 
> Something like:
>

Nothing right now but we've talked about this some. You have to keep in 
mind that channels also can have a transducer which means the read and 
write ends of a channel might have different specs. Tim Baldridge pointed 
out that you could use a map transducer that checked s/valid? on it's 
inputs - that could be used at either the beginning and/or end of a 
transducer chain. That's pretty brute force though and would add a lot of 
overhead.
 

>
> (s/fdef some-fn
>  :args (s/cat :ch (s/chan ::unq/model))
>  :ret (s/chan :unq/model))
>
> --
>
> And yet another: I have a game project with some test.check scenarios. The 
> test run takes 8s without instrumenting and 22s with instrumentation, and 
> this makes me think on starting to split tests in test suites. Is there 
> something to handle this in clojure.test?
>

That's the first timing report I've seen - pretty interesting! How many fns 
do you have instrumented? clojure.test does not support this directly but 
if you're using leiningen you can use their test selectors on how to do 
this.
 

>
> Thanks!
>
>
> On Thu, May 26, 2016 at 7:00 PM Beau Fabry  wrote:
>
>> I'm in a similar position to you Wesley, I'm all for generative testing, 
>> but sometimes I prefer not to spec out the full depth of the tree (ie some 
>> input leaves with s/Any) and just turn on validation in staging and see 
>> what happens. The cpu-time wasted there doesn't matter much to me. Looking 
>> forward to seeing where things end up. Spec certainly seems really well 
>> thought through.
>>
>> Aside: Great work on the docs Alex. Much much more comprehensive and 
>> readable than is usually available for an alpha feature in *any* language.
>>
>>
>> On Thursday, May 26, 2016 at 6:57:24 AM UTC-7, Wesley Hall wrote:
>>>
>>> Thanks Rich, for this and your work in general. After 15 years of 
>>> working with Java, it has been a real joy to find clojure (let's face it, 
>>> that pun alone is pure gold!). 
>>>
>>> I might try my hand at the macrology you describe as an exercise... 
>>> everybody stand well back
>>>
>>> On Thursday, 26 May 2016 14:43:04 UTC+1, Rich Hickey wrote:

 If you name (register) your (sub)specs with s/def and you can reuse 
 them as much as you like. 

 (s/def ::argi (s/cat :i integer?)) 
 (s/def ::fnii (s/fspec :args ::argi :ret integer?)) 
 (s/conform ::fnii +) 
 (s/valid? ::argi '(42)) 

 However you are talking about calling ‘instrument’ so I don’t think you 
 are in the HOF case. So you shouldn’t be using fspec but fdef: 

 (s/fdef fooi :args (s/cat :i integer?) :ret integer?) 

 (defn fooi [i] 
   (let [spec (-> `fooi s/fn-specs :args)] 
 (assert (s/valid? spec (list i)) (s/explain-str spec (list i 
   42) 

 (fooi "42") 
 user=> AssertionError Assert failed: In: [0] val: "42" fails at: [:i] 
 predicate: integer? 

 Obviously some macrology could make this more succinct, as is being 
 discussed elsewhere. 

 > On May 26, 2016, at 9:17 AM, Wesley Hall  wrote: 
 > 
 > spec is not a contract system. 
 > 
 > Forgive me for I am about to sin :). 
 > 
 > I have a little RPC framework that I use to do simple remoting 
 between clojurescript in the browser and ring based web services. I'm 
 currently using schema to validate arguments received from clients and 
 return appropriate exceptions upon non-conforming invocations. 
 > 
 > The idea of being able to perform generative testing against a 
 specification for these functions is really appealing but if I am using 
 generative testing to verify that my functions behave properly if invoked 
 as intended it does feel like there would be some benefit to ensuring that 
 the conditions under which the function has been tested are enforced at 
 runtime for those functions on the edges of my API. 
 > 
 > I'd definitely prefer a manual conformity check over instrumentation 
 in these cases, but it seems like an fspec cannot be used for this purpose 
 (from within the function itself). I'd rather not define my specs twice. 
 > 
 > Seems like I might be destined to make cheeky instrument calls after 
 each of these edge functions, in the same was the always-validate metadata 
 is used in schema. 
 > 
 > Do I have a despe

Re: vector of chars vs string

[Alex Miller]

On Friday, May 27, 2016 at 6:30:45 AM UTC-5, Camilo Roca wrote:
>
> If what I guess is right, the amount of chars that exist are finite,
>

Well, kind of - see Unicode.
 

> thus Clojure treats them like a "pool of charts".
>

Java has a small number of primitive value types - byte, short, int, long, 
double, float, boolean, and char. In the JVM there is no "pool of 
primitives" - all of these types (plus Objects) describe how values are 
actually stored. If you had a "pool" then something would have to refer to 
it and the pointer would be larger than the value in many cases.

Several of the boxed versions of these primitives do pool the boxed forms 
in a range. I think Character is pooled for 0-127. Integers use a larger 
extended pool. This is all defined in the Java spec. This is a Java 
feature, not a JVM one.
 

> The question is then why are not strings implemented as vectors of charts 
> instead of using the underlying Java String class? 
>

Java strings are stored as arrays of chars  (hand-waving over the actual 
tricky details of multi-byte character encoding) which is about as 
efficient as you can get in the JVM (once I implemented a hack to String 
itself to compress and decompress big char arrays - that was fun! totally 
not worth it). Clojure vectors are certainly not as memory efficient as a 
simple array - they are a tree structure of nodes containing arrays (hash 
array mapped tries).
 

> As by using the Java String new allocations would have to be performed 
> every time that a new string needs to be created, even if it contains 
> exactly the same information of an existing string.
>

True, although these operations (being so common) are highly optimized in 
the JVM and even in the garbage collector. G1 will now autodetect the reuse 
of literal strings and de-dupe them in the latest versions. In short, the 
JVM is optimizing strings way more than we ever would and the best thing to 
do is to leverage the common path there and assume it will continue to be 
as fast as possible. Java strings can also be interned which forces a 
literal string to be effectively cached in the JVM and reused - you can 
explicitly do that via String.intern() but literal strings in your source 
code are always interned. There are some interesting effects with interning 
though so it's good to tread carefully with it - we used to use it more 
inside Clojure but have backed off of it as it makes allocation slower.
 

> This might not be a big deal if the amount of strings is small of lazy 
> produced, but (at least in my case) when I needed to load a relatively 
> small text file (120 MB) fully into memory* then I started having memory 
> problems as (from what I saw with YourKit) I had lots of repeated strings.
>

Interning might be worth looking at it if you're seeing this. In particular 
for cases like reading a file into maps where the map keys are common - 
those keys can be interned.

You might also try the G1 string deduplication with something 
like -XX:+UseG1GC -XX:+UseStringDeduplication 
-XX:+PrintStringDeduplicationStatistics - the last to see the effects. 
Google around for more info on this and make sure you're on the latest JDK 
as it's evolved.
 

>
> I would like to know your thoughts on this idea and implications/problems 
> with it.
>
>
> -- 
> notes
> * yes I know that I could lazily analyze the whole file and thus avoid 
> having memory problems, but in some cases such as using sort-by or 
> group-by, there is no other alternative than holding the whole thing and 
> then process it.
>
>

-- 
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: Avoiding nested ifs...

[John Szakmeister]

On Thu, May 26, 2016 at 7:09 PM, Mark Engelberg
 wrote:
> On Thu, May 26, 2016 at 1:29 PM, John Szakmeister 
> wrote:
>>
>>
>> Yeah, cond is definitely useful here, but not in general.
>>
>
> cond is useful in general, just not the cond that is built-in to Clojure.

Sorry, I didn't mean it that way--just that it didn't seem useful to
me in general for the problems I've been facing with validation.

> About 5 years ago, Christophe Grand pointed out in a blog post that cond,
> augmented with a few extra things (:let, :when, and :when-let) neatly solved
> a ton of situations where Clojure often gets inelegantly nested, i.e.,
> interleavings of conditional tests with local variable definitions,
> protection against nil values, etc.
>
> I've been using this better cond ever since, for five years now, routinely,
> in my own code.  Once you start using this better cond, you'll never want to
> go back.
>
> Here's the implementation, for use in your own code:
> https://gist.github.com/Engelberg/9fc1264f938077cf03eee112ebed1768
>
> The most important ingredient here is the ability to put :let into your
> cond.  There has been a JIRA issue for this for nearly 7 years (it's a
> natural extension to cond, because :let is allowed in for clauses).  Given
> the incredible value this feature offers in terms of keeping code nice and
> "flat" as opposed to deeply nested/indented, I'm surprised it hasn't yet
> made it in to Clojure core.  Maybe soon, though, if enough people
> demonstrate that they care.  Go vote for this issue:
> http://dev.clojure.org/jira/browse/CLJ-200.

I can see a lot of use for this!  Thank you for pointing it out!

-John

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

[dominic]

> OTOH, you may encounter user- or externally-supplied data at runtime and 
want to use the facilities of spec to validate/process it. Then you can use 
valid? or conform *explicitly* to do so. 

With regards to this use-case, I was wondering if there were any plans for 
spec to allow for additional information to be passed to the predicates in 
some way?

A practical example for my question is user registration, I need to check 
that the new user's email isn't already taken by looking in the database. 

The methods I've come up with for working with spec are:
- To bind a dynamic variable (*db* for example) containing my database 
reference, and have the predicate use that for looking up the email value.
- This loses some locality in my code, and generally suggests a "bad 
code smell" in my experience.
- Update the user supplied data to include a reference to the db
- I feel like this complects between the data being validated, with the 
information required to perform a validation.

Any suggestions for how I can utilize spec for this scenario?

Dominic

On Wednesday, 25 May 2016 13:30:03 UTC+1, Rich Hickey wrote:
>
> > Would you ever expect to use fdef/instrument active in production for 
> validation 
>
> No, definitely not. It’s that kind of runtime checking (and expense) that 
> gives some dynamic lang checking systems a bad rep. 
>
> The philosophy is - generative testing has made sure your function 
> complies with the specs. So, testing the :ret and :fn properties over and 
> over is redundant and serves no point. 
>
>
>
> The intent is that running with wrappers (instrumentation) should be done 
> only during testing. 
>
> > On May 24, 2016, at 7:43 PM, Elliot > 
> wrote: 
> > 
> > Super super excited for this feature, thanks so much for creating this. 
> > 
> > In the runtime-validation case, the guide mentions: 
> > 
> > 1. Calling `valid?` in a precondition 
> > 2. Calling `conform` in the fn implementation 
> > 
> > However neither of these appear to use the `fdef`/`instrument` combo, 
> which seems the closest to "type annotating" the function.  Would you ever 
> expect to use fdef/instrument active in production for validation, or is 
> that a misunderstanding of its use? 
> > 
> > Thanks! 
> > 
> > - E 
> > 
> > 
> > On Tuesday, May 24, 2016 at 11:12:59 AM UTC-7, scott stackelhouse wrote: 
> > I restructured my data to make this section an optional sub-map, which I 
> think is actually better anyway. 
> > 
> > On Tuesday, May 24, 2016 at 11:08:27 AM UTC-7, scott stackelhouse wrote: 
> > Ok.   
> > 
> > Thanks all who have worked on this, btw.  It is incredibly timely for me 
> and is already great help for a work project. 
> > 
> > --Scott 
> > 
> > On Tuesday, May 24, 2016 at 10:57:26 AM UTC-7, Rich Hickey wrote: 
> > ‘and' and ‘or’ are not currently supported in :opt 
> > 
> > 
> > > On May 24, 2016, at 1:45 PM, scott stackelhouse <
> scott.sta...@gmail.com> wrote: 
> > > 
> > > I'm having a problem writing a spec for a map with some required 
> keywords and some optional keywords.  The caveat here is that the optional 
> keywords are all or none... that is they are optional but if one is present 
> they must all be present. 
> > > 
> > > What I tried to write was: 
> > > 
> > > (s/keys :req [::a ::b ::c] :opt [(and ::d ::e ::f)])   
> > > 
> > > and that fails an assertion.  It appears that the logicals (and, or) 
> are not allowed in the optional section? 
> > > 
> > > Am I thinking about this in the wrong way?   
> > > 
> > > --Scott 
> > > 
> > > -- 
> > > You received this message because you are subscribed to the Google 
> > > Groups "Clojure" group. 
> > > To post to this group, send email to clo...@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+u...@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+u...@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 clo...@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+u...@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+u...@googlegroups.com

Re: clojure.spec

[dominic]

Sorry if this is coming through a second time, I'm not having much luck 
with google groups.

> OTOH, you may encounter user- or externally-supplied data at runtime and 
want to use the facilities of spec to validate/process it. Then you can use 
valid? or conform *explicitly* to do so. 

Expanding on the use case of user-supplied data, would it be possible for 
predicates to have additional information in some way for this purpose? 
Sometimes you only have the information you need to validate data, at 
runtime.

For example user registration requires a check that the email isn't already 
registered. So to check it, you would need to provide a reference to the 
current database. Under the current api, I would need to make that db 
reference part of my data, or provide it through dynamic vars. Neither of 
these are ideal, as my database isn't part of the user-supplied data, and 
dynamic vars remove code locality. I think that, where possible, it's 
always best to pass all the arguments that a function needs.

Will the spec api open up for this in the future? Or is this not a scenario 
that spec will ever support?

On Wednesday, 25 May 2016 13:30:03 UTC+1, Rich Hickey wrote:
>
> > Would you ever expect to use fdef/instrument active in production for 
> validation 
>
> No, definitely not. It’s that kind of runtime checking (and expense) that 
> gives some dynamic lang checking systems a bad rep. 
>
> The philosophy is - generative testing has made sure your function 
> complies with the specs. So, testing the :ret and :fn properties over and 
> over is redundant and serves no point. 
>
> OTOH, you may encounter user- or externally-supplied data at runtime and 
> want to use the facilities of spec to validate/process it. Then you can use 
> valid? or conform *explicitly* to do so. 
>
> The intent is that running with wrappers (instrumentation) should be done 
> only during testing. 
>
> > On May 24, 2016, at 7:43 PM, Elliot  wrote: 
> > 
> > Super super excited for this feature, thanks so much for creating this. 
> > 
> > In the runtime-validation case, the guide mentions: 
> > 
> > 1. Calling `valid?` in a precondition 
> > 2. Calling `conform` in the fn implementation 
> > 
> > However neither of these appear to use the `fdef`/`instrument` combo, 
> which seems the closest to "type annotating" the function.  Would you ever 
> expect to use fdef/instrument active in production for validation, or is 
> that a misunderstanding of its use? 
> > 
> > Thanks! 
> > 
> > - E 
> > 
> > 
> > On Tuesday, May 24, 2016 at 11:12:59 AM UTC-7, scott stackelhouse wrote: 
> > I restructured my data to make this section an optional sub-map, which I 
> think is actually better anyway. 
> > 
> > On Tuesday, May 24, 2016 at 11:08:27 AM UTC-7, scott stackelhouse wrote: 
> > Ok.   
> > 
> > Thanks all who have worked on this, btw.  It is incredibly timely for me 
> and is already great help for a work project. 
> > 
> > --Scott 
> > 
> > On Tuesday, May 24, 2016 at 10:57:26 AM UTC-7, Rich Hickey wrote: 
> > ‘and' and ‘or’ are not currently supported in :opt 
> > 
> > 
> > > On May 24, 2016, at 1:45 PM, scott stackelhouse <
> scott.sta...@gmail.com> wrote: 
> > > 
> > > I'm having a problem writing a spec for a map with some required 
> keywords and some optional keywords.  The caveat here is that the optional 
> keywords are all or none... that is they are optional but if one is present 
> they must all be present. 
> > > 
> > > What I tried to write was: 
> > > 
> > > (s/keys :req [::a ::b ::c] :opt [(and ::d ::e ::f)])   
> > > 
> > > and that fails an assertion.  It appears that the logicals (and, or) 
> are not allowed in the optional section? 
> > > 
> > > Am I thinking about this in the wrong way?   
> > > 
> > > --Scott 
> > > 
> > > -- 
> > > You received this message because you are subscribed to the Google 
> > > Groups "Clojure" group. 
> > > To post to this group, send email to clo...@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+u...@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+u...@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 clo...@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+u...@googlegroups.com 
> > For more options, visit this group at 
> > http://groups.google.com/group/cl

vector of chars vs string

[Camilo Roca]

Hey guys,

First of all I would like to ask some thing. In clojure the following 
statements results in:
(identical? "foo" (str "f" "oo"))
;;=> false
> (= "foo" (str "f" "oo"))
;;=> true

Everything is ok with that. The next one on the other hand is what puzzles 
me:
(identical? \f (first (str "f" "oo")))
;;=> true

If what I guess is right, the amount of chars that exist are finite, thus 
Clojure treats them like a "pool of charts". The question is then why are 
not strings implemented as vectors of charts instead of using the 
underlying Java String class? As by using the Java String new allocations 
would have to be performed every time that a new string needs to be 
created, even if it contains exactly the same information of an existing 
string.

This might not be a big deal if the amount of strings is small of lazy 
produced, but (at least in my case) when I needed to load a relatively 
small text file (120 MB) fully into memory* then I started having memory 
problems as (from what I saw with YourKit) I had lots of repeated strings.

I would like to know your thoughts on this idea and implications/problems 
with it.


-- notes
* yes I know that I could lazily analyze the whole file and thus avoid 
having memory problems, but in some cases such as using sort-by or 
group-by, there is no other alternative than holding the whole thing and 
then process it.

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

[Beau Fabry]

You just need to come up with qualified names for them:

user=> (require '[clojure.spec :as s])
nil
user=> (s/def :base/attack (s/and integer? pos? #(<= % 1000)))
:base/attack
user=> (s/def :base/bonus (s/keys :req-un [:bonus/category]))
:base/bonus
user=> (s/valid? :base/event {:attack 100 :bonus {:category {:heavy 100}}})
true

Not sure about channels.

On Friday, May 27, 2016 at 12:36:56 AM UTC-7, Pedro Pereira Santos wrote:

> Hello,
>
> How can I differentiate between the same keyword, but with difference 
> semantics? Example:
>
> {:attack 100
>  :bonus {:attack {:category {:heavy 100
>
> I have:
> (s/def ::attack (s/and pos? #(<= 1 1000))
> (s/def ::bonus (s/keys :req-un [::attack ; <--- 
>
> Is there a way to do this?
>
> --
>
> Another question: is there a way to spec a fn that handles channels? 
> Something like:
>
> (s/fdef some-fn
>  :args (s/cat :ch (s/chan ::unq/model))
>  :ret (s/chan :unq/model))
>
> --
>
> And yet another: I have a game project with some test.check scenarios. The 
> test run takes 8s without instrumenting and 22s with instrumentation, and 
> this makes me think on starting to split tests in test suites. Is there 
> something to handle this in clojure.test?
>
> Thanks!
>
>
> On Thu, May 26, 2016 at 7:00 PM Beau Fabry > 
> wrote:
>
>> I'm in a similar position to you Wesley, I'm all for generative testing, 
>> but sometimes I prefer not to spec out the full depth of the tree (ie some 
>> input leaves with s/Any) and just turn on validation in staging and see 
>> what happens. The cpu-time wasted there doesn't matter much to me. Looking 
>> forward to seeing where things end up. Spec certainly seems really well 
>> thought through.
>>
>> Aside: Great work on the docs Alex. Much much more comprehensive and 
>> readable than is usually available for an alpha feature in *any* language.
>>
>>
>> On Thursday, May 26, 2016 at 6:57:24 AM UTC-7, Wesley Hall wrote:
>>>
>>> Thanks Rich, for this and your work in general. After 15 years of 
>>> working with Java, it has been a real joy to find clojure (let's face it, 
>>> that pun alone is pure gold!). 
>>>
>>> I might try my hand at the macrology you describe as an exercise... 
>>> everybody stand well back
>>>
>>> On Thursday, 26 May 2016 14:43:04 UTC+1, Rich Hickey wrote:

 If you name (register) your (sub)specs with s/def and you can reuse 
 them as much as you like. 

 (s/def ::argi (s/cat :i integer?)) 
 (s/def ::fnii (s/fspec :args ::argi :ret integer?)) 
 (s/conform ::fnii +) 
 (s/valid? ::argi '(42)) 

 However you are talking about calling ‘instrument’ so I don’t think you 
 are in the HOF case. So you shouldn’t be using fspec but fdef: 

 (s/fdef fooi :args (s/cat :i integer?) :ret integer?) 

 (defn fooi [i] 
   (let [spec (-> `fooi s/fn-specs :args)] 
 (assert (s/valid? spec (list i)) (s/explain-str spec (list i 
   42) 

 (fooi "42") 
 user=> AssertionError Assert failed: In: [0] val: "42" fails at: [:i] 
 predicate: integer? 

 Obviously some macrology could make this more succinct, as is being 
 discussed elsewhere. 

 > On May 26, 2016, at 9:17 AM, Wesley Hall  wrote: 
 > 
 > spec is not a contract system. 
 > 
 > Forgive me for I am about to sin :). 
 > 
 > I have a little RPC framework that I use to do simple remoting 
 between clojurescript in the browser and ring based web services. I'm 
 currently using schema to validate arguments received from clients and 
 return appropriate exceptions upon non-conforming invocations. 
 > 
 > The idea of being able to perform generative testing against a 
 specification for these functions is really appealing but if I am using 
 generative testing to verify that my functions behave properly if invoked 
 as intended it does feel like there would be some benefit to ensuring that 
 the conditions under which the function has been tested are enforced at 
 runtime for those functions on the edges of my API. 
 > 
 > I'd definitely prefer a manual conformity check over instrumentation 
 in these cases, but it seems like an fspec cannot be used for this purpose 
 (from within the function itself). I'd rather not define my specs twice. 
 > 
 > Seems like I might be destined to make cheeky instrument calls after 
 each of these edge functions, in the same was the always-validate metadata 
 is used in schema. 
 > 
 > Do I have a desperate need to be convinced otherwise? :) 
 > 
 > -- 
 > You received this message because you are subscribed to the Google 
 > Groups "Clojure" group. 
 > To post to this group, send email to clo...@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+u...@googlegroups.com 
 > Fo

Re: clojure.spec

[Pedro Santos]

Hello,

How can I differentiate between the same keyword, but with difference
semantics? Example:

{:attack 100
 :bonus {:attack {:category {:heavy 100

I have:
(s/def ::attack (s/and pos? #(<= 1 1000))
(s/def ::bonus (s/keys :req-un [::attack ; <---

Is there a way to do this?

--

Another question: is there a way to spec a fn that handles channels?
Something like:

(s/fdef some-fn
 :args (s/cat :ch (s/chan ::unq/model))
 :ret (s/chan :unq/model))

--

And yet another: I have a game project with some test.check scenarios. The
test run takes 8s without instrumenting and 22s with instrumentation, and
this makes me think on starting to split tests in test suites. Is there
something to handle this in clojure.test?

Thanks!


On Thu, May 26, 2016 at 7:00 PM Beau Fabry  wrote:

> I'm in a similar position to you Wesley, I'm all for generative testing,
> but sometimes I prefer not to spec out the full depth of the tree (ie some
> input leaves with s/Any) and just turn on validation in staging and see
> what happens. The cpu-time wasted there doesn't matter much to me. Looking
> forward to seeing where things end up. Spec certainly seems really well
> thought through.
>
> Aside: Great work on the docs Alex. Much much more comprehensive and
> readable than is usually available for an alpha feature in *any* language.
>
>
> On Thursday, May 26, 2016 at 6:57:24 AM UTC-7, Wesley Hall wrote:
>>
>> Thanks Rich, for this and your work in general. After 15 years of working
>> with Java, it has been a real joy to find clojure (let's face it, that pun
>> alone is pure gold!).
>>
>> I might try my hand at the macrology you describe as an exercise...
>> everybody stand well back
>>
>> On Thursday, 26 May 2016 14:43:04 UTC+1, Rich Hickey wrote:
>>>
>>> If you name (register) your (sub)specs with s/def and you can reuse them
>>> as much as you like.
>>>
>>> (s/def ::argi (s/cat :i integer?))
>>> (s/def ::fnii (s/fspec :args ::argi :ret integer?))
>>> (s/conform ::fnii +)
>>> (s/valid? ::argi '(42))
>>>
>>> However you are talking about calling ‘instrument’ so I don’t think you
>>> are in the HOF case. So you shouldn’t be using fspec but fdef:
>>>
>>> (s/fdef fooi :args (s/cat :i integer?) :ret integer?)
>>>
>>> (defn fooi [i]
>>>   (let [spec (-> `fooi s/fn-specs :args)]
>>> (assert (s/valid? spec (list i)) (s/explain-str spec (list i
>>>   42)
>>>
>>> (fooi "42")
>>> user=> AssertionError Assert failed: In: [0] val: "42" fails at: [:i]
>>> predicate: integer?
>>>
>>> Obviously some macrology could make this more succinct, as is being
>>> discussed elsewhere.
>>>
>>> > On May 26, 2016, at 9:17 AM, Wesley Hall  wrote:
>>> >
>>> > spec is not a contract system.
>>> >
>>> > Forgive me for I am about to sin :).
>>> >
>>> > I have a little RPC framework that I use to do simple remoting between
>>> clojurescript in the browser and ring based web services. I'm currently
>>> using schema to validate arguments received from clients and return
>>> appropriate exceptions upon non-conforming invocations.
>>> >
>>> > The idea of being able to perform generative testing against a
>>> specification for these functions is really appealing but if I am using
>>> generative testing to verify that my functions behave properly if invoked
>>> as intended it does feel like there would be some benefit to ensuring that
>>> the conditions under which the function has been tested are enforced at
>>> runtime for those functions on the edges of my API.
>>> >
>>> > I'd definitely prefer a manual conformity check over instrumentation
>>> in these cases, but it seems like an fspec cannot be used for this purpose
>>> (from within the function itself). I'd rather not define my specs twice.
>>> >
>>> > Seems like I might be destined to make cheeky instrument calls after
>>> each of these edge functions, in the same was the always-validate metadata
>>> is used in schema.
>>> >
>>> > Do I have a desperate need to be convinced otherwise? :)
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> > Groups "Clojure" group.
>>> > To post to this group, send email to clo...@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+u...@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+u...@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 pos