Thanks for the correction, Alex.
On Sunday, July 19, 2015 at 12:34:37 PM UTC-4, Alex Miller wrote:
seqs on eductions *are* chunked - they will fall into this case during
seq:
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L524-L525
which produces a chunked
Stuart and Alex, thank you for your replies and recommondations.
I take it then that the problem is the seq casting performed in apply and
in reduce1.
For now the only way to avoid applys seq casting seems to be a hackish
.doInvoke call.
Kind regards,
Leon.
On Sunday, July 19, 2015 at
Hi Leon,
I think this is an edge case related to how varargs functions are
implemented in Clojure.
The varargs arity of `max` is implemented with `reduce1`: core.clj line 1088
https://github.com/clojure/clojure/blob/36d665793b43f62cfd22354aced4c6892088abd6/src/clj/clojure/core.clj#L1088
On Sunday, July 19, 2015 at 10:53:25 AM UTC-5, Stuart Sierra wrote:
Hi Leon,
I think this is an edge case related to how varargs functions are
implemented in Clojure.
The varargs arity of `max` is implemented with `reduce1`: core.clj line
1088
My understanding was that if I pass an eduction to a process using reduce,
I can save the computer time and space because the per step overhead of
lazy sequences is gone and also the entire sequence does not have to reside
in memory at once.
When I time the difference between (apply max (map
:
Is there a rule of thumb or set of use cases when metadata is a more
elegant solution than simply adding more entries to a map or record?
--
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
:
Is there a rule of thumb or set of use cases when metadata is a more
elegant solution than simply adding more entries to a map or record?
--
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
McKitrick
wrote:
Is there a rule of thumb or set of use cases when metadata is a more
elegant solution than simply adding more entries to a map or record?
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure
16:10:34 UTC+1 Jonathon McKitrick napísal(-a):
Is there a rule of thumb or set of use cases when metadata is a more
elegant solution than simply adding more entries to a map or record?
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post
Is there a rule of thumb or set of use cases when metadata is a more
elegant solution than simply adding more entries to a map or record?
--
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
Yes- when the data you want to add shouldn't affect the value of the map.
---
Joe R. Smith
@solussd
On Jan 29, 2015, at 9:10 AM, Jonathon McKitrick jmckitr...@gmail.com wrote:
Is there a rule of thumb or set of use cases when metadata is a more elegant
solution than simply adding more
2014-07-10 18:34 GMT+02:00 Plínio Balduino pbaldu...@gmail.com:
IMO, ! is used when change any global state. A side effect like print on
screen is not enough to cause a ! in the name. I think that's why the
functions print/println don't have ! =)
Than I did it in the 'right' way. In the
2014-07-10 18:46 GMT+02:00 Stefan Kamphausen ska2...@gmail.com:
On Thursday, July 10, 2014 5:28:26 PM UTC+2, Cecil Westerhof wrote:
When a function returns a true/false value you should end it with a '?'.
Clojure Programming says that with side effects you should end the
function name with
Hi,
On Friday, July 11, 2014 11:10:53 AM UTC+2, Cecil Westerhof wrote:
2014-07-10 18:34 GMT+02:00 Plínio Balduino pbal...@gmail.com
javascript::
IMO, ! is used when change any global state. A side effect like print on
screen is not enough to cause a ! in the name. I think that's why the
2014-07-10 19:10 GMT+02:00 Softaddicts lprefonta...@softaddicts.ca:
The fn that does the display is the one having side effects.
Now if your look fn creates the side effect, it should reflect that in its
name.
Look discribes the current location. So it has a side-effect, but as I
understood
2014-07-11 11:28 GMT+02:00 Stefan Kamphausen ska2...@gmail.com:
On Friday, July 11, 2014 11:10:53 AM UTC+2, Cecil Westerhof wrote:
2014-07-10 18:34 GMT+02:00 Plínio Balduino pbal...@gmail.com:
IMO, ! is used when change any global state. A side effect like print on
screen is not enough to
I look at side effects this way, will it ever record some state change that
some
code in the universe will eventually rely on ?
If no, then there's no state change/side effect to care about.
Sending a message is a side effect (a pgm will eventually use it), writing to
a database, ... qualify.
Hi,
On Friday, July 11, 2014 11:33:34 AM UTC+2, Cecil Westerhof wrote:
2014-07-10 19:10 GMT+02:00 Softaddicts lprefo...@softaddicts.ca
javascript::
but as I understood from others it is not about side-effects, but global
state.
as James and I already pointed out, that is not what it
2014-07-11 14:19 GMT+02:00 Softaddicts lprefonta...@softaddicts.ca:
I look at side effects this way, will it ever record some state change
that some
code in the universe will eventually rely on ?
If no, then there's no state change/side effect to care about.
Sending a message is a side
2014-07-11 14:28 GMT+02:00 Stefan Kamphausen ska2...@gmail.com:
On Friday, July 11, 2014 11:33:34 AM UTC+2, Cecil Westerhof wrote:
2014-07-10 19:10 GMT+02:00 Softaddicts lprefo...@softaddicts.ca:
but as I understood from others it is not about side-effects, but global
state.
as James
You do not reuse log file output to propagate state changes.
If you do I would like to know for what purpose...
In my world the ultimate goal of log file output is human consumption with or
without aggregation or alert filtering.
It has nothing to do with your system internal state. It's merely
When a function returns a true/false value you should end it with a '?'.
Clojure Programming says that with side effects you should end the function
name with a '!'.
I have functions reset-game! and walk!. But what about a function like
look? It does not change state, but it displays where you
IMO, ! is used when change any global state. A side effect like print on
screen is not enough to cause a ! in the name. I think that's why the
functions print/println don't have ! =)
Plínio
On Thu, Jul 10, 2014 at 12:28 PM, Cecil Westerhof cldwester...@gmail.com
wrote:
When a function returns
On Thursday, July 10, 2014 5:28:26 PM UTC+2, Cecil Westerhof wrote:
When a function returns a true/false value you should end it with a '?'.
Clojure Programming says that with side effects you should end the
function name with a '!'.
Use the bang! only for things not safe in an STM
In clojure.core, an ending ! indicates a function that is unsafe for STM,
rather than one with side effects. For instance, alter and send are
functions with side effects, but have no ending ! because they're safe to
use in a dosync block.
In other words, an ending ! indicates a function has side
The fn that does the display is the one having side effects.
Now if your look fn creates the side effect, it should reflect that in its name.
But... I wonder why it does so. Looking at something does not change state.
You may be better splitting the side effect away from it or change the name.
See points 2, 3 and 8 at http://clojure.org/refs
It is just a way to obtain the change lock of the ref in the dosync
transaction, without rewriting it. The alternative would be to
explicitly modify it to the same value as it was before, which is
potentially wasteful.
One possible case where this
Hi,
When dealing with Clojure ref types, when to use (ensure) ?
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
I believe it is to avoid write skew. Check this Wikipedia page:
http://en.m.wikipedia.org/wiki/Snapshot_isolation
--
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
Hi Hussein,
Maybe this StackOverflow QA can help in understanding when to use *ensure*
: Clojure STM ambiguity factor http://stackoverflow.com/a/17197281/519383.
HTH,
Juan
On Thursday, June 19, 2014 10:35:24 AM UTC-3, Hussein B. wrote:
Hi,
When dealing with Clojure ref types, when to use
I tried it with doseq many times, but the behvior is the same. In the
REPL I got a full map of information, but when I use the program the map
with the agent logs is empty.
Am 22.04.2012 19:51, schrieb Moritz Ulrich:
Just a quick guess after a quick glimpse at the code you linked:
(map
[number-of-creators time timetype]
(prepare-evolution number-of-creators)
(start-evolution)
(track-evolution time timetype))
And when I use this function
=(def stat (retrieve-new-stats 3 5 :second))
I get as result for '(:creator-log stat)' this:
{593848 {}, 9db6ff {}, d03269
is the Map with the information I described above).
To make it easier I wrote a function which I want to execute
(defn retrieve-new-stats
[number-of-creators time timetype]
(prepare-evolution number-of-creators)
(start-evolution)
(track-evolution time timetype))
And when I use
time timetype))
And when I use this function
=(def stat (retrieve-new-stats 3 5 :second))
I get as result for '(:creator-log stat)' this:
{593848 {}, 9db6ff {}, d03269 {}}
In this case I get only empty maps. I tried also to use do in the function
like
(defn retrieve-new-stats
[number-of-creators
It works now, thank you, Jonas.
--
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
Hi all:
I got trouble when i combine use condition-map and doc-string in my
function, the condition-map seems not work anymore:
user= (defn f [x]
{:pre [(pos? x)]}
x)
#'user/f
user= (f -1)
AssertionError Assert failed: (pos? x) user/f (NO_SOURCE_FILE:1)
user= (defn another
The docstring goes before the argument list:
(defn another-f
doc string here
[x]
{:pre [(pos? x)]}
x)
user= (another-f -1)
java.lang.AssertionError: Assert failed: (pos? x) (NO_SOURCE_FILE:0)
user= (doc another-f)
-
user/another-f
([x])
I'm implementing a litte game thing in Clojure. So far I'm passing
around a world status object among functions. It is very
functional and I can simulate any moment of the game my simply
feeding the system with a made-up world state.
Since Clojure has a very sophisticate system for managing state
On Fri, Oct 14, 2011 at 7:58 AM, pistacchio pistacc...@gmail.com wrote:
I'm implementing a litte game thing in Clojure. So far I'm passing
around a world status object among functions. It is very
functional and I can simulate any moment of the game my simply
feeding the system with a made-up
On Oct 14, 2011, at 8:48 AM, Timothy Baldridge wrote:
On Fri, Oct 14, 2011 at 7:58 AM, pistacchio pistacc...@gmail.com wrote:
I'm implementing a litte game thing in Clojure. So far I'm passing
around a world status object among functions. It is very
functional and I can simulate any moment of
this to learn more! I'd like to
know some good sources of further information on when to use #' . It is
a
bit mysterious to me at this point.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure
Hi, I find it extremely hard to google this to learn more! I'd like to
know some good sources of further information on when to use #' . It is a
bit mysterious to me at this point.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post
alexander.barano...@gmail.com wrote:
Hi, I find it extremely hard to google this to learn more! I'd like to
know some good sources of further information on when to use #' . It is a
bit mysterious to me at this point.
--
You received this message because you are subscribed to the Google
Groups
expands to (var x).
from:
http://clojure.org/special_forms#var
On Wed, Jan 12, 2011 at 9:11 PM, Alex Baranosky
alexander.barano...@gmail.com wrote:
Hi, I find it extremely hard to google this to learn more! I'd like to
know some good sources of further information on when to use
Thanks everyone for all of the feedback. I think I have a solution to
the warnings and if I understand deftype/defrecord, I should be able
to replace defrecord with deftype in my implementation. I'll give it a
try and report back when I have a chance.
Thanks,
Damon
On Dec 26, 7:31 pm, David
This worked as expected. I just replaced defrecord with deftype here
https://github.com/drsnyder/beanstalk/blob/82f301f1f825bb05aa14d85a220ec57c1dea61b2/src/beanstalk/core.clj#L117
and re-ran my tests.
The suggestion from Baishampayan to add (:refer-clojure :exclude [read
peek use]) also worked.
Hello,
In an effort to learn a little more about clojure (and possibly
introduce it at work) I decided to write a native client for the
Beanstalk work queue. See http://kr.github.com/beanstalkd/ for more
information about the queue and https://github.com/drsnyder/beanstalk
for the client.
One of
But one issue I encountered with defprotocol is that there appears to
be a possible symbol table/space issue. When I compile, I get warnings
like the following:
Warning: protocol #'beanstalk.core/BeanstalkObject is overwriting
function read
Warning: protocol #'beanstalk.core/BeanstalkObject
Damon Snyder drsny...@gmail.com writes:
One of the decisions I wasn't sure about was whether to use a protocol
or a struct map for the (socket, reader, writer) tuple. I started
using a struct-map and then switched over to defprotocol/defrecord.
See
On Sun, Dec 26, 2010 at 7:18 PM, Alex Osborne a...@meshy.org wrote:
Damon Snyder drsny...@gmail.com writes:
One of the decisions I wasn't sure about was whether to use a protocol
or a struct map for the (socket, reader, writer) tuple. I started
using a struct-map and then switched over to
Ken Wesson kwess...@gmail.com writes:
On Sun, Dec 26, 2010 at 7:18 PM, Alex Osborne a...@meshy.org wrote:
Struct maps were in the language for a long time before defrecord was
added. Records are supposed to replace them for most purposes. So if
in doubt between the two use a defrecord.
On Sun, Dec 26, 2010 at 8:20 PM, Alex Osborne a...@meshy.org wrote:
Ken Wesson kwess...@gmail.com writes:
On Sun, Dec 26, 2010 at 7:18 PM, Alex Osborne a...@meshy.org wrote:
Struct maps were in the language for a long time before defrecord was
added. Records are supposed to replace them for
Ken Wesson kwess...@gmail.com writes:
Actually you don't need to AOT compile records or types. They work fine
for interactive development.
Eh. That's not what I saw written elsewhere. Or is it just protocols?
Though usually those are used hand-in-hand with records.
Perhaps you're thinking
On Sun, Dec 26, 2010 at 9:25 PM, Alex Osborne a...@meshy.org wrote:
Ken Wesson kwess...@gmail.com writes:
Actually you don't need to AOT compile records or types. They work fine
for interactive development.
Eh. That's not what I saw written elsewhere. Or is it just protocols?
Though usually
On Sun, Dec 26, 2010 at 10:00 PM, Ken Wesson kwess...@gmail.com wrote:
On Sun, Dec 26, 2010 at 9:25 PM, Alex Osborne a...@meshy.org wrote:
Ken Wesson kwess...@gmail.com writes:
Actually you don't need to AOT compile records or types. They work fine
for interactive development.
Eh. That's
On Sun, Dec 26, 2010 at 9:00 PM, Ken Wesson kwess...@gmail.com wrote:
On Sun, Dec 26, 2010 at 9:25 PM, Alex Osborne a...@meshy.org wrote:
Ken Wesson kwess...@gmail.com writes:
Actually you don't need to AOT compile records or types. They work fine
for interactive development.
Eh.
I've recently discovered the io! macro. Is this something to try to use all
the time.. or only in certain situations?
It's useful when you are exposing some sort of an API (internal
external) and want to prohibit the use of certain functions inside
transactions.
Regards,
BG
--
Baishampayan
This is a good question and I'm not sure of the right answer or if
there is one. Personally, if I were exposing an API I would use the
io! macro for sure. Even otherwise its a good convention to follow.
On Nov 30, 9:06 am, Alex Baranosky alexander.barano...@gmail.com
wrote:
Hi guys,
I've
It gives a convenience macro which checks if there is a transaction running
when the following code block is called. The idea is that since the code in
a transaction could be called a multiple times, you should not do things
like sending things on to the network or writing to a file during a
What I said is purely from reading the documentation .. I have never ever
used it. Take it with a pinch of salt!
On Sat, Dec 4, 2010 at 8:40 AM, Sunil S Nandihalli
sunil.nandiha...@gmail.com wrote:
It gives a convenience macro which checks if there is a transaction running
when the following
Hi guys,
I've recently discovered the io! macro. Is this something to try to use all
the time.. or only in certain situations?
Alex
--
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
question:
What would be the better implementation? When should I use loop/recur
and when seq library functions? Stuart Halloway writes in his book
Use recur when you are producing scalar values or small, fixed
sequences and also Know the sequences library. You can often write
code without
msecs
Elapsed time: 0.214048 msecs
Elapsed time: 0.217317 msecs
As you can see, the loop/recur version is a bit faster (not
significantly but a little bit). This leads me to a general question:
What would be the better implementation? When should I use loop/recur
and when seq library functions
Here's your second implementation cleaned up a little:
(defn perimeter [ pn]
(apply +
(map euclidean-distance pn (rest pn
My own personal opinion is:
The second approach is
(1) faster to write
(2) easier to understand
(3) less error-prone
So that's the one that I prefer.
IF the first
Hi,
Am 29.08.2009 um 21:48 schrieb ronen:
In a lot of cases its seems that macros are used even when a function
can do the same task,
Macros seems to be less readable than their functional counterparts
more complex to write (to me at least).
Its clear that there are special cases in which
On Aug 29, 3:48 pm, ronen nark...@gmail.com wrote:
In a lot of cases its seems that macros are used even when a function
can do the same task,
Macros seems to be less readable than their functional counterparts
more complex to write (to me at least).
Its clear that there are special
I would argue that macros always should be syntax wrappers for
functions. Coding the logic into a macro in most cases is a mistake.
So first write the function that does the work. Then write a macro
that simplifies a syntax to call that function.
Cool, I guess that there is no one correct answer but more a
question of style experience,
the separation of logic code mangling into two parts makes the most
sense to me.
Ill continue to sharp my macro foo ;)
On Aug 30, 8:16 pm, Vagif Verdi vagif.ve...@gmail.com wrote:
I would argue that
In a lot of cases its seems that macros are used even when a function
can do the same task,
Macros seems to be less readable than their functional counterparts
more complex to write (to me at least).
Its clear that there are special cases in which macros are the perfect
solution (like partial
69 matches
Mail list logo
