Re: ANN: Parallel let macro!
Very nice! Kudos. -- 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] Dunaj project, an alternative core API for Clojure
Amazing work Jozef. Very interesting experiments. On Wednesday, March 18, 2015 at 9:21:25 AM UTC+1, Jozef Wagner wrote: Another big experiment for today. As new reducer features (continuations) will be applied heavily here, please read 5th experiment if you have not done so yet. Prepare for the longest write-up so far. Experiment #8 - Computer and Network Resources Most applications perform some file and networking I/O. Clojure leaves this domain largerly uncovered and advises users to use host facilities instead. Dunaj attempts to cover this realm with an extensive and powerful set of features dedicated to computer and network resources. Goals of this experiment are as follows: * Design and implement the concept of resource scopes * Develop facilities for implementers of computer and network resources * Create abstractions for basic resource functionalities and integrate them with the rest of core API, mainly with collections and transducers * Provide implementation for widely used resources * Devise abstraction for composing resources into 'systems' You can read more about this experiment at http://www.dunaj.org Regards, Jozef On Thursday, March 5, 2015 at 10:33:53 PM UTC+1, Jozef Wagner wrote: I'm happy to announce a project called Dunaj [1], which provides an alternative core API for Clojure. Its main aim is to experimentally test major additions to the language. Dunaj /ˈdunaɪ/ is a set of core language experiments aimed to improve Clojure language and its core API. It deals with language features that require changes across different parts of Clojure and which cannot be evaluated in isolation. Dunaj aims to bring Clojure even more towards simplicity, consistency and performance. It is intended to be used by regular Clojure developers, either for application or library development. Dunaj was created to test 10 experiments that bring significant changes to the Clojure language. As there is a substantial number of additions and changes, I want to try a bit unconventional approach here. Before I'll release the actual library, I will introduce Dunaj's experiments in a series of individual posts. Every part states the motivation behind the experiment, introduces changes and additions to the language and demonstrates its intended use. If you do not want to miss any of this, you may want to register for a mailing list at [1] or follow @dunajproject at Twitter. -- Jozef Wagner [1] http://www.dunaj.org/ -- 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: OO Programmer trying to move to Clojure: Encapsulation
If you find yourself passing the same argument over and over, you can
always work in a partial:
(def save-account (partial save db))
On Sunday, February 8, 2015 at 6:47:29 PM UTC+1, Colin Yates wrote:
I missed the salient point about data transformations which is that of
abstractions. In OO (Java at least) almost everything was a special case,
in Clojure it is the polar opposite; almost nothing is a special case.
It is astonishing how many domains can be sufficiently modeled as a
sequence of maps [{..} {..} ...] and can be sufficiently transformed with
the 'map' function (with assoc/assoc-in).
On Sunday, 8 February 2015 17:16:40 UTC, Colin Yates wrote:
+1 This separation of behaviour and state is a key part of Clojure's
philosophy. That isn't to say that stateful components are bad as such
(Stuart Sierra's https://github.com/stuartsierra/component is an
obvious analog here) only that they aren't a given as they are in OO
languages.
As Jony says, when functions only depend on their parameters it makes
many things simpler and more flexible, but can appear 'noisy'.
http://thinkrelevance.com/blog/2009/08/12/rifle-oriented-programming-with-clojure-2
is another good resource here, although I must say I haven't seen some
of those examples in the wild :).
From a similar background (Java) and having learnt some lessons, I
wish somebody hammered me on the head with the following:
- get real familiar with the notion of data transformations,
particularly maps
- internalise map, reduce, filter, apply, loop/recur and into
- before writing any code check the API doesn't already provide it
- repeat the above three points
- embrace vanilla maps, they really are all you need (and also watch
https://www.youtube.com/watch?v=ZQkIWWTygio)
- small functions (10 lines is uncomfortable) always
- embrace pre/post conditions, documentation (defn doc and
marginalia) and prismatic schema
- read as much Clojure code as you can get your hands on
- TDD is still a helpful process/technique in Clojure ;)
Longer term, watch anything from Rich Hickey.
By far the biggest conceptual shift was thinking in terms of data
being the public API and data transformation over blobs of state and
data.
Hope this helps.
On 8 February 2015 at 14:21, Jony Hudson jonye...@gmail.com
javascript: wrote:
To put take a different angle on it: you might soon get to *like* that
it's
usual to pass in everything as a parameter explicitly. It has the
advantage
that it's easy to reason about what a function does just by looking at
the
function. In the example above, when reading AccountRepository.Save you
need
to check elsewhere to see how _connection is defined. Whereas with the
function save, so long as the parameters you feed in are sensible, then
you
can be pretty sure what it will do.
Making the functions self-contained like this is also a boon when it
comes
to working at the REPL. The OO approach you have often makes it
difficult
(for less trivial examples) to run a particular function in the right
context. But with the self-contained function it's just a case of
getting
the parameters right, which is often easier to think about.
Jony
On Saturday, 7 February 2015 16:07:45 UTC, Dru Sellers wrote:
Greetings,
I am trying to convert my mind from OO (C#) to one more functionally
friendly. I am increasingly comfortable with simple applications in
clojure,
but as I start to build more complex applications, I start to fall
down
about how to structure my application. I don't want to just shove OO
ideas
into the functional nature of Clojure. I'm looking for any help
someone can
provide to help shimmy my brain into the right mental patterns.
Background: Long time C# developer who leans heavily on IoC / DI /
Interfaces / Testing / Object Encapsulation.
Specific Question: Object Encapsulation
I feel like my function parameter lists are much wider than they
would
be in C#. This is due to the lack of a constructor. So if I
previously had
a C# class that looked like:
public class AccountRepository : IAccountRepository
{
IDatabaseConnection _connection;
public AccountRepository(IDatabaseConnection connection)
{
_connection = connection;
}
public void Save(Account account)
{
_connection.Execute(UPDATE accounts SET coupon=@coupon WHERE
id=@id,
{ coupon = account.Coupon, id=account.Id});
}
}
In the above I have encapsulated the _connection, the other methods
don't have to deal with it. In Clojure (especially if you are
following
Sierra's Component pattern) you end up with
(defn save [db account]
(update db (:coupon account) (:id account))
)
I end up having to pass this 'db' around all over the place. I think
that
this is just something
Re: gemacl: Scientific computing application written in Clojure
Interesting read Jose, thanks! It might be interesting to try a transducer on (defn dot-prod Returns the dot product of two vectors [v1 v2] (reduce + (map * v1 v2))) if you can get your hands on the 1.7 alpha and the time and inclination to do it. Transducers have shown to be faster than running functions in sequence. Although I don't know how likely they are to beat native arrays, probably not very much. On Sunday, December 21, 2014 7:10:41 PM UTC+1, Jose M. Perez Sanchez wrote: Regarding the speed optimizations, execution time for a given model was reduced from 2735 seconds to 70 seconds, over several versions by doing several optimizations. The same calculation implemented in C# takes 12 seconds using the same computer and OS. Maybe the Clojure code can still be improved, but for the time being I'm happy with the Clojure version being six times slower, since the new software has many advantages. For these tests the model was the circle with radius 1 using the diffmr1 tracker, the simulation was run using 1 particles and 1 total random walk steps. These modifications in the critical parts of the code accounted for most of the improvement: - Avoid reflection by using type hints. - Use Java arrays. - In some cases call Java arithmetic functions directly instead of Clojure ones. - Avoid using partial functions in the critical parts of the code. Avoiding lazyness did not help much. Regarding the use of Java arrays, there are many small functions performing typical vector operations on arrays, such as the following example: Using Clojure types: (defn dot-prod Returns the dot product of two vectors [v1 v2] (reduce + (map * v1 v2))) Using Java arrays: (defn dot-prod-j Returns the dot product of two arrays of doubles [^doubles v1 ^doubles v2] (areduce v1 i ret 0.0 (+ ret (* (aget v1 i) (aget v2 i) This gives a general idea of which optimizations helped the most. These changes are not in the public repository, since previous commits have been omitted because the code code was not ready for publication (different license disclaimer, contained email addresses, etc.). If anyone is interested in the diffs and the execution times over several optimizations, please contact me. Kind regards, Jose. On Sunday, December 21, 2014 3:38:35 AM UTC-5, Jose M. Perez Sanchez wrote: Hi everyone: Sorry that it has taken so long. I've just released the software in GitHub under the EPL. It can be found at: https://github.com/iosephus/gema Kind regards, Jose. -- 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: Ring and Compojure with Node.js via Clojurescript
Awesome! I look forward to seeing the results. On Monday, December 8, 2014 3:50:48 PM UTC+1, Matthew Molloy wrote: Dear Community, I love making Clojure web apps, however their startup time is a serious drawback when used with a transient hosting service such as Heroku. My thought is to port Ring and Compojure over to Clojurescript so that can get their nice abstractions hosted on the Node.js runtime. Any thoughts or suggestions? Matthew -- 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] Re: [ANN] freactive - high performance, pure Clojurescript, declarative DOM library
Hacker News has sort of noticed: https://news.ycombinator.com/item?id=8648491 On Sunday, November 23, 2014 8:32:11 PM UTC+1, Jason Lewis wrote: Furthermore (it occurs to me) cesium is used to drive atomic clocks... so if you're using an atom to maintain state... even more relevance. Relevance? Wait, it's Cognitect now :) Jason Lewis vox 410.428.0253 twitter @canweriotnow blog http://decomplecting.org else http://about.me/jason.lewis On Sun, Nov 23, 2014 at 2:20 PM, Jason Lewis ja...@decomplecting.org javascript: wrote: Cesium is the most reactive element of all... and the name isn't taken on Clojars. Cesium will react explosively even with ice. Jason Lewis vox 410.428.0253 twitter @canweriotnow blog http://decomplecting.org else http://about.me/jason.lewis On Sun, Nov 23, 2014 at 1:21 PM, Gary Trakhman gary.t...@gmail.com javascript: wrote: The two best ones I can think of right now Halogen: they're known as highly reactive elements. Precipitate: both a noun and a verb, the solid that falls out of a solution, or to bring about such a reaction. Other chemical-ish names considered Enantiopure - Containing compounds of only a single chirality Fullerene - Bucky-Balls, they're just cool Recycle - 'Save the trees', and also 'recycle streams' from chemical engineering. On Sun, Nov 23, 2014 at 12:37 PM, Aaron Craelius aaronc...@gmail.com javascript: wrote: Fresco isn't bad. I think it's better than freactive at least. Seems to be relatively popular for a name, but no big projects: https://github.com/search?o=descp=1q=frescos=starstype=Repositoriesutf8=✓ On Sun, Nov 23, 2014 at 3:05 AM, Olli Piepponen kot...@gmail.com javascript: wrote: If you are open to name suggestions, how about Fresco http://www.wikiwand.com/en/Fresco? -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to a topic in the Google Groups ClojureScript group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/99myJ9vLeKQ/unsubscribe . To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com javascript:. To post to this group, send email to clojur...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com javascript:. To post to this group, send email to clojur...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com javascript:. To post to this group, send email to clojur...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/clojurescript. -- 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: thread-any macro %
You can find this functionality in the Swiss Arrows library here: https://github.com/rplevy/swiss-arrows My first thought was that using the % symbol seems cleaner than the of Swiss Arrows. Thinking about it though, wouldn't overloading the % create trouble when you do want to use the literal form of an anonymous function within a % clause? On Saturday, November 15, 2014 2:55:51 PM UTC+1, Krzysiek Herod wrote: Guys, what do you think about new thread macro (I would call it thread-any and represent it as %), that would require you to always specify the position of the argument you want to pass to the function? This code: (defn csv-line-sql-line [table, line] (- line (str ) (str/split separator) (#(map csv-field-sql-field %)) (#(str/join , %)) (str/replace strings-wrapper \) (#(str INSERT INTO , table, VALUES( % ); would become: (defn csv-line-sql-line [table, line] (% line (str % ) (str/split % separator) (map csv-field-sql-field %) (str/join , %) (str/replace strings-wrapper % \) (str INSERT INTO , table, VALUES( % );))) Reasoning: - there are functions that are thread-first fiendly, and other that are thread-last friendly, by using thread-in you don't have to redefine functions only to change the order of the attributes - I find it easier to follow execution chain if the argument is passed explicitely PS. I'm a clojure newbie, still in the process of learning basics. For example I'm not sure how to implement such macro yet, so if you find something obviously wrong, or missing in my suggestion, please let me know. I'll be super happy to read about alternative solutions to achieve similar goal. -- 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
I tried now, just running boot -u, and it worked perfectly. It's was probably some caching thing with Clojars. Currently at pre21 Now the command runs without errors, but it also doesn't seem to do all that much. Running boot -d reagent/reagent:0.4.3 gives the exact same output as running boot -h currently. On Friday, November 7, 2014 12:18:41 AM UTC+1, Micha Niskin wrote: It looks like Clojars is doing what I thought it would do: https://clojars.org/repo/boot/boot/maven-metadata.xml release2.0.0-pre20/release 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
Agreed, because it seems like a good tool. :-)
On that vein; what's the syntax for add-src?
I'm trying to include helper.cljs in the project, a file with a bunch of
convenience functions that I use. However, I get the following error:
stopping Jetty... clojure.lang.ExceptionInfo:
clojure.lang.ExceptionInfo: Could not locate helpers__init.class or
helpers.clj on classpath: at line 1 {:tag :cljs/analysis-error, :file
nil, :line 1, :column 1}
It seems enamoured with the idea that the file should end with .clj. I'm
guessing that boot has to be told of the existence of the file, but I'm not
sure how to do this. For the purposes of this experiment, the namespace of
helpers.cljs is simply (ns helpers).
On Friday, November 7, 2014 12:01:14 PM UTC+1, Laurent PETIT wrote:
Really looking forward to a couple more blog posts:
- an instructive / provocative one which could be named after how to
replace leiningen with boot 2. Would be very practical, showing how all
major usecases done with lein translate to boot.
- an tutorial / documenting one on how to write new task and be good
citizens of boot (what to do, what not to do, and then how)
:-)
2014-11-07 10:16 GMT+01:00 Henrik Eneroth henrik@gmail.com
javascript::
I tried now, just running boot -u, and it worked perfectly. It's was
probably some caching thing with Clojars. Currently at pre21
Now the command runs without errors, but it also doesn't seem to do all
that much.
Running
boot -d reagent/reagent:0.4.3
gives the exact same output as running
boot -h
currently.
On Friday, November 7, 2014 12:18:41 AM UTC+1, Micha Niskin wrote:
It looks like Clojars is doing what I thought it would do:
https://clojars.org/repo/boot/boot/maven-metadata.xml
release2.0.0-pre20/release
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 clo...@googlegroups.com
javascript:
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 javascript:
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 javascript:.
For more options, visit https://groups.google.com/d/optout.
--
Laurent Petit
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure
Re: Introducing Boot v2 with a streamlined CLJS workflow
Gotcha! Thanks!
On Friday, November 7, 2014 4:22:35 PM UTC+1, Micha Niskin wrote:
Henrik, the -d option simply adds dependencies to the project. The main
use case for this option is to pull in dependencies when you have no formal
“project” and no build.boot file. Mainly it’s used in concert with the
repl task so you can quickly and easily try something out:
$ boot -d aysylu/loom repl
boot.user= (use 'loom.graph)
nil
boot.user= (graph [1 2] [2 3] {3 [4] 5 [6 7]} 7 8 9)
...
However, if a dependency pulled in via -d (not transitive deps) contains
namespaces in which tasks are defined, these namespaces may be tagged with
^:boot/export-tasks metadata. Boot will find these namespaces and refer
all public vars into your build.boot environment.
So if the reagent jar contained task namespaces you should see them when
you do
$ boot -d reagent
Note that you don’t need to supply the group-id for reagent, and if you
want the latest release you can also omit the version.
--
Micha Niskin
On Fri, Nov 7, 2014 at 4:16 AM, Henrik Eneroth henrik@gmail.com
javascript: wrote:
I tried now, just running boot -u, and it worked perfectly. It's was
probably some caching thing with Clojars. Currently at pre21
Now the command runs without errors, but it also doesn't seem to do all
that much.
Running
boot -d reagent/reagent:0.4.3
gives the exact same output as running
boot -h
currently.
On Friday, November 7, 2014 12:18:41 AM UTC+1, Micha Niskin wrote:
It looks like Clojars is doing what I thought it would do:
https://clojars.org/repo/boot/boot/maven-metadata.xml
release2.0.0-pre20/release
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 clo...@googlegroups.com
javascript:
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 javascript:
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to a topic in the
Google Groups Clojure group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/clojure/YAckwMSfZkY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
clojure+u...@googlegroups.com javascript:.
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
Re: Introducing Boot v2 with a streamlined CLJS workflow
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
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: Rich Hickey's Transducers talk from Strange Loop
I'm tempted to make a conference called Rich Hickey talks about stuff, and it's just two days of Rich Hickey giving awesome presentations and telling us that we are still complecting stuff. On Saturday, September 20, 2014 1:22:50 PM UTC+2, Fergal Byrne wrote: Thanks Alex, right up there with the best Rich talks, and in record time! On Sat, Sep 20, 2014 at 6:35 AM, Wilker wilke...@gmail.com javascript: wrote: Awesome! Thank you very much! --- Wilker Lúcio http://about.me/wilkerlucio/bio Woboinc Consultant +55 81 82556600 On Fri, Sep 19, 2014 at 5:33 PM, Bruce Durling b...@otfrom.com javascript: wrote: Alex, Thanks for getting the videos up so quickly! cheers, Bruce On Fri, Sep 19, 2014 at 9:31 PM, Alex Miller al...@puredanger.com javascript: wrote: For your enjoyment... https://www.youtube.com/watch?v=6mTbuzafcII -- 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 javascript: 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 javascript: 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 javascript:. For more options, visit https://groups.google.com/d/optout. -- @otfrom | CTO co-founder @MastodonC | mastodonc.com See recent coverage of us in the Economist http://econ.st/WeTd2i and the Financial Times http://on.ft.com/T154BA -- 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 javascript: 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 javascript: 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 javascript:. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.com javascript: 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 javascript: 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 javascript:. For more options, visit https://groups.google.com/d/optout. -- Fergal Byrne, Brenter IT http://inbits.com - Better Living through Thoughtful Technology http://ie.linkedin.com/in/fergbyrne/ - https://github.com/fergalbyrne Author, Real Machine Intelligence with Clortex and NuPIC Read for free or buy the book at https://leanpub.com/realsmartmachines Speaking on Clortex and HTM/CLA at euroClojure Krakow, June 2014: http://euroclojure.com/2014/ and at LambdaJam Chicago, July 2014: http://www.lambdajam.com e:fergalby...@gmail.com javascript: t:+353 83 4214179 Join the quest for Machine Intelligence at http://numenta.org Formerly of Adnet edi...@adnet.ie javascript: http://www.adnet.ie -- 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: Programming Clojure in the large: libraries, frameworks, oh my
And just recently, we have Onyx as well: https://github.com/MichaelDrogalis/onyx On Friday, September 19, 2014 9:40:14 PM UTC+2, Mike Haney wrote: Just a note - juxt/jig isn't being maintained, and has been replaced by juxt/modular. Modular is based on Stuart Sierra's component library, and mainly consists of several pre-built components and some nice helpers for wiring and configuring components. It also plays well with juxt/ceylon, which provides a growing collection of pre-built security components and looks very promising. -- 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} defun: A beautiful macro to define clojure functions with pattern match.
For all the good qualities of the Clojure group, it can sometimes produce a bit of a harsh tone. Don't let that get you down though, it's great that you're building stuff and showing it off! As far as defun goes, it looks interesting. The out-of-the-box pattern matching was one of the things I enjoyed with ML. It's usually a quite tidy way to handle the termination conditions of recursions. It's less useful in Clojure, since we're more or less confined to loop and recur, but I still like the looks of this. On Sunday, September 14, 2014 8:47:28 AM UTC+2, dennis wrote: Hi , i am pleased to introduce defun https://github.com/killme2008/defun: a beautiful macro to define clojure functions with pattern match. Some examples: (defun say-hi ([:dennis] Hi,good morning, dennis.) ([:catty] Hi, catty, what time is it?) ([:green] Hi,green, what a good day!) ([other] (str Say hi to other))) (say-hi :dennis) ;; Hi,good morning, dennis. (say-hi :catty) ;; Hi, catty, what time is it? (say-hi :green) ;; Hi,green, what a good day! (say-hi someone) ;; Say hi to someone Recursive function? It's all right: (defun count-down ([0] (println Reach zero!)) ([n] (println n) (recur (dec n (defun fib ([0] 0) ([1] 1) ([n] (+ (fib (- n 1)) (fib (- n 2) Guard functions? it's all right: (defun valid-geopoint? ([(_ :guard #(and ( % -180) ( % 180))) (_ :guard #(and ( % -90) ( % 90)))] true) ([_ _] false)) (valid-geopoint? 30 30) ;; true (valid-geopoint? -181 30) ;; false It's really cool,all the magic are from core.match, much more details please see https://github.com/killme2008/defun -- 庄晓丹 Email:killm...@gmail.com javascript: xzh...@avos.com javascript: Site: http://fnil.net Twitter: @killme2008 -- 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.
Annex is a fact store
Conceptually, this looks vaguely similar to Datomic. https://speakerdeck.com/markhibberd/towards-annex-a-fact-based-dependency-system-icfp -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Is Clojure a language for growth?
(this, and elderly care jobs, are powering much of the popular music industry here). Ah, everybody generalizes all the time. Henrik can nuance the picture. I have been programming and promoting Clojure quite aggressively for some years (it's hard not to), and the last months people have been starting to say yeah, my java friends really likes it or yes, my bf likes it too. Wind of change. /Linus working at Agical AB, a consultancy in love with technology and sometimes hosting Clojure Meet ups with Stockholm Clojure User Group and wov, so much thing I really can help companies with everywhere, epic win On Wednesday, August 20, 2014, Quzanti quz...@googlemail.com wrote: Just looked at your profile. Sweden? A very enlightened place. I am a big fan of the Paradox Interactive games. What happens in Sweden when investors lose their money? On Wednesday, August 20, 2014 7:16:55 PM UTC+1, Henrik Eneroth wrote: … as soon as anything goes wrong whether it has anything to do with the technology choice or not you become mr fall guy, to be blamed and fired so that other people can keep their jobs. Seen it happen so many times. Good lord, truly? Perhaps this is a good time to ask what culture OP lives in. This wouldn't happen where I live/work. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Is Clojure a language for growth?
+ Grammar. I should not write correspondence before having coffee. On Thursday, August 21, 2014 9:31:42 AM UTC+2, Henrik Eneroth wrote: Sweden has some things going for it, and some not, as always. I think business overall is somewhat less cutthroat here than in the States, which is why it struck me that I might be making assumptions about what OP should or should not do out of ignorance of his situation. The scape goat reasoning really brought this home. At the two most recent places I've been (I'm a consultant, a UX designer), they've worked with autonomous teams. That is, the teams are themselves responsible for deciding how to solve a problem, sometimes including what programming language to use. One result of this seems to emerge (I only have a sample size of two) a microservice centered design and a general decoupling between the teams. Also, it naturally seems to lead to a more heterogeneous environment, for good or for bad. This seems to be somewhat self-regulating however, as other most members of a team will protest if one member wants to write the new service in the Shakespearean Programming Language, for example. It also leads to the same kind of resistance to more sensible choices as well, like Clojure. But unlike SPL or Brainfuck, they actually have chance of being used if they show merit, probably by filling some niche role to begin with. When I was with Spotify, I learned that they had snuck in some Clojure in one of the teams of the organization. No one has been fired yet, and everyone seems happy enough. Especially the people who now get to do at least *some* Clojure during their work day. Oh, and like Linus, I try to promote Clojure wherever I go. As a designer, I'd love to work with a team that uses Clojure. That is, a team that understands that incidental complexity eventually seeps out to for the user to deal with, and so on. Unfortunately, being framed as a designer means I have less natural authority when I say that Clojure is awesome. Although this is somewhat mitigated somewhat by the sheer shock of having a designer saying something comprehensible about a programming language. On Thursday, August 21, 2014 7:44:18 AM UTC+2, Quzanti wrote: If an investor were kicking people out, its usually because money is running low or for other more diffuse reasons. If an investor or boss somewhere where kicking out people at random, he would quickly loose respect from his other employeers. The rest would soon leave as well. Hence the need for a scapegoat. Generally if an investor can make 20% of their startups work, people will blame the technologists for the failure of the other 80%, and the investor will have a PR machine to distort the history if needed. But yes, startup hubs work best when there are angel investors who want to build a personal reputation or where the institutional investors have strong links with the universities producing the start up talent and so don't want to jeopardise those (eg the Stanford University system). Even the best VCs will shut down the majority of their start ups though, so you'd think that would make people avoid them, but there are always people out there who need money to try and realise their dreams. All a bit tangential to the the original thread question though, which was assuming a high growth, high pressure, scale it up fast, need results kind of culture, would Clojure be a good fit? On Wednesday, August 20, 2014 11:46:48 PM UTC+1, Linus Ericsson wrote: Well, for better or worse we don't like conflicts that much. This has benefits when it comes to some kinds of problem solving (the way to consensus in Swedish companies is worth at least a chapter in a big book about antrophology). This shyness for open conflicts can lead to stagnation. This means that status quo is not turned over that easily, but when it does, it happens like an avalanche (cow oscillator comes to mind). Stockholm University has Clojure and Erlang in its second year curriculum for computer science. Just saying. Apart from that, its 3kloc database queries and Java classes galore and Wordpress shops all over, like everywhere else. The single larges group of workers in Stockholm is of course computer programmer. 33000 people out of a million of so. If an investor were kicking people out, its usually because money is running low or for other more diffuse reasons. If an investor or boss somewhere where kicking out people at random, he would quickly loose respect from his other employeers. The rest would soon leave as well. In Sweden we have a system... the ironic saying goes, but the truth is that even though the housing situation is outright catastrophic, you would not ever be put on the street if you wasn't psychotic enough not to accept the help offered (worst case you would end up in a sad, sleepy, far far out suburb with long commuting
Re: Is Clojure a language for growth?
Have you read Paul Graham's *beating the averages http://www.paulgraham.com/avg.html*? I find it absolutely amazing, but one of the reasons that Clojure is such a phenomenal choice, if you can deal with the incidental complexity around it, is that it still is a somewhat non-obvious choice. Make your boss read the article as well, if s/he hasn't. As for recruiting, I'm not sure what input to give, as I haven't had to deal with that particular issue myself. I have a hunch that if you tried to engage people who have a background in functional languages rather than C++, you may find that they have an easier time to adapt and to learn how to read code. I'm guessing that the trouble that C++ devs find themselves with when trying to read the language has much more to do with patterns than grammar. I had a fun time showing core.async to someone who'd only worked with callbacks and futures/promises previously, and it took quite some time for them wrap their head around it. I think that it's possibly a feature rather than a bug that the patterns are non-obvious to someone completely new to the game. If not, they would be incremental, and the performance benefit for your organization would be similarly incremental. If you want a new level of something, rather than an increment of something, then logically, the stuff you need to learn is going to be somewhat alien. Clojure, provided that it is done in a Clojure kind of way, has all manner of benefits, if you discount the availability of people and how approachable it is to a person who has never seen it before. You and your organization has to decide if it's worth the effort to get the people who can do this, or if it makes more sense to settle on something that is widely available. Just bear in mind that if you go for what is common, your performance is most likely going to be on an average level as well. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Is Clojure a language for growth?
… as soon as anything goes wrong whether it has anything to do with the technology choice or not you become mr fall guy, to be blamed and fired so that other people can keep their jobs. Seen it happen so many times. Good lord, truly? Perhaps this is a good time to ask what culture OP lives in. This wouldn't happen where I live/work. -- 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: Transit Idea
Awesome! Well done! On Monday, August 18, 2014 12:55:23 AM UTC+2, Ashton Kemerling wrote: I went ahead and wrote it. I'm sure there are some bugs to work out, but for now it works in the basic cases. The pullrequest for this feature can be located on Solr's github here: https://github.com/apache/lucene-solr/pull/85. -- Ashton On Wednesday, August 13, 2014 6:50:34 PM UTC-6, Alex Miller wrote: Sounds good to me. :) On Wednesday, August 13, 2014 1:59:54 PM UTC-4, Ashton Kemerling wrote: I realized that Solr currently provides a lot of language-specific serializer options. Currently Ruby, Python, PHP, and javabin(?) are options, along with the normal json and xml. Wouldn't it make a lot of sense for us to add a transit-json and transit-messagepack options to Solr? -- Ashton -- 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] Sente - Clojure(Script) + core.async + WebSockets/Ajax
Yes, thanks for Sente, Peter! Will Sente eventually use/support Transit? :-) On Friday, August 15, 2014 11:30:56 AM UTC+2, Peter Taoussanis wrote: You're very welcome Andrew, thanks for saying so! Cheers! :-) -- *Peter Taoussanis* taoensso.com https://www.taoensso.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/d/optout.
Re: Core.logic for boardgames
I have no idea, but I'm also interested in the answer. ^_^ On Saturday, August 9, 2014 12:51:20 PM UTC+2, Robin Heggelund Hansen wrote: Hi. I'm starting a new project now, where users are presented with a set of boardgames (chess, checkers, othello...) which they then can play together online. Does it make sense to implement the game logic using core.logic, and does it transfer well to cljs (i'd like to share logic between backend and frontend if i can)? I don't know core.logic, but would like to learn if it is a good fit for the problem I'm solving. 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/d/optout.
Re: [ANN] Garden 1.1.7
Thanks! On Saturday, May 24, 2014 7:14:40 PM UTC+2, Joel Holdbrooks wrote: Garden, a library for authoring stylesheets in Clojure and ClojureScript, is now 1.1.7. ADDED: Support for :preamble IMPROVED: Support for meta data in garden.def/* macros https://github.com/noprompt/garden -- 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: rant / cljs in cljs ? :-)
If that is your criterion, use something that reloads the browser
automatically when the js is changed. I use CodeKit personally.
On Wednesday, April 2, 2014 10:09:45 PM UTC+2, lypanov wrote:
I hate REPLs. I also hate large compile times.
For me the hardest part of the ~5s compile time is not waiting, it's the
watching of the progress of the auto build and waiting until exactly that
moment
before pressing reload in the browser.
That being said, I find run this currently selected code block in my
connected browser functionality in editors (lighttable is the one I
use/know) to be
the best solution to this problem. It's painful as hell at first though.
I had a work around in the past via a fork of noir-cljs which would delay
the load of the .js files until compile completed via some hacks but
now that I've switched to a browser editor work flow I find myself
doing as much work as possible in the editor via the run it in the browser
REPL
script tag trick from lighttable that I'm no longer even noticing compile
times. I leave them to the end of the pomodoro.
On Friday, March 21, 2014 7:48:59 AM UTC+1, t x wrote:
Hi,
* I'm already using:
:incremental true
:compiler { :optimizations :none }
* I'm also aware of cljs brepl
However:
1) the cljs compiler is still too slow for my liking (even though it's
not calling closure)
2) I don't like the cljs repl nearly as much as I like the clj repl
Now, my dumb/stupid question:
Is there any cljs in cljs _slow_ interpreter? I'm perfectly happy
with an interpreter that runs 10x slower, if, in exchange, I get to
hit refresh and my new code starts running.
Furthermore, I'm _okay_ with their being a big delay every time I
introduce a new macro from clj land.
I realize this sounds spoiled -- but -- the cljs compiler delays are
really really breaking my flow.
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/d/optout.
Re: ANN: Om 0.5.0
Great stuff! Thanks! On Thursday, February 20, 2014 8:07:36 PM UTC+1, David Nolen wrote: The only change is that we now depend on the just released React 0.9.0. Feedback welcome! https://github.com/swannodette/om David -- 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: Reagent 0.3.0 - now with async rendering
Cheers, Dan! I'm doing experiments with both Reagent and Om at the moment, and I'm very excited about this way of rendering changes to a webpage. I particularly enjoy how easy it is to work with Reagent's API, and appreciate the time you are putting into this project. One of the major wins is how explicit I can be with where I put state. My current experimental design puts state squarely in two places only: an atom in the client, and the database (Datomic, for the time being). The server essentially behaves like a pure function only. I don't have time to enumerate all the benefits of this design as opposed to the mess I usually encounter, where state is stored absolutely everywhere. On Monday, February 3, 2014 3:24:25 PM UTC+1, Dan Holmsand wrote: Reagent, a minimalistic interface between React.js and ClojureScript, is now at 0.3.0. The new release adds a couple of bugfixes, and async rendering. Read more here: http://holmsand.github.io/reagent/news/reagent-is-async.html The project page is here: https://github.com/holmsand/reagent Cheers, /dan -- 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: data.fressian, read and write Fressian from Clojure
Thanks for this! I watched your talk about this on the conj, and this is really cool stuff. Are there any plans for a ClojureScript version of Fressian? On Thursday, November 14, 2013 5:51:41 PM UTC+1, stuart@gmail.com wrote: data.fressian [1] is a Clojure-language wrapper for the reference implementation [2] of Fressian. I am still setting up CI, maven release, etc. but wanted to get the source up so that interested parties can peruse and contribute. The wiki at [2] is currently the best source of documentation. Cheers, Stu [1] https://github.com/clojure/data.fressian [2] https://github.com/Datomic/fressian/wiki -- -- 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] Chord 0.2.1 - making WebSockets look like core.async channels in CLJ+CLJS
Cool! I presume you're restricted to EDN on the channels though, right?
On Saturday, November 30, 2013 5:23:17 PM UTC+1, James Henderson wrote:
https://github.com/james-henderson/chord
Chord is a library for making WebSockets look like simple core.async
channels in Clojure (using http-kit) and ClojureScript.
Basic usage:
Leiningen:
[jarohen/chord 0.2.1]
ClojureScript:
(:require [chord.client :refer [ws-ch]]
[cljs.core.async :refer [! ! put! close!]])(:require-macros
[cljs.core.async.macros :refer [go]])
(go
(let [ws (! (ws-ch ws://localhost:3000/ws))]
(! ws Hello server!)
(loop []
(when-let [{:keys [message]} (! ws)]
(js/console.log Got message from server: message)
(recur)
Clojure (a wrapper around http-kit's 'with-channel'):
(:require [chord.http-kit :refer [with-channel]]
[clojure.core.async :refer [! ! put! close! go]])
(defn your-handler [req]
(with-channel req ws-ch
(go
(let [{:keys [message]} (! ws-ch)]
(println Message received from client: message)
(! ws-ch Hello client from server!)
(close! ws-ch)
There's more documentation and a few code examples on the Github page, and
a full example project in the repo.
Feedback is *always very welcome* - either here, through Github in the
usual way or (if it fits into 140 chars!) Twitter.
Version 0.2.1 brings the ability to specify custom buffered channels -
thanks to Timo Sulg for the PR!
James (@jarohen)
--
--
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] Chord 0.2.1 - making WebSockets look like core.async channels in CLJ+CLJS
Since we don't really care what the data looks like while it's on the wire,
it could even be byte code in order to compress data. But it's certainly
nice if it's possible to use EDN in any case.
Also, you could consider whether it'd be worthwhile interacting with
something like SockJS in order to get wider platform support.
On Monday, December 2, 2013 2:02:35 PM UTC+1, James Henderson wrote:
Unfortunately Chord only accepts raw strings on the channel at the moment
- I've been using pr-str and read-string around EDN messages until now.
It's a great idea to be able to format/parse different message formats
automatically though and something that IMO Chord should provide. I've
added a GitHub issue https://github.com/james-henderson/chord/issues/4 -
watch this space!
Thanks,
James
On Monday, 2 December 2013 09:38:50 UTC, Henrik Eneroth wrote:
Cool! I presume you're restricted to EDN on the channels though, right?
On Saturday, November 30, 2013 5:23:17 PM UTC+1, James Henderson wrote:
https://github.com/james-henderson/chord
Chord is a library for making WebSockets look like simple core.async
channels in Clojure (using http-kit) and ClojureScript.
Basic usage:
Leiningen:
[jarohen/chord 0.2.1]
ClojureScript:
(:require [chord.client :refer [ws-ch]]
[cljs.core.async :refer [! ! put! close!]])(:require-macros
[cljs.core.async.macros :refer [go]])
(go
(let [ws (! (ws-ch ws://localhost:3000/ws))]
(! ws Hello server!)
(loop []
(when-let [{:keys [message]} (! ws)]
(js/console.log Got message from server: message)
(recur)
Clojure (a wrapper around http-kit's 'with-channel'):
(:require [chord.http-kit :refer [with-channel]]
[clojure.core.async :refer [! ! put! close! go]])
(defn your-handler [req]
(with-channel req ws-ch
(go
(let [{:keys [message]} (! ws-ch)]
(println Message received from client: message)
(! ws-ch Hello client from server!)
(close! ws-ch)
There's more documentation and a few code examples on the Github page,
and a full example project in the repo.
Feedback is *always very welcome* - either here, through Github in the
usual way or (if it fits into 140 chars!) Twitter.
Version 0.2.1 brings the ability to specify custom buffered channels -
thanks to Timo Sulg for the PR!
James (@jarohen)
--
--
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.
