Re: How to reset a counter
On May 29, 9:44 am, James Reeves wrote: > On 29 May 2010 14:19, WoodHacker wrote: > > > I'm working on a simple imaging problem. I want to copy an array of > > pixels to an image buffer. That means that I have to deal both with > > an array and a matrix (x and y). As I go along my array, each time x > > reaches the end of a line in the matrix I have to set it back to zero > > and increment y. > > > I can find no simple way to do this without getting a compile error. > > Can someone show me how to do this? > > (dotimes [k 256] > (write-buffer (mod k 16) (quot k 16) (value 16))) > James, Thanks. I have written code in about every mainstream language. None of them have this power (except Lisp). Two lines? Amazing. Bill -- 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 script with shebangoid on windows
Thank you! Greetings, a. On 28 Mai, 17:51, Paul Moore wrote: > On 28 May 2010 16:17, alux wrote: > > > Hello Paul, > > > thats much better, many thanks! > > I've added it to the Wikibooks > page,http://en.wikibooks.org/wiki/Clojure_Programming/Tutorials_and_Tips#S... > > Paul. -- 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 script with shebangoid on windows
Small addition, you missed to add the : before eof replace "goto eof" by "goto :eof" Thank you, and regards, alux On 28 Mai, 16:09, Paul Moore wrote: > On 28 May 2010 09:48, alux wrote: > > > Hello! > > > Short: It works, but is not perfect. > > > (this may need an windows expert to make it better) > > Try this: > > --- myscript.bat --- > :x (comment > @echo off > java -cp clojure.jar clojure.main "%~f0" %* > goto eof > ) > > (println "Hi!" *command-line-args*) > > -- > > The way it works: > > The line starting with :x is treated as a label by cmd.exe (and so, in > effect, ignored). In Clojure, it's treated as a keyword :x followed by > the start of a multiline comment - (comment > > So everything down to the closing ) is ignored by clojure, but > executed by cmd.exe > > The next bits: > @echo off - suppress cmd.exe's annoying habit of displaying everything > java... Run the clojure script. %~f0 is the script name - I quote it > in case it has spaces, and %* is the rest of the command line. > Then, goto eof terminates the batch file (goto end of file), ignoring > the rest of the file, which can therefore be arbitrary clojure. > > Paul. -- 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: How to reset a counter
On 30 May 2010 12:39, WoodHacker wrote: > > > On May 29, 9:44 am, James Reeves wrote: >> On 29 May 2010 14:19, WoodHacker wrote: >> >> > I'm working on a simple imaging problem. I want to copy an array of >> > pixels to an image buffer. That means that I have to deal both with >> > an array and a matrix (x and y). As I go along my array, each time x >> > reaches the end of a line in the matrix I have to set it back to zero >> > and increment y. >> >> > I can find no simple way to do this without getting a compile error. >> > Can someone show me how to do this? > >> >> (dotimes [k 256] >> (write-buffer (mod k 16) (quot k 16) (value 16))) >> > > James, > > Thanks. I have written code in about every mainstream language. > None of them have this power (except Lisp). > Two lines? Amazing. Well, what's wrong with this: for (k = 0; k < 256; ++k) writeBuffer(k % 16, k / 16, value[k]); :) -- Michael Wood -- 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: How to reset a counter
This is precisely what 'for' is for in clojure.
For example:
(for [x (range 10) y (range 10)] [x y])
... produces a sequence of the coordinates in a 10x10 grid. You can
then consume the sequence for whatever purpose. The position of each
matrix coord in the seq produced would match up with the position of
the data in your array.
On May 29, 9:19 am, WoodHacker wrote:
> I've been working with Lisp and Scheme for the past few years and have
> migrated to Clojure because of the JVM. I think I get functional
> programming, but one problem is giving me fits.
>
> I'm working on a simple imaging problem. I want to copy an array of
> pixels to an image buffer. That means that I have to deal both with
> an array and a matrix (x and y). As I go along my array, each time x
> reaches the end of a line in the matrix I have to set it back to zero
> and increment y.
>
> I can find no simple way to do this without getting a compile error.
> Can someone show me how to do this?
>
> Example in pseudo code:
>
> x = 0
> y = 0
>
> for (k = 0; k < 256; ++k)
> if (= x 16) {
> x = 0
> (inc y)
> }
> else
> (inc x)
>
> writeBuffer (x, y, value[k])
>
> Bill
--
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: Anyone experienced in using clojure as a "database"
Hi Andrzej, > I have a question about primary keys. As far as I can see you're > currently using the first field of the relation as a primary key. > While that's what other databases do (and it is working well), I think > it would be better to make _records_ themselves primary keys. Since > records are immutable they are guaranteed to be unique and comparing > them is essentially free. Right, and my first "iteration" did exactly this (because I wanted to stay "pure" relational), but it turned out not to be that practical. My #1 issue with primary-key-less relations was, how do I update them efficiently (efficient in terms of LOC and code-complexity, not runtime efficiency)?. To alter a value of a tuple, I had to store the tuple as a reference in every place which initiates an update. That made debugging and working on the repl an extreme unpleasant task. It also made commuting updates hard, since there was no "stable" primary- key to rely on. Additionaly, while praktically working with relations, I hardly found any dataset wich hadn't some kind of unique id. > I have a feeling that would make whole lot > of things much easier (no need to check the primary key field for > uniqueness, no need to implement auto increment mechanisms, foreign > keys would just become actual records). What do you think about it? The good news is, that a relation without a "single" primary key field, is a relation, where every field belongs to the primary-key. Of course, indexes over mutliple fields are currently not implemented, but I do consier this an easy task (just look at the clojure.set/index function, which will generate an index for one or many given fields). Erik -- 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
You could be really odd and write a wrapper for Edje. http://trac.enlightenment.org/e/wiki/Edje Not a serious recommendation, really. I just don't have any strong positive opinions regarding any of the others except for QT, and as you say On May 27, 10:18 am, Luke VanderHart wrote: > My side project is a fairly complex GUI application written in > Clojure. Recently, I've become irritated with using Java interop for > everything. It's not that Clojure doesn't have nice java interop - it > does. It's just that when interacting with a GUI framework, which is a > large part of my app, I have to be back in mutable object-oriented > land, worrying about class hierarchies, mutable state, locks, etc. > Yucky. > > So, with a perhaps dangerous lack of sanity and without any guarantee > of success, I've decided to try my hand at writing an idiomatic > Clojure GUI library. If I have success (which I doubt) I will of > course make it available as open source. > > I intend for it to be mostly declarative, with a nice DSL for defining > GUI elements. Each component will also implement map, and use one of > Clojure's reference types as an interface for inspecting / updating > its state. I may also implement some aspects of Functional Reactive > Programming wherever it's convenient to do so. > > What you all must help me decide is what GUI framework to use as the > underpinnings of it. It's genuinely hard to decide. I have at least > some experience with all of them, so I have no strong preference, but > I'd like to get your input. I did consider trying to make it abstract > enough that you could plug in *any* of them under the hood, but > there's enough differences between the frameworks that that would get > very ugly very fast. > > Possibilities are: > > AWT > Pros: native widgets, bundled with Java, low-level > Cons: few widgets, considered somewhat obselete > > Swing > Pros: bundled with Java, good widget selection > Cons: non-native widgets > > SWT > Pros: native widgets, widely used > Cons: requires platform-specific libs > > QT Jambi > Pros: native widgets, huge widget selection, highly-regarded framework > Cons: requires platform-specific libs, writing custom widgets is > hairy, momentum and support seem to be lagging since Nokia dropped > official support. > > Remember, the actual API won't matter - that will be completely > abstracted away. So try to focus on the framework's look and feel. > Also let me know if I've missed any of the framework's key > characteristics. > > Thanks! > > -Luke -- 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
Macro question from a clojure newbie
Hi all, I'm running into a problem where I need to define several functions and/or vars inside another function, but the function has multiple definitions and they all need to have access to the inner things. This could be solved by making private functions and using partial, but this sounds like a good problem to tackle with a macro. I'm not sure how to do it, though, being so new to the language. Here's a useful example, where defwithinner is the macro name: (defwithinner primitives "Generates pythagorean primitives. Will filter them against pred if given." (let [U (gen-matrix [1 2 2 -2 -1 -2 2 2 3] 3 3) A (gen-matrix [1 2 2 2 1 2 2 2 3] 3 3) D (gen-matrix [-1 -2 -2 2 1 2 2 2 3] 3 3) S (gen-vector [3 4 5])] (letfn [(prims-from [m] [(mult m U) (mult m A) (mult m D)]) (next-prims [l] (flatten (map prims-from l)))])) ([] (iterate next-prims [S])) ([pred] (iterate #(filter pred (next-prims %)) [S]))) ---> (defn primitives "Generates pythagorean primitives. Will filter them against pred if given." ([] (let [U (gen-matrix [1 2 2 -2 -1 -2 2 2 3] 3 3) A (gen-matrix [1 2 2 2 1 2 2 2 3] 3 3) D (gen-matrix [-1 -2 -2 2 1 2 2 2 3] 3 3) S (gen-vector [3 4 5])] (letfn [(prims-from [m] [(mult m U) (mult m A) (mult m D)]) (next-prims [l] (flatten (map prims-from l)))] (iterate next-prims [S] ([pred] (let [U (gen-matrix [1 2 2 -2 -1 -2 2 2 3] 3 3) A (gen-matrix [1 2 2 2 1 2 2 2 3] 3 3) D (gen-matrix [-1 -2 -2 2 1 2 2 2 3] 3 3) S (gen-vector [3 4 5])] (letfn [(prims-from [m] [(mult m U) (mult m A) (mult m D)]) (next-prims [l] (flatten (map prims-from l)))] (iterate #(filter pred (next-prims %)) [S]) OTOH, being so new to clojure I've probably missed some mechanism which already takes care of this problem. -- 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
JavaFx has one other major issue. The scene graph isn't accessible outside of JavaFx script. On Friday, May 28, 2010, Luke VanderHart wrote: > My understanding may be wrong, but I think JavaFX is intended more as > a competitor to Flash or Silverlight than a GUI toolkit. It'd probably > be great for a Clojure games framework, or for simple graphical > drawing and such, but I'm not sure it's appropriate for a complex, > high performance GUI. In fact, according to the Wiki page, if you want > to use desktop style widgets, you actually end up embedding Swing > components *within* JavaFX anyway. > > On May 28, 9:59 am, mmwaikar wrote: >> I work on .Net, so my observation could be totally wrong, but I think >> JavaFx could be an option to consider (specially because of its JSON >> kind of syntax). >> I am working on a WPF project currently, and although WPF is big and >> complex, the kind of UIs one can build with it is amazing, and JavaFx >> looked similar to me in intent and purpose. >> >> So I am really surprised why no one mentioned JavaFx. Is it because >> it's new? >> >> On May 27, 11:18 am, Luke VanderHart >> wrote: >> >> > My side project is a fairly complex GUI application written in >> > Clojure. Recently, I've become irritated with using Java interop for >> > everything. It's not that Clojure doesn't have nice java interop - it >> > does. It's just that when interacting with a GUI framework, which is a >> > large part of my app, I have to be back in mutable object-oriented >> > land, worrying about class hierarchies, mutable state, locks, etc. >> > Yucky. >> >> > So, with a perhaps dangerous lack of sanity and without any guarantee >> > of success, I've decided to try my hand at writing an idiomatic >> > Clojure GUI library. If I have success (which I doubt) I will of >> > course make it available as open source. >> >> > I intend for it to be mostly declarative, with a nice DSL for defining >> > GUI elements. Each component will also implement map, and use one of >> > Clojure's reference types as an interface for inspecting / updating >> > its state. I may also implement some aspects of Functional Reactive >> > Programming wherever it's convenient to do so. >> >> > What you all must help me decide is what GUI framework to use as the >> > underpinnings of it. It's genuinely hard to decide. I have at least >> > some experience with all of them, so I have no strong preference, but >> > I'd like to get your input. I did consider trying to make it abstract >> > enough that you could plug in *any* of them under the hood, but >> > there's enough differences between the frameworks that that would get >> > very ugly very fast. >> >> > Possibilities are: >> >> > AWT >> > Pros: native widgets, bundled with Java, low-level >> > Cons: few widgets, considered somewhat obselete >> >> > Swing >> > Pros: bundled with Java, good widget selection >> > Cons: non-native widgets >> >> > SWT >> > Pros: native widgets, widely used >> > Cons: requires platform-specific libs >> >> > QT Jambi >> > Pros: native widgets, huge widget selection, highly-regarded framework >> > Cons: requires platform-specific libs, writing custom widgets is >> > hairy, momentum and support seem to be lagging since Nokia dropped >> > official support. >> >> > Remember, the actual API won't matter - that will be completely >> > abstracted away. So try to focus on the framework's look and feel. >> > Also let me know if I've missed any of the framework's key >> > characteristics. >> >> > Thanks! >> >> > -Luke > > -- > 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 -- Omnem crede diem tibi diluxisse supremum. -- 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
Verify errors - has clojure/contrib officially moved the java 1.6?
I'm getting verify errors again with the latest 1.2 shapshots of clojure..contrib within Netbeans. I know the source=1.5 and target=1.5 should work when you are compiling with the 1.6 jdk but so far that has not been my experience. I'll stop caring about this when Netbeans 6.9 is out (which I hope is soon) as it will be a 1.6 app but for the time being, the 1.2 features are out of my reach if these assets are built with the jdk 1.6 compiler. Is that the story for the 1.2 release? Thanks, Eric -- 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: Transient HashMaps with not more than 8 elements?
> user> (loop [thm (transient {}),
> i 0]
> (if (<= 10 i)
> (persistent! thm)
> (recur (assoc! thm i i)
> (inc i
> {0 0, 1 1, 2 2, 3 3, 4 4, 5 5, 6 6, 7 7, 8 8, 9 9}
>
By the way, FYI:
(reduce #(assoc %1 %2 %2) {} (range 10))
or
(persistent! (reduce #(assoc! %1 %2 %2) (transient {}) (range 10)))
Reduce is handy for repeatedly assoc'ing into a hash-map.
Justin
--
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: How to reset a counter
On 30 May 2010 12:42, Michael Wood wrote: > Well, what's wrong with this: > > for (k = 0; k < 256; ++k) > writeBuffer(k % 16, k / 16, value[k]); > > :) I was about to say the same thing. Clojure can be more concise than most other languages, but in this case, all one needs is a simple loop, modulus and quotient operations; and all languages have at least that :) - James -- 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: How to reset a counter
It's also worth to mention that the produced seq is lazy, so you can
work on big images without memory issues.
On Saturday, May 29, 2010, John Cromartie wrote:
>
> This is precisely what 'for' is for in clojure.
>
> For example:
>
> (for [x (range 10) y (range 10)] [x y])
>
> ... produces a sequence of the coordinates in a 10x10 grid. You can
> then consume the sequence for whatever purpose. The position of each
> matrix coord in the seq produced would match up with the position of
> the data in your array.
>
> On May 29, 9:19 am, WoodHacker wrote:
>> I've been working with Lisp and Scheme for the past few years and have
>> migrated to Clojure because of the JVM. I think I get functional
>> programming, but one problem is giving me fits.
>>
>> I'm working on a simple imaging problem. I want to copy an array of
>> pixels to an image buffer. That means that I have to deal both with
>> an array and a matrix (x and y). As I go along my array, each time x
>> reaches the end of a line in the matrix I have to set it back to zero
>> and increment y.
>>
>> I can find no simple way to do this without getting a compile error.
>> Can someone show me how to do this?
>>
>> Example in pseudo code:
>>
>> x = 0
>> y = 0
>>
>> for (k = 0; k < 256; ++k)
>> if (= x 16) {
>> x = 0
>> (inc y)
>> }
>> else
>> (inc x)
>>
>> writeBuffer (x, y, value[k])
>>
>> Bill
>
> --
> 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: Datatype Usage Examples
"Adrian Cuthbertson" said: >> That said, I'd rather make sure that my low-level data structures are being >> operated on by only one implementation. > > You could use closures to encapsulate the refs/atoms ... > > (let [car-mem (ref nil)] > (defn set-car-mem [new-car-mem] > (dosync (ref-set car-mem new-car-mem))) > (defn update-car-mem [new-car-mem] > (dosync (set-car-mem new-car-mem))) > (defn get-car-mem [] @car-mem)) > > user=> (set-car-mem 0) > user=> (get-car-mem) > 0 > user=> @car-mem > java.lang.Exception: Unable to resolve symbol: car-mem in this context > (NO_SOURCE_FILE:0) This is how I'd implemented state-hiding in Scheme [1]. The problem though, is exporting a public interface. In [1], (export x y) is just a macro for (define x null) and (define y null). So I define my public bindings and re-assign them to their actual values while I'm inside the closure. I can't do the same in Clojure, since I'm not allowed to re-assign a definition --i.e. its root. A dispatch function should do the trick [2]. [1] http://github.com/sindoc/algorithms/blob/master/src/main/scheme/memory-management/manual/pairs/pair.scm [2] http://github.com/sindoc/algorithms/blob/master/src/test/clojure/whiteboard/y2010/hide-adt-state-using-closure.clj > (note that you need a do-sync around ref-set - your code didn't have one.) 'set-car-mem' and the like are always called from within a dosync. I should probably remove those set-* functions since (1) they don't abstract too much and (2) they confuse readers. Thank you Adrian, for your help. Kind regards, SinDoc -- 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: Datatype Usage Examples
Hi, Am 30.05.2010 um 16:39 schrieb Sina K. Heshmati: > [2] > http://github.com/sindoc/algorithms/blob/master/src/test/clojure/whiteboard/y2010/hide-adt-state-using-closure.clj I'm almost sure, that this code does not what you expect. Nested def's, and in particular defn's, are almost surely wrong. You want: (defn make-module [] (let [state (atom 0) say-hello (fn [] (println "Hello")) public-op (fn [x y] (+ @state x y))] (fn [op] (case op :hello say-hello :public public-op And I'm not sure with what you mean by "you are not allowed to change the root of a Var". Of course you can do that. (declare x) (defn fn-using-x ...) (def x 5) The declare is also (more or less) equivalent to (def x nil). But I'm not sure I misunderstand something here. 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
Having trouble getting full performance from a quad-core with trivial code
I'm running Clojure code on an early Mac Pro with OS X 10.5 and Java 1.6. It has two dual-core Xeon 5150s and 5GB of memory. I'm not getting the performance I expected despite top reporting 390% steady-state CPU use, so I wrote some trivial tests to see if I was actually getting the benefit of all four cores. It runs about twice as fast with four cores as with one, and only slightly faster with three or four than with two. This code being trivially parallel, I was expecting nearly 4x the speed with four cores. Here are the tests and results: http://gist.github.com/418631 I'd appreciate it if anybody could a. point out any problems with my code that might be hurting performance b. try this out on your own 3+ core machine and see if you have better results -- 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: Having trouble getting full performance from a quad-core with trivial code
On May 30, 2010, at 18:31 , Zak Wilson wrote: > I'm running Clojure code on an early Mac Pro with OS X 10.5 and Java > 1.6. It has two dual-core Xeon 5150s and 5GB of memory. Just a idea, two dual cores != 4 cores. Parallelism on more then one CPU is always slower then on one cpu with multiple cores, for the first seconds the process might not even get swapped to the second CPU at all. Perhaps that is why your speed gain isn't that high. Try to take 10k instead of 5k for the tests, does that change anything? Regards, Heinz -- 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: Having trouble getting full performance from a quad-core with trivial code
Zak, This may not be your main issue and I haven't done enough testing with my own code to know if it's even my main issue, but I've found that things appear to go better for me on multicore machines if I invoke java with the -XX:+UseParallelGC option. -Lee On May 30, 2010, at 12:31 PM, Zak Wilson wrote: > I'm running Clojure code on an early Mac Pro with OS X 10.5 and Java > 1.6. It has two dual-core Xeon 5150s and 5GB of memory. > > I'm not getting the performance I expected despite top reporting 390% > steady-state CPU use, so I wrote some trivial tests to see if I was > actually getting the benefit of all four cores. It runs about twice as > fast with four cores as with one, and only slightly faster with three > or four than with two. This code being trivially parallel, I was > expecting nearly 4x the speed with four cores. > > Here are the tests and results: http://gist.github.com/418631 > > I'd appreciate it if anybody could > > a. point out any problems with my code that might be hurting > performance > b. try this out on your own 3+ core machine and see if you have better > results -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.blogspot.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
Understanding sequence abstraction
Hi Clojurians, I have some conceptual questions on the sequence abstraction. I understand that (seq coll) will give me a "sequence". coll maybe be a list, vector, map, set, LazySeq or nil. 1. In case coll is a LazySeq why does (seq coll) realize its first element? I thought seq just did a type conversion and all of list, vector .. etc implemented Seqable or something. 2. Why is there no other way to determine an empty coll except (not (seq coll)). - Thanks -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
special forms and let binding
Hi! For example, it's possible to do things like: (def do println) ((var do) "example") And it works correct. But I don't understand how to get the same behavior in let bindings. I mean (let [do println] ..) what can I write to get the same results? -- 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: Having trouble getting full performance from a quad-core with trivial code
Heinz - playing with the size of the number doesn't have much effect, except that when it becomes very small, parallelization overhead eventually exceeds compute time. Lee - Parallel GC slowed it down by 3 seconds on the four core benchmark. -- 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
Swing, mainly for deployment reasons. It's not hard to set the look and feel to the platform's look and feel. That's not perfect, but it's usually not bad either, though the GTK1-style file chooser is horrid. -- 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: Understanding sequence abstraction
1. In case coll is a LazySeq why does (seq coll) realize its first element? I thought seq just did a type conversion and all of list, vector .. etc implemented Seqable or something. Because seq is defined as returning nil for an empty sequence. The only way to find that out for a lazy sequence is to realize the first element. 2. Why is there no other way to determine an empty coll except (not (seq coll)). user=> (empty? []) true -- 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: Understanding sequence abstraction
On May 30, 8:11 pm, Richard Newman wrote: > > 2. Why is there no other way to determine an empty coll except (not > > (seq coll)). > > user=> (empty? []) > true And in fact, the docs for (empty?) say: "Please use the idiom (seq x) rather than (not (empty? x))" Perhaps the seq docs should indicate empty? in some 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
Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
+1 SWT -- but if it's good, Swing works also. -- 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
On May 29, 10:29 pm, Daniel wrote: > You could be really odd and write a wrapper for Edje. > > http://trac.enlightenment.org/e/wiki/Edje > > Not a serious recommendation, really. I just don't have any strong > positive opinions regarding any of the others except for QT, and as > you say I would give that a point also, if it were really a practical possibility. It is my preferred window manager. I have spent quite a bit of time developing Swing GUI applications on Linux under Enlightenment, plus some testing under KDE, XFCE. Swing looks okay, is highly usable, and gave me less issues than SWT for LaF under different window managers. When using the GTK LaF Swing can be tweaked with gtk-chtheme for a custom appearance, including to look fairly similar to KDE by using QtCurve. There are numbers of LaF for Windows (e.g., substance) that give a good selection/conformance. Mac basically has only one look for any particular major version of the OS (for which there is quauqua, MRJAdapter, and others). -- 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
I am not knocking all of these +1 Swing posts. But I would love to see one good public application built in Swing (besides Netbeans) On May 28, 9:10 am, laseray wrote: > +1 Swing > > If I had my druthers I would go with QtJambi, but since Nokia dropped > development for that it has not been able to keep pace with Qt. So > that would be immediately out of sync. Plus the need for platform > native compiled code is a minus. Fine for the main three (Linux, Mac, > Windows) with precompiled libs, but separate compile for anything else > equals ongoing maintenance effort. This defeats the point of having a > cross-platform language. Java and Clojure will work (.e.g, on FreeBSD, > OpenSolaris, AIX), but the GUI won't unless you make extra C/C++ > coding effort? > > SWT is a minus due to native code needs, too much XML configuration, > and the fact that it does not look nearly as good as some people think > when used cross-platform. Looks fine on Windows, the Mac side is > getting better now that they are starting to use Cocoa underneath, > Linux side is questionable with varying appearance across different > window managers. Other OS? This is the same as for QtJambi, extra C/C+ > + coding effort needed to be really cross-platform. > > No reason to go with AWT exclusively. A lot of Swing wraps parts of or > needs AWT anyway. You can't really get away from it and will be > cutting off a limb, so to speak, if you go with it rather than Swing > first. > > A lot of the misgivings about Swing look and feel across platform > boils down to bad GUI development efforts. I have seen this many > times. Many developers just do not understand the specific interface > needs across different platforms and just leave parameters at the > default settings, which only by luck will be near optimal. I have > developed a number of Swing applications that look pretty close to > native (at least on Linux, Mac, Windows, Solaris) so I can say that it > takes some attention to platform specific details to make this happen > (and access to multiple OS). That is what it takes to develop a > serious professional cross-platform desktop application, no way around > it (you would even have to do this if going with QtJambi or SWT). > > Overall, I would go with Swing. The main reason is that it will > already be cross-platform on any Java compliant OS that can run > Clojure. I think that is the most important thing if you want a GUI to > go along with the language. Nothing additional is needed to complicate > matters, besides the GUI layer/framework on top of Clojure. > > Nonetheless, the best idea would be to ensure you have enough > abstraction in your implementation so that other GUI toolkits could be > "almost" dropped in place later on. That is, it should not close out > other toolkits, but going with what will work now or sooner than later > is better. Going with Swing is a way to get something out soon without > having to spend additional effort worrying about C/C++ libraries, > packaging and so on. Get something to work, then the additional > toolkits can come. -- 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 script with shebangoid on windows
On 30 May 2010 12:31, alux wrote:
> Small addition, you missed to add the : before eof
>
> replace "goto eof" by "goto :eof"
Thanks, good catch. ("goto eof" without the colon works on TCC, which
I normally use as my command shell).
Paul.
--
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
Function Size
I'm new to Clojure and have a long background in Java. After writing Clojure code for a month or so now, I find myself struggling with function size. If I have expressions that can be grouped by association, then I can re-factor these expression(s) into a function. However, the newly re-factored function is then accessible outside the (let []) of the function from which I'll access it. This seems wrong since my new function is only intended to be accessed from it's calling function. In Java, code separation is encouraged to promote cohesion. Classes are intended to be small and single purpose in nature. The class's public method(s) are intended to provide the interface (or api) by which the functionality of the class is accessed. In Java I can constrain access to a method by declaring it private making it invisible to calling classes. For Clojure I'd like to be able to specify the function or set of functions that expose the api of a namespace without implying that every function in the namespace is meant to be accessed directly. -jbs -- 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: Function Size
Hi jbs,
Not sure why the title of this post is about "size" instead of "protection",
but why don't you just use private functions in Clojure?
(defn- my-little-helper [] "visible only in my namespace" ...)
Note the "-" on the end of defn, which is idiomatic for introducing a private
var. You can also do this with explicit {:private true} metadata on the name.
Cheers,
Stu
> I'm new to Clojure and have a long background in Java. After writing
> Clojure code for a month or so now, I find myself struggling with
> function size. If I have expressions that can be grouped by
> association, then I can re-factor these expression(s) into a
> function. However, the newly re-factored function is then accessible
> outside the (let []) of the function from which I'll access it. This
> seems wrong since my new function is only intended to be accessed from
> it's calling function.
>
> In Java, code separation is encouraged to promote cohesion. Classes
> are intended to be small and single purpose in nature. The class's
> public method(s) are intended to provide the interface (or api) by
> which the functionality of the class is accessed. In Java I can
> constrain access to a method by declaring it private making it
> invisible to calling classes.
>
> For Clojure I'd like to be able to specify the function or set of
> functions that expose the api of a namespace without implying that
> every function in the namespace is meant to be accessed directly.
>
> -jbs
>
>
> --
> 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: Macro question from a clojure newbie
Hi, Not really mechanisms, but two Idioms will help you with your problem: Either wrap the defn in a let: (let [U (gen-matrix [1 2 2 -2 -1 -2 2 2 3] 3 3) A (gen-matrix [1 2 2 2 1 2 2 2 3] 3 3) D (gen-matrix [-1 -2 -2 2 1 2 2 2 3] 3 3) S (gen-vector [3 4 5])] (letfn [(prims-from [m] [(mult m U) (mult m A) (mult m D)]) (next-prims [l] (flatten (map prims-from l)))] (defn primitives "Generates pythagorean primitives. Will filter them against pred if given." ([] (iterate next-prims [S])) ([pred] (iterate #(filter pred (next-prims %)) [S]) or use a default value for pred: (constantly true) (defn primitives "Generates pythagorean primitives. Will filter them against pred if given." ([] (primitives (constantly true))) ([pred] (let [U (gen-matrix [1 2 2 -2 -1 -2 2 2 3] 3 3) A (gen-matrix [1 2 2 2 1 2 2 2 3] 3 3) D (gen-matrix [-1 -2 -2 2 1 2 2 2 3] 3 3) S (gen-vector [3 4 5])] (letfn [(prims-from [m] [(mult m U) (mult m A) (mult m D)]) (next-prims [l] (flatten (map prims-from l)))])) (iterate #(filter pred (next-prims %)) [S]))) The former will evaluate the values only once when the file is loaded and keep them around until your program dies and do not impose any runtime overhead when you call the function, because all variables are already initialized. The latter one uses a default argument to pred. (constantly true) returns a n-argument function wich returns true on every invokation. Erik -- 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: Function Size
You can bind functions inside a let, which can help if you're just trying to make code less nested. The thread-first and thread-last macros help here too. But if you're looking for the equivalent of the "private" keyword (sort of) check out defn-. Note the dash at the end. On Sunday, May 30, 2010, jbs wrote: > I'm new to Clojure and have a long background in Java. After writing > Clojure code for a month or so now, I find myself struggling with > function size. If I have expressions that can be grouped by > association, then I can re-factor these expression(s) into a > function. However, the newly re-factored function is then accessible > outside the (let []) of the function from which I'll access it. This > seems wrong since my new function is only intended to be accessed from > it's calling function. > > In Java, code separation is encouraged to promote cohesion. Classes > are intended to be small and single purpose in nature. The class's > public method(s) are intended to provide the interface (or api) by > which the functionality of the class is accessed. In Java I can > constrain access to a method by declaring it private making it > invisible to calling classes. > > For Clojure I'd like to be able to specify the function or set of > functions that expose the api of a namespace without implying that > every function in the namespace is meant to be accessed directly. > > -jbs > > > -- > 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: Function Size
On May 30, 12:18 pm, Stuart Halloway
wrote:
> Hi jbs,
>
> Not sure why the title of this post is about "size" instead of "protection",
> but why don't you just use private functions in Clojure?
>
> (defn- my-little-helper [] "visible only in my namespace" ...)
>
> Note the "-" on the end of defn, which is idiomatic for introducing a private
> var. You can also do this with explicit {:private true} metadata on the name.
>
> Cheers,
> Stu
>
>
>
> > I'm new to Clojure and have a long background in Java. After writing
> > Clojure code for a month or so now, I find myself struggling with
> > function size. If I have expressions that can be grouped by
> > association, then I can re-factor these expression(s) into a
> > function. However, the newly re-factored function is then accessible
> > outside the (let []) of the function from which I'll access it. This
> > seems wrong since my new function is only intended to be accessed from
> > it's calling function.
>
> > In Java, code separation is encouraged to promote cohesion. Classes
> > are intended to be small and single purpose in nature. The class's
> > public method(s) are intended to provide the interface (or api) by
> > which the functionality of the class is accessed. In Java I can
> > constrain access to a method by declaring it private making it
> > invisible to calling classes.
>
> > For Clojure I'd like to be able to specify the function or set of
> > functions that expose the api of a namespace without implying that
> > every function in the namespace is meant to be accessed directly.
>
> > -jbs
>
> > --
> > 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
Thanks. I hadn't noticed (defn- foo []) in the API. This seems
exactly what I'm looking for.
--
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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
> I am not knocking all of these +1 Swing posts. But I would love to > see one good public application built in Swing (besides Netbeans) Here's a couple just off the top of my head... jEdit http://www.jedit.org/ GanttProject http://www.ganttproject.biz/ Intellij IDEA, RubyMine, PhpStorm, WebStorm, PyCharm http://www.jetbrains.com/ SmatCVS, SmartSVN, SmartGIT http://www.syntevo.com/index.html LimeWire/FrostWire http://www.frostwire.com/ ImageJ http://rsbweb.nih.gov/ij/ Video Annotation and Reference System http://vars.sourceforge.net/ -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlin...@gmail.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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
> > > I am not knocking all of these +1 Swing posts. But I would love to >> see one good public application built in Swing (besides Netbeans) > > > Here's a couple just off the top of my head... > Also, Aqua Data Studio (my favorite db tool) http://www.aquafold.com/ -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlin...@gmail.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: special forms and let binding
Hi A., I dont completely understand what you refer to with "works correct". You define a local variable, named do, and use it. That works of course. Btw you may use it without the call to var (def do println) (do "example") In let you may do (let [do println] (do :plop)) Is this what you want? (I'm driven to point out that this is bad style - but you probably know already.) Regards, alux On 30 Mai, 19:07, "A.Rost" wrote: > Hi! > For example, it's possible to do things like: > (def do println) > ((var do) "example") > > And it works correct. But I don't understand how to get the same > behavior in let bindings. > I mean > (let [do println] > ..) > what can I write to get the same results? -- 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
review the clojure.string code
I have been working on a branch [1] and haven't updated the ticket yet [2]. Given the number of diverse (and sometimes opposite!) opinions already expressed on this topic, I thought a little extra community review would be in order. David and I organized the work into several fairly small commits so you can grab the branch and see the individual decisions being made. Thanks! Stu [1] http://github.com/stuarthalloway/clojure/tree/string [2] https://www.assembla.com/spaces/clojure/tickets/359-promote-contrib-string -- 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: Macro question from a clojure newbie
The first solution looks good. I had no idea that wrapping a defn inside of let's would leave the function exposed. Interesting. Is it considered idiomatic though? On May 30, 2:16 pm, Erik Söhnel wrote: > Hi, > > Not really mechanisms, but two Idioms will help you with your problem: > Either wrap the defn in a let: > > (let [U (gen-matrix [1 2 2 -2 -1 -2 2 2 3] 3 3) > A (gen-matrix [1 2 2 2 1 2 2 2 3] 3 3) > D (gen-matrix [-1 -2 -2 2 1 2 2 2 3] 3 3) > S (gen-vector [3 4 5])] > (letfn [(prims-from [m] [(mult m U) (mult m A) (mult m D)]) > (next-prims [l] (flatten (map prims-from l)))] > (defn primitives > "Generates pythagorean primitives. Will filter them against > pred if > given." > ([] (iterate next-prims [S])) > ([pred] (iterate #(filter pred (next-prims %)) [S]) > > or use a default value for pred: (constantly true) > > (defn primitives > "Generates pythagorean primitives. Will filter them against pred if > given." > ([] (primitives (constantly true))) > ([pred] > (let [U (gen-matrix [1 2 2 -2 -1 -2 2 2 3] 3 3) > A (gen-matrix [1 2 2 2 1 2 2 2 3] 3 3) > D (gen-matrix [-1 -2 -2 2 1 2 2 2 3] 3 3) > S (gen-vector [3 4 5])] > (letfn [(prims-from [m] [(mult m U) (mult m A) (mult m D)]) > (next-prims [l] (flatten (map prims-from l)))])) > (iterate #(filter pred (next-prims %)) [S]))) > > The former will evaluate the values only once when the file is loaded > and keep them around until your program dies and do not impose any > runtime overhead when you call the function, because all variables are > already initialized. > The latter one uses a default argument to pred. (constantly true) > returns a n-argument function wich returns true on every invokation. > > Erik -- 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: Newbie question about vector performance
Michael Gardner wrote: As a style issue I'd suggest using inc, dec, neg?, pos?, and zero? instead of the various (+ x 1), (< x 0), etc. in your code. This actually seems to improve performance a bit on my laptop, but it's nothing amazing. To get good performance you're likely going to need to do some type hinting. Thanks for the style suggestion, this is something I will use. I have been playing a little with type hinting without much improvement. It is perfectly possible I have done it wrong, but my algorithm is not that intensive in integer arithmetic. My Java version with Integers instead of ints (still using arrays) is some 4 times slower than the Java version with ints and arrays, but still some 40 times faster than my original Clojure attempt. Luke VanderHart wrote: I can't see your code due to the IT policies here, but I can make some generalizations - these are assuming your code is correct and you're not accidentally using an exponential algorithm (which I wouldn't preclude, 4 minutes does sound truly excessively slow, even for vectors). Well, actually it is 4 seconds, if it was 4 minutes I would have been too embarrassed even to ask for help ;-) Vectors are significantly slower than Java arrays due to their copy-on- write semantics. You have a few options, both of which are considered perfectly acceptable Clojure for high-performance numerical code: 1. Use transients (http://clojure.org/transients) when you update your vectors. This should give you a pretty significant speed increase. 2. Alternatively, use native java arrays. Clojure provides a complete set of functions for creating and mutating raw Java arrays 3. Use type hints to eliminate reflection at choke points in your processing. It seems 2 and 3 must be in my to-learn list inmediately. Transients look like a little bit "advanced Clojure" for me now... :-) Thank you. Igor Rumiha wrote: Here is a version that is approx 10 times faster: http://snipt.org/Olml The code structure is basically the same but it uses integer arrays for storage, some manual inlining and lots of type casts. I'm not certain it _works_ correctly, but... :) You did not have to do that, a simple "try with native Java arrays" would have been enough for me to do my homework. Any way, I truly appreciate your effort... :-) My observations: - use the profiler. jvisualvm that comes with the sun JDK has received some much needed love recently (especially in java 1.6.0_20) and has helped me alot in profiling the code. Install an additional plugin: Sampler. It is has a much lower overhead compared to the Profiler plugin that is installed by default. Both are useful, though. - native clojure data structures (seqs, vectors, maps, etc.) are slow (compared to native Java arrays for instance). There is no going around that. Immutability and other very nice features come with a price. Dynamic languages are also, by their nature, slower than their static companions. - jvisualvm shows that in my version 40% - 50% of the time is spent in the ur-8neigh-minmax function. That time is further split into array fetches, casts to int, arithmetic (inc, dec, add, multiply, comparisons). I simply don't know how to optimise that further without changing the algorithm. On that note, the Clojure compiler and core libraries are getting better: http://snipt.org/Olmn Current Clojure 1.2.0 gives approx 10% better results. I have never been a "man of profilers", so I do not have experience with them. Maybe another thing for my to-learn list. Yes, that function is called once per every cell in the CA, and reads the value of every neighoubr of that cell, so it is quite natural it takes most of the time. The truth is that I am a bit surprised it is just 40-50 percent of the time, I would have guessed it was more. I'll have to think about it... Hope this helps... :) It helps, thank you very much :-) Laurent Petit asked: If you change the size of your CA, is the ( java time / clojure time ratio ) roughly constant ? Not really sure. For instance, in Java (array of ints) a 2000x2000 CA is updated in some 180 ms. (the 500x500 was 16ms, but I measured it with System.currentTimeMillis(), which is not very precise with that short periods of time) and in Clojure the 2000x2000 CA is updated in 98 secs some times and up to 150 s. other times (the 500x500 was 4 secs), but I have just measured it in my home laptop, so it is really not fair to compare with my original measurement at my work desktop. I will make some more tests tomorrow if I can, bur for now I would say that in the worst case my Clojure algorithm may be slightlly worse than the one I have implemented in Java (that it is the basic one you would apply after taking "Programming 101"). Thanks to all of you for your interest, I will inform of any further advance... :-) Rubén -- Rubén BÉJAR HERNÁNDEZ Dpto. de Informática e Ingeniería de Sistemas - Universidad de Zaragoza (Computing and S
Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
I'd vote for swing and against anything that abstracts away the toolkit so that you can switch the backend. Implementing a clojure wrapper for the apache pivot toolkit gave me a little insight on at least two GUI toolkits, namely swing and pivot. Despite their goal of displaying widgets on a 2 dimensional plane, their APIs differ in a lot of ways, like different listener types, totally different approaches to layout. I'd say that it would hardly possible to find a common API without implementing substancial parts of, say, the layout engine yourself so that its results look equal on every backend. My main issue, besides the deployment hurdle with SWT, is that you have to manage graphics resources manually in SWT (see http://www.otug.org/groups/javasig/richclient.pdf). Like, say you would like to have built a form where you have a lazy seq of checkboxes for displaying the contents of a map. Also, with swing, you can add a small gui to whatever program you are going to ship, without bothering about the additional complexity induced by including a gui. Erik -- 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
Rationals, and their size
Hello, I careless used rationals in a function, and, well, it took some minutes to understand why it was slowing down. (I did this formatting by (println (* 1.0 x)) when it started being unreadable - and forgot that). I still see rationals as very nice, but try to use them carefully now. What I would really like is a possibility to round to a numer of a certain size. Like, to an continued fraction of a certain size. But, there I need access to the length of numerator and denominator. Now the question - is there any way to access this (or to reach to goal of rounding to a rational), that is easier than using the BigIntegers myself? Thank you, alux -- 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: review the clojure.string code
Why do some of the functions use StringBuilder (no internal synchronization) and some use StringBuffer (provides internal synchronization). Using the latter is probably a mistake. The first function -- reverse -- uses StringBuilder#reverse() to reverse the character sequence in place, and then calls StringBuilder#toString() to yield a String. Why is the final step necessary? Since StringBuilder implements CharSequence, isn't it sufficient to just return the StringBuilder? That's what the function signature promises. Calling toString() makes yet another copy of the data, so it's best avoided. Some of these functions construct instances of class StringBuilder using its default constructor, which gives it a default capacity. But most of the functions also know at the outset some reasonable size for the buffer. For instance, function `replace-first-by' could reasonably use the length of its argument "s" as the size of the buffer, even though the replacement for some matched substring may increase the overall length. Why does function `replace-first' unconditional call CharSequence#toString() on its argument "s", when in several cases just using "s" as a CharSequence would be fine. Again, calling CharSequence#toString() might make a copy of the data, depending on whether the CharSequence was actually a String or something like a StringBuilder. The implementation of a function like `trim' could be more efficient, given that it's allowed to return a CharSequence. You can construct a StringBuilder of length equal to the source CharSequence, then walk the source sequence from the beginning, skipping over all whitespace, copying the non-whitespace characters, repeating until you hit the end of the source string. The "right trim" behavior is a little tricky, as you have to suspend the copying upon encountering whitespace, but but back up and copy that whitespace upon encountering something else before the end of the source string. Alternately, just walk backward from the end of the source string. The bonus is that you only copy the data once. With the current implementation, calling CharSequence#toString() might copy the data once, and calling String#trim() will copy it again. Rounding out the review, function `trim-newline' doesn't have to call toString() on the CharSequence yielded by CharSequence#subSequence(), as it already promises to return a CharSequence. Most Java code poisons its string manipulation efficiency by always promising to return String rather than CharSequence. You've done better in your signatures here, so I'm just encouraging you to avoid String and the extra copies it forces. -- Steven E. Harris -- 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
not being a programmer perhaps I should be quite, but I never do that. +10 for swing, here is why: 1: it is there 2: it is good enough 3: doing the bare minimum you are signing up for a large amount of work, don't sign up for more. 4: people who build new gui libs usually have their own ideas how things should work, often incompatible ideas. 5: there is someone else who wants to work with you on this. 1 is very important, if your users must install custom packages you will have to answer a lot of emails and write good docs instead of doing fun stuff. you do not want to be supporting skeedo linux, HP-UX . if your doing swing support is install java 1.5 or better. but with that said +1 Tk, marc On Thu, May 27, 2010 at 11:18 AM, Luke VanderHart wrote: > My side project is a fairly complex GUI application written in > Clojure. Recently, I've become irritated with using Java interop for > everything. It's not that Clojure doesn't have nice java interop - it > does. It's just that when interacting with a GUI framework, which is a > large part of my app, I have to be back in mutable object-oriented > land, worrying about class hierarchies, mutable state, locks, etc. > Yucky. > > So, with a perhaps dangerous lack of sanity and without any guarantee > of success, I've decided to try my hand at writing an idiomatic > Clojure GUI library. If I have success (which I doubt) I will of > course make it available as open source. > > I intend for it to be mostly declarative, with a nice DSL for defining > GUI elements. Each component will also implement map, and use one of > Clojure's reference types as an interface for inspecting / updating > its state. I may also implement some aspects of Functional Reactive > Programming wherever it's convenient to do so. > > What you all must help me decide is what GUI framework to use as the > underpinnings of it. It's genuinely hard to decide. I have at least > some experience with all of them, so I have no strong preference, but > I'd like to get your input. I did consider trying to make it abstract > enough that you could plug in *any* of them under the hood, but > there's enough differences between the frameworks that that would get > very ugly very fast. > > Possibilities are: > > AWT > Pros: native widgets, bundled with Java, low-level > Cons: few widgets, considered somewhat obselete > > Swing > Pros: bundled with Java, good widget selection > Cons: non-native widgets > > SWT > Pros: native widgets, widely used > Cons: requires platform-specific libs > > QT Jambi > Pros: native widgets, huge widget selection, highly-regarded framework > Cons: requires platform-specific libs, writing custom widgets is > hairy, momentum and support seem to be lagging since Nokia dropped > official support. > > Remember, the actual API won't matter - that will be completely > abstracted away. So try to focus on the framework's look and feel. > Also let me know if I've missed any of the framework's key > characteristics. > > Thanks! > > -Luke > > > > > > > > > > > > > > > > -- > 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 -- Freedom is nothing but a chance to be better. --Albert Camus The problem with socialism is that eventually you run out of other people's money. --Margaret Thatcher -- 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
On 31/05/2010, at 9:44 AM, Marc Spitzer wrote: > 2: it is good enough IMO This is the entire point. Swing is not good enough if you want to build something with native integration and correct look and feel. Everything else comes down to whether developers are prepared to pay the price for producing something great. And anyway is 'good enough' what we should be aiming for. How about going for something superlative rather than something mediocre. Bundling SWT into a native wrapper isn't a big deal. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. -- Douglas Adams -- 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
On Sun, May 30, 2010 at 8:23 PM, Antony Blakey wrote: > > On 31/05/2010, at 9:44 AM, Marc Spitzer wrote: > >> 2: it is good enough > > IMO This is the entire point. Swing is not good enough if you want to build > something with native integration and correct look and feel. Everything else > comes down to whether developers are prepared to pay the price for producing > something great. And anyway is 'good enough' what we should be aiming for. > How about going for something superlative rather than something mediocre. > > Bundling SWT into a native wrapper isn't a big deal. I do agree with you for 'a' native wrapper. What is your opinion for all native wrappers? The thing is that each platform that requires native code is a source of tech support requests. Now let me go with the things I have at work: 1: redhat 64 and 32 bit, various flavors 2: solaris x86 and sparc various flavors 3: aix various flavors 4: mac os various flavors including powerpc 5: windows 6 other linuxes also lets not forget about LD_LIBRARY_PATH issues, incomparable installed libs, the need to go off the reservation to get something working. Instead of yum working on my redhat boxes I need to compile a specific version of something *AND* make sure this app finds it but that the other apps do not. and for all of the above tech support for swing is install right version of java. *AND* if you can not do that then tech support stops and people can get back to coding. well java is not good enough if you want a native look, you need C/C++ and binding that java uses. And why should Luke be a martyr and pay the price in his personal time/life for something that should be fun. If it is fun he more likely to continue to work on it, as is the case with most hobbies. And who said that I valued native integration all that much. And no one is saying he should or should not make a superlative swing wrapper or what ever he chooses to do. Also please keep in mind that "Better" is a good target and generally much more achievable then superlative. Shipped is also a wonderful thing. Better and shipped are really cool. And if you keep shipping better thing you get to superlative. thanks, marc > > Antony Blakey > -- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > Human beings, who are almost unique in having the ability to learn from the > experience of others, are also remarkable for their apparent disinclination > to do so. > -- Douglas Adams > > > -- > 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 -- Freedom is nothing but a chance to be better. --Albert Camus The problem with socialism is that eventually you run out of other people's money. --Margaret Thatcher -- 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
On 31/05/2010, at 10:44 AM, Marc Spitzer wrote: > I do agree with you for 'a' native wrapper. What is your opinion for > all native wrappers? The thing is that each platform that requires > native code is a source of tech support requests. Now let me go with > the things I have at work: > 1: redhat 64 and 32 bit, various flavors > 2: solaris x86 and sparc various flavors > 3: aix various flavors > 4: mac os various flavors including powerpc > 5: windows > 6 other linuxes I care about Mac and Windows primarily, and building software that will sell (not dev tools) requires good native look and feel. > also lets not forget about LD_LIBRARY_PATH issues, No Mac or Windows user would encounter these. > incomparable > installed libs, the need to go off the reservation to get something > working. Instead of yum working on my redhat boxes I need to compile > a specific version of something *AND* make sure this app finds it but > that the other apps do not. And this is just one reason Linux on the desktop is a million miles from Mac and Windows. > well java is not good enough if you want a native look, you need C/C++ > and binding that java uses. And why should Luke be a martyr and pay > the price in his personal time/life for something that should be fun. a) SWT is not martydom, and is a lot better than Swing for a native L&F b) Luke asked for opinions. > Also please keep in mind that "Better" is a good target and generally > much more achievable then superlative. Shipped is also a wonderful > thing. Better and shipped are really cool. And if you keep shipping > better thing you get to superlative. Not if your toolkit (Swing) places an upper bound on the quality of your app. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Nothing is really work unless you would rather be doing something else. -- J. M. Barre -- 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
This is a great idea, and is something that Clojure really needs in my opinion (for starters it would be nice to be able to write GUI apps in Clojure without worrying about the Java level, with its completely different and completely annoying semantics). My vote is for Swing, simply because the difference in look and feel doesn't seem to be all that great. If the added difficulty of deploying bought tremendous LAF benefits I would say yeah use SWT, but really the differences don't seem to justify it. Also, it could always be forked later on if there were a big enough contingency of SWT fans, and the work put into building Swing version would go a long way toward that goal, especially considering that this is going to abstract away the Swing-specific stuff. Rob On Thu, May 27, 2010 at 11:18 AM, Luke VanderHart wrote: > My side project is a fairly complex GUI application written in > Clojure. Recently, I've become irritated with using Java interop for > everything. It's not that Clojure doesn't have nice java interop - it > does. It's just that when interacting with a GUI framework, which is a > large part of my app, I have to be back in mutable object-oriented > land, worrying about class hierarchies, mutable state, locks, etc. > Yucky. > > So, with a perhaps dangerous lack of sanity and without any guarantee > of success, I've decided to try my hand at writing an idiomatic > Clojure GUI library. If I have success (which I doubt) I will of > course make it available as open source. > > I intend for it to be mostly declarative, with a nice DSL for defining > GUI elements. Each component will also implement map, and use one of > Clojure's reference types as an interface for inspecting / updating > its state. I may also implement some aspects of Functional Reactive > Programming wherever it's convenient to do so. > > What you all must help me decide is what GUI framework to use as the > underpinnings of it. It's genuinely hard to decide. I have at least > some experience with all of them, so I have no strong preference, but > I'd like to get your input. I did consider trying to make it abstract > enough that you could plug in *any* of them under the hood, but > there's enough differences between the frameworks that that would get > very ugly very fast. > > Possibilities are: > > AWT > Pros: native widgets, bundled with Java, low-level > Cons: few widgets, considered somewhat obselete > > Swing > Pros: bundled with Java, good widget selection > Cons: non-native widgets > > SWT > Pros: native widgets, widely used > Cons: requires platform-specific libs > > QT Jambi > Pros: native widgets, huge widget selection, highly-regarded framework > Cons: requires platform-specific libs, writing custom widgets is > hairy, momentum and support seem to be lagging since Nokia dropped > official support. > > Remember, the actual API won't matter - that will be completely > abstracted away. So try to focus on the framework's look and feel. > Also let me know if I've missed any of the framework's key > characteristics. > > Thanks! > > -Luke > > > > > > > > > > > > > > > > -- > 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
On Sun, May 30, 2010 at 9:23 PM, Antony Blakey wrote: > > On 31/05/2010, at 10:44 AM, Marc Spitzer wrote: > >> I do agree with you for 'a' native wrapper. What is your opinion for >> all native wrappers? The thing is that each platform that requires >> native code is a source of tech support requests. Now let me go with >> the things I have at work: >> 1: redhat 64 and 32 bit, various flavors >> 2: solaris x86 and sparc various flavors >> 3: aix various flavors >> 4: mac os various flavors including powerpc >> 5: windows >> 6 other linuxes > > I care about Mac and Windows primarily, and building software that will sell > (not dev tools) requires good native look and feel. I actually primarily do not care about mac or windows, personally or professionally. Also keep in mind that one of the selling points of clojure is that it runs where *Java* runs not mac and windows, I would think that in my mind anyway, be a strong contributing point. Now to be honest I am responsible for Macs at work but hopefully less of them as time goes by. > >> also lets not forget about LD_LIBRARY_PATH issues, > > No Mac or Windows user would encounter these. Have you ever heard of DLL HELL? It is a special case of library path issues, they exist every where you have shared libs/DLLS being loaded. And as a sysadmin I have had LD issues with OSX. > >> incomparable >> installed libs, the need to go off the reservation to get something >> working. Instead of yum working on my redhat boxes I need to compile >> a specific version of something *AND* make sure this app finds it but >> that the other apps do not. > > And this is just one reason Linux on the desktop is a million miles from Mac > and Windows. your right we should all be using pcbsd much better, http://pcbsd.org/ > >> well java is not good enough if you want a native look, you need C/C++ >> and binding that java uses. And why should Luke be a martyr and pay >> the price in his personal time/life for something that should be fun. > > a) SWT is not martydom, and is a lot better than Swing for a native L&F > b) Luke asked for opinions. > >> Also please keep in mind that "Better" is a good target and generally >> much more achievable then superlative. Shipped is also a wonderful >> thing. Better and shipped are really cool. And if you keep shipping >> better thing you get to superlative. > > Not if your toolkit (Swing) places an upper bound on the quality of your app. native integration is not quality, quality is quality native integration is look and feel. marc -- Freedom is nothing but a chance to be better. --Albert Camus The problem with socialism is that eventually you run out of other people's money. --Margaret Thatcher -- 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
On 31/05/2010, at 11:13 AM, Marc Spitzer wrote: > I actually primarily do not care about mac or windows, personally or > professionally. Also keep in mind that one of the selling points of > clojure is that it runs where *Java* runs not mac and windows, I would > think that in my mind anyway, be a strong contributing point. Now to > be honest I am responsible for Macs at work but hopefully less of them > as time goes by. This is obviously another input into Luke's decision making. What kind of apps does he want to target, what kind of developers, what platforms, with what intentions. > Have you ever heard of DLL HELL? It is a special case of library path > issues, they exist every where you have shared libs/DLLS being loaded. That only happens if you try to share the DLL, which isn't necessary. > And as a sysadmin I have had LD issues with OSX. Consumer apps using SWT don't have this problem on OSX. > your right we should all be using pcbsd much better, http://pcbsd.org/ LOL. > native integration is not quality, quality is quality native > integration is look and feel. which is an essential part of quality from a user's perspective for the two consumer desktop platforms. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The project was so plagued by politics and ego that when the engineers requested technical oversight, our manager hired a psychologist instead. -- Ron Avitzur -- 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: review the clojure.string code
Type-hinting args as a CharSequence is a GoodThing; type-hinting that you're returning a CharSequence when you're actually returning a String is not. I disagree with Steven that some functions should return the StringBuilder instance due to being type-hinted as CharSequence. CharSequence is barely a step above being a marker interface, useful only insofar as calling .toString() is likely to be useful (which is precisely what StringBuilder's constructor does anyway). Further, any purported performance benefit from getting the mutable object back is lost if/when it is passed to another clojure.string function since the very first usage of a CharSequence is always to call .toString() on it. I'd go the other way and document functions as returning a String, and type-hinting them as such. This also has practical effects: user=> (defn ^CharSequence reverse [^CharSequence s] (.toString (.reverse (StringBuilder. s user=> (set! *warn-on-reflection* true) true user=> (.substring (reverse "hello") 3) Reflection warning, NO_SOURCE_PATH:7 - call to substring can't be resolved. "eh" user=> (defn ^String reverse [^CharSequence s] (.toString (.reverse (StringBuilder. s #'user/reverse user=> (.substring (reverse "hello") 3) "eh" As for the concern about data copying, there are reasonable optimizations already in place such that the String returned from StringBuilder.toString() is likely to be created with the same char array instance; no copying needed. As for the use of StringBuffer, it appears that they are used solely when dealing with regex, since that API requires them. On May 30, 3:45 pm, "Steven E. Harris" wrote: > Why do some of the functions use StringBuilder (no internal > synchronization) and some use StringBuffer (provides internal > synchronization). Using the latter is probably a mistake. > > The first function -- reverse -- uses StringBuilder#reverse() to reverse > the character sequence in place, and then calls StringBuilder#toString() > to yield a String. Why is the final step necessary? Since StringBuilder > implements CharSequence, isn't it sufficient to just return the > StringBuilder? That's what the function signature promises. Calling > toString() makes yet another copy of the data, so it's best avoided. > > Some of these functions construct instances of class StringBuilder using > its default constructor, which gives it a default capacity. But most of > the functions also know at the outset some reasonable size for the > buffer. For instance, function `replace-first-by' could reasonably use > the length of its argument "s" as the size of the buffer, even though > the replacement for some matched substring may increase the overall > length. > > Why does function `replace-first' unconditional call > CharSequence#toString() on its argument "s", when in several cases just > using "s" as a CharSequence would be fine. Again, calling > CharSequence#toString() might make a copy of the data, depending on > whether the CharSequence was actually a String or something like a > StringBuilder. > > The implementation of a function like `trim' could be more efficient, > given that it's allowed to return a CharSequence. You can construct a > StringBuilder of length equal to the source CharSequence, then walk the > source sequence from the beginning, skipping over all whitespace, > copying the non-whitespace characters, repeating until you hit the end > of the source string. The "right trim" behavior is a little tricky, as > you have to suspend the copying upon encountering whitespace, but but > back up and copy that whitespace upon encountering something else before > the end of the source string. Alternately, just walk backward from the > end of the source string. > > The bonus is that you only copy the data once. With the current > implementation, calling CharSequence#toString() might copy the data > once, and calling String#trim() will copy it again. > > Rounding out the review, function `trim-newline' doesn't have to call > toString() on the CharSequence yielded by CharSequence#subSequence(), as > it already promises to return a CharSequence. > > Most Java code poisons its string manipulation efficiency by always > promising to return String rather than CharSequence. You've done better > in your signatures here, so I'm just encouraging you to avoid String and > the extra copies it forces. > > -- > Steven E. Harris -- 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: Rationals, and their size
Ratio doesn't emit the numerator and denominator: http://github.com/richhickey/clojure/blob/master/src/jvm/clojure/lang/Ratio.java I'm not sure that would help solve your problem, even if it were available. You either need to turn the ratio into a non-ratio (using float or double) or use unchecked math functions which are subject to truncation (e.g., unchecked-multiply). On May 30, 1:32 pm, alux wrote: > Hello, > > I careless used rationals in a function, and, well, it took some > minutes to understand why it was slowing down. (I did this formatting > by (println (* 1.0 x)) when it started being unreadable - and forgot > that). > > I still see rationals as very nice, but try to use them carefully now. > What I would really like is a possibility to round to a numer of a > certain size. Like, to an continued fraction of a certain size. But, > there I need access to the length of numerator and denominator. > > Now the question - is there any way to access this (or to reach to > goal of rounding to a rational), that is easier than using the > BigIntegers myself? > > Thank you, alux -- 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: special forms and let binding
On May 30, 12:45 pm, alux wrote: > Hi A., > > I dont completely understand what you refer to with "works correct". > > You define a local variable, named do, and use it. That works of > course. Btw you may use it without the call to var > (def do println) > (do "example") It only appears to "work"; the second line is still using the special form. You can see this more clearly here: user=> (def if println) #'user/if user=> (if "hi") java.lang.Exception: Too few arguments to if (NO_SOURCE_FILE:22) user=> ((var if) "hi") hi nil The "hi" is from the println function, the "nil" is what was returned from the call. -- 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
Multithreading didn't make my program as much faster as I expected...
I've written a small simulation program, in order to help me learn Clojure. I've reproduced it below. It's quite likely not very idiomatic - any suggestions on how to improve it would be nice. However, my main concern is that it doesn't seem to scale as I would expect when multi-threading. The simulation is a simple test of rolling 3 6-sided dice 1,000,000 times. It uses Sean Luke's Java implementation of the Mersenne Twister RNG. I'm using the fast (non-threadsafe) version, which is why I'm using a separate MT instance in each thread. The non-threaded version takes about 18 seconds to run, with CPU showing at about 50% throughout (on my dual-core PC). The threaded version shows CPU maxed out at 100%, but still takes 12 seconds to run. That's not a bad speedup, but it still implies there's about a 33% overhead for multithreading. Are these plausible sorts of figures to see? Or should I be able to get extra performance by tricks I haven't thought of? Thanks, Paul. (use 'clojure.contrib.accumulators) (defn D [mt n m] (apply + (take n (repeatedly #(+ 1 (.nextInt mt m)) (defn histogram [s] (add-items empty-counter s)) (defn testN [count n m] (let [mt (ec.util.MersenneTwisterFast.)] (histogram (take count (repeatedly #(D mt n m)) (time (pr (testN 100 3 6))) (time (pr (apply combine (pmap #(testN % 3 6) (repeat 100 1) (shutdown-agents) -- 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: review the clojure.string code
Also, according to Merriam-Webster, uppercase and lowercase don't have hyphens in them. RJ On May 30, 3:49 pm, Stuart Halloway wrote: > I have been working on a branch [1] and haven't updated the ticket yet [2]. > Given the number of diverse (and sometimes opposite!) opinions already > expressed on this topic, I thought a little extra community review would be > in order. David and I organized the work into several fairly small commits so > you can grab the branch and see the individual decisions being made. > > Thanks! > Stu > > [1]http://github.com/stuarthalloway/clojure/tree/string > [2]https://www.assembla.com/spaces/clojure/tickets/359-promote-contrib-s... -- 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: review the clojure.string code
Thanks! Trying to pass through non-strings was overreaching. Ease of use first: the API should return immutable strings. If you really need to optimize more than this, roll your own. Stu > Type-hinting args as a CharSequence is a GoodThing; type-hinting that > you're returning a CharSequence when you're actually returning a > String is not. > > I disagree with Steven that some functions should return the > StringBuilder instance due to being type-hinted as CharSequence. > CharSequence is barely a step above being a marker interface, useful > only insofar as calling .toString() is likely to be useful (which is > precisely what StringBuilder's constructor does anyway). Further, any > purported performance benefit from getting the mutable object back is > lost if/when it is passed to another clojure.string function since the > very first usage of a CharSequence is always to call .toString() on > it. > > I'd go the other way and document functions as returning a String, and > type-hinting them as such. This also has practical effects: > > user=> (defn ^CharSequence reverse > [^CharSequence s] > (.toString (.reverse (StringBuilder. s > user=> (set! *warn-on-reflection* true) > true > user=> (.substring (reverse "hello") 3) > Reflection warning, NO_SOURCE_PATH:7 - call to substring can't be > resolved. > "eh" > user=> (defn ^String reverse > [^CharSequence s] > (.toString (.reverse (StringBuilder. s > #'user/reverse > user=> (.substring (reverse "hello") 3) > "eh" > > As for the concern about data copying, there are reasonable > optimizations already in place such that the String returned from > StringBuilder.toString() is likely to be created with the same char > array instance; no copying needed. > > As for the use of StringBuffer, it appears that they are used solely > when dealing with regex, since that API requires them. > > > On May 30, 3:45 pm, "Steven E. Harris" wrote: >> Why do some of the functions use StringBuilder (no internal >> synchronization) and some use StringBuffer (provides internal >> synchronization). Using the latter is probably a mistake. >> >> The first function -- reverse -- uses StringBuilder#reverse() to reverse >> the character sequence in place, and then calls StringBuilder#toString() >> to yield a String. Why is the final step necessary? Since StringBuilder >> implements CharSequence, isn't it sufficient to just return the >> StringBuilder? That's what the function signature promises. Calling >> toString() makes yet another copy of the data, so it's best avoided. >> >> Some of these functions construct instances of class StringBuilder using >> its default constructor, which gives it a default capacity. But most of >> the functions also know at the outset some reasonable size for the >> buffer. For instance, function `replace-first-by' could reasonably use >> the length of its argument "s" as the size of the buffer, even though >> the replacement for some matched substring may increase the overall >> length. >> >> Why does function `replace-first' unconditional call >> CharSequence#toString() on its argument "s", when in several cases just >> using "s" as a CharSequence would be fine. Again, calling >> CharSequence#toString() might make a copy of the data, depending on >> whether the CharSequence was actually a String or something like a >> StringBuilder. >> >> The implementation of a function like `trim' could be more efficient, >> given that it's allowed to return a CharSequence. You can construct a >> StringBuilder of length equal to the source CharSequence, then walk the >> source sequence from the beginning, skipping over all whitespace, >> copying the non-whitespace characters, repeating until you hit the end >> of the source string. The "right trim" behavior is a little tricky, as >> you have to suspend the copying upon encountering whitespace, but but >> back up and copy that whitespace upon encountering something else before >> the end of the source string. Alternately, just walk backward from the >> end of the source string. >> >> The bonus is that you only copy the data once. With the current >> implementation, calling CharSequence#toString() might copy the data >> once, and calling String#trim() will copy it again. >> >> Rounding out the review, function `trim-newline' doesn't have to call >> toString() on the CharSequence yielded by CharSequence#subSequence(), as >> it already promises to return a CharSequence. >> >> Most Java code poisons its string manipulation efficiency by always >> promising to return String rather than CharSequence. You've done better >> in your signatures here, so I'm just encouraging you to avoid String and >> the extra copies it forces. >> >> -- >> Steven E. Harris > > -- > 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 >
Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
Antony Blakey wrote .. > > On 31/05/2010, at 11:13 AM, Marc Spitzer wrote: > > > I actually primarily do not care about mac or windows, personally or > > professionally. Also keep in mind that one of the selling points of > > clojure is that it runs where *Java* runs not mac and windows, I would > > think that in my mind anyway, be a strong contributing point. Now to > > be honest I am responsible for Macs at work but hopefully less of them > > as time goes by. > > This is obviously another input into Luke's decision making. What kind of apps > does he want to target, what kind of developers, what platforms, with what intentions. Vast survey indeed... how should we find the "real" numbers ? Any suggestion is welcomed but I doubt we can find a core group of developers that will "win" this survey. > > > Have you ever heard of DLL HELL? It is a special case of library path > > issues, they exist every where you have shared libs/DLLS being loaded. > > That only happens if you try to share the DLL, which isn't necessary. Yep but then you need to ship the DLLs (and any other native implementations for the various platforms) with a synced version of the wrapper. Of course the native libraries may vary according to the platorm/maintenance releases, ... > > > And as a sysadmin I have had LD issues with OSX. > > Consumer apps using SWT don't have this problem on OSX. > So should we expect problems in other OSes ? What about testing then ? Do we multiply the number of test suites to run by the number of platforms we support multiplied by the different versions of SWT ? Maybe we should include the captain's age in the equation above... Wow, vast test program. How many man/years to get wrappers around SWT tested with a sufficient number of implementations and how can we keep up with future versions coming in (multiplied by the number of platforms, ...) > > your right we should all be using pcbsd much better, http://pcbsd.org/ > > LOL. > > > native integration is not quality, quality is quality native > > integration is look and feel. > > which is an essential part of quality from a user's perspective for the two consumer > desktop platforms. Not true, we ship Swing based apps on different platforms and the value has never been the "look" but what they allow users to achieve. The single look and feel (aka uniformity) is welcomed by users, some of them are switching regurlaly between Windows and Macs. Were not in the cosmetics business however so we speak for our business (cross-platform, cross-language, cross-) A menu bar is a menu bar... Even if I rarely use Windows, I'm not freaking because the widgets are not "the same" as my usual desktop. I hate Microsoft for the number of changes they make from version to version because they move stuff around, not because they changed the look and feel of individual apps. That's why I often start apps from command line instead of digging endlessly in the startup menu. I can even get myself around on a MAC without pain. Swing is a much more logical choice effort wise. Of course we may start a Clojure-GUI group eventually but that is premature.. if worthwhile at all. Luc P. > > Antony Blakey > -- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > The project was so plagued by politics and ego that when the engineers > requested > technical oversight, our manager hired a psychologist instead. > -- Ron Avitzur > > -- > 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
On Mon, 31 May 2010 10:53:45 +0930 Antony Blakey wrote: > > On 31/05/2010, at 10:44 AM, Marc Spitzer wrote: > > also lets not forget about LD_LIBRARY_PATH issues, > No Mac or Windows user would encounter these. You forget that the Mac is a Unix box. It supports LD_LIBRARY_PATH. In an ideal world - where every developer did things right - you'd never need it on any system. We don't live in such a world. In particular, OSX tends to ship with obsolete versions of *very* popular Unix libraries. So much so that you wind up having to choose between building obsolete versions of the tools you want, losing valuable features and bug fixes; or building current versions of libraries in the system, leading to having to make sure your code and only your code finds it - even when you're dynamically loading frameworks that want to use the system version of the same library. On Windows, the problem is so common it's been given the name "DLL hell". 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: review the clojure.string code
Steven, thanks for the detailed feedback! Responses inline: > Why do some of the functions use StringBuilder (no internal > synchronization) and some use StringBuffer (provides internal > synchronization). Using the latter is probably a mistake. Stuck with this thanks to the Java API: .appendReplacement and .appendTail *require* a StringBuffer. :-( > The first function -- reverse -- uses StringBuilder#reverse() to reverse > the character sequence in place, and then calls StringBuilder#toString() > to yield a String. Why is the final step necessary? Since StringBuilder > implements CharSequence, isn't it sufficient to just return the > StringBuilder? That's what the function signature promises. Calling > toString() makes yet another copy of the data, so it's best avoided. Switching to returning String everywhere (see feedback from ataggart). > Some of these functions construct instances of class StringBuilder using > its default constructor, which gives it a default capacity. But most of > the functions also know at the outset some reasonable size for the > buffer. For instance, function `replace-first-by' could reasonably use > the length of its argument "s" as the size of the buffer, even though > the replacement for some matched substring may increase the overall > length. Saw this in one place (on a StringBuffer): agreed and fixed. > Why does function `replace-first' unconditional call > CharSequence#toString() on its argument "s", when in several cases just > using "s" as a CharSequence would be fine. Again, calling > CharSequence#toString() might make a copy of the data, depending on > whether the CharSequence was actually a String or something like a > StringBuilder. Won't work for most of the branches, which depend on String methods. IMO not worth doing for the few cases where it could be done. > The implementation of a function like `trim' could be more efficient, > given that it's allowed to return a CharSequence. You can construct a > StringBuilder of length equal to the source CharSequence, then walk the > source sequence from the beginning, skipping over all whitespace, > copying the non-whitespace characters, repeating until you hit the end > of the source string. The "right trim" behavior is a little tricky, as > you have to suspend the copying upon encountering whitespace, but but > back up and copy that whitespace upon encountering something else before > the end of the source string. Alternately, just walk backward from the > end of the source string. > > The bonus is that you only copy the data once. With the current > implementation, calling CharSequence#toString() might copy the data > once, and calling String#trim() will copy it again. > > Rounding out the review, function `trim-newline' doesn't have to call > toString() on the CharSequence yielded by CharSequence#subSequence(), as > it already promises to return a CharSequence. The Java String methods are already smarter than this, and avoid naive unnecessary copying. Moreover, subSequence on StringBuilder already returns a String, so the copying damage is already done. Stu -- 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
Mike Meyer wrote .. > On Mon, 31 May 2010 10:53:45 +0930 > Antony Blakey wrote: > > > > > On 31/05/2010, at 10:44 AM, Marc Spitzer wrote: > > > also lets not forget about LD_LIBRARY_PATH issues, > > No Mac or Windows user would encounter these. > > You forget that the Mac is a Unix box. It supports LD_LIBRARY_PATH. In > an ideal world - where every developer did things right - you'd never > need it on any system. We don't live in such a world. In particular, > OSX tends to ship with obsolete versions of *very* popular Unix > libraries. So much so that you wind up having to choose between > building obsolete versions of the tools you want, losing valuable > features and bug fixes; or building current versions of libraries in > the system, leading to having to make sure your code and only your > code finds it - even when you're dynamically loading frameworks that > want to use the system version of the same library. > > On Windows, the problem is so common it's been given the name "DLL > hell". > > -- Mike makes a good point here. We had an Xserve for 7/8 years and one thing we found frustrating was the lack of updates for open source tools and how the next Apple release would zap the ones we made ourselves in between. It finally died last November and we were happy to replace it with an Ubuntu server box were we can control what is updated and when. As for the DLL hell, try to get an app. deployed to desktops through a central IT controlled process. Even if you do not intend to share DLLs, you will have a lot of explanations to give if your package contains a few... I went through this several times. 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: review the clojure.string code
But they can be separate words, and Java treats them so (.toUpperCase, .toLowerCase). Stu > Also, according to Merriam-Webster, uppercase and lowercase don't have > hyphens in them. > > RJ > > On May 30, 3:49 pm, Stuart Halloway wrote: >> I have been working on a branch [1] and haven't updated the ticket yet [2]. >> Given the number of diverse (and sometimes opposite!) opinions already >> expressed on this topic, I thought a little extra community review would be >> in order. David and I organized the work into several fairly small commits >> so you can grab the branch and see the individual decisions being made. >> >> Thanks! >> Stu >> >> [1]http://github.com/stuarthalloway/clojure/tree/string >> [2]https://www.assembla.com/spaces/clojure/tickets/359-promote-contrib-s... > > -- > 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
On 31/05/2010, at 12:31 PM, Mike Meyer wrote: > On Mon, 31 May 2010 10:53:45 +0930 > Antony Blakey wrote: > >> >> On 31/05/2010, at 10:44 AM, Marc Spitzer wrote: >>> also lets not forget about LD_LIBRARY_PATH issues, >> No Mac or Windows user would encounter these. > > You forget that the Mac is a Unix box. It supports LD_LIBRARY_PATH. In > an ideal world - where every developer did things right - you'd never > need it on any system. We don't live in such a world. In particular, > OSX tends to ship with obsolete versions of *very* popular Unix > libraries. So much so that you wind up having to choose between > building obsolete versions of the tools you want, losing valuable > features and bug fixes; or building current versions of libraries in > the system, leading to having to make sure your code and only your > code finds it - even when you're dynamically loading frameworks that > want to use the system version of the same library. > > On Windows, the problem is so common it's been given the name "DLL > hell". I build installers that include chains of co-dependent base libraries with isolating setups (programatically mutated binary and load paths) for multiple platforms, so I know about this issue, but I'm talking specifically about SWT which doesn't suffer from that problem. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Hi, I'd like to do $THING. I know that $SOLUTION_A and $SOLUTION_B will do it very easily and for a very reasonable price, but I don't want to use $SOLUTION_A or $SOLUTION_B because $VAGUE_REASON and $CONTRADICTORY_REASON. Instead, I'd like your under-informed ideas on how to achieve my $POORLY_CONCEIVED_AMBITIONS using Linux, duct tape, an iPod, and hours and hours of my precious time. -- Slashdot response to an enquiry -- 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
I doubt this subthread is of any use to the OP at this point. On 31/05/2010, at 12:31 PM, lprefonta...@softaddicts.ca wrote: > Any suggestion is welcomed but I doubt we can find a core group of > developers that will "win" this survey. It's a survey group of 1 i.e. what are *his* responses to those questions. > Yep but then you need to ship the DLLs (and any other native implementations > for > the various platforms) with a synced version of the wrapper. > Of course the native libraries may vary according to the platorm/maintenance > releases, ... And yet, somehow, commercial software is produced ... > So should we expect problems in other OSes ? What about testing then ? > Do we multiply the number of test suites to run by the number of platforms > we support multiplied by the different versions of SWT ? No, you treat SWT as a black box as regards testing. It has it's own test regime and cross-platform validation. > Were not in the cosmetics business however so we speak for our business > (cross-platform, cross-language, cross-) You are begging the question then. Antony Blakey -- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt. -- Bertrand Russell -- 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 script with shebangoid on windows
On 31 May 2010 04:51, Paul Moore wrote:
> On 30 May 2010 12:31, alux wrote:
> > Small addition, you missed to add the : before eof
> >
> > replace "goto eof" by "goto :eof"
>
> Thanks, good catch. ("goto eof" without the colon works on TCC, which
> I normally use as my command shell).
>
>
I noticed it seemed to have problems when trying to use an absolute path to
reference clojure.jar.
java -cp d:\products\clojure\clojure.jar clojure.main "%~f0" %*
Using forward slashes instead seemed to do the trick.
--
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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
Antony Blakey wrote .. > I doubt this subthread is of any use to the OP at this point. I run a software business, I generally look at product decisions in terms of cost/benefits from end to end over time not just looking solely at a specific item and specific time frame. > > On 31/05/2010, at 12:31 PM, lprefonta...@softaddicts.ca wrote: > > > Any suggestion is welcomed but I doubt we can find a core group of > > developers that will "win" this survey. > > It's a survey group of 1 i.e. what are *his* responses to those questions. Two alternatives seem to gather some support, Swing and SWT. Now what are the cost/benefits of choosing SWT ? > > > Yep but then you need to ship the DLLs (and any other native implementations > for > > the various platforms) with a synced version of the wrapper. > > Of course the native libraries may vary according to the platorm/maintenance > > releases, ... > > And yet, somehow, commercial software is produced ... Maybe but does it have to be more painful and complex than necessary ? What value brings SWT ? a) Performance ? Maybe a few years ago but presently Swing and SWT are similar in terms of performance in general. b) Swing is bundled in the JRE, SWT is not. This means some extra work somehow. c) Cosmetic aspect ? SWT "wins" for its ability to look like other apps on a given platform. Swing offers a uniform look and feel. So the only "feature" offered by SWT if I follow your point is c). At what cost ? > > > So should we expect problems in other OSes ? What about testing then ? > > Do we multiply the number of test suites to run by the number of platforms > > we support multiplied by the different versions of SWT ? > > No, you treat SWT as a black box as regards testing. It has it's own test > regime > and cross-platform validation. Impacts on testing/deployment: a) Black boxes are good until top layers get hit. You still need to manage dependencies between the top wrapper and the bottom layers. Swing has a major advantage here. No native wrappers, no need for a complex installation process or per platform dependency management. b) No test completed = not a product yet. You have to test before delivering anything to a desktop and that includes all the variants you intend to support. Swing is the same everywhere so the occurrences of GUI related problems are reduced. SWT opens the gate to potential problems since it is implemented in different components depending on the platform. Swing wins here. c) Building/packaging/maintaning variants for every desktop type supported is significant work. Swing wins here. d) I do not see writing installers has being a mundane and funny task. Having to write per desktop variant installers is another drawback of SWT. Delivering a single jar on all platforms is a big bonus. Complex installers have to be tested themselves, there subject to the same problems as any piece of software whatever good the tool you use maybe. Another level of complexity Swing wins here. Back to "why does producing software has to be more painful than necessary" and "what value brings SWT overall". > > > Were not in the cosmetics business however so we speak for our business > > (cross-platform, cross-language, cross-) > > You are begging the question then. Swing has prove itself up to know (and improved a lot), why get entangled in a complex process with all the above ramifications ? Simplicity as some value. You should meditate a bit on this. Luc P. > > Antony Blakey > -- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > The trouble with the world is that the stupid are cocksure and the intelligent > are full of doubt. > -- Bertrand Russell > > > -- > 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
On 31/05/2010, at 2:04 PM, lprefonta...@softaddicts.ca wrote: > Two alternatives seem to gather some support, Swing and SWT. Now what are > the > cost/benefits of choosing SWT ? See below. > What value brings SWT ? > > a) Performance ? Maybe a few years ago but presently > Swing and SWT are similar in terms of performance in general. Not my experience, but YMMV, and in any case not the deciding factor for me. > c) Cosmetic aspect ? SWT "wins" for its ability to look like other apps > on a given platform. Swing offers a uniform look and feel. > > So the only "feature" offered by SWT if I follow your point is c). > At what cost ? Well, I'd argue that it's more than cosmetic, which I take you to mean pejoratively. In fact I place an enormous value on this point, for what seems to me to be a slight cost (and the major one is manual management of resource lifetime, not deployment). > Back to "why does producing software has to be more painful than necessary" > and "what value brings SWT overall". I guess we just differ in our assessment of 'necessary' and 'value' in this paragraph. > >> >>> Were not in the cosmetics business however so we speak for our business >>> (cross-platform, cross-language, cross-) >> >> You are begging the question then. > > Swing has prove itself up to know (and improved a lot), why get entangled > in a complex process with all the above ramifications ? > > Simplicity as some value. You should meditate a bit on this. I'm a big fan of simplicity. However there are two sayings that come to mind: 1. Make everything as simple as possible, but not simpler. (Albert Einstein) 2. For every complex problem, there is an answer that is clear, simple - and wrong (H. L. Mencken). Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away. -- Antoine de Saint-Exupery -- 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
On May 30, 9:23 pm, Antony Blakey wrote: > I care about Mac and Windows primarily, and building software that will sell > (not dev tools) requires good native look and feel. Do you have a single example of an SWT app that has a decent feel on OS X? I've spent a fair amount of time with Eclipse lately, and--- frankly---it feels about as native as an Alabaman in Nice. No native toolbar, no native tabs, slower and uglier than either Netbeans or Intellij. My only other experience with an SWT app was entirely negative from a performance and look-and-feel perspective (Vuze). SWT sounded nice a few years ago, but in my opinion it never lived up to its promise. If you want native GUIs there is no alternative to using platform-specific toolkits; for cross-platform work SWT has nothing on Swing. > Antony Blakey Best, James -- 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: Multithreading didn't make my program as much faster as I expected...
The trouble with pmap is that it only works well with a slow function and a short sequence. In trivial tests, it seems to be best if the sequence has as many elements as you do cores. I've been experimenting with things that are like pmap, but work better in situations that I care about. I'm having trouble getting full performance out of a quad-core machine, but dual-core is working pretty well so far. Here's some discussion with a link to sample code: http://groups.google.com/group/clojure/browse_thread/thread/963cdb76f0c3c178 And here's my personal utility file containing mostly re- implementations of things I didn't know where to find. The zpmap function is an eager parallel map that works well on large vectors and maps with a fairly fast function: http://github.com/zakwilson/zutil-clj/blob/master/util.clj -- 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: Datatype Usage Examples
Hi Meikel, Meikel Brandmeyer wrote: > Am 30.05.2010 um 16:39 schrieb Sina K. Heshmati: > >> [2] >> http://github.com/sindoc/algorithms/blob/master/src/test/clojure/whiteboard/y2010/hide-adt-state-using-closure.clj > > I'm almost sure, that this code does not what you expect. Nested def's, and > in > particular defn's, are almost surely wrong. You want: > > (defn make-module > [] > (let [state (atom 0) > say-hello (fn [] (println "Hello")) > public-op (fn [x y] (+ @state x y))] > (fn [op] > (case op > :hello say-hello > :public public-op Could you elaborate a bit please? Is there a reason why nested defns are wrong? > And I'm not sure with what you mean by "you are not allowed to change the > root of > a Var". Of course you can do that. I referred to the fact that we can't do as follows: > (def x 10) > (set! x (* x x)) It should be possible to achieve the exact same effect using some other means but not as a result of evaluating the two expressions above. > (declare x) > (defn fn-using-x ...) > (def x 5) > > The declare is also (more or less) equivalent to (def x nil). (declare symbol) seems to work [3]. I'll later try it with deftypes to see if I can also export datatypes since my method as in [2] failed to export datatypes. Thank you Meikel. Kind regards, SinDoc [3] http://gist.github.com/419568 -- 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
On 31/05/2010, at 2:27 PM, James Cunningham wrote: > > > On May 30, 9:23 pm, Antony Blakey wrote: >> I care about Mac and Windows primarily, and building software that will sell >> (not dev tools) requires good native look and feel. > > Do you have a single example of an SWT app that has a decent feel on > OS X? I've spent a fair amount of time with Eclipse lately, and--- > frankly---it feels about as native as an Alabaman in Nice. No native > toolbar, no native tabs, slower and uglier than either Netbeans or > Intellij. My only other experience with an SWT app was entirely > negative from a performance and look-and-feel perspective (Vuze). Vuze looks OK to me in the 5 minutes I've just spent. In any case, my opinion comes from doing parallel GUI development in IB and SWT to see if I could use Clojure/SWT rather than MacRuby (XCode/IB). I'm not using the RCP which imprints it's own not-really-OSX flavour in spite of the widgets. You have to do more than just use SWT to get a Mac application to feel right, and one's GUI layout code needs to be parametric and rules based, rather than just swapping the L&F. That said, it's still easier than writing three UIs. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 The intuitive mind is a sacred gift and the rational mind is a faithful servant. We have created a society that honours the servant and has forgotten the gift. -- Albert Einstein -- 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 script with shebangoid on windows
Ah!
Hello Glen, good hint. Problem and solution reproduced ;-)
Thank you,
greetings, alux
On 31 Mai, 06:00, Glen Stampoultzis wrote:
> On 31 May 2010 04:51, Paul Moore wrote:
>
> > On 30 May 2010 12:31, alux wrote:
> > > Small addition, you missed to add the : before eof
>
> > > replace "goto eof" by "goto :eof"
>
> > Thanks, good catch. ("goto eof" without the colon works on TCC, which
> > I normally use as my command shell).
>
> I noticed it seemed to have problems when trying to use an absolute path to
> reference clojure.jar.
>
> java -cp d:\products\clojure\clojure.jar clojure.main "%~f0" %*
>
> Using forward slashes instead seemed to do the trick.
--
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: special forms and let binding
Hello ataggart, thank you for the correction! Only now I understand A.Rosts question. May be somebody can help, and explain why my hypothesis was wrong. Obviousely, while functions are first class, special forms are even "better", kind of zeroth class. Thank you, alux On 31 Mai, 04:15, ataggart wrote: > On May 30, 12:45 pm, alux wrote: > > > Hi A., > > > I dont completely understand what you refer to with "works correct". > > > You define a local variable, named do, and use it. That works of > > course. Btw you may use it without the call to var > > (def do println) > > (do "example") > > It only appears to "work"; the second line is still using the special > form. You can see this more clearly here: > > user=> (def if println) > #'user/if > user=> (if "hi") > java.lang.Exception: Too few arguments to if (NO_SOURCE_FILE:22) > user=> ((var if) "hi") > hi > nil > > The "hi" is from the println function, the "nil" is what was returned > from the call. -- 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
