Re: [ANN] test-runner, a test runner for projects using Clojure Deps
You're very likely correct about shutdown-agents, I don't think I happened to fire up any agents in my test code. I'll try to reproduce as soon as I get a chance. On Tuesday, February 20, 2018 at 11:25:01 AM UTC-5, Eli Naeher wrote: > > I love this, and have set it up in our latest project alongside Lein. > > I've noticed a delay (~60s) after the tests finish and the results are > reported before the process exits. I'm wondering if there's a missing call > to shutdown-agents somewhere. Adding it to a shutdown hook doesn't seem to > have any effect. With lein test there is no similar delay. > > Thanks, > -Eli > > > On Fri, Feb 16, 2018, at 9:47 AM, Luke VanderHart wrote: > > The goal is to have a full featured, standardized test runner on a project > using basic Clojure Deps, without needing to introduce Boot or Leiningen > just for that. > > https://github.com/cognitect-labs/test-runner > > Feedback, bugfixes and PRs welcome. > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] test-runner, a test runner for projects using Clojure Deps
The goal is to have a full featured, standardized test runner on a project using basic Clojure Deps, without needing to introduce Boot or Leiningen just for that. https://github.com/cognitect-labs/test-runner Feedback, bugfixes and PRs welcome. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[ANN] Arachne, a new rapid web development framework for Clojure
Just realized I forgot to post about this here, which is kind of important. :) It is still under development - I am raising funds via Kickstarter in order to get the opportunity to work on it full time and make sure it gets off to a really solid start. It's a pretty ambitious project, but I've had some amazing minds generously agree to help me think through it at the high level. I'm optimistic that not only can we bring Clojure up to par with other language/framework stacks out there, but advance the state of the art in web development as a whole. The steering and advisory group consists of: - Tim Ewald - Jamie Kite - David Nolen - Mike Nygard - Russ Olsen - Nola Stowe - Stuart Sierra Check it out, and please consider donating if you have the resources to do so: https://www.kickstarter.com/projects/1346708779/arachne-rapid-web-development-for-clojure Thanks! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Feature expressions demo
In case anyone is interested in venturing beyond the bleeding edge and trying out the current state of feature expressions, I have created forks of the relevant repositories with the patches applied, and put together a minimal hello-world repository. https://github.com/levand/fx-hello-world 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: New release of Domina (now with reworked eventing)
David, Yes. I've been looking at that today. Something is going on that is not so straightforward, though - I think there might be a compiler issue (or else I'm misunderstanding some aspect of the compiler). For example, I'm getting the warning on compiler-generated vars. e.g: WARNING: Use of undeclared Var domina.css/t7256 at line 14 Still investigating (though if you happen to know what's going on, please let me know) On Friday, April 27, 2012 3:26:43 PM UTC-4, David Nolen wrote: lein-cljsbuild is now becoming the tool of choice for many CLJS devs. One thing I've noticed about domina is that it's not particularly careful about declaration order. This results in a spew of compiler warnings when building your project with domina. It would be nice to sprinkle the code with the necessary declares to eliminate these warnings. David On Fri, Apr 27, 2012 at 10:47 AM, Luke VanderHart wrote: Some of you may already be aware of of Domina, a jQuery-inspired DOM manipulation library I've been working on. It's been out there for a while, but I just finished up a round of changes that I think bring it to a certain degree of completion for basic use (although there's definitely a lot of cool stuff that still remains to be added). Most notable is a new set of eventing functions; I hope they'll provide an easy-to-use, low-level foundation for building more complex data- and event-driven web applications. Please check it out: https://github.com/levand/domina/ Feedback, pull request, etc. are welcome. 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: New release of Domina (now with reworked eventing)
Yep, still happens against master. Trying to reduce it to a simpler test case now (and also see if it still happens when I take lein-cljsbuild out of the equation). On Saturday, April 28, 2012 1:29:07 PM UTC-4, David Nolen wrote: Which version of ClojurScript? Have you tried building against master? David On Sat, Apr 28, 2012 at 1:19 PM, Luke VanderHart luke.vanderh...@gmail.com wrote: David, Yes. I've been looking at that today. Something is going on that is not so straightforward, though - I think there might be a compiler issue (or else I'm misunderstanding some aspect of the compiler). For example, I'm getting the warning on compiler-generated vars. e.g: WARNING: Use of undeclared Var domina.css/t7256 at line 14 Still investigating (though if you happen to know what's going on, please let me know) On Friday, April 27, 2012 3:26:43 PM UTC-4, David Nolen wrote: lein-cljsbuild is now becoming the tool of choice for many CLJS devs. One thing I've noticed about domina is that it's not particularly careful about declaration order. This results in a spew of compiler warnings when building your project with domina. It would be nice to sprinkle the code with the necessary declares to eliminate these warnings. David On Fri, Apr 27, 2012 at 10:47 AM, Luke VanderHart wrote: Some of you may already be aware of of Domina, a jQuery-inspired DOM manipulation library I've been working on. It's been out there for a while, but I just finished up a round of changes that I think bring it to a certain degree of completion for basic use (although there's definitely a lot of cool stuff that still remains to be added). Most notable is a new set of eventing functions; I hope they'll provide an easy-to-use, low-level foundation for building more complex data- and event-driven web applications. Please check it out: https://github.com/levand/**domina/https://github.com/levand/domina/ Feedback, pull request, etc. are welcome. 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+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/**group/clojure?hl=enhttp://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 -- 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
New release of Domina (now with reworked eventing)
Some of you may already be aware of of Domina, a jQuery-inspired DOM manipulation library I've been working on. It's been out there for a while, but I just finished up a round of changes that I think bring it to a certain degree of completion for basic use (although there's definitely a lot of cool stuff that still remains to be added). Most notable is a new set of eventing functions; I hope they'll provide an easy-to-use, low-level foundation for building more complex data- and event-driven web applications. Please check it out: https://github.com/levand/domina/ Feedback, pull request, etc. are welcome. 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
Re: Bug recognizing tail position as default value in maps?
Using a map instead of if means that it is evaluated as a function call.
Unlike the if form, function calls eval their arguments. So the (recur)
form is getting eval'd prior to being passed to the map/function, which
isn't a tail position.
That's why if is a special form/macro, not a regular function (like maps
are).
On Friday, April 27, 2012 10:52:10 AM UTC-4, Dominikus wrote:
Sure? The semantics of the default value corresponds to a 'if', doesn't
it? From this viewpoint, the default value is in tail position. And why
does the non-tailrecursive version not run as expected?
Dominikus
Am Freitag, 27. April 2012 16:45:44 UTC+2 schrieb Meikel Brandmeyer
(kotarak):
Hi,
(defn fix2 [f x] (let [v (f x)] ({x x} v (recur f v
recur is not in the tail position. The call to the map is the tail
call. So the result is as expected.
Kind regards,
Meikel
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Funding 2011?
For what it's worth, I am really glad of the position Rich is taking on a roadmap and Clojure's future development. I would much rather Clojure remained fresh, innovative and agile, and that it continues to offer unexpected, delightful new features and abilities. It can't really do that if Rich has to work through a years worth of mundane improvements he's already committed to before he can implement a new idea. -Luke On Jan 4, 11:45 am, Rich Hickey richhic...@gmail.com wrote: On Jan 4, 2011, at 11:10 AM, Daniel Werner wrote: Hi Rich, On 4 January 2011 06:31, Rich Hickey richhic...@gmail.com wrote: I was going to continue the funding effort, but have decided against it for the reasons given here: Regarding the entitlement [...] as to what I do with my time, I believe I know of one of the discussions that lead you to this conclusion. It seems this discussion originated from a community member's desire for a Clojure roadmap of some sorts, but quickly died from emotional buttons having been pushed. As for me, I too would appreciate a central place to read about the next big things you are working on (apparently dev.clojure.org is in the process of becoming this place), but am excited about the direction Clojure is taking right now and would gladly donate if you decided to accept funding again in the future. The Confluence instance at: http://dev.clojure.org/ is definitely that place and is positively overflowing with design docs and plans. And: http://dev.clojure.org/jira/ lets you follow issues and changes being made. Clojure has never had a roadmap and won't have one any time soon. Things get done when they can get done, given need and people with the inclination, willingness, time and ability to do them (myself included). That has always been the case. It has never been the case that at the beginning of a particular year I could have predicted what would have been the big features developed that year. Some things get hot and get done, while others need more thinking time. I'm comfortable with that and happy with the results. People need to be cautious not to become too infatuated with planning and the ability to see the future than is supportable by an open source project of this size. Rich -- 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: Time/size bounded cache?
I've been working on a simple Clojure library for bounded caching and
memoization. It's not quite ready for prime-time, but the simple case
that you need is usable.
I'll throw it up on github when I get home tonight and post the URL
here.
On Dec 30, 1:35 pm, Miki miki.teb...@gmail.com wrote:
Hello,
I'm wring a service that polls RSS feeds (using feedme). And I'd like to act
only on the new entries in each feed.
So far I have something like:
(defn get-new-entries [seen]
(let [seen? (complement seen)]
(filter #(seen? (:id %)) (get-entries
(defn poll [sleep-time]
(loop [seen #{}]
(let [entries (get-new-entries seen)]
(doall (map process-entry entries))
(println )
(Thread/sleep sleep-time)
(recur (union seen (set (map :id entries)))
(Full demo code athttps://gist.github.com/760094)
The problem is that seen will grow without bounds.
Is there a built in way to have some sort of LRU cache or should I use
external libraries (like plru)?
Thanks,
--
Miki
--
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: ANN: ClojureQL 1.0.0 finally released as public beta
Thanks... I think I do see the benefit. I'll certainly give it a try
and see if I can get the feel of it.
One question... You say it generates optimized SQL. Does it take the
DBMS into account? I know the performance profiles of various SQL
idioms vary widely between MySQL and Oracle, for example - what may be
better as a subselect on one may sometimes be better as a join on
another.
Thanks so much for the detailed answer...
-Luke
On Nov 24, 3:37 am, LauJensen lau.jen...@bestinclass.dk wrote:
Hi Luke,
Thanks!
Initially CQL0.1 was motivated by everything in Clojure which was
the driving design principle behind the first version of CQL. When
I scrapped that project (for reasons you can read on my blog) I
instead turned my attention towards Relational Algebra as this
gives you unique ways to compose and express your queries, in
my opinion far superior to the SQL language itself.
Example from our test suite: Lets say you want to define a table
which computes an aggregate on a column, ex counting pictures
by user id and then join those stats to your users table. In CQL
you will (hopefully) intuitively write:
(let [photo-counts (- (table :photos)
(aggregate [[:count/* :as :cnt]]
[:id])))]
(- (table :users)
(join photo-counts (= {:users.id :photos.id}))
I think thats really as simple as you can express that join operation.
However for the SQL to work/be efficient, you need to detect when
a join benefits from spawning subselects and ClojureQL handles this
for you completely transparently, so if you execute the above
statement
the following is actually generated and run:
SELECT users.*,photos_aggregation.cnt FROM users
LEFT OUTER JOIN
(SELECT photos.user_id,count(photos.*) AS cnt FROM photos GROUP BY
user_id)
AS photos_aggregation ON (users.user_id = photos_aggregation.user_id)
And notice how your reference to :id in photos is automatically
aliased
to photos_aggregation. There are SQL statements which are truely
complex
and it takes a long time to master SQL and get comfortable with such
queries.
It is my ambition that ClojureQL will take away that complexity while
still
generating the most efficient SQL statements possible. The
implications for
Q/A on your projects will be substantial I hope.
And even if I was only doing CRUD - I'd prefer to do it (and have my
developers do it)
in Clojure, which is guaranteed to compile to correct SQL.
Answers your question?
Lau
On Nov 24, 1:56 am, Luke VanderHart luke.vanderh...@gmail.com wrote:
Lau,
This is really impressive, and I can't wait to experiment with it.
That said, I'm curious as to what good use cases for this would be,
and what it's motivation is. SQL is already a highly specialized DSL
for slinging around relational data that most developers are already
pretty good with. I'm wondering how useful it is to have a separate
relational DSL. Is this motivated by the same everything in Clojure
philosophy (like Hiccup or Scriptjure)? Not that there's anything
wrong with that... I'm just curious as to use cases.
Or does it confer some other benefit over SQL besides being Clojure?
The only thing I see is the ability to reuse and compose fragments of
relational logic. Unarguably, that is very cool, but off the top of my
head I can't think of any particular benefit it would give, at least
in my apps. 99% of my database interaction is a fixed set of CRUD
operations, which (unless I'm missing something) would be just as easy
to write in SQL directly.
Thanks,
-Luke
On Nov 18, 2:10 pm, LauJensen lau.jen...@bestinclass.dk wrote:
Hi gents,
For those of you who have followed the development
of ClojureQL over the past 2.5 years you'll be excited
to know that ClojureQL is as of today being released
as 1.0.0 beta1.
That means that the significant primitives from Relational
Algebra are all in place and functional. The documentation
is there and I've even made a screencast in order to get
you guys started.
Personally Im excited about this version because it really
does change the way you work with a database. Queries
are incredibly composable!
For more information, please checkout this blogpost +
screencast:http://bestinclass.dk/index.clj/2010/11/clojureql--1.0.0-now-in-beta
Best regards,
Lau
--
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: ANN: ClojureQL 1.0.0 finally released as public beta
Lau, This is really impressive, and I can't wait to experiment with it. That said, I'm curious as to what good use cases for this would be, and what it's motivation is. SQL is already a highly specialized DSL for slinging around relational data that most developers are already pretty good with. I'm wondering how useful it is to have a separate relational DSL. Is this motivated by the same everything in Clojure philosophy (like Hiccup or Scriptjure)? Not that there's anything wrong with that... I'm just curious as to use cases. Or does it confer some other benefit over SQL besides being Clojure? The only thing I see is the ability to reuse and compose fragments of relational logic. Unarguably, that is very cool, but off the top of my head I can't think of any particular benefit it would give, at least in my apps. 99% of my database interaction is a fixed set of CRUD operations, which (unless I'm missing something) would be just as easy to write in SQL directly. Thanks, -Luke On Nov 18, 2:10 pm, LauJensen lau.jen...@bestinclass.dk wrote: Hi gents, For those of you who have followed the development of ClojureQL over the past 2.5 years you'll be excited to know that ClojureQL is as of today being released as 1.0.0 beta1. That means that the significant primitives from Relational Algebra are all in place and functional. The documentation is there and I've even made a screencast in order to get you guys started. Personally Im excited about this version because it really does change the way you work with a database. Queries are incredibly composable! For more information, please checkout this blogpost + screencast:http://bestinclass.dk/index.clj/2010/11/clojureql--1.0.0-now-in-beta Best regards, Lau -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
Ok... Fair enough. Most of my comment related to Spring, not to Grails. Grails has other issues which I won't get into here. I have nothing but respect for Rails, and I look forward to the day when Clojure has a comparable system. On Nov 2, 2:32 pm, Wilson MacGyver wmacgy...@gmail.com wrote: On Tue, Nov 2, 2010 at 12:49 PM, Luke VanderHart luke.vanderh...@gmail.com wrote: fanvie, two comments: 2. You don't need 99% of the special crap that Spring/Grails gives you. Clojure's abstractions are smaller, yes, but the're just as powerful, and give you more control, in a more standardized way, then Spring does. I'll take exception to this comment. I think calling what grails as a framework provide you as special crap, is at best, a disservice to grails as well as other web framework. At the end of the day, people want to deliver a solution for a problem they are working on. Not focusing on oh look, shiny technology and abstractions There is value in being able to define a domain object, and right off the bat have ORM taken care of for you, tables created, controllers setup with CRUD/webservice/scafold. and then grails war to produce a complete single war file to deploy to any java application server. Not everyone needs it, but that doesn't make it crap. --- 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
Re: From jetty to war?
I have no problem at all with polyglot systems. That said, Clojure, as a general-purpose programming language, is in my subjective opinion superior to Ruby. Furthermore, there is nothing special about Ruby that makes it particularly suited to webapps (MVC webapps, perhaps, but MVC is not the only paradigm) As such, I expect and would welcome an eventual Clojure web framework with the same level of polish and stability as Rails. I don't mind polyglot programming, but one-language programming is easier. Plus, I just like working in Clojure. I don't think that's unreasonable, is it? Development platforms are not a zero-sum game. Just because I work on/prefer a Clojure framework to a Ruby one doesn't mean I'm trying to insult or belittle Rails. On Nov 3, 1:43 pm, Sean Corfield seancorfi...@gmail.com wrote: On Wed, Nov 3, 2010 at 8:51 AM, Luke VanderHart luke.vanderh...@gmail.com wrote: I have nothing but respect for Rails, and I look forward to the day when Clojure has a comparable system. I sort of have to ask why? - what's wrong with using Rails on JRuby for the front end and Clojure for the model? Why are folks so insistent on monolingual systems? -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. --http://getrailo.com/ An Architect's View --http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: From jetty to war?
fanvie, two comments: 1. It will get better over time, of course, as standard practices for Clojure shake out. 2. You don't need 99% of the special crap that Spring/Grails gives you. Clojure's abstractions are smaller, yes, but the're just as powerful, and give you more control, in a more standardized way, then Spring does. A couple of examples: A. Beans wiring. Spring adds a lot of value in Java - the whole problem they solve, however, is completely irrelevant in Clojure. Instead of stateful or singleton beans, just use a namespace filled with functions. Equally as versatile, equally as configurable, much less mental and typographical overhead, and all within the language itself without requiring extra config. If you want another layer of indirection between your caller and callee, it's trivial to def that out, too. B. Security integration. Spring gives you elaborate security-filter- chains that manage request and session scoped authorization and user objects, all of which wrap the basic servlet API. Clojure, with stateless first-class functions, makes this far simpler. In Ring, for example, all your security functions can be implemented as middleware that just throws a :user onto the request map. I've done it - it's literally easier to write a Clojure middleware function that handles authentication from scratch than it is to figure out how to wire in whatever spring security filter you need. And all the code you need to write is actually 100% relevant to your authentication logic. To my mind, this is a vast improvement over Spring, where the few nuggets of actual logic are lost in a sea of Java filters, wrappers and xml configuration files. The same holds true of most other Spring/Grails idioms, such as MVC, JDBC access, AOP, etc. On Nov 1, 5:34 pm, faenvie fanny.aen...@gmx.de wrote: my short-time experience with implementing webapps on a clojure-base is: i feel like in the very early days of java-servlet-api and j2ee. productivity way way way behind springframework or grails i don't even want to think about doing something sophisticated like security-integration. and of course this is not surprising because everything is new and much things are built up from scratch. esp. when it comes to build and webapp-deployment i feel a mismatch that hurts. (this is an average java-programmer with 2+ years experience in implementing webapps with springframework and grails) thanks have a successful time -- 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
Feature idea: meta-macros
The ability to use macros to do code generation and transformation is extremely useful. However, you still have to explicitly call the macro everywhere you want it to be used. In many scenarios, it might be desirable to do code transformation/generation on code, without explicitly modifying that code to call the macro. This could be accomplished by declaring a meta-macro, which combines a normal macro with a function which takes a form and tests whether the macro ought to be applied. Then, somewhere in the compilation pipeline, every form is passed to the test function, and the macro applied if it returns true. Sort of like aspect-oriented programming in Java. For example, say I have a codebase that makes frequent calls to a (sql ...) function to make a query to the database. I'm tracking down an obscure performance bug, and I decide I want to log all calls to (sql...), and time how long they took. But I don't want to modify the sql function itself (it's in a third-party library), and it'd be a major pain to find and replace all the hundreds of calls to it in my codebase with a normal macro call, particularly as I'm going to want to remove it all again after I finish my analysis. Enter metamacros: (defmacro my-logger [sqlform] (do...)) ;standard macro body, wrapping a form with timing and logging code. (def-meta-macro log-sql (fn [form] (if (= sql (first form ; test function my-logger) ; macro to apply Recompile, and, poof. I've instrumented my entire program with additional functionality in a handful of lines, without impact to my existing codebase. Of course, this would be tremendously susceptible to abuse, and if used inappropriately could lead to some very, very hard-to-debug errors. I'd think long and hard before using it in production code at all (maybe even enable metamacros only with a specific compiler flag, turned off by default?) But it's also very powerful, and allows one to try new things across a codebase very easily. It's also incredibly powerful... you could run it over a whole codebase to do static analysis and transformations to improve performance, or to catch stylistic errors. Hell, in theory, you could implement the entire compiler just in metamacros ;) Any thoughts? I grant you, the potential for abuse is huge. Would the benefits outweigh it? Thanks, -Luke V. -- 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: Feature idea: meta-macros
Unless I misunderstand something, (binding...) wouldn't work for this because I'd have to wrap all of the code I wanted to be modified within a (binding...) form. Fine if it's one source file, not so fine if I have dozens... Or am I missing something? On Sep 15, 2:26 pm, Nicolas Oury nicolas.o...@gmail.com wrote: Your example can be solved with (binding ...) For the proposal, I think it's a bad idea : huge potential for abuse (and importing abuse from other namespaces written by other people) and little benefit. I wouldn't be so strongly against it if it was in a delimited scope. In any case, you can probably implement it as a library on top of the compiler, with a code walker. -- 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: Feature idea: meta-macros
Oh, you're right, of course. Still, that doesn't quite meet the case I described, since the bindings won't effect any spawned threads/agents. On Sep 15, 2:47 pm, Alan a...@malloys.org wrote: Binding uses dynamic scope, not lexical scope, right? So any functions called before the binding expires will be affected by the new bindings, not just the code explicitly within its lexical scope. On Sep 15, 11:35 am, Luke VanderHart luke.vanderh...@gmail.com wrote: Unless I misunderstand something, (binding...) wouldn't work for this because I'd have to wrap all of the code I wanted to be modified within a (binding...) form. Fine if it's one source file, not so fine if I have dozens... Or am I missing something? On Sep 15, 2:26 pm, Nicolas Oury nicolas.o...@gmail.com wrote: Your example can be solved with (binding ...) For the proposal, I think it's a bad idea : huge potential for abuse (and importing abuse from other namespaces written by other people) and little benefit. I wouldn't be so strongly against it if it was in a delimited scope. In any case, you can probably implement it as a library on top of the compiler, with a code walker. -- 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: Is it possible in theory to write/modify a Clojure compiler that doesn't
Robert, The only problem with this approach is that there ARE practically guaranteed to be circular references. If the goal is to compile Clojure as if it were Java, circular references must be accounted for. But dependencies on classes generated based on parsing bytecode... that seems a pretty extreme edge case. Not to say that it won't ever happen, but I think it would be reasonable to say that anyone doing that should roll their own build process, and not expect a standard one to work by default. I know most Java compilers would choke if I pulled this sort of shennanigans. This actually sounds a lot like generating classes via Java annotations... but even there, you wouldn't hardcode a direct reference to a generated class. You reference an interface which is defined in the normal way, and then have some sort of dependency injection to look up and inject an instance of the generated class. On Aug 29, 5:44 pm, Robert McIntyre r...@mit.edu wrote: I don't think two pases is enough. What if a clojure file uses reflection (with macros of course) on a compiled java file to generate classes, sort of like how lancet works but generating classes instead of functions? And then those classes are used from other clojure and java files. Oh, and then another clojure file does the same reflection based junk to make more classes, from the classes that were generated from the first clojure file. These classes are, of course, used by other java and clojure files. In this case the only way I can think to compile everything (and sadly I'm doing something like this on my current project in lieu of a better way) is to: try to compile all the java files first (fail at some), try to compile all the clojure files (fail at some), try to compile all the java files (fail at some, but a little bit less than the first time), repeat until bytecode-level quiescence. The clojure compiler and java compiler will at most have to be invoked something like n times where n is the total number of source files in the project in certain pathological conditions as above. However, no matter what crazy stuff they're doing, as long as there no circular dependencies I think I can prove that this process will always make progress and converge to a steady state. I can make a concrete example of this condition if anyone's interested (at least I think I can!) As wasteful as it sounds is it really that bad? If the compilers only tried files that weren't already compiled and had minimal startup time then this sort of oscillation can be continued until quiescence is reached and will only take around the same time as single pass over all files. I've screwed around with this a lot and think that it would be a triumph if clojure and java could be intermixed freely. Then, there are no barriers to rewriting just one piece of a tightly interconnected java program in clojure for greater clarity/efficiency. You can just replace one java file with one clojure file, and use a java-clojure aware compiler instead of pure javac. I dream of the day where you could do this in a streamlined way in eclipse, so that everyone else on the project can focus on the concepts behind the program, not trivial minutiae like compile order. --Robert McIntyre On Sun, Aug 29, 2010 at 4:46 PM, Meikel Brandmeyer m...@kotka.de wrote: Hi, Am 28.08.2010 um 19:09 schrieb Michał Marczyk: I'm sure I'm missing lots of things, but I'd love to know which, so -- please let me know. :-) In fact, your two-pass scenario is probably the best you can get, since you can define arbitrary classes in arbitrary namespaces. (Whether this is advisable is a different question!) So any compiler trying to translate a classname to a defining namespace must fail in general. This could only be remedied by following a convention of one class per namespace which is quite a restriction. Just scanning the source files will also fail, because classes might be generated by macros. And macros might to depend on arbitrary functions defined in the file. So they can only be expanded by loading the file and executing the functions. Hence you cannot discover class generation in general. So I would suspect that your two pass scenario is a strict limit. 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 -- 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
Is it possible in theory to write/modify a Clojure compiler that doesn't
For the past week or two, I've been investigating what it would take to write something that would allow *.clj and *.java files to seamlessly compile together, such that they could be freely intermixed in a project. I knew it was a difficult problem, but I think the adoption benefits would be substantial, and the benefits huge for those stuck in Java-land at work. My conclusion (and *please* tell me if I'm missing something) is, unfortunately, that the problem requires full compiler support from both ends. Either a new compiler needs to be written that can compile both Clojure and Java, or the existing Java/Clojure compilers need some fairly extensive patching to make this possible, to share a dependency graph and symbol tables. The exception would be if it were possible to simply pass through class references when compiling *.clj files to *.class files, and not resolve them until run-time (or perhaps a seperate resolution phase of the compile process, for more compile-time safety). I realize this can't be done for dependencies between Clojure source files, since macro definitions are required at compile time. But is there any reason you couldn't do this for Java references from Clojure files? Then, it'd be very easy - just compile all the Clojure, put the classes in the classpath, and compile the Java. Any thoughts? -- 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: Is it possible in theory to write/modify a Clojure compiler that doesn't
My apologies, the title got cut off. It should be: Is it possible in theory to write/modify a Clojure compiler that doesn't resolve Java references? On Aug 28, 12:50 pm, Luke VanderHart luke.vanderh...@gmail.com wrote: For the past week or two, I've been investigating what it would take to write something that would allow *.clj and *.java files to seamlessly compile together, such that they could be freely intermixed in a project. I knew it was a difficult problem, but I think the adoption benefits would be substantial, and the benefits huge for those stuck in Java-land at work. My conclusion (and *please* tell me if I'm missing something) is, unfortunately, that the problem requires full compiler support from both ends. Either a new compiler needs to be written that can compile both Clojure and Java, or the existing Java/Clojure compilers need some fairly extensive patching to make this possible, to share a dependency graph and symbol tables. The exception would be if it were possible to simply pass through class references when compiling *.clj files to *.class files, and not resolve them until run-time (or perhaps a seperate resolution phase of the compile process, for more compile-time safety). I realize this can't be done for dependencies between Clojure source files, since macro definitions are required at compile time. But is there any reason you couldn't do this for Java references from Clojure files? Then, it'd be very easy - just compile all the Clojure, put the classes in the classpath, and compile the Java. Any thoughts? -- 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: Is it possible in theory to write/modify a Clojure compiler that doesn't
I'm not just talking about class hierarchy dependencies, but also
reference dependencies.
For example:
Foo.java
class Foo {
public Bar getBar() {...}
}
Bar.java
class Bar{
public Foo getFoo() {...}
}
This is pretty common in the Java world.
What I'd like to do is have Foo be written in Java, and Bar in Clojure
(for example). Right now, I'm not aware of any way to make this work.
The two-pass compilation does sound like the right track...
interesting idea.
On Aug 28, 1:09 pm, Michał Marczyk michal.marc...@gmail.com wrote:
Providing we're happy with disallowing circular dependencies (which is
what javac and clojure.lang.Compiler do anyway), I wonder if it might
be possible to have a build tool invoke the appropriate compilers on a
file-by-file basis, so that if foo.java depends on a class generated
by bar.clj, which in turn depends on the class defined in quux.java,
the compilation order is quux.java = bar.clj (at this stage
target/classes/quux.class already exists) = foo.java (at this stage
all the .class files generated by the compilation of bar.clj are there
in target/classes)...?
Alternatively, I suppose a two-pass compilation of Clojure sources
might be possible: (1) compile all Clojure code in a way heavily
reliant on reflection for all method calls on classes outside the base
library, disregarding all type hints and such; (2) compile the Java
code; (3) compile the Clojure code again, hopefully producing more
performant, less reflection-heavy bytecode.
I'm sure I'm missing lots of things, but I'd love to know which, so --
please let me know. :-)
Sincerely,
Michał
--
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: Is it possible in theory to write/modify a Clojure compiler that doesn't
Hm, thanks for the reference to that groovy thread... an interesting read. I might take a stab at writing a *generate-stubs* patch to Clojure's compiler, just to see how hard it would be to do. Out of curiosity, if Rich or anyone on the dev team reads this, is this the sort of thing that might possibly be a candidate for inclusion into the main Clojure compiler? On Aug 28, 7:02 pm, Seth seth.schroe...@gmail.com wrote: This sounds very similar to groovyc:http://groovyland.wordpress.com/2009/03/03/groovyscalajava/ On Aug 28, 12:50 pm, Luke VanderHart luke.vanderh...@gmail.com wrote: For the past week or two, I've been investigating what it would take to write something that would allow *.clj and *.java files to seamlessly compile together, such that they could be freely intermixed in a project. I knew it was a difficult problem, but I think the adoption benefits would be substantial, and the benefits huge for those stuck in Java-land at work. My conclusion (and *please* tell me if I'm missing something) is, unfortunately, that the problem requires full compiler support from both ends. Either a new compiler needs to be written that can compile both Clojure and Java, or the existing Java/Clojure compilers need some fairly extensive patching to make this possible, to share a dependency graph and symbol tables. The exception would be if it were possible to simply pass through class references when compiling *.clj files to *.class files, and not resolve them until run-time (or perhaps a seperate resolution phase of the compile process, for more compile-time safety). I realize this can't be done for dependencies between Clojure source files, since macro definitions are required at compile time. But is there any reason you couldn't do this for Java references from Clojure files? Then, it'd be very easy - just compile all the Clojure, put the classes in the classpath, and compile the Java. Any thoughts? -- 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: Idea for personal Clojure project
This is a hard problem. If you go by degrees and shades of synonymity, it can (and has been) done manually - see Visual Thesaurus (http:// www.visualthesaurus.com/). But for grouping based on the same semantic topics - that's pretty difficult. You could do it based on co-location in a corpus, but there'd be a lot of noise and results wouldn't be perfect. Maybe by using a syntactic parser to pull out nouns and verbs you could improve the results a bit. You could probably get something. Your best bet is definitely a statistical, corpus-linguistics based approach.. Actual semantic parsing isn't anywhere close, yet. The consensus of those I've talked to seems to be that we won't have full semantic language processing until we have strong AI - in fact, the two are very probably equivalent. Natural language is just too full of ambiguity and context. For example, there's probably a great many *people* in the world who'd have a hard time linking the words fish and reel, if they haven't fished before. And a lot of people would probably associate reel with dance more strongly than fish. The task potentially would strain even the verbal prowess of a non- linguist human, and computers are much more limited. On Jul 28, 4:58 pm, Daniel doubleagen...@gmail.com wrote: I want to write a clojure program that searches for similarities of words in the english language and places them in a graph, where the distance between nodes indicates their similarity. I don't mean syntactical similarity. Related contextual meaning is closer to the mark. For instance: fish and reel don't have much similarity, but in the context of fishing they do, so the distance in such a graph wouldn't be very large. I'm sure research has been done in this area (I suspect with no small portion belonging to google), so can anybody point me in the right direction? 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
Re: Enhanced Primitive Support
I've been reading this thread, and there's good arguments being made both ways - I've just been reading with interest. But after seeing the factorial function that won't compile without hints/casts, I feel I have to speak up. I wrote a book on Clojure. It's a short book. That's because Clojure is simple. It's dynamically typed, and everything just works. In the current version of Clojure, you can use numbers all day long without worrying about types. Type hinting and casting is an advanced topic - I think it should stay that way. It seems evident that some sort of compromise will be made on this question. That's fine. I genuinely could go either way. But whatever combination of features makes it into the final decision, they should absolutely, vehemently not *require* knowing how to type hint or cast just to get something basic to compile (as in the factorial example). That is antithetical to the whole concept of dynamic typing. Having exceptions thrown on overflow is ok with me - that's something programmers are used to putting up with, I think, as long as the rules are clear. I don't care what the rules are, as long as they're simple to understand and based on a few axioms. If integers are bounded, that's fine, if they automatically promote, that's fine, as long as the rules are clear. If there's a separate set of math functions which do or don't promote, that's fine. But don't, please don't, do anything that would mean I'd have to explain the intricacies of primitives, boxing, hinting and casting in an Intro to Clojure course. As much as humanely possible, that should be reserved for the Performance coding in Clojure sequel. Thanks, -Luke On Jun 20, 6:39 am, Nicolas Oury nicolas.o...@gmail.com wrote: It seems to me that there is mainly 2 categories in this thread: - people that are worried about the difficulty to understand and to code with the throw-on-overflow semantic. They worry about untested cases showing in production code and the steeper learning curve of the language. (I am not of this side, so please forgive me if I don't understand the argument well enough) - people that are annoyed to lose some speed everywhere in programs, in a way that can't be easily profiled or solved without annotating every lines. People that also believe it is rare and predictable to overflow a long. I think both arguments are valid, and that most people won't change their mind on this subject. In consequence, I would like to advocate a proposal along the lines of: - A set of operations per return size, labelled by their size. +-long, +-boxed, +-float,+-double ... (I am not good with name, so I am sure other people can come with better names) . They are overloaded on their arguments, but indicate return size (I think that's what the last branch does, but then again I might be totally wrong). - A set of operation without annotations : +, - ,... By default, these operators map to +-boxed, --boxed,... This solves the worries about the steep learning curve, because for beginners the story stops here. There is a flag allowing to change the default value, (or a namespace trickery, but it make it harder to apply to library code). That should come with some coding convention: - use +-boxed when you write a function that creates int exponentially bigger that its argument. (fact is in this category) - use +-long when you write code abound integers bound to a resource (indices, counters and the like...) - use the untagged operators in the other situations, +-boxed when in doubt. I would also advocate that there should be a +-small family that is either +-long or +-int depending on the platform. (+-long on modern computers, but open the way to +-int on phones, or +-double on Javascript platform where there is no integer, if I am no wrong.) For those worrying about a semantic-changing flag, I would like to note that it is not semantic-changing, it is only resource-size changing. You answer the question : what is the size of an integer? It is not different than choosing your heap size. If you don't have enough resource there is an exception (not a silent failure, so this is safe) and you can add more resources. I like this because: - it gives a clear story for beginners - it gives an easy way for people having very important production code (like a server), that does not need very high performance - it gives an easy solution for people having some code that need higher performance - it paves the way for other platforms - it is a pay-as-you-go approach, you don't have to understand any of that before you need it. What do you think? -- 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
Re: Enhanced Primitive Support
As Rich has mentioned a couple times, though, let's be careful not to conflate bounded integers with unsafe integers. In the proposed system, an overflowing number would throw an exception. Presumably the documentation would make it very clear what the behavior of numbers is. That's not unsafe or unexpected in any way, even for a dynamic language, it's just different. The only thing that sends shivers down my spine is *requiring* knowledge of casting and type hinting. I don't think that's appropriate to demand of someone new to Clojure. Let them learn to enjoy Clojure first, before showing them the ugly underbelly of what's sometimes necessary for performance. -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
Re: Clojure on the tiobe index
Tiobes rankings always seems a little dubious to me. Delphi more popular than Javascript? Really? Google Go more popular than Lisp/Scheme/Clojure? Ranking those three together is an atrocity, by the way. Just because they all have paren's doesn't make them the same. Anyway, I'm sure Tiobe measures something. But I'm not sure it's anything useful. On Jun 4, 10:11 am, BerlinBrown berlin.br...@gmail.com wrote: Nice. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html It is number 16. ...combined with Lisp and Scheme. -- 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?
Ok... thanks everyone for the extended discussion. I'm thrilled to get so much feedback - apparently something like this is much-desired. Tentatively, based on the feedback in this thread, I'm going to provide a thick API and a Swing implementation. I will *attempt* to keep it abstract enough that if someone wants to provide an alternative SWT (or even platform specific w/ JNI) backend, it will be possible, at least in theory. I can't make any guarantee that implementation will be easy, though, and I don't expect any alternative implementation will be anything like a drop-in replacement for the Swing one. But, at least if people really like the API (in which I'm investing considerable thought), they can re-use it for other GUIs. The general consensus seems to be that Swing can meet 95% of use cases. The remaining 5% who need truly polished native apps are probably going to end up doing a lot of work anyway to look good across platforms, so the right answer for them is probably to use a native library directly. Meanwhile, the rest of us will have a quick, easy way to write acceptable GUI interfaces with no extra work or library management. My goal is Netbeans-like quality out of the box. Later on this week I'll probably start posting some stuff to github - Design philosophies, use cases, and APIs, upon which I'd appreciate feedback. Implementations will follow as I get time to work on them. Thanks to everyone who has expressed an interest in contributing; if and when I feel the project has a clear direction and a little momentum, I'd definitely like some others on board. Again, thanks to everyone for your input. -Luke On May 27, 11:18 am, Luke VanderHart luke.vanderh...@gmail.com 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
Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
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 mmwai...@gmail.com 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 luke.vanderh...@gmail.com 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
Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
I would love to see an idiomatic clojure QtJambi wrapper that solves the writing custom widgets is hairy problem. I think QT Jambi's basic architecture precludes this. Jambi is basically a bunch of JNI calls to a backend C++ QT app. As soon as you start delving into Jambi's internals, you end up in C++ land. -- 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
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). 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. If you do 2 and 3, you should get pretty close to native Java speeds. On May 28, 12:20 pm, Rubén Béjar ruben.be...@gmail.com wrote: Hi again, I have tried a few more things: I have done the same in Java but using an array of Integers, instead of an array of ints. It just takes 78 ms. (more than 16, still far less than 4 secs). I have also tried with an update function which just returns a fixed 1. It still takes some 400 ms. to update de data vector of the CA. This is similar to the time it is giving me to create a vector of 1's with this function: (time (vec (repeat 25 1))). I was not expecting Clojure vectors so much slower than Java arrays. Is that comparison so unfair? Next thing I am trying is using Java Vectors in my Java implementation... Rubén Rubén Béjar escribió:Hi all, I am new to the list and to Clojure. I have been working in implementing some 2D cellular automata (CA) just to have a project to teach Clojure to myself. After some work I have something that works, but it is pretty slow. The function that takes a CA of 500x500 cells (integers) and returns an updated (*) copy takes 4 s. (using Clojure vectors), while doing more or less the same in Java (using arrays and primitive types) takes more or less 16 *ms.*. I expected some difference, but not that big. Before trying to use Java arrays and primitive types in Clojure, I would like to know how my Clojure approach can be improved (I am willing to sacrifice some performance to keep it more Clojure, but not that much). As I do not want to post a bunch of horrible code full of comments and not properly indented, I have extracted what i hope are the main pieces, written some comments and posted it here:http://snipt.org/Okpk Pasting that code in a new file in Eclipse (I am using counterclockwise) and running it in the REPL prints this: Clojure 1.1.0-alpha-SNAPSHOT Elapsed time: 4355.363706 msecs Elapsed time: 4416.98562 msecs 1:1 user= #Namespace cellular-automata-basic 1:2 cellular-automata-basic= I would thank a lot any hint, suggestion, comment, or whatever... :-) Best regards, Rubén (*) The update consists on adding the values of the 8 neighbours of every cell and changing it if that sum is between two fixed numbers.-- Rubén BÉJAR HERNÁNDEZ Dpto. de Informática e Ingeniería de Sistemas - Universidad de Zaragoza (Computing and Systems Engineering Department - Universidad de Zaragoza) c/ María de Luna 1, 50018 Zaragoza, Spain Tel: (+34) 976 76 2332 (Fax: 1914) e-mail:rbe...@unizar.esgrupo IA3 (IA3 Laboratory) -http://iaaa.cps.unizar.es On May 28, 12:20 pm, Rubén Béjar ruben.be...@gmail.com wrote: Hi again, I have tried a few more things: I have done the same in Java but using an array of Integers, instead of an array of ints. It just takes 78 ms. (more than 16, still far less than 4 secs). I have also tried with an update function which just returns a fixed 1. It still takes some 400 ms. to update de data vector of the CA. This is similar to the time it is giving me to create a vector of 1's with this function: (time (vec (repeat 25 1))). I was not expecting Clojure vectors so much slower than Java arrays. Is that comparison so unfair? Next thing I am trying is using Java Vectors in my Java implementation... Rubén Rubén Béjar escribió:Hi all, I am new to the list and to Clojure. I have been working in implementing some 2D cellular automata (CA) just to have a project to teach Clojure to myself. After some work I have something that works, but it is pretty slow. The function that takes a CA of 500x500 cells (integers) and returns an updated (*) copy takes 4 s. (using Clojure vectors), while doing more or less the same in Java (using arrays and primitive types) takes more or less 16 *ms.*. I expected some difference, but not that big. Before trying to use Java arrays and primitive types in Clojure, I would like to know how my Clojure approach can be improved (I am willing to sacrifice some performance to keep it more Clojure, but not that much). As I do not want to post a bunch of horrible code full of comments and not
Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
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
Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?
Thanks, Heinz... I may. Right now I'm still exploring what I want the API to be. I was hoping to achieve something a bit thicker that could insulate the user from Java classes completely. The user wouldn't even have to know Swing or handle JObjects or worry about the event thread... In other words, it wouldn't be a wrapper API for Swing, but a Clojure GUI api that, coincidentally, is /backed/ by Swing. This may be an unrealistic goal, but I've got pretty far down the path of designing it, though I definitely don't want to declare victory until I've figured out a strategy for covering every reasonably common use case. -Luke On May 27, 5:54 pm, Heinz N. Gies he...@licenser.net wrote: +1 For swing especially since I started this already. Look for clj-swing in github, since this seems quite a load of work I'd be glad for any help so :). Regards, Heinz On May 27, 2010, at 21:30 , Luc Préfontaine wrote: +1 for Swing. On Thu, 2010-05-27 at 11:59 -0700, Brian Schlining wrote: +1 Swing. +1 Swing. +1 Swing. There's a ton of documentation out there, and it got some -- 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?
Why not design it so that it can be backed by Swing or SWT or HTML (perhaps with some AJAX) or whatever? It seems kind of silly to do an abstraction on a single backend, don't you think? Ideally, yes. In practice, I'd rather implement one framework well than implement only the lowest common denominator of several. We're not just talking creating a window with menus and a few buttons - My project, for example, is a word processor. Having a requirement that it work across multiple GUI toolkits sounds a little bit hellish. That said, I do plan the core API to be abstract enough from the underlying implementation that it could in theory be backed by a different framework. I just don't intend to do the work of providing bindings to multiple implementations and ensuring that behavior is consistent. If some enterprising soul wants to use the same basic interfaces to front an alternative implementation, I'll certainly try to make it conducive to that. But having a API with seamlessly interchangeable back-ends doesn't sound very feasible. By the way, do the SWT people only come out at night? Or is it a US vs Europe issue? Seems somewhat curious that 7 in a row vote for Swing, then the next 4 are all SWT advocates. Should I expect the QT fans to show up tomorrow? :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: Announcing Clojure/core
Very cool. The website doesn't say... how was/is the Clojure/core team selected? Are they all Relevance employees, or freelance? Do you plan on ever bringing more people on board? Although I'm not quite as qualified as some of the others, that's something I'd potentially be very interested in, particularly since the book Stuart and I wrote is now out... -Luke On May 25, 8:30 am, Rich Hickey richhic...@gmail.com wrote: I'm happy to announce Clojure/core, a joint endeavor between myself and Relevance, Inc. Clojure/core is a specialized technical practice within Relevance, focused on Clojure. Featuring myself and Stuart Halloway as advisors, the team also includes Clojure experts such as David Liebke (Incanter), Stuart Sierra (clojure-contrib contributor) and Aaron Bedra (an experienced consultant using Clojure). The practice will be providing mentorship, training and development services for those using, or planning to use, Clojure, and sustaining Clojure itself. Not interested in Clojure mentorship, training or dev assistance? There's still plenty of good news for the Clojure community in this announcement. One of the missions of Clojure/core is the sustainability of Clojure. The team will spend 20% of its time on Clojure itself. This includes working on enhancements and tickets, incorporating patches, helping tend the mailing list etc. This will enable our team to get a lot more done than I could ever do myself, while enabling me to focus on the fundamental aspects of Clojure. It will also broaden the pool of people with intimate knowledge of the internals of Clojure. The availability of services such as this is an important milestone for Clojure, as people choosing to adopt Clojure can be assured they can get mentorship, training and dev assistance, from experts. I'm very excited about this effort. The folks at Relevance have never failed to impress me with their skills and attitude, and they truly get Clojure and care about its sustainability. Note: clojure.com will now resolve to the Clojure/core site. Come check it out! http://clojure.com Rich -- 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 athttp://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: Anyone experienced in using clojure as a database
Clojure is not a great choice for this. It's oriented as a programming language, not a database. It doesn't have any built-in persistence mechanisms, and while it has many virtues, it's a little bit of a memory hog. That isn't really what you want in an in-memory DB. For anything more than a toy app where you don't want to do the work, I think you'll be much more pleased with the results if you hook up a real DB or NoSQL solution. - Luke On May 25, 2:08 pm, Fabio Kaminski fabiokamin...@gmail.com wrote: Folks, i would like advice, cause since im starting something that will be eventually big data intensive, from scratch and i really like the options already built in in clojure like STM, parallelizing data and concurrency logic implemented on it i think its wonderfully tuned to use as database... and you can achieve different strategies, like graphs or balanced trees for different data my worries are about the efficiency in serializing it and recovering from/to the disk, java VM as a hungry heap VM, (and with immutable strategies, more heap needed) the benefits are control of sharding mechanism's and parallelizing not only in the unit's cores but between nodes of a cluster.. anyone using clojure not just as database middleware(wich is perfect for) but as database backend too? Thanks all, Fabio Kaminski -- 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 athttp://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: Periodic tasks
Why not just run an agent that does something, then calls sleep for N seconds, then calls the next thing? Granted, it will eat up a thread in your agent thread pool, but if you've only got one of these in the app it shouldn't be a problem. Or you could go the Java route, and start a daemon thread manually. -Luke On Oct 30, 12:05 am, Stefan Arentz ste...@arentz.ca wrote: What is a good and simple way to run periodic tasks in Clojure? I need to run a simple function every couple of minutes. And make sure that if it throws an exception that it won't kill the periodic task. I come from a Spring world where XML, Timers, Jobs and Quartz rule the world, so am hoping for something small and elegant for Closure :-) 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: Infinite sequences hang sets and maps
Wouldn't hashCode be called every time you use an infinite sequence as a key in a hash map? That strikes me as a problem, since everything else in Clojure makes perfectly good map keys. On Oct 29, 4:01 am, Mark Engelberg mark.engelb...@gmail.com wrote: On Wed, Oct 28, 2009 at 11:08 PM, John Harrop jharrop...@gmail.com wrote: For the specific case of hashCode, no; identical values must have identical hashes but different values need not have different hashes. Collisions due to the hypothetical cutoff get exponentially less likely with each additional increment of 1 of the cutoff length. I see your point that hashCode could be made to work on infinite sequences, but since hashing is almost always a prelude to testing for equality, I'm hard pressed to think of an example of why you'd want to be able to do this. Can you illustrate with an example? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Authers needed for Apress book: Definitive Guide to Clojure
Hello all, I am writing a book on Clojure for Apress - you can read about it at http://www.apress.com/book/view/1430272317 (be aware, before you consider buying it, that it's still VERY rough and less than half done) It's coming along well. I am enjoying the writing, and I feel it will be a good resource to supplement what is already available. Unfortunately, it is progressing rather slowly. It's my first book, and somewhat more labor-intensive than I had guessed, in addition to which I am working full time on several other projects. Apress would like to publish as soon as possible, and in order to do that we decided to see if we could bring in some guest authors to help out and write some chapters. That's where you all come in. We're looking for one or more guest authors to contribute 1 to ~5 chapters. Each chapter needs to be at least 20 pages long (approximately). There will be compensation, with advances, royalties and marketing recognition proportionate to the amount of work contributed. The list of chapters so far looks like this: 1 The Clojure Way 2 The Clojure Environment 3 Defining Symbols and Functions 4 Data Types and Structures 5 Sequences 6 State Management 7 Namespaces and Libraries 8 Multimethods 9 Metadata 10 Working with Java 11 Parallel Programming 12 Macros Metaprogramming 13 Appendices (Overview of Clojure tooling and environments, overview of Java) I've finished through chapter 5. If you've written about Clojure in the past, or if you feel you are able to write lucidly about any of the following chapters, with examples, then I strongly encourage you to consider doing this. It would be a great help to Apress, and having more variety of experience in the book can only make it stronger. It will continue, either way, but this is a great opportunity to be a part of it and help it get to market more quickly (hurray for parallelism in writing!) . Also, if you have an idea for an additional chapter that you're willing to contribute, we will definitely entertain the idea - I didn't initially put in chapters about web programming, GUI programming or unit testing in Clojure to keep the scope down, but these are all deserving topics if someone really wants to give them a shot. If you are interested, reply here, or send me an email to me, or to my editor Michelle Lowman ( michellelow...@apress.com ) so we can talk about it. Thanks very much for considering this. Sincerely, -Luke VanderHart --~--~-~--~~~---~--~~ 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: You know you've been writing too much Clojure when...
Wow. I have seriously done most of these. Leaving out return statements in javascript is the most insidious, however, particularly since my JS coding style has become extremely functional since learning Clojure. -Luke On Jun 12, 9:55 am, Luc Prefontaine lprefonta...@softaddicts.ca wrote: You get back into Java code and find it cumbersome, clunky, (add your own) ... and wish you had written it in Clojure in the first place. Then you realize that this code was written ... before Clojure was born. Bouhouhou !! Luc On Fri, 2009-06-12 at 13:24 +0200, Christophe Grand wrote: You forgot to write return. Paul Stadig a écrit : You meant to type disclosure, but instead you typed disclojure. Paul Luc Préfontaine Armageddon was yesterday, today we have a real 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: AIML pattern matcher design
; First thing to learn is XML parsing with Clojure. This is basically done. Use the xml library in core if you just need to load XML into a map data structure. Use the zip library if you need to navigate it. Use the xml library in contrib if you need to do xpath- style navigation. For the rest of it... it looks very well thought out. I'm not familiar enough with the problem domain to comment specifically, but obviously you're putting a lot of thought into it, so I'm pretty sure you won't have any problems. -Luke On May 8, 12:50 pm, dhs827 scheur...@gmail.com wrote: I'm stealing knowledge left and right (just ask me :-) to design me an AIML pattern matcher. I've compiled a draft list of objects and behaviors, which I would like to see reviewed for plausibility: startup - opens configuration file (e.g. startup.xml) - passes configuration file to bot-loader object bot-loader - loads general input substitutions (spelling, person) - loads sentence splitters (.;!?) - looks for enabled bot, takes first one it finds - reads bot-id; uses it as key (for saving/loading variables and chatlogs) - loads bot properties (global constants, e.g. name) - passes control to aiml-loader object aiml-loader - loads list of AIML files to load, and for each file - opens file - reads AIML categories (XML) one by one as they appear in the file - parses and stores the content of the match path (e.g.BOTID * INPUTPATTERN * CONTEXT1 * CONTEXT2 *) - when it reaches the end of the category - the template, or leaf of this branch of the tree - calls a method to store the elements of the match path, together with the template, in the pattern-matcher-tree ; First thing to learn is XML parsing with Clojure. ; Though it is probably the easiest thing to do, it is not necessary for the templates to be stored along with the paths in the tree. They might as well be left on disc or in a database. ; A function like parser/scan must advance the parse to the next part of the document (element - element content - processing instruction...) and tokenize it. I can then use case/switch/if (must look at what Clojure offers) to make decisions/set variables/call methods. ; The whole path, with all components, gets created at load time. The loader combines all elements of the path (e.g. INPUTPATTERN * CONTEXT1 * CONTEXT2 *) into one string, seperating the components using special context-id strings (e.g. input, context1, context2) ; The idea of the AIML graphmaster is: take this string, seperate it into words, then store these words as nodes in a tree. ; A variation of this idea: instead of keying the nodes by their values, key them first by context, then by value. ; Now that the bot is up and running, the user types something into the input box and hits Enter. The pre-processor - protects sentences - blocks common attack vectors, e.g. code injection, flooding - eliminates common spelling mistakes - for each loaded substitution - finds and replaces it in the input string - alternatively, uses a tree to search for them - removes redundant whitespace - splits input into sentences (everything that follows is for each sentence) pattern-matcher - combines INPUTPATTERN * CONTEXT1 * CONTEXT2 * into one string - tokenizes the path to be matched into the individual words (nodes) - traverses the tree from the root; first - tries matching underscore (_)wildcards - matching of wildcards is recursive - match one word of the current path component - try remainder against child node - if the whole remaining input matches - and if the last node is a leaf - return the template - else try 2 words, then 3 - if all words in the string are used up and the current node is a leaf - return the template - else stop matching underscores, and - tries matching exact words in alphabetical order - if there is a childnode that equals to the input word, recurse a level deeper - if at the next level there is a leaf, return the template - else - tries matching the star (*) wildcard - when a complete path was matched, creates a match-object - holds information about the match - the input (sentence)
Re: Using Map
Do you mean map the function or map the data structure? If the most natural form of your data is truly rows, you're probably best off using a vector data structure. As for which function you use, that depends whether you're doing something to every element or only to specific elements, and if you know which position those elements are in or if you have to search for them, etc. On May 4, 11:01 am, Emeka emekami...@gmail.com wrote: Hello All, I want to arrange objects in rows and also being able to manipulate them. By manipulation I meant, I could move one object from one row and use it to replace another object in another. Should I use Map or something else? I need your opinions here Regards, Emeka --~--~-~--~~~---~--~~ 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 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: Writer turned programmer seeks string processing advice
On May 6, 4:39 am, dhs827 scheur...@gmail.com wrote: I realize now that there is no quick fix, and I'll have to learn a lot to do this properly. But are there already enough resources so that I can learn how to do it in Clojure? For example, would there be enough about string processing in Programming Clojure to learn it from theere? Clojure itself is very well documented for a language that's been out for less than two years, and as you can see, there is an active community to turn to for help. With persistence, it's very possible to become a Clojure expert in a short amount of time. I don't imagine you'll have any problem with the language itself. You'll probably have to get some books or look elsewhere for help with the actual algorithms specific to this problem domain, though - I doubt there's any Clojure tutorials dedicated specifically to pattern matching or AI. But anything that can be implemented in another language can be implemented (probably better) in Clojure, so if you know Clojure and you can at least read the examples in the AI literature, you should be good to go. -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 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: Writer turned programmer seeks string processing advice
First of all, this is a very interesting question. I definitely wish I had more time to think about it and maybe put together some code - unfortunately I don't. Clojure does sound like it would be good for this kind of processing. This is an ideal example of where it would be incredibly powerful to built up a domain specific language from Clojure using macros, allowing both the full expressivity of AIML and the full power of Clojure when necessary. That said, just from reading your post - Clojure is a much less specialized language than AIML appears to be, particularly in the area of pattern matching in the strings. You will either have to find a Java (or Clojure) library that does this, or write the Clojure yourself. It's definitely possible, but I'm afraid there's no way to avoid actually getting dirty and writing the pattern-finding code (unless you can find a library that does exactly what you want, and wrap it). My intuition is that it would be fairly easy to get something that just works - a lot can probably be done with Clojure's regular expression capability. But I have a feeling that in order to get high- performance code, you'll have to do a lot of indexing and caching which could potentially get complex. All in all, I think Clojure's a great language for this, but in order to replicate some of the advanced features of a made-for-ai specialized language you're going to have to do some non-trivial coding to basically recreate those features of AIML that are unique. This is true of Clojure or any other general-purpose programming language. Whether it's worth the effort is up to you, but if you can do a good job I bet there'd be a lot of interested people. It actually sounds very like the classic exercise of building a logic- based language similar to Prolog in Scheme or Lisp, only with an AI/ pattern matching functionality instead of a logic resolution engine. I'll look over your questions in more detail later, if I have time, and see if I can provide any more specific input. Thanks! -Luke On May 5, 12:16 pm, dhs827 scheur...@gmail.com wrote: Hi, my name is Dirk Scheuring, I'm a writer based in Cologne, Germany, and I want to write something about AI that can only be expressed by using AI technology and technique. You could say that what I aim for is a chatbot, but it's a bot that works quiet different from the norm; at it's core, there is a functional program, and on the fringe, there's lots of state information. I have a working prototype, written in AIML, the language in which the famous Alicebot was written. Most bots written in AIML use a simple stimulus-response conception of dialogue, without using (sequences of) state, self-reflection, or other advanced concepts. So some people who have only cursory knowledge of this language think that it's too simple to be doing anything with that might be computationally interesting. I know this to be false. AIML is sort of a micro-version of a Lisp, with String being the only type, and recursion over everything (powerful and dangerous). You can write serious functions with it [1], but you have to abuse it. And I heavily abused the language to make it do what I want. I managed to build a prototype that does something interesting, but only does it for like ten conversational strokes, because then the interpreter's stack overflows, causing an infinite loop. I need to implement my ideas in a different language - one that I don't have to abuse to do complex stuff. I've looked at various functional languages, and have now installed two, Scala and Clojure, doing a couple tutorials at the respective REPLs. I have a hunch that Clojure might turn out to be closer to what I already have in AIML, but I'm not sure yet. Maybe you can help me decide. AIML is an XML dialect; its most important construct is the category/, which has a pattern/ and a template/. This is a default category/, which matches any string: category pattern*/pattern template sraiSOMEFUNCTION/srai /template /category The srai/ element in the template/ means that I invoke the pattern matcher recursivly to match SOMEFUNCTION. How can I express this in Clojure? The next primitive construction I need to translate is substitution: category pattern* RAN */pattern template sraistar index=1/ RUNNING star index=2//srai /template /category This code matches the substring RAN in the middle of a set of other substrings, and substitutes it for RUNNING, leaving the values before and after it untouched for the next recursion. And I need to know how to do: category pattern* MADONNA */pattern template think set name=celebrityMadonna/set /think sraistar index=1/ star index=2//srai /template /category The above category extracts a substring from the input and saves it to a (global) variable; the other substrings are up for another round of pattern matching. Another important low-level
Re: Clojure Poetry
Cool... I actually did a Markov chain generator myself as one of my
early Clojure projects. I posted about it at the DC Study group, here:
http://groups.google.com/group/clojure-study-dc/browse_thread/thread/26ccdc8acb102f9/d18d7627ddcaf167
It looks like yours is more succinct... I'll definitely have to take
some time and compare our approaches.
-Luke
On Apr 24, 8:47 am, tmountain tinymount...@gmail.com wrote:
In an effort to learn more about Clojure, I decided to port a markov
text generator which a friend wrote in Python. After getting through a
few snags, I completed the program and decided to have some fun
feeding in some e-books downloaded from the Gutenberg project as
input. In this case, I chose Sherlock Holmes and Bram Stoker's Dracula
to create a bizarre mashup, which could be called Draclock Holmes or
something approximate. I had the program print out three-line snippits
of text, and some of the resulting text resembles a sort of absurd
poetry. I'd imagine if I let it churn and burn for a few hours, some
real gems could emerge.
acting in her interests
Mina's morning and evening hypnotic answer is unvaried
with devilish passion
she succeeded somewhat
swiftly and deftly
His look is a warning
together as we swept along
found myself lying on my bed trembling all over
Miss Stoner and I gazed at him in many tongues
my power to reward you for your services
common subject for conversation
throwing open another door
nine years in England
strong-faced old man
to mediaeval times
Here's the code. I'm new to Clojure, so I'm open to suggestions. It's
written in a purely functional non-destructive fashion; although, I'm
sure a few things could be improved.
(ns markov
(use clojure.contrib.str-utils))
(defn rand-nth [coll]
return a random element from a collection
(nth (seq coll) (rand-int (count coll
(defn clean [txt]
clean given txt for symbols disruptive to markov chains
(let [new-txt (re-gsub #[:;,^\()] txt)
new-txt (re-gsub #'(?!(d|t|ve|m|ll|s|de|re)) new-txt)]
new-txt))
(defn chain-lengths [markov-chain]
return a set of lengths for each element in the collection
(let [markov-keys (map keys markov-chain)]
(set (for [x markov-keys] (count x)
(defn max-chain-length [markov-chain]
return the length lf the longest chain
(apply max (chain-lengths markov-chain)))
(defn flatten [x]
Flatten a collection
(let [s? #(instance? clojure.lang.Sequential %)]
(filter (complement s?) (tree-seq s? seq x
(defn build-chain [markov-chain keychain words]
Builds a markov chain
(let [first-word (first words)]
(if (seq words)
(recur (assoc markov-chain keychain
(cons first-word (get markov-chain keychain)))
(concat (rest keychain) [first-word])
(rest words))
(assoc markov-chain keychain []
(defn chain
Take a list of words and build a markov chain out of them.
The length is the size of the key in number of words.
([words]
(chain words 3))
([words length]
(build-chain {} (for [x (range length)] nil) (map clean words
(defn split-sentence [text]
Convert a string to a collection on common boundaries
(filter seq (re-split #[,.!?()\d]+\s* text)))
(defn file-chain
Create a markov chain from the contents of a given file
([file]
(file-chain file 3))
([file length]
(let [sentences (split-sentence (slurp file))
flatten-list (fn [ x] (flatten (list x)))]
(loop [markov-chain {} words sentences]
(if (seq words)
(recur (merge-with flatten-list
markov-chain
(chain (re-split #\s+ (first words
(rest words))
markov-chain)
(defn construct-sentence
Build a sentence from a markov chain structure. Given a
Markov chain (any size key), Seed (to start the sentence) and
Proc (a function for choosing the next word), returns a sentence
composed until is reaches the end of a chain (an end of sentence).
([markov-chain]
(construct-sentence markov-chain nil rand-nth))
([markov-chain seed]
(construct-sentence markov-chain seed rand-nth))
([markov-chain seed proc]
(loop [words (if seed seed (rand-nth (keys markov-chain)))
sentence (str-join (filter identity words))]
(if (seq (markov-chain words))
(let [word-new (proc (markov-chain words))]
(recur (concat (rest words) [word-new])
(str-join (into [sentence] [word-new]
sentence
Example usage:
(ns main (use markov))
(def markov (file-chain draclock.txt))
(doseq [x (range 100)]
(doseq [x (range 3)] (println (construct-sentence markov)))
(println))
Input files:http://www.gutenberg.org/files/345/345.txt-
draculahttp://www.gutenberg.org/dirs/etext99/advsh12.txt- sherlock holmes
I just cat them together to make draclock.txt
Re: The Path to 1.0
To me, major version numbers means no more nor less than a marker pointing to a stable, consistent release that can be easily referred to consistently by everyone. It doesn't mean that there can't be major, breaking changes for 2.0 (or even 1.5, whatever). I don't even care what features are in that release, as long as it's stable and useful. But I'd like a release of Clojure 1.0 so I can say to people this works with version X, with 100% certainty that we're talking about the exact same feature set. It's hard for new people to get working with Clojure, as it is, because everything is in a constant state of flux and you never know when an upgrade will break Slime, ect. Coherent versioning eliminates this worry. To me, a 1.0 release is all about reducing barriers for newcomers by saying this is definitely safe to use. The only reason NOT to release 1.0 immediately, imho, is if a major change is just around the corner. Thanks, -Luke On Apr 16, 12:53 pm, Rich Hickey richhic...@gmail.com wrote: People (and not just book authors :) often ask - whither 1.0? [Ok, maybe they don't use 'whither']. The fact remains, some people want a 1.0 designation, and I'm not unwilling, providing we as a community can come to an understanding as to what that means, the process it implies, and the work it will require (and who will do it). Here are some of the relevant issues, IMO: - Stability/completeness/robustness This is mostly about - does it work? Is it relatively free of bugs? Is it free of gaping holes in core functionality? I think Clojure is in a pretty good place right now, but am obviously biased. This in no way implies there isn't room for improvement. - API stability With the semantic changes of fully lazy sequences behind us, I think the syntax and semantics of existing functions is largely stable. - Development process stability Currently all new work (fixes and enhancements) occurs in trunk. There's no way to get fixes without also getting enhancements. I think this is the major missing piece in offering stable numbered releases. While I've cut a branch for each of the prior two releases, no one has ever submitted a bugfix patch for either. If people are going to want to work with a particular release version for an extended period of time, someone (other than me) will have to produce patches of (only!) fixes from the trunk for the release branch, and occasionally produce point releases (1.0.x) from that branch. I'd like to continue to do the bulk of my work in trunk, without messing anyone up or forcing everyone to follow along. - Freedom from change Numbered releases are most definitely not about absence of change in general. There are more things I want to add and change, and there will be for some time. That will keep Clojure a living language. 1.0 or any numbered release can't and won't constitute a promise of no further change. But there are different kinds of change, changes that fix bugs and changes that add new capabilities or break existing code. People need to be able to choose the type of change they can tolerate, and when to incur it. - Perception Obviously, a 1.0 designation impacts perception. I am not interested in pursuing it just to influence perception, but rather to (collectively) acknowledge a milestone in usability and stability. However there may be other perceptions, good/bad or simply wrong (e.g. that Clojure is finished). Will the general perception engendered by 1.0 be met in the large, or a mismatch? What does 1.0 mean to you? Are we there yet? Any recommendations for the organization of the release branches, patch policy etc? Feedback welcome, Rich --~--~-~--~~~---~--~~ 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 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: The Path to 1.0
My .02 on the version control issue: All of them work. Some are easier to use than others. There are successful projects that use just about all of them. It's personal preference. Rich is going to be doing most the contributing, let him choose the VCS. Period. On Apr 17, 4:29 pm, Laurent PETIT laurent.pe...@gmail.com wrote: I guess there's really no perfect solution here :-( The question is : do you prefer to have some clojure users united against subversion, or divided by Rich not having chosen their preferred DVCS (Mercurial users vs Git users, not sure whether clojure needs those kinds of nonsense internal wars in the community ) 2009/4/17 mifrai fraim...@gmail.com Rich says Git is not going to happen any time soon, great as it may be, given the current lack of infrastructure (google code) and tools support. I'm curious as to why github isn't a viable alternative to google code? Now that it has issue tracking, I don't see the advantages of choosing google code over it (aside from the learning curve). Mike On Apr 17, 6:21 am, Rich Hickey richhic...@gmail.com wrote: Thanks all for the feedback. One impression I get is that it seems the existing community is getting along ok on trunk, so perhaps we also need to consider those not yet using Clojure, possibly even because of a lack of 1.0. I joked about book authors, but I'd like to make it clear that I think it is very important that Stuart's book correspond to a release of Clojure. It would be huge for newcomers coming to Clojure find a book that says Covers Clojure 1.0, and a compatible download for 1.0.x with the latest fixes. Stuart has worked hard on tracking the latest changes, as have I in trying to get in those changes that would be breaking as soon as I could before 1.0. I'm presuming it's not too late to get Covers Clojure 1.0 in there (Stuart?), and, if so, it is a factor in this decision. I'll also add that there is plenty more I'd like to do, and as soon as I get into that trunk will again be changing rapidly. There simply has to be a branch for fixes only. As to the feedback: A library management system seems like a tall order for a language 1.0. It is certainly an interesting and useful pursuit, but given the variety of approaches and opinions therein, it seems a bit out in front of us. Advantages of Maven vs Ivy vs whatever should be separate. Git is not going to happen any time soon, great as it may be, given the current lack of infrastructure (google code) and tools support. Is there some respect in which this impacts the core? It would seem dangerous to marry any single approach in the language itself. A deprecation policy is a good idea. Backward compatibility mode is unlikely. As for tests, there are tests in: http://code.google.com/p/clojure-contrib/source/browse/#svn/trunk/src... Anyone who wants more tests can contribute them. Overall, I'm getting feature requests (more change!) and not a strong drive for 1.0 stability. If you feel otherwise, please speak up. Otherwise, my conclusion is that 1.0 may be more important for not-yet- users wary of working from source. Rich --~--~-~--~~~---~--~~ 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 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: New release of the enclojure plugin is up.
Excellent... this is the first release of a Clojure IDE that hasn't immediately proven itself unusable as I put it through its paces. I expect this will become my main platform for Clojure development. Thanks! -Luke On Apr 6, 8:43 pm, Eric Thorsen ethor...@enclojure.org wrote: There is a new release of the Enclojure plugin that addresses many of the items I have seen discuss here recently with regards to managing classpaths in REPLs as well as many other Clojure development scenarios. The plugin supports several use cases for the clojure.main REPL use: a. Project based REPLs where the REPL is started using the dependancies on the project in the IDE. b. Remote REPLs where some shim code can be included in your application(s) and you can attach a REPL (or REPLs) to running VMs. c. Ad-hoc REPLs - manually set your classpaths and start a REPL up. All of these scenarios have strong integration with the editor supporting integrated Clojure/Java completion, debugging with viewable clojure data, syntax highlighting, code loading, expression evaluation, s-expression nav and many more features. There have been well over 100 patches since the last release in February. For more information, please see:http://enclojure.wikispaces.com Plugin can be downloaded at:http://code.google.com/p/enclojure-nb-clojure-plugin/downloads/list Feedback welcome! Eric Eric Thorsen ThorTech Solutionswww.thortech-solutions.com (914) 302-7638 [work] (914) 302-7641 [fax] (914) 804-4954 [cell] --~--~-~--~~~---~--~~ 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 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: 08 and 09 are invalid numbers, but 01 through 07 are fine?
Well! You learn something new every day. Ironically, I knew about octal, but back in the day when I was learning Java, the book I was reading didn't have a typeface that distinguished O and 0 very well, and since I never had to use them I never was corrected. Interesting. Thanks! On Mar 12, 5:14 pm, Shawn Hoover shawn.hoo...@gmail.com wrote: On Thu, Mar 12, 2009 at 5:13 PM, Meikel Brandmeyer m...@kotka.de wrote: Hi, Am 12.03.2009 um 22:08 schrieb levand: Seems like there's a bug here. All the digits less than 8 work. If leading zeros aren't allowed, at least the behavior ought to be consistent. Leading zeros indicate octal, which has no digits like 8 or 9... In so far it's not a bug nor is it inconsistent, I guess. Indeed. And if you just use 0-7 and it's all good: user 010 8 --~--~-~--~~~---~--~~ 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 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: Performance conundrum - my primes function should really be faster.
Ok, sorry for posting this. I figured it out myself. Turns out that my eratosthenes function took much, much longer on primes and near-primes than it does on the average number. And, of course, the numbers that pass through the wheel factorization filter are just that. So the good news is that I figured it out... the bad news is that, for smallish numbers, wheel factorization doesn't appear to provide a significant improvement over the unadorned Sieve of Eratosthenes. Thanks, -Luke On Mar 12, 2:07 pm, levand luke.vanderh...@gmail.com wrote: So, I'm doing the whole Euler thing, and I'm writing a function for finding primes using wheel factorization in combination with the Sieve of Eratosthenes. The algorithm is correct, but very slow. I've managed to isolate the part that's having unexpectedly bad performance. I just can't see why the last of these four expressions is so slow. The only overhead it ought to have is a single if statement. I am beginning to think there's something about the implementation of filter that I'm missing... Any help would be greatly appreciated. The code below uses only 2 functions... wheelfactor? returns a boolean if the number is a good candidate for a prime by wheel factorization, eratosthenes checks a given number against a sieve. For the purposes of this demonstration I've defined the sieve to merely be the first 1000 primes - so the answers returned here aren't necessarily correct, but the performance factors ought to be about the same. I have ran all the benchmarks multiple times against a warmed-up JVM, so that's not the issue. ;;See how long wheelfactor? takes to run over 100k (time (dorun (filter wheelfactor? (range 1 10 ;;30 milliseconds ;;See how long a simple eratosthenes takes to run over 100k (time (dorun (filter #(eratosthenes % sieve) (range 1 10 ;;13 seconds ;;See how many numbers 100k are potential primes? (count (filter wheelfactor? (range 1 10))) ;;26687 ;;See how long it takes to run eratosthenes ;;to evaluate 26687 large numbers: (time (dorun (filter #(eratosthenes % sieve) (range (- 10 26687) 10 ;;3 seconds ;;See how long it takes to run a combination ;;I expect ~3 seconds, from the previous tests (time (dorun (filter #(if (wheelfactor? %) (eratosthenes % sieve)) (range 1 10 ;;13 seconds!? ;;But I put a trace in eratosthenes and it still only runs 26687 times!? --~--~-~--~~~---~--~~ 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 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: What is Clojure NOT good for?
The biggest barrier to using Clojure in an enterprise environment is that enterprise projects are typically built and maintained by 100s of replaceable code-monkeys and consultants, all of which understand Java and almost none of which understand Lisp of any kind, let alone Clojure. To be honest, even if I could get away with it, I wouldn't want to inflict hell on the next person who has to fix something in my Clojure code. Even if they're a good developer, they are very unlikely to care about Clojure or functional programming. I heard of one guy in our company who wrote some web services in Scala on the grounds that they were one-off services that wouldn't need to be modified - until they were, and everyone was roundly cursing him for it. They were small enough that it turned out to be easier to redo them in Java rather than to learn Scala and understand his code. Like it or not, enterprise development = Java or .NET until the language landscape has some radical changes. On Mar 6, 9:22 am, Rich Hickey richhic...@gmail.com wrote: On Mar 6, 8:15 am, Joshua Fox joshuat...@gmail.com wrote: Is it fair to say that Clojure shines in algorithmic processing, string processing, concurrency management, but that there are better choices in other areas: - Application programming , where the key challenge is fitting a standard three-tier application to the business domain. - Enterprise programming, where the challenge is gluing together overweight and fragile libraries, and one should always use exactly the set of software which the API creators envisioned? Rich himself has suggested something along these lines, but I wonder what others think. I don't recall suggesting that. I would certainly consider application programming a prime domain for Clojure. OTOH, if that's the definition of enterprise programming, I'm not sure any language is going to produce a satisfying result. Being a Lisp, and having the ability to generate primitive math ops that map to machine instructions, Clojure can scale high and low. I wouldn't count it out in many domains just yet, as we're just starting to see it applied to a wide array of problems. Often its applicability will just be a matter of libraries and macro packages. I think it is unlikely to end up with less applicability than Java. Even what seems like a categoric absence, like static typing, may be filled with a la carte typing and constraint systems built on logic programming extensions like the Datalog work. Of course, I'm biased, but wide applicability is certainly the intent of Clojure. I'm interested in what others think as well. Rich --~--~-~--~~~---~--~~ 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 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: What is Clojure NOT good for?
Oh, I agree with you 100%. I outlined why I wouldn't use Clojure in a project self-described as enterprise, but at risk of ranting I didn't get into how I consider the word enterprise synonymous with bloated, bureaucracy-bound, over-engineered, unoriginal and above all /expensive/ ball of tar. Ironically, enterprise has nothing to do with actual size or significance of the project. I've seen very small projects that are infected with enterprise, whereas I don't think there is anything enterprisy about, say, Google. -Luke On Mar 6, 11:07 am, lprefonta...@softaddicts.ca wrote: I agree about consultants (these days it's not anymore an synonym for expert) and the state of the market but... If you write a new software product and you are concerned with deadlines and speed in general, Java is not the way to go anymore considering the pile of code you need to do anything significant these days. More code = more people = inefficiencies. I know some business where HR and IT managers come back with this mantra that they can find Java and .Net coders, anything else is too risky or too scarce on the market. It reminds the time when you could not get fired when buying IBM mainframes. Many HR departments do not understand anything about software development in general and the profile of individuals needed. They go for the standard available bodies with a single fit all projects skill set and their batteries of psychological tests. That explains a lot why productivity is low on most projects. The landscape will change when HR changes (and managers)... seeking intelligence and initiative instead of a single static fit. (looks like StarTrek quest...) The day they will understand that software development is not a Taylor assembly line (less the efficiency), the situation will improve. You cannot get more from people that what you are asking for... I am not generally optimistic about the state of things in the software industry but we need to bring in tools that are more accessible to the masses. Clojure is one if you compared it to CL... Luc The biggest barrier to using Clojure in an enterprise environment is that enterprise projects are typically built and maintained by 100s of replaceable code-monkeys and consultants, all of which understand Java and almost none of which understand Lisp of any kind, let alone Clojure. To be honest, even if I could get away with it, I wouldn't want to inflict hell on the next person who has to fix something in my Clojure code. Even if they're a good developer, they are very unlikely to care about Clojure or functional programming. I heard of one guy in our company who wrote some web services in Scala on the grounds that they were one-off services that wouldn't need to be modified - until they were, and everyone was roundly cursing him for it. They were small enough that it turned out to be easier to redo them in Java rather than to learn Scala and understand his code. Like it or not, enterprise development = Java or .NET until the language landscape has some radical changes. --~--~-~--~~~---~--~~ 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 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: Extensive use of let?
Very interesting ideas, everyone... thanks a lot for the input. Yeah, I recognize that each case is going to be different - I guess I was just looking for suggestions on how to manage it. Which I found... Comp and partial look particularly interesting. Thanks! -Luke On Feb 25, 5:09 pm, Kevin Downey redc...@gmail.com wrote: You should look at - it lest you take (op3 (op2 (op1 input))) and write it as (- input op1 op2 op3) there is also comp which composes functions, and partial for partial application. some example comp usage:http://github.com/hiredman/clojurebot/blob/297e266b0badf0f301a556e957... On Wed, Feb 25, 2009 at 12:57 PM, levand luke.vanderh...@gmail.com wrote: Recently, in my code, I have been struggling with which of the two equivalent forms is, in a general sense, better. (defn my-fn1 [input] (let [value1 (op1 input) value2 (op2 input) value3 (op4 value1 value2)] (op5 value3))) (defn my-fn2 [input] (op5 (op4 (op1 input) (op2 input Now, the second is definitely cleaner and more elegant, besides being smaller, which is a non-trivial benefit when I have a fair amount of code to page through. However, if I've been away from the code awhile, it's much easier to come back determine what the code is doing when its written the first way, especially when it uses descriptive names. An operation that is impenetrable when written in nested form can become quite simple when each step is broken down and labeled. Clojure is my first Lisp - should I just stick with the second form until I learn to see through the nested s-expressions? It's not that I'm trying to make my code more imperative - Although I come from a Java background, I love functional programming, and it is a delight to see how much I can do without side-effects. But I do miss the self-documentation that well-named variables can provide. Any thoughts? Also, is there any performance degradation from the first way, or can the compiler optimize it away? -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com 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: challenge: best fibo implementation under the new laziness?
Just out of curiosity - did you by any chance warm up the JVM to make sure that the fib function was JIT'd before you did this benchmark? On Feb 23, 5:46 pm, Raffael Cavallaro raffaelcavall...@gmail.com wrote: On Feb 23, 2:51 pm, Stephen C. Gilardi squee...@mac.com wrote: The fibs implementation in clojure.contrib.lazy-seqs is not a function that returns fib(n) given n. I think defining a fib(n) function somewhere in contrib or core that operates as efficiently as we can manage would be a good idea. There was a thread on comp.lang.lisp a while ago where a number of people went back and forth trying to come up withe the fastest fib(n) algorithm (again, *not* returning a sequence, but just the nth fib given n). Here is the winner of that informal competition translated to clojure: (defn fib ([n] (fib n 1)) ([n b] (if (zero? b) ;calculate lucas numbers (cond (zero? n) 2 (= n 1) 1 :otherwise (if (even? n) (let [ k (/ n 2) l (fib k 0)] (+ (* l l) (if (even? k) -2 2))) (let [ k (- n 1) l (fib k 0) f (fib k 1)] (/ (+ (* 5 f) l) 2 (cond ;calculate fibonacci numbers (zero? n) 0 (= n 1) 1 :otherwise (if (even? n) (let [ k (/ n 2) l (fib k 0) f (fib k 1)] (* f l)) (let [ k (- n 1) l (fib k 0) f (fib k 1)] (/ (+ f l) 2))) btw, the relatively naive algorithm: (defn fib-naive [n] (first (nth (iterate (fn [[a b]] [b (+ a b)]) [0 1]) n))) takes over 85 seconds, or more than 40 times as long as the lucas number based algorithm at top to compute the one millionth fibonacci number. The simple loop version: (defn fib-naive2 [n] (loop [a 0 b 1 counter 0] (if (= counter n) a (recur b (+ a b) (inc counter) fares exactly the same as one might expect. for comparison, here are some timings under different lisps on the same machine. All timings are after several runs to warm up caches and, in the case of clojure, hotspot optimizations. Time to calculate the one millionth fibonacci number using the lucas number based algorithm at top: clojure: 2 seconds ccl: 0.5 seconds lispworks: 1.7 seconds mzscheme: 0.15 seconds sbcl: 0.8 seconds larceny: 13 seconds ecl: 0.04 seconds as you can see, clojure is competitive with other lisps/schemes, faster than some, slower than others. this is really just a benchmark of the bignum package used by the lisp implementation. I think ecl uses GMP which is quite fast. btw, I tried adding type annotations to the clojure version but it didn't seem to make much difference. --~--~-~--~~~---~--~~ 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 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 -~--~~~~--~~--~--~---
