Re: Polymorphic protocols and containers....
Do you know of a reason why (deftype [foo & more]) isn't read in as having two fields where the second is a seq? Barring that, would it be reasonable to disallow & as a valid field name, thus preventing this class of error? On Nov 4, 11:54 pm, Christophe Grand wrote: > On Fri, Nov 5, 2010 at 1:39 AM, Mike Meyer < > > > > > > > > > > mwm-keyword-googlegroups.620...@mired.org> wrote: > > It seems like the polymorphism of protocols breaks inside the > > methods. This is a problem for having a function that's polymorphic > > between an object and a container of the same objects. > > > For instance: > > > user=> (defprotocol Tune (tweek [this])) > > Tune > > user=> (deftype Knob [name] Tune (tweek [this] (println "Tweeked" name))) > > user.Knob > > user=> (def base (Knob. "base")) > > #'user/base > > user=> (tweek base) > > Tweeked base > > nil > > user=> (def treble (Knob. "treble")) > > #'user/treble > > user=> (tweek treble) > > Tweeked treble > > nil > > user=> (deftype Box [& knobs] Tune (tweek [this] (for [knob knobs] (tweek > > knob > > this vector is not an argument list but a field list, so you are defiing to > fields, one named & and one named knobs. > Try to evaluate (.name (.knobs (Box. base treble))) and you'll see that > knobs only holds treble. > > if you fix it: > (deftype Box [knobs] Tune (tweek [this] (for [knob knobs] (tweek knob > > then: > (tweek (Box. [base treble])) > > will work as expected. > > If you really want var-args, you just have to write a factory fn > (defn box [& knobs] (Box. knobs)) > > hth, > > Christophe -- 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
Re: Some questions about Clojure Protocols
Hi,
On 5 Nov., 03:17, ka wrote:
> Yes Meikel that is exactly what I have right now. Just trying to learn
> and stir up a discussion here :)
And it's a good discussion. I think many in the community - myself
included! - don't grok protocols, yet. So any discussion on how they
are intended to be used is of value. :)
> (deftype ReallyCool ... Coolness .. Comparable .. Serializable)
> (deftype SneakyCool .. Coolness)
>
> (x (ReallyCool.)) ;yay rocket launches and reaches moon!
> (x (SneakyCool.)) ;rocket launches alright (no exception thrown), but
> blows mid air
Yeah. That's tragic. But the fate of dynamic typing. As I said: what
is the difference to your protocol function calling seq on an argument
of your protocol function which turns out at runtime to be not
seqable? 3 2 1 0 "We have a lift off!" "100m" "200m"..*BOOM*. You may
want some dependency graph on your protocols, but why stop half the
way? Then we can go the full way to static typing. I don't see the
first argument of a protocol function differently from an importance
point of view besides it's used to choose the implementation which is
used in the call.
> I know you might argue its a code bug and caller's problem etc. - but
> you just allowed a rocket to blow up.
Yeah. Then use Haskell, OCaml or Ada. Any dynamically typed languge
will suffer from such types of problems. I think the magic word
usually used here is "testing".
> static public ISeq seq(Object coll){
> if(coll instanceof ASeq)
> return (ASeq) coll;
> else if(coll instanceof LazySeq)
> return ((LazySeq) coll).seq();
> else
> return seqFrom(coll);
>
> }
>
> @Laurent,> * first, when I see calls to (instance?) (satisifies?), it rings a
> bell in my head. "design problem".
>
> Do you see the above seq method as a design problem? - or if you don't
> care about Java, consider clojure.walk.
I think no one (including Rich) disagrees when I say that this sucks.
This type of thing is exactly the reason why protocols exist: to
handle this problem fast. (Multimethods would scratch the same itch,
but are too slow for low-level code. seq is called quite a lot around
the library.)
> I simply asked - is there anything fundamentally wrong with the notion
> of those protocols being composable. Protocol P is a set of abstract
> functions, can we have a convenient way of saying P = union(P1, P2) ?
Maybe that's perfectly fine? I don't know. I leave this to people with
more experience than I have. But as I said I have a feeling that there
is swinging a lot of object-oriented thinking in this style of
reasoning. I'm not sure whether this is good or bad, or whether I'm
just reacting alergic to O's.
> On a related note how is this:
>
> (defn dispatch-fn [this ..]
> (if (and (comparable? this) (serializable? this))
> :green-signal :red-signal)
>
> (defmulti x dispatch-fn)
> (defmulti y dispatch-fn)
> (defmulti z dispatch-fn)
I don't understand this: what do you do in case of :red-signal? Handle
things gracefully? How is this different to catching an exception?
On 5 Nov., 03:42, David Nolen wrote:
> This highlights a sore spot in the current multimethod implementation - the
> dispatch fn is "closed".
The dispatch function might just as well be another (open)
multimethod.
Sincerely
Meikel
--
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
Re: Some questions about Clojure Protocols
2010/11/5 ka :
> static public ISeq seq(Object coll){
> if(coll instanceof ASeq)
> return (ASeq) coll;
> else if(coll instanceof LazySeq)
> return ((LazySeq) coll).seq();
> else
> return seqFrom(coll);
> }
>
> @Laurent,
>> * first, when I see calls to (instance?) (satisifies?), it rings a bell in
>> my head. "design problem".
> Do you see the above seq method as a design problem? - or if you don't
> care about Java, consider clojure.walk.
Yes. And protocols were created to avoid that.
>
> If I understand you correctly (probability of which is less) you don't
> really see protocols as defining abstractions - but just as a
> convenient tool for polymorphism. Like:
As was said by David, polymorphism is already a kind of abstraction ?
>
> (extend ReallyCool clojure.contrib.json/Write-JSON
> {:write-json ...})
>
> But all of this discussion is kind of bypassing my original question,
Sorry for having hijacked the thread with my thoughts :-/
--
Laurent
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Polymorphic protocols and containers....
On Fri, Nov 5, 2010 at 8:23 AM, ataggart wrote: > Do you know of a reason why (deftype [foo & more]) isn't read in as > having two fields where the second is a seq? > deftype is low level and exposes limitations of the host and constructors should not be exposed directly (add a new field, change the field ordering and you'll have to fix all the constructor calls) but through a factory fn. Barring that, would it be reasonable to disallow & as a valid field > name, thus preventing this class of error? > It sounds reasonable. Christophe -- 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
Re: Documentation lacking for ns macro
2010/11/4 Ken Wesson : > The ns macro seems to be poorly documented as yet. The Namespaces page > at the main Clojure site does not go into detail about its syntax; Yes. The docs related to the ns form are indeed insufficient and need attention. However, have you seen the http://clojure.org/libs page? I think it will answer *some* of you questions. That page isn't perfect, but it seems to contain the kind of examples you are looking for. // raek -- 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
Re: REQUEST for feedback on http://clojure.org
I think there should be a link from the Namespaces page to the Libs page. Hopefully, this will make it easier for people to find examples on how to use the ns form. -- 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
compiling a protocol with types
Hi,
I'm trying to define an interface for our automated import system
written in Clojure so that we can use parsers implemented in Java. So
far everything works great, but I'm wondering if there is any way to
get types into the method signatures in the interface. For starters I
created a simple protocol:
(ns importer.parser)
(defprotocol Parser
(parse ^java.util.Iterator [this ^java.lang.String path]))
compiled it from the repl:
(compile 'importer.parser)
and then when I decompile it using jd-gui I get this:
package importer.parser;
public abstract interface Parser
{
public abstract Object parse(Object paramObject);
}
It would be nice to have a tool that could inspect a Clojure namespace
and then generate Javadoc for the protocols and types. Does something
like this already exist? If that javadoc could specify the types,
even if under the hood it's using Object, that would also be fine. Is
there a way to access this type hint information though? I don't see
it in the importer.Parser map.
Thanks,
Jeff
--
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
Re: From jetty to war?
On Nov 3, 2010, at 11:43 AM, Sean Corfield wrote: > Why are folks so insistent on monolingual systems? Business reasons. Two languages means staffing expertise in both languages, either people who know both and cost more, or two people who cost less. In compsci terms, it's another dependency, which increases vulnerability. And Clojure and Ruby are quite different in syntax, features and general attitude about the world. Finally, while Clojure is great, it is not accepted enough yet to be able to easily find people who know it, who are good, and who are available. (All up-and-coming languages have to deal with this. The solution is to be dramatically better at solving certain problems, aka having a killer app. Ruby's killer app was/is Rails. When you are 10x more efficient at solving a problem, the bean counters wake up.) I don't even like having to use Javascript, or even HTML or CSS. I do so because it's the only way, really. I wish I could do everything in one great language. Which leads me to faenie's earlier comment: On Nov 1, 2010, at 3:34 PM, faenvie wrote: > my short-time experience with implementing webapps on > a clojure-base is: > > i feel like in the very early days of java-servlet-api and j2ee. That's my feeling too. Clojure is very impressive, but I think the ecosystem needs some maturing, more like e.g. jRuby. I'd like to see Clojure have a Pythonesque (batteries included) core library (not bifurcated as with clojure-contrib) that allows you to do the vast majority of what you'd want to do without additional libraries; and a gem or CPAN-style repository of modules. On a simpler level, I'd like it to Just Work Without Hassles. Install Clojure, write script, run anywhere without complex commands, twiddling with the environment, etc. For me, getting simple Clojure programs to work was difficult, not because I wrote them wrong, but because I had to deal with the idiosyncrasies of the JVM way of doing things. It's still a great start and I am eager to see how Clojure develops over the coming months and years. steven -- 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
bit manipulation and java arrays
Hi... my first post here, so hello everyone! I just started to learn Clojure and I currently try to use int arrays and bit manipulation. All the bit manipulation works great, but if the highest bit is set, I cannot write back the result into the array using e.g. (aset-int (make-array Integer/TYPE 1) 0 0x8000) I get an error: "Value out of range for int: 2147483648" I found that 0x8000 is propagated to a long (other than java which on 8 character hex literals keeps an int) so I try to cast using (int 0x8000) as possible in Java but still the error occurs. Any ideas what I can do here? Ciao ...Jochen -- 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
Re: clojure-mini kanren implementation of nonvar
On Thu, Nov 4, 2010 at 11:36 PM, Sunil S Nandihalli < sunil.nandiha...@gmail.com> wrote: > Hello everybody, > I know that mini-kanren does not have "nonvar" I was trying to emulate its > effect by using > > (cond-u > ((& x :unassigned) >fail) > (succeed)) > > The idea is if x is not assigned it would successfully unify with > :unassigned (ofcourse I am assuming that none of the valid values can be > :unassigned ). So since I am using cond-u it would commit to the first > clause in which the first predicate would succeed and the next predicate > always fails hence it would fail.. > > (run q > (exist [x] > (& x 10) > (cond-u > ((& x :unassigned) > fail) > (succeed)) > (& q 20))) > > I tried the above code it is not having the expected behaviour .. Can > somebody help me with this ..? > Thanks, > Sunil > What is the output that you are seeing? 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
Re: bit manipulation and java arrays
Hi, On 5 Nov., 13:04, Jochen wrote: > (aset-int (make-array Integer/TYPE 1) 0 0x8000) > > I found that 0x8000 is propagated to a long (other than java which > on 8 character hex literals keeps an int) so I try to cast using (int > 0x8000) as possible in Java but still the error occurs. Any ideas > what I can do here? It sounds as if you use 1.3-alpha-something. The problem is that aset- int is a function. So your int gets boxed again to a Long. Just use aset. It's also a function but is usually inlined, so you pass primitive directly. (aset (make-array Integer/TYPE 1) 0 (int 0x8000)) This should work, although I can't verify at the moment. Sincerely Meikel -- 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
Re: Documentation lacking for ns macro
On Fri, Nov 5, 2010 at 5:51 AM, Rasmus Svensson wrote: > 2010/11/4 Ken Wesson : >> The ns macro seems to be poorly documented as yet. The Namespaces page >> at the main Clojure site does not go into detail about its syntax; > > Yes. The docs related to the ns form are indeed insufficient and need > attention. > > However, have you seen the http://clojure.org/libs page? I think it > will answer *some* of you questions. That page isn't perfect, but it > seems to contain the kind of examples you are looking for. I've seen it, but not especially recently. It's not the obvious place to look for such, I'm afraid. -- 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
Re: Documentation lacking for ns macro
(inc) On Thu, Nov 4, 2010 at 2:41 PM, Ken Wesson wrote: > The ns macro seems to be poorly documented as yet. The Namespaces page > at the main Clojure site does not go into detail about its syntax; > "doc ns" comes closer, with: > > (ns foo.bar >(:refer-clojure :exclude [ancestors printf]) >(:require (clojure.contrib sql sql.tests)) >(:use (my.lib this that)) >(:import (java.util Date Timer Random) > (java.sql Connection Statement))) > > given as an example. But what exactly, for instance, is the use clause > really supposed to look like? Is that a list of libraries starting > with my.lib, for example, or is it a single lib and a list of symbols? > The accompanying text only suggests looking at the use function's > documentation. But using "doc use" gives: > > clojure.core/use > ([& args]) > Like 'require, but also refers to each lib's namespace using > clojure.core/refer. Use :use in the ns macro in preference to calling > this directly. > > 'use accepts additional options in libspecs: :exclude, :only, :rename. > The arguments and semantics for :exclude, :only, and :rename are the same > as those documented for clojure.core/refer. > > Yeah, that's a real help if you're trying to remember the syntax. "& > args". How specific. :) > > I think this is one area that could definitely use improvement, > including a couple of actual examples of usage on the Namespaces page > and a better description of the arglist for the use function (and > ditto require) as well as a better :use example in "doc ns". The model > here should be the example :import clause above, which is perfect -- > it's clear that it should be followed by lists that start with a > package and continue with classnames from that package. By contrast, > it's not clear from all of this exactly how to use :use and :require. > Studying (or copying and modifying) example code from elsewhere seems > to be the way to do it and I think it's suboptimal when that's the > ONLY way. > > -- > 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 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
swank-clojure and clojure 1.3
Dear all, Currently swank-clojure SNAPSHOT does not show the stack, nor the exception, on some uncaught exception. Is it something I can do to inspect the errors? Best, Nicolas. -- 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
Re: Python is way faster than Clojure on this task
I don't know how to check the GC activity on my project, but I did run Mian on Jython. It performs much like my initial Clojure version. It consumes absurd amounts of memory and never finishes. So I think we can safely say that Java's GC or the way it stores data is less efficient on this type of problem than Python. On Nov 4, 10:43 pm, Mike Meyer wrote: > On Thu, 4 Nov 2010 22:28:12 +0100 > Pepijn de Vos wrote: > > > Hi all, > > > I have written a Python script to analyze Minecraft levels and render a > > graph. Then I did the same with Clojure. It takes Python 10 seconds to > > analyze a map, while it takes Clojure over a minute. > > > After having tried different options without any significant improvement, I > > am lost as to why there is such a huge difference. I wouldn't mind an extra > > pair of eyes/brains to look at this. > > > I blogged about it in more detail > > here:http://pepijndevos.nl/clojure-versus-python > > Clojure version:https://github.com/pepijndevos/Clomian/ > > Python version:https://github.com/l0b0/mian > > > Clojure spends most of its time in the freqs function, here are a couple of > > variations:https://gist.github.com/663096 > > > If you want to run the code yourself, you'll need a Minecraft level and > > JNBT, which is not on Maven. > > JNBT:http://jnbt.sourceforge.net/ > > The level used in the blogpost:http://dl.dropbox.com/u/10094764/World2.zip > > Can you check GC activity in the clojure version? > > I once ran into an issue where Python was running rings around an > Eiffel version (compiled down to native code - no VM need apply). This > looks similar to what you have, in that I built a large data > structure, and then started groveling over it. Turned out that Eiffel > was doing a mark-and-sweep GC, which was spending all of it's time > marking and sweeping the large static data structure, whereas python > doing a reference count GC didn't. Given that I know nothing about > Java GCs, this is just a WAG. > > Come to think of it, how about trying to run the program Jython? That > should have the same GC issues. If it's some similar environmental > problem, that would show up there as well. > > -- > Mike Meyer http://www.mired.org/consulting.html > Independent Network/Unix/Perforce consultant, email for more information. > > O< ascii ribbon campaign - stop html mail -www.asciiribbon.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
Re: bit manipulation and java arrays
Hi Mikel... Thanks for your quick reply! I use 1.2.0. aset does not work. It seems that aset is only useable for arrays of Reference types, but I need to use primitive types, so aset-int is the only option. To me it looks that there should be unchecked-xxx versions of the coerce functions (e.g. unchecked-int) for this case?!? Ciao ...Jochen > It sounds as if you use 1.3-alpha-something. The problem is that aset- > int is a function. So your int gets boxed again to a Long. Just use > aset. It's also a function but is usually inlined, so you pass > primitive directly. > > (aset (make-array Integer/TYPE 1) 0 (int 0x8000)) > > This should work, although I can't verify at the moment. > > Sincerely > Meikel -- 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
Re: Python is way faster than Clojure on this task
Can you recommend any? I tied a few of the GC options, but that didn't help much. On Nov 4, 10:52 pm, Andrew Gwozdziewycz wrote: > On Thu, Nov 4, 2010 at 5:43 PM, Mike Meyer > > > > > > > > > > wrote: > > On Thu, 4 Nov 2010 22:28:12 +0100 > > Pepijn de Vos wrote: > > >> Hi all, > > >> I have written a Python script to analyze Minecraft levels and render a > >> graph. Then I did the same with Clojure. It takes Python 10 seconds to > >> analyze a map, while it takes Clojure over a minute. > > >> After having tried different options without any significant improvement, > >> I am lost as to why there is such a huge difference. I wouldn't mind an > >> extra pair of eyes/brains to look at this. > > >> I blogged about it in more detail > >> here:http://pepijndevos.nl/clojure-versus-python > >> Clojure version:https://github.com/pepijndevos/Clomian/ > >> Python version:https://github.com/l0b0/mian > > >> Clojure spends most of its time in the freqs function, here are a couple > >> of variations:https://gist.github.com/663096 > > >> If you want to run the code yourself, you'll need a Minecraft level and > >> JNBT, which is not on Maven. > >> JNBT:http://jnbt.sourceforge.net/ > >> The level used in the blogpost:http://dl.dropbox.com/u/10094764/World2.zip > > > Can you check GC activity in the clojure version? > > > I once ran into an issue where Python was running rings around an > > Eiffel version (compiled down to native code - no VM need apply). This > > looks similar to what you have, in that I built a large data > > structure, and then started groveling over it. Turned out that Eiffel > > was doing a mark-and-sweep GC, which was spending all of it's time > > marking and sweeping the large static data structure, whereas python > > doing a reference count GC didn't. Given that I know nothing about > > Java GCs, this is just a WAG. > > > Come to think of it, how about trying to run the program Jython? That > > should have the same GC issues. If it's some similar environmental > > problem, that would show up there as well. > > There are many different collectors for the JVMs, too numerous to list > here, all tunable. > > http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-1401... > > --http://www.apgwoz.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
Re: bit manipulation and java arrays
Hi, On 5 Nov., 15:42, Jochen wrote: > Thanks for your quick reply! > I use 1.2.0. aset does not work. It seems that aset is only useable > for arrays of Reference types, but I need to use primitive types, so > aset-int is the only option. To me it looks that there should be > unchecked-xxx versions of the coerce functions (e.g. unchecked-int) > for this case?!? Ah. Ok. I see the problem now. You actually want a donut. The value is not taken verbatim - wrapping around to a negative number - but promoted to a long. You can exploit the internal representation as a workaround. user=> (printf "%x %x\n" 0x8000 (int (- 0x8000))) 8000 8000 nil user=> (aset (make-array Integer/TYPE 1) 0 (int (- 0x8000))) -2147483648 Sincerely Meikel -- 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
Re: bit manipulation and java arrays
Hi again, On 5 Nov., 16:09, Meikel Brandmeyer wrote: > user=> (aset (make-array Integer/TYPE 1) 0 (int (- 0x8000))) > -2147483648 Of course only a special case. But this works: user=> (aset (make-array Integer/TYPE 1) 0 (.intValue 0x8000)) -2147483648 user=> (aset (make-array Integer/TYPE 1) 0 (.intValue 0x8001)) -2147483647 user=> (aset (make-array Integer/TYPE 1) 0 (.intValue 0xf001)) -268435455 Sincerely Meikel -- 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
Re: Python is way faster than Clojure on this task
On Fri, Nov 5, 2010 at 10:41 AM, pepijn (aka fliebel) wrote: > I don't know how to check the GC activity on my project, but I did run > Mian on Jython. It performs much like my initial Clojure version. It > consumes absurd amounts of memory and never finishes. > > So I think we can safely say that Java's GC or the way it stores data > is less efficient on this type of problem than Python. It's common that iteration heavy, mutation heavy code which is idiomatic in Python poses some challenges when translating to Clojure. Making this run faster than Python should be possible, and I would be surprised if it wasn't quite a bit faster. You should search the Google Group for the various threads on optimizing slow Clojure code. I note that the repo does not contain the data file which your code runs against? 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
Re: bit manipulation and java arrays
Hi... > user=> (aset (make-array Integer/TYPE 1) 0 (int (- 0x8000))) > -2147483648 >user=> (aset (make-array Integer/TYPE 1) 0 (.intValue 0x8000)) >-2147483648 cool, that (both) works! I often forget that in clojure I can drop back to Java any time. Thanks a lot! Ciao ...Jochen -- 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
Re: bit manipulation and java arrays
Hi, On 5 Nov., 16:33, Jochen wrote: > > user=> (aset (make-array Integer/TYPE 1) 0 (int (- 0x8000))) > > -2147483648 > >user=> (aset (make-array Integer/TYPE 1) 0 (.intValue 0x8000)) > >-2147483648 > > cool, that (both) works! I often forget that in clojure I can drop > back to Java any time. But this does not work: (int (- 0xf000)). But the (.intValue ..) version will. Sincerely Meikel -- 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
Re: Documentation lacking for ns macro
On Thu, Nov 4, 2010 at 2:41 PM, Ken Wesson wrote: > > clojure.core/use > ([& args]) > Like 'require, but also refers to each lib's namespace using ... > > Yeah, that's a real help if you're trying to remember the syntax. "& > args". How specific. :) > You stopped one indirection short, try (doc require). It's probably a matter of taste how often the documentation should repeat itself and how often it should refer you to somewhere else. I agree that a couple of more examples would be nice though. -- 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
Re: Documentation lacking for ns macro
On Fri, Nov 5, 2010 at 11:51 AM, Aaron Cohen wrote: > On Thu, Nov 4, 2010 at 2:41 PM, Ken Wesson wrote: >> >> clojure.core/use >> ([& args]) >> Like 'require, but also refers to each lib's namespace using > ... >> >> Yeah, that's a real help if you're trying to remember the syntax. "& >> args". How specific. :) > > You stopped one indirection short, try (doc require). I have an HTL of 1. If I get referred elsewhere a second time I get annoyed. :) -- 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
Re: using swig in clojure
System/loadLibrary uses the paths set in the System property java.library.path to look for dynamic libraries so you need to make sure it contains the directory where your .so is. I think it also gets cached at first read or something stupid like that so it's very important to get java.library.path right before the first time you call System/loadLibrary. The syntax for java.library.path is the same as for classpath (wich is the same as for the OS path env. variable). You also have to make sure not to call System/loadLibrary from the top level of a file unless you are just playing with the repl. You need to call it from inside a function or everything will break if you try to pre compile the code since the library will be linked at compile time only and not at runtime... So to make sure it's linked at runtime, never put System/loadLibrary on the top level. To set java.library.path from the command line use the parameter - Djava.library.path='your stuff here'. To set it from Clojure code: (System/setProperty "java.library.path" "your stuff here") /Markus On Nov 4, 11:42 pm, Seth wrote: > Ive recently had troubles using swig in clojure getting a 'unsatisfied > link exception' even though using the swig generated library worked in > regular java code. I believe there was a post on this somewhere in > these google groups. > > Anyways, I have figured out that if I place the following code in a > clojure file (test.clj) > (System/loadLibrary "Seth") > > and go (compile 'test) on the REPL, i get > > No such file or directory > [Thrown class java.io.IOException] > > Restarts: > 0: [QUIT] Quit to the SLIME top level > > Backtrace: > 0: java.io.UnixFileSystem.createFileExclusively(Native Method) > 1: java.io.File.createNewFile(File.java:900) > 2: clojure.lang.Compiler.writeClassFile(Compiler.java:5885) > 3: clojure.lang.Compiler.compile(Compiler.java:6043) > 4: clojure.lang.RT.compile(RT.java:368) > 5: clojure.lang.RT.load(RT.java:407) > 6: clojure.lang.RT.load(RT.java:381) > 7: clojure.core$load$fn__4511.invoke(core.clj:4905) > 8: clojure.core$load.doInvoke(core.clj:4904) > 9: clojure.lang.RestFn.invoke(RestFn.java:409) > --more-- > > However, afterwards i can succesfully do > (import Seth) > (Seth/add 2 3) => 5 > > I cant do the loadlibrary thing on the repl, or it wont work (i get > the 'unsatisfied link error' when calling (Seth/add)). Notice that if > I do (compile 'test) again i get the same error above, which is > weird because if i do (System/loadLibrary "Seth") on the repl i get > the 'expected' error > > Native Library /home/seth/.random/java/libSeth.so already loaded in > another classloader > [Thrown class java.lang.UnsatisfiedLinkError] > > Restarts: > 0: [QUIT] Quit to the SLIME top level > > Backtrace: > 0: java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1715) > 1: java.lang.ClassLoader.loadLibrary(ClassLoader.java:1675) > 2: java.lang.Runtime.loadLibrary0(Runtime.java:840) > 3: java.lang.System.loadLibrary(System.java:1047) > 4: user$eval1825.invoke(NO_SOURCE_FILE:1) > 5: clojure.lang.Compiler.eval(Compiler.java:5424) > 6: clojure.lang.Compiler.eval(Compiler.java:5391) > 7: clojure.core$eval.invoke(core.clj:2382) > --more-- > > Anyone know whats going on and how this can be fixed? -- 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
Re: compiling a protocol with types
for defining an interface you should use definterface
On Fri, Nov 5, 2010 at 4:18 AM, Jeff Rose wrote:
> Hi,
> I'm trying to define an interface for our automated import system
> written in Clojure so that we can use parsers implemented in Java. So
> far everything works great, but I'm wondering if there is any way to
> get types into the method signatures in the interface. For starters I
> created a simple protocol:
>
> (ns importer.parser)
>
> (defprotocol Parser
> (parse ^java.util.Iterator [this ^java.lang.String path]))
>
> compiled it from the repl:
>
> (compile 'importer.parser)
>
> and then when I decompile it using jd-gui I get this:
>
> package importer.parser;
>
> public abstract interface Parser
> {
> public abstract Object parse(Object paramObject);
> }
>
> It would be nice to have a tool that could inspect a Clojure namespace
> and then generate Javadoc for the protocols and types. Does something
> like this already exist? If that javadoc could specify the types,
> even if under the hood it's using Object, that would also be fine. Is
> there a way to access this type hint information though? I don't see
> it in the importer.Parser map.
>
> Thanks,
> Jeff
>
> --
> 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
--
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?
--
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
Re: From jetty to war?
Steven Arnold wrote .. > On Nov 3, 2010, at 11:43 AM, Sean Corfield wrote: > > > Why are folks so insistent on monolingual systems? > > Business reasons. Two languages means staffing expertise in both languages, either > people who know both and cost more, or two people who cost less. In compsci terms, > it's another dependency, which increases vulnerability. And Clojure and Ruby > are > quite different in syntax, features and general attitude about the world. Finally, > while Clojure is great, it is not accepted enough yet to be able to easily > find > people who know it, who are good, and who are available. (All up-and-coming languages > have to deal with this. The solution is to be dramatically better at solving certain > problems, aka having a killer app. Ruby's killer app was/is Rails. When you > are > 10x more efficient at solving a problem, the bean counters wake up.) Having expert people mastering several tools in any project increases the like hood of being on time and within budget. The "blue collar" approach where one person knows only one thing and were you try to build "teams" to create software does not work within the scheduled time and budgets. We see this here everyday here, we have government driven projects following a Taylor style approach to software projects and they never get anything done on time and on budget. They do not even approach their target ROI by a significant factor. Private businesses do not go very far on this track given that their resources are limited but they have their own significant rate of failures. I drove a business creating custom software components for several customers in different markets for 7 years and we were 4 times faster than our customer's staff. We mastered multiple languages and frameworks and we were not dividing responsibilities between a bunch of individuals according to these artificial barriers. We were not afraid of putting forward creative solutions to their specific needs for the same reasons. Using a single hammer to solve any given problems is an error. You are better with a swiss knife. The super all purpose hammer maybe on its way but its not there yet Luc P. -- 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
Re: Python is way faster than Clojure on this task
I will have a look around. I listed the map I used in my first email, It's on my Dropbox: http://dl.dropbox.com/u/10094764/World2.zip Meanwhile I wrote a function that is already twice as fast as I had, no memory problems, no threads. One tinny problem: it doesn't produce the same result. It's the one at the top: https://gist.github.com/663096 The other day I found out that this kind of logic will actually refer to the same same transient. This eliminates the remainder and associng in the areduce fn second in the list, but I'm not sure this is reliable, and it might be the reason why some results get lost. On Nov 5, 4:24 pm, David Nolen wrote: > On Fri, Nov 5, 2010 at 10:41 AM, pepijn (aka fliebel) > > wrote: > > I don't know how to check the GC activity on my project, but I did run > > Mian on Jython. It performs much like my initial Clojure version. It > > consumes absurd amounts of memory and never finishes. > > > So I think we can safely say that Java's GC or the way it stores data > > is less efficient on this type of problem than Python. > > It's common that iteration heavy, mutation heavy code which is idiomatic in > Python poses some challenges when translating to Clojure. Making this run > faster than Python should be possible, and I would be surprised if it wasn't > quite a bit faster. You should search the Google Group for the various > threads on optimizing slow Clojure code. > > I note that the repo does not contain the data file which your code runs > against? > > 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
Re: compiling a protocol with types
I thought there was some minor magic to get types in there though, wasn't
that one of the interesting things Rich pointed out at a recent NYC Clojure
meetup (Sept, maybe)?
Dave
On Nov 5, 2010 10:59 AM, "Kevin Downey" wrote:
> for defining an interface you should use definterface
>
> On Fri, Nov 5, 2010 at 4:18 AM, Jeff Rose wrote:
>> Hi,
>> I'm trying to define an interface for our automated import system
>> written in Clojure so that we can use parsers implemented in Java. So
>> far everything works great, but I'm wondering if there is any way to
>> get types into the method signatures in the interface. For starters I
>> created a simple protocol:
>>
>> (ns importer.parser)
>>
>> (defprotocol Parser
>>(parse ^java.util.Iterator [this ^java.lang.String path]))
>>
>> compiled it from the repl:
>>
>> (compile 'importer.parser)
>>
>> and then when I decompile it using jd-gui I get this:
>>
>> package importer.parser;
>>
>> public abstract interface Parser
>> {
>>public abstract Object parse(Object paramObject);
>> }
>>
>> It would be nice to have a tool that could inspect a Clojure namespace
>> and then generate Javadoc for the protocols and types. Does something
>> like this already exist? If that javadoc could specify the types,
>> even if under the hood it's using Object, that would also be fine. Is
>> there a way to access this type hint information though? I don't see
>> it in the importer.Parser map.
>>
>> Thanks,
>> Jeff
>>
>> --
>> 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
>
>
>
> --
> And what is good, Phaedrus,
> And what is not good—
> Need we ask anyone to tell us these things?
>
> --
> 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 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
Re: From jetty to war?
On Nov 5, 2010, at 10:20 AM, lprefonta...@softaddicts.ca wrote: > Having expert people mastering several tools in any project increases the like > hood of being on time and within budget. I agree partially. Given unlimited resources, it would be great for all the people on the project to have a mastery of all the tools used in the project. But resources are never unlimited, and therefore compromise is always necessary. I bet your organization was a small, focused team of experts -- a sharp tool for specific jobs -- not a large consulting organization with hundreds of employees and dozens of major projects. The primary point I was making was that each new technology introduces overhead in development, maintenance and operations. Therefore it should be included only if the benefit is compelling when compared to the change in costs associated with a team who can develop, maintain and operate a system that uses the technology. If a team like yours introduces a new technology, eventually the customer will have to maintain and operate it without your staff of top-notch experts to hold their hands. And I guess you guys weren't cheap in the first place. As they say, fast delivery, low cost, high quality -- pick any two. You were high quality and fast delivery. As far as failed projects go, in my experience, most failed projects fail not because the team is not good enough to deliver -- although this is possible -- but because of poor project leadership, poor executive support, requirements that shift too much, or disinterested or distant customers. These are essentially business reasons, not technical reasons. steven -- 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
Re: Python is way faster than Clojure on this task
On Fri, Nov 5, 2010 at 17:38, pepijn (aka fliebel)
wrote:
> I will have a look around.
>
> I listed the map I used in my first email, It's on my Dropbox:
> http://dl.dropbox.com/u/10094764/World2.zip
>
> Meanwhile I wrote a function that is already twice as fast as I had,
> no memory problems, no threads. One tinny problem: it doesn't produce
> the same result.
>
> It's the one at the top: https://gist.github.com/663096
>
> The other day I found out that this kind of logic will actually refer
> to the same same transient. This eliminates the remainder and associng
> in the areduce fn second in the list, but I'm not sure this is
> reliable, and it might be the reason why some results get lost.
(defn freqs [^bytes blocks]
(loop [idx 0
ret (cycle (repeatedly 128 #(transient {})))]
(if (< idx (alength blocks))
(do
(update! (first ret) (aget blocks idx) (fnil inc 0))
(recur (inc idx) (next ret)))
(map persistent! (take 128 ret)
I'm not familiar with incanter, which defines update!, but the update!
call makes me suspicious. Transients are not designed to be banged on
in place. That would explain your losing results.
// ben
--
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
Re: Python is way faster than Clojure on this task
I'm very curios about this situation, please let us know if you manage to write a version that's faster than the python one (as David claims is possible). I would attempt it myself but I've only just recently had the time to dive back into Clojure. :-\ - Greg On Nov 5, 2010, at 9:38 AM, pepijn (aka fliebel) wrote: > I will have a look around. > > I listed the map I used in my first email, It's on my Dropbox: > http://dl.dropbox.com/u/10094764/World2.zip > > Meanwhile I wrote a function that is already twice as fast as I had, > no memory problems, no threads. One tinny problem: it doesn't produce > the same result. > > It's the one at the top: https://gist.github.com/663096 > > The other day I found out that this kind of logic will actually refer > to the same same transient. This eliminates the remainder and associng > in the areduce fn second in the list, but I'm not sure this is > reliable, and it might be the reason why some results get lost. > > On Nov 5, 4:24 pm, David Nolen wrote: >> On Fri, Nov 5, 2010 at 10:41 AM, pepijn (aka fliebel) > >>> wrote: >>> I don't know how to check the GC activity on my project, but I did run >>> Mian on Jython. It performs much like my initial Clojure version. It >>> consumes absurd amounts of memory and never finishes. >> >>> So I think we can safely say that Java's GC or the way it stores data >>> is less efficient on this type of problem than Python. >> >> It's common that iteration heavy, mutation heavy code which is idiomatic in >> Python poses some challenges when translating to Clojure. Making this run >> faster than Python should be possible, and I would be surprised if it wasn't >> quite a bit faster. You should search the Google Group for the various >> threads on optimizing slow Clojure code. >> >> I note that the repo does not contain the data file which your code runs >> against? >> >> 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 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
Re: Python is way faster than Clojure on this task
On Fri, Nov 5, 2010 at 2:31 PM, Greg wrote: > I'm very curios about this situation, please let us know if you manage to > write a version that's faster than the python one (as David claims is > possible). I would attempt it myself but I've only just recently had the > time to dive back into Clojure. :-\ > > - Greg I'm almost 100% certain it's possible. But having already optimized other people's code several times on this list as a learning experiment, I've become bored with optimizing other people's code ;) 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
Re: From jetty to war?
Steven Arnold wrote .. > > On Nov 5, 2010, at 10:20 AM, lprefonta...@softaddicts.ca wrote: > > > Having expert people mastering several tools in any project increases the > > like > > hood of being on time and within budget. > > I agree partially. Given unlimited resources, it would be great for all the people > on the project to have a mastery of all the tools used in the project. But resources > are never unlimited, and therefore compromise is always necessary. I bet your > organization was a small, focused team of experts -- a sharp tool for specific > jobs -- not a large consulting organization with hundreds of employees and > dozens > of major projects. That's why the large consulting organizations typically fail... I could give you around 2 billion$ worth of failed projects in the last 5 years driven by the big consulting firms here without having to dig very deep. I am not talking about the success of these big organizations (bill until the customer budgets are exhausted). I am talking about the success of the projects themselves. I can assure you than up here these large organizations are healthy. Not true about their customers budgets... but that's their business model. > > The primary point I was making was that each new technology introduces > overhead > in development, maintenance and operations. Therefore it should be included > only > if the benefit is compelling when compared to the change in costs associated > with > a team who can develop, maintain and operate a system that uses the > technology. Exactly what I have been saying earlier in this thread. Pick the proper tool... if a project was developed faster with it then guess what, the maintenance cost will be following the same trend. > If a team like yours introduces a new technology, eventually the customer will > have to maintain and operate it without your staff of top-notch experts to > hold > their hands. And I guess you guys weren't cheap in the first place. As they > say, > fast delivery, low cost, high quality -- pick any two. You were high quality > and > fast delivery. Yep but we were not either cheap or charging high fees. We used to sell fixed cost projects. Real fixed cost, not the "let's go in at cost + 3% and then lets make our bread and butter on change requests". And we were not trying to pull the customer out of is comfort bubble technology wise. However we were proposing original designs with the then trendy technologies that our customers embraced at the time. We knew more about their business and the software tool they used than their employees. That's what I call being a consultant, bringing some expertise and real solutions to the table, not just merely occupying a seat. > > As far as failed projects go, in my experience, most failed projects fail not because > the team is not good enough to deliver -- although this is possible -- but > because > of poor project leadership, poor executive support, requirements that shift > too > much, or disinterested or distant customers. These are essentially business reasons, > not technical reasons. These are valid reasons.. after the failure. The early detectable reason why projects are doomed to fail is that many projects are huge in scope and timeline and are not sliced to deliver some ROI fast enough. Customers are not getting usable components delivered in the near future. They just get vague promises that something will be delivered in x years. Nothing tangible there just vapor ware. And by the way can you pay me now since we completed 30% of the analysis... you can guess what is the ROI of such a delivery mile stone, it's worth about as much as toilet paper in terms of ROI. Given the pace of technology, user expectations, ... we should aim at short development cycles. Exactly the opposite of what occurs in these huge projects. We worked on projects worth more than 1 million dollars on several occasions but we never submitted proposals to bite the bullet at once. We focused on ROI milestones ... for the customer's sake. Luc > > steven > > -- > 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 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
Re: Python is way faster than Clojure on this task
update! is of my own making, based on assoc! and update-in
On Nov 5, 7:30 pm, B Smith-Mannschott wrote:
> On Fri, Nov 5, 2010 at 17:38, pepijn (aka fliebel)
>
>
>
>
>
>
>
>
>
> wrote:
> > I will have a look around.
>
> > I listed the map I used in my first email, It's on my Dropbox:
> >http://dl.dropbox.com/u/10094764/World2.zip
>
> > Meanwhile I wrote a function that is already twice as fast as I had,
> > no memory problems, no threads. One tinny problem: it doesn't produce
> > the same result.
>
> > It's the one at the top:https://gist.github.com/663096
>
> > The other day I found out that this kind of logic will actually refer
> > to the same same transient. This eliminates the remainder and associng
> > in the areduce fn second in the list, but I'm not sure this is
> > reliable, and it might be the reason why some results get lost.
>
> (defn freqs [^bytes blocks]
> (loop [idx 0
> ret (cycle (repeatedly 128 #(transient {})))]
> (if (< idx (alength blocks))
> (do
> (update! (first ret) (aget blocks idx) (fnil inc 0))
> (recur (inc idx) (next ret)))
> (map persistent! (take 128 ret)
>
> I'm not familiar with incanter, which defines update!, but the update!
> call makes me suspicious. Transients are not designed to be banged on
> in place. That would explain your losing results.
>
> // ben
--
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
Re: From jetty to war?
On Fri, Nov 5, 2010 at 2:42 PM, wrote: > Customers are not getting usable components delivered in the near future. > They just get vague promises that something will be delivered in x years. > Nothing tangible there just vapor ware. That's more than Half-Life fans are getting from Valve -- they won't even give a "vague promise that something will be delivered in x years"! -- 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
Re: From jetty to war?
Ken Wesson wrote .. > On Fri, Nov 5, 2010 at 2:42 PM, wrote: > > Customers are not getting usable components delivered in the near future. > > They just get vague promises that something will be delivered in x years. > > Nothing tangible there just vapor ware. > > That's more than Half-Life fans are getting from Valve -- they won't > even give a "vague promise that something will be delivered in x > years"! > Agree but each user did not have to pay 10,000$ each BEFORE the first alpha release :))) oups ! Luc P. > -- > 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 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
Re: From jetty to war?
On Wed, Nov 3, 2010 at 20:51, Mike Meyer < mwm-keyword-googlegroups.620...@mired.org> wrote: > > Finding good people is hard enough that wanting them to be good in > three or four languages is enough to break the camels back. If you've > got time to cross-train them - then you don't need > > I've regularly found that the multi-disciplinarian programmer is far more adept at solving issues in a creative manner than the "I've a skilled hammer and I'll wield it in the direction of any nail"-mono-linguistic programmer. Perhaps that is just an artifact of working in startups though. -- 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
Re: Python is way faster than Clojure on this task
Could you refer me to some of those relevant to my problem? I tried searching for them, and most stuff I found is about killing reflection, using buffered IO and other basics I've already covered. On Nov 5, 7:37 pm, David Nolen wrote: > On Fri, Nov 5, 2010 at 2:31 PM, Greg wrote: > > I'm very curios about this situation, please let us know if you manage to > > write a version that's faster than the python one (as David claims is > > possible). I would attempt it myself but I've only just recently had the > > time to dive back into Clojure. :-\ > > > - Greg > > I'm almost 100% certain it's possible. But having already optimized other > people's code several times on this list as a learning experiment, I've > become bored with optimizing other people's code ;) > > 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
dynamic bindability (Re: Clojure 1.3 Alpha 2)
On Oct 25, 2010, at 3:44 PM, Stuart Halloway wrote: > * code path for using vars is now *much* faster for the common case, > and you must explicitly ask for :dynamic bindability This has been bouncing around in my head for the last week or so, occasionally colliding with the memory of Rich Hickey showing dynamic rebinding of vars during a run (in a video, maybe on the ant simulation?) and saying something like "It's a dynamic language!" (apparently with approval). I understand how this can be a big win on performance and I guess it's a minor sacrifice since one will still be able ask for dynamic bindability with only a little more clutter. But it leads me to ask whether it would be possible to simultaneously provide a way to load libraries (e.g. in require or :require clauses of ns) while specifying that certain vars in the library are to be defined as dynamically bindable, even if they're not coded as such within the library. The reason I ask is that I often create a library and then want to use it in a context in which I want one of the library's internal subfunctions to be defined differently. So I load the library and then redefine the subfunction's var (sandwiched between calls to ns, so I'm redefining the var in the right namespace). [Perhaps this is not a recommended way to do things? In any event I find it useful... Is there a better way that's not a lot more work?] Anyway, I don't know ahead of time, when I write the library, which particular vars I might want to redefine for any particular application/experiment. But I'd rather not change the library's code between experiments; I'd like that to be frozen and constant (and I use the exact same file for many experiments). So if I wanted to make this work in all possible use cases I'd have to designate *all* of my vars as dynamically, but then: A) I'd have to clutter all of my vars with :dynamic specifications and, 2) I'd lose the optimizations that this new feature of 1.3 alpha 2 are providing (which sound worthwhile, being "*much* faster"). It would be nicer if I could define everything in the library in the normal way, and have everything loaded as not-dynamically-bindable in the usual case, but if I could say in a particular application file that loads the library something like: (ns foo (:require [bar :dynamic baz bingo])) Or something to that effect -- I don't know if this exact syntax is consistent with the various options in an ns/require form. The idea is that this would load bar but with the definitions of baz and bingo marked as dynamically bindable, even though the code in bar.clj doesn't ask for dynamic bindability. Possible? Desirable? Thanks! -Lee -- 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
Re: From jetty to war?
On Nov 5, 2010, at 12:42 PM, lprefonta...@softaddicts.ca wrote: > That's why the large consulting organizations typically fail... I agree with most of your points. So let me address the one point which was the original subject of the thread... >> The primary point I was making was that each new technology introduces >> overhead >> in development, maintenance and operations. Therefore it should be included >> only >> if the benefit is compelling when compared to the change in costs associated >> with >> a team who can develop, maintain and operate a system that uses the >> technology. > > Exactly what I have been saying earlier in this thread. Pick the proper > tool... > if a project was developed faster with it then guess what, the maintenance > cost > will be following the same trend. I once had a very senior database developer take a set of requirements and deliver to me a solution that used a specialized database framework called Queues. Work was prepared, placed on the queue in the database, and a client later took the work off the queue and performed it. It took a few weeks to deliver the solution. It did everything it was supposed to do. But then the need changed slightly. We needed to resumbit work sometimes, or a portion of the work. We needed some work to be more important than other work. We wanted to tune the submission of work so we didn't pile up on a resource that was obviously not functional (e.g. a server that was straining or completely down). It turned out that for many reasons, the Queues framework was simply not designed to handle these variations on our original problem. After spending a lot of money and time trying to force the solution to work, we ended up throwing the whole thing away and using a simple table to store our work. Queues caused the product to be delivered perhaps 50% faster. But maintaining the product was a nightmare. Our database developer was a very senior resource. He had spent his entire career mastering the toolsets he used to deliver the product I asked from him. But it took all the cleverness of this senior resource to create a solution. The rest of my team were not as versed in that database platform and its frameworks as this developer. We did not have enough cleverness on the team to maintain the very clever tool he had created. This is why the proliferation of toolsets, including languages and major frameworks, is at best a necessary evil. Additional technologies add overhead and they add risk. This is why people want to keep the technology stack short and sweet. This is why speed of development does not trump everything else, and why speed of delivery is not a perfect corollary to ease of maintenance or operation. steven -- 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
Re: From jetty to war?
On Fri, Nov 5, 2010 at 12:41 PM, Michael Ossareh wrote: > I've regularly found that the multi-disciplinarian programmer is far more > adept at solving issues in a creative manner than the "I've a skilled hammer > and I'll wield it in the direction of any nail"-mono-linguistic programmer. > Perhaps that is just an artifact of working in startups though. Possibly. I've worked in a variety of organizations from small startups to large corporations (such as insurance companies). In the smaller companies, developers have to wear more hats and it's common for a web developer to know HTML, JavaScript, SQL, **insert scripting language** and often shell scripts and / or other tools to help automate tasks. I don't see much difference between that and **insert multiple languages**. My exposure to the Agile world also leads me to believe they favor multi-disciplinary developers for productivity - and they certainly favor small teams of more experienced / expert programmers over large teams of less capable programmers. They also seem to be suspicious of frameworks because the more a framework seems to do for you, the less Agile it is likely to be if your requirements change (Steven's post about the Queues framework reinforces this argument). Interesting to see different people's opinions here - and to know that I'm not alone in my thinking (although I may well be in the minority). -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- 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
Re: dynamic bindability (Re: Clojure 1.3 Alpha 2)
Hello Lee, 2010/11/5 Lee Spector : > > On Oct 25, 2010, at 3:44 PM, Stuart Halloway wrote: >> * code path for using vars is now *much* faster for the common case, >> and you must explicitly ask for :dynamic bindability > > This has been bouncing around in my head for the last week or so, > occasionally colliding with the memory of Rich Hickey showing dynamic > rebinding of vars during a run (in a video, maybe on the ant simulation?) and > saying something like "It's a dynamic language!" (apparently with approval). > > I understand how this can be a big win on performance and I guess it's a > minor sacrifice since one will still be able ask for dynamic bindability with > only a little more clutter. > > But it leads me to ask whether it would be possible to simultaneously provide > a way to load libraries (e.g. in require or :require clauses of ns) while > specifying that certain vars in the library are to be defined as dynamically > bindable, even if they're not coded as such within the library. > > The reason I ask is that I often create a library and then want to use it in > a context in which I want one of the library's internal subfunctions to be > defined differently. So I load the library and then redefine the > subfunction's var (sandwiched between calls to ns, so I'm redefining the var > in the right namespace). [Perhaps this is not a recommended way to do > things? In any event I find it useful... Is there a better way that's not a > lot more work?] If I understand well, you are re-def'ing the var. If so, then no problem, because you have mistaken "redefinition of a var" for "dynamic rebinding of a var". redefinition of a var will still be possible for non dynamically rebindable vars. (or we could then just stop to work on the REPL with Chas !) > > Anyway, I don't know ahead of time, when I write the library, which > particular vars I might want to redefine for any particular > application/experiment. But I'd rather not change the library's code between > experiments; I'd like that to be frozen and constant (and I use the exact > same file for many experiments). So if I wanted to make this work in all > possible use cases I'd have to designate *all* of my vars as dynamically, but > then: A) I'd have to clutter all of my vars with :dynamic specifications and, > 2) I'd lose the optimizations that this new feature of 1.3 alpha 2 are > providing (which sound worthwhile, being "*much* faster"). It would be nicer > if I could define everything in the library in the normal way, and have > everything loaded as not-dynamically-bindable in the usual case, but if I > could say in a particular application file that loads the library something > like: > > (ns foo > (:require [bar :dynamic baz bingo])) > > Or something to that effect -- I don't know if this exact syntax is > consistent with the various options in an ns/require form. > > The idea is that this would load bar but with the definitions of baz and > bingo marked as dynamically bindable, even though the code in bar.clj doesn't > ask for dynamic bindability. > > Possible? Desirable? > > Thanks! > > -Lee > > -- > 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 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
Re: Python is way faster than Clojure on this task
You can use Visual VM (https://visualvm.dev.java.net/) to see how the VM is using memory. I don't think it specifically show a log of GC activity, but it is pretty clear from the graphs. mch On Nov 5, 8:41 am, "pepijn (aka fliebel)" wrote: > I don't know how to check the GC activity on my project, but I did run > Mian on Jython. It performs much like my initial Clojure version. It > consumes absurd amounts of memory and never finishes. > > So I think we can safely say that Java's GC or the way it stores data > is less efficient on this type of problem than Python. > > On Nov 4, 10:43 pm, Mike Meyer > > > > > > > 620...@mired.org> wrote: > > On Thu, 4 Nov 2010 22:28:12 +0100 > > Pepijn de Vos wrote: > > > > Hi all, > > > > I have written a Python script to analyze Minecraft levels and render a > > > graph. Then I did the same with Clojure. It takes Python 10 seconds to > > > analyze a map, while it takes Clojure over a minute. > > > > After having tried different options without any significant improvement, > > > I am lost as to why there is such a huge difference. I wouldn't mind an > > > extra pair of eyes/brains to look at this. > > > > I blogged about it in more detail > > > here:http://pepijndevos.nl/clojure-versus-python > > > Clojure version:https://github.com/pepijndevos/Clomian/ > > > Python version:https://github.com/l0b0/mian > > > > Clojure spends most of its time in the freqs function, here are a couple > > > of variations:https://gist.github.com/663096 > > > > If you want to run the code yourself, you'll need a Minecraft level and > > > JNBT, which is not on Maven. > > > JNBT:http://jnbt.sourceforge.net/ > > > The level used in the blogpost:http://dl.dropbox.com/u/10094764/World2.zip > > > Can you check GC activity in the clojure version? > > > I once ran into an issue where Python was running rings around an > > Eiffel version (compiled down to native code - no VM need apply). This > > looks similar to what you have, in that I built a large data > > structure, and then started groveling over it. Turned out that Eiffel > > was doing a mark-and-sweep GC, which was spending all of it's time > > marking and sweeping the large static data structure, whereas python > > doing a reference count GC didn't. Given that I know nothing about > > Java GCs, this is just a WAG. > > > Come to think of it, how about trying to run the program Jython? That > > should have the same GC issues. If it's some similar environmental > > problem, that would show up there as well. > > > > -- > > Mike Meyer http://www.mired.org/consulting.html > > Independent Network/Unix/Perforce consultant, email for more information. > > > O< ascii ribbon campaign - stop html mail -www.asciiribbon.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
Clojure Box Windows XP
I have installed twice, restarted my machine to make sure all is well. However, the Emacs Client window shows: "Waiting for Emacs server to start" and yet the SLIME REPL buffer appears to be functional and various messages like: "Connected Your hacking starts now!" show up in the status. Eventually the Emacs Client window shows: "ERROR Timeout waiting for server". What can I look at to debug this? I tried guessing at ports and processes using netstat -ao | grep'ing for process ids... nothing real popped up. I am using Clojure box 1.2.0 on Windows XP Service Pack 3. -- 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
Re: dynamic bindability (Re: Clojure 1.3 Alpha 2)
On Nov 5, 2010, at 4:43 PM, Laurent PETIT wrote: > > If I understand well, you are re-def'ing the var. If so, then no > problem, because you have mistaken "redefinition of a var" for > "dynamic rebinding of a var". > > redefinition of a var will still be possible for non dynamically > rebindable vars. (or we could then just stop to work on the REPL with > Chas !) Ah -- beautiful. I completely misunderstood and was "borrowing worries," as we say in my family. Maybe it's from my time in the Lisp/Scheme world, where "binding" in used more broadly (I think!). Thanks so much! -Lee -- 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
Re: From jetty to war?
On Fri, 5 Nov 2010 13:42:44 -0700 Sean Corfield wrote: > On Fri, Nov 5, 2010 at 12:41 PM, Michael Ossareh wrote: > > I've regularly found that the multi-disciplinarian programmer is far more > > adept at solving issues in a creative manner than the "I've a skilled hammer > > and I'll wield it in the direction of any nail"-mono-linguistic programmer. > > Perhaps that is just an artifact of working in startups though. > > Possibly. His comment is generally true, at least so long as the languages are really different. The obvious solution in one language may be non-obvious in a second, but have advantages over the obvious solution in the second language. A programmer skilled in both languages is more likely to see that "creative" solution than one who only knows the second language. > I've worked in a variety of organizations from small > startups to large corporations (such as insurance companies). In the > smaller companies, developers have to wear more hats and it's common > for a web developer to know HTML, JavaScript, SQL, **insert scripting > language** and often shell scripts and / or other tools to help > automate tasks. I don't see much difference between that and **insert > multiple languages**. This affect only works if the languages are sufficiently different to have different "obvious" solutions for a large number of problems. This is why people recommend learning a LISP even if you'll never use it - it will expand the way you look at problems. In your case, you have a markup language instead of a programming language, a database language, and a handful of scripting languages. Depending on the scripting languages, that's more like an expert in C++, C# and Java - basically three iterations of the same language - than an expert in (for example) C, Python, and Scheme. When it comes to multi-language projects, if you project is all Python, then someone who knows C/Python/Scheme and someone who knows Java/Python/Clojure are probably equivalent candidates. If your project is Java/Python, then the second one would be a good fit, and the first somewhat questionable (at the very least, they'll need time to come up to speed on Java). So even if you restrict yourself to multilingual programmers, multiple implementation languages cuts down on the pool of qualified people. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.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
Re: From jetty to war?
On Fri, Nov 5, 2010 at 3:20 PM, wrote: > Ken Wesson wrote .. >> On Fri, Nov 5, 2010 at 2:42 PM, wrote: >> > Customers are not getting usable components delivered in the near future. >> > They just get vague promises that something will be delivered in x years. >> > Nothing tangible there just vapor ware. >> >> That's more than Half-Life fans are getting from Valve -- they won't >> even give a "vague promise that something will be delivered in x >> years"! > > Agree but each user did not have to pay 10,000$ each > BEFORE the first alpha release :))) That much is true. That's probably what saves Valve from the end of a lynch mob's rope. :) -- 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
Re: Python is way faster than Clojure on this task
I think you missed his point. (assoc! m k v) is *allowed* to modify m,
not *guaranteed*. It returns a pointer to a transient map, which may
be m, or may be a totally distinct map, or may be a new map that
shares some pointers with m. So your (do (update! blah foo
bar) ...more stuff) is potentially (and unpredictably) throwing away
the results of the update. You need to save the return value.
On Nov 5, 11:48 am, "pepijn (aka fliebel)"
wrote:
> update! is of my own making, based on assoc! and update-in
>
> On Nov 5, 7:30 pm, B Smith-Mannschott wrote:
>
> > On Fri, Nov 5, 2010 at 17:38, pepijn (aka fliebel)
>
> > wrote:
> > > I will have a look around.
>
> > > I listed the map I used in my first email, It's on my Dropbox:
> > >http://dl.dropbox.com/u/10094764/World2.zip
>
> > > Meanwhile I wrote a function that is already twice as fast as I had,
> > > no memory problems, no threads. One tinny problem: it doesn't produce
> > > the same result.
>
> > > It's the one at the top:https://gist.github.com/663096
>
> > > The other day I found out that this kind of logic will actually refer
> > > to the same same transient. This eliminates the remainder and associng
> > > in the areduce fn second in the list, but I'm not sure this is
> > > reliable, and it might be the reason why some results get lost.
>
> > (defn freqs [^bytes blocks]
> > (loop [idx 0
> > ret (cycle (repeatedly 128 #(transient {})))]
> > (if (< idx (alength blocks))
> > (do
> > (update! (first ret) (aget blocks idx) (fnil inc 0))
> > (recur (inc idx) (next ret)))
> > (map persistent! (take 128 ret)
>
> > I'm not familiar with incanter, which defines update!, but the update!
> > call makes me suspicious. Transients are not designed to be banged on
> > in place. That would explain your losing results.
>
> > // ben
>
>
--
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
Lightweight persistence of the ref world
I may need a ref world that could get bigger than main memory can
easily cope with. I was wondering if something like this would work
well:
(defvar- node-cache (ConcurrentHashMap. 128 0.75 128))
(defn- dead-entries-keys []
(doall
(filter identity
(for [entry node-cache]
(let [val (.getValue entry)]
(if (instance? WeakReference val)
(if-not (.get val)
(.getKey entry
(defn- prune-dead-entries []
(doseq [k (dead-entries-keys)]
(.remove node-cache k)))
(defn- undertaker
(loop []
(Thread/sleep 6)
(prune-dead-entries)
(recur)))
(.start (Thread. undertaker))
(defn get-node [node-id base-dir]
(let [dummy (Object.)]
(loop []
(.putIfAbsent node-cache node-id dummy)
(let [val (.get node-cache node-id)]
(if (= val dummy)
; Node not already cached. We own the entry.
(let [noderef (ref @(future load-node node-id base-dir))]
(.put node-cache node-id (WeakReference. noderef))
noderef)
(if-not (instance? val WeakReference)
; Node not already cached. Someone else owns the entry. Wait for the
; node to be loaded.
(do
(Thread/sleep 10)
(recur))
(let [noderef (.get val)]
(if noderef
; Already cached.
noderef
(do
; Dead entry. Prune it.
(.replace node-cache node-id val dummy)
(recur))
(defvar- to-be-saved (ref #{}))
(defn put-node [noderef base-dir]
(dosync
(commute to-be-saved #(conj % [noderef base-dir]
(defn- saver
(loop []
(let [entry (dosync
(let [entry (first @to-be-saved)]
(if entry (commute to-be-saved disj entry))
entry))]
(if entry
(save-node @noderef base-dir)
(Thread/sleep 100)))
(recur)))
Here, the objects subjected to persistence are called "nodes". It's
assumed there's a load-node that can find a node on disk given a
"node-id" for it, which should be a string or other bit of data, and
there's a save-node that will save a node likewise; nodes would have
to carry around their ids. The node could e.g. be an [id object]
vector. There'd need to be a way of making globally unique ids and
other details to work out too.
The basic concept seems sound. The get-node function is the
complicated bit and tries to atomically retrieve a node from the
ConcurrentHashMap if already cached there and load it from disk if
not. The @(future load-node ...) bit is so that get-node can be called
in a transaction without plotzing. The I/O shouldn't get done twice
even if the transaction retries because of how get-node is designed.
The dummy Object marks a cache entry that's under construction with a
market unique to the get-node invocation, so it can tell if a
different get-node invocation beat it to the punch by a smidgen. It
sleeps .01 second and retries until the other invocation has loaded
the node.
Of course to avoid all the nodes accumulating into memory something
has to kill off ones not in use, and that's
java.lang.ref.WeakReference. An undertaker thread sweeps once a minute
through the cache pruning dead entries. Of course get-node may run
into one in which case it tries to prune it and then reruns itself;
the three-parameter replace method is used so that if another get-node
invocation has concurrently already put in a new entry it doesn't
clobber it.
There's also a put-node to signal that a node has changes in need of
persisting. The put-node function schedules nodes for saving using a
private set held in a ref and a transaction. The saver thread checks
every ten seconds for the set to be non-empty and whenever it is it
empties it, calling save-node out-transaction. Both load-node and
save-node are called out-transaction.
The set operations commute; that and ConcurrentHashMap avoids
contention for access to the node cache or the save queue. (Actually
perhaps a LinkedBlockingQueue would be better for the latter?)
If there are any problems likely with this approach I'm all ears.
(I know a straightforward (spit (filename-from-id-and-basedir node))
for save-node has durability problems if e.g. the power goes out in
mid-write. That's an issue for save-node implementation though, not
for the above. Some scheme involving temporary files and .renameTo
ought to do it anyway. It's also incomplete in that it has no function
for creating a new node ex nihilo.)
If this actually works, it adds lightweight persistance to the ref
world almost transparently to users, who just need to package their
ref objects in nodes and extract them again when needed. This likely
just means either adding an :id field to maps, adding an id at the
start of vectors, or adding one more key to their assoc-ins and
update-ins.
--
You received this message because you are subscribed to the
Re: From jetty to war?
On Fri, Nov 5, 2010 at 2:33 PM, Mike Meyer wrote: > This affect only works if the languages are sufficiently different to > have different "obvious" solutions for a large number of problems. > This is why people recommend learning a LISP even if you'll never use > it - it will expand the way you look at problems. True, and why for years I've recommended to the CFML developers I interact with that they should learn languages like Prolog and Haskell rather than Java. Now I have the luxury of recommending they learn Clojure so they can stay within the JVM :) FWIW, my constant tweets and blog posts about Clojure have encouraged a number of them to try Clojure but most of them don't yet see a use case for it (because a lot of their apps are UI intensive and mostly just do CRUD behind the scenes - which CFML is very good at, especially now it has Hibernate ORM built-in). > So even if you restrict yourself to > multilingual programmers, multiple implementation languages cuts down > on the pool of qualified people. True dat... I know a lot of languages but Python is not one of them so I'd be no use for that hypothetical job (and why I was bummed when my former boss at Macromedia went to Linden Labs - because they required developers to know Python and I wasn't qualified to work for her :( -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- 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
Re: Python is way faster than Clojure on this task
Here's what I have so far. The code splits blocks into 128 smaller
sub-arrays, each representing a level, then calls a modified version
of frequencies (using areduce instead of reduce) on each level. On my
machine, with server mode on, it takes about 20 seconds to compute the
frequencies for an array of 99844096 blocks. I haven't tested it on
your level, because I'm too lazy to get JNBT set up, but I'm curious
to see if it returns the correct result for you.
(def num-levels 128)
(defn get-level [level-num ^bytes blocks]
(let [size (/ (count blocks) num-levels)
output (byte-array size)]
(doseq [output-idx (range size)]
(let [block-idx (+ (* output-idx num-levels) level-num)]
(aset output output-idx (aget blocks block-idx
output))
(defn afrequencies
[^bytes a]
(persistent!
(areduce a
idx
counts
(transient {})
(let [x (aget a idx)]
(assoc! counts x (inc (get counts x 0)))
(defn freqs [^bytes blocks]
(let [levels (map #(get-level % blocks) (range num-levels))]
(map afrequencies levels)))
user=> (def blocks (byte-array 99844096))
#'user/blocks
user=> (time (count (freqs blocks)))
"Elapsed time: 20160.780769 msecs"
128
On Nov 4, 3:28 pm, Pepijn de Vos wrote:
> Hi all,
>
> I have written a Python script to analyze Minecraft levels and render a
> graph. Then I did the same with Clojure. It takes Python 10 seconds to
> analyze a map, while it takes Clojure over a minute.
>
> After having tried different options without any significant improvement, I
> am lost as to why there is such a huge difference. I wouldn't mind an extra
> pair of eyes/brains to look at this.
>
> I blogged about it in more detail
> here:http://pepijndevos.nl/clojure-versus-python
> Clojure version:https://github.com/pepijndevos/Clomian/
> Python version:https://github.com/l0b0/mian
>
> Clojure spends most of its time in the freqs function, here are a couple of
> variations:https://gist.github.com/663096
>
> If you want to run the code yourself, you'll need a Minecraft level and JNBT,
> which is not on Maven.
> JNBT:http://jnbt.sourceforge.net/
> The level used in the blogpost:http://dl.dropbox.com/u/10094764/World2.zip
>
> Groeten,
> Pepijn de Vos
> --
> Sent from my iPod Shufflehttp://pepijndevos.nl
--
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
Re: Development vs Production resource files
On Mon, Nov 1, 2010 at 21:09, Sean Corfield wrote: > This Q came up on the Leiningen list but I wanted to share my answer > on the larger Clojure group to get feedback from a bigger pool... > > On Mon, Nov 1, 2010 at 8:40 PM, Shantanu Kumar > wrote: > > There are some resource files (e.g. dbconfig.properties) I need to > > include in code so that they are on the classpath. However, they need > > to vary during dev/testing and production -- I will have different > > versions of dbconfig.properties during dev/testing and production. I > > want to know what is the recommended way to include/specify them so > > that they are on the classpath based on he profile (dev, testing, > > production, staging etc.) I am referring to. > > My solution to this is ghetto in just the right ways for my needs. I have a config.clj that sits next to my uberjar. In my main gen-class clj namespace I (load-file './config.clj'). config.clj has all the configs pertinent to that running config. The not so great part of this is that every time I need to reference a configed parameter I have to @(ns-resolve "config" (symbol "param")). -- 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
Re: Python is way faster than Clojure on this task
Oops, sorry, got my terminology wrong. The sub-arrays represent
*layers*, not levels. So the code should actually read as follows:
(def num-layers 128)
(defn get-layer [layer-num ^bytes blocks]
(let [size (/ (count blocks) num-layers)
output (byte-array size)]
(doseq [output-idx (range size)]
(let [block-idx (+ (* output-idx num-layers) layer-num)]
(aset output output-idx (aget blocks block-idx
output))
(defn afrequencies
[^bytes a]
(persistent!
(areduce a
idx
counts
(transient {})
(let [x (aget a idx)]
(assoc! counts x (inc (get counts x 0)))
(defn freqs [^bytes blocks]
(let [layers (map #(get-layer % blocks) (range num-layers))]
(map afrequencies layers)))
On Nov 5, 4:57 pm, Benny Tsai wrote:
> Here's what I have so far. The code splits blocks into 128 smaller
> sub-arrays, each representing a level, then calls a modified version
> of frequencies (using areduce instead of reduce) on each level. On my
> machine, with server mode on, it takes about 20 seconds to compute the
> frequencies for an array of 99844096 blocks. I haven't tested it on
> your level, because I'm too lazy to get JNBT set up, but I'm curious
> to see if it returns the correct result for you.
>
> (def num-levels 128)
>
> (defn get-level [level-num ^bytes blocks]
> (let [size (/ (count blocks) num-levels)
> output (byte-array size)]
> (doseq [output-idx (range size)]
> (let [block-idx (+ (* output-idx num-levels) level-num)]
> (aset output output-idx (aget blocks block-idx
> output))
>
> (defn afrequencies
> [^bytes a]
> (persistent!
> (areduce a
> idx
> counts
> (transient {})
> (let [x (aget a idx)]
> (assoc! counts x (inc (get counts x 0)))
>
> (defn freqs [^bytes blocks]
> (let [levels (map #(get-level % blocks) (range num-levels))]
> (map afrequencies levels)))
>
> user=> (def blocks (byte-array 99844096))
> #'user/blocks
> user=> (time (count (freqs blocks)))
> "Elapsed time: 20160.780769 msecs"
> 128
>
> On Nov 4, 3:28 pm, Pepijn de Vos wrote:
>
>
>
>
>
>
>
> > Hi all,
>
> > I have written a Python script to analyze Minecraft levels and render a
> > graph. Then I did the same with Clojure. It takes Python 10 seconds to
> > analyze a map, while it takes Clojure over a minute.
>
> > After having tried different options without any significant improvement, I
> > am lost as to why there is such a huge difference. I wouldn't mind an extra
> > pair of eyes/brains to look at this.
>
> > I blogged about it in more detail
> > here:http://pepijndevos.nl/clojure-versus-python
> > Clojure version:https://github.com/pepijndevos/Clomian/
> > Python version:https://github.com/l0b0/mian
>
> > Clojure spends most of its time in the freqs function, here are a couple of
> > variations:https://gist.github.com/663096
>
> > If you want to run the code yourself, you'll need a Minecraft level and
> > JNBT, which is not on Maven.
> > JNBT:http://jnbt.sourceforge.net/
> > The level used in the blogpost:http://dl.dropbox.com/u/10094764/World2.zip
>
> > Groeten,
> > Pepijn de Vos
> > --
> > Sent from my iPod Shufflehttp://pepijndevos.nl
--
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
Clojure 1.3 Alpha 3
Clojure 1.3 Alpha 2 is now available at http://clojure.org/downloads 0 Changes from 1.3 Alpha 2 to 1.3 Alpha 3 1 Changes from 1.3 Alpha 1 to 1.3 Alpha 2 2 Changes from 1.2 to 1.3 Alpha 1 3 About Alpha Releases = 0 Changes from 1.3 Alpha 2 to 1.3 Alpha 3 * fixed filter performance issue introduced in 1.3A2 * with-redefs macro (useful for stubbing) * print-table = 1 Changes from 1.3 Alpha 1 to 1.3 Alpha 2 * code path for using vars is now *much* faster for the common case, and you must explicitly ask for :dynamic bindability * new: clojure.reflect/reflect http://dev.clojure.org/display/design/Reflection+API * new: clojure.data/diff = 2 Changes from 1.2 to 1.3 Alpha 1 * enhanced primitive support (http://dev.clojure.org/display/doc/Enhanced+Primitive+Support) * better exception reporting * ancillary namespaces no longer auto-load on startup: clojure.set, clojure.xml, clojure.zip = 3 About Alpha Releases 1.3 is the first release of Clojure that will include a series of alpha builds. We are adding these builds to support maven and leiningen users, who want a specific artifact that they can target (as opposed to building from master or "moving-target" snapshots). If you are the kind of person who used to track master by building from source, but no longer do so because you are using maven or leiningen, alpha releases are for you. -- 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
Re: Clojure 1.3 Alpha 3
On Fri, Nov 5, 2010 at 5:53 PM, Stuart Halloway wrote: > Clojure 1.3 Alpha 2 is now available at > > http://clojure.org/downloads Thanx. Will contrib get a 1.3.0-alpha3 build? -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- 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
Re: Clojure Box Windows XP
This sounds like a problem with emacs server/client that might be unrelated to Clojure or Slime. Some configurations of emacs will start a server mode so that you can run emacsclient and have a new frame pop up instantaneously. If you don't need emacsclient then you might look in the clojure box configs for a line (server-start) and remove that. On Fri, Nov 5, 2010 at 4:50 PM, Jferg wrote: > I have installed twice, restarted my machine to make sure all is > well. However, the Emacs Client window shows: "Waiting for Emacs > server to start" and yet the SLIME REPL buffer appears to be > functional and various messages like: "Connected Your hacking starts > now!" show up in the status. Eventually the Emacs Client window > shows: "ERROR Timeout waiting for server". > > What can I look at to debug this? I tried guessing at ports and > processes using netstat -ao | grep'ing for process ids... nothing real > popped up. > I am using Clojure box 1.2.0 on Windows XP Service Pack 3. > > > -- > 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 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
Re: Reloading java classes
Do you thin that JRebel for Clojure would be an interesting option to have? I had the impression that REPL solves this problem for Clojure developers, but probably I'm wrong. Definitely, if there's a demand, Clojure support could be added to JRebel. The same way as for Scala.. BR, On Nov 4, 4:31 am, Alexy Khrabrov wrote: > On Nov 3, 2010, at 9:24 PM, Seth wrote: > > > Is it possible to reload modified classes? I would likely to quickly > > test my java classes with clojure. > > http://www.zeroturnaround.com/jrebel/ > > Used to have a free, um, Scala license too... > > -- Alexy -- 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
Why isn't there a fold-right?
Maybe because Clojure has a vector, and conj conjoins new elements to the end of the vector, so there's mere little use of fold-right. But, fold-right is an abstraction tool, missing it in the core is kind of pity. -- 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
Re: clojure-mini kanren implementation of nonvar
Hi David, I get (20) whether "(& x 10)" is commented out or not.. I was expecting it to return '() when"(& x 10)" is commented out and (20) when it is not commented out.. I might have understood the meaning cond-u not correctly.. Sunil. On Fri, Nov 5, 2010 at 7:16 PM, David Nolen wrote: > On Thu, Nov 4, 2010 at 11:36 PM, Sunil S Nandihalli < > sunil.nandiha...@gmail.com> wrote: > >> Hello everybody, >> I know that mini-kanren does not have "nonvar" I was trying to emulate its >> effect by using >> >> (cond-u >> ((& x :unassigned) >>fail) >> (succeed)) >> >> The idea is if x is not assigned it would successfully unify with >> :unassigned (ofcourse I am assuming that none of the valid values can be >> :unassigned ). So since I am using cond-u it would commit to the first >> clause in which the first predicate would succeed and the next predicate >> always fails hence it would fail.. >> >> (run q >> (exist [x] >> (& x 10) >> (cond-u >> ((& x :unassigned) >> fail) >> (succeed)) >> (& q 20))) >> >> I tried the above code it is not having the expected behaviour .. Can >> somebody help me with this ..? >> Thanks, >> Sunil >> > > What is the output that you are seeing? > > 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 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
Re: Lightweight persistence of the ref world
Just had a look-over of the code and spotted a subtle bug I'd missed before: the undertaker is potentially going to remove live keys from the map if the node is loaded again in between (dead-keys-entries) and (remove ...). This oughta fix it: (defn- dead-entries-keys [] (doall (filter identity (for [entry node-cache] (let [val (.getValue entry)] (if (instance? WeakReference val) (if-not (.get val) [(.getKey entry) val]))) (defn- prune-dead-entries [] (doseq [[k v] (dead-entries-keys)] (.remove node-cache k v))) Now the dead WeakReference is bundled with the key in dead-entries- keys; prune-dead-entries destructures and uses the atomic two-argument remove in ConcurrentHashMap to remove the mapping only if the value is still the dead WeakReference and not something else. -- 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
