On Aug 12, 2009, at 10:34 PM, Richard Newman wrote:
> This is the difference between 'conventional' and point-free style, by
> the way. Many people view point-free as being somehow more elegant,
> and I'm generally inclined to agree... apart from in cases like your
> example, where a ton of part
I know that if you have a dosync call in some function executed by a
thread, and then that function calls other functions (which might have
their own dosyncs, which get bundled together with the original
transaction), then everything is fine. It seems common that all of
that work would be done se
2009/8/12 Chas Emerick :
>
> On Aug 12, 2009, at 3:19 PM, Mark Volkmann wrote:
>
>> I didn't release it was valid to define names with colons in them.
>> Maybe that shouldn't be allowed. I'd like to be able to specify type
>> hints using UML-like syntax like the second example from Chas which
>> w
http://github.com/swannodette/convex-hull/tree/master
This version runs in 2-2.5s. About exactly an order of magnitude slower than
Java.
Amazingly, I did discover afterwards
that there is a Clojure version that is _exactly_ the same speed as
the Java version:
.
.
.
(.test (new TimeJarvisMarch))
-XX:+AggressiveOpts improves another 5-10%.
EscapeAnalysis seems more important than BiasedLocking.
I don't have a disassembling module installed. Could someone use the
PrintAssembly option and put the asm for the JITed method somewhere.
It could be interesting to see it side by side with the
On Thu, Aug 13, 2009 at 10:40 AM, Glen Stampoultzis wrote:
>> There was a good thread on this list some weeks ago which mentioned
>> another JVM flag:
>> -XX:+PrintOptoAssembly
>>
>> The original thread:
>>
>> http://groups.google.com/group/clojure/browse_thread/thread/314952431ec064b7?fwc=1
>>
>
> I know that if you have a dosync call in some function executed by a
> thread, and then that function calls other functions (which might have
> their own dosyncs, which get bundled together with the original
> transaction), then everything is fine. It seems common that all of
> that work would
Hi,
On Aug 13, 11:58 am, Chas Emerick wrote:
> That said, I would urge caution in circumstances like what you've
> described.
Additionally, transactions should be kept small. IIRC,
Rich recommended that before. If possible, don't do
complicated calculations inside a transaction.
Sincerely
M
Hi,
I think I know what is going on.
You are using the Clojure 1.0, but you should use the latest Clojure,
because there are depoendencies.
This is what you need to do:
1. remove Clojure 1.0
2. get latest Clojure with git
3. get latest Clojure-Contrib with git
4. build Clojure using A
Piyush,
I would have to disagree. If fft1976 was a troll then he wouldn't be
contributing meaningfully and substantively to testing performance in
Clojure on another thread. So I think your accusation was unfair.
That said, I did find some of fft1976's comments to be somewhat
unnecessarily test
Although I didn't solve the problem, I can confirm it.
I'm using latest clojure, slime, swank-clojure (pulled daily), and
Cygwin Emacs 23 on XP.
On 22 Jul., 22:45, Kelvin Ward wrote:
> I've been using EmacsW32 withSLIME. Whenever I call (read-line) in
> theREPLit never completes reading the inp
On Aug 13, 12:25 pm, Arie van Wingerden wrote:
> Hi,
>
> I think I know what is going on.
> You are using the Clojure 1.0, but you should use the latest Clojure,
> because there are depoendencies.
>
> This is what you need to do:
> 1. remove Clojure 1.0
> 2. get latest Clojure with git
>
On Aug 11, 8:45 pm, Chouser wrote:
> I don't know either. 'loop' is a macro that expands to
> 'loop*', which is in turn a special form. At that most
> basic level, loop* still creates a recur point, so I don't
> think that's the point.
Can you enlighten us, Rich?
Cheers,
/Karl
--~--~--
This is the same Clojure for Lispers talk with audio, and video of
slides, available on clojure.blip.tv, among others, from the September
2008 Boston Lisp meeting.
It has been uploaded to the files section of the group with this name:
clojure-for-lispers-transcript.txt
I've added a very few ref
I'm just wondering what people's response would be to allow user-generated
reader macros. I'm not sure, but I think the only change to the clojure
core that would be necessary in order to do this would be that in
clojure/src/jvm/clojure/lang, LispReader.dispatchMacros would have to be
made public.
On Aug 12, 2009, at 3:24 PM, Chas Emerick wrote:
>> I'd hate to see somebody do it, but it's currently valid to define
>> variables with colons in them, so there could be code out in the wild
>> with those definition forms already. Other than that, I like the
>> looks of it. I think the macro
On Aug 13, 2009, at 2:30 PM, Brian Hurt wrote:
> I'm just wondering what people's response would be to allow user-
> generated reader macros. I'm not sure, but I think the only change
> to the clojure core that would be necessary in order to do this
> would be that in clojure/src/jvm/clojur
Hi,
Am 13.08.2009 um 22:30 schrieb Brian Hurt:
Now, I can certainly see a lot of potiential downsides to this.
Redefining what #{} or #() means is just the start.
I think, this is the reason Rich is not very positive for that idea:
because nobody came up with a way of defining "namespaces
On Aug 13, 2009, at 4:59 PM, Daniel Lyons wrote:
> On Aug 13, 2009, at 2:30 PM, Brian Hurt wrote:
>
>> I'm just wondering what people's response would be to allow user-
>> generated reader macros. I'm not sure, but I think the only change
>> to the clojure core that would be necessary in ord
On Thu, Aug 13, 2009 at 5:14 PM, Meikel Brandmeyer wrote:
> Hi,
>
> Am 13.08.2009 um 22:30 schrieb Brian Hurt:
>
>> Now, I can certainly see a lot of potiential downsides to this.
>> Redefining what #{} or #() means is just the start.
>
> I think, this is the reason Rich is not very positive for
On Thu, Aug 13, 2009 at 5:23 PM, Aaron Cohen wrote:
> On Thu, Aug 13, 2009 at 5:14 PM, Meikel Brandmeyer wrote:
>> Hi,
>>
>> Am 13.08.2009 um 22:30 schrieb Brian Hurt:
>>
>>> Now, I can certainly see a lot of potiential downsides to this.
>>> Redefining what #{} or #() means is just the start.
>>
What is the main point of reader macros? Is it so you can define your
own short-hand syntax, or is it the ability to get more direct access
to the reader?
If it is the first point, then I'd be happy to not have them - to me
shorthand doesn't buy much.
If it is the second point then why not simply
On Aug 13, 2009, at 3:35 PM, Bradbev wrote:
>
> What is the main point of reader macros? Is it so you can define your
> own short-hand syntax, or is it the ability to get more direct access
> to the reader?
> If it is the first point, then I'd be happy to not have them - to me
> shorthand doesn
On Aug 13, 3:43 pm, Daniel Lyons wrote:
> On Aug 13, 2009, at 3:35 PM, Bradbev wrote:
>
>
>
>
>
> > What is the main point of reader macros? Is it so you can define your
> > own short-hand syntax, or is it the ability to get more direct access
> > to the reader?
> > If it is the first point, t
On Aug 13, 1:30 pm, Brian Hurt wrote:
> I'm just wondering what people's response would be to allow user-generated
> reader macros. [...]
I think you could get most of the benefits for DSL's by using regular
strings, except that regular strings have quoting issues:
(my-dsl-macro "Here is my
On Aug 13, 2009, at 8:29 PM, Scott wrote:
> A single "super quoted" string reader would avoid this problem.
> Instead of defining a new read syntax like:
>
> #my-syntax(your DSL goes between here and here)
>
> Clojure could provide a general purpose string creating read syntax.
> Something like
On Jul 31, 1:47 pm, Chris Kent wrote:
> Great. As far as my (possibly flawed) understanding goes it should be
> pretty simple. Make it implementSerializableand add a readResolve
> method that returns intern(sym). sym will have already been interned
> by its own readResolve method.
No, you're
On Aug 14, 2:47 am, Chas Emerick wrote:
> On Aug 13, 2009, at 8:29 PM, Scott wrote:
>
> > A single "super quoted" string reader would avoid this problem.
> > Instead of defining a new read syntax like:
>
> > #my-syntax(your DSL goes between here and here)
>
> > Clojure could provide a general pu
>> So, what are people's thoughts?
>
> Trying to use them in Common Lisp has frustrated the crap out of me.
> The only library I know of that promulgates them seriously is CL-SQL
> and the gymnastics you have to do to install the reader macros are
> frustrating. Another library I tried to us
On Aug 13, 5:47 pm, Chas Emerick wrote:
>
> A good thought, but #"foo" is reader syntax for defining a regular
> expression with the pattern "foo". :-/
>
Sorry about that, I'm not experienced at Clojure, but I should have
been more clear. The first important part isn't which character
trigge
Hmm, not so sure this is related, but I've often thought it would be
great to have some way of having "embedded" source of other types as a
"special" string defined as normal in the clojure source but marked in
such as way that the editor (vim, emacs, etc) could recognise this and
do formatting, s
I was just watching that earlier. Here's an interesting part (as per
earlier discussion).
http://blip.tv/file/1313503
56:00
With type hints, you can get Java (?) code to run EXACTLY the same
speed as Java, so Clojure is FAST.
P.S. The moderators (Chouser) are now censoring my posts, so if you
d
On Aug 13, 2009, at 5:30 PM, Bradbev wrote:
>>> More complex "reader" macros could be (infix x + y + z / 3).
>>
>> I think you can already do that with regular macros.
>
> I don't think so. Macros are invoked after the read stage but before
> evaluation of arguments. This kind of macro would b
On Aug 13, 2009, at 6:56 PM, fft1976 wrote:
>
> I was just watching that earlier. Here's an interesting part (as per
> earlier discussion).
>
> http://blip.tv/file/1313503
> 56:00
>
> With type hints, you can get Java (?) code to run EXACTLY the same
> speed as Java, so Clojure is FAST.
And you
When running the AOT compiled Clojure (clojure.jar) on an Azul box I
get an error during startup (in particular in the class-initializer
for clojure.main). This error does not occur in the clojure-slim.jar.
The stacktrace is this:
k...@azulpod1:~/download$ java $JVM_PARAMS -cp clojure.jar clojure
On Aug 14, 2009, at 12:48 AM, Daniel Lyons
wrote:
>
>
> On Aug 13, 2009, at 5:30 PM, Bradbev wrote:
>
More complex "reader" macros could be (infix x + y + z / 3).
>>>
>>> I think you can already do that with regular macros.
>>
>> I don't think so. Macros are invoked after the read stag
On Aug 14, 2009, at 2:03 AM, Chouser wrote:
>
>
> On Aug 14, 2009, at 12:48 AM, Daniel Lyons
> wrote:
>
>>
>>
>> On Aug 13, 2009, at 5:30 PM, Bradbev wrote:
>>
> More complex "reader" macros could be (infix x + y + z / 3).
I think you can already do that with regular macros.
>
37 matches
Mail list logo
