Re: In core structure editor, anyone?

[John Newman]

Some Noobian critique:

Thread-local bindings also allow us to monkey-patch for the span of a local
> context. Say we have a function *cat* which calls a function stored in a
> Var; if a function *goat* is root-bound to the Var, then *cat* will
> normally call *goat*; however, if we call *cat* in a scope where we have
> thread-locally bound a function *moose* to that Var, then *cat* will
> invoke *moose* instead of *goat*. (The key idea here is that the function
> call is bound to a Var, not directly to a function, so the actual function
> called is up for grabs every time the call is executed.)


 You lost me at "span of a local context."

I pretty much understand what you're saying, since I've been playing around
with clojure for a while and "thread-local bindings" is somewhat
self-explanatory, if a little bit cryptic.

Basically, a var is a container.  Different threads can have vars
(containers) of the same name but with different values (contents).  If a
var is called but not found in a thread, clojure will search the global/root
bindings/namespace.

Is that accurate?

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: literate snake

[John Newman]

I don't know much about functional programming, but I believe you're
supposed to think about functions as black boxes.  Put something in, get
something out.

Take this function, for example:

(defn snake-head [] (first (@snake :body)))


(We're cheating on the put something in part!)

Perhaps it'd be better if we didn't instantiate the snake until later in the
"game loop." What if we wanted to make a game with two snakes?  Then
snake-head is broken.

Rather, we just do something like:

(defn snake-head [any-snake] (first (@any-snake :body)))

Now many snakes from many threads can use this function. (I think.. I'm
noobs, so... :)

In fact, in most game tutorials, the "game loop" will be in a separate
thread all together, so it might be more common to leave any def'ing of
apples and snakes toward the bottom, where you have the gui code.

As a side note, if I remember correctly, other Java game tutorials usually
frame up the gui fairly early in the code.  They probably do that for
aesthetic reasons -- so the Java app seems to load faster.  Don't quote me
on that though.

2cents


On Fri, Jan 2, 2009 at 8:39 PM, Mark Volkmann wrote:

>
> For anyone still following this, the latest code that incorporates
> many of the suggestions I've received here is at
> http://www.ociweb.com/mark/programming/ClojureSnake.html, replacing my
> original version. It now uses refs. I think I have the dosyncs
> optimally placed. Feedback still welcomed! Can I / should I further
> reduce the number of defs I have?
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
> >
>


-- 
John

--~--~-~--~~~---~--~~
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: [Discuss] Contribs with dependencies

[John Newman]

How 'bout something like Ruby Gems?
Having to svn and build the clojure-contrib sources is a hassle for some of
us.

On Thu, Apr 16, 2009 at 7:41 AM, Stu Hood  wrote:

> I agree. I think the "breaking into modules" approach is the only scalable
> solution.
>
> Someone else mentioned that clojure-contrib is/shouldbe an incubating area
> for core, which seems reasonable. There should be a little more pushback
> when a project wants to make it into contrib, and it should already be
> organized such that its dependencies would be well known if it wanted to
> make it out of 'incubation' and into core.
>
>
> On Tue, Apr 14, 2009 at 5:02 PM, Howard Lewis Ship wrote:
>
>>
>> I'd say to refactor clojure-contrib into a number of seperate modules;
>> individual modules (each with its own pom) could have their own
>> dependencies. Thus if you choose clojure-contrib-freechart, you get
>> that JAR (or compiled Clojure sources) plus the jfreechart dependency.
>>
>> In this way you are using the good part of Maven: transitive
>> dependency management.
>>
>> On Tue, Apr 14, 2009 at 5:19 AM, Rich Hickey 
>> wrote:
>> >
>> > I've been thinking recently about contribs with dependencies.
>> >
>> > I think it's very important to have layers - e.g. core depends only on
>> > JDK 1.5, contrib only on core. Lately there have been some ideas
>> > centering around Joda Time, [Parallel]Colt, AWS, JFreeChart, Fork/Join
>> > etc.
>> >
>> > I'd like to start a discussion about how best to support the
>> > contributions of libraries that depend on things not in the JDK.
>> >
>> > Obviously, without care and rules it could get crazy quickly, and I
>> > want to avoid the kitchen-sink effect. It is very important that
>> > things remain [truly, not just apparently] simple.
>> >
>> > Looking for suggestions,
>> >
>> > Rich
>> >
>> > >
>> >
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>> Director of Open Source Technology at Formos
>>
>>
>>
>
> >
>


-- 
John

--~--~-~--~~~---~--~~
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

[John Newman]

I vote for 1.0 as soon as possible.  Seems stable to me.  I'm working on a
chat application and when we moved to fully lazy sequences, still none of my
code broke.

I vote no on making contrib the "Standard Library."  The Java Standard
Library is large enough.  I would like contrib to be easier to get though.

On Fri, Apr 17, 2009 at 11:42 AM, Stuart Halloway  wrote:

>
> I would love to see 1.0, and the sooner the better. At Relevance we
> are doing real work in Clojure today.
>
> As for wish list I would love to see improvements to the development
> process:
>
> * move from svn to git
> * move regression tests from contrib into clojure itself
>
> But neither of these need necessarily to block 1.0 IMO.
>
> When I release software that depends on Clojure I pin it to a commit
> number, not to a named release. For me the named release is more about
> public recognition than anything else.
>
> Cheers,
> Stu
>
> P.S. Git is to svn as functional languages are to mutable languages.
> Git repositories are immutable data structures, and repos-local
> pointers such as HEAD are like atoms. It would be interesting to see
> Clojure's data structures have a canonicalized serialization and play
> around with content addressability.
>
> > When we release software that depends on Clojure we don't care about
> > numbered releases at all -- we will run regression tests of our own
> > production app against the Clojure and contrib repositories and pin
> > our releases to a commit number, not a specif
>
>
> >
> > 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
> >
> > >
>
>
> >
>


-- 
John

--~--~-~--~~~---~--~~
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

[John Newman]

Well, perhaps if str-utils becomes the universal standard for string
operations, it would be rolled into Clojure come 2.0?

On Sat, Apr 18, 2009 at 2:58 PM, Konrad Hinsen wrote:

>
> On 18.04.2009, at 12:15, John Newman wrote:
>
> > 2) One way to maintain Clojure's flexibility would be if it were
> > like what the kernel is to a Linux distribution.  What if every
> > distribution had to use the same standard set of packages?  The
> > Linux ecosystem is much richer today because the kernel can develop
> > somewhat independently of the applications that target it.
>
> True, but there is still a standard set of packages (or rather
> functionalities) that all but the most specialized Linux
> distributions contain and that everybody expects to find in a
> "normal" Linux distribution. Things like the shell, ls, rm, etc.
>
> > One way to compensate for a lack of "batteries included" might be a
> > powerful, agnostic library management solution, which allows for
> > different contrib libraries, VMs, or architectures, but that
> > definitely seems like a 2.0 feature.
>
> That sounds like a lot of work, and it won't take care of one
> important contribution of a standard library: standardization for
> basic, well-understood tasks. It's no fun to program in an
> environment where there are three competing libraries for parsing
> HTML that differ only in function names and parameter order.
>
> Konrad.
>
>
> >
>


-- 
John

--~--~-~--~~~---~--~~
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

[John Newman]

> I do not agree with John Newman that the Java standard library
> should be the Clojure standard library.
>

I'm not saying that.  I'm saying that:

1) Requiring Java's standard library on every system is unfortunate enough
-- it's too big for some of the smaller devices coming out now. And,

2) One way to maintain Clojure's flexibility would be if it were like what
the kernel is to a Linux distribution.  What if every distribution had to
use the same standard set of packages?  The Linux ecosystem is much richer
today because the kernel can develop somewhat independently of the
applications that target it.

Eventually, clojure-contrib will be much much larger than clojure the
language.  If clojure-contrib is Clojure's "standard", most of the work
involved in developing "Clojure 2.0" won't be in core but in hammering on
contrib.  If that's what people want then great. It just seems like a less
flexible solution to me.

One way to compensate for a lack of "batteries included" might be a
powerful, agnostic library management solution, which allows for different
contrib libraries, VMs, or architectures, but that definitely seems like a
2.0 feature.

On Sat, Apr 18, 2009 at 1:51 AM, Tom Faulhaber wrote:

>
> Tom's 2 cents:
>
> I think Clojure is basically ready to go to 1.0. I like the idea of
> having a book about Clojure 1.0 go hand in hand with the release.
>
> While I agree that the library management problem is too hard for a
> 1.0 release (and also largely separable), it would be nice to see the
> software version number (e.g. 1.0.0) and the subversion number (e.g.
> r1352) in the built clojure.jar somewhere that's easily accessible to
> tools that are trying to do library management. My solution to this
> would probably just be to generate a couple of (def *clojure-version-
> number* "1.0.0") things as part of the build. Do any Java/Maven heads
> have more sophisticated ideas that we should consider here? I've just
> started hacking on some svn manipulation stuff (and a little bit of
> jar manipulation) in the process of doing my contrib autodoc robot, so
> I'd be happy to help here too.
>
> While I agree that "what is clojure.contrib?" is a pretty big issue, I
> think we could leave it a little fuzzy for a while longer. One thing
> we should probably do is do a real comparison of how we stack up
> against python's "batteries included" model and see how we need to
> address that. (To my mind, the python library has always felt very ad
> hoc.) I do not agree with John Newman that the Java standard library
> should be the Clojure standard library. There's enough that's
> different in Clojure that I think we do want some of our own ways to
> approach things. I think there's also space for some great documents
> (& screencasts, etc.) that show how to leverage parts of the Java
> library to do cool things in Clojure. (Rich's demo of building swing
> apps in Clojure comes to mind.)
>
> I'd also like to see a little more focus on the perl/python/ruby
> equivalence from a newbie perspective. That is, more clarity around
> startup, script execution (including having an equivalent to python's
> "if  __name__ == '__main__':" construct), class path management, etc.
> I know that this is one area where being in the JVM ecosystem makes
> our life worse rather than better, but approaching Clojure is still a
> bit daunting compared to these other languages.
>
> You can count me among the git fanboys, but I can't get too worked up
> about moving off google code right now (and that would be necessary if
> we switched to git). (Aside to Matt Revelle: You can use git-svn on
> the client side (and I do) but that provides only a local solution, so
> it isn't a magic bullet.)
>
> Really, we all know that 1.0 means 1.0. Clojure will be much further
> along than most other languages at their 1.0 point, so I wouldn't
> stress over it too much.
>
> I think that might have been 6 cents worth :-).
>
> Tom
>
>
> >
>


-- 
John

--~--~-~--~~~---~--~~
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 Contrib?

[John Newman]

I'm a novice, myself, but Clojure got me reading up on Scheme and, what
about the PLaneT thing (require (planet blah ...

(where dependencies are automatically pulled from a repository?)

Maybe it's not applicable here, but I thought it was pretty neat.


On Wed, May 13, 2009 at 11:41 AM, Konrad Hinsen
wrote:

>
> On 13.05.2009, at 00:04, Phil Hagelberg wrote:
>
> > Now that Clojure 1.0 is out, I think it's a good time to take a
> > look at
> > contrib. I noticed it didn't get an official 1.0 release along with
> > Clojure core. I wonder if this is because its role is just not very
> > well-defined. Several people have expressed this opinion here on the
> > mailing list and on IRC.
>
> I'd say the real question is not "what is contrib?" but "what kind of
> library system should Clojure have?"
>
> I think that it is clear to most of us that contrib started as
> something which it isn't any more. At the moment, it's a bucket of
> code whose only common point is the licence, which allows it to be
> distributed under exactly the same terms as Clojure itself, whatever
> those may become.
>
> As I have said before, I strongly believe that Clojure should have a
> standard library. Contrib could then become the staging ground for
> both code and the standard library. But the important question is
> about the standard library, not about the fate of contrib.
>
> Alternatively, we could also envisage something like the Haskell
> platform:
>
>http://hackage.haskell.org/platform/
>
> This is a collection of separately written libraries distributed as a
> single package with a single installation procedure. I think an
> officially labelled and maintained standard library is important, but
> there could well be a collection of independent (and differently
> licenced) libraries on top of that.
>
> Konrad.
>
>
> >
>


-- 
John

--~--~-~--~~~---~--~~
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: Clojure at JavaOne

[John Newman]

I believe it was the presentation you gave on the ants simulation, where you
updated the program while it was running.  I'm not sure if the other
languages in the shootout can do that, but I thought that was pretty
awesome.

I think a display of building an application while it's running in front of
you (be that a web app or a desktop app) is flashy and compelling.  Not sure
how far you could go with that though.

2 cents.

Regards,

On Mon, May 18, 2009 at 5:42 PM, Laurent PETIT wrote:

>
> As a general idea, I would say :
>
> specific to lisp:
> the possibility to get rid of "boiler plate code", such as the one
> involved in each and every (re)implementation of some GOF design
> patterns.
>
> This could be either a demonstration of the power of higher order
> functions or macros (the first with higher order functions *can* be
> done in java, but it is such a pain in the ass to do this right with
> anonymous functions that it is rarely done in practice, some spring
> framework frameworks let apart)
>
> specific to clojure:
> a demonstration of the ease of use of concurrent/parallel programming
> constructs.
>
> 2009/5/18 Rich Hickey :
>  >
> > I'll be doing two sessions involving Clojure at JavaOne this June. One
> > is a traditional talk (TS-4164), the other is as a participant in the
> > Script Bowl 2009: A Scripting Languages Shootout (PAN-5348).
> >
> > The 'script' bowl is a friendly competition, basically a place to show
> > off your language and seek audience acclaim.
> >
> > "Scripting language gurus returning from 2008 are Groovy, JRuby,
> > Jython, and Scala. This year there is also a new kid on the block:
> > Clojure."
> >
> > There are two very brief rounds, 4 minutes per language each round .
> >
> > round 1: Core language and libraries round (show something really cool
> > with the core language and libraries)
> >
> > round 2: Community round (show some significant community
> > contributions)
> >
> > Note there is no comparative aspect, each language presenter talks up
> > their own language and the audience decides, so it's not an
> > opportunity to draw contrasts explicitly. It's about being pro-
> > Clojure, not anti- anything else.
> >
> > The audience is Java developers, many of whom will have never seen
> > Clojure or any Lisp.
> >
> > I'd appreciate some suggestions *and help* preparing demos for the
> > Script Bowl. What (that could be demonstrated in 4 minutes) would make
> > you think - 'Clojure looks cool, I need to look into it'? What
> > community contribution(s) should we showcase?
> >
> > Thanks,
> >
> > Rich
> >
> > >
> >
>
> >
>


-- 
John

--~--~-~--~~~---~--~~
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: 3d viewer

[John Newman]

Including import statements at the top would make it easier for me to try it
out.

Thanks,

On Wed, May 20, 2009 at 4:09 AM, kyle smith  wrote:

>
> I have uploaded 3d-viewer.clj to the files section.  If anyone finds
> it useful, I would appreciate some feedback.
> >
>


-- 
John

--~--~-~--~~~---~--~~
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: 3d viewer

[John Newman]

Thanks.  On my setup I had to add '(javax.swing JFrame) too.

Pretty neat.

On Wed, May 20, 2009 at 3:12 PM, kyle smith  wrote:

>
> Import statements added.  Example usage:
>
> (def coords [[0 0 0] [1 1 1] [2 2 2]]);etc
> (g3d coords)
>
> That should pop open the viewer.  Left click and drag to rotate, and
> use the scroll wheel to zoom in/out.
> >
>


-- 
John

--~--~-~--~~~---~--~~
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: Clojure at JavaOne

[John Newman]

Speaking of "walking/filtering code," what about walking _actual_ code?

The only thing off the top of my mind would be an example of, say, a "Hello
World" function, but with the code represented as a JTree.  Say, in the
function (pr (.toLowerCase "Hello World")), you'd see .toLowerCase as a
node.  You'd click on the node to edit it and enter .toUpperCase.

After showing people the "HELLO WORLD," you could show them how the JTree
used a zipper (or some similar walking tool) to edit the datastructure.
This shows how a textual .clj file is only one of the possible
representations of the datastructure, code is data, data is code, etc. etc.

Even better, the JTree could be editing a live program... Or the program
running the JTree itself! :)

This doesn't have to be the actually example used.  Someone else might be
able to come up with something more practical, ideally implementing some of
the xml stuff you were talking about.

However, I can tell you that from my perspective, this whole "code is data"
thing was a bit of an epiphany for me when I realized it allowed for things
like in the example above.  (And it's thanks to Clojure that I took the dive
into lisp.)  I think something like this might have some jazz to it.  Not
sure the other languages can play the same tune.  (correct me if I'm wrong)

Regards,

On Thu, May 21, 2009 at 11:43 AM, Rich Hickey  wrote:

>
>
>
> On May 21, 10:38 am, Chas Emerick  wrote:
> > I'm guessing glitz and visual impact is what's going to wow the crowd,
> > especially in that environment, where it's likely that most people are
> > steeped in "business applications".
> >
> > Perhaps using one of the clojure-processing wrappers to do some
> > outrageously-slick data visualization, and then showing how little
> > code is required to do it and how much leverage the language provides
> > when addressing changes in requirements?  Maybe the slick visual
> > impact part can be merged with the "business application" mindset by
> > generating a report that includes the data visualization (I think PDF
> > generation is built into processing).
> >
>
> Last year the JRuby demo was a fancy graphics thing that utilized the
> motion sensor in the laptop + OpenGL or something. It really said
> little about JRuby (IMO), other than that being on the JVM lets you
> reach these libs, and perf was good enough.
>
> I'd like to do something modest but distinguishing. I have a vague
> notion of showing some Clojure data originating in some XML off the
> web, being passed to some filtering/walking code, getting displayed,
> stored in a DB, all without specific DOM/model/recordset APIs, a
> couple of lines for each task. This demonstrating the difference of
> not being OO - using generic abstract data types like maps everywhere.
>
> Help wanted in implementing some demo code.
>
> Rich
>
> >
>


-- 
John

--~--~-~--~~~---~--~~
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: Poll for a new name for clojure eclipse plugin 'clojure-dev'

[John Newman]

How 'bout eclj?

On Tue, Jun 23, 2009 at 9:01 PM, Meikel Brandmeyer  wrote:

> Hi,
>
> Am 23.06.2009 um 18:00 schrieb Laurent PETIT:
>
>  clojure-eclipse
>>
>> This one has the merit to clearly state that it relates to clojure and
>> eclipse (even more cleary than eclojure). Looks like an interesting
>> candidate to me.
>>
>
> Since I'm quite uncapable of finding good names
> I simply rip-off one I already have:
>
> EclipseClojure ;)
>
> Sincerely
> Meikel
>
>


-- 
John

--~--~-~--~~~---~--~~
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: ants.clj and render thread starvation

[John Newman]

I think I remember running the ants.clj demo on my netbook and it running
normally.  I'll check again this evening.

On Tue, Jun 30, 2009 at 12:40 PM, Daniel B Lucraft 
wrote:

>
> I didn't think it was possible for the render agent to be interrupted
> like that. Isn't the point of the MVCC system that the render agent
> will see a consistent view of the world as it was when the render
> started? And that the ants can continue modifying the world during the
> render's processing but the render agent will not see any of it until
> it has completed it's transaction? It only reads the refs so it
> shouldn't ever retry.
>
> Sorry to jump in despite being inexperienced at this, but it makes me
> think I don't understand something correctly.
>
> Dan
>
> On Jun 29, 6:51 pm, B Smith-Mannschott  wrote:
> > After watching most of Rich's Clojure presentations over the weekend,
> > I found myself playing with ants.clj again on my netbook. The ant
> > simulation runs brilliantly on my quad-core machine at work. Not so
> > much on my netbook. The problem seems to be that with only a single
> > (hyperthreaded) core the render agent is almost constantly interrupted
> > by some pesky ant while attempting to snapshot the world, forcing the
> > render agent to automatically retry. And so, the ants run merrily
> > around the world, only I can't see it.
> >
> > This raises a question. Clojure's refs and dosync sure are neat, but
> > this experience would seem to indicate that there are potential
> > scalability problems when combining long-running and short-running
> > transactions. Under load (or on a slow machine) a long-running
> > transaction may never get a chance to complete and may be stuck
> > forever retrying, burning CPU but producing no useful output. This
> > makes me uneasy.
> >
> > I was able to get ants.clj to work reliably on my netbook by playing
> > around with the sleep times in such a way as to increase the
> > probability of the renderer actually completing a snapshot, but this
> > process felt hacky and ad-hoc. What works on my netbook might well be
> > sub-optimal on another system.
> >
> > How could one change the design of ants.clj to work reliably (i.e.
> > update the screen periodically) even on slower systems?
> >
> > // Ben
>
> >
>


-- 
John

--~--~-~--~~~---~--~~
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: ants.clj and render thread starvation

[John Newman]

I'm on an hp mini.  It runs on an Atom processor.  I ran ants.clj and it was
frozen for a little while.  Then after maybe 30 seconds it looked normal --
a tick every second or half second or so.  I'm running a lot of applications
though.  On Ubuntu here too.

On Sun, Jul 5, 2009 at 11:17 PM, B Smith-Mannschott
wrote:

>
> On Tue, Jun 30, 2009 at 18:01, Rich Hickey wrote:
> >
> > On Tue, Jun 30, 2009 at 7:50 AM, Krukow wrote:
> >>
> >> On Jun 29, 7:51 pm, B Smith-Mannschott  wrote:
> >> [snip...]
> >>> much on my netbook. The problem seems to be that with only a single
> >>> (hyperthreaded) core the render agent is almost constantly interrupted
> >>> by some pesky ant while attempting to snapshot the world, forcing the
> >>> render agent to automatically retry. And so, the ants run merrily
> >>> around the world, only I can't see it.
> >>
> >> If my understanding of the STM is correct (and it may very well not
> >> be) the render function should not retry. The render function reads
> >> all the refs that define ant positions, but does not modify any ref.
> >> So I suspect that the missing renders are caused by a thread
> >> starvation rather than retries.
> >>
> >> But I'd like to hear if Rich agrees ;-)
> >>
> >
> > MVCC history in Clojure's STM is dynamic, created by need. There is no
> > read tracking, and more important for this case, no transaction
> > tracking. So, if a read transaction is unable to satisfy its snapshot
> > view from history, it will flag the offending ref with a fault and
> > retry. When a writer sees a ref with a read fault it will grow history
> > for that ref. In this way only as much history is created as is needed
> > to satisfy the dynamic contention patterns, and
> > tracking/synchronization is minimized.
> >
> > The problem for scanning readers like render is that the ref that
> > caused the fault this pass is unlikely to be the ref that causes the
> > fault next time, and it will take a while to accumulate even one step
> > of history for each scanned ref using the fault system.
> >
> > This has caused me to implement (in git master) some long-planned
> > controls on ref history. You can now supply :min-history and
> > :max-history args to ref. The defaults are 0 and 10 respectively. By
> > setting min-history to some positive value, history will be
> > accumulated even in the absence of faults, providing a window, if you
> > will, for scanning readers like render.
> >
> > You can see this history acquisition by periodically running:
> >
> > (map ref-history-count (world 20))
> >
> > while the ants demo is going.
> >
> > So, now you can preemptively maintain history in the ants demo by
> > modifying the world init with some min-history (the value 2 below is
> > your 'knob' for accommodating the duration of the render sweep)
> >
> > (def world ... (ref (struct cell 0 0) :min-history 2) ...)
> >
> > Please let me know how that works for you, and, everyone else, please
> > let me know if max-history default of 10 causes you any trouble
> > ("Transaction failed after reaching retry limit").
>
> Sorry it took me so long to try this out...
>
> I've tried this with a build of
> a1397390d8b3b63f2039359520629d87b152d717 (July 4), I tried
> :min-history values of 2 and 9, which didn't help, meaning the window
> stayed blank because the rendering agent does not run to completion. I
> was able to get something to display by dialing :min-history up to
> 100. It draws less than one frame per second, but it does draw.
> (Perhaps it's too much to expect for a single core to juggle some 50
> threads.)
>
> I'm going to play around with it some more and see what I find.
>
> // Ben
>
> >
>


-- 
John

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Website down?

[John Newman]

I've been trying to get to Clojure.org  for a few days
now and I can't get to it from my military network, nor my civilian
satellite connection (I'm deployed).  I can't ping it though (resolves to
75.126.104.177).  Is anyone else having the same problem?

-- 
John

--~--~-~--~~~---~--~~
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: Website down?

[John Newman]

Yea, false alarm.  I guess my network at work is just jacked up.

On Mon, Jul 27, 2009 at 2:21 PM, Glen Stampoultzis  wrote:

> Seems to be up.
> http://downforeveryoneorjustme.com/clojure.org
> <http://downforeveryoneorjustme.com/clojure.org>
>
> 2009/7/27 John Newman 
>
>> I've been trying to get to Clojure.org <http://clojure.org> for a few
>> days now and I can't get to it from my military network, nor my civilian
>> satellite connection (I'm deployed).  I can't ping it though (resolves to
>> 75.126.104.177).  Is anyone else having the same problem?
>>
>> --
>> John
>>
>>
>>
>
> >
>


-- 
John

--~--~-~--~~~---~--~~
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: gen-class & bytecode for method implementation

[John Newman]

I'm new to Clojure so bare with me, but I'm trying to figure out what it
does...

Is it doing something like this:

user=> (apply pr (.split #"\n" (str "hello\n" "world\n")))
"hello" "world"nil

Or do you want those concatenated?  Or is that too slow?

On Tue, Jul 28, 2009 at 12:07 AM, Mark Addleman
wrote:

>
> I have written some Clojure code to implement java.lang.CharSequence
> that is constructed with a length and an ISeq of strings.  I need this
> because I want to pass the resulting CharSequence into Java's regex
> library.  I got the thing working (thanks to the docs and some good
> examples that I found in the discussion group) and I'm trying to
> optimize it now.  I'm willing to accept the Clojure code being ~2x
> slower than the Java equivalent, but the best I can do is 10x slower.
>
> The code is below.  After examining the resulting bytecode, it looks
> to me that the problem is that the Clojure compiler dispatches every
> method to an IFn that is bound as part of the class initialization.
> It's a cool idea that probably saved implementation effort but I'm
> pretty sure all the boxing/unboxing of primitives is what's killing
> the performance.
>
> My question is:  Can someone come up with a better way of implementing
> this to avoid the performance problems?
>
> ;; char_sequence
>
> (ns SeqCharSequence
>   (:gen-class
>   :implements [java.lang.CharSequence]
>   :init init
>   :state state
>   :constructors {[Integer Object] []})
>  (:use
>[clojure.contrib.test-is]))
>
>  (defstruct state-struct
>:buffer
>:strings
>:length)
>
> (defn -init [length strings]
>[[]
>(struct state-struct (StringBuilder.) (atom strings) length)])
>
> (defmacro ensure-capacity [state index]
>`(let [{#^StringBuilder buffer# :buffer} ~state]
>(while (>= ~index (. buffer# (length)))
>(let [{strings# :strings} ~state
>   strings-seq# @strings#
>   #^String newString# (first strings-seq#)]
>(. buffer# (append newString#))
>(compare-and-set! strings# strings-seq#
> (rest strings-seq#
>buffer#))
>
> (defn -charAt [#^SeqCharSequence this i]
>(let [#^StringBuilder buffer (ensure-capacity (.state this) i)]
>(. buffer (charAt i
>
> (defn -subSequence [#^SeqCharSequence this start end]
>(let [state (.state this)
>#^StringBuilder buffer (ensure-capacity
> state end)]
>(. buffer subSequence start end)))
>
> (defn -length [#^SeqCharSequence this]
>(let [{length :length} (.state this)]
>length))
>
> (defn -toString [#^SeqCharSequence this]
>(let [length (. this (length))
>#^CharSequence charSequence (. this
> subSequence 0 length)]
>(String. charSequence)))
>
> (deftest performance-test
>(let [words ["hello\n" "world\n"]
>  #^java.util.regex.Pattern pattern #"\n"]
>(time (dotimes [_ 1000]
>(let [#^SeqCharSequence cs (SeqCharSequence. 10
> words)]
>(. pattern split cs))
>
> (deftest test-length
>(let [cs (SeqCharSequence. 10 ["hello" "world"])]
>(is (= 10 (. cs (length))
>
> (deftest test-toString
>(let [cs (SeqCharSequence. 10 ["hello" "world"])]
>(is (= "helloworld" (. cs (toString))
>
> fyi - I made ensure-capacity a macro in an  effort to avoid boxing/
> unboxing before I realized how the dispatching to IFns worked.
> >
>


-- 
John

--~--~-~--~~~---~--~~
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: gen-class & bytecode for method implementation

[John Newman]

Clojure!  Not *'clothier.'*  :)

On Tue, Jul 28, 2009 at 5:05 AM, wlr  wrote:

>
> On Jul 27, 8:25 pm, John Newman  wrote:
> > I'm new to Clojure so bare with me,
>
> Sorry, can't resist... you must be seeking the naked truth. :-)
> >
>


-- 
John

--~--~-~--~~~---~--~~
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: Package manager proposal

[John Newman]

Meikel said,

>
> I think, "clojure context" is underestimating things. The high
> integration
> of external Java libraries makes it necessary that such dependencies
> can be handled in the same way.
>
>
On the other hand, will this package system be able to stradle and
accommodate future platforms for Clojure, like JS and CLR, or even Parrot
implementations?

-- 
John

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Transient Data Structures

[John Newman]

I'm a noob, so this is probably a dumb question but, how does this work with
closures?  Can transients be closed over?

Like,

(defn make-transient-counter [init-val]
>   (let [acounter (transient [init-val])]
> (fn [add-val] (assoc! acounter 0 (+ add-val (nth acounter 0))
>

Is that possible?  And if so, what are the thread-safety implications (if
any)?
...
Oh, I just re-read the description page where Rich says,

Not persistent, so you can't hang onto interim values or alias
>

So, would the above code throw an exception?

Thanks,

-- 
John

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Clojure as a First Language

[John Newman]

First of all, sorry that this post is so long-winded.  I don't have a blog,
so this seems like the best place to put to words something I've been
thinking about for a while.

One subject I haven't seen discussed is that of Clojure as a "first
language."  By that I mean, the programming language that a person first
learns before learning any other programming language.  I'm no expert at
computer programming, which is why this subject interests me in the first
place, but I do think there is a strong case for Clojure's candidacy as a
novice's first language.

I'm not sure if I can call Clojure my first language.  I've taken a 101 and
102 course in Java.  I've dabbled in Python, Ruby, and even Io, in order of
precedence.  But I've never done any significant work or projects.  I read a
lot about programming, I subscribe to many of the programming rss feeds, but
I only ever write code when it delights me, not because I have to.  And, of
most of the languages I've tried, the languages eventually got in the way
and I lost interest.  To my delight, Clojure doesn't get in my way.  I can
hack and play and explore with minimal fuss.  I've now written more in
Clojure than any other language.

Now, as to whether my positive experience with Clojure is indicative of
Clojure's appropriateness as a first language, I have to ask myself whether,
in all my years on the sidelines of programming, I've unconsciously
progressed and am no longer a novice.  In other words, am I a good subject
for this discussion -- a case study on Clojure as a first language?  I think
I am, but perhaps other programming novices like me can un-lurk, chime in,
and give their experiences.

Seeing as how Clojure is geared towards functional programming, one might
think these really advanced concepts of macros, immutability, laziness,
etc., aren't suitable for beginners.  In fact, I think languages like Haskel
have created a stigma around functional programming.  A friend of mine is in
the same boat as I am and I can't get him to try Clojure because he doesn't
feel like he can "dive in" to functional programming at this point.  True,
Clojure has some advanced concepts, but I've written some neat toy programs
in Clojure so far (a small chat server/client, a cellular automaton, some
cli tools) and I haven't used any macros, multi-methods, parameter
destructuring, or any other gizmos.  I feel confident I'll move on to those
when I'm ready.

So yes, Clojure is advanced but it is also simple and easy to understand.
 This is due in part to the homoiconicity of Clojure (and Lisp).  As a
novice, I can immediately recognize the benefits of homoiconicity, as it
lowers the bar to entry – my impression is that it provides a more uniform
canvas on which to paint, where I can say "if this works here, then it will
also work there."  The transactional memory, as it has often been compared
to garbage collection, has also significantly lowered the bar to entry for
novices like myself.  I first wrote my multi-threaded chat server/client in
Java and my Clojure version is much more readable.  The Java version worked
but the Clojure version worked correctly.

I know that it's also been argued in academic circles that Scheme (or some
functional language) should be one's first language, not Basic, because it
teaches you to think about programming the "right" way the first time.  I
can't speak with them as an expert but I can say that if they are right,
Clojure makes even more sense.  This has been my experience.  Even as a
novice, Clojure's access to Java libraries has enabled me to experiment and
learn on my own.  Keep in mind, I'm only doing it because it's fun – There's
nothing forcing me to write code.

Now, with that being said, if it's true that Clojure is indeed a good
candidate for a first language, is that worth anything?  I hope I've
stimulated some thought (and discussion) about the relationship between
Clojure and novice programmers, but I also want to argue for taking this
aspect of Clojure into account when creating the future of Clojure and it's
libraries.  Accommodating novices as a "first language" doesn't have to be a
stated design goal, but it should at least be known that the simplicity of
Clojure is a win for novices everywhere, and that can only benefit Clojure.

Specifically, I would ask, can Clojure be kept simple?  Can it even move
towards more simplicity?  If two future features in Clojure overlap to some
degree, can they be combined, for the sake of simplicity?  "More simplicity"
might cause a knee-jerk reaction in some people's minds, but it can be
argued that simplifying some things, like abstracting the first/rest
cons-cell notion from lists on to the rest of Clojure's data-structures, has
made Clojure more powerful.  For me, it's also made things easier to
understand.

As a side note, I'd like to add that the helpfulness and maturity of the
Clojure community is also a win for novices using Clojure.  Please, keep
being awesome and helpful and keep 

Re: Transient Data Structures

[John Newman]

>
> (def transhashmap (transient {})

(assoc transhashmap "a" 1)

(assoc transhashmap "b" 2)

etc


Isn't that what Rich was talking about, about not bashing in place?

On Fri, Aug 7, 2009 at 6:45 PM, Patrick Sullivan <
wizardofwestma...@gmail.com> wrote:

>
> I don't have the EXACT code handy to c/p (at work now) but I did
> something like the following.
> (apologies for doing it such an iterative looking way, never got
> comfortable with -> ;-))
>
> (def transhashmap (transient {})
> (assoc transhashmap "a" 1)
> (assoc transhashmap "b" 2)
> etc
>
> Then when I did (count transhashmap) I never got higher than 8.
> Perhaps something about the way it is handling strings/characters as a
> hash is broken?  I know my original code that screwed me up was taking
> a long text and breaking it down into wordcounts.
>
> ~Patrick
>
> On Aug 7, 7:38 am, Christophe Grand  wrote:
> > Hi Patrick !
> >
> > Can you post some code. here is what I get:
> > user=> (-> {} transient (assoc! :a 1) (assoc! :b 2) (assoc! :c 3) (assoc!
> :d
> > 4)
> > (assoc! :e 5) (assoc! :f 6) (assoc! :g 7) (assoc! :h 8) (assoc! :i 9)
> > persistent!)
> > {:a 1, :c 3, :b 2, :f 6, :g 7, :d 4, :e 5, :i 9, :h 8}
> > user=> (persistent! (reduce #(assoc! %1 (str "k" %2) %2) (transient {})
> > (range 2
> > 0)))
> > {"k0" 0, "k1" 1, "k2" 2, "k3" 3, "k4" 4, "k5" 5, "k10" 10, "k6" 6, "k11"
> 11,
> > "k7"
> >  7, "k12" 12, "k8" 8, "k13" 13, "k9" 9, "k14" 14, "k15" 15, "k16" 16,
> "k17"
> > 17,
> >  "k18" 18, "k19" 19}
> >
> > Christophe
> >
> > On Fri, Aug 7, 2009 at 10:07 AM, Patrick Sullivan <
> >
> >
> >
> > wizardofwestma...@gmail.com> wrote:
> >
> > > Testing Transient w/Hashmaps (Thanks Cristophe!) and it seems like the
> > > object won't store more then 8 keys.  At first I thought it was my
> > > frequency function
> > > that was rolling it up, but then I simply tried creating a transient
> > > object and manually assoc! ing a bunch of items into it.  After the
> > > 8th it seemed to stop taking new
> > > keys.
> >
> > > Am I doing something silly here or is this a bug?
> >
> > > ~Patrick Sullivan
> >
> > > On Aug 6, 5:53 am, Rich Hickey  wrote:
> > > > On Aug 5, 10:10 pm, Luc Prefontaine 
> > > > wrote:
> >
> > > > > I like this very much... that's the kind of clever optimizations
> that
> > > > > preserves Clojure principles and
> > > > > can yield significant performance increases. This could also help
> > > > > dealing with performance critics
> > > > > in these small mutable languages "benchmarks" that newbies attempt
> to
> > > > > clone in Clojure.
> >
> > > > > Thank's Rich !
> >
> > > > You're welcome!
> >
> > > > And special thanks to Christophe Grand, who (quickly!) applied the
> > > > same technique to the hash maps and contributed that yesterday. So
> > > > now, in the master branch, vectors and hash maps support transients.
> > > > Everyone please try them out (where appropriate :).
> >
> > > > Rich
> >
> > --
> > Professional:http://cgrand.net/(fr)
> > On Clojure:http://clj-me.blogspot.com/(en)
> >
>


-- 
John

--~--~-~--~~~---~--~~
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 as a First Language

[John Newman]

Thanks for all the responses, both on the list and off.
Many good counter-arguments were given, but I think the most compelling one
was the issue of Java-interop.  Without a doubt, at least some knowledge of
Java is necessary to really do much of anything interesting.  It's
unfortunate that such a strength, Java-interop, is also such a dependency in
terms of knowledge.  I guess I took my Java knowledge for granted.

So it seems like, as it stands now, Clojure is a tool made for people
already preoccupied with getting things done and not so much a tool for
learning to program.  It's designed for a certain purpose and that's OK.

Perhaps a better argument at this point would be that, if you are a novice
programmer and you already know Java, Clojure should be your next language
:)

--~--~-~--~~~---~--~~
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: Package manager proposal

[John Newman]

I like this idea too, because if you end up wanting to port this package
manager to CLR, Parrot, or JS, you're less tied down to the package formats
of specific platforms.

Heck, even if Clojure was ported to Ruby (not that there'd be any point to
do that), you could wrap the Gems framework.

On Sat, Aug 8, 2009 at 1:30 AM, James Reeves wrote:

>
> On Aug 7, 10:17 am, Lauri Pesonen  wrote:
> > Surely we can do better with s-expressions:
> >
> > (:repository "third-party" [(:package "Compojure" "/compojure.xml")])
>
> Not very forward compatible, though.
>
> Perhaps we should sidestep the whole question about the format of
> package metadata. At some point, the metadata will have to be parsed
> into a Clojure data structure, so we could have a parsing multimethod
> that could take a variety of different input formats.
>
> This would allow Maven repositories (in XML) to co-exist with Clojure
> repositories (in S-Exprs).
>
> - James
> >
>


-- 
John

--~--~-~--~~~---~--~~
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: A funny thing happened on the way to running Clojure

[John Newman]

In general, when writing documentation about software, you have to ask your
self "what if the user downloaded 0.9?" or "what if the user downloaded
1.1?"  How do you know what other docs someone might have written, that
might have led the user to have downloaded one version or another?  So the
doc's author was probably trying to be general, expecting you to know what
to do.  Some people won't though.

Perhaps some more specific wording like "replace 'clojure.jar' with the
version of Clojure that you have downloaded." might be of help with those
edge cases.

Welcome to Clojure!

On Sat, Aug 15, 2009 at 5:13 PM, Waysys  wrote:

>
> Today I downloaded Clojure version 1.0.0 as a new Clojure user.  I
> prepared a .cmd file to run the program.  I copied and pasted in the
> instructions from the readme file into the .cmd file:
>
> java -cp clojure.jar clojure.lang.Repl
>
> (This is also the instruction on the "Getting Started" documentation
> on the Web site.
>
> I received this error:
>
> Exception in thread "main" java.lang.NoClassDefFoundError: clojure/
> lang/Repl
>
> While preparing a blistering message on software that does not even
> start up, I noticed that the .jar file was actually named
> clojure-1.0.0.jar.  When the correct .jar file name is used, things
> work much better.
>
> However, accurate documentation is nice too.
>
> >
>


-- 
John

--~--~-~--~~~---~--~~
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: Improving the documentation

[John Newman]

I believe http://en.wikibooks.org/wiki/Clojure_Programming is the intended
central location for contributing documentation.  I've heard complaints
about it's openness though.

Is it a pain to try to contribute there?

On Tue, Aug 18, 2009 at 4:52 AM, Seth  wrote:

>
> I'm also very interested in a more public wiki for Clojure and would
> help maintain it.
>
> Seth
>
> On Aug 17, 11:39 am, Ollie Saunders  wrote:
> > OK, so given all the support this idea got and the amount of material
> > we already have. Who should I talk to about getting access to the
> > clojure.org wiki so more centralised contribution can start there?
> >
> > 2009/8/17 Mark Volkmann :
> >
> >
> >
> >
> >
> > > On Sun, Aug 16, 2009 at 8:27 PM, Chas Emerick
> wrote:
> >
> > >>> On Aug 16, 2009, at 8:52 PM, Mark Volkmann wrote:
> >
> >  I took a shot at it at
> > http://ociweb.com/mark/clojure/ClojureCategorized.html. Suggestions
> >  for changes to this are welcomed. Also check out
> > http://ociweb.com/mark/clojure/article.html.
> >
> > >> Indeed, Mark, there's a ton of great material there -- I know I
> > >> benefitted from it a number of times.  I hope you'll consider
> > >> contributing all or parts of it to whatever central resource develops.
> >
> > > Consider it contributed! Everything I've written about Clojure is
> > > freely available for inclusion in some central repository of Clojure
> > > documentation.
> >
> > > --
> > > R. Mark Volkmann
> > > Object Computing, Inc.
> >
>


-- 
John

--~--~-~--~~~---~--~~
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: Another Clojure Box - Version 1.4

[John Newman]

I like Scite but I also use Linux.

Any guidance on what steps I would need to take to port just the Scite part
of ACV to linux?  What specific config files?

Thanks,

On Fri, Sep 4, 2009 at 7:30 PM, Shantanu Kumar wrote:

>
> Not sure if I am the only one - I was not able to make the copy-to-
> REPL and execute-block-of-code work using the keyboard shortcuts
> mentioned on the URL, nor using any other method. I am using Windows
> XP 32-bit with JDK 1.6.0_16.
>
> I look forward to somebody correcting me what I am doing wrong. :-)
>
> Regards,
> Shantanu
>
> On Sep 3, 8:37 pm, Darmac  wrote:
> > Hi,
> > I just release version 1.4 of ACB.
> >
> > Changelog:
> > ++ Customized version of SciTE 2.01. It's accept \n in tooltips and
> > have a simple clojure lexer (don't use lisp lexer any more).
> > ++ Better SciTE autocomplete (recognize ?,- and others keyword
> > symbols)
> > ++ Now you can resize file explorer in SciTE (bug fixed)
> >
> > With the customized clojure SciTE lexer I have more freedom in order
> > to make SciTE more confortable (better syntax, better folding, etc.)
> >
> > Give it a try and tell me what you think!!
> >
> > http://sites.google.com/site/dariomac/Home/projects/anotherclojurebox
> >
>


-- 
John

--~--~-~--~~~---~--~~
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: Another Clojure Box - Version 1.4

[John Newman]

Would I be able to achieve the auto-complete function with just a properties
file, without having to recompile?

On Fri, Sep 4, 2009 at 11:14 PM, Darmac  wrote:

>
> John,
>
> If you want to use this version of SciTE in linux I can send you the
> scite source and you will have to compile it.
> If you don't want to compile it I can send the properties files in
> order to use the lisp lexer with your standard scite version.
>
>
> Let me know what you want!
>
> On Sep 4, 12:06 pm, John Newman  wrote:
> > I like Scite but I also use Linux.
> >
> > Any guidance on what steps I would need to take to port just the Scite
> part
> > of ACV to linux?  What specific config files?
> >
> > Thanks,
> >
> > On Fri, Sep 4, 2009 at 7:30 PM, Shantanu Kumar  >wrote:
> >
> >
> >
> >
> >
> >
> >
> > > Not sure if I am the only one - I was not able to make the copy-to-
> > > REPL and execute-block-of-code work using the keyboard shortcuts
> > > mentioned on the URL, nor using any other method. I am using Windows
> > > XP 32-bit with JDK 1.6.0_16.
> >
> > > I look forward to somebody correcting me what I am doing wrong. :-)
> >
> > > Regards,
> > > Shantanu
> >
> > > On Sep 3, 8:37 pm, Darmac  wrote:
> > > > Hi,
> > > > I just release version 1.4 of ACB.
> >
> > > > Changelog:
> > > > ++ Customized version of SciTE 2.01. It's accept \n in tooltips and
> > > > have a simple clojure lexer (don't use lisp lexer any more).
> > > > ++ Better SciTE autocomplete (recognize ?,- and others keyword
> > > > symbols)
> > > > ++ Now you can resize file explorer in SciTE (bug fixed)
> >
> > > > With the customized clojure SciTE lexer I have more freedom in order
> > > > to make SciTE more confortable (better syntax, better folding, etc.)
> >
> > > > Give it a try and tell me what you think!!
> >
> > > >http://sites.google.com/site/dariomac/Home/projects/anotherclojurebox
> >
> > --
> > John
> >
>


-- 
John

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Distributed b-tree

[John Newman]

Hello All,
I thought this might interest the group:
http://highscalability.com/paper-practical-scalable-distributed-b-tree

An interesting bit:

*Moreover, our algorithm is conceptually simple: we use transactions to
manipulate B-tree nodes so that clients need not use complicated concurrency
and locking protocols used in prior work.*


It's like a distributed hash-table, but a b-tree.

-- 
John

--~--~-~--~~~---~--~~
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: Single method interface proxies

[John Newman]

I agree though, proxy is off-putting.  It just looks so much less clean than
the rest of Clojure.

On Fri, Sep 18, 2009 at 6:43 PM, CuppoJava wrote:

>
> Hi Nikolay,
> In my opinion it's hard to reduce the verbosity of proxy without
> sacrificing some of its generality. For my own code I just made a
> new_listener macro that simply returns a new actionListener for me.
> This worked fine since 99% of the time, I only use proxies for
> actionListeners anyway. I think you're probably too focused on making
> sproxy as general as you can, which sometimes is not always better.
>
> My code simply looks like this:
>
> (new_listener
>  (println "Running")
>  (.getEventName action_event))
>
> I think that's very readable is it not?
>  -Patrick
> >
>


-- 
John

--~--~-~--~~~---~--~~
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: Managing Clojure project files

[John Newman]

Sweet!  I'd like to try it out.  Wondering, though, might blogspot
have a feature of some sort to render the code in something more
palatable?  I'd like to review it but it's a pain.

Thanks,

On 9/22/09, Emeka  wrote:
> Hello All,
>
> Please make out time and check the below link. And if you consider the code
> there useful, I  encourage you to use it.
> I would appreciate your comments and reviews.
>
> http://emekamicro.blogspot.com/2009/09/managing-clojure-project-files.html
>
> Regards,
> Emeka
>
> >
>


-- 
John

--~--~-~--~~~---~--~~
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: Getting REPL transcript

[John Newman]

I'm still learning, myself, so I could be wrong, but you might be able to
use clojure.contrib.server-socket and tweak it's binding for *in*, *out*,
and *err*, like another PushbackInputStream for *in* and copy the lines to a
file before sending it into the repl.

Or use a pipe perhaps?

-- 
John

--~--~-~--~~~---~--~~
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: immutable defs?

[John Newman]

>From what I've seen, people never redef vars in source code.  In general,
you shouldn't have to worry about users of your code redefing your vars as
it's against common convention, non-idiomatic.

The exception, as Stuart Sierra said, is when writing interactively from the
REPL, where you'd like to experiment, replacing nuts and bolts, etc.

--~--~-~--~~~---~--~~
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: immutable defs?

[John Newman]

Also, I'm not sure if your understanding of "binding" is correct.

because within any lexical scope inside a function, I can
> pretty much count on my bindings to never change.
>

binding is actually like a lexical re-def:

user=> (def x 1)
#'user/x

user=> (binding [x 2] (pr x) (binding [x 3] (pr x)) x)
232

user=> x
1

This allows us to confine var re-def to specific scope, safely -- which is
the convention over redefing a var globally.

That's my understanding of it at least.  Anyone can feel free to correct me
if I'm wrong.

--~--~-~--~~~---~--~~
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: Load Bitmap

[John Newman]

I don't know much about it, but Yann N. Dauphin's Mona Lisa program might
use what you're looking for:  Clojure: Genetic Mona Lisa problem in 250
beautiful 
lines

Here's the relevant code:

>
>1. ; grab-pixels :: BufferedImage -> [Integer]
>2. (defn grab-pixels
>3.   "Returns an array containing the pixel values of image."
>4.   [image]
>5.   (let [w (. image (getWidth))
>6. h (. image (getHeight))
>7. pixels (make-array (. Integer TYPE) (* w h))]
>8. (doto (new PixelGrabber image 0 0 w h pixels 0 w)
>9.   (.grabPixels))
>10. pixels))
>
>

On Sat, Oct 3, 2009 at 10:20 PM, prishvin  wrote:

>
> Dear friends,
>
> I have some experience in lisp and now want to write a small program
> in clojure.
> The question is,  how can I load a gray scale bitmap and how can i
> access individual pixels in it.
>
> Thank you in advance.
> M.Prishvin.
>
> >
>


-- 
John

--~--~-~--~~~---~--~~
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: Load Bitmap

[John Newman]

Actually, that code is rather dated.  An updated version might look like
this.

(Warning, not tested)

; grab-pixels :: BufferedImage -> [Integer]
(defn grab-pixels
  "Returns an array containing the pixel values of the image"
  [image]
  (let [w (.getWidth image)
h (.getHeight image)
pixels (make-array (Integer/TYPE) (* w h))]
(.grabPixels (PixelGrabber. image 0 0 w h pixels 0 w))
pixels))


On Sun, Oct 4, 2009 at 3:52 AM, John Newman  wrote:

> I don't know much about it, but Yann N. Dauphin's Mona Lisa program might
> use what you're looking for:  Clojure: Genetic Mona Lisa problem in 250
> beautiful 
> lines<http://npcontemplation.blogspot.com/2009/01/clojure-genetic-mona-lisa-problem-in.html>
>
> Here's the relevant code:
>
>>
>>1. ; grab-pixels :: BufferedImage -> [Integer]
>>2. (defn grab-pixels
>>3.   "Returns an array containing the pixel values of image."
>>4.   [image]
>>5.   (let [w (. image (getWidth))
>>6. h (. image (getHeight))
>>7. pixels (make-array (. Integer TYPE) (* w h))]
>>8. (doto (new PixelGrabber image 0 0 w h pixels 0 w)
>>9.   (.grabPixels))
>>10. pixels))
>>
>>
>

> On Sat, Oct 3, 2009 at 10:20 PM, prishvin  wrote:
>
>>
>> Dear friends,
>>
>> I have some experience in lisp and now want to write a small program
>> in clojure.
>> The question is,  how can I load a gray scale bitmap and how can i
>> access individual pixels in it.
>>
>> Thank you in advance.
>> M.Prishvin.
>>
>> >>
>>
>
>
> --
> John
>



-- 
John

--~--~-~--~~~---~--~~
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: Seq wrappers for arrays can morph

[John Newman]

When someone knowingly dips into arrays, though, aren't doing so because
they require java's semantics?  For speed, interop, or whatever?

We want to champion functional programming, but on the other hand we want to
preserve the smooth java-interop use-cases. Not an easy balancing act, I
suppose.

On Fri, Oct 30, 2009 at 9:10 PM, John Harrop  wrote:

> user=> (def x (int-array 3))
> #'user/x
> user=> x
> [0, 0, 0]
> user=> (def y (seq x))
> #'user/y
> user=> (first y)
> 0
> user=> (aset x 1 3)
> 3
> user=> x
> [0, 3, 0]
> user=> (second y)
> 3
> user=> (aset x 0 2)
> 2
> user=> x
> [2, 3, 0]
> user=> (first y)
> 2
>
> Here, (first y) returned first 0, then 2 without y being rebound in
> between. This is a bit disturbing; some seqs can't be counted on to remain
> constant. I'd expected (first y) once produced as a 0 to be carved in stone,
> while (second y) would be 3 because it would be lazily produced from the
> array only after the corresponding array cell was changed. For this, the seq
> implementation would be something analogous to
>
> (defn lazy-array-seq
>   ([arr]
> (lazy-array-seq arr 0))
>   ([arr from-idx]
> (lazy-array-seq arr 0 (count arr)))
>   ([arr from-idx end-idx]
> (if-not (= from-idx end-idx)
>   (lazy-seq (aget arr from-idx) (lazy-array-seq arr (inc from-idx)
> end-idx)
>
> but apparently it's actually just a very thin wrapper around the array,
> something like a "Java Iterator with copy-on-next semantics".
>
> Perhaps it should be changed to behave something more like the
> lazy-array-seq function above?
>
> Probably the seq wrappers for java.util collections exhibit the same ... I
> hesitate to call it a "bug", but I'm not sure it's the best choice of
> semantics. My feeling is that once realized seq values should never change,
> however the seq was produced.
>
>
> >
>


-- 
John

--~--~-~--~~~---~--~~
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 as a first programming language?

[John Newman]

I actually posted on this subject back in August.

http://groups.google.com/group/clojure/browse_thread/thread/7146112187d8468c/89ad67c6b7ec3b5c?hl=en&lnk=gst&q=clojure+as+a+first+language#

Seems like Java is the biggest bar-to-entry for programming novices learning
Clojure at this time.

On Tue, Dec 1, 2009 at 9:57 PM, Harold Ancell  wrote:

> At 09:42 AM 12/1/2009, Base wrote:
> >[...]
> >
> >I rhighly recommend you check out SICP (free HTML book herehttp://
> >mitpress.mit.edu/sicp/full-text/book/book.html and videos here
> >http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/)
>
> Note that while quite useful and fun, these lectures are based
> on the first edition of SICP.
>
> >and prepare to have your mind blown. They use Scheme in this class
> >(though I hear they have just switched to Python for this calss
> >now...!)
>
> Actually, they dropped 6.001/SICP and much if not most of
> the material it teaches :-(
>
> >which is just another Lisp with slightly different syntax.
> >It was a good place for me to start.
>
> Also check out the Open Courseware versions of 6.001; this
> is the most recent and there is an earlier archived one
> linked off of it:
>
>
> http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-001Spring-2005/CourseHome/index.htm
>
> or http://tinyurl.com/845qq
>
> Includes lots of useful stuff such as a pointer to the On-Line
> Tutor, where you can among many other things do problem sets
> and have them automagicly checked.
>
>- Harold
>
> --
> 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
>



-- 
John

-- 
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 development environments

[John Newman]

+1 for Waterfront

I was hoping it would be what IDLE is to Python.

On Fri, Dec 4, 2009 at 8:43 AM, Wilson MacGyver  wrote:

> I want to add another vote for using La Clojure plugin for IntelliJ.
>
> I use it on both OSX and windows. works pretty well for me.
>
> --
> 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
>



-- 
John

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: How to do functional programming

[John Newman]

So I've been hammocking it up recently on this subject. Just to add more
philosophical perspective - you could look at the universe in two different
ways: from the _inside_, where a thing subjectively experiences the flow of
time, as the world mutates around it; and from the _outside_, where
objectively no time exists, and the history of the universe is a static
network of immutable states, like a unidirectional graph. Animals
understand things from the _inside_ perspective, teleologically, where
things seem dynamic, contextual, and place oriented in time and space.
Physics and philosophy give us the second, ontological understanding. Some
might say the inside perspective is more intuitive while the outside
perspective is more correct or precise.

FP has an ideally unidirectional flow of causality, whereas OOP has loops,
where state flows backwards in the causal chain. A class instance is like a
state machine (to my mind) and that machine moves through time, updating
it's properties. (Banging on things in place)

FP allows you to more easily create an objective universe, where you
control all states from the outside and have absolute control over those
states. This also, however, requires more explicit definition of what you
want to occur, because the context of your transformation is not implicit
in the data itself.

OOP allows you to more easily forget about the complexities of the global,
outside context and operate under the illusion that context is built into
the instance - that the same "thing" is moving across the causal graph,
through time. Unfortunately, as our programs become more complex this
illusion breaks down and our efforts to hide the complexities of the
outside context in looping state machines makes us in fact ignorant of too
much. No, the class is not a duck. No, the method does not actually quack.
It's convenient to pretend like it does, in the small, but the inside,
subjective metaphor becomes a burden in the large.

So while FP sometimes requires more explicit definition of the desired
transformations from one state to the next, you'll end up with a lot more
hair on your head when working with large systems, if Rich and Stu's heads
are any indication :)
John


On Mon, Aug 8, 2016, 11:42 AM Gary Johnson  wrote:

> A shell script written in a procedural style (e.g. with Bash or equivalent
> shell language) will frequently start out by declaring some global
> variables, then perform some conditional checks (if then else), throw in a
> few loops (for, while), and ultimately end up with some new values in those
> initially declared variables that you use as your program's output. If you
> are feeling particularly intrepid, you might factor out some repetitive
> operations into separate subroutines defined higher up in the file and then
> call them as necessary in those aforementioned conditional blocks and loops.
>
> The mental model behind this type of programming is the Universal Turing
> Machine. Your variables are some internal state that the program
> instructions are reading and writing, reading and writing, writing and
> reading until you get to the last instruction that returns some subset of
> the final variable values. The driving principle is that computation is
> accomplished by the free mutation of state.
>
> A program written in a functional style (e.g. with any Lisp, one of the
> MLs, Haskell, Clean, etc) begins with a chunk of data, which may either be
> hard-coded, input from the outside world, or generated internally with a
> function like "range" or "rand". This piece of data may or may not be
> stored in one or more global variables. However (and this is HUGE however),
> these are not generally mutated over the life of the program. That is to
> say, they are constants. More often than not, you won't even store the
> initial data in a global variable but will just feed it into a function
> that processes it and spits out some new data, which is then fed to another
> function that performs some other processing operation and again spits out
> some new data. Ultimately, the data that you produce is passed through an
> arbitrarily long pipeline of functions until the final result is produced
> and returned by the program. In practice, these function calls are rarely
> linear and are much more likely to form a branching call tree. But
> ultimately, the relevant branches of this tree will be traversed and
> executed in a depth first manner (unless lazy evaluation inserts its magic
> to reorder some of that computation behind the scenes) and you still get to
> a final output returned by the last function fall evaluated.
>
> The mental model behind this type of programming is Lambda Calculus. There
> is no mutable state anywhere in a pure functional program, and instead the
> intermediate results are passed through the call stack from function to
> function. In practice, because stack sizes are limited, most values passed
> between functions will be boxed references pointing t

Re: Two suggestions re: core.spec, `ns`, and clojure 1.9alpha11

[John Newman]

I'd prefer getting rid of the symbol option. Some kind of deprecation
warning for a version or two might be an idea though.

On Sat, Aug 20, 2016, 10:51 PM Sean Corfield  wrote:

> Or keep the stricter compiler and:
>
> 1. People who want to port to clojurescript will incur exactly the same
> cost as they do now.
>
> **2. People who don’t want to port to clojurescript and don’t want to move
> to Clojure 1.9  will incur no additional cost.
>
> 3. Clojurescript maintainers will incur no additional cost.
>
> **4. COST REMOVED: Clojure maintainers will incur NO additional cost.
>
> 5. No one writing documentation will incur any cost, as what was not
> mentioned before will continue to be unmentioned.
>
> **6. COST REMOVED: There will be NO psychic cost because there will NOT be
> an undocumented inconsistency between clojure and clojurescript.
>
> **7. COST REMOVED: If, at some point, clojure and clojurescript shared
> code for the implementation of `ns`, neither of them would have to change
> how they interpret the ns form
>
> **8. BENEFIT ADDED: We benefit because an undocumented and unintended
> behavior went away, and one of the most confusing and complex Clojure forms
> becomes more consistent – we no longer have to explain to beginners that
> trip over (require …) mysteriously working inside ns, contrary to all the
> documentation out there, that “Yeah, we know (require …) works in ns, like
> it does outside ns, but it’s not supposed to and you shouldn’t do that –
> it’s a bug in Clojure”…
>
>
>
> --
> 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.

Re: Contribute Specter to Clojure core?

[John Newman]

I think the path navigator DSL feels slightly un-Clojurey. But other than
that, I think Specter is pure magic and Nathan is right that editing deeply
nested data structures in Clojure is a point of deficiency, especially for
people coming from mutable languages/data structures. To that extent, I
think Specter does a yeoman's job of filling that "missing piece" of
Clojure. Again, it's only the navigator DSL that feels a little un-Clojurey
to me.

On Wed, Feb 15, 2017 at 10:05 PM Alex Miller  wrote:

>
> On Wednesday, February 15, 2017 at 3:41:36 PM UTC-6, Nathan Marz wrote:
>
> Alex – care to elaborate? When I get this question it would be nice to be
> able to tell people why the core team isn't interested.
>
>
> The default answer to all such questions is no. Clojure has a small
> library and Rich wants it to remain that way.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To 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.

Re: Contribute Specter to Clojure core?

[John Newman]

Gregg, agreed. But as an aside, as an external library, like core.async,
Specter is a shining example of why Clojure (and lisp) is such an awesome
platform. The fact that Nathan was able to even implement this
functionality, in some places even more performant than core idioms, imho
proves that Clojure has power well beyond what the core team can or will
provide to users. That's a good sell for both Clojure as a platform and for
Specter as a library.

On Sat, Mar 4, 2017 at 5:39 PM Gregg Reynolds  wrote:

>
>
> On Mar 4, 2017 3:52 PM, "Gregg Reynolds"  wrote:
>
>
>
> On Mar 3, 2017 6:27 PM, "John Newman"  wrote:
>
> I think the path navigator DSL feels slightly un-Clojurey. But other than
> that, I think Specter is pure magic and Nathan is right that editing deeply
> nested data structures in Clojure is a point of deficiency, especially for
> people coming from mutable languages/data structures. To that extent, I
> think Specter does a yeoman's job of filling that "missing piece" of
> Clojure. Again, it's only the navigator DSL that feels a little un-Clojurey
> to me.
>
>
> +1.  the functionality is great, but the api imho is not just a little
> unclojurish, it's massively unclojurish.  MAP-VALS? END?  No way, for me at
> least.
>
> Specter is a specific solution to a general problem.  all such solutions
> will probably boil down to more or less the same thing,
> implementation-wise.  but the interface makes all the diff.  for example,
> it's easy to imagine a more xsl-like (or even css-like) syntax with the
> same functionality.
>
>
> more to the point, imho everything specter is doing could be expressed in
> a more naturally clojure idiom.
>
> for example, let's take the first example at ,
> https://github.com/nathanmarz/specter/blob/master/README.md, which
> amounts to "apply f to every value in a map structure, at every level".
> this would be a good thing to have. essentially, update-in with wildcards.
>  sth like (update-in-v* m even? inc) would do quite nicely, i think.
> update-in-v means map values (as opposed to update-in-k) the * makes it
> recursive, even? is the predicate that selects values, inc is the fn to
> apply.
>
> --
> 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.

Re: What makes Clojure Clojure?

[John Newman]

Yeah, only Rich can really answer that question, right? :) But for me,
Clojure is increasingly becoming cljc. When a library advertises
compatibility in both clj and cljs, it just looks shinier to me. Feels like
a trend for Clojure libraries in general. And if agents and STM were on
cljs, I'd probably reach of those tools more often on both platforms.

On that note, if some Clojure concurrency magician would implement a
lightweight threading library in cljc, which worked on both single-threaded
cljs (offloading to webworkers where available) and JVM/CLR, allowing for
STM on cljc... Hell, I'd throw down on a bounty for that. It would really
bring cljs and clj into closer parity. And it would make cljs even more
appetizing to js programmers. And it would reunite cljs with one of clj's
original selling points - how immutability and persistent structures allow
for unparalleled (lol) concurrency solutions.

I almost got a rudimentary pmap thing working in cljs on core.async with
webworkers by using a binding-hack macro I found online somewhere. I
couldn't find great docs out there though on how to implement a lightweight
threading library.

On Sat, Mar 4, 2017 at 6:51 PM Didier  wrote:

> The Specter post about if it should be made into core or not got me
> wondering what makes Clojure Clojure.
>
> I'm trying to wrap my head around what is the most minimal set of things
> that uniquely make up Clojure.
>
> Right now, in that set I've got:
>
>- The Clojure syntax and its semantics
>- The Clojure special forms and their semantics
>- The Clojure core libraries and their semantics
>
> So if I implemented a compiler that worked with the above set, it would be
> a valid Clojure compiler.
>
> Now, ClojureScript appears to me like it is not Clojure, but a dialect of
> it. I say that because it breaks some of the syntax semantics of Clojure,
> like not allowing macros in the same namespace as functions. It also breaks
> some of the core semantics, like def creating standard JS vars and not
> Clojure Vars. In this respect, a language like hy-lang is also a Clojure
> dialect, granted it shares even less of the Clojure set.
>
> Is ClojureCLR a dialect of Clojure, or is it a true Clojure implementation?
>
> One last thing that is interesting about Clojure versus other languages is
> that it does not provide standard IO. These two things make it so that it
> is kind of dependent on its host to complete its offering as a programming
> language, which means any Clojure compiler will need to provide a mechanism
> for IO. Those would always differ from Clojures to Clojures, so I don't
> think that's part of what makes Clojure Clojure.
>
> What are others thoughts on this?
>
> P.S.: There's no point to this thread, its mostly curiosity.
>
> --
> 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.

Re: Contribute Specter to Clojure core?

[John Newman]

Okay, let's call it a Context Specific Vocabulary (CSV) ;)

Every function is at least a mini DSL, IMO. And as promising as Spec
sounds, I still haven't trained up on it because of the size of the new
vocabulary (or DSL or whatever you want to call it) it introduces. Adding
semantics is expensive for users.

Just wondering here, but would it be impossible for a Specter like system
to piggyback on Specs operators for it's navigator vocabulary? Or are the
semantics between the operators and navigators too different?

On Sun, Mar 5, 2017, 2:16 PM Gregg Reynolds  wrote:

>
>
> On Mar 5, 2017 1:04 PM, "Timothy Baldridge"  wrote:
>
> >>  Specter is not a DSL.
>
> Specter implements a set of terms (navigators) specific to the library
> that are interpreted by the library (the transform function) to accomplish
> some task for a specific domain (manipulating data structures). In the same
> way, `update-in` is a DSL. Both Specter and `update-in` support certain
> operators and have certain behaviors under difference occasions. Specter
> may compile down to composed functions, or Clojure code, while `update-in`
> is always interpreted, but the net effect is still the same. They both are
> languages specific to a certain domain.
>
>
> sure, but so is + and every other operator; every op is specific to a
> computational domain (e.g. arithmetic). to me DSL means specific to an
> application domain. since Specter is not tied to any such domain, i think
> it's fair for Nathan to claim it is not a DSL. on the other hand, its
> vocabulary is quite idiosyncratic, imo.
>
> gregg
>
>
> There's noting inherently wrong with using a DSL, they have their places.
> The value of the DSL will different for each project and programmer. In
> some cases the added cognitive overhead of learning the caveats of a new
> DSL may be worth it when compared to the simplification the DSL offers.
> Other times not so much, depends on the context.
>
> Timothy
>
> On Sun, Mar 5, 2017 at 7:14 AM, Nathan Marz  wrote:
>
> To answer a few comments/misconceptions on this thread:
>
> - Specter is not a DSL. Things like ALL and MAP-VALS are first class
> objects that implement the underlying navigator interface. Specter's core
> is a high-performance method of composing implementations of that
> interface. It makes zero assumptions about what kinds of data it will be
> used for. I think any DSL for this problem would ultimately either not be
> generic enough or would be overly complex.
> - If you want to use a number as a navigator, then extend the ImplicitNav
> protocol on numbers and return (nthpath this).
> - Zippers are an advanced form of navigation, and Specter integrates them
> fully in the com.rpl.specter.zipper namespace. However, zippers add
> significant overhead and indirection, and 99.9% of the time you don't need
> them (but they do have the occasional use).
> - I wrote at length about why I think Specter fills a major hole in
> Clojure: http://nathanmarz.com/blog/clojures-missing-piece.html
>
>
> On Saturday, March 4, 2017 at 9:55:49 PM UTC-5, Herwig Hochleitner wrote:
>
> 2017-03-05 0:25 GMT+01:00 Didier :
> > I'm not too sure what the contribs are. Are they simply packages
> maintained
> > by the Clojure team itself, or are they actually part of the standard
> > library?
>
> As I understand it, they aren't any more sanctioned than any
> third-party library, but the goal is to provide a stock of clojure
> libraries under the same license as clojure itself. Also they provide
> a common CI and path into maven central.
>
> 2017-03-04 22:52 GMT+01:00 Gregg Reynolds :
> > it's easy to imagine a more xsl-like (or even css-like) syntax with the
> same
> > functionality
>
> I don't know how it squares up against specter in terms of
> performance, but I've always been fond of the selector-engine in
> enlive, from an engineering elegance POV, as an interface for tree
> query and update.
> It utilizes zippers, but only ever does a single pass (save for some
> weird selectors). Can specter substantially improve on zippers for
> this workload?
> Is there an underlying abstraction, that could sit next to clojure.zip
> or clojure.data.zip?
>
> --
> 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.
>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no wa

Re: Contribute Specter to Clojure core?

[John Newman]

The "language" Specter introduces "specific"ally navigates the "domain" of
Clojure data structures. Regexes also provide a DSL that navigate or
operate over the string/text domain and that's often considered a large,
generic, unstructured domain. What matters is the semantic surface area the
library introduces and how idiomatic those semantics are to the language.
Core.async is arguably as idiomatic as it can be, but it has a large enough
surface area that it hasn't even been folded into clojure.core. And
core.async was created by the core team.

I agree though that given the difficulty of editing deeply nested
structures in Clojure, Specter does at least make a good _candidate_ for
discussing inclusion - Nathan is asking a question that many of us ask when
we're introduced to the awesome powers of Specter, "Why can't something
like this be in core?" It's a real, ubiquitous problem in Clojure that
Specter solves, where not a lot of other solutions yet exist. But given the
core team's decision to not include core.async in core, it's hard to
imagine them including Specter's idiosyncrasies IMO.

But hey, if in a year or two some majority of all new Clojure projects on
GitHub are using Specter - and the semantics have become normalized and
idiosyncratic - then I think we could argue that maybe Specter is the Right
way. Either way, I'll be using Specter when necessary.

On Sun, Mar 5, 2017 at 3:19 PM Gregg Reynolds  wrote:

>
>
> On Mar 5, 2017 2:10 PM, "Gregg Reynolds"  wrote:
>
> see the section titled "deftype and defrecord?" at
> https://clojure.org/reference/datatypes
>
> Specter traffics in abstractions, afaik, just like clojure. it does not
> depend in any way on application concepts like "bank account", so i think
> it's a little unfair to call it x-specific for any x; that makes it sound
> less general than clojure itself, which i do not believe is the case. so it
> is indeed a good _candidate_ for core.  but since i think there are many
> unexplored ways to do the same thing, its too soon.  Not to mention the
> aesthetic question of whether all the UPPER CASE stuff is a good idea.
> Personally i find it a little too magical and opaque.
>
> gregg
>
>
> ps. just as food for thought, what xslt does for xml trees is very similar
> to what specter does for clojure structures. if you're familiar with xslt
> it's not that hard to imagine sth similar in idiomatic clojure that would
> solve the same problems with a very different vocab.
>
> g
>
> --
> 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.

Re: Doc strings for complex cases?

[John Newman]

Way back when - when Rich was fielding suggestions for how to do doc
strings - I made the offhand comment that every arity could have it's own
doc string.

He didn't like the idea back then. Doubtful he will now. I'm glad he went
the route he did.

I believe the discussion took place on this mail list.

On Nov 9, 2017 3:53 PM, "Mikhail Gusarov"  wrote:

> Hello.
>
> > Should any breaking changes occur in Clojure core,
>
> Why should they?
>
> Regards,
> Mikhail.
>
> --
> 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.

Re: [core.spec] Stricter map validations?

[John Newman]

Great conversation! I'm still catching up on Spec, but it seems like 
there's a correlation here to type systems. Type systems can introduce a 
certain kind of technical debt - type debt? It seems that leaving maps open 
here is also attempting to avoid that sort of type debt - parochial maps 
that don't play nice with others. And when we constrain maps in that closed 
way, aren't we creating some new subtype of a map, with fundamentally 
different semantics? If you are going to fully close a map, you might as 
well use a deftype and make a custom object and not call it a map, right?

On Wednesday, November 15, 2017 at 11:34:04 AM UTC-5, Eric Normand wrote:
>
> Wow, this has been a really great discussion. I have only played with spec 
> a little, not used it in production. Reading this and participating has 
> really helped me clarify a lot of things. Thanks!
>
> In particular, I've been thinking a lot about the three things you 
> mentioned, Didier: safety, compatibility, and correctness. I think it's 
> great that you pulled them apart. I've written a number of public-facing 
> APIs in my day, and what I always wound up doing was being really strict 
> with the clients because it actually helps correctness. It helps give 
> really fast feedback to third parties writing client code because they get 
> error messages about everything that's wrong with their request. Anything 
> that's silently accepted could mask a bigger problem and, especially with 
> third-party clients, you want to get those problems out in the open as soon 
> as possible.
>
> But the more I look at the behavior of s/keys, the more I'm starting to 
> appreciate it. It's not trying to be strict to educate clients. It's for 
> asking "does this have the minimum I need to handle this map?" And this is 
> very much how idiomatic Clojure is written. We ignore keys we don't care 
> about and pass them along. Or we select only the keys we care about and 
> operate on those. I wonder why we don't want to do this with our APIs. It's 
> so comfortable and practical internally.
>
> Now, the educational value of strictness (as developers write clients for 
> our API) is important. But it doesn't seem to be in the purview of spec. 
> I've been thinking about a few guidelines, because I haven't seen them 
> written down:
>
> 1. Use namespaced keywords with globally unique namespaces that you own.
> 2. Don't "invent" keys in a namespace you don't own.
> 3. Validate the keys you care about, to ensure that you have the minimum 
> you need to continue (using a s/keys spec) with appropriate types.
> 4. Handle extra keys you can't use in the appropriate way (ignore them and 
> pass them on OR select only the ones you want).
>
> With these, you actually do get a lot of the safety and correctness you're 
> talking about, but it's more of a systemic safety (unexpected input won't 
> break the system) and safety across changes (growth).
>
> There are still two problems that this won't solve. The first is the OP's 
> original problem, which was typos in keys allowing values with bad types to 
> get through a s/valid? check. That's serious but could easily be checked 
> with Stuart's code, using what Spec provides. So I think that's a real 
> solution provided by Spec. You could check in a test, for instance.
>
> The second problem is that education problem: you want clients to know 
> when they send typos, not just silently ignore them. I think this is 
> important. We've already got s/valid?, which asks "can I handle this?". 
> Maybe you could implement something called strict? that takes a spec and a 
> value and makes sure there aren't any extra keys. It doesn't seem to belong 
> in the spec. To me, it should go in a function which you could deploy when 
> you need it.
>
>
> Rock on!
> Eric
>
> On Tuesday, November 14, 2017 at 8:04:34 PM UTC-6, Didier wrote:
>>
>> | I think you're assuming you're validating API endpoints where client 
>> and server are tightly coupled. I can imagine a microservices system where 
>> some services put maps on a queue and others consume them. The consumers 
>> should allow keys they don't understand. They and also need to validate 
>> that the keys they need are there and of the right shape.
>>
>> That use case sounds more like the exception then the rule to me. I still 
>> think its valid, and for that I recognise there should be a way to have a 
>> spec which allows any key and requires specific ones.
>>
>> Now that I've listened to everyone, I see that there might be many things 
>> needed by different people, and its not clear if all should be provided by 
>> spec directly.
>>
>> Mostly I can see wanting:
>>   A. To spec a map in which you expect the keys to have a registered spec.
>>   B. To spec a map in which you don't expect the keys to have a 
>> registered spec.
>>   1. To spec a map in which the keys should be closed to only the req and 
>> opt keys that are defined. 
>>   2. To spec a map in which the keys should 

Re: Immutable names of things?

[John Newman]

This might be a step towards a more clojury way:
http://blog.datomic.com/2012/10/codeq.html

John

On Mon, Dec 11, 2017 at 7:53 PM, Didier  wrote:

> I'll have a look at all these other projects, its very interesting. Unison
> seems to embody the spirit or Richs talk about never changing anything too.
> I guess I was trying to think how could you bring some of this to Clojure.
> And in a way, if the constructs like functions had an id and a name, you
> could start building out things like that more so. Which is where I thought
> about the potential of considering the existing name as an id, and having
> something else for naming the construct.
>
> I guess, if I think about it some more, Clojure could save its code as the
> AST straight up using EDN. Someone could build an IDE on top of that, which
> never allows you to change the text, but only works directly at the EDN
> level with the clojure code as data. It would be a lot of work, but
> possible I think.
>
>
> On Monday, 11 December 2017 16:12:37 UTC-8, Eric Normand wrote:
>>
>> Hi Didier,
>>
>> Are you familiar with Unison (http://unisonweb.org/)? It has this same
>> feature. Functions are named by a hash of their code (the AST). Names refer
>> to hashes. So if you want to recompile a function, you can optionally
>> choose newer versions of all of the functions. But changing a function's
>> code does not make the old version go away. Other functions compiled
>> against the old versions will still use the old versions. It basically
>> pushes the version control down to the function level instead of the whole
>> project.
>>
>> The effect was that you could have a dynamically-recompiled language
>> experience without breaking anything that was already compiled. You could
>> redefine everything about a function (it's type signature, it's code, etc)
>> but existing stuff would keep working. Then when the function was to your
>> liking, you could recompile everything to use the new version.
>>
>> Eric
>>
>>
>>
>> On Wednesday, December 6, 2017 at 11:37:10 PM UTC-6, Didier wrote:
>>>
>>> Warning: This is the spawn of an idea, not very well refined, and that
>>> is little extravagant.
>>>
>>> I've been doing some hammock time, and I've been thinking that names in
>>> a programming language are kind of a complecting of two things, the human
>>> readable form, and the machine identifier. What if a function always had
>>> the same name, which never changed, from the moment the function was
>>> created. This would be fine, until a human finds it didn't like the name
>>> anymore, and thus a refactor of the name would occur, requiring to change
>>> all references to the function. This is also true say of a spec, if you
>>> want to change the name of the spec, its a big refactor to update all usage
>>> of it. So var names and spec names are troubling in that if humans want to
>>> refer to it differently, they also break all machine reference to them.
>>>
>>> So I thought, how awesome would it be if each named things in a
>>> programming language would be given a unique machine name, which can be
>>> used everywhere, and the name you saw was just meta-data for the programmer
>>> to have a more human readable/descriptive name.
>>>
>>> The problem is I'm not sure how to do this with a text based programming
>>> language. I can imagine a language where constructs would be first class,
>>> not based on text, and thus all construct could be assigned a unique id and
>>> a name, and the IDEs could easily hide the unique ids and project a view of
>>> the construct with the human name instead. Code would be stored in a
>>> structured format, and obviously a standard editor would not work, and an
>>> IDE of some form would be required.
>>>
>>> So right now, my idea is that maybe you can compromise. If you added
>>> support for Vars and specs, so that they can have like a doc-name. It would
>>> be like a doc-string a bit, but it expects a name instead. That name could
>>> be the human readable name, you could change it freely. The normal var name
>>> or spec name would continue to be used as normal to refer to this var/spec
>>> from other code. At its most basic it means you can have the normal name be
>>> anything, maybe a name you don't like that much, or you could go further
>>> and make it a guid if you want. Then you could make the doc-name the name
>>> you want to use when talking to other people, or when people read the code.
>>> Now IDEs could support this doc-name, so they could show the doc-name in
>>> place everywhere you have code referring to the normal name. They could
>>> auto-complete from doc-name to normal name, etc.
>>>
>>> So an IDE could still kind of hide this for you, and make it appear like
>>> everything is just doc-name pointing to each other, and refactoring would
>>> not require changing all code that refers to it, but actually its just a
>>> change of the doc-name on the var or spec being pointed to, but the IDE
>>> could quickly replace the new doc

Re: Immutable names of things?

[John Newman]

What if the code segments were hashed by zipper coordinates instead of
line-column location? I like this idea of structurally navigating the code
as an AST of EDN :)

John

On Mon, Dec 11, 2017 at 7:55 PM, John Newman  wrote:

> This might be a step towards a more clojury way: http://blog.datomic.com/
> 2012/10/codeq.html
>
> John
>
> On Mon, Dec 11, 2017 at 7:53 PM, Didier  wrote:
>
>> I'll have a look at all these other projects, its very interesting.
>> Unison seems to embody the spirit or Richs talk about never changing
>> anything too. I guess I was trying to think how could you bring some of
>> this to Clojure. And in a way, if the constructs like functions had an id
>> and a name, you could start building out things like that more so. Which is
>> where I thought about the potential of considering the existing name as an
>> id, and having something else for naming the construct.
>>
>> I guess, if I think about it some more, Clojure could save its code as
>> the AST straight up using EDN. Someone could build an IDE on top of that,
>> which never allows you to change the text, but only works directly at the
>> EDN level with the clojure code as data. It would be a lot of work, but
>> possible I think.
>>
>>
>> On Monday, 11 December 2017 16:12:37 UTC-8, Eric Normand wrote:
>>>
>>> Hi Didier,
>>>
>>> Are you familiar with Unison (http://unisonweb.org/)? It has this same
>>> feature. Functions are named by a hash of their code (the AST). Names refer
>>> to hashes. So if you want to recompile a function, you can optionally
>>> choose newer versions of all of the functions. But changing a function's
>>> code does not make the old version go away. Other functions compiled
>>> against the old versions will still use the old versions. It basically
>>> pushes the version control down to the function level instead of the whole
>>> project.
>>>
>>> The effect was that you could have a dynamically-recompiled language
>>> experience without breaking anything that was already compiled. You could
>>> redefine everything about a function (it's type signature, it's code, etc)
>>> but existing stuff would keep working. Then when the function was to your
>>> liking, you could recompile everything to use the new version.
>>>
>>> Eric
>>>
>>>
>>>
>>> On Wednesday, December 6, 2017 at 11:37:10 PM UTC-6, Didier wrote:
>>>>
>>>> Warning: This is the spawn of an idea, not very well refined, and that
>>>> is little extravagant.
>>>>
>>>> I've been doing some hammock time, and I've been thinking that names in
>>>> a programming language are kind of a complecting of two things, the human
>>>> readable form, and the machine identifier. What if a function always had
>>>> the same name, which never changed, from the moment the function was
>>>> created. This would be fine, until a human finds it didn't like the name
>>>> anymore, and thus a refactor of the name would occur, requiring to change
>>>> all references to the function. This is also true say of a spec, if you
>>>> want to change the name of the spec, its a big refactor to update all usage
>>>> of it. So var names and spec names are troubling in that if humans want to
>>>> refer to it differently, they also break all machine reference to them.
>>>>
>>>> So I thought, how awesome would it be if each named things in a
>>>> programming language would be given a unique machine name, which can be
>>>> used everywhere, and the name you saw was just meta-data for the programmer
>>>> to have a more human readable/descriptive name.
>>>>
>>>> The problem is I'm not sure how to do this with a text based
>>>> programming language. I can imagine a language where constructs would be
>>>> first class, not based on text, and thus all construct could be assigned a
>>>> unique id and a name, and the IDEs could easily hide the unique ids and
>>>> project a view of the construct with the human name instead. Code would be
>>>> stored in a structured format, and obviously a standard editor would not
>>>> work, and an IDE of some form would be required.
>>>>
>>>> So right now, my idea is that maybe you can compromise. If you added
>>>> support for Vars and specs, so that they can have like a doc-name. It would
>>>> be like a doc-string a bit, but it expects a name ins

Re: Simulations in Clojure/Clojurescript

[John Newman]

You might want to look into Chris Granger's work on component entity
systems in clojurescript:
http://www.chris-granger.com/2012/12/11/anatomy-of-a-knockout/

Light Table went on to have a similar component-entity layout internally.

On Jan 10, 2018 6:12 PM, "Michael Nardell"  wrote:

> Greetings :: I am new to Clojure and have not really gotten my feet wet
> with Clojurescript yet. The advice I always give someone when leaning
> programming or a new language is to pick a project that they are interested
> in and dive in. For me, that project would be creating educational
> simulations that model complex systems.
>
> Part of my challenge with this as a project is that it is leading me
> towards programming (at least partially) with objects to model the discrete
> components in these systems. Arguably simulations are one of the domains
> where objects are the right paradigm. The question I pose to the group is
> how to work with objects in Clojure, in a manner that "goes with the grain"
> of the language. Perhaps best to ground my question in a concrete example:
>
> I had created simulations / visualizations of Hubel and Wiesel's model of
> the  center-surround receptive fields in the retina. My past simulations I
> used a collection of objects to model  photo receptors (i.e. rods/cones),
> horizontal, bi-polar cells, connected together to represent the behavior of
> either on-center or off-center receptive fields. Kind of a simple neural
> network. Would like to preserve the object nature of nodes in the network,
> since the nodes have state and should be represented by graphics in a gui.
> Ultimately I would like to move toward a "constructor kit" approach that
> would allow students and teachers to model and simulate a whole variety of
> various systems that can be represented as a network of processes with
> feed-forward and feed-back connections.
>
> Interested to know of any useful examples and guidance for doing objects
> the Clojure/Clojurescript way. Certainly one of the examples I want to look
> at closely is the Ant Hill that Rich Hickey demonstrated.
>
> As is the case with a neophyte - any advice is well appreciated.
>
> Mike
>
> --
> 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.

Re: what does future do after fn finish ?

[John Newman]

Agents manage a pool of threads for you. Try doing it without the future
call and see if that works (unless you're trying to do something else).

John

On Wed, Jan 31, 2018 at 7:31 PM, Jacek Grzebyta 
wrote:

> Thanks a lot. I will check it tomorrow.
>
> J
>
> On 1 Feb 2018 12:12 a.m., "Justin Smith"  wrote:
>
>> this is exactly the kind of problem code I was describing - there's no
>> backpressure on existing future tasks to hold up the launching of more
>> futures - the work done by the agent calling conj is negligible. You need
>> to control the size of the pool of threads used, and you need to impose
>> back-pressure.
>>
>> On Wed, Jan 31, 2018 at 3:46 PM Jacek Grzebyta 
>> wrote:
>>
>>> On 31 January 2018 at 18:08, James Reeves  wrote:
>>>
 On 31 January 2018 at 17:59, Jacek Grzebyta 
 wrote:

> I have application with quite intense tripe store populating ~30/40 k
> records per chunk (139 portions). The data are wrapped within the future:
>
> (conj agent (future (apply task args)))
>
>  and that all together is send-off into (agent []).
>

 What is "agent"? The first line of code indicates that it's a local
 collection shadowing the code function, while the second code snippet
 indicates that you're using the core agent function.

 Also why are you sending off to an agent?

>>>
>>> I have ~8sec computing task for each input dataset which generates those
>>> records. After that I write it into disk (in software-specific
>>> transaction). I just wanted to separate hard computing and io operations. I
>>> created a side-effect method which is injected together with the dataset
>>> into a future. The futures are async collected within a list wrapped in
>>> agent. After the computing the main thread is waiting until all io tasks
>>> will be finished.
>>>
>>>

 At the end of the main thread function I just use await-for and after
> that:
>
> (reduce + (map #(deref %) @data-loading-tasks))
>

>>> As a control, tasks return number of written records.
>>>
>>>
>>>

> For some reason I see the happy collecting (see attached screenshot of
> jconsole).
>

 "happy" = "heap"?

>>>
>>> Both. As you can see on attached screenshot the heap usage grows easy
>>> until aver. ~2 1/4 G than keep that  for a few minutes. In that moment I
>>> stopped. After that starts grow till ~4G with tendency to do jumps a bit
>>> more that 4G.
>>>
>>>


> After seeing the source code of future I suppose that the memory (data
> are kept as #{} set) is not released. The task returns only integer so I 
> do
> not think that might cause the problem.
>

 Can you provide more detail? You keep alluding to things that you don't
 provide code for, such as the sets of data.

>>>
>>>
>>> The code is attached. However the important code is
>>>
>>> L123 .
>>>   (let [;; keeps all data loading futures.
>>> ;; waiting until all futures are finished
>>> ;; should be done outside the main loop
>>> data-loading-tasks (agent [])]
>>>
>>> L128
>>> (doseq
>>>  (let [r1 (long operation)]   L133
>>>  (doseq
>>> (let [r2 (v.v. long)]   L155
>>>
>>>   L163   (send-off data-loading-task conj-task)
>>>
>>>  )
>>>  )
>>> )
>>> )
>>>
>>>
>>> I guess first I will move data-loading-tasks list into one of inner
>>> lets. Also I will create within an injecting function a separate abstract
>>> function let inside. The task will populate tmp variable which will be
>>> returned as a future result:
>>>
>>>
>>> L114 (conj agent (future (apply (fn [] (let [result (apply task args)]
>>> result)
>>>
>>>

 --
 James Reeves
 booleanknot.com

 --
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with
 your first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en
 ---
 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.goo

Re: what does future do after fn finish ?

[John Newman]

Multiple sen-doffs to one agent will serialize it's calls, but spawning
agents on each new task will spawn threads on a bounded thread pool, I
believe.

On Jan 31, 2018 8:32 PM, "Justin Smith"  wrote:

> Doing all the actions via one agent means that the actions are serialized
> though - you end up with no performance improvement over doing them all in
> a doseq in one future - the right way to do this tends to be trickier than
> it looks at first glance, and depends on your requirements. agents, the
> claypoole library, and reducers are all potentially useful. If
> parallelization leads to complex coordination needs, core.async can help
> too.
>
> On Wed, Jan 31, 2018 at 5:18 PM John Newman  wrote:
>
>> Agents manage a pool of threads for you. Try doing it without the future
>> call and see if that works (unless you're trying to do something else).
>>
>> John
>>
>> On Wed, Jan 31, 2018 at 7:31 PM, Jacek Grzebyta 
>> wrote:
>>
>>> Thanks a lot. I will check it tomorrow.
>>>
>>> J
>>>
>>> On 1 Feb 2018 12:12 a.m., "Justin Smith"  wrote:
>>>
>>>> this is exactly the kind of problem code I was describing - there's no
>>>> backpressure on existing future tasks to hold up the launching of more
>>>> futures - the work done by the agent calling conj is negligible. You need
>>>> to control the size of the pool of threads used, and you need to impose
>>>> back-pressure.
>>>>
>>>> On Wed, Jan 31, 2018 at 3:46 PM Jacek Grzebyta 
>>>> wrote:
>>>>
>>>>> On 31 January 2018 at 18:08, James Reeves 
>>>>> wrote:
>>>>>
>>>>>> On 31 January 2018 at 17:59, Jacek Grzebyta 
>>>>>> wrote:
>>>>>>
>>>>>>> I have application with quite intense tripe store populating ~30/40
>>>>>>> k records per chunk (139 portions). The data are wrapped within the 
>>>>>>> future:
>>>>>>>
>>>>>>> (conj agent (future (apply task args)))
>>>>>>>
>>>>>>>  and that all together is send-off into (agent []).
>>>>>>>
>>>>>>
>>>>>> What is "agent"? The first line of code indicates that it's a local
>>>>>> collection shadowing the code function, while the second code snippet
>>>>>> indicates that you're using the core agent function.
>>>>>>
>>>>>> Also why are you sending off to an agent?
>>>>>>
>>>>>
>>>>> I have ~8sec computing task for each input dataset which generates
>>>>> those records. After that I write it into disk (in software-specific
>>>>> transaction). I just wanted to separate hard computing and io operations. 
>>>>> I
>>>>> created a side-effect method which is injected together with the dataset
>>>>> into a future. The futures are async collected within a list wrapped in
>>>>> agent. After the computing the main thread is waiting until all io tasks
>>>>> will be finished.
>>>>>
>>>>>
>>>>>>
>>>>>> At the end of the main thread function I just use await-for and after
>>>>>>> that:
>>>>>>>
>>>>>>> (reduce + (map #(deref %) @data-loading-tasks))
>>>>>>>
>>>>>>
>>>>> As a control, tasks return number of written records.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>> For some reason I see the happy collecting (see attached screenshot
>>>>>>> of jconsole).
>>>>>>>
>>>>>>
>>>>>> "happy" = "heap"?
>>>>>>
>>>>>
>>>>> Both. As you can see on attached screenshot the heap usage grows easy
>>>>> until aver. ~2 1/4 G than keep that  for a few minutes. In that moment I
>>>>> stopped. After that starts grow till ~4G with tendency to do jumps a bit
>>>>> more that 4G.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>> After seeing the source code of future I suppose that the memory
>>>>>>> (data are kept as #{} set) is not released. The task returns only 
>>>>>>> integer
>>>>>>> so 

Re: what does future do after fn finish ?

[John Newman]

Ah, he's using one agent, I see.

On Jan 31, 2018 9:15 PM, "John Newman"  wrote:

> Multiple sen-doffs to one agent will serialize it's calls, but spawning
> agents on each new task will spawn threads on a bounded thread pool, I
> believe.
>
> On Jan 31, 2018 8:32 PM, "Justin Smith"  wrote:
>
>> Doing all the actions via one agent means that the actions are serialized
>> though - you end up with no performance improvement over doing them all in
>> a doseq in one future - the right way to do this tends to be trickier than
>> it looks at first glance, and depends on your requirements. agents, the
>> claypoole library, and reducers are all potentially useful. If
>> parallelization leads to complex coordination needs, core.async can help
>> too.
>>
>> On Wed, Jan 31, 2018 at 5:18 PM John Newman  wrote:
>>
>>> Agents manage a pool of threads for you. Try doing it without the future
>>> call and see if that works (unless you're trying to do something else).
>>>
>>> John
>>>
>>> On Wed, Jan 31, 2018 at 7:31 PM, Jacek Grzebyta 
>>> wrote:
>>>
>>>> Thanks a lot. I will check it tomorrow.
>>>>
>>>> J
>>>>
>>>> On 1 Feb 2018 12:12 a.m., "Justin Smith"  wrote:
>>>>
>>>>> this is exactly the kind of problem code I was describing - there's no
>>>>> backpressure on existing future tasks to hold up the launching of more
>>>>> futures - the work done by the agent calling conj is negligible. You need
>>>>> to control the size of the pool of threads used, and you need to impose
>>>>> back-pressure.
>>>>>
>>>>> On Wed, Jan 31, 2018 at 3:46 PM Jacek Grzebyta 
>>>>> wrote:
>>>>>
>>>>>> On 31 January 2018 at 18:08, James Reeves 
>>>>>> wrote:
>>>>>>
>>>>>>> On 31 January 2018 at 17:59, Jacek Grzebyta 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I have application with quite intense tripe store populating ~30/40
>>>>>>>> k records per chunk (139 portions). The data are wrapped within the 
>>>>>>>> future:
>>>>>>>>
>>>>>>>> (conj agent (future (apply task args)))
>>>>>>>>
>>>>>>>>  and that all together is send-off into (agent []).
>>>>>>>>
>>>>>>>
>>>>>>> What is "agent"? The first line of code indicates that it's a local
>>>>>>> collection shadowing the code function, while the second code snippet
>>>>>>> indicates that you're using the core agent function.
>>>>>>>
>>>>>>> Also why are you sending off to an agent?
>>>>>>>
>>>>>>
>>>>>> I have ~8sec computing task for each input dataset which generates
>>>>>> those records. After that I write it into disk (in software-specific
>>>>>> transaction). I just wanted to separate hard computing and io 
>>>>>> operations. I
>>>>>> created a side-effect method which is injected together with the dataset
>>>>>> into a future. The futures are async collected within a list wrapped in
>>>>>> agent. After the computing the main thread is waiting until all io tasks
>>>>>> will be finished.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> At the end of the main thread function I just use await-for and
>>>>>>>> after that:
>>>>>>>>
>>>>>>>> (reduce + (map #(deref %) @data-loading-tasks))
>>>>>>>>
>>>>>>>
>>>>>> As a control, tasks return number of written records.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>> For some reason I see the happy collecting (see attached screenshot
>>>>>>>> of jconsole).
>>>>>>>>
>>>>>>>
>>>>>>> "happy" = "heap"?
>>>>>>>
>>>>>>
>>>>>> Both. As you can see on attached screenshot the heap usage grows easy
>>>>>> until aver. ~2 1/4 G than keep that  for a few minutes. In that moment I
>>&g

Re: [ANN] Schism, a set of CRDTs for Clojure and ClojureScript

[John Newman]

Wow, this is really cool!

Could you describe how one might go about using this to implement, say, a
crdt chat room using maps and sets? Can I for instance just push crdts
between clients in a serverless fashion?

Perhaps some examples would be instructive, but I've been hoping for
something just like this recently, so thanks!

V/r

John

On Wed, Apr 18, 2018, 9:05 PM Alex Redington  wrote:

> Good evening!
>
> I submit for your evaluation and reasoned feedback a library I've been
> working on to provide a set of convergent replicated data types to Clojure
> and ClojureScript:
>
> https://github.com/aredington/schism
> [com.holychao/schism "0.1.0"]
>
> Schism provides convergent collections for sets, vectors, lists, and maps,
> along with edn readers and writers out of the gate. My intent is to provide
> you with all the tools necessary to replicate a collection across two or
> more computing nodes.
>
> Replication is a hard problem, so there are a few caveats to these tools
> as I provide them:
>
> - You must identify nodes within your cluster. You may choose to identify
> nodes with a random UUID, in which case schism will help you to do so. Node
> identifiers must be clojure serializable data.
> - Schism purposefully avoids carrying around a monotonically increasing
> historical collection of data about deleted entries. Consequently there are
> some ambiguities during convergence that may not exactly mirror local
> modification.
> - Schism is only solving the problem of synchronizing two in memory sets.
> Maintaining identity of those two sets, tracking state changes, and long
> term durability are responsibilities left to the schism user.
>
> Schism collections are persistent collections, so you should feel free to
> work with them as a drop in replacement for a function which would work
> against a Clojure collection. The usual utilities such as conj, assoc,
> dissoc, disj, and rest are pure functions which will return you derived
> copies, implicitly soing the convergence bookkeeping necessary in the
> background. As you work with it, schism will maintain node and timestamp
> information, with the goal of convergence providing the same result as if
> all previous invocations had occurred on one local collection in memory.
> Schism's requirements are your expectations of a Clojure collection, so
> hash, =, and support for meta are all included, as well as many other
> functions defined against Clojure's own collections. Particularly with hash
> and =, you can expect a schism collection to return the same hashcode as
> its Clojure equivalent, and to determine equality in the same way as its
> Clojure equivalent would.
>
> I've built schism in the absence of a direct itch to scratch with it.
> Should you find that it betrays your expectations of Clojure collections,
> I'd greatly appreciate a bug report and will work to correct schism quickly.
>
> I hope that it assists you in solving your own problems.
>
> -Alex
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note 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.

Re: [ANN] Schism, a set of CRDTs for Clojure and ClojureScript

[John Newman]

Alex, yeah that explains it for me. I'll probably want to use a fully
connected address space, via a mesh or a hub and spoke topology, that I
fully manage - so this is the perfect level of abstraction for me. I'd like
to see that ZQ implementation though.

So, to be clear, if node A sends schism-map M to node B, both A and B
update M, B sends M back to A, A converges M1 and M2: If M1 and M2 have
destructive conflicts, does the most "recent" change win? Or does the local
copy win?

Thanks,

V/r

John

John

On Thu, Apr 19, 2018 at 8:55 AM, Alex Redington 
wrote:

> I'll try to answer this question and John's at the same time.
>
> Schism does not try to manage state for you over time; there are a lot of
> good tools for doing that already (atoms, refs, agents, channels, etc).
> Schism is a set of collections that augment basic clojure collections with
> enough additional information that you can take two persistent collections
> with common ancestry and merge them together. So, you could take a schism
> map held in an atom, dereference it and send it from a pedestal process to
> an om application as edn, and read-string it in the om app to have a
> replicated copy of the map. The om app could make some changes (dissoc one
> key, update another) without communicating to the pedestal app for each
> operation. Then send it back to the pedestal app in a POST body, and the
> pedestal app would swap! the atom using schism.core/converge and the value
> it just received from om. The changes, both additive and destructive, would
> be replicated in the atom's value.
>
> So, yes, you could build a serverless chatroom where each client held an
> atom with a schism collection, and they sent their copies around using
> WebRTC to stay in sync. You could push a schism edn serialization over a
> message queue to be synchronized on the other end. I anticipate pushing
> each discrete state over the mq with an add-watch hook might yield bad
> performance for little semantic gain. Schism collections are necessarily
> more expensive than Clojure collections in serialization size, and
> synchronization is where all of the signficant computational expense of
> these kinds of data structures resides, so doing it less frequently than
> every discrete update will probably be best. (A debounced send & sync that
> guaranteed transmission after n milliseconds of being inert would make
> sense to me)
>
> I'm not presently confronting a problem that these solve in my day job; my
> intent was to build and have the tool ready if and when we wanted to have
> better answers for "offline sync" in a single page ClojureScript
> application.
>
> Thank you for the great questions!
>
> -Alex
>
> On Wednesday, April 18, 2018 at 9:55:36 PM UTC-4, Luke Burton wrote:
>>
>>
>> This is cool!
>>
>> There seems to be some room for a recommendation on how to apply these
>> data structures effectively in practice, especially around the distribution
>> mechanism. For instance, I can imagine storing these in an atom and using
>> watchers to push changes out over zero-mq. Or is that the Worst Idea Ever™?
>> I feel like the transit layer probably has *some* impact on whether CRDTs
>> are the right solution to the problem, and I'm interested to know what
>> those boundaries are.
>>
>> Have you used them in production over the network, and if so, what
>> solution did you use?
>>
>> Thanks again!
>>
>>
>>
>> On Apr 18, 2018, at 5:57 PM, Alex Redington  wrote:
>>
>> Good evening!
>>
>> I submit for your evaluation and reasoned feedback a library I've been
>> working on to provide a set of convergent replicated data types to Clojure
>> and ClojureScript:
>>
>> https://github.com/aredington/schism
>> [com.holychao/schism "0.1.0"]
>>
>> Schism provides convergent collections for sets, vectors, lists, and
>> maps, along with edn readers and writers out of the gate. My intent is to
>> provide you with all the tools necessary to replicate a collection across
>> two or more computing nodes.
>>
>> Replication is a hard problem, so there are a few caveats to these tools
>> as I provide them:
>>
>> - You must identify nodes within your cluster. You may choose to identify
>> nodes with a random UUID, in which case schism will help you to do so. Node
>> identifiers must be clojure serializable data.
>> - Schism purposefully avoids carrying around a monotonically increasing
>> historical collection of data about deleted entries. Consequently there are
>> some ambiguities during convergence that may not exactly mirror local
>> modification.
>> - Schism is only solving the problem of synchronizing two in memory sets.
>> Maintaining identity of those two sets, tracking state changes, and long
>> term durability are responsibilities left to the schism user.
>>
>> Schism collections are persistent collections, so you should feel free to
>> work with them as a drop in replacement for a function which would work
>> against a Clojure collection. The usual utilities such as conj, assoc,
>

Re: [ANN] clj-new -- creating new Clojure projects using the clj CLI

[John Newman]

These are nice ideas... Sort of like nmp. But you could implement this
yourself as a lib and stick it behind a `clj -A:install ...` tool.

@dominicm (on clojurians.slack) has build an "injector" tool into pack,
which you could reimplement into something that you're describing:
https://github.com/juxt/pack.alpha/blob/master/src/mach/pack/alpha/inject.clj

Who knows, maybe if some of these aliases get super popular and
standardized, we can convince Alex to fold some of them into the tools over
time :)

V/r

John

John

On Thu, Apr 19, 2018 at 3:18 AM, Didier  wrote:

> Ah, awesome.
>
> I guess I'm starting to think, it would be great if clj supported
> something like:
>
> clj --install alias-name alias-url
>
> So maybe in a repo, you could put a file of a given convention in the root
> with a common name. Clj could pull it, it would contain a clj alias in it,
> and clj would auto add it to your deps.edn file as an alias. You could add
> a -g option to add it to your global deps.edn, if you wanted to "install"
> it globally.
>
> Nothing else would happen.
>
> But then, you could run your newly "installed" clojure program by doing:
>
> clj -A:alias-name args ...
>
> If you omit the alias name, it could default to something specified in the
> alias file.
>
> What that alias url resolves too, I'm not sure. I'm thinking a git url to
> an alias-install.edn file which contains something like:
>
> {:default-alias-name alias-map-to-add-as-an-alias}
>
>
> And similarly, you could add:
>
> clj --uninstall alias-name
>
> And it would remove the alias from your deps.edn, or if given -g, from
> your global deps.edn config.
>
> Ideally, it would remember the alias-url in the deps.edn file, so you
> could run:
>
> clj --update alias-name
>
> Maybe there could even be a kind of global url repo, with a list of
> registered alias names, so one could do:
>
> clj --install alias-name
>
> And it would know where to pull the alias-install.edn file from based on
> some global repo of distributed Clojure programs.
>
> I'd love this. Would seem like a pretty great way to deliver Clojure
> programs, which does not require any bash script, adding anything to your
> PATH, or having to edit a file.
>
> So for clj-new, ideally one could do:
>
> clj --install -g clj-new
>
> And clj would take care of adding the alias for it in my global deps.edn.
>
> But at the very least, without the alias registry, once could simply do:
>
> clj --install -g clj-new https://github.com/seancorfield/clj-new.git
>
> Which would auto-install the alias from a top level alias-install.edn file
> inside the repo.
>
> Something of the sort.
>
>
>
> On Tuesday, 17 April 2018 20:06:16 UTC-7, Sean Corfield wrote:
>>
>> clj-new -- https://github.com/seancorfield/clj-new
>>
>>
>>
>> This will generate new projects for you, either based on `clj`, or from
>> any existing Leiningen or Boot template (or, I hope in the future,
>> `clj-template` projects!).
>>
>>
>>
>> You'll probably want to add clj-new as an alias in your
>> ~/.clojure/deps.edn like this:
>>
>>
>>
>> {:aliases
>>
>> {:new {:extra-deps {seancorfield/clj-new
>>
>>  {:git/url "https://github.com/seancorfield/clj-new";
>>
>>   :sha "492bb2e7ad7373a8b5958124a86cddc4c7a123d5"}}
>>
>> :main-opts ["-m" "clj-new.create"]}}
>>
>> ...}
>>
>>
>>
>> Create a basic application:
>>
>>
>>
>> clj -A:new app myname/myapp
>>
>> cd myapp
>>
>> clj -m myname.myapp
>>
>>
>>
>> Run the tests:
>>
>>
>>
>> clj -A:test:runner
>>
>>
>>
>> Yes, the `deps.edn` generated from the `app` (and `lib`) built-in
>> template includes aliases to include your `test` folder, add `test.check`
>> as a dependency, and bring in and run Cognitect's `test-runner`
>>
>>
>>
>> The project name should either be a qualified Clojure symbol or a
>> multi-segment name -- single segment project names are not allowed!
>>
>>
>>
>> For a qualified Clojure symbol, the first part is typically your GitHub
>> account name or your organization's domain reversed, e.g., `com.acme`, and
>> the second part is the "local" name for your project (and is used as the
>> name of the folder in which the project is created).
>>
>>
>>
>> For a multi-segment project name, such as `foo.bar`, the folder that will
>> be created would be called `foo.bar` and will contain `src/foo/bar.clj`.
>>
>>
>>
>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
>> 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: Efficient Predicate Dispatch [was ANN: Logos v0.6]

[John Newman]

In order to answer a SO question I ended up whipping up a quick and dirty 
implementation of predicate dispatch here 
.
 
(unless I'm misunderstanding the definition of "predicate dispatch")

If you know your dispatch set is going to be small, a first-one-wins 
strategy should be good enough, right? And we can't really measure the 
complexity of a user's supplied predicate function a priori anyway, so if 
an isa? hierarchy isn't supplied, we might as well just check them in the 
order they're provided from the user and let the first one win, right?

V/r

John

On Thursday, April 14, 2011 at 11:25:48 AM UTC-4, David Nolen wrote:
>
> When things begin to get recursive you may be on the right track :D
>
> Initially I was going to implement Nominal Logic Programming for Logos a 
> la William Byrd's dissertation, but I realized that his implementation 
> requires pattern matching. All the pattern matching libs I've seen thus far 
> for Clojure are too naive and too slow. Even more importantly pattern 
> matching is subsumed by predicate dispatch (CiteSeerX — Efficient 
> Predicate Dispatching 
> ).
>
> Rich Hickey mentioned many moons ago that he'd like to see a predicate 
> dispatch implementation for Clojure that didn't have the kind of hardwiring 
> found in the Chambers/Chen paper. He suggested investigating Datalog. After 
> much reading, I've decided that a runtime in-memory Datalog that handles 
> dispatching is going to be too slow for many useful scenarios (an efficient 
> Datalog based on Binary Decision Diagrams might be possible, but this is an 
> incredibly complex undertaking in itself, meh).
>
> What we want is Standard MLs efficient compilation from decision diagrams 
> to switch statements (CiteSeerX — Optimizing Pattern Matching 
> ). 
> However Standard ML (Haskell, OCaml, Scala as well) pattern-matching has 
> issues with order among other things (Programming in Standard ML 
> ).
>
> What if we allow a logic engine to drive the compilation of the decision 
> diagram? This would be done by users mapping logic predicates to Clojure 
> predicate functions. Relationships between predicates can be added to the 
> logic engine allowing compilation to produce a very efficient decision 
> diagram. Nothing is hard coded, everything is driven by the kinds of 
> predicates and relationships between predicates that a user actually cares 
> about.
>
> All this is to say that this means Logos needs the ability to load 
> database of facts, index those facts, and to accept new facts and 
> relationships and update accordingly. So this going to happen sooner rather 
> then later.
>
> I welcome any feedback from anyone who has thoughts on this approach to 
> implementing predicate dispatch efficiently!
>
> Some thoughts on what this might look like is evolving here, 
> https://github.com/swannodette/match/wiki/Crazy-Ideas.
>
> David
>
> On Mon, Apr 11, 2011 at 3:08 PM, David Nolen  > wrote:
>
>> On Mon, Apr 11, 2011 at 2:01 PM, Vagif Verdi > > wrote:
>>
>>> Can it be used as an inference (rule) engine ?
>>
>>
>> If you mean in the same way that you can build inference (rule) engines 
>> in Prolog - I don't see why not.
>>
>> However there is a bit of work to be done in order to make building 
>> efficient rule engines easier:
>>
>> * Be able to load a database (aka Clojure collection) of facts
>> * Indexing of facts
>> * Intelligently use indexed facts
>>
>> Currently I'm a bit more interested in exploring type inference (via 
>> nominal logic) so I'm not sure when exactly I'll get to these, tho I'll 
>> gladly take patches from people who want such features sooner rather than 
>> later :)
>>
>> David
>>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To 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: Efficient Predicate Dispatch [was ANN: Logos v0.6]

[John Newman]

Update the example to leverage isa? hierarchies and allow prefer-poly, a la 
prefer-method: 
https://stackoverflow.com/questions/53329709/dispatching-function-calls-on-different-formats-of-maps/53354967#53354967

V/r

John

On Saturday, November 17, 2018 at 5:09:09 PM UTC-5, John Newman wrote:
>
> In order to answer a SO question I ended up whipping up a quick and dirty 
> implementation of predicate dispatch here 
> <https://stackoverflow.com/questions/53329709/dispatching-function-calls-on-different-formats-of-maps/53354967#53354967>.
>  
> (unless I'm misunderstanding the definition of "predicate dispatch")
>
> If you know your dispatch set is going to be small, a first-one-wins 
> strategy should be good enough, right? And we can't really measure the 
> complexity of a user's supplied predicate function a priori anyway, so if 
> an isa? hierarchy isn't supplied, we might as well just check them in the 
> order they're provided from the user and let the first one win, right?
>
> V/r
>
> John
>
> On Thursday, April 14, 2011 at 11:25:48 AM UTC-4, David Nolen wrote:
>>
>> When things begin to get recursive you may be on the right track :D
>>
>> Initially I was going to implement Nominal Logic Programming for Logos a 
>> la William Byrd's dissertation, but I realized that his implementation 
>> requires pattern matching. All the pattern matching libs I've seen thus far 
>> for Clojure are too naive and too slow. Even more importantly pattern 
>> matching is subsumed by predicate dispatch (CiteSeerX — Efficient 
>> Predicate Dispatching 
>> <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.47.4553>).
>>
>> Rich Hickey mentioned many moons ago that he'd like to see a predicate 
>> dispatch implementation for Clojure that didn't have the kind of hardwiring 
>> found in the Chambers/Chen paper. He suggested investigating Datalog. After 
>> much reading, I've decided that a runtime in-memory Datalog that handles 
>> dispatching is going to be too slow for many useful scenarios (an efficient 
>> Datalog based on Binary Decision Diagrams might be possible, but this is an 
>> incredibly complex undertaking in itself, meh).
>>
>> What we want is Standard MLs efficient compilation from decision diagrams 
>> to switch statements (CiteSeerX — Optimizing Pattern Matching 
>> <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.6.5507>). 
>> However Standard ML (Haskell, OCaml, Scala as well) pattern-matching has 
>> issues with order among other things (Programming in Standard ML 
>> <http://www.cs.cmu.edu/~rwh/smlbook/book.pdf>).
>>
>> What if we allow a logic engine to drive the compilation of the decision 
>> diagram? This would be done by users mapping logic predicates to Clojure 
>> predicate functions. Relationships between predicates can be added to the 
>> logic engine allowing compilation to produce a very efficient decision 
>> diagram. Nothing is hard coded, everything is driven by the kinds of 
>> predicates and relationships between predicates that a user actually cares 
>> about.
>>
>> All this is to say that this means Logos needs the ability to load 
>> database of facts, index those facts, and to accept new facts and 
>> relationships and update accordingly. So this going to happen sooner rather 
>> then later.
>>
>> I welcome any feedback from anyone who has thoughts on this approach to 
>> implementing predicate dispatch efficiently!
>>
>> Some thoughts on what this might look like is evolving here, 
>> https://github.com/swannodette/match/wiki/Crazy-Ideas.
>>
>> David
>>
>> On Mon, Apr 11, 2011 at 3:08 PM, David Nolen  wrote:
>>
>>> On Mon, Apr 11, 2011 at 2:01 PM, Vagif Verdi  wrote:
>>>
>>>> Can it be used as an inference (rule) engine ?
>>>
>>>
>>> If you mean in the same way that you can build inference (rule) engines 
>>> in Prolog - I don't see why not.
>>>
>>> However there is a bit of work to be done in order to make building 
>>> efficient rule engines easier:
>>>
>>> * Be able to load a database (aka Clojure collection) of facts
>>> * Indexing of facts
>>> * Intelligently use indexed facts
>>>
>>> Currently I'm a bit more interested in exploring type inference (via 
>>> nominal logic) so I'm not sure when exactly I'll get to these, tho I'll 
>>> gladly take patches from people who want such features sooner rather than 
>>> later :)
>>>
>>>

[ANN] dispacio

[John Newman]

dispacio is an experimental, simple, predicate stack dispatch system. 
Predicates are tested in the order they are defined and the first truthy 
match wins.

Features being worked on:
- similar interface to `defmethod`
- `isa?` hierarchies, similar to `defmethod`
- `prefer` a la `prefer-method`
- dispatch on arbitrary functions or specs, datomic/datalog queries, 
core.match, etc.
- extend functions to data types, rather than data types to functions
- small, simple, cljc codebase

See the examples in the readme: https://github.com/johnmn3/dispacio

This is an very alpha release - expect changes. If you see anything 
unexpected, please open an issue.

-- 
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.

Understanding tap

[John Newman]

Not sure why two wouldn't compose. You should probably wrap values in 
namespaced maps and dispatch with multimethods for your add-tap handlers. You 
could probably do pub sub pretty easy over that.

But I'd like to see more examples with tap too. What alternative design were 
you thinking of?

-- 
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: Any way to replace function body?

[John Newman]

dispacio  has a 
shadow-extend-like capability:

(defp assoc string? [s i c] (str (subs s 0 i) c (subs s (inc i

And then

(assoc "abc" 2 'x);#_=> "abx"

Using alter-var-root in dispacio correctly would prevent var replacement 
warnings I believe, similar to s/instrument, but I haven't figured out how 
to do it yet in a cross-platform way. PRs welcome. 

V/r

John
On Saturday, January 19, 2019 at 9:58:29 AM UTC-5, Janko Muzykant wrote:
>
> Hi,
>
> Is there an way to replace body of existing (interned) function with own 
> code still being able to call original fn? 
> Suppose, I have a function:
>
> (defn fetch-data [arg1 arg2]
>   (db/fetch-data ...))
>
> I would like to intern a slightly modified version of this fn. Something 
> like this:
>
> (defn fetch-data [& args]
>   (let [result (apply original-fetch-data args)]
> (transform-result result)))
>
> The problem I see is how to keep the reference to original fetch-data fn 
> (here denoted by original-fetch-data),
> so it could be still called in a altered version of fetch-data function.
>
> Best,
> JM.
>
>
>
>

-- 
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: The magic of Lisps

[John Newman]

I like Eric Normand's take here:
https://lispcast.com/magical-leverage-languages/

On Sun, Apr 28, 2019 at 9:46 AM  wrote:

> I agree Erik, macros and the dsl idea are edge cases imho. Having written
> clojure for 4 years now (and with 30 as a professional developer) I’ve only
> written a few macros and they were for very specific use cases where I
> wanted to support something specific.
>
> I think they are over-hyped features which most people will never use.
> That said, it’s nice to have macros when you need them
>
> On Apr 28, 2019, at 9:41 AM, James Reeves  wrote:
>
> Macros allow for experimentation in language design, not only by third
> parties, but also by the developers of the language themselves. If you have
> an idea for some new piece of syntax, it can be tried out in a library
> first.
>
> Macros are also useful for precompiling code for performance. If you have
> a literal data structure you need to transform, or even one that's
> partially literal, you can use macros to transform those parts at compile
> time.
>
> That's not to say macros are written often; but they have an important
> niche.
>
> Regarding DSLs, I don't think applications are often written using an
> encompassing internal DSL. I think most of the time when people talk about
> a DSL, it's actually just an overly complex API.
>
> In my view, a good DSL is both more consise within a domain, and less
> powerful than a general purpose language. A regular expression, for
> example, can concisely search through text, but has no side effects and is
> guaranteed to halt at some point. Certain regex libraries even go further,
> and guarantee they will halt within a time proportional to the input text.
>
> Ideally we should be aiming for the *least* powerful tool for the job,
> which often means using data to describe a solution rather than arbitrary
> code. Not only is this more reliable, it's also more transparent and allows
> for greater introspection.
>
> For example, my own Integrant 
> library replaces the dependency management of an application with a data
> structure. This is less powerful, because the dependencies need to be
> explicitly mapped out beforehand, but it's also more reliable and allows
> for introspection.
>
> Going further, Cognitect's Vase 
> allows for micro-services to be expressed almost entirely through a data
> structure.
>
> Maybe these examples allow people to write applications faster, but I
> think it's more important that they allow applications to be written more
> reliably. Over time, applications that are reliable and predictable are
> going to be easier for people to continue developing.
>
> On Sun, 28 Apr 2019 at 05:46, Erik Assum  wrote:
>
>> First of all, this might very well be a ramble without much sense, but
>> please bear with me.
>> Secondly, I’m writing this first and foremost not as an application
>> programmer.
>>
>> Having programmed in the crud-application business some twenty years
>> professionally, the last couple of them in Clojure, there are (at least)
>> two things (that might be related) that puzzle me:
>>
>> 1) The power of macros
>> I see, and acknowledge that eg the go-macro core.async is a wonderful
>> piece of work, and that it’s really cool that it could be done in a
>> library. But as an application programmer, I really don’t care if it’s a
>> macro or a language feature, and I couldn’t really see myself investing
>> that amount of time (nor would I have the skills to do so if I had the
>> time) to solve my concurrency problems in such a general manner.
>>
>> 2) The creating of a DSL for your problem domain, and then write a custom
>> compiler to solve your problem
>> In my (most optimistic view) every program that I write is somewhat an
>> internal DSL, built up of domain-specific functions, glued together with
>> Clojure. But I don’t feel that this is very specific to how I program in
>> Clojure vs other languages.
>>
>> So what I’d really like to achieve with this post is two things
>>
>> 1) Arguments ranging from  “Oh, you should look at it from this angle” to
>> “That’s how I feel too” to “You’re totally wrong, because…”
>>
>> 2) Pointers to blogs/articles/codebases which shows how applications
>> written either with extensive use of macros or by implementing an internal
>> DSL (and compiler) are significantly quicker to develop than their
>> brute-force alternatives.
>>
>> You might consider this as a first effort to create a presentation around
>> the subject :)
>>
>> Erik.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.goo

Re: [ANN] cpython bindings for clojure

[John Newman]

👏

On Wed, Jun 5, 2019 at 12:59 PM Jonah Benton  wrote:

> Wow, that is incredibly cool. Eager to check it out.
>
>
> On Wed, Jun 5, 2019, 12:41 PM Chris Nuernberger 
> wrote:
>
>> Good morning Clojurians,
>>
>> About 2 months ago during a talk about the tech.ml systems the point was
>> made that if we could load the python C libraries then that would provide
>> us with a lot more libraries to draw from.  In addition, I seem to remember
>> one of the ML talks a concern about lack of libraries being the problem.
>>
>> So, in the spirit of building bridges and providing clojure with the best
>> possible libraries for any particular problem on the planet, I took the
>> last month and built out raw cpython (libpython3.X) bindings based on JNA.
>>
>> So, today after cleaning things up just a little bit I decided it was
>> time to announce libpython-clj.  My hope is that there are enough clojuian
>> pythonistas that we can take this library and make it an absolute joy to
>> work with; the best python hosting environment that exists.
>>
>> https://github.com/cnuernber/libpython-clj
>>
>> Some features include:
>>
>> * Python dicts are represented in java as java.util.Map's.
>> * stdout,stderr are overridden to write to *out* and *err*, respectively.
>> * transparent access to the python interpreter from any thread.
>> * zero-copy pathways for numpy->tech.datatype tensors and back.  So you
>> can intermix heavy processing between clojure and python without pay a
>> large conversion cost.
>> * Decent performance.  This is built on the raw cpython shared library so
>> our cost of executing or interoperating with python should not be any
>> higher than anyone else's.
>> * two way bridging.  Expose your JVM objects to python and vice versa.
>>
>> I have a simple keras demo where I use Keras from clojure to train a
>> neural network included in the examples.  So that proves out keras and
>> tensorflow access from clojure.
>>
>> I think this soundly addresses our ability to load cutting edge math and
>> machine learning libraries.
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/clojure/CADbpEJvOWoxZu0Y_LHi%2B36bEbcOfxCV5n0jd7mhvq8TO9MaD_w%40mail.gmail.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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/CANoO%3DwR%3Dwau9Ci%2BbCxaO_vRJXbbPoE%2B8bg_tYsUTEU9Wz3LrSA%40mail.gmail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAPaaNq2Prt268YX2BQwHrcfgjOMqrVu4fqNdfTyZS%3D4ZMxd-4Q%40mail.gmail.com.
For more options, visit https://groups.google.c

Re: [ANN] proxy-plus: Faster and more usable replacement for "proxy"

[John Newman]

Bravo 👏

Are there any differences in behavior to be aware of? AOT, Graal, consuming
proxy+ classes from vanilla clojure classes?

On Mon, Jan 13, 2020, 11:47 AM Nathan Marz  wrote:

> proxy+ is a replacement for Clojure's proxy that's faster and more usable.
> proxy has a strange implementation where it overrides every possible method
> and uses a mutable field to store a map of string -> function for
> dispatching the methods. This causes it to be unable to handle methods with
> the same name but different arities.
>
> proxy+ fixes these issues with proxy. Usage is like reify, and it's up to
> 10x faster.
>
> *Repository: *https://github.com/redplanetlabs/proxy-plus
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/6d9bf48a-c5b5-417a-9f66-aa494cc38346%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAFw7CQJo8fGyqsbpW1YTPT0t10ckiTDkR4%3DN-NL%2B9uR1e1t17A%40mail.gmail.com.

Re: misunderstanding collection

[John Newman]

Don't forget destructuring:

(for [[a b c] signal]
  (map (partial reduce +) [a b c]))

and,

((fn [[[a b c][d e f]]]
  (map (partial reduce +) [a b c d e f]))
 signal)

While messing around with that, I was wondering if there were some
function that allowed you to destructure on-demand.

Like,
=> (destruct [[[a b c][d e f]]] signal)
(1 2 3 4) (2 3 4 5) (3 4 5 6) (3 4 5 6) (4 5 6 7) (5 6 7 8)

Anything like that exist?

-- 
John

On Wed, Aug 25, 2010 at 10:36 AM, James Reeves  wrote:
> I think you're getting confused.
>
> (map reduce + %) won't work, because the signature of the map function
> is (map func & colls). In other words, the second argument is expected
> to be a collection, but you've put in +, which is a function.
>
> When dealing with nested collections, you may want to work from the
> inside out. So take one of your inner lists:
>
>  s1: (1 2 3 4)
>
>  (reduce + s1)  =>  10
>  (apply + s1)  =>  10
>
> You can use reduce or apply to sum the lists. On the next level, we have:
>
>  s2: ((1 2 3 4) (2 3 4 5) (3 4 5 6))
>
>  (map (partial reduce +) s2)  =>  (10 14 18)
>
> So we're using map to sum each list. (partial reduce +) is just
> another way of writing #(reduce + %).
>
> Next is the final layer:
>
>  signal: (((1 2 3 4) (2 3 4 5) (3 4 5 6)) ((3 4 5 6) (4 5 6 7) (5 6 7 8)))
>
>  (map (partial map (partial reduce +)) signal)
>  => ((10 14 18) (18 22 26))
>
> Again, we add a map, and use partial. We could perhaps make this a
> little clearer by using for:
>
>  (for [s signal]
>    (for [c s] (reduce + c)))
>
> - James
>
>
> On 25 August 2010 15:06, Glen Rubin  wrote:
>> After toying around at the REPL I realize that I have been working
>> with a heretofore invalid understanding of collections.  For example,
>> working with the following collection(s):
>>
>> signal:
>> (((1 2 3 4) (2 3 4 5) (3 4 5 6)) ((3 4 5 6) (4 5 6 7) (5 6 7 8)))
>>
>> I wanted to sum each individual list: e.g. (1 2 3 4) = (10)
>>
>> I thought I could do this as follows:
>>
>> (map #(map reduce + %) signal)
>>
>> This resulted in an error, so trying to comprehend why I ran the
>> following:
>>
>> (map #(map identity (take 1 %)) signal)
>>
>> which results in,
>> (((1 2 3 4)) ((3 4 5 6)))
>>
>> So, clojure sees 'signal' as 2 collections, whereas I thought it was a
>> single collection.  This makes me concerned that I have been doing
>> everything wrong thus far and getting computational errors. :(  So,
>> how should I sum each individual list in the above collections?
>>
>> --
>> 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

-- 
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: misunderstanding collection

[John Newman]

A reader macro for destructuring might be nifty, like #[...].

So you could do things like:

(#(map (partial reduce +) #a b c][d e f]]] %]) signal)

Not sure if that'd be the right syntax, but you get the point.

On Sat, Aug 28, 2010 at 12:08 PM, John Newman  wrote:
> Don't forget destructuring:
>
> (for [[a b c] signal]
>  (map (partial reduce +) [a b c]))
>
> and,
>
> ((fn [[[a b c][d e f]]]
>  (map (partial reduce +) [a b c d e f]))
>  signal)
>
> While messing around with that, I was wondering if there were some
> function that allowed you to destructure on-demand.
>
> Like,
> => (destruct [[[a b c][d e f]]] signal)
> (1 2 3 4) (2 3 4 5) (3 4 5 6) (3 4 5 6) (4 5 6 7) (5 6 7 8)
>
> Anything like that exist?
>
> --
> John
>
> On Wed, Aug 25, 2010 at 10:36 AM, James Reeves  
> wrote:
>> I think you're getting confused.
>>
>> (map reduce + %) won't work, because the signature of the map function
>> is (map func & colls). In other words, the second argument is expected
>> to be a collection, but you've put in +, which is a function.
>>
>> When dealing with nested collections, you may want to work from the
>> inside out. So take one of your inner lists:
>>
>>  s1: (1 2 3 4)
>>
>>  (reduce + s1)  =>  10
>>  (apply + s1)  =>  10
>>
>> You can use reduce or apply to sum the lists. On the next level, we have:
>>
>>  s2: ((1 2 3 4) (2 3 4 5) (3 4 5 6))
>>
>>  (map (partial reduce +) s2)  =>  (10 14 18)
>>
>> So we're using map to sum each list. (partial reduce +) is just
>> another way of writing #(reduce + %).
>>
>> Next is the final layer:
>>
>>  signal: (((1 2 3 4) (2 3 4 5) (3 4 5 6)) ((3 4 5 6) (4 5 6 7) (5 6 7 8)))
>>
>>  (map (partial map (partial reduce +)) signal)
>>  => ((10 14 18) (18 22 26))
>>
>> Again, we add a map, and use partial. We could perhaps make this a
>> little clearer by using for:
>>
>>  (for [s signal]
>>    (for [c s] (reduce + c)))
>>
>> - James
>>
>>
>> On 25 August 2010 15:06, Glen Rubin  wrote:
>>> After toying around at the REPL I realize that I have been working
>>> with a heretofore invalid understanding of collections.  For example,
>>> working with the following collection(s):
>>>
>>> signal:
>>> (((1 2 3 4) (2 3 4 5) (3 4 5 6)) ((3 4 5 6) (4 5 6 7) (5 6 7 8)))
>>>
>>> I wanted to sum each individual list: e.g. (1 2 3 4) = (10)
>>>
>>> I thought I could do this as follows:
>>>
>>> (map #(map reduce + %) signal)
>>>
>>> This resulted in an error, so trying to comprehend why I ran the
>>> following:
>>>
>>> (map #(map identity (take 1 %)) signal)
>>>
>>> which results in,
>>> (((1 2 3 4)) ((3 4 5 6)))
>>>
>>> So, clojure sees 'signal' as 2 collections, whereas I thought it was a
>>> single collection.  This makes me concerned that I have been doing
>>> everything wrong thus far and getting computational errors. :(  So,
>>> how should I sum each individual list in the above collections?
>>>
>>> --
>>> 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
>



-- 
John

-- 
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: misunderstanding collection

[John Newman]

> #%3 %2 %1][%4 %5 %6]]] signal] -> [c b a d e f]

Right, the names are superfluous.  So are the extra set of brackets I
guess.  Perhaps even better would be:

(#[[_ _ _][_ _ _]] signal)

Or if you wanted just the third item of the second collection:

(#[[][2]] signal)

Also, I took the signal out of the #[...] form and passed it in as an
argument instead.

No, it is not as flexible as let, but it eliminates having to
duplicate a b c d e h, etc.

I am going to see if I can write a function that does:

=> (destructure [[][2]] signal)
(5 6 7 8)

Or would it have to be a macro?

John



On Sat, Aug 28, 2010 at 2:55 PM, Mike Meyer  wrote:
> On Sat, 28 Aug 2010 12:23:04 -0400
> John Newman  wrote:
>
>> A reader macro for destructuring might be nifty, like #[...].
>
> I don't think so.
>
> But first, we already have an "on-demand" destructuring facility: let.
>
>> So you could do things like:
>>
>> (#(map (partial reduce +) #a b c][d e f]]] %]) signal)
>
> which would be
>
> (#(map (partial reduce +) (let a b c][d e f]]] %] [a b c d e f])) signal)
>
> But using let allows you to put the destructuring first, which I
> think is a bit easier to read:
>
> (#(let a b c][d e f]]] %] (map (partial reduce +) [a b c d e f])) signal)
>
>> Not sure if that'd be the right syntax, but you get the point.
>
> I think so. It's sort of like fn and #(, only "backwards". #( lets you
> elide the argument list by creating implicit names for them, so it's
> as flexible as fn and a bit shorter. #[, on the other hand, elides the
> body part of the let, just giving you back the list. This isn't nearly
> as flexible as let, since all you get is a list, with no chance to
> plug the values into an expression where they'll do the most good.
>
> Another issue: What does this mean:
>
>   #a b c]]] (first signal) [[[d e f]]] (second signal)]
>
> And finally, the names (a, b, etc.) are pointless. Why not just call
> them %1, %2, %3 so that you could do:
>
>     #%3 %2 %1][%4 %5 %6]]] signal] -> [c b a d e f]
>
> Except then you have to worry about #[[%1 %1 %2] value], so maybe just
> make them all %?
>
>        --
> Mike Meyer               http://www.mired.org/consulting.html
> Independent Network/Unix/Perforce consultant, email for more information.
>
> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Simple things should be simple

[John Newman]

(use '[clojure.contrib.server-socket :only (create-server)]
   '[clojure.contrib.duck-streams :only (read-lines)])
(create-server 8080
  (fn [in out] (when-not (empty? (read-lines in)) (spit out "Hello,
World!\n"

4/0/0

John

On Thu, Sep 9, 2010 at 9:21 PM, Matt  wrote:
>> You cannot deploy a .clj script on a running Tomcat (yet).
>
> In the unstable 0.8 version of Conjure, you can create a war file by
> simply adding leiningen-war to your dev-dependencies and running "lein
> uberwar". You can then simply drop the war file into a Tomcat server.
> The web.xml file is already created for you with a default
> configuration which will work with your Conjure app out of the box. Of
> course, if the web.xml file doesn't do what you need, you can still
> edit it.
>
> The only reason I've not released 0.8 yet, is that I'm trying to make
> deployment on Google App Engine nearly as easy. Unfortunately, Google
> App Engine doesn't like all of the reflection stuff in Conjure.
>
> Obviously, Conjure is much slower and a lot more overhead than most of
> the other solutions mentioned in this thread.
>
> -Matt Courtney
>
>
> On Sep 9, 2:16 pm, Brenton  wrote:
>> Mike,
>>
>> While evaluating Clojure, just remember, you don't have use it for
>> everything. When you need something simple, as in your examples, then
>> use cgi. When you need to do something more complex then Clojure can
>> help.
>>
>> You cannot deploy a .clj script on a running Tomcat (yet). When you
>> install Tomcat, you have a ROOT context into which you can place .html
>> and .jsp files and they will be dynamically loaded. This gives you
>> about the same functionality as you would get from php and apache.
>>
>> Even though Clojure doesn't already have what you are looking for it
>> would not be difficult to make it work. For example, you could create
>> a generic web app that would have an embedded REPL as well as the
>> ability to dynamically load code from external files. You would then
>> just need to install Tomcat (which is easy) and drop this war into it.
>> Form then on out you would just create simple .clj scripts and drop
>> them into a directory. You could also connect to the REPL and
>> dynamically add and remove code from the application. This hasn't been
>> done yet because I don't think many people would find it useful.
>>
>> Clojure is new so when you see something missing, build it. That is
>> why all of this other stuff is so simple, someone built it.
>>
>> Brenton
>>
>> On Sep 9, 10:40 am, Mike Meyer >
>> 620...@mired.org> wrote:
>> > On Thu, 9 Sep 2010 09:41:09 -0700 (PDT)
>>
>> > Brenton  wrote:
>> > > Mike,
>>
>> > > Your point has been made, simple things are simple. When you need to
>> > > print "hello world" you don't need to bring Clojure into the picture.
>> > > You could have given a much simpler example of needing to print "hello
>> > > world" on the command line. echo "hello world" is much simpler than
>> > > what you would need to do in Clojure.
>>
>> > The thing is, I'm evaluating clojure - that's what drags clojure into
>> > it. If I wasn't interested in using clojure, I'd never have asked the
>> > question. Printing "hello world" is just a simple, well-understood
>> > example application. There are *lots* of applications worth putting on
>> > the web that aren't much more complicated than that. I chose it to
>> > emphasis how much extra work the environment that clojure seems to be
>> > inextricably linked with adds.
>>
>> > > When faced with any problem to solve, you have to look at the tools
>> > > you have available and then determine what the simplest solution will
>> > > be. In your case, all of the software you need is already installed,
>> > > configured and running. So it's simple. If you gave me a system with
>> > > Tomcat installed, configured and running then I could do the exact
>> > > same thing. It has nothing to do with Java, it has to do with what you
>> > > are given to work with.
>>
>> > I thought I *gave* you all those things to work with when I said "not
>> > counting the web server and whatever else it needs to be ready to run
>> > applications." Could you show me (or point me to an web page showing)
>> > how I'd go from a simple .clj script to an application running on
>> > Tomcat that's been installed and is ready to run applications? If
>> > that's as simple as the apache/cgi example, I'll be very happy.
>>
>> >      > > --
>> > Mike Meyer           http://www.mired.org/consulting.html
>> > Independent Network/Unix/Perforce consultant, email for more information.
>>
>> > O< ascii ribbon campaign - stop html mail -www.asciiribbon.org
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more option

Re: Simple things should be simple

[John Newman]

Finally,

> cat - > /usr/local/www/apache22/cgi-bin/hello-world
>
> #!/usr/local/bin/clj
>
> (println "Content-type: text/plain\n")
> (println "Hello, World!")
> ^D

I can start using Clojure again :)

John

-- 
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

http-client and ignoring ssl errors

[John Newman]

Hello All,

I am trying to add some functionality to http-client.  Basically, I need the
ability to do get requests on a server while ignoring ssl errors.  Once I
figure out how to get it working, I'll put it up on github and people can
pull it if they'd like.

I am working from a fork of http-client that has support for cookies,
located here: https://github.com/r0man/clj-http/commits/cookies

I used r0man's changes (
https://github.com/r0man/clj-http/commit/f8152c6182c148539148fdc7f77faab14b7567c3)
as an example of what I needed to change in order to add "ssl error ignore"
capability.

I used some java wisdom from stackoverflow (
http://stackoverflow.com/questions/2012497/accepting-a-certificate-for-https-on-android/3904473#3904473)
to ignore ssl errors.

I came up with this:

src/http-client/client.clj

...
  (:use [clj-http.cookies :only (wrap-cookies)]
[clj-http.noauth :only (wrap-noauth)])))
...
and
...
(defn wrap-request
  "Returns a battaries-included HTTP request function coresponding to the
given
   core client. See client/client."
  [request]
  (-> request
wrap-noauth
wrap-redirects
wrap-exceptions
...

I put wrap-noauth (which might have been a bad name) at the beginning
because it takes the old client and actually returns a new one:

src/http-client/noauth.clj

(ns clj-http.noauth
  "Allows client to ignore some SSL errors (only use in dev!)"
  (:import (javax.net.ssl HostnameVerifier HttpsURLConnection))
  (:import (org.apache.http.conn.ssl SSLSocketFactory X509HostnameVerifier))
  (:import (org.apache.http.conn.scheme Scheme SchemeRegistry))
  (:import (org.apache.http.impl.client DefaultHttpClient))
  (:import (org.apache.http.impl.conn SingleClientConnManager)))

(defn wrap-noauth [client]
  (fn [req]
(if (:noauth req)
  (let [registry (SchemeRegistry.)
hostname-verifier SSLSocketFactory/ALLOW_ALL_HOSTNAME_VERIFIER
socket-factory (SSLSocketFactory/getSocketFactory)
_ (.setHostnameVerifier
socket-factory hostname-verifier)
_ (.register registry (Scheme. "https" socket-factory 443))
noauth-client (DefaultHttpClient.
(SingleClientConnManager. (.getParams client)
registry)
(.getParams client))
_ (HttpsURLConnection/setDefaultHostnameVerifier
hostname-verifier)]
(noauth-client req))
  (client req
I essentially modeled wrap-noauth on the stackoverflow thread.

When I run (c/get my-url {:noauth true :cookies ...

I get:

user=> IllegalArgumentException No matching field found: getParams for class
clojure.lang.Var  clojure.lang.Reflector.getInstanceField
(Reflector.java:289)

Taking the ':noauth true' out of the argument map makes the error go away.

The only place I see getParams used is towards the beginning of the request
function in core.clj

src/http-client/core.clj
...
  (let [http-client (DefaultHttpClient.)]
(try
  (-> http-client
(.getParams)
(.setParameter ClientPNames/COOKIE_POLICY
CookiePolicy/BROWSER_COMPATIBILITY))
  (let [http-url (str scheme "://" server-name
...

I'm still not sure what is going on... Am I breaking it by instantiating a
new DefaultHttpClient?  Should a new key for noauth be put in the parameters
to core/request [{:keys [noauth...  the cookies branch didn't do this, so I
wasn't sure.

Thanks in advance for the help.  Hopefully, once this is figured out, it
will be useful to others as well.

John

-- 
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: http-client and ignoring ssl errors

[John Newman]

Maybe I should just build the SSL logic into http-client.core/request and
have request instantiate a different DefaultHttpClient based on the value of
:noauth in the request map?

Will try when I get home.

John


On Thu, Sep 1, 2011 at 4:31 PM, John Newman  wrote:

> Hello All,
>
> I am trying to add some functionality to http-client.  Basically, I need
> the ability to do get requests on a server while ignoring ssl errors.  Once
> I figure out how to get it working, I'll put it up on github and people can
> pull it if they'd like.
>
> I am working from a fork of http-client that has support for cookies,
> located here: https://github.com/r0man/clj-http/commits/cookies
>
> I used r0man's changes (
> https://github.com/r0man/clj-http/commit/f8152c6182c148539148fdc7f77faab14b7567c3)
> as an example of what I needed to change in order to add "ssl error ignore"
> capability.
>
> I used some java wisdom from stackoverflow (
> http://stackoverflow.com/questions/2012497/accepting-a-certificate-for-https-on-android/3904473#3904473)
> to ignore ssl errors.
>
> I came up with this:
>
> src/http-client/client.clj
>
> ...
>   (:use [clj-http.cookies :only (wrap-cookies)]
> [clj-http.noauth :only (wrap-noauth)])))
> ...
> and
> ...
> (defn wrap-request
>   "Returns a battaries-included HTTP request function coresponding to the
> given
>core client. See client/client."
>   [request]
>   (-> request
> wrap-noauth
> wrap-redirects
> wrap-exceptions
> ...
>
> I put wrap-noauth (which might have been a bad name) at the beginning
> because it takes the old client and actually returns a new one:
>
> src/http-client/noauth.clj
>
> (ns clj-http.noauth
>   "Allows client to ignore some SSL errors (only use in dev!)"
>   (:import (javax.net.ssl HostnameVerifier HttpsURLConnection))
>   (:import (org.apache.http.conn.ssl SSLSocketFactory
> X509HostnameVerifier))
>   (:import (org.apache.http.conn.scheme Scheme SchemeRegistry))
>   (:import (org.apache.http.impl.client DefaultHttpClient))
>   (:import (org.apache.http.impl.conn SingleClientConnManager)))
>
> (defn wrap-noauth [client]
>   (fn [req]
> (if (:noauth req)
>   (let [registry (SchemeRegistry.)
> hostname-verifier SSLSocketFactory/ALLOW_ALL_HOSTNAME_VERIFIER
> socket-factory (SSLSocketFactory/getSocketFactory)
> _ (.setHostnameVerifier
> socket-factory hostname-verifier)
> _ (.register registry (Scheme. "https" socket-factory 443))
> noauth-client (DefaultHttpClient.
> (SingleClientConnManager. (.getParams client)
> registry)
> (.getParams client))
> _ (HttpsURLConnection/setDefaultHostnameVerifier
> hostname-verifier)]
> (noauth-client req))
>   (client req
> I essentially modeled wrap-noauth on the stackoverflow thread.
>
> When I run (c/get my-url {:noauth true :cookies ...
>
> I get:
>
> user=> IllegalArgumentException No matching field found: getParams for
> class clojure.lang.Var  clojure.lang.Reflector.getInstanceField
> (Reflector.java:289)
>
> Taking the ':noauth true' out of the argument map makes the error go away.
>
> The only place I see getParams used is towards the beginning of the request
> function in core.clj
>
> src/http-client/core.clj
> ...
>   (let [http-client (DefaultHttpClient.)]
> (try
>   (-> http-client
> (.getParams)
> (.setParameter ClientPNames/COOKIE_POLICY
> CookiePolicy/BROWSER_COMPATIBILITY))
>   (let [http-url (str scheme "://" server-name
> ...
>
> I'm still not sure what is going on... Am I breaking it by instantiating a
> new DefaultHttpClient?  Should a new key for noauth be put in the parameters
> to core/request [{:keys [noauth...  the cookies branch didn't do this, so I
> wasn't sure.
>
> Thanks in advance for the help.  Hopefully, once this is figured out, it
> will be useful to others as well.
>
> John
>

-- 
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