Re: Introducing Boot v2 with a streamlined CLJS workflow

[Laurent PETIT]

yes, it's working now, thanks

2014-11-06 0:28 GMT+01:00 Alan Dipert :

> Hi Laurent,
> The boot-cljs-example has started to move ahead of the blog post, and
> includes an optional 'serve' task.
>
> There was a bug in the boot-cljs task that was deleting index.html
> erroneously; I pushed a new version and updated boot-cljs-example.
>
> If you `boot -u` to update boot (which was also updated today) and fetch
> latest from boot-cljs-example, there's a decent chance it will actually
> work :-)
> Alan
>
>
> On Wednesday, November 5, 2014 5:07:04 PM UTC-5, Laurent PETIT wrote:
>>
>> Alternatively, if I follow instructions from https://github.com/
>> adzerk/boot-cljs-example ,
>>
>> then there's no mention of target/index.html, so I directly jump to
>> http://localhost:3000/ but I get an HTTP 404, so same problem there I
>> think.
>>
>> command is different than from the blog post:
>>
>> $ boot serve -d target/ watch speak cljs-repl cljs -usO none reload
>> Retrieving ring-jetty-adapter-1.3.1.jar from http://clojars.org/repo/
>> Retrieving ring-core-1.3.1.jar from http://clojars.org/repo/
>> Retrieving clj-time-0.6.0.jar from http://clojars.org/repo/
>> Retrieving crypto-random-1.2.0.jar from http://clojars.org/repo/
>> Retrieving crypto-equality-1.0.0.jar from http://clojars.org/repo/
>> Retrieving ring-servlet-1.3.1.jar from http://clojars.org/repo/
>> Retrieving compojure-1.2.1.jar from http://clojars.org/repo/
>> Retrieving clout-2.0.0.jar from http://clojars.org/repo/
>> Retrieving instaparse-1.3.4.jar from http://clojars.org/repo/
>> Retrieving medley-0.5.3.jar from http://clojars.org/repo/
>> Retrieving ring-codec-1.0.0.jar from http://clojars.org/repo/
>> Retrieving tools.reader-0.8.1.jar from http://repo1.maven.org/maven2/
>> Retrieving commons-fileupload-1.3.jar from http://repo1.maven.org/maven2/
>> Retrieving jetty-server-7.6.13.v20130916.jar from
>> http://repo1.maven.org/maven2/
>> Retrieving javax.servlet-2.5.0.v201103041518.jar from
>> http://repo1.maven.org/maven2/
>> Retrieving joda-time-2.2.jar from http://repo1.maven.org/maven2/
>> Retrieving jetty-continuation-7.6.13.v20130916.jar from
>> http://repo1.maven.org/maven2/
>> Retrieving jetty-http-7.6.13.v20130916.jar from
>> http://repo1.maven.org/maven2/
>> Retrieving jetty-io-7.6.13.v20130916.jar from
>> http://repo1.maven.org/maven2/
>> Retrieving jetty-util-7.6.13.v20130916.jar from
>> http://repo1.maven.org/maven2/
>> Retrieving tools.macro-0.1.5.jar from http://repo1.maven.org/maven2/
>> Retrieving commons-codec-1.6.jar from http://repo1.maven.org/maven2/
>> << started reload server on ws://localhost:8090 >>
>> 2014-11-05 22:59:51.865:INFO:oejs.Server:jetty-7.6.13.v20130916
>> 2014-11-05 22:59:51.928:INFO:oejs.AbstractConnector:Started
>> SelectChannelConnector@0.0.0.0:3000
>> << started web server on http://localhost:3000 (serving: target/) >>
>> Starting file watcher (CTRL-C to quit)...
>>
>> nREPL server listening: 0.0.0.0:50475
>> Compiling main.js...
>> Adding 

Re: how clojure infers types.

[Gary Verhaegen]

First of all, remember that Clojure usually assumes that the programmer is
right and the program is correct, especially when not doing so would incur
a performance penalty.

It's important to remember what we are doing here. The Clojure compiler
wants to emit the correct method call, and lets the Java runtime deal with
type errors. So the point of type inference and type hints is to select the
correct method.

In most (?) cases, the method name is known. This leaves only two potential
problems: unknown class, or, if the class is known and the method has
multiple definitions, unknown parameter types.

There is no inference at all in your two working examples, just the
assumption that the programmer is infaillible.

As to what Clojure infers: basically nothing. I don't think there is any
inference at all in the compiler; it simply trusts type hints and assumes
Object otherwise. It does *locally* respect Java interop return types, but
this is strictly local (remembe that the unit of compilation is essentially
a single function - if you don't type hint its return value, Clojure will
not try to do it for you).

I would personally solve your problem by isolating the interop call inside
a function:

(defn get-owl-equivalent-classes-action
  [^OWLDataFactory fact ^java.util.Set arg1 ^java.util.Set arg2]
  (.getOWLEquivalentClassesActions arg1 arg2))

If the factory is not shared/reused you could of course create it inside
the method.


On a related note, Clojure itself does not rely on type hints or type
inference for (Clojure) function calls, so the vast majority of Clojure
functions are not type hinted. I have no idea whether this is deliberate
(i.e. whether there would be a cost to doing it beside the man-hours it
would take). Maybe you could suggest that as an enhancement?

On Wednesday, 5 November 2014, Phillip Lord 
wrote:

>
> Ah, okay. I thought it might be this.
>
> Not that I don't trust you, though, but how do you know this? Is there a
> good way of finding out what clojure has infered or not? tools.analyzer?
> I'm thinking from a point of view of the developer trying to get his
> type hints sorted.
>
> Phil
>
> Nicola Mometto > writes:
>
> > The reason why that call doesn't require reflection is that
> > Collection.unmodifiableSet has no overloaded methods, it only takes a
> > Set so the compiler doesn't have to disambiguate between different
> > signatures.
> >
> > Phillip Lord writes:
> >
> >> Yes, I checked the code.
> >>
> >> (defn set
> >>   "Returns a set of the distinct elements of coll."
> >>   {:added "1.0"
> >>:static true}
> >>   [coll] (clojure.lang.PersistentHashSet/create (seq coll)))
> >>
> >> And that was my first assumption. But if clojure doesn't know the return
> >> type, then why does this:
> >>
> >> (defn two []
> >>   (java.util.Collections/unmodifiableSet
> >>(set [])))
> >>
> >> Not require reflection? Clojure should not know which method to call.
> >> Unless it is just because unmodifiableSet has an arity of one and it's
> >> the only arity of one, so it doesn't try to disambiguate.
> >>
> >> I guess even if set was type hinted (to IPersistentSet) it would still
> >> not work since, IPersistentSet is not assignable from java.util.Set.
> >>
> >> Phil
> >>
> >>
> >>
> >> Nicola Mometto > writes:
> >>
> >>> Actually `set` and a lot of other clojure.core functions are neither
> >>> inlineable nor have type hints.
> >>>
> >>> Phillip Lord writes:
> >>>
>  I have a piece of code that looks like this
> 
>  (.getOWLEquivalentClassesAxiom
>    (owl-data-factory)
>    (set classlist)
>    (union-annotations classlist))
> 
>  The method signature is
> 
>  getOWLEquivalentClassesAxiom(Set,Set)
> 
>  On runing lein check I get
> 
> 
>  Reflection warning, tawny/owl.clj:2219:6 - call to method
>  getOWLEquivalentClassesAxiom on
>  org.semanticweb.owlapi.model.OWLDataFactory can't be resolved
> (argument
>  types: unknown, java.util.Set).
> 
>  which makes no sense. Surely, the return type of clojure.core/set is
>  known to be java.util.Set? I have quite a few calls like this in my
>  code, which is why I don't want to type hint the return of set
>  individually.
> 
>  If I add a function like so:
> 
>  (defn ^java.util.Set hset [coll]
>    (set coll))
> 
>  and call like this:
> 
>  (.getOWLEquivalentClassesAxiom
>    (owl-data-factory)
>    (hset classlist)
>    (union-annotations classlist))
> 
>  The reflection warning goes away.
> 
> 
>  I've tried to reproduce this with simpler cases, like so:
> 
> 
>  (defn one []
>    (java.util.Collections/unmodifiableSet
> (java.util.HashSet.)))
> 
> 
>  (defn two []
>    (java.util.Collections/unmodifiableSet
> (set [])))
> 
>  But both of these pass lein check just fine. Which suggests that
> clojure
> >

Re: Dependency problem between clj-http and com.cemerick/friend

[Christian Egli]

Andy Fingerhut  writes:

> Try running 'lein deps :tree >& deps.txt' in each of those projects,
> and diff them. I can't explain why the differences are there that
> exist, but there are significant differences, including in version
> numbers of some of the dependencies brought in.
>
> Asking on the Leiningen email list or #clojure IRC channel may be more
> fruitful.

Thanks for you answer. Further research indicates that the order of the
dependencies does matter (at least for transitive dependencies). Both
friend and clj-httpclient depend on org.apache.httpcomponents/httpclient,
so if friend comes first in the dependency vector lein will fetch
version 4.2.1. However if clj-httpclient comes first lein will fetch
version 4.3.5.

I guess there are two ways out of this:

1. change the order so that clj-httpclient comes first
2. file a bug report with friend

For my project I changed the order and I just filed a bug with friend
(https://github.com/cemerick/friend/issues/128). In fact there is even
already a pull request that adresses this issue.

Thanks
Christian

-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

-- 
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: Dependency problem between clj-http and com.cemerick/friend

[Plínio Balduino]

Christian

I just forked friend, updated the library versions and opened a pull
request.

If you want to try and see if the problem still happens, please check
https://github.com/pbalduino/friend

Please note that it's not the official Friend repository, it's not intended
to be a replacement and I'm going to remove it as soon as the pull request
be accepted, if accepted.

Note also that I changed the version to 0.2.3-SNAPSHOT to avoid conflicts
with official Friend binary.

Anyway we could validate together to ensure that we won't have any problems
with different third-party libraries.

Regards

Plínio Balduino

On Thu, Nov 6, 2014 at 9:47 AM, Christian Egli 
wrote:

> Andy Fingerhut  writes:
>
> > Try running 'lein deps :tree >& deps.txt' in each of those projects,
> > and diff them. I can't explain why the differences are there that
> > exist, but there are significant differences, including in version
> > numbers of some of the dependencies brought in.
> >
> > Asking on the Leiningen email list or #clojure IRC channel may be more
> > fruitful.
>
> Thanks for you answer. Further research indicates that the order of the
> dependencies does matter (at least for transitive dependencies). Both
> friend and clj-httpclient depend on org.apache.httpcomponents/httpclient,
> so if friend comes first in the dependency vector lein will fetch
> version 4.2.1. However if clj-httpclient comes first lein will fetch
> version 4.3.5.
>
> I guess there are two ways out of this:
>
> 1. change the order so that clj-httpclient comes first
> 2. file a bug report with friend
>
> For my project I changed the order and I just filed a bug with friend
> (https://github.com/cemerick/friend/issues/128). In fact there is even
> already a pull request that adresses this issue.
>
> Thanks
> Christian
>
> --
> Christian Egli
> Swiss Library for the Blind, Visually Impaired and Print Disabled
> Grubenstrasse 12, CH-8045 Zürich, Switzerland
>
> --
> 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: Dependency problem between clj-http and com.cemerick/friend

[Christian Egli]

Hi Plínio

Plínio Balduino  writes:

> I just forked friend, updated the library versions and opened a pull
> request.
>
> If you want to try and see if the problem still happens, please check
> https://github.com/pbalduino/friend

AFAIK the problem I have with friends dependencies is not the fact that
it depends on an old version of clj-http but that it depends on an old
version of org.apache.httpcomponents/httpclient. So I think your commit
(https://github.com/pbalduino/friend/commit/926f01ba718c355c82faad4aa0438162708a1efb)
will not help with that.

Thanks
Christian

-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

-- 
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: Dependency problem between clj-http and com.cemerick/friend

[Plínio Balduino]

I noticed that. You're correct.

I updated my local copy of httpclient to 4.3.5

Plínio

On Thu, Nov 6, 2014 at 11:23 AM, Christian Egli 
wrote:

> Hi Plínio
>
> Plínio Balduino  writes:
>
> > I just forked friend, updated the library versions and opened a pull
> > request.
> >
> > If you want to try and see if the problem still happens, please check
> > https://github.com/pbalduino/friend
>
> AFAIK the problem I have with friends dependencies is not the fact that
> it depends on an old version of clj-http but that it depends on an old
> version of org.apache.httpcomponents/httpclient. So I think your commit
> (
> https://github.com/pbalduino/friend/commit/926f01ba718c355c82faad4aa0438162708a1efb
> )
> will not help with that.
>
> Thanks
> Christian
>
> --
> Christian Egli
> Swiss Library for the Blind, Visually Impaired and Print Disabled
> Grubenstrasse 12, CH-8045 Zürich, Switzerland
>
> --
> 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.

Clojure User Group Mannheim zweites Treffen 12.11.2014 ab 19:00 Uhr im RaumZeitLabor

[Andreas Klein]

Liebe Clojurianer,


wir möchten unser nächstes User Group Meeting für Mannheim und die Umgebung 
ankündigen.

Das nächste Treffen findet am Mittwoch den 12.11.2014 ab 19:00 Uhr
im Raumzeitlabor Mannheim statt. https://raumzeitlabor.de/kontakt/anfahrt/ 


Wir können 3 oder mehr Teilnehmer auch nach dem Treffen am Hauptbahnhof oder 
Bahnhof SAP Arena absetzen, bitte eventuell vorher bescheid sagen. Die 
Anbindung ist vom Mannheimer Hbf mit der Linie 4 oder 5 sehr gut möglich, 
Ausstieg Boveristraße. 
Wenn ihr da seid (und die Tore geschlossen sind) einfach das Raumtelefon 
anrufen: +49 621 76231370

Agenda für das erste Treffen:

Nachdem wir beim letzten mal vor lauter anregender Gespräche nicht zum Vortrag 
gekommen sind, noch einmal:

1. Vortrag (ca. 30 Minuten)
   Web Entwicklung in Clojure - Tools und Best Practices (Andreas Klein)

Andreas ist Mitarbeiter der DemandFlow GmbH und entwickelt
eine Web Software in Clojure. Seit ca. einem Jahr beschäftigt
er sich professionell mit Clojure Entwicklung.

2. Abendessen und Erfahrungsaustausch.

-- 
Viele Grüße
Christian Weilbach und Andreas Klein

-- 
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: Dependency problem between clj-http and com.cemerick/friend

[casphas]

Hi Christian,

Friend (at least in this version) and clj-http depend on different
versions of org.apache.httpcomponents/httpclient. If the version friend
wants wins (friend first in dependencies), clj-http gets an earlier
version than it wants and fails because the earlier version does not
provide the same classes.

If you put [com.cemerick/friend "0.2.1" :exclusions
[org.apache.httpcomponents/httpclient]] then you will always get the
version of httpclient that clj-http specifies, regardless of the order
you specify the dependencies in. I don't know if that might cause a
runtime problem for friend, but I have used this setup without a problem
so far.

Regards,

Caspar

On Wed, Nov 05, 2014 at 12:20:42PM +0100, Christian Egli wrote:
> Hi all
> 
> I have a strange interaction between clj-http and com.cemerick/friend. I
> don't know if this is a problem in either of the two packages or maybe
> even Leiningen.
> 
> The problem is very easy to reproduce. Create a project with `lein new`,
> add dependencies to clj-http and com.cemerick/friend, start a repl and
> simpy require clj-http.client as follows:
> 
> $ lein new app friend-and-clj-http
> $ cd friend-and-clj-http
> $ # add clj-http and friend as a dependency to project.clj
> $ lein repl
> friend-and-clj-http.core=> (require '[clj-http.client :as client])
> 
> If the dependency to friend is before the dependency to clj-http you
> will get the following exception:
> 
> CompilerException java.lang.ClassNotFoundException: 
> org.apache.http.conn.ssl.SSLContexts, compiling:(clj_http/conn_mgr.clj:1:1)
> 
> However if you change the order of the dependencies everything works as
> expected.
> 
> $ # change the order of the dependencies
> $ lein repl
> friend-and-clj-http.core=> (require '[clj-http.client :as client])
> nil
> friend-and-clj-http.core=> Bye for now!
> 
> I put both versions of project.clj, the shell session and the output of
> `lein deps :tree` for both versions in public gists
> 
> - https://gist.github.com/egli/8e6086f4d35ff7c11f80 project.clj with
>   friend and clj-http as dependencies
> - https://gist.github.com/egli/ff26669047b9273741c6 project.clj with
>   clj-http and friend as dependencies 
> - https://gist.github.com/egli/076b4f450cc237e2ac4a shell session
> - https://gist.github.com/egli/b3e149aded64c7628f8e lein deps :tree with
>   friend before clj-http
> - https://gist.github.com/egli/4fa13bc791e52061f9e9 lein deps :tree with
>   clj-http before friend
> 
> Where do I report this problem?
> 
> Thanks
> Christian
> 
> -- 
> Christian Egli
> Swiss Library for the Blind, Visually Impaired and Print Disabled
> Grubenstrasse 12, CH-8045 Zürich, Switzerland
> 
> -- 
> 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.

[ANN] Suricatta: 0.1.0-alpha - high level sql toolkit for clojure (backed by jooq)

[Andrey Antukh]

Hello everybody.

I wanted to announce the first alpha release of suricatta, a high level sql
toolkit for clojure (backed by fantastic jooq library)

Main features:
- Clear and simple sql executing api.
- Asynchronous query execution api.
- Lightweight sql dsl.

You might be wondering:

Yet an other sql dsl?
In first instance suricatta is not a dsl library, is a sql toolkit, and one
part of the toolkit is a dsl.
Secondly, suricatta's dsl don’t intends to be a sql abstraction. The real
purpose of suricatta's dsl is make SQL composable, allowing use all or
almost all vendor specific sql constructions.

Why I should use suricatta instead of clojure.jdbc or java.jdbc?
Unlike any jdbc library, suricatta works in slightly higher level. It hides
a lot of idiosyncrasies of jdbc under much simpler, cleaner and less error
prone api, with better resource management.

You can find a complete FAQ here: http://niwibe.github.io/suricatta/#_faq

Repository: https://github.com/niwibe/suricatta
Docs: http://niwibe.github.io/suricatta/

My apologies for the spelling mistakes in the documentation. My English
isn't very good, and all improvements are welcome!

Yours,

Andrey

-- 
Andrey Antukh - Андрей Антух -  / 
http://www.niwi.be 
https://github.com/niwibe

-- 
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: Introducing Boot v2 with a streamlined CLJS workflow

[Henrik Eneroth]

Hello Micha!


I'm trying to tuck Reagent in there to take it for a spin, and it seems 
reluctant to comply:

boot -d reagent/reagent:0.4.3
java.lang.NullPointerException:
 boot.main/dep-ns-decls  main.clj:   36
boot.main/export-task-namespaces/fn  main.clj:   49
clojure.core/map/fn  core.clj: 2557
...
   clojure.core/seq  core.clj:  133
 clojure.core/apply  core.clj:  624
clojure.core/mapcat  core.clj: 2586
...
   boot.main/export-task-namespaces  main.clj:   51
boot.main/-main  main.clj:  111
...
   boot.App.runBoot  App.java:  217
  boot.App.main  App.java:  309


Any feedback on what I (or it) may be doing wrong?


Thanks!

Henrik

On Monday, November 3, 2014 9:40:58 PM UTC+1, Micha Niskin wrote:
>
> Hi!
>
> Boot (http://github.com/boot-clj/boot) is a build tool for Clojure. We've 
> pulled together lessons learned from a year or so using boot v1 in 
> production and are now getting ready to release v2. To show what boot can 
> do we present a very streamlined and awesome boot-based ClojureScript 
> development workflow (
> http://adzerk.com/blog/2014/11/clojurescript-builds-rebooted/). 
>
> Try it out, maybe you'll like it! We're hoping to get some feedback before 
> committing to a stable release, so please if you have any comments or 
> questions we'd be happy to hear them. Have fun!
>

-- 
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: Introducing Boot v2 with a streamlined CLJS workflow

[Micha Niskin]

Hi Henrik,

You found a bug! We just fixed it though. Boot was confused by 
`reagent/reagent` when it tried to match that against the artifact ids 
returned by Pomegranate, because Pomegranate collapses it to just `reagent` 
in that case. If you do `boot -u` you should be updated to boot version 
`2.0.0-pre20`, and your command line will work.

On Thursday, November 6, 2014 12:31:13 PM UTC-5, Henrik Eneroth wrote:
>
> Hello Micha!
>
>
> I'm trying to tuck Reagent in there to take it for a spin, and it seems 
> reluctant to comply:
>
> boot -d reagent/reagent:0.4.3
> java.lang.NullPointerException:
>  boot.main/dep-ns-decls  main.clj:   36
> boot.main/export-task-namespaces/fn  main.clj:   49
> clojure.core/map/fn  core.clj: 2557
> ...
>clojure.core/seq  core.clj:  133
>  clojure.core/apply  core.clj:  624
> clojure.core/mapcat  core.clj: 2586
> ...
>boot.main/export-task-namespaces  main.clj:   51
> boot.main/-main  main.clj:  111
> ...
>boot.App.runBoot  App.java:  217
>   boot.App.main  App.java:  309
>
>
> Any feedback on what I (or it) may be doing wrong?
>
>
> Thanks!
>
> Henrik
>
> On Monday, November 3, 2014 9:40:58 PM UTC+1, Micha Niskin wrote:
>>
>> Hi!
>>
>> Boot (http://github.com/boot-clj/boot) is a build tool for Clojure. 
>> We've pulled together lessons learned from a year or so using boot v1 in 
>> production and are now getting ready to release v2. To show what boot can 
>> do we present a very streamlined and awesome boot-based ClojureScript 
>> development workflow (
>> http://adzerk.com/blog/2014/11/clojurescript-builds-rebooted/). 
>>
>> Try it out, maybe you'll like it! We're hoping to get some feedback 
>> before committing to a stable release, so please if you have any comments 
>> or questions we'd be happy to hear them. Have fun!
>>
>

-- 
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.test.check with fixtures

[Sven Richter]

Hi,

thank you, I just wanted to make sure I am not missing some functionality.

Best Regards,
Sven

Am Mittwoch, 5. November 2014 23:29:54 UTC+1 schrieb Ashton Kemerling:
>
> You can use fixtures from Clojure.test, but each spec from the perspective 
> of clojure.test includes multiple runs. So I use fixtures :once to do any 
> global setup, and then farm out to a setup function for anything that needs 
> to be done before each test run. 
>
> --Ashton
>
> Sent from my iPhone
>
> On Nov 5, 2014, at 3:27 PM, Sven Richter  > wrote:
>
> Hi,
>
> Is there a way to use clojure.test.check's defspec with fixtures?
> Like (use-fixtures :each (partial wrap-setup setup teardown)) in clojures 
> test library?
>
> How do other people execute setup and teardowns with clojure.test.check?
>
> Best Regards,
> Sven
>
> -- 
> 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 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.

better way to group consecutive numbers in a vector?

[John Gabriele]

Hi all,

I've got this: `[1 3 4 5 7 9 10 11 12]`
and I'd like to turn it into this: `[[1] [3 4 5] [7] [9 10 11 12]]`.

That is, I'd like to group consecutive numbers together (the final goal 
being to produce something like `["1" "3-5" "7" "9-12"]`, but that's the 
easy part).

I haven't found an easy way to do this. Here's what I've come up with in 
Clojure:

~~~clojure
#!/usr/bin/env lein-exec

(def v [1 3 4 5 7 9 10 11 12])

(defn congeal-consecutives
  [coll]
  (reduce (fn [accum x]
(if (= x (inc (last (last accum
  (concat (butlast accum)
  [(conj (last accum) x)])
  (concat accum
  [[x]])))
  [[(first coll)]]
  (rest coll)))

(prn (congeal-consecutives v))
~~~

and here's it done in Python:

~~~python
#!/usr/bin/python3

v = [1, 3, 4, 5, 7, 9, 10, 11, 12]

def congeal_consecutives(coll):
accum = [[ coll[0] ]]
more  = coll[1:]
for x in more:
if x == accum[-1][-1] + 1:
accum[-1].append(x)
else:
accum.append([x])
return accum

print(congeal_consecutives(v))
~~~

Can anyone suggest a better / simpler / more easily-understandable way to 
do this in Clojure?

Thanks,
-- 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: better way to group consecutive numbers in a vector?

[Ashton Kemerling]

Consider using partition-by. I can't type clojure on my phone, but the 
following link might help. https://clojuredocs.org/clojure.core/partition-by

--Ashton

Sent from my iPhone

> On Nov 6, 2014, at 3:22 PM, John Gabriele  wrote:
> 
> Hi all,
> 
> I've got this: `[1 3 4 5 7 9 10 11 12]`
> and I'd like to turn it into this: `[[1] [3 4 5] [7] [9 10 11 12]]`.
> 
> That is, I'd like to group consecutive numbers together (the final goal being 
> to produce something like `["1" "3-5" "7" "9-12"]`, but that's the easy part).
> 
> I haven't found an easy way to do this. Here's what I've come up with in 
> Clojure:
> 
> ~~~clojure
> #!/usr/bin/env lein-exec
> 
> (def v [1 3 4 5 7 9 10 11 12])
> 
> (defn congeal-consecutives
>   [coll]
>   (reduce (fn [accum x]
> (if (= x (inc (last (last accum
>   (concat (butlast accum)
>   [(conj (last accum) x)])
>   (concat accum
>   [[x]])))
>   [[(first coll)]]
>   (rest coll)))
> 
> (prn (congeal-consecutives v))
> ~~~
> 
> and here's it done in Python:
> 
> ~~~python
> #!/usr/bin/python3
> 
> v = [1, 3, 4, 5, 7, 9, 10, 11, 12]
> 
> def congeal_consecutives(coll):
> accum = [[ coll[0] ]]
> more  = coll[1:]
> for x in more:
> if x == accum[-1][-1] + 1:
> accum[-1].append(x)
> else:
> accum.append([x])
> return accum
> 
> print(congeal_consecutives(v))
> ~~~
> 
> Can anyone suggest a better / simpler / more easily-understandable way to do 
> this in Clojure?
> 
> Thanks,
> -- 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.

-- 
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: Introducing Boot v2 with a streamlined CLJS workflow

[Henrik Eneroth]

Thanks for looking into it, Micha! 


I'm getting -pre19 with boot -u, though. Did you forget to cut a release or 
should I set BOOT_CHANNEL to dev?


On Thursday, November 6, 2014 8:30:55 PM UTC+1, Micha Niskin wrote:
>
> Hi Henrik,
>
> You found a bug! We just fixed it though. Boot was confused by 
> `reagent/reagent` when it tried to match that against the artifact ids 
> returned by Pomegranate, because Pomegranate collapses it to just `reagent` 
> in that case. If you do `boot -u` you should be updated to boot version 
> `2.0.0-pre20`, and your command line will work.
>
> On Thursday, November 6, 2014 12:31:13 PM UTC-5, Henrik Eneroth wrote:
>>
>> Hello Micha!
>>
>>
>> I'm trying to tuck Reagent in there to take it for a spin, and it seems 
>> reluctant to comply:
>>
>> boot -d reagent/reagent:0.4.3
>> java.lang.NullPointerException:
>>  boot.main/dep-ns-decls  main.clj:   36
>> boot.main/export-task-namespaces/fn  main.clj:   49
>> clojure.core/map/fn  core.clj: 2557
>> ...
>>clojure.core/seq  core.clj:  133
>>  clojure.core/apply  core.clj:  624
>> clojure.core/mapcat  core.clj: 2586
>> ...
>>boot.main/export-task-namespaces  main.clj:   51
>> boot.main/-main  main.clj:  111
>> ...
>>boot.App.runBoot  App.java:  217
>>   boot.App.main  App.java:  309
>>
>>
>> Any feedback on what I (or it) may be doing wrong?
>>
>>
>> Thanks!
>>
>> Henrik
>>
>> On Monday, November 3, 2014 9:40:58 PM UTC+1, Micha Niskin wrote:
>>>
>>> Hi!
>>>
>>> Boot (http://github.com/boot-clj/boot) is a build tool for Clojure. 
>>> We've pulled together lessons learned from a year or so using boot v1 in 
>>> production and are now getting ready to release v2. To show what boot can 
>>> do we present a very streamlined and awesome boot-based ClojureScript 
>>> development workflow (
>>> http://adzerk.com/blog/2014/11/clojurescript-builds-rebooted/). 
>>>
>>> Try it out, maybe you'll like it! We're hoping to get some feedback 
>>> before committing to a stable release, so please if you have any comments 
>>> or questions we'd be happy to hear them. Have fun!
>>>
>>

-- 
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: Introducing Boot v2 with a streamlined CLJS workflow

[Micha Niskin]

I don’t understand why Aether isn’t finding -pre20 via the coordinates [boot 
"RELEASE"]. I can see the jar file and pom in the repo: 
https://clojars.org/repo/boot/boot/2.0.0-pre20/. Do you have any idea why 
Pomegranate wouldn’t be fetching that? Is there some subtlety of the 
sorting order that I’m missing, do you think?

On Thursday, November 6, 2014 5:50:14 PM UTC-5, Henrik Eneroth wrote:

Thanks for looking into it, Micha! 
>
>
> I'm getting -pre19 with boot -u, though. Did you forget to cut a release 
> or should I set BOOT_CHANNEL to dev?
>
>
> On Thursday, November 6, 2014 8:30:55 PM UTC+1, Micha Niskin wrote:
>>
>> Hi Henrik,
>>
>> You found a bug! We just fixed it though. Boot was confused by 
>> `reagent/reagent` when it tried to match that against the artifact ids 
>> returned by Pomegranate, because Pomegranate collapses it to just `reagent` 
>> in that case. If you do `boot -u` you should be updated to boot version 
>> `2.0.0-pre20`, and your command line will work.
>>
>> On Thursday, November 6, 2014 12:31:13 PM UTC-5, Henrik Eneroth wrote:
>>>
>>> Hello Micha!
>>>
>>>
>>> I'm trying to tuck Reagent in there to take it for a spin, and it seems 
>>> reluctant to comply:
>>>
>>> boot -d reagent/reagent:0.4.3
>>> java.lang.NullPointerException:
>>>  boot.main/dep-ns-decls  main.clj:   36
>>> boot.main/export-task-namespaces/fn  main.clj:   49
>>> clojure.core/map/fn  core.clj: 2557
>>> ...
>>>clojure.core/seq  core.clj:  133
>>>  clojure.core/apply  core.clj:  624
>>> clojure.core/mapcat  core.clj: 2586
>>> ...
>>>boot.main/export-task-namespaces  main.clj:   51
>>> boot.main/-main  main.clj:  111
>>> ...
>>>boot.App.runBoot  App.java:  217
>>>   boot.App.main  App.java:  309
>>>
>>>
>>> Any feedback on what I (or it) may be doing wrong?
>>>
>>>
>>> Thanks!
>>>
>>> Henrik
>>>
>>> On Monday, November 3, 2014 9:40:58 PM UTC+1, Micha Niskin wrote:

 Hi!

 Boot (http://github.com/boot-clj/boot) is a build tool for Clojure. 
 We've pulled together lessons learned from a year or so using boot v1 in 
 production and are now getting ready to release v2. To show what boot can 
 do we present a very streamlined and awesome boot-based ClojureScript 
 development workflow (
 http://adzerk.com/blog/2014/11/clojurescript-builds-rebooted/). 

 Try it out, maybe you'll like it! We're hoping to get some feedback 
 before committing to a stable release, so please if you have any comments 
 or questions we'd be happy to hear them. Have fun!

>>> ​

-- 
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: Introducing Boot v2 with a streamlined CLJS workflow

[Micha Niskin]

Does adding BOOT_CHANNEL=DEV boot -u do the trick? (We aren’t pushing 
snapshots currently so it should be the same…in theory.)

On Thursday, November 6, 2014 5:50:14 PM UTC-5, Henrik Eneroth wrote:

Thanks for looking into it, Micha! 
>
>
> I'm getting -pre19 with boot -u, though. Did you forget to cut a release 
> or should I set BOOT_CHANNEL to dev?
>
>
> On Thursday, November 6, 2014 8:30:55 PM UTC+1, Micha Niskin wrote:
>>
>> Hi Henrik,
>>
>> You found a bug! We just fixed it though. Boot was confused by 
>> `reagent/reagent` when it tried to match that against the artifact ids 
>> returned by Pomegranate, because Pomegranate collapses it to just `reagent` 
>> in that case. If you do `boot -u` you should be updated to boot version 
>> `2.0.0-pre20`, and your command line will work.
>>
>> On Thursday, November 6, 2014 12:31:13 PM UTC-5, Henrik Eneroth wrote:
>>>
>>> Hello Micha!
>>>
>>>
>>> I'm trying to tuck Reagent in there to take it for a spin, and it seems 
>>> reluctant to comply:
>>>
>>> boot -d reagent/reagent:0.4.3
>>> java.lang.NullPointerException:
>>>  boot.main/dep-ns-decls  main.clj:   36
>>> boot.main/export-task-namespaces/fn  main.clj:   49
>>> clojure.core/map/fn  core.clj: 2557
>>> ...
>>>clojure.core/seq  core.clj:  133
>>>  clojure.core/apply  core.clj:  624
>>> clojure.core/mapcat  core.clj: 2586
>>> ...
>>>boot.main/export-task-namespaces  main.clj:   51
>>> boot.main/-main  main.clj:  111
>>> ...
>>>boot.App.runBoot  App.java:  217
>>>   boot.App.main  App.java:  309
>>>
>>>
>>> Any feedback on what I (or it) may be doing wrong?
>>>
>>>
>>> Thanks!
>>>
>>> Henrik
>>>
>>> On Monday, November 3, 2014 9:40:58 PM UTC+1, Micha Niskin wrote:

 Hi!

 Boot (http://github.com/boot-clj/boot) is a build tool for Clojure. 
 We've pulled together lessons learned from a year or so using boot v1 in 
 production and are now getting ready to release v2. To show what boot can 
 do we present a very streamlined and awesome boot-based ClojureScript 
 development workflow (
 http://adzerk.com/blog/2014/11/clojurescript-builds-rebooted/). 

 Try it out, maybe you'll like it! We're hoping to get some feedback 
 before committing to a stable release, so please if you have any comments 
 or questions we'd be happy to hear them. Have fun!

>>> ​

-- 
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: Introducing Boot v2 with a streamlined CLJS workflow

[Micha Niskin]

It looks like Clojars is doing what I thought it would do: 
https://clojars.org/repo/boot/boot/maven-metadata.xml

2.0.0-pre20

On Thursday, November 6, 2014 5:50:14 PM UTC-5, Henrik Eneroth wrote:

Thanks for looking into it, Micha! 
>
>
> I'm getting -pre19 with boot -u, though. Did you forget to cut a release 
> or should I set BOOT_CHANNEL to dev?
>
>
> On Thursday, November 6, 2014 8:30:55 PM UTC+1, Micha Niskin wrote:
>>
>> Hi Henrik,
>>
>> You found a bug! We just fixed it though. Boot was confused by 
>> `reagent/reagent` when it tried to match that against the artifact ids 
>> returned by Pomegranate, because Pomegranate collapses it to just `reagent` 
>> in that case. If you do `boot -u` you should be updated to boot version 
>> `2.0.0-pre20`, and your command line will work.
>>
>> On Thursday, November 6, 2014 12:31:13 PM UTC-5, Henrik Eneroth wrote:
>>>
>>> Hello Micha!
>>>
>>>
>>> I'm trying to tuck Reagent in there to take it for a spin, and it seems 
>>> reluctant to comply:
>>>
>>> boot -d reagent/reagent:0.4.3
>>> java.lang.NullPointerException:
>>>  boot.main/dep-ns-decls  main.clj:   36
>>> boot.main/export-task-namespaces/fn  main.clj:   49
>>> clojure.core/map/fn  core.clj: 2557
>>> ...
>>>clojure.core/seq  core.clj:  133
>>>  clojure.core/apply  core.clj:  624
>>> clojure.core/mapcat  core.clj: 2586
>>> ...
>>>boot.main/export-task-namespaces  main.clj:   51
>>> boot.main/-main  main.clj:  111
>>> ...
>>>boot.App.runBoot  App.java:  217
>>>   boot.App.main  App.java:  309
>>>
>>>
>>> Any feedback on what I (or it) may be doing wrong?
>>>
>>>
>>> Thanks!
>>>
>>> Henrik
>>>
>>> On Monday, November 3, 2014 9:40:58 PM UTC+1, Micha Niskin wrote:

 Hi!

 Boot (http://github.com/boot-clj/boot) is a build tool for Clojure. 
 We've pulled together lessons learned from a year or so using boot v1 in 
 production and are now getting ready to release v2. To show what boot can 
 do we present a very streamlined and awesome boot-based ClojureScript 
 development workflow (
 http://adzerk.com/blog/2014/11/clojurescript-builds-rebooted/). 

 Try it out, maybe you'll like it! We're hoping to get some feedback 
 before committing to a stable release, so please if you have any comments 
 or questions we'd be happy to hear them. Have fun!

>>> ​

-- 
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: better way to group consecutive numbers in a vector?

[Steve Miner]

I would try to avoid last and but-last as they work in linear time.  How about 
something like this?

(defn congeal-consecutives [coll] 
  (when (seq coll) 
(let [[_ group res] (reduce (fn [[succ group res] n] 
(if (== succ n) 
[(inc n) (conj group n) res] 
[(inc n) [n] (conj res group)])) 
   [(nth coll 0) [] []] 
   coll)]
   (conj res group


> On Nov 6, 2014, at 5:22 PM, John Gabriele  wrote:
> 
> Hi all,
> 
> I've got this: `[1 3 4 5 7 9 10 11 12]`
> and I'd like to turn it into this: `[[1] [3 4 5] [7] [9 10 11 12]]`.
> 
> That is, I'd like to group consecutive numbers together (the final goal being 
> to produce something like `["1" "3-5" "7" "9-12"]`, but that's the easy part).
> 
> I haven't found an easy way to do this. Here's what I've come up with in 
> Clojure:
> 
> ~~~clojure
> #!/usr/bin/env lein-exec
> 
> (def v [1 3 4 5 7 9 10 11 12])
> 
> (defn congeal-consecutives
>   [coll]
>   (reduce (fn [accum x]
> (if (= x (inc (last (last accum
>   (concat (butlast accum)
>   [(conj (last accum) x)])
>   (concat accum
>   [[x]])))
>   [[(first coll)]]
>   (rest coll)))
> 
> (prn (congeal-consecutives v))

-- 
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: better way to group consecutive numbers in a vector?

[john walker]

Hi John,

As miner mentioned, peek is preferable to last for vectors. Here is an 
implementation based on the observation that consecutive increasing numbers 
are equivalent when you subtract their indices. Maybe it is more clever 
than simple.

(ns experimental-clojure.congeal-consecutives)

(def v [1 3 4 5 7 9 10 11 12])
 (defn congeal-consecutives [coll]
  (->> coll
   (map-indexed (fn [i x] [(- x i) x]))
   (partition-by first)
   (mapv (fn [pairs]
   (mapv second pairs)
 (defn rangify [coll]
  (mapv (fn [r]
  (assert (vector? coll))
  (let [f(first r)
top  (peek  r)]
(if (= f top)
  (str f)
  (str f "-" top coll))
 (-> v
congeal-consecutives
rangify)


https://gist.github.com/johnwalker/8e7e6a8bcbeff03d4e80


On Thursday, November 6, 2014 2:22:14 PM UTC-8, John Gabriele wrote:
>
> Hi all,
>
> I've got this: `[1 3 4 5 7 9 10 11 12]`
> and I'd like to turn it into this: `[[1] [3 4 5] [7] [9 10 11 12]]`.
>
> That is, I'd like to group consecutive numbers together (the final goal 
> being to produce something like `["1" "3-5" "7" "9-12"]`, but that's the 
> easy part).
>
> I haven't found an easy way to do this. Here's what I've come up with in 
> Clojure:
>
> ~~~clojure
> #!/usr/bin/env lein-exec
>
> (def v [1 3 4 5 7 9 10 11 12])
>
> (defn congeal-consecutives
>   [coll]
>   (reduce (fn [accum x]
> (if (= x (inc (last (last accum
>   (concat (butlast accum)
>   [(conj (last accum) x)])
>   (concat accum
>   [[x]])))
>   [[(first coll)]]
>   (rest coll)))
>
> (prn (congeal-consecutives v))
> ~~~
>
> and here's it done in Python:
>
> ~~~python
> #!/usr/bin/python3
>
> v = [1, 3, 4, 5, 7, 9, 10, 11, 12]
>
> def congeal_consecutives(coll):
> accum = [[ coll[0] ]]
> more  = coll[1:]
> for x in more:
> if x == accum[-1][-1] + 1:
> accum[-1].append(x)
> else:
> accum.append([x])
> return accum
>
> print(congeal_consecutives(v))
> ~~~
>
> Can anyone suggest a better / simpler / more easily-understandable way to 
> do this in Clojure?
>
> Thanks,
> -- 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: [ANN] Suricatta: 0.1.0-alpha - high level sql toolkit for clojure (backed by jooq)

[john walker]

Cool! I can see myself using this in an upcoming project. Thanks as usual 
for your work :)

On Thursday, November 6, 2014 9:23:53 AM UTC-8, Andrey Antukh wrote:
>
> Hello everybody.
>
> I wanted to announce the first alpha release of suricatta, a high level 
> sql toolkit for clojure (backed by fantastic jooq library)
>
> Main features:
> - Clear and simple sql executing api.
> - Asynchronous query execution api.
> - Lightweight sql dsl.
>
> You might be wondering: 
>
> Yet an other sql dsl? 
> In first instance suricatta is not a dsl library, is a sql toolkit, and 
> one part of the toolkit is a dsl.
> Secondly, suricatta's dsl don’t intends to be a sql abstraction. The real 
> purpose of suricatta's dsl is make SQL composable, allowing use all or 
> almost all vendor specific sql constructions.
>
> Why I should use suricatta instead of clojure.jdbc or java.jdbc?
> Unlike any jdbc library, suricatta works in slightly higher level. It 
> hides a lot of idiosyncrasies of jdbc under much simpler, cleaner and less 
> error prone api, with better resource management.
>
> You can find a complete FAQ here: http://niwibe.github.io/suricatta/#_faq
>
> Repository: https://github.com/niwibe/suricatta
> Docs: http://niwibe.github.io/suricatta/
>
> My apologies for the spelling mistakes in the documentation. My English 
> isn't very good, and all improvements are welcome!
>
> Yours,
>
> Andrey
>
> -- 
> Andrey Antukh - Андрей Антух - > / <
> ni...@niwi.be >
> http://www.niwi.be 
> https://github.com/niwibe
>  

-- 
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: ClojureScript and development workflow

[Asim Jalis]

Hi Laurent,

For refreshing the browser, I call (.reload js/location) from the browser 
REPL.

So this is the workflow:

Terminal 1: lein cljsbuild auto dev
Terminal 2: lein trampoline cljsbuild repl-listen
Browser: localhost:9000/myapp.html

1. I make change to the CLJS file.
2. cljsbuild auto dev picks it up and recompiles the JS file.
3. In the REPL I call (.reload js/location) which picks up the new JS file.
4. In the REPL I call (myapp.run-tests) which runs the unit tests.

You can view the sources at http://github.com/asimjalis/cluster_splitter.

Asim

On Monday, September 10, 2012 9:28:44 AM UTC-7, Laurent PETIT wrote:
>
> Hello, 
>
> A "ClojureScript workflow" newbie question.
>
> People seem to be using a lot lein-cljsbuild to work with their 
> ClojureScript project.
>
> From what I understand, this means they have a watcher which recompiles 
> javascript in the background whenever they save changes to clojurescript 
> files to the disk.
> Thus, this means that whenever they make a change, they have to restart 
> the application (e.g. refresh the browser).
>
> Is that the end of the story with lein-cljs ? (wrt development workflow ?)
>
> On the other end, when looking at the wiki page for ClojureScript One, one 
> can see : 
>
> "Using the REPL as the main way to deliver code to the browser means never 
> having to refresh the page. One could theoretically build an entire 
> application without a single page refresh. If you find yourself refreshing 
> the page after every change you make, you're doing it wrong. What is this, 
> 2009?"
>
>
> So before digging into ClojureScript for the first time, I'd like to know 
> what to thing about all this, so that I don't waste my time following wrong 
> paths.
>
>
> What would be my expected "default" workflow when starting to write a 
> single page application with ClojureScript, in September 2012 ?
>
> Cheers,
>
> -- 
> Laurent
>

-- 
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: better way to group consecutive numbers in a vector?

[Gordon Stratton]

On Thu, Nov 6, 2014 at 10:22 PM, John Gabriele  wrote:
> Hi all,
>
> I've got this: `[1 3 4 5 7 9 10 11 12]`
> and I'd like to turn it into this: `[[1] [3 4 5] [7] [9 10 11 12]]`.
>
> That is, I'd like to group consecutive numbers together (the final goal
> being to produce something like `["1" "3-5" "7" "9-12"]`, but that's the
> easy part).
>
> I haven't found an easy way to do this. Here's what I've come up with in
> Clojure:
>
> ~~~clojure
> #!/usr/bin/env lein-exec
>
> (def v [1 3 4 5 7 9 10 11 12])
>
> (defn congeal-consecutives
>   [coll]
>   (reduce (fn [accum x]
> (if (= x (inc (last (last accum
>   (concat (butlast accum)
>   [(conj (last accum) x)])
>   (concat accum
>   [[x]])))
>   [[(first coll)]]
>   (rest coll)))
>
> (prn (congeal-consecutives v))
> ~~~
>
> Can anyone suggest a better / simpler / more easily-understandable way to do
> this in Clojure?

Hey John,

I think your approach is pretty good. I made some small modifications:

(defn congeal-consecutives
  [xs]
  (if (empty? xs)
[]
(reduce (fn [acc x]
  (let [l (last acc)]
(if (= (inc (last l)) x)
  (conj (pop acc) (conj l x))
  (conj acc [x]
[[(first xs)]]
(rest xs

I didn't see how to use `partition-by` in a way that made the function
any clearer than the `reduce` version, but I'd be interested if you or
others do.

-- 
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: better way to group consecutive numbers in a vector?

[blake]

I wanted to put the delimiters in one step and then split in a different
one, so I did this:

(defn delimit[v]
  (reduce #(if (= (last %) (dec %2))
(conj % %2)
(conj % :split %2))
[(first v)] (rest v)))

(delimit [1 3 4 5 7 9 10 11 12])
=> [1 :split 3 4 5 :split 7 :split 9 10 11 12]

But that was before I realized there was no equivalent to
clojure.string/split that works on lists.
​

-- 
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: ClojureScript and development workflow

[Chris Sims]

I’m not sure that the original question is still valid, as it’s over 2 years 
old now.  I’ve had success using figwheel[1] to automatically recompile 
Clojurescript and send the updated js to the browser, sans reloading.

[1] https://github.com/bhauman/lein-figwheel 
> On Nov 6, 2014, at 4:57 PM, Asim Jalis  wrote:
> 
> Hi Laurent,
> 
> For refreshing the browser, I call (.reload js/location) from the browser 
> REPL.
> 
> So this is the workflow:
> 
> Terminal 1: lein cljsbuild auto dev
> Terminal 2: lein trampoline cljsbuild repl-listen
> Browser: localhost:9000/myapp.html
> 
> 1. I make change to the CLJS file.
> 2. cljsbuild auto dev picks it up and recompiles the JS file.
> 3. In the REPL I call (.reload js/location) which picks up the new JS file.
> 4. In the REPL I call (myapp.run-tests) which runs the unit tests.
> 
> You can view the sources at http://github.com/asimjalis/cluster_splitter.
> 
> Asim
> 
> On Monday, September 10, 2012 9:28:44 AM UTC-7, Laurent PETIT wrote:
> Hello, 
> 
> A "ClojureScript workflow" newbie question.
> 
> People seem to be using a lot lein-cljsbuild to work with their ClojureScript 
> project.
> 
> From what I understand, this means they have a watcher which recompiles 
> javascript in the background whenever they save changes to clojurescript 
> files to the disk.
> Thus, this means that whenever they make a change, they have to restart the 
> application (e.g. refresh the browser).
> 
> Is that the end of the story with lein-cljs ? (wrt development workflow ?)
> 
> On the other end, when looking at the wiki page for ClojureScript One, one 
> can see : 
> 
> "Using the REPL as the main way to deliver code to the browser means never 
> having to refresh the page. One could theoretically build an entire 
> application without a single page refresh. If you find yourself refreshing 
> the page after every change you make, you're doing it wrong. What is this, 
> 2009?"
> 
> 
> So before digging into ClojureScript for the first time, I'd like to know 
> what to thing about all this, so that I don't waste my time following wrong 
> paths.
> 
> 
> What would be my expected "default" workflow when starting to write a single 
> page application with ClojureScript, in September 2012 ?
> 
> Cheers,
> 
> -- 
> Laurent
> 
> -- 
> 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: ClojureScript and development workflow

[Daniel Szmulewicz]

My experience has been that the promise of hot reloadable code in the 
browser was fulfilled most reliably by lein-figwheel.
I have relinquished all other solutions (which gave me trouble), and I am a 
happy with my newfound cljs workflow.
https://github.com/bhauman/lein-figwheel

On Monday, September 10, 2012 7:28:44 PM UTC+3, Laurent PETIT wrote:
>
> Hello, 
>
> A "ClojureScript workflow" newbie question.
>
> People seem to be using a lot lein-cljsbuild to work with their 
> ClojureScript project.
>
> From what I understand, this means they have a watcher which recompiles 
> javascript in the background whenever they save changes to clojurescript 
> files to the disk.
> Thus, this means that whenever they make a change, they have to restart 
> the application (e.g. refresh the browser).
>
> Is that the end of the story with lein-cljs ? (wrt development workflow ?)
>
> On the other end, when looking at the wiki page for ClojureScript One, one 
> can see : 
>
> "Using the REPL as the main way to deliver code to the browser means never 
> having to refresh the page. One could theoretically build an entire 
> application without a single page refresh. If you find yourself refreshing 
> the page after every change you make, you're doing it wrong. What is this, 
> 2009?"
>
>
> So before digging into ClojureScript for the first time, I'd like to know 
> what to thing about all this, so that I don't waste my time following wrong 
> paths.
>
>
> What would be my expected "default" workflow when starting to write a 
> single page application with ClojureScript, in September 2012 ?
>
> Cheers,
>
> -- 
> Laurent
>

-- 
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: better way to group consecutive numbers in a vector?

[John Gabriele]

On Thursday, November 6, 2014 8:48:07 PM UTC-5, blake wrote:
>
> I wanted to put the delimiters in one step and then split in a different 
> one, so I did this:
>
> (defn delimit[v]
>   (reduce #(if (= (last %) (dec %2))
> (conj % %2)
> (conj % :split %2))
> [(first v)] (rest v)))
>
> (delimit [1 3 4 5 7 9 10 11 12])
> => [1 :split 3 4 5 :split 7 :split 9 10 11 12]
>
> But that was before I realized there was no equivalent to 
> clojure.string/split that works on lists.
> ​
>

Oooh, that's a good idea. Thanks. It's easy enough to split after you've 
added those markers/gaps in:

~~~clojure
#!/usr/bin/env lein-exec

(def v [1 3 4 5 7 9 10 11 12])

(defn insert-gaps
  [coll]
  (reduce (fn [accum x]
(if (= x (inc (last accum)))
  (conj accum x)
  (conj accum :gap x)))
  [(first coll)]
  (rest coll)))

(defn congeal-consecutives
  "Assumes coll has :gaps."
  [coll]
  (let [res (partition-by (fn [x]
(= x :gap))
  coll)]
(remove (fn [x]
  (= x '(:gap)))
res)))

(prn (congeal-consecutives (insert-gaps v)))
~~~
 

-- 
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: better way to group consecutive numbers in a vector?

[Ben Wolfson]

I don't know if this is *clearer* than the reduce version ...

user> (def xs [1 3 4 5 7 9 10 11 12 ])
#'user/xs
user> (defn consecutivizer []
(let [prev (atom nil)
  last-returned (atom (gensym))]
  (fn [cur]
(when-not (or (nil? @prev)
  (= (inc @prev) cur))
  (reset! last-returned (gensym)))
(reset! prev cur)
@last-returned)))
#'user/consecutivizer
user> (partition-by (consecutivizer) xs)
((1) (3 4 5) (7) (9 10 11 12))




On Thu, Nov 6, 2014 at 5:10 PM, Gordon Stratton 
wrote:

> On Thu, Nov 6, 2014 at 10:22 PM, John Gabriele  wrote:
> > Hi all,
> >
> > I've got this: `[1 3 4 5 7 9 10 11 12]`
> > and I'd like to turn it into this: `[[1] [3 4 5] [7] [9 10 11 12]]`.
> >
> > That is, I'd like to group consecutive numbers together (the final goal
> > being to produce something like `["1" "3-5" "7" "9-12"]`, but that's the
> > easy part).
> >
> > I haven't found an easy way to do this. Here's what I've come up with in
> > Clojure:
> >
> > ~~~clojure
> > #!/usr/bin/env lein-exec
> >
> > (def v [1 3 4 5 7 9 10 11 12])
> >
> > (defn congeal-consecutives
> >   [coll]
> >   (reduce (fn [accum x]
> > (if (= x (inc (last (last accum
> >   (concat (butlast accum)
> >   [(conj (last accum) x)])
> >   (concat accum
> >   [[x]])))
> >   [[(first coll)]]
> >   (rest coll)))
> >
> > (prn (congeal-consecutives v))
> > ~~~
> >
> > Can anyone suggest a better / simpler / more easily-understandable way
> to do
> > this in Clojure?
>
> Hey John,
>
> I think your approach is pretty good. I made some small modifications:
>
> (defn congeal-consecutives
>   [xs]
>   (if (empty? xs)
> []
> (reduce (fn [acc x]
>   (let [l (last acc)]
> (if (= (inc (last l)) x)
>   (conj (pop acc) (conj l x))
>   (conj acc [x]
> [[(first xs)]]
> (rest xs
>
> I didn't see how to use `partition-by` in a way that made the function
> any clearer than the `reduce` version, but I'd be interested if you or
> others do.
>
> --
> 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.
>



-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks, which
may be sweet, aromatic, fermented or spirit-based. ... Family and social
life also offer numerous other occasions to consume drinks for pleasure."
[Larousse, "Drink" entry]

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