Re: RESTful API Auth with Friend and Liberator

[Bastien]

Sam Ritchie  writes:

> The code for that tutorial is all here:
>
> https://github.com/paddleguru/liberator-friend

Yes, thanks.

> PaddleGuru.com isn't open source, so I can't share any of the
> dashboards, unfortunately. Maybe some examples down the road.

Looking forward!

-- 
 Bastien

-- 
-- 
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/groups/opt_out.

Re: [ANN] - modern-cljs integrates a port on emacs of lt-cljs-tutorial By David Nolen

[Magomimmo]

It works on Eclipse/CCW too thanks to the recent CCW updates by Laurent 
Petit. 
mimmo

On Saturday, January 18, 2014 7:44:43 PM UTC+1, Magomimmo wrote:
>
> Hi all,
>
> the `modern-cljs` series 
>
> https://github.com/magomimmo/modern-cljs
>
> now includes a port for Emacs users 
>
> https://github.com/magomimmo/modern-cljs/tree/master/cljs-tutorial
>
> of the recent lt-cljs-tutorial - A ClojureScript Programming Language 
> Tutorial for Light Table Users
> by David Nolen.
>
> https://github.com/swannodette/lt-cljs-tutorial
>
> I consider `lt-cljs-tutorial` the best companion resource for the
> `modern-cljs` series because it represents the fastest path to start
> learning the ClojureScript Programming Language as is, in a very
> interactive way, and from the most competent guy for the language
> itself.
>
> For those not using Emacs or Light Table, it should be
> very easy to run the emacs port of the David's tutorial with any 
> editor/IDE supporting nREPL. The port has been generated by `cljs-start` 
> lein-temaplate which works without problem with CCW, so the ported tutorial 
> should work as well on it. 
>
> Enjoy
>
> Mimmo
>
>
>
>

-- 
-- 
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/groups/opt_out.

Re: oob schemas, re: The Language of the System

[Jonah Benton]

I read these self-describing, extensible points in the context of EDN,
which has a syntax/wire format for some types- maps, strings, etc- and also
has an extensibility syntax:

#myapp/Person {:first "Fred" :last "Mertz"}

These tagged elements are "extensions" because they allow values of types
not known to EDN to be included in the stream, and are "self-describing" in
two senses:

* if a wire format reader does know how to create a myapp/Person{}, that
blob of data contains all the information needed to do so
* if a wire format reader doesn't known how to create a myapp/Person, it
can still read past this particular element in the stream, because tags
have a defined envelope, so a reader can figure out where data comprising
this element ends

The JSON example is mostly about the "extensibility" attribute. JSON's
format natively supports some types (like strings) but not others (like
dates), and for those others, JSON's format does not include a way to
"bucket" or "envelope" data comprising those unknown types. So JSON is not
extensible.

The google example is mostly about the "self-describing" attribute, and to
my mind is more accurately framed as a statement about the Internet as a
whole. Hypothetically, if all data exchange occurred using data formats
whose details were private arrangements between writers and readers- for
instance, all servers only spoke ProtocolBuffers and used a different
schema for each client- there would be no Internet at all, much less a
google who as a third party is able to broadly read and understand data
made available by servers. (Or, to your point, any ability to parse
anything useful from a server data stream by clients lacking knowledge of
the schema would be at best be inferential and heuristic- possible, but
infeasible on a large scale.)

With all that said- my read is that Rich bundled those two points together
in the JSON date example- JSON doesn't have an extensibility syntax to
support dates, but people still have to transmit dates over JSON, so how do
they do that? One way is by adopting a  "convention", which in some ways is
better than an out of band schema, because, as you say, a convention gives
a reader additional information to heuristically interpret the stream, but
in other ways is worse because it isn't consistent- some people will want
date fields to look like "dateModified", others will want "modifiedDate",
and others use "modificationDatetime".

So in a broad sense, it is not desirable to use a data format that does not
include an extensibility capability which itself is self-describing,
because a format that lacks extensibility creates a combinatorial explosion
in conventions to convey values not known to the format, and extensions
that are not self-describing require out of band agreements between readers
and writers that can preclude the scalable third-party interoperability
that is so important to the Internet.

Hope that helps.


On Sat, Jan 18, 2014 at 6:08 PM, Brian Craft  wrote:

> Ok, so consider a different system (besides google) that handles the JSON
> example. If it has no prior knowledge of the date field, of what use is it
> to know that it's a date? What is a situation where a system reading the
> JSON needs to know a field is a date, but has no idea what the field is for?
>
>
> On Saturday, January 18, 2014 1:27:31 PM UTC-8, Jonas wrote:
>>
>> IIRC in that particular part of the talk he was specifically talking
>> about (non-self describing) protocol buffers and not JSON.
>>
>> On Saturday, January 18, 2014 10:00:09 PM UTC+2, Brian Craft wrote:
>>>
>>> Regarding Rich's talk (http://www.youtube.com/watch?v=ROor6_NGIWU), can
>>> anyone explain the points he's trying to make about self-describing and
>>> extensible data formats, with the JSON and google examples?
>>>
>>> He argues that google couldn't exist if the web depended on out-of-band
>>> schemas. He gives as an example of such a schema a JSON encoding where an
>>> out-of-band agreement is made that field names with substring "date" refer
>>> to string-encoded dates.
>>>
>>> However, this is exactly the sort of thing google does. It finds dates,
>>> and other data types, heuristically, and not through the formats of the web
>>> being self-describing or extensible.
>>>
>>>
>>> --
> --
> 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/groups/o

Redefining the notion of S-EXP, and pattern matching S-EXPs in clojure

[Dave Tenny]

As I try to reconcile my ancient past in writing common lisp code with a 
clojure learning exercise, 
I wonder whether clojure philosophy redefines the notion of an s-expression
or whether it just  adds vectors and maps to s-expressions in without 
trying to define what an s-expression is.

The question came up as I was looking for a certain capability in clojure 
libraries.

Back in the day when lisps had only parenthesized collection types, there 
were lisp libraries
(whose names I've long since forgotten) that would allow pattern matching 
of s-expressions,
so that you could describe a pattern, match it to some tree, pick up 
matches and continue to match some more.

Sort of like java.util.Matcher.find().

However with every clojure program (and program output) being a huge set of 
lists, vectors, and maps
I was looking for an s-exp matcher that would allow pattern expressions of 
and matching against paths of combinations of these data structures.

Sort of like enlive/select can traverse a nasty list/vector/map output of 
enlive/html-resource with predicates that will match a sequence of nodes in 
the web page.
(Only I don't think enlive/select returns matcher state that allows 
continuation from where you left off, maybe it does, and of course it's 
html oriented).

Looking at the clojure.walk and clojure.zip stuff, I don't see anything 
other than low level tools for certain kinds of traversals.

What libraries are there for higher level "reach in and grab patterns of 
data" abstractions that will work against a tree of lists/vectors/maps (and 
preferably any other walkable data structure in clojure)?

Looking for suggestions, and whatever philosophy there is about 
s-expressions in clojure like reader environments.

If I wanted lists, vectors, and maps with no zen, I'd be using python ;-)

Thanks!

-- 
-- 
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/groups/opt_out.

Re: oob schemas, re: The Language of the System

[Brian Craft]

That helps, thanks. It's still unclear to me that this is important enough 
to worry about. What application or service is hindered by string encoding 
a date in JSON? An example would really help. It's not compelling to assert 
or imagine some hypothetical application that benefits from knowing a field 
is a date without having any other knowledge of it. I would guess that 
cases where this matters are vanishingly few.


On Sunday, January 19, 2014 9:03:53 AM UTC-8, jonah wrote:
>
> I read these self-describing, extensible points in the context of EDN, 
> which has a syntax/wire format for some types- maps, strings, etc- and also 
> has an extensibility syntax:
>
> #myapp/Person {:first "Fred" :last "Mertz"}
>
> These tagged elements are "extensions" because they allow values of types 
> not known to EDN to be included in the stream, and are "self-describing" in 
> two senses:
>
> * if a wire format reader does know how to create a myapp/Person{}, that 
> blob of data contains all the information needed to do so
> * if a wire format reader doesn't known how to create a myapp/Person, it 
> can still read past this particular element in the stream, because tags 
> have a defined envelope, so a reader can figure out where data comprising 
> this element ends
>
> The JSON example is mostly about the "extensibility" attribute. JSON's 
> format natively supports some types (like strings) but not others (like 
> dates), and for those others, JSON's format does not include a way to 
> "bucket" or "envelope" data comprising those unknown types. So JSON is not 
> extensible. 
>
> The google example is mostly about the "self-describing" attribute, and to 
> my mind is more accurately framed as a statement about the Internet as a 
> whole. Hypothetically, if all data exchange occurred using data formats 
> whose details were private arrangements between writers and readers- for 
> instance, all servers only spoke ProtocolBuffers and used a different 
> schema for each client- there would be no Internet at all, much less a 
> google who as a third party is able to broadly read and understand data 
> made available by servers. (Or, to your point, any ability to parse 
> anything useful from a server data stream by clients lacking knowledge of 
> the schema would be at best be inferential and heuristic- possible, but 
> infeasible on a large scale.)
>
> With all that said- my read is that Rich bundled those two points together 
> in the JSON date example- JSON doesn't have an extensibility syntax to 
> support dates, but people still have to transmit dates over JSON, so how do 
> they do that? One way is by adopting a  "convention", which in some ways is 
> better than an out of band schema, because, as you say, a convention gives 
> a reader additional information to heuristically interpret the stream, but 
> in other ways is worse because it isn't consistent- some people will want 
> date fields to look like "dateModified", others will want "modifiedDate", 
> and others use "modificationDatetime".
>
> So in a broad sense, it is not desirable to use a data format that does 
> not include an extensibility capability which itself is self-describing, 
> because a format that lacks extensibility creates a combinatorial explosion 
> in conventions to convey values not known to the format, and extensions 
> that are not self-describing require out of band agreements between readers 
> and writers that can preclude the scalable third-party interoperability 
> that is so important to the Internet. 
>
> Hope that helps.
>
>
> On Sat, Jan 18, 2014 at 6:08 PM, Brian Craft 
> > wrote:
>
>> Ok, so consider a different system (besides google) that handles the JSON 
>> example. If it has no prior knowledge of the date field, of what use is it 
>> to know that it's a date? What is a situation where a system reading the 
>> JSON needs to know a field is a date, but has no idea what the field is for?
>>
>>
>> On Saturday, January 18, 2014 1:27:31 PM UTC-8, Jonas wrote:
>>>
>>> IIRC in that particular part of the talk he was specifically talking 
>>> about (non-self describing) protocol buffers and not JSON.  
>>>
>>> On Saturday, January 18, 2014 10:00:09 PM UTC+2, Brian Craft wrote:

 Regarding Rich's talk (http://www.youtube.com/watch?v=ROor6_NGIWU), 
 can anyone explain the points he's trying to make about self-describing 
 and 
 extensible data formats, with the JSON and google examples?

 He argues that google couldn't exist if the web depended on out-of-band 
 schemas. He gives as an example of such a schema a JSON encoding where an 
 out-of-band agreement is made that field names with substring "date" refer 
 to string-encoded dates.

 However, this is exactly the sort of thing google does. It finds dates, 
 and other data types, heuristically, and not through the formats of the 
 web 
 being self-describing or extensible.


 -- 
>> -- 
>> You received this m

Re: Redefining the notion of S-EXP, and pattern matching S-EXPs in clojure

[Jozef Wagner]

s-expression is a notation, with which nested lists can be represented in a
textual form. In any lisp language, your code is not working with
s-expressions, but with a data structure, which is most likely a cons.

s-expressions provide a convenient textual representation from which you
can *read* or into which you can *print*. As Clojure offers more than one
basic data structure for collections, it needs multiple notations in order
to textually represent a collection type alongside its contents. While
there is a cons type in Clojure, the clj syntax does not support
traditional s-expression syntax for cons, e.g.  (a . (b . NIL)). Closest
you can get is with (a b), which creates a list.

If your matcher does not need to differentiate between collection types,
you can treat all collections as sequences and that way you can uniformly
walk/transform any nested sequence.

JW


On Sun, Jan 19, 2014 at 6:40 PM, Dave Tenny  wrote:

> As I try to reconcile my ancient past in writing common lisp code with a
> clojure learning exercise,
> I wonder whether clojure philosophy redefines the notion of an s-expression
> or whether it just  adds vectors and maps to s-expressions in without
> trying to define what an s-expression is.
>
> The question came up as I was looking for a certain capability in clojure
> libraries.
>
> Back in the day when lisps had only parenthesized collection types, there
> were lisp libraries
> (whose names I've long since forgotten) that would allow pattern matching
> of s-expressions,
> so that you could describe a pattern, match it to some tree, pick up
> matches and continue to match some more.
>
> Sort of like java.util.Matcher.find().
>
> However with every clojure program (and program output) being a huge set
> of lists, vectors, and maps
> I was looking for an s-exp matcher that would allow pattern expressions of
> and matching against paths of combinations of these data structures.
>
> Sort of like enlive/select can traverse a nasty list/vector/map output of
> enlive/html-resource with predicates that will match a sequence of nodes in
> the web page.
> (Only I don't think enlive/select returns matcher state that allows
> continuation from where you left off, maybe it does, and of course it's
> html oriented).
>
> Looking at the clojure.walk and clojure.zip stuff, I don't see anything
> other than low level tools for certain kinds of traversals.
>
> What libraries are there for higher level "reach in and grab patterns of
> data" abstractions that will work against a tree of lists/vectors/maps (and
> preferably any other walkable data structure in clojure)?
>
> Looking for suggestions, and whatever philosophy there is about
> s-expressions in clojure like reader environments.
>
> If I wanted lists, vectors, and maps with no zen, I'd be using python ;-)
>
> Thanks!
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

OOP question re: The Language of the System

[Brian Craft]

http://www.youtube.com/watch?v=ROor6_NGIWU

Around 56:28 Rich is talking about whether components pass a data 
structure, or "an object that has all these verbs and knows how to do stuff 
...".

Clojure data types also have verbs, in protocols, and if one component 
passes a record to another component, the receiver will need to use those 
verbs to make use of the data. How is that different than the OOP example? 
There's the syntactic difference that in OOP you write it object, verb, 
arguments, and in clojure you write it verb, object, arguments. But that's 
trivial. How is it architecturally different to pass an object with methods 
vs passing a record with protocol?

-- 
-- 
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/groups/opt_out.

Re: OOP question re: The Language of the System

[James Reeves]

On 19 January 2014 19:55, Brian Craft  wrote:

> http://www.youtube.com/watch?v=ROor6_NGIWU
>
> Around 56:28 Rich is talking about whether components pass a data
> structure, or "an object that has all these verbs and knows how to do stuff
> ...".
>
> Clojure data types also have verbs, in protocols, and if one component
> passes a record to another component, the receiver will need to use those
> verbs to make use of the data. How is that different than the OOP example?
> There's the syntactic difference that in OOP you write it object, verb,
> arguments, and in clojure you write it verb, object, arguments. But that's
> trivial. How is it architecturally different to pass an object with methods
> vs passing a record with protocol?
>

Protocols should be considered a tool for polymorphism, rather than a tool
for encapsulation. You shouldn't consider protocols to be tightly coupled
to a record or type.

To give a more concrete example, consider a edn data structure like:

#inst "2014-01-19T21:44:46.471-00:00"

By default Clojure reads this as a java.util.Date object, but we could
equally read this as a org.joda.time.DateTime object, or
a hirondelle.date4j.DateTime object.

All these implementations describe the same data, but will have subtly
different methods and interfaces. The data structure serialised in edn
doesn't mandate a particular class, or a particular set of methods.

Similarly, if we imagine a data structure like:

#myapp/Person {:first "Fred" :last "Mertz"}

You should think of this as a map tagged with "#myapp/Person", not a
representation of a specific Clojure record that has a specific set of
functions. It's up to the receiver to interpret this data, and the
functions that operate on this data might differ between components. For
instance, a component that displays the data to the user might have a
function to derive a person's full name, but a component that archives the
data wouldn't need this functionality.

- James

-- 
-- 
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/groups/opt_out.

Re: oob schemas, re: The Language of the System

[Matching Socks]

Hmm, here's a date field that says "090715".  I wonder what it means...  

-- 
-- 
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/groups/opt_out.

Re: OOP question re: The Language of the System

[Timothy Baldridge]

A couple of things on this subject:

1) protocols were invented primarily for their speed. If one was going to
write Clojure in Clojure it would be a little hard to implement
PersistentHashMaps using pure data. You have to start with something. Thus
deftype and defprotocol were born.

2) Unlike in most OOP, the protocol methods are not tied to the object.
Instead they are tied to the function. You can see that with the function
clojure.core/extend. Extend says "when you call function A with a type T as
the first argument, dispatch to function B". This is quite a bit different
from normal polymorphism (especially in languages like Python/Ruby, etc).

3) Thirdly I'd say that using protocols/types for data is often considered
a bit un-idiomatic. For example, see the ClojureScript compiler:
https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/compiler.clj#L377

The AST of ClojureScript is stored in nested hashmaps, and dispatching is
done on the :op value in each map. No records, no protocols, no types. Just
hashmaps and multimethods. I would argue that this is the "Clojure way".
Use data, except when performance requirements dictate otherwise. Almost
everytime I've built a large codebase using protocols instead of
multimethods, I've regretted it. "Data all the things"...as the saying
goes.

Timothy Baldridge


On Sun, Jan 19, 2014 at 2:55 PM, James Reeves  wrote:

> On 19 January 2014 19:55, Brian Craft  wrote:
>
>> http://www.youtube.com/watch?v=ROor6_NGIWU
>>
>> Around 56:28 Rich is talking about whether components pass a data
>> structure, or "an object that has all these verbs and knows how to do stuff
>> ...".
>>
>> Clojure data types also have verbs, in protocols, and if one component
>> passes a record to another component, the receiver will need to use those
>> verbs to make use of the data. How is that different than the OOP example?
>> There's the syntactic difference that in OOP you write it object, verb,
>> arguments, and in clojure you write it verb, object, arguments. But that's
>> trivial. How is it architecturally different to pass an object with methods
>> vs passing a record with protocol?
>>
>
> Protocols should be considered a tool for polymorphism, rather than a tool
> for encapsulation. You shouldn't consider protocols to be tightly coupled
> to a record or type.
>
> To give a more concrete example, consider a edn data structure like:
>
> #inst "2014-01-19T21:44:46.471-00:00"
>
> By default Clojure reads this as a java.util.Date object, but we could
> equally read this as a org.joda.time.DateTime object, or
> a hirondelle.date4j.DateTime object.
>
> All these implementations describe the same data, but will have subtly
> different methods and interfaces. The data structure serialised in edn
> doesn't mandate a particular class, or a particular set of methods.
>
> Similarly, if we imagine a data structure like:
>
> #myapp/Person {:first "Fred" :last "Mertz"}
>
> You should think of this as a map tagged with "#myapp/Person", not a
> representation of a specific Clojure record that has a specific set of
> functions. It's up to the receiver to interpret this data, and the
> functions that operate on this data might differ between components. For
> instance, a component that displays the data to the user might have a
> function to derive a person's full name, but a component that archives the
> data wouldn't need this functionality.
>
> - James
>
> --
> --
> 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/groups/opt_out.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

cljx repetition

[t x]

Consider the following two code blocks:

(ns util.core
  #+clj  (:require [clojure.core.async :as async]
   [types])
  #+cljs (:require [cljs.core.async :as async]
   [types])
  #+cljs (:require-macros [cljs.core.async.macros :as async]))

(ns macros.lett
  #+clj (:require [macros.arrow :refer (=>)]
  [types])
  #+cljs (:require [macros.arrow])
  #+cljs (:require-macros [macros.arrow :refer (=>)]))

is there anyway here to reduce some of the repetition?

I realize it does not look like much, however I find that keeping track of
+clj and +cljs has been a source of bugginess (as the two constantly seems
to get out of sync).

## Concrete Question:

With cljx, is there someway, when requiring macros, to minimize repetition?

Thanks!

-- 
-- 
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/groups/opt_out.

Re: oob schemas, re: The Language of the System

[Patrick Logan]

"finds dates, and other data types, heuristically" -- I'm sure Google would 
rather not, but that's life on the web.

Google also supports JSON-LD which is a W3 standard for semi-structured and 
linked data. JSON-LD defines "in-band" syntax for dates, all XSD data 
types, and arbitrary data types (including but not exclusively those 
defined at http://schema.org/docs/full.html )



On Saturday, January 18, 2014 12:00:09 PM UTC-8, Brian Craft wrote:
>
> Regarding Rich's talk (http://www.youtube.com/watch?v=ROor6_NGIWU), can 
> anyone explain the points he's trying to make about self-describing and 
> extensible data formats, with the JSON and google examples?
>
> He argues that google couldn't exist if the web depended on out-of-band 
> schemas. He gives as an example of such a schema a JSON encoding where an 
> out-of-band agreement is made that field names with substring "date" refer 
> to string-encoded dates.
>
> However, this is exactly the sort of thing google does. It finds dates, 
> and other data types, heuristically, and not through the formats of the web 
> being self-describing or extensible.
>
>
>

-- 
-- 
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/groups/opt_out.

Re: OOP question re: The Language of the System

[Sam Ritchie]

can you elaborate on #3? What constraints did you run into with 
type-based dispatch that a multimethod that dispatched on :op allowed 
you to get around? It seems like, if that's your pattern, lifting the 
:op field up into an actual record type would only give you MORE 
freedom. You rely on the convention of a type, and the typeclass-like 
protocol dispatch, rather than re-inventing the identifier with an :op 
field.


Just curious as to what problems that records have caused (especially 
since you could write multimethods that dispatched on type and change 
that later if you actually do need the flexibility).



Timothy Baldridge 
January 19, 2014 5:10 PM
A couple of things on this subject:

1) protocols were invented primarily for their speed. If one was going 
to write Clojure in Clojure it would be a little hard to implement 
PersistentHashMaps using pure data. You have to start with something. 
Thus deftype and defprotocol were born.


2) Unlike in most OOP, the protocol methods are not tied to the 
object. Instead they are tied to the function. You can see that with 
the function clojure.core/extend. Extend says "when you call function 
A with a type T as the first argument, dispatch to function B". This 
is quite a bit different from normal polymorphism (especially in 
languages like Python/Ruby, etc).


3) Thirdly I'd say that using protocols/types for data is often 
considered a bit un-idiomatic. For example, see the ClojureScript 
compiler: 
https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/compiler.clj#L377


The AST of ClojureScript is stored in nested hashmaps, and dispatching 
is done on the :op value in each map. No records, no protocols, no 
types. Just hashmaps and multimethods. I would argue that this is the 
"Clojure way". Use data, except when performance requirements dictate 
otherwise. Almost everytime I've built a large codebase using 
protocols instead of multimethods, I've regretted it. "Data all the 
things"...as the saying goes.


Timothy Baldridge





--
“One of the main causes of the fall of the Roman Empire was 
that–lacking zero–they had no way to indicate successful termination 
of their C programs.”

(Robert Firth)
--
--
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/groups/opt_out.
James Reeves 
January 19, 2014 2:55 PM
On 19 January 2014 19:55, Brian Craft > wrote:


http://www.youtube.com/watch?v=ROor6_NGIWU

Around 56:28 Rich is talking about whether components pass a data
structure, or "an object that has all these verbs and knows how to
do stuff ...".

Clojure data types also have verbs, in protocols, and if one
component passes a record to another component, the receiver will
need to use those verbs to make use of the data. How is that
different than the OOP example? There's the syntactic difference
that in OOP you write it object, verb, arguments, and in clojure
you write it verb, object, arguments. But that's trivial. How is
it architecturally different to pass an object with methods vs
passing a record with protocol?


Protocols should be considered a tool for polymorphism, rather than a 
tool for encapsulation. You shouldn't consider protocols to be tightly 
coupled to a record or type.


To give a more concrete example, consider a edn data structure like:

#inst "2014-01-19T21:44:46.471-00:00"

By default Clojure reads this as a java.util.Date object, but we could 
equally read this as a org.joda.time.DateTime object, or 
a hirondelle.date4j.DateTime object.


All these implementations describe the same data, but will have subtly 
different methods and interfaces. The data structure serialised in edn 
doesn't mandate a particular class, or a particular set of methods.


Similarly, if we imagine a data structure like:

#myapp/Person {:first "Fred" :last "Mertz"}

You should think of this as a map tagged with "#myapp/Person", not a 
representation of a specific Clojure record that has a specific set of 
functions. It's up to the receiver to interpret this data, and the 
functions that operate on this data might differ between components. 
For instance, a component that displays the data to the user might 
have a function to derive a person's full name, but a component that 
archives 

Re: OOP question re: The Language of the System

[Softaddicts]

If you implement an API returning custom types or records, consumers
will have to adhere to the same implementation in their own implementations,

The so called freedom becomes a cage for others, they are stuck
with your implementation and it leaks out in places were they should not.

Using generic structures like maps an collections favors decoupling.
Consumers can decide how they want to handle this w/o having
your choice of implementation in their way. They can decide to take
a 180 degree approach if they wish so.

I restrict protocols, defrecords or deftypes to internal implementations
when performance, local mutation or extending base classes are required.
I never leak out these out of the API. Anything returned by the API
is made of generic values. Maps, collections, ...
Records or types are never carried away in another implementation
of something else.

The same in messages sent between systems.
No implementation details. Total decoupling.

Luc P.

> can you elaborate on #3? What constraints did you run into with 
> type-based dispatch that a multimethod that dispatched on :op allowed 
> you to get around? It seems like, if that's your pattern, lifting the 
> :op field up into an actual record type would only give you MORE 
> freedom. You rely on the convention of a type, and the typeclass-like 
> protocol dispatch, rather than re-inventing the identifier with an :op 
> field.
> 
> Just curious as to what problems that records have caused (especially 
> since you could write multimethods that dispatched on type and change 
> that later if you actually do need the flexibility).
> 
> > Timothy Baldridge 
> > January 19, 2014 5:10 PM
> > A couple of things on this subject:
> >
> > 1) protocols were invented primarily for their speed. If one was going 
> > to write Clojure in Clojure it would be a little hard to implement 
> > PersistentHashMaps using pure data. You have to start with something. 
> > Thus deftype and defprotocol were born.
> >
> > 2) Unlike in most OOP, the protocol methods are not tied to the 
> > object. Instead they are tied to the function. You can see that with 
> > the function clojure.core/extend. Extend says "when you call function 
> > A with a type T as the first argument, dispatch to function B". This 
> > is quite a bit different from normal polymorphism (especially i
> > languages like Python/Ruby, etc).
> >
> > 3) Thirdly I'd say that using protocols/types for data is often 
> > considered a bit un-idiomatic. For example, see the ClojureScript 
> > compiler: 
> > https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/compiler.clj#L377
> >
> > The AST of ClojureScript is stored in nested hashmaps, and dispatching 
> > is done on the :op value in each map. No records, no protocols, no 
> > types. Just hashmaps and multimethods. I would argue that this is the 
> > "Clojure way". Use data, except when performance requirements dictate 
> > otherwise. Almost everytime I've built a large codebase using 
> > protocols instead of multimethods, I've regretted it. "Data all the 
> > things"...as the saying goes.
> >
> > Timothy Baldridge
> >
> >
> >
> >
> >
> > -- 
> > “One of the main causes of the fall of the Roman Empire was 
> > that–lacking zero–they had no way to indicate successful termination 
> > of their C programs.”
> > (Robert Firth)
> > -- 
> > -- 
> > 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/groups/opt_out.
> > James Reeves 
> > January 19, 2014 2:55 PM
> > On 19 January 2014 19:55, Brian Craft  > > wrote:
> >
> > http://www.youtube.com/watch?v=ROor6_NGIWU
> >
> > Around 56:28 Rich is talking about whether components pass a data
> > structure, or "an object that has all these verbs and knows how to
> > do stuff ...".
> >
> > Clojure data types also have verbs, in protocols, and if one
> > component passes a record to another component, the receiver will
> > need to use those verbs to make use of the data. How is that
> > different than the OOP example? There's the syntactic difference
> > that in OOP you write it object, verb, arguments, and in clojure
> > you write it verb, object, arguments. But that's trivial. How is
> > it architecturally differ

Clojure development & laptop battery usage

[gvim]

Is it likely that a typical Clojure development environment:

- LightTable instarepl
- Luminus web app running within `lein ring server`

 will consume significantly more battery power than a typical Rails 
environment:


- Vim
- Rails app running within `rail server`

It's just that I've noticed my new-ish Macbook Pro doesn't last as long 
per charge as before I started development with Clojure and LightTable. 
I'm aware that the JVM allocates significantly more RAM by default and 
LightTable is RAM-hungry but I'm wondering if that implies increased 
power consumption? I'm on Mountain Lion so don't have the new Activity 
Monitor feature for checking this.


gvim


--
--
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/groups/opt_out.

Re: Clojure development & laptop battery usage

[Timothy Baldridge]

One thing that will totally kill MBP batter performance is if the system
decides do kick over to dedicated graphics. I highly recommend this app:
http://gfx.io/ It'll put an icon in the top right of your screen that shows
which GFX card is in use. On my 2012 MBP I get about 6 hours of life on the
integrated graphics and about 1.5 on heavy use with the dedicated graphics.

Now this all may sound like nonsense until you realize that LightTable is
based on Webkit and that the entire UI is rendered via a combination of Web
DOMs and Canvas objects. 9/10 times, a website using canvas will kick my
machine into dedicated GFX mode.

I wouldn't be surprised at all to see that a different editor would
dramatically improve battery life. On my MBP running Emacs LIVE (which has
never been accused of being light on CPU usage), I can get about 4-5 hours
of Clojure development before needing to plug in.

Hope this helps,

Timothy Baldridge


On Sun, Jan 19, 2014 at 7:52 PM, gvim  wrote:

> Is it likely that a typical Clojure development environment:
>
> - LightTable instarepl
> - Luminus web app running within `lein ring server`
>
>  will consume significantly more battery power than a typical Rails
> environment:
>
> - Vim
> - Rails app running within `rail server`
>
> It's just that I've noticed my new-ish Macbook Pro doesn't last as long
> per charge as before I started development with Clojure and LightTable. I'm
> aware that the JVM allocates significantly more RAM by default and
> LightTable is RAM-hungry but I'm wondering if that implies increased power
> consumption? I'm on Mountain Lion so don't have the new Activity Monitor
> feature for checking this.
>
> gvim
>
>
> --
> --
> 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/groups/opt_out.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
-- 
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/groups/opt_out.

Re: OOP question re: The Language of the System

[Jonah Benton]

I'm curious for the response re: #3 as well, but one pain point I've
experienced with protocols vs multimethods is that as a system evolves,
retaining the semantics that led me to bundle functions together into a
protocol in the first place has sometimes been difficult, a source of
incidental complexity. It winds up being easier and more coherent to
distribute multimethods between namespaces- even though initially going all
multimethods at the start feels less clean.



On Sun, Jan 19, 2014 at 7:37 PM, Sam Ritchie  wrote:

> can you elaborate on #3? What constraints did you run into with type-based
> dispatch that a multimethod that dispatched on :op allowed you to get
> around? It seems like, if that's your pattern, lifting the :op field up
> into an actual record type would only give you MORE freedom. You rely on
> the convention of a type, and the typeclass-like protocol dispatch, rather
> than re-inventing the identifier with an :op field.
>
> Just curious as to what problems that records have caused (especially
> since you could write multimethods that dispatched on type and change that
> later if you actually do need the flexibility).
>
>   Timothy Baldridge 
>  January 19, 2014 5:10 PM
> A couple of things on this subject:
>
> 1) protocols were invented primarily for their speed. If one was going to
> write Clojure in Clojure it would be a little hard to implement
> PersistentHashMaps using pure data. You have to start with something. Thus
> deftype and defprotocol were born.
>
> 2) Unlike in most OOP, the protocol methods are not tied to the object.
> Instead they are tied to the function. You can see that with the function
> clojure.core/extend. Extend says "when you call function A with a type T as
> the first argument, dispatch to function B". This is quite a bit different
> from normal polymorphism (especially in languages like Python/Ruby, etc).
>
> 3) Thirdly I'd say that using protocols/types for data is often considered
> a bit un-idiomatic. For example, see the ClojureScript compiler:
> https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/compiler.clj#L377
>
> The AST of ClojureScript is stored in nested hashmaps, and dispatching is
> done on the :op value in each map. No records, no protocols, no types. Just
> hashmaps and multimethods. I would argue that this is the "Clojure way".
> Use data, except when performance requirements dictate otherwise. Almost
> everytime I've built a large codebase using protocols instead of
> multimethods, I've regretted it. "Data all the things"...as the saying
> goes.
>
> Timothy Baldridge
>
>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
> --
> --
> 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/groups/opt_out.
>   James Reeves 
>  January 19, 2014 2:55 PM
> On 19 January 2014 19:55, Brian Craft  wrote:
>
>> http://www.youtube.com/watch?v=ROor6_NGIWU
>>
>> Around 56:28 Rich is talking about whether components pass a data
>> structure, or "an object that has all these verbs and knows how to do stuff
>> ...".
>>
>> Clojure data types also have verbs, in protocols, and if one component
>> passes a record to another component, the receiver will need to use those
>> verbs to make use of the data. How is that different than the OOP example?
>> There's the syntactic difference that in OOP you write it object, verb,
>> arguments, and in clojure you write it verb, object, arguments. But that's
>> trivial. How is it architecturally different to pass an object with methods
>> vs passing a record with protocol?
>>
>
> Protocols should be considered a tool for polymorphism, rather than a tool
> for encapsulation. You shouldn't consider protocols to be tightly coupled
> to a record or type.
>
> To give a more concrete example, consider a edn data structure like:
>
> #inst "2014-01-19T21:44:46.471-00:00"
>
> By default Clojure reads this as a java.util.Date object, but we could
> equally read this as a org.joda.time.DateTime object, or
> a hirondelle.date4j.DateTime object.
>
> All these implementations describe the same data, but will have subtly
> different methods and interfaces. The data structure serialised in edn
> doesn't mandate a particular class, or a particular se

Re: Clojure development & laptop battery usage

[gvim]

Good points about the graphics, Tim. Do you have any idea if the JVM's 
RAM requirement in itself takes more power from the system than 
developing, say, a Rails app in Vim? One pisser with my new-ish Macbook 
Pro is there's no such thing as a spare battery.


gvim



On 20/01/2014 03:47, Timothy Baldridge wrote:

One thing that will totally kill MBP batter performance is if the system
decides do kick over to dedicated graphics. I highly recommend this app:
http://gfx.io/ It'll put an icon in the top right of your screen that
shows which GFX card is in use. On my 2012 MBP I get about 6 hours of
life on the integrated graphics and about 1.5 on heavy use with the
dedicated graphics.

Now this all may sound like nonsense until you realize that LightTable
is based on Webkit and that the entire UI is rendered via a combination
of Web DOMs and Canvas objects. 9/10 times, a website using canvas will
kick my machine into dedicated GFX mode.

I wouldn't be surprised at all to see that a different editor would
dramatically improve battery life. On my MBP running Emacs LIVE (which
has never been accused of being light on CPU usage), I can get about 4-5
hours of Clojure development before needing to plug in.

Hope this helps,

Timothy Baldridge


--
--
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/groups/opt_out.

Re: Clojure development & laptop battery usage

[Mars0i]

fwiw, there is the option of developing Clojure in vim.  That's what I 
prefer at present--but everyone's needs and preferences are different.

(Also, probably not relevant, but I noticed that 'lein repl' eats up CPU 
even when it's not doing anything, if I start it in a directory without a 
Leiningen project.  No idea why.  Doesn't happen if I start a repl 
directly, without Leiningen.  Someone here probably knows why Leiningen 
does this.  Easy to fix, though: Don't do that!)

-- 
-- 
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/groups/opt_out.

MyType cannot be cast to MyType?

[Jonathan Barnard]

For fun, I've been porting a very simple particle animation from Java to 
Clojure. It was somewhat slow so to see how fast I could make it I decided 
to try using mutation. I've defined a Particle type, and a PSlice type that 
contains an array of objects and a length (number of non-nil objects in the 
slice), but when I try to provide type hints for this slice type, I get the 
error:

*ClassCastException MyProject.core.PSlice cannot be cast to *

*MyProject.core.PSlice *Is this a bug, or am I doing something wrong? My 
code defining the two types is:

(definterface IPt
  (^Double gx []) (^Double gy []) (^Double gz []) (^Double gvx []) (^Double 
gvy []) (^Double gvz []) (^Double gR []) (^Double glife []) (^Boolean gis 
[])
  (sx [^Double v]) (sy [^Double v]) (sz [^Double v]) (svx [^Double v]) (svy 
[^Double v]) (svz [^Double v]) (sR [^Double v]) (slife [^Double v]) 
(^Boolean sis [^Boolean v]))

(deftype Particle [^:unsynchronized-mutable ^Double x 
^:unsynchronized-mutable ^Double y ^:unsynchronized-mutable ^Double z 
   ^:unsynchronized-mutable ^Double vx 
^:unsynchronized-mutable ^Double vy ^:unsynchronized-mutable ^Double vz 
   ^:unsynchronized-mutable ^Double R 
^:unsynchronized-mutable ^Double life ^:unsynchronized-mutable ^Boolean is]
  IPt
  (gx [_] x) (gy [_] y) (gz [_] z) (gvx [_] vx) (gvy [_] vy) (gvz [_] vz) 
(gR [_] R) (glife [_] life) (gis [_] is)
  (sx [this v] (set! x v)) (sy [this v] (set! y v)) (sz [this v] (set! z v))
  (svx [this v] (set! vx v)) (svy [this v] (set! vy v)) (svz [this v] (set! 
vz v))
  (sR [this v] (set! R v)) (slife [this v] (set! life v)) (sis [this v] 
(set! is v)))

(definterface ISlice
  (^Long gLen [])
  (sLen [^Long x])
  (^Particle gPt [^Long n])
  (sPt [^Long n ^Particle pt] ))

(deftype PSlice [^"[Ljava.lang.Object;" pts ^:unsynchronized-mutable ^Long 
len]
  ISlice
  (gLen [_] len)
  (sLen [this new-len] (set! len new-len))
  (gPt [this n] (aget pts n))
  (sPt [this n pt] (aset pts n pt)))


Then the error occurs if I define a PSlice, such as by:

(def tslice (PSlice. (make-array Object 100) 0))

and a function:

(defn test-fn [^PSlice slice]
  (print (.gLen slice))
  )

Then call (test-fn tslice).

Note that the function will work as intended if no type hints are provided, 
but will run quite slowly due to reflection, defeating the point of using 
mutation.

-- 
-- 
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/groups/opt_out.

Re: OOP question re: The Language of the System

[Jonah Benton]

Will just add, in re: an earlier thread on this talk, one way to view this
is in re: the lifespan of the data.

Building and evolving the components that deal with live data passed around
between them is easier and more fluid when working with maps than with
working with types. One can add a field to a map without changing anything
else, often not so when adding a field to a class. Exposing data directly
in the data structure, rather than hiding it behind methods, forces better
data flow and management decisions and simplifies changes. The classic
example is of first and last name fields in a class that get combined in a
getFullName() method. Then something in the business rules changes and you
need to take a full name and decompose it into a first and last. Performing
changes like this is less work in a data flow design, more work in OO with
data encapsulation.

There are all sorts of decisions that one has to make with types when
working solely within an application that arguably create incidental
complexity. Types can bring more value at the edges- when exchanging data
between applications, and when persisting data in a durable form.

And as with the other responses- don't think of protocols as tied to the
data. They are not wrappers around data. Instead, think of them as their
name implies- protocols can be used to crisply describe how 2 components,
the caller and the callee, *participate* in an interaction (a "protocol")
around different concrete bundles of data. (Though as in the other
responses, it's probably often the case that the interactions are not
really that crisp, so multimethods are a better choice for polymorphism.)





On Sun, Jan 19, 2014 at 2:55 PM, Brian Craft  wrote:

> http://www.youtube.com/watch?v=ROor6_NGIWU
>
> Around 56:28 Rich is talking about whether components pass a data
> structure, or "an object that has all these verbs and knows how to do stuff
> ...".
>
> Clojure data types also have verbs, in protocols, and if one component
> passes a record to another component, the receiver will need to use those
> verbs to make use of the data. How is that different than the OOP example?
> There's the syntactic difference that in OOP you write it object, verb,
> arguments, and in clojure you write it verb, object, arguments. But that's
> trivial. How is it architecturally different to pass an object with methods
> vs passing a record with protocol?
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: OOP question re: The Language of the System

[Mars0i]

This is peripheral to the real focus of this thread, but it's worth noting 
the parallel between objects and closures.  You can implement encapsulation 
with closures--although it's less useful if without mutability.  Scheme was 
supposedly designed as a language for exploration of object-oriented 
systems.

user=> (defn two-accessors
 [n]
 (list
   (fn [] n)
   (fn [] (str n
#'user/two-accessors

user=> (def x (two-accessors 25.0001))
#'user/x

user=> ((first x))
25.0001

user=> ((second x))
"25.0001"

-- 
-- 
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/groups/opt_out.

binding / async / go

[t x]

Hi,

  Consider this piece of code:

(binding [*foo* 20]
  (async/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/groups/opt_out.

Re: Clojure development & laptop battery usage

[gvim]

On 20/01/2014 04:37, Mars0i wrote:

fwiw, there is the option of developing Clojure in vim.  That's what I
prefer at present--but everyone's needs and preferences are different.

(Also, probably not relevant, but I noticed that 'lein repl' eats up CPU
even when it's not doing anything, if I start it in a directory without
a Leiningen project.  No idea why.  Doesn't happen if I start a repl
directly, without Leiningen.  Someone here probably knows why Leiningen
does this.  Easy to fix, though: Don't do that!)



Yes, I prefer Vim though the Clojure/Lisp Emacs tradition may be worth 
investigating. LightTable 6 is just too resource-hungry running on a 
Macbook Pro. I'm out a lot and can't always plug in so battery life is a 
critical factor. I'm not sure I can work outside Leiningen, though. It 
seems to be as much a part of the Clojure development process as anything.


gvim

--
--
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/groups/opt_out.

Re: Clojure development & laptop battery usage

[john walker]

The JVM hasn't been receiving the love it deserves lately! Fortunately, 
percent memory usage isn't going to have any effect on battery life until 
you hit swap. The resources you should consider are just activity on the 
cpu/gpu/disk.

So yeah, it's light table. It's not its fault for being released ~2014.

On Sunday, January 19, 2014 10:55:45 PM UTC-5, g vim wrote:
>
> Good points about the graphics, Tim. Do you have any idea if the JVM's 
> RAM requirement in itself takes more power from the system than 
> developing, say, a Rails app in Vim? One pisser with my new-ish Macbook 
> Pro is there's no such thing as a spare battery. 
>
> gvim 
>
>
>
> On 20/01/2014 03:47, Timothy Baldridge wrote: 
> > One thing that will totally kill MBP batter performance is if the system 
> > decides do kick over to dedicated graphics. I highly recommend this app: 
> > http://gfx.io/ It'll put an icon in the top right of your screen that 
> > shows which GFX card is in use. On my 2012 MBP I get about 6 hours of 
> > life on the integrated graphics and about 1.5 on heavy use with the 
> > dedicated graphics. 
> > 
> > Now this all may sound like nonsense until you realize that LightTable 
> > is based on Webkit and that the entire UI is rendered via a combination 
> > of Web DOMs and Canvas objects. 9/10 times, a website using canvas will 
> > kick my machine into dedicated GFX mode. 
> > 
> > I wouldn't be surprised at all to see that a different editor would 
> > dramatically improve battery life. On my MBP running Emacs LIVE (which 
> > has never been accused of being light on CPU usage), I can get about 4-5 
> > hours of Clojure development before needing to plug in. 
> > 
> > Hope this helps, 
> > 
> > Timothy Baldridge 
>

-- 
-- 
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/groups/opt_out.

Re: Clojure development & laptop battery usage

[gvim]

On 20/01/2014 05:43, john walker wrote:

The JVM hasn't been receiving the love it deserves lately! Fortunately,
percent memory usage isn't going to have any effect on battery life
until you hit swap. The resources you should consider are just activity
on the cpu/gpu/disk.

So yeah, it's light table. It's not its fault for being released ~2014.


Ah, good. So RAM usage is irrelevant as far as battery life goes. I can 
use Vim instead of LightTable so problem solved.


gvim

--
--
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/groups/opt_out.

Re: binding / async / go

[Timothy Baldridge]

That works just fine on my box, infact, core.async's test code includes
checking that dynamic vars actually work.

Timothy


On Sun, Jan 19, 2014 at 10:11 PM, t x  wrote:

> Hi,
>
>   Consider this piece of code:
>
> (binding [*foo* 20]
>   (async/(async/go
> (+ 1 2 *foo*
>
>
>   From this, it follows that binding and async/go do not work together
> (probably due to the go block running in another thread).
>
> ## Question: Is there anyway to pass a _dynamic_ var to a go block?
>
> Thanks!
>
> --
> --
> 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/groups/opt_out.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
-- 
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/groups/opt_out.

Re: binding / async / go

[t x]

It also works for me now.

Problem: I'm an idiot and forgot to write:

(def ^:dynamic *foo*).




On Sun, Jan 19, 2014 at 9:54 PM, Timothy Baldridge wrote:

> That works just fine on my box, infact, core.async's test code includes
> checking that dynamic vars actually work.
>
> Timothy
>
>
> On Sun, Jan 19, 2014 at 10:11 PM, t x  wrote:
>
>> Hi,
>>
>>   Consider this piece of code:
>>
>> (binding [*foo* 20]
>>   (async/>(async/go
>> (+ 1 2 *foo*
>>
>>
>>   From this, it follows that binding and async/go do not work together
>> (probably due to the go block running in another thread).
>>
>> ## Question: Is there anyway to pass a _dynamic_ var to a go block?
>>
>> Thanks!
>>
>> --
>> --
>> 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/groups/opt_out.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

cljs / format

[t x]

Hi,

  Does cljs provide anything like format?

  I do not need it to provide the same output as clojure's format.

  I just want to write things like:

  (format " ... % ... % ... %  ... " arg1 arg2 arg3 )

  rather than:

  (str "..." arg1 "..." arg2 "..." arg3 ...)

Thanks!

-- 
-- 
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/groups/opt_out.

Re: cljs / format

[john walker]

Kind of ..? Based off the discussion, it's probably better not to, but the 
closure library provides an implementation that's trivial to wrap 
(accepting the problems).

Discussion:
 http://dev.clojure.org/jira/browse/CLJS-324

Example:
https://www.refheap.com/19693

On Monday, January 20, 2014 1:31:06 AM UTC-5, t x wrote:
>
> Hi,
>
>   Does cljs provide anything like format?
>
>   I do not need it to provide the same output as clojure's format.
>
>   I just want to write things like:
>
>   (format " ... % ... % ... %  ... " arg1 arg2 arg3 )
>
>   rather than:
>
>   (str "..." arg1 "..." arg2 "..." arg3 ...)
>
> Thanks!
>

-- 
-- 
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/groups/opt_out.

Re: concat/forth in ->, ->>

[Brandon Bloom]

It's worth noting that the -> and ->> macros are just that: macros. They 
have lexical extent and are expanded at compile time.

Factjor is (essentially) interpreted, but can be used in interesting higher 
order ways. For example, you can write functions that return lazy sequences 
of Factjor instructions. The idea of sequences-as-concatenative-programs, 
called "quotations", is best explored by downloading Factor and tinkering 
with the (excellent!) environment & live/interactive 
docs: http://factorcode.org/

When I presented Factjor at Clojure/West a while back, quite a few people 
mentioned to me that they were reminded of the threading macros. I never 
attempted to do this, but in theory it wouldn't be too hard to create a 
macro that does (naive) partial evaluation of concatenative code at 
expansion time!

If you attempt it, I'd love to see what you come up with :-)

On Saturday, January 18, 2014 7:01:52 PM UTC-5, Nicola Mometto wrote:
>
> I don't know if that's what you're asking for, but there's 
> https://github.com/brandonbloom/factjor 
>
> t x writes: 
>
> > Hi, 
> > 
> >   Despite the title and content of this email, this is a serious, non 
> > joking (i.e. brainfuck) question. 
> > 
> > After studying 
> > https://github.com/rplevy/swiss-arrows/blob/master/src/swiss/arrows.cljfor 
> > a bit, it hit me: 
> > 
> > -> and ->> are special cases of forth machines, where there is a stack, 
> > which always has exactly one item. 
> > 
> > Thus, when we have something like 
> > (-> init 
> >   instr1 
> >   instr2 
> >   ... instr k ... ) 
> > 
> > what happens is that "init" is pushed onto the stack, then for each $i$, 
> we 
> > pop the top item off the stack, pass it to (instr i), then push the 
> value 
> > back on the stack. 
> > 
> > 
> > Now, if take a few steps back and squint, we ask: why is it that we only 
> > have one item on the stack? why not multiple items on the stack -- and 
> now, 
> > suddenly, we are approaching forth. 
> > 
> > Thus, in a completely serious question -- is there any clojure 
> > threading-macro DSL basically provides a forth-like? 
> > 
> > -- 
>

-- 
-- 
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/groups/opt_out.

New Functional Programming Job Opportunities

[Functional Jobs]

Here are some functional programming job opportunities that were posted

recently:



Software Developer at Xively

http://functionaljobs.com/jobs/8676-software-developer-at-xively



Cheers,

Sean Murphy

FunctionalJobs.com


-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Redefining the notion of S-EXP, and pattern matching S-EXPs in clojure

[Dom Kiva-Meyer]

I'm not sure if this is what you're looking for, but seqex (
https://github.com/jclaggett/seqex) might be of use.


On Sun, Jan 19, 2014 at 9:40 AM, Dave Tenny  wrote:

> As I try to reconcile my ancient past in writing common lisp code with a
> clojure learning exercise,
> I wonder whether clojure philosophy redefines the notion of an s-expression
> or whether it just  adds vectors and maps to s-expressions in without
> trying to define what an s-expression is.
>
> The question came up as I was looking for a certain capability in clojure
> libraries.
>
> Back in the day when lisps had only parenthesized collection types, there
> were lisp libraries
> (whose names I've long since forgotten) that would allow pattern matching
> of s-expressions,
> so that you could describe a pattern, match it to some tree, pick up
> matches and continue to match some more.
>
> Sort of like java.util.Matcher.find().
>
> However with every clojure program (and program output) being a huge set
> of lists, vectors, and maps
> I was looking for an s-exp matcher that would allow pattern expressions of
> and matching against paths of combinations of these data structures.
>
> Sort of like enlive/select can traverse a nasty list/vector/map output of
> enlive/html-resource with predicates that will match a sequence of nodes in
> the web page.
> (Only I don't think enlive/select returns matcher state that allows
> continuation from where you left off, maybe it does, and of course it's
> html oriented).
>
> Looking at the clojure.walk and clojure.zip stuff, I don't see anything
> other than low level tools for certain kinds of traversals.
>
> What libraries are there for higher level "reach in and grab patterns of
> data" abstractions that will work against a tree of lists/vectors/maps (and
> preferably any other walkable data structure in clojure)?
>
> Looking for suggestions, and whatever philosophy there is about
> s-expressions in clojure like reader environments.
>
> If I wanted lists, vectors, and maps with no zen, I'd be using python ;-)
>
> Thanks!
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.

Re: liberator video, compression question

[Philipp Meier]

Hi,

Am Sonntag, 19. Januar 2014 03:04:40 UTC+1 schrieb Benjamin R. Haskell:
>
> On Sat, 18 Jan 2014, Brian Craft wrote: 
>
> > http://www.youtube.com/watch?v=OEZZOz6__CY 
> > 
> > At about 30 min he mentions that gzip, etc. aren't so interesting here 
> > because we can use, um.. something transfer, proxies... don't know 
> > what he's saying. Anyone know what he's talking about? 
>
> Slide for context: 
>
> {:media-type "application/edn" 
>   :language "de" 
>   :charset "UTF-8" 
>   :encoding "deflate"} 
>
> With that on-screen, he says: 
>
> """ 
> ...and we have an encoding, which can be for example, deflate or gzip or 
> like that, um, which we don't care about a lot, I think, on this side of 
> the 
> server, because we can use like transparent proxies to do all those 
> on-the-fly gzip things for us, but it's possible. 
> """ 
>
> Presumably, he's talking about something like putting a Clojure app 
> behind an nginx frontend server, where handling gzip is as simple as 
> adding 'gzip on;' to the 'server {}' configuration block.  (So, you 
> don't care about gzip'ing on the Clojure side of the application, you 
> care about it on the transparent-proxying-server side.)  
>

Yes, that's exactly what I meant in the talk. Liberator can negotiate the 
content 
encoding but I does not implement any out of the box. If you really want to 
do it
in your liberator resource, you'd need to implement it in your handler 
function
and must not forget to set the "content-encoding" header.

However, it is much easier to delegate this to a transparent proxy. If you
want to have a ring-only system, then 
https://github.com/mikejs/ring-gzip-middleware
might be a way to implement content-encoding lightweight.

-billy.

-- 
-- 
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/groups/opt_out.

clojure meetups / Stanford

[t x]

Hi,

  (apologies for spamming non-bay area people)

  Is there an official site listing Clojure study-groups / meetups?

  In particular, I'm looking for one close to Stanford (i.e. wouldn't mind
meeting in Gates) and focused on sharing cool Clojure/CLJS/macro tricks
over lunch / dinner.

Thanks!

-- 
-- 
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/groups/opt_out.

Re: clojure meetups / Stanford

[Andy Fingerhut]

There is this list of Clojure user groups:
http://dev.clojure.org/display/community/Clojure+User+Groups

You can go to meetup.com and search for Clojure.  There are several
meetings per month in the Bay area, in San Francisco and San Mateo, usually.

There is also the #clojure IRC channel, which is a bit more interactive
than a typical mailing list.

Andy


On Sun, Jan 19, 2014 at 11:46 PM, t x  wrote:

> Hi,
>
>   (apologies for spamming non-bay area people)
>
>   Is there an official site listing Clojure study-groups / meetups?
>
>   In particular, I'm looking for one close to Stanford (i.e. wouldn't mind
> meeting in Gates) and focused on sharing cool Clojure/CLJS/macro tricks
> over lunch / dinner.
>
> Thanks!
>
> --
> --
> 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/groups/opt_out.
>

-- 
-- 
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/groups/opt_out.