Re: [ANN] Nightcode, an IDE for Clojure and Java

[Colin Fleming]

Hi Zach,

Congratulations, Nightcode looks very impressive - it looks like a worthy
Clooj successor. I'll definitely download it and check it out.

Cheers,
Colin


On 3 August 2013 07:07, Dave Ray  wrote:

> In Seesaw [1] you can specify your shortcuts as "menu S" instead of "ctrl
> S" and it will pick the right one for the platform.
>
> Cheers,
>
> Dave
>
> [1] my memory's a little fuzzy here :)
>
>
>
> On Fri, Aug 2, 2013 at 12:00 PM, Zach Oakes  wrote:
>
>> That's a good point, I should be using command instead of control on OSX.
>> I don't have a Mac so that slipped my mind; I'll make a note of it.
>>
>>
>> On Friday, August 2, 2013 2:54:45 PM UTC-4, Lee wrote:
>>>
>>>
>>> On Aug 2, 2013, at 1:53 PM, Jeff Heon wrote:
>>> > If I can suggest the one feature that I couldn't bear to use an IDE
>>> without:
>>> > Strict Structural Editing Mode (paredit-style)
>>>
>>> But please note that while many love paredit, many others hate it -- so
>>> if you implement this I would make it optional.
>>>
>>> Also:
>>>
>>> On Aug 2, 2013, at 2:26 PM, John Gabriele wrote:
>>> > . (Hm, when using "Run with REPL", having trouble calling a function I
>>> added above -main...)
>>>
>>> That happened to me and in my case it was because I hadn't saved the
>>> changed file... thought I did because I had hit command-s (on a mac) while
>>> Nightcode save is control-s.
>>>
>>> > One big issue I see right now: no smart indentation in the editor
>>> window.
>>>
>>> Totally essential, IMHO.
>>>
>>> If I can dream big, after the core editing features, somewhere near the
>>> top of my own feature wish-list would be a debugging feature that I think
>>> is currently available for Clojure only in emacs via nrepl-ritz (oh,
>>> actually now I think I see that it's available in a vim environment too):
>>> the ability to browse or at least print the values of locals up and down
>>> the stack at the point of an exception (presumably in a run with
>>> locals-clearing off, although it'd be great to see whatever hasn't been
>>> cleared anyway).
>>>
>>> There's a long thread of discussion about this and related ideas here:
>>> https://groups.google.com/**forum/#!topic/clojure/**qhdCrUoT_O0
>>>
>>> It'd be totally fabulous to have this feature in a Clojure IDE that's as
>>> clean and usable as Clooj or Nightcode.
>>>
>>>  -Lee
>>>
>>>
>>>
>>>
>>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To 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/groups/opt_out.
>>
>>
>>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: Robo VM

[Niklas Therning]

I'm not very familiar with how RubyMotion works but I guess it's similar.
RoboVM takes Java bytecode and compiles it into machine code ahead of time.
For each .class file an object file is produced. The object files are
linked together with a runtime library into an executable. RoboVM uses the
Boehm GC.



On Thu, Aug 1, 2013 at 4:25 AM, PublicFarley  wrote:

> Niklas, RoboVM looks incredibly cool. I'm definitely going to fool around
> with it to see if I can get some Clojure code up and running on iOS. This
> could become RubyMotion for JVM language devs!
>
> Have you looked at RubyMotion? Is your approach conceptually similar? How
> do you handle GC? Via an ARC like mechanism or do you bundle a garbage
> collector?
>
> Again, great work.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/69tZB2Wh6Tg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: Two Dimensional Associative Map

[JvJ]

Actually, what I'm looking for is a way to use arbitrary types of keys 
rather than integers.

I have this so far:

 Table data structure.
 For now, the table data structure is a map of maps.

(defn row
  "Get a row of the table.
 If only the key is passed, a row
lookup function is returned."
  ([r]
 #(row r %))
  ([r m]
 (get m r)))

(defn col
  "Get a column of the table."
  ([c]
 #(col c %))
  ([c m]
 (for [[rk r] m
   :let [x (get r c)]
   :when x]
   [rk x])))

(defn t-get
  "Get values in a table."
  [m &{:keys [r c]}]
  (cond
   (and r c) (get-in m [r c])
   r (row r m)
   c (col c m)
   :else m))

(defn t-update
  "Update a value or values in the map."
  [m f &{:keys [r c]}]
  (cond
   (and r c) (update-in m [r c] f)
   r (update-in m [r] f)
   
   ;; This O(n) column update is making me angry!
   c (let [res (f (into {} (t-get m :c c)))]
   (println "f result: " res)
   (reduce
(fn [acc k]
  (if-let [v (get res k)]
(update-in acc [k] assoc c v)
(if (contains? (get m k) c)
  (update-in acc [k] dissoc c)
  acc)))
m
(clojure.set/union (set (keys m))
   (set (keys res)))

(defn t-set
  "Set a value or values in the map."
  [m v & r]
  (apply t-update m (constantly v) r))

It works pretty well for swapping out rows or individual cells, but setting 
a column seems like an inefficient operation.  I don't know how much I'll be
using that.

On Thursday, 1 August 2013 17:59:40 UTC-7, JvJ wrote:
>
> I'm looking for an associative data structure that can be accessed by both 
> rows and columns, and could potentially be sparse.
>
> Suppose the following table is called t:
>
> |   | :A   | :B   | :C   ||---+--+--+--|| 1 |  |  
> | '[x y z] || 2 | "2a" | "2b" |  || 3 |  |  |  || 3 | 
> :3a  |  | "Foo"|
>
>
> Then (t :A) would return {2 "2a", 3 :3a}, and (t 2) would return {:A "2a", 
> :B "2b"}.
> (t :A 2) or (t 2 :A) would return "2a".
>
> I'm thinking of implementing it as a simple map of maps with some extra 
> functions, but I'm not sure if
> that would be the best option.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: Can I refer all but specified symbols with 'ns' macro?

[guns]

On Fri  2 Aug 2013 at 04:32:32PM -0400, Lee Spector wrote:

> I can believe that these assertions are true in some (maybe many)
> programming contexts, but from other perspectives anything that
> requires you to type stuff that's not directly about the problem
> you're trying to solve or the idea you're trying to express can be
> seen as an anti-feature.

Of course, this is the tension of simple vs easy. Coming from languages
like C and Ruby, the explicit namespacing in Clojure is a breath of
fresh air, and one of my _favorite_ features of the language.

"Let's keep adding header files until it compiles", and "let's mixin
this entire module for a single method" is easy at first, but you're
adding a lot of incidental complexity for comparatively little gain.

For example, tightly controlled namespacing is what allows Golang to
compile at ludicrous speed, and even relatively small programs can
become incomprehensible when they fall into the hole of super calls and
method shadowing.

> In my own case I generally don't want to spend my time maintaining
> catalogs of all of the locations of the functions that I call or
> cluttering up function calls with project plumbing; I want to spend my
> time thinking about and developing and testing my algorithms.

…

> I'd personally like it even better if you could accomplish the same
> thing without listing the conflicts explicitly, but I'm sure that will
> seem totally nuts to others.

It has been mentioned before, but if you are going to depend on tools
to manage vars for you, why not use Slamhound?¹ It's quality DWIM: do
what's easy, Slamhound makes it simple.

It will take the following buffer:

(ns example)

(split (trim " hello, world. ") #",")

and transform it into:

(ns example
  (:require [clojure.string :refer [split trim]]))

(split (trim " hello, world. ") #",")

It also removes unused :refers, so it's useful for cleaning up a
namespace after refactoring.

I have the call to slam.hound bound to a key sequence in my editor², so
I do not have to suffer a context switch:

https://gist.github.com/guns/6144732

There remain a few small problems (and one admittedly large one WRT
macros), but I think automated ns management is a killer feature for
Clojure.

I found hacking on the Slamhound codebase straightforward, so I
encourage people to send patches for any small annoyance they might
have. (it's easy!)

guns

¹ https://github.com/technomancy/slamhound
² I'm pretty sure technomancy has something similar for Emacs users.


pgp_ov2P9N9Pm.pgp
Description: PGP signature

Re: Hiring Clojure Programmer(s)

[Marcus Blankenship]

Unless that doesn't matter…


On Aug 2, 2013, at 12:27 PM, Andrew Stine  wrote:

> Might help if you said what part of the world you're in.
> 
> On Friday, August 2, 2013 12:47:21 PM UTC-4, Quinn Finney wrote:
> Hello all,
> 
> My company is looking to hire a Clojure programmer to help assess and finish 
> our product, a server architecture system for Java instances. The product 
> involves receiving input from a web control panel and making changes based on 
> that. To our knowledge, the product is currently 85% complete. This will be a 
> payed position. Please email me at quinn@gmail.com or call me at (206) 
> 660 5366 for more information if you are interested. 
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from 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/groups/opt_out.
>  
>  

MARCUS BLANKENSHIP
\\\ Owner, Problem Solver, Thinker
\\\ 541.805.2736 \ @justzeros \ skype:marcuscreo

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: RPC over channels

[David Pollak]

This is a tough and interesting issue.

Let's put aside the whole RPC issue for a moment and look at how code
progressed from C-land to Java-land.

In C, the developer had to check return values from function calls to see
if the function succeeded. That led to ignoring return values or testing
with a nested block of code:

if (succeeded(open_file(name, &file_struct))) {
  if (succeeded(do_something_else(...))) {
do work;
  } else {
close resources; release memory; return error;
  }
} else { close resources; release memory; return error;}

Java improved on this with exceptions and garbage collection:

try {
File f = open_file(name);
try {
  Something s = do_something_else(...)
} finally {
  close f;
} catch (...) {
// handle inner and outer errors
}

Add ARM (automatic resource management) and you have something that looks a
lot like a supervisor in Erlang (in my opinion)... basically you run all
your code and the exception handlers handle the exceptional situations.

So, this works for both local calls and remote calls (putting aside the
marshalling of parameters and state across address spaces) as long as the
number of threads of execution can be handled by the runtime/operating
system.

But in the JVM, we can no longer build systems that cause threads to block
on the execution of off-process code because we will need a lot more
threads than the OS (because the JVM is native threaded and can have about
4K threads) can provide.

This is where core.async is particularly nice (it's double extra nice in
JavaScript-land where there's only 1 thread, so blocking is verboten).
Basically, rather than having nested call-back functions (like our C-style
nested if statements), core.async re-writes the code such that where there
are blocking calls to a channel, the code is re-written so that it is in
effect a series of call-backs, but the code that the developer writes is
linear.

Put another way, core.async gives us the syntax of a normal flow, but with
the performance of releasing the thread until a result is available and
then continuing the logical computation.

I think the idea of extending the ideas in core.async to accessing remote
systems makes a lot of sense. Call it RPC. Call it something else... but
it's the same concept... you give the developer linear looking code that
"does the right thing" with off-process calls. The right thing being
releasing the current JVM thread until the answer comes back, dealing
correctly with timeouts, and correctly handing failures by releasing
resources as well as invoking appropriate exception handling code
(supervisor?).

If we don't have a nice layer like this, we're stuck writing code like:

(let [v (alt! (some_call_to_external_system_that_returns a channel)
(timeout 1000))]
  (if (not (timeout? v)) (do something with v) (raise error)))

Where we are repeating the boilerplate of timeouts and we probably have to
test v against nil (the channel is closed) and exceptions.

Instead, if we have:

(rpc #(handle_error %) 1000 ;; default timeout
(let [v call_to_external_system] (do something with v)))

And we do the same deep walking with the rpc macro that's done with the go
macro so we identify all the remote calls and turn them into the go-based
code with alt! and the timeout boilerplate.

And then we've got a nice rpc system layered on top of core.async that has
default timeouts... and if rpc supports nesting, then we can tune the
timeout for a given call.

So, I think the concepts and the code in core.async lend themselves
directly to building an rpc-style system where the boilerplate for dealing
with invoking off-process resources and getting the results from these
off-process resources with correct timeout, exception handling, and
resource release.




On Fri, Aug 2, 2013 at 6:46 AM, Timothy Baldridge wrote:

> RPC ties a local process (and all the memory its currently using) to a
> remote process. It glosses over the fact that that the link between these
> two processes is quite unreliable. In his thesis, Joe Armstrong also points
> that this system is not only susceptible to hardware/network failure, it's
> also very susceptible to programming failures. A bug in your code could
> cause every 100th RPC call to fail, for example.
>
> So instead of all of this, Erlang (or actually Erlang's OTP libraries)
> proposes a different view:
>
> 1) all messages are sent async and unreliable. This is the way networks
> are designed anyways, if you sent a message to a remote system and it gets
> thrown into a queue, you really don't know what happens to that message in
> the end, except by asking the remote system again, and again until you
> finally get an ACK.
>
> 2) If we follow the above model, then we can start programming in a
> fail-fast mode. This is what OTP is based on. Supervisor processes that
> reset dead sub processes. This is also why I'm not a fan of populating
> error messages across channels. Instead, errors should kill go blocks, and
> then those blocks 

Re: Can I refer all but specified symbols with 'ns' macro?

[Lee Spector]

On Aug 2, 2013, at 9:16 AM, Laurent PETIT wrote:
> 2013/8/2 Anthony Grimes :
>> Keep in mind that you should almost never do this. It's much better to
>> require :as or explicitly refer which things you want from each namespace.
>> When you do :refer :all, you pollute your namespace with tons of vars and
>> when you use them, nobody has any clue where they're coming from so they
>> have to hunt through the codebase, your libraries, etc, to find out where
>> the various vars you're using come from. All of that is mitigated by
>> referring specific vars or qualifying the namespace with :as. It really
>> isn't that many more characters. You can give your namespace a one letter
>> prefix and access vars like x/some-var.
> 
> True.
> 
> Tho note that with an IDE (Counterclockwise for Clojure does that for
> instance) with good integration with nrepl, you can hover over the
> symbol (provided that you've successfully loaded the namespace in your
> repl) to see documentation (including where it comes from), type F3 to
> jump to its definition (either in your project files, or in jar
> entries).

Laurent's point that an IDE can tell you where things are defined is an 
excellent one, but I'd go further and contest Anthony's assertions that "you 
should almost never do this" and that it's "much better to require :as or 
explicitly refer which things you want from each namespace." 

I can believe that these assertions are true in some (maybe many) programming 
contexts, but from other perspectives anything that requires you to type stuff 
that's not directly about the problem you're trying to solve or the idea you're 
trying to express can be seen as an anti-feature. In my own case I generally 
don't want to spend my time maintaining catalogs of all of the locations of the 
functions that I call or cluttering up function calls with project plumbing; I 
want to spend my time thinking about and developing and testing my algorithms.

I do understand that explicitness is good when you're writing code for 
mission-critical production environments, etc. But in other programming 
contexts (most of mine, and most of my students', and most of my 
collaborators') it's more important to be able to write code quickly and 
fluidly, without worrying about the plumbing.

In this context the OP's request was perfectly reasonable, and the right 
combination of :require, :refer :all, and :exclude is a reasonable way to do 
the job. I'd personally like it even better if you could accomplish the same 
thing without listing the conflicts explicitly, but I'm sure that will seem 
totally nuts to others.

 -Lee

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

Re: Hiring Clojure Programmer(s)

[Andrew Stine]

Might help if you said what part of the world you're in.

On Friday, August 2, 2013 12:47:21 PM UTC-4, Quinn Finney wrote:
>
> Hello all,
>
> My company is looking to hire a Clojure programmer to help assess and 
> finish our product, a server architecture system for Java instances. The 
> product involves receiving input from a web control panel and making 
> changes based on that. To our knowledge, the product is currently 85% 
> complete. This will be a payed position. Please email me at 
> quinn@gmail.com  or call me at (206) 660 5366 for more 
> information if you are interested. 
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Dave Ray]

In Seesaw [1] you can specify your shortcuts as "menu S" instead of "ctrl
S" and it will pick the right one for the platform.

Cheers,

Dave

[1] my memory's a little fuzzy here :)



On Fri, Aug 2, 2013 at 12:00 PM, Zach Oakes  wrote:

> That's a good point, I should be using command instead of control on OSX.
> I don't have a Mac so that slipped my mind; I'll make a note of it.
>
>
> On Friday, August 2, 2013 2:54:45 PM UTC-4, Lee wrote:
>>
>>
>> On Aug 2, 2013, at 1:53 PM, Jeff Heon wrote:
>> > If I can suggest the one feature that I couldn't bear to use an IDE
>> without:
>> > Strict Structural Editing Mode (paredit-style)
>>
>> But please note that while many love paredit, many others hate it -- so
>> if you implement this I would make it optional.
>>
>> Also:
>>
>> On Aug 2, 2013, at 2:26 PM, John Gabriele wrote:
>> > . (Hm, when using "Run with REPL", having trouble calling a function I
>> added above -main...)
>>
>> That happened to me and in my case it was because I hadn't saved the
>> changed file... thought I did because I had hit command-s (on a mac) while
>> Nightcode save is control-s.
>>
>> > One big issue I see right now: no smart indentation in the editor
>> window.
>>
>> Totally essential, IMHO.
>>
>> If I can dream big, after the core editing features, somewhere near the
>> top of my own feature wish-list would be a debugging feature that I think
>> is currently available for Clojure only in emacs via nrepl-ritz (oh,
>> actually now I think I see that it's available in a vim environment too):
>> the ability to browse or at least print the values of locals up and down
>> the stack at the point of an exception (presumably in a run with
>> locals-clearing off, although it'd be great to see whatever hasn't been
>> cleared anyway).
>>
>> There's a long thread of discussion about this and related ideas here:
>> https://groups.google.com/**forum/#!topic/clojure/**qhdCrUoT_O0
>>
>> It'd be totally fabulous to have this feature in a Clojure IDE that's as
>> clean and usable as Clooj or Nightcode.
>>
>>  -Lee
>>
>>
>>
>>
>>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To 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/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Zach Oakes]

That's a good point, I should be using command instead of control on OSX. I 
don't have a Mac so that slipped my mind; I'll make a note of it.

On Friday, August 2, 2013 2:54:45 PM UTC-4, Lee wrote:
>
>
> On Aug 2, 2013, at 1:53 PM, Jeff Heon wrote: 
> > If I can suggest the one feature that I couldn't bear to use an IDE 
> without: 
> > Strict Structural Editing Mode (paredit-style) 
>
> But please note that while many love paredit, many others hate it -- so if 
> you implement this I would make it optional. 
>
> Also: 
>
> On Aug 2, 2013, at 2:26 PM, John Gabriele wrote: 
> > . (Hm, when using "Run with REPL", having trouble calling a function I 
> added above -main...) 
>
> That happened to me and in my case it was because I hadn't saved the 
> changed file... thought I did because I had hit command-s (on a mac) while 
> Nightcode save is control-s. 
>
> > One big issue I see right now: no smart indentation in the editor 
> window. 
>
> Totally essential, IMHO. 
>
> If I can dream big, after the core editing features, somewhere near the 
> top of my own feature wish-list would be a debugging feature that I think 
> is currently available for Clojure only in emacs via nrepl-ritz (oh, 
> actually now I think I see that it's available in a vim environment too): 
> the ability to browse or at least print the values of locals up and down 
> the stack at the point of an exception (presumably in a run with 
> locals-clearing off, although it'd be great to see whatever hasn't been 
> cleared anyway). 
>
> There's a long thread of discussion about this and related ideas here: 
> https://groups.google.com/forum/#!topic/clojure/qhdCrUoT_O0 
>
> It'd be totally fabulous to have this feature in a Clojure IDE that's as 
> clean and usable as Clooj or Nightcode. 
>
>  -Lee 
>
>
>
>
>

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

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Lee Spector]

On Aug 2, 2013, at 1:53 PM, Jeff Heon wrote:
> If I can suggest the one feature that I couldn't bear to use an IDE without:
> Strict Structural Editing Mode (paredit-style)

But please note that while many love paredit, many others hate it -- so if you 
implement this I would make it optional.

Also:

On Aug 2, 2013, at 2:26 PM, John Gabriele wrote:
> . (Hm, when using "Run with REPL", having trouble calling a function I added 
> above -main...)

That happened to me and in my case it was because I hadn't saved the changed 
file... thought I did because I had hit command-s (on a mac) while Nightcode 
save is control-s.

> One big issue I see right now: no smart indentation in the editor window.

Totally essential, IMHO.

If I can dream big, after the core editing features, somewhere near the top of 
my own feature wish-list would be a debugging feature that I think is currently 
available for Clojure only in emacs via nrepl-ritz (oh, actually now I think I 
see that it's available in a vim environment too): the ability to browse or at 
least print the values of locals up and down the stack at the point of an 
exception (presumably in a run with locals-clearing off, although it'd be great 
to see whatever hasn't been cleared anyway).

There's a long thread of discussion about this and related ideas here: 
https://groups.google.com/forum/#!topic/clojure/qhdCrUoT_O0

It'd be totally fabulous to have this feature in a Clojure IDE that's as clean 
and usable as Clooj or Nightcode.

 -Lee




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

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Zach Oakes]

I agree that better parenthesis and indentation behavior is a must; I'll 
add that to my list. The REPL at the bottom left is not associated with 
your project; I thought it would be nice to just have a bare, always-on 
REPL to test clojure commands.

The "Run with REPL" button should use the leiningen REPL with your 
project's namespaces available, but I don't yet have any interaction 
between the editor and REPL, so any functions you add after loading the 
REPL won't be available -- I'll be fixing this soon.

A few people mentioned to me that they are getting errors when trying to 
run or build anything. I'll be overhauling how Leiningen is run so that 
should be fixed soon -- like I mentioned in the original post, I am 
currently running it in a separate process and it's quite slow and 
inefficient even when it works.

On Friday, August 2, 2013 2:26:44 PM UTC-4, John Gabriele wrote:
>
> On Friday, August 2, 2013 9:03:03 AM UTC-4, Zach Oakes wrote:
>>
>> I’ve been working on a simple IDE for the past few months. It started as 
>> an attempt to add Leiningen integration to Clooj, but eventually I decided 
>> to start a new project from scratch. It is very alpha-quality, so please be 
>> gentle:
>>
>> http://nightcode.info/
>>
>>
> Some comments:
>
>   * Wow the GUI looks amazing! Works great as well.
>   * Rather than use a built-in lein, is there any way I can have it use my 
> own ~/bin/lein? Why does it come with its own leiningen?
>   * To open an existing project: Why "import" rather than "open"?
>
> Is the repl at the bottom-left associated with a given project? It seems 
> to be the same as if I'd run `lein repl` in the dir from where I ran the 
> jar. (Hm. I can't get at any `(doc whatever)` from here...)
>
> The buttons below the text-editing area correspond to the project to which 
> the given open file belongs, correct? If so, that's really nice. (Hm, when 
> using "Run with REPL", having trouble calling a function I added above 
> -main...)
>
> One big issue I see right now: no smart indentation in the editor window.
>
> Seems to be quite a nice piece of work so far!
>
> -- 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
--- 
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/groups/opt_out.

Re: [ANN] Nightcode, an IDE for Clojure and Java

[John Gabriele]

On Friday, August 2, 2013 9:03:03 AM UTC-4, Zach Oakes wrote:
>
> I’ve been working on a simple IDE for the past few months. It started as 
> an attempt to add Leiningen integration to Clooj, but eventually I decided 
> to start a new project from scratch. It is very alpha-quality, so please be 
> gentle:
>
> http://nightcode.info/
>
>
Some comments:

  * Wow the GUI looks amazing! Works great as well.
  * Rather than use a built-in lein, is there any way I can have it use my 
own ~/bin/lein? Why does it come with its own leiningen?
  * To open an existing project: Why "import" rather than "open"?

Is the repl at the bottom-left associated with a given project? It seems to 
be the same as if I'd run `lein repl` in the dir from where I ran the jar. 
(Hm. I can't get at any `(doc whatever)` from here...)

The buttons below the text-editing area correspond to the project to which 
the given open file belongs, correct? If so, that's really nice. (Hm, when 
using "Run with REPL", having trouble calling a function I added above 
-main...)

One big issue I see right now: no smart indentation in the editor window.

Seems to be quite a nice piece of work so far!

-- 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
--- 
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/groups/opt_out.

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Jeff Heon]

That's really cool. Thank you for doing this!

I really like the import feature, coloring and keyboard friendlyness.

If I can suggest the one feature that I couldn't bear to use an IDE without:
Strict Structural Editing Mode 
(paredit-style)

Basically I get pissed-off if an editor kills my selected expression when I 
type a paren or some other twin delimiter 8)

I even wish I had it when editing other languages than 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/groups/opt_out.

Re: Two Dimensional Associative Map

[Kevin Downey]

On 8/1/13 5:59 PM, JvJ wrote:
> I'm looking for an associative data structure that can be accessed by both 
> rows and columns, and could potentially be sparse.
> 
> Suppose the following table is called t:
> 
> |   | :A   | :B   | :C   ||---+--+--+--|| 1 |  |  
> | '[x y z] || 2 | "2a" | "2b" |  || 3 |  |  |  || 3 | 
> :3a  |  | "Foo"|
> 
> 
> Then (t :A) would return {2 "2a", 3 :3a}, and (t 2) would return {:A "2a", 
> :B "2b"}.
> (t :A 2) or (t 2 :A) would return "2a".
> 
> I'm thinking of implementing it as a simple map of maps with some extra 
> functions, but I'm not sure if
> that would be the best option.
> 
> 
I would recommend looking at the clojure.set namespace. it has an index
function which builds indices

user> (require '[clojure.set :as s])
nil
user> (clojure.repl/doc s/index)
-
clojure.set/index
([xrel ks])
  Returns a map of the distinct values of ks in the xrel mapped to a
  set of the maps in xrel with the corresponding values of ks.
nil
user> (s/index [{:row 1 :col 2}] [:row])
{{:row 1} #{{:row 1, :col 2}}}
user> (merge (s/index [{:row 1 :col 2}] [:row]) (s/index [{:row 1 :col
2}] [:col]) (s/index [{:row 1 :col 2}] [:row :col]))
{{:col 2, :row 1} #{{:row 1, :col 2}}, {:col 2} #{{:row 1, :col 2}},
{:row 1} #{{:row 1, :col 2}}}
user> (def d (merge (s/index [{:row 1 :col 2}] [:row]) (s/index [{:row 1
:col 2}] [:col]) (s/index [{:row 1 :col 2}] [:row :col])))
#'user/d
user> (get d {:col 2})
#{{:row 1, :col 2}}
user> (get d {:row 1})
#{{:row 1, :col 2}}
user> (get d {:row 1 :col 2})
#{{:row 1, :col 2}}
user>

-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?



signature.asc
Description: OpenPGP digital signature

Hiring Clojure Programmer(s)

[Quinn Finney]

Hello all,

My company is looking to hire a Clojure programmer to help assess and 
finish our product, a server architecture system for Java instances. The 
product involves receiving input from a web control panel and making 
changes based on that. To our knowledge, the product is currently 85% 
complete. This will be a payed position. Please email me at 
quinn.fin...@gmail.com or call me at (206) 660 5366 for more information if 
you are interested. 

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Zach Oakes]

I have no problem using third-party code that is copyright-licensed, but 
for the sake of sanity I'd prefer that modifications to my own code be 
public domain -- it can get really absurd if one line of code in a file is 
EPL-licensed and the rest is public domain. There should not be any issue 
with using my code in other projects.

On Friday, August 2, 2013 11:56:01 AM UTC-4, Laurent PETIT wrote:
>
> 2013/8/2 Zach Oakes >: 
> > I definitely plan on continuing development of Nightcode. As of 
> yesterday, I 
> > am unemployed, so for the time being I have a lot of time on my hands. I 
> am 
> > hoping to support myself with freelancing and tutoring in the Pittsburgh 
> > area. If that works out, I should be able to work on Nightcode (and my 
> other 
> > project, Nightweb) indefinitely. We'll see how it goes. 
>
> That's great. Because Clojure deserves an easy entry point. I like 
> what I've seen so far, it's inspiring. 
>
>
> > As for my choice of public domain, I always do that for my projects. I 
> > realize that I am going against the grain, but it's a principled issue 
> for 
> > me. I wrote about it on my blog, but if you'd like to discuss it further 
> we 
> > should do it elsewhere because it can easily derail the thread. 
>
> I will not start a discussion on the merits of public domain over EPL 
> or vice versa. 
>
> Just want to notice that you have a whole ecosystem around your 
> codebase, upon which you depend, which may start to depend upon you 
> also, and it is not public domain. 
>
> And I think it would probably help exchanging code between those 
> projects and yours if they have compatible licenses. Of course I can 
> see public domain code migrating easily to EPL code, but is the 
> reverse true? 
>
> All I need to know is if you're willing to "stand by your rule" for 
> nightcode, or make an exception. 
>
> Cheers, 
>
> -- 
> Laurent 
>

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

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Laurent PETIT]

2013/8/2 Zach Oakes :
> I definitely plan on continuing development of Nightcode. As of yesterday, I
> am unemployed, so for the time being I have a lot of time on my hands. I am
> hoping to support myself with freelancing and tutoring in the Pittsburgh
> area. If that works out, I should be able to work on Nightcode (and my other
> project, Nightweb) indefinitely. We'll see how it goes.

That's great. Because Clojure deserves an easy entry point. I like
what I've seen so far, it's inspiring.


> As for my choice of public domain, I always do that for my projects. I
> realize that I am going against the grain, but it's a principled issue for
> me. I wrote about it on my blog, but if you'd like to discuss it further we
> should do it elsewhere because it can easily derail the thread.

I will not start a discussion on the merits of public domain over EPL
or vice versa.

Just want to notice that you have a whole ecosystem around your
codebase, upon which you depend, which may start to depend upon you
also, and it is not public domain.

And I think it would probably help exchanging code between those
projects and yours if they have compatible licenses. Of course I can
see public domain code migrating easily to EPL code, but is the
reverse true?

All I need to know is if you're willing to "stand by your rule" for
nightcode, or make an exception.

Cheers,

-- 
Laurent

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

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Zach Oakes]

I definitely plan on continuing development of Nightcode. As of yesterday, 
I am unemployed, so for the time being I have a lot of time on my hands. I 
am hoping to support myself with freelancing and tutoring in the Pittsburgh 
area. If that works out, I should be able to work on Nightcode (and my 
other project, Nightweb) indefinitely. We'll see how it goes.

As for my choice of public domain, I always do that for my projects. I 
realize that I am going against the grain, but it's a principled issue for 
me. I wrote about it on my blog, 
but if you'd like to discuss it further we should do it elsewhere because 
it can easily derail the thread.

On Friday, August 2, 2013 11:36:28 AM UTC-4, Laurent PETIT wrote:
>
> Great initiative ! 
>
> Is it okay if I ask what your plans are? 
> Asking because in the past, there have been similar initiative which 
> are now either dead or at a slow pace, so it'd be good to know if it's 
> a between-2-jobs project that might not be pursued in the future, or 
> if you're serious about giving it time for a long period, etc. Feel 
> free to answer or not :-) 
>
> I saw that you use "public domain" as a license. Why so? I can see 
> people be relunctant to publish their work / submit pull requests with 
> such a "free for everyone" type of license. But maybe it's just me. 
> What about the EPL, the same as Clojure, Leiningen, Counterclockwise, 
> and a buuunnnch of other clojure all around us? 
>
>
>
>
> 2013/8/2 Zach Oakes >: 
> > I’ve been working on a simple IDE for the past few months. It started as 
> an 
> > attempt to add Leiningen integration to Clooj, but eventually I decided 
> to 
> > start a new project from scratch. It is very alpha-quality, so please be 
> > gentle: 
> > 
> > 
> > http://nightcode.info/ 
> > 
> > 
> > Here’s what it has: 
> > 
> > 
> > -Written in Clojure (the UI is written with seesaw) 
> > 
> > -Built-in copy of Leiningen to build Clojure and pure-Java projects 
> > 
> > -Built-in templates for several common types of Clojure and Java 
> projects 
> > 
> > -Always-on REPL in the corner to try Clojure commands 
> > 
> > -Android integration (includes the lein-droid plugin, LogCat output, 
> etc) 
> > 
> > -ClojureScript integration (includes the lein-cljsbuild plugin) 
> > 
> > -Cool looking dark theme, because that’s trendy these days 
> > 
> > 
> > Here’s what it’s missing: 
> > 
> > 
> > -Fast build times (it launches Leiningen in a separate process, which is 
> > slw...I plan on fixing this and would love any help) 
> > 
> > -Important editing features (code completion, text replace, etc) 
> > 
> > -Quick switching between recent files 
> > 
> > -Jump to definition, built-in documentation 
> > 
> > -Integration between editor and REPL (eval form or entire file) 
> > 
> > -Integration with git 
> > 
> > -Many other things -- please give me your thoughts! 
> > 
> > -- 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@googlegroups.com 
> > Note that posts from new members are moderated - please be patient with 
> your 
> > first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@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+u...@googlegroups.com . 
> > For more options, visit https://groups.google.com/groups/opt_out. 
> > 
> > 
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: Two Dimensional Associative Map

[Mikera]

It wasn't designed for Clojure originally, but I have an immutable "grid" 
persistent data structure in Java that I've used with some success in 
Clojure. It works nicely and efficiently with Clojure idioms because it is 
a proper persistent data structure (with a 64-way branching factor).

https://github.com/mikera/mikera/blob/master/src/main/java/mikera/engine/PersistentTreeGrid.java

It's actually a 3D grid, but you can use just 2 dimensions and keep the 3rd 
set to zero.


On Friday, 2 August 2013 01:59:40 UTC+1, JvJ wrote:
>
> I'm looking for an associative data structure that can be accessed by both 
> rows and columns, and could potentially be sparse.
>
> Suppose the following table is called t:
>
> |   | :A   | :B   | :C   ||---+--+--+--|| 1 |  |  
> | '[x y z] || 2 | "2a" | "2b" |  || 3 |  |  |  || 3 | 
> :3a  |  | "Foo"|
>
>
> Then (t :A) would return {2 "2a", 3 :3a}, and (t 2) would return {:A "2a", 
> :B "2b"}.
> (t :A 2) or (t 2 :A) would return "2a".
>
> I'm thinking of implementing it as a simple map of maps with some extra 
> functions, but I'm not sure if
> that would be the best option.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Laurent PETIT]

Great initiative !

Is it okay if I ask what your plans are?
Asking because in the past, there have been similar initiative which
are now either dead or at a slow pace, so it'd be good to know if it's
a between-2-jobs project that might not be pursued in the future, or
if you're serious about giving it time for a long period, etc. Feel
free to answer or not :-)

I saw that you use "public domain" as a license. Why so? I can see
people be relunctant to publish their work / submit pull requests with
such a "free for everyone" type of license. But maybe it's just me.
What about the EPL, the same as Clojure, Leiningen, Counterclockwise,
and a buuunnnch of other clojure all around us?




2013/8/2 Zach Oakes :
> I’ve been working on a simple IDE for the past few months. It started as an
> attempt to add Leiningen integration to Clooj, but eventually I decided to
> start a new project from scratch. It is very alpha-quality, so please be
> gentle:
>
>
> http://nightcode.info/
>
>
> Here’s what it has:
>
>
> -Written in Clojure (the UI is written with seesaw)
>
> -Built-in copy of Leiningen to build Clojure and pure-Java projects
>
> -Built-in templates for several common types of Clojure and Java projects
>
> -Always-on REPL in the corner to try Clojure commands
>
> -Android integration (includes the lein-droid plugin, LogCat output, etc)
>
> -ClojureScript integration (includes the lein-cljsbuild plugin)
>
> -Cool looking dark theme, because that’s trendy these days
>
>
> Here’s what it’s missing:
>
>
> -Fast build times (it launches Leiningen in a separate process, which is
> slw...I plan on fixing this and would love any help)
>
> -Important editing features (code completion, text replace, etc)
>
> -Quick switching between recent files
>
> -Jump to definition, built-in documentation
>
> -Integration between editor and REPL (eval form or entire file)
>
> -Integration with git
>
> -Many other things -- please give me your thoughts!
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> 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/groups/opt_out.
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Arie van Wingerden]

What a fantastic initiative!
It already looks great and promises a lot.
I love the leight weight approach, still having lots of features.
Keep up the good work!


2013/8/2 Alexander Yakushev 

> This initial version looks very mature already! I wonder what will become
> of it by the time of the release.
>
> Great job, Zach! Eagerly waiting to see Nightcode's future.
>
>
> On Friday, August 2, 2013 4:03:03 PM UTC+3, Zach Oakes wrote:
>>
>> I’ve been working on a simple IDE for the past few months. It started as
>> an attempt to add Leiningen integration to Clooj, but eventually I decided
>> to start a new project from scratch. It is very alpha-quality, so please be
>> gentle:
>>
>> http://nightcode.info/
>>
>> Here’s what it has:
>>
>> -Written in Clojure (the UI is written with seesaw)
>>
>> -Built-in copy of Leiningen to build Clojure and pure-Java projects
>>
>> -Built-in templates for several common types of Clojure and Java projects
>>
>> -Always-on REPL in the corner to try Clojure commands
>>
>> -Android integration (includes the lein-droid plugin, LogCat output, etc)
>>
>> -ClojureScript integration (includes the lein-cljsbuild plugin)
>>
>> -Cool looking dark theme, because that’s trendy these days
>>
>> Here’s what it’s missing:
>>
>> -Fast build times (it launches Leiningen in a separate process, which is
>> slw...I plan on fixing this and would love any help)
>>
>> -Important editing features (code completion, text replace, etc)
>>
>> -Quick switching between recent files
>>
>> -Jump to definition, built-in documentation
>>
>> -Integration between editor and REPL (eval form or entire file)
>>
>> -Integration with git
>> -Many other things -- please give me your thoughts!
>>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> 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/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Steven Degutis]

Excited to try it out! Thanks for your hard work :)


On Fri, Aug 2, 2013 at 8:03 AM, Zach Oakes  wrote:

> I’ve been working on a simple IDE for the past few months. It started as
> an attempt to add Leiningen integration to Clooj, but eventually I decided
> to start a new project from scratch. It is very alpha-quality, so please be
> gentle:
>
> http://nightcode.info/
>
> Here’s what it has:
>
> -Written in Clojure (the UI is written with seesaw)
>
> -Built-in copy of Leiningen to build Clojure and pure-Java projects
>
> -Built-in templates for several common types of Clojure and Java projects
>
> -Always-on REPL in the corner to try Clojure commands
>
> -Android integration (includes the lein-droid plugin, LogCat output, etc)
>
> -ClojureScript integration (includes the lein-cljsbuild plugin)
>
> -Cool looking dark theme, because that’s trendy these days
>
> Here’s what it’s missing:
>
> -Fast build times (it launches Leiningen in a separate process, which is
> slw...I plan on fixing this and would love any help)
>
> -Important editing features (code completion, text replace, etc)
>
> -Quick switching between recent files
>
> -Jump to definition, built-in documentation
>
> -Integration between editor and REPL (eval form or entire file)
>
> -Integration with git
> -Many other things -- please give me your thoughts!
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> 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/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: RPC over channels

[James Ashley]

>
>
>   RPC over channels
>
>
>
>
>toberepla...@gmail.com Aug 01 10:09AM -0700
>
> With
>ZeroMQ, it might be a router that delivers your request to the machine
>it
>thinks is most likely to be able to handle the request. The system
>serving
>your requests could be a single process executing blocking calls to a
>third-party http rest api, or it could be a network of load-balancing
>machines.
>
>
...

>
>
>There would be no intent to solve the messenger problem explicitly --
>those
>semantics are up to the user. By default, in the case of server death,
>the
>client side will just no longer receive responses on its
>receive-channel.
>In the case of a blocking call, this means that the client side will
>hang.
>
>
Hung clients are bad.

Reliable request/reply gets hairy very quickly. The zeromq guide devotes a
long chapter to it.

The simplest (and least useful) approach they suggest is what they call the
Lazy Pirate Pattern.

The nutshell version:
The server listens on a robust socket that can handle multiple requests
from the same client (a Dealer, in 0mq terms). The client connects with
their brain-dead REQ socket, sends the request, then periodically polls for
a response. If it doesn't get a response before some time out, it drops the
socket and reconnects. After a certain number of retries, it gives up and
notifies the user that it's lost the server connection.

There's obviously a lot of black magic going on behind the scenes, but
that's a big part of the point of using an MQ.

I don't have any idea about how the other MQ's handle this sort of thing.

Just to try to keep this on-topic:
I haven't had a chance yet to experiment with how well core.async
cooperates with 0mq's basic strategy. It looks like there are a lot of
really cool possibilities, and I think that some of the projects I'm seeing
in this area are really exciting.

Regards,
James

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

Re: RPC over channels

[ToBeReplaced]

I'm uneducated here since I've not used Erlang in any real capacity.  I 
thought that typically if A sent a message to B that caused B to raise 
an exception, that B would send an exception back to A and that A would 
error out.  Thus, the client is blamed for the exception.  Is this 
correct?  In clojure, I would have written this pattern via populating 
channels with exceptions:


server -> receive-channel -> 
deserialize-or-throw-if-exception-on-channel -> client-receive-channel.


The deserialize-or-throw-if-exception-on-channel would be in a go block, 
which would error out before the client sees anything.  If a supervisor 
wants to restart that it would be their business.  In the event that 
every 100th RPC call receives one of these exceptions, eventually every 
client would die, or their supervisors would restart them.


I'm wondering if maybe I have different expectations of RPC from 
Timothy.  I would like to view RPC as inherently unreliable.  "send" 
would have many different options -- send and pray, send and wait for 
ack, send and return control before you've finished serializing, etc.  
"receive" could be async, could be blocking, could require a UUID it's 
looking for a response to, could have a timeout, could have a timeout 
function, etc.


What would OTP look like over channels?

-ToBeReplaced

On 08/02/2013 10:16 AM, Marc Hämmerle wrote:
On Erlang: sometimes you *want* to block on a node and wait for the 
answer of a remote node. It's implemented as message passing under the 
hood - the process gets de-scheduled, restarted in case of crash if 
you want et al. - but the semantics are clearly sequential and 
blocking. Erlang obviously also has benefits in that area with OTP 
supervision and the lightweight processes - but doesn't core.async 
have at least the last one too?


Take a look into Basho's riak_core 
(https://github.com/basho/riak_core) and other distributed systems 
written in Erlang: heavy use of RPC calls.


So I'd say on RPC: clearly depends on your needs and is not 
automatically bad.


Marc


On 2 August 2013 15:46, Timothy Baldridge > wrote:


RPC ties a local process (and all the memory its currently using)
to a remote process. It glosses over the fact that that the link
between these two processes is quite unreliable. In his thesis,
Joe Armstrong also points that this system is not only susceptible
to hardware/network failure, it's also very susceptible to
programming failures. A bug in your code could cause every 100th
RPC call to fail, for example.

So instead of all of this, Erlang (or actually Erlang's OTP
libraries) proposes a different view:

1) all messages are sent async and unreliable. This is the way
networks are designed anyways, if you sent a message to a remote
system and it gets thrown into a queue, you really don't know what
happens to that message in the end, except by asking the remote
system again, and again until you finally get an ACK.

2) If we follow the above model, then we can start programming in
a fail-fast mode. This is what OTP is based on. Supervisor
processes that reset dead sub processes. This is also why I'm not
a fan of populating error messages across channels. Instead,
errors should kill go blocks, and then those blocks should be
restarted by supervisors.

So RPC assumes that every call will succeed. Message passing
systems assume that it's kind-of-sort-of-not-really-likely that
your message will arrive at the remote system. It's a pessimistic
view of the world. And with the systems I work with, this is the
best approach.

So I guess this is a super long way of saying I love the OTP style
and would love to see it ported to core.async. But RPC is not the
way, blocking send/recv is not the way. To get reliable systems
you need your system to always be capable of forward progress, and
having a local process tightly coupled to a remote process will
not get you there.

Timothy


On Thu, Aug 1, 2013 at 1:55 PM, ToBeReplaced
mailto:toberepla...@gmail.com>> wrote:

A client could use a timeout channel as its receive channel to
get timeouts on a blocking call, though I don't think that's
the right way to do it.  Alternatively, implementing a
blocking call with an optional timeout wouldn't be difficult,
it just can't be the default.

I think if you disallowed nil as a response, then it would be
easy to use a variety of different blocking calls -- wait
forever, wait 30 seconds, wait until (f) returns truthy, etc.

-ToBeReplaced


On 08/01/2013 03:36 PM, Cedric Greevey wrote:

On Thu, Aug 1, 2013 at 1:09 PM, mailto:toberepla...@gmail.com>> wrote:

There would be no intent to solve the messenger problem
explicitly -- those semantics are up to the user.  By
default

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Alexander Yakushev]

This initial version looks very mature already! I wonder what will become 
of it by the time of the release.

Great job, Zach! Eagerly waiting to see Nightcode's future.

On Friday, August 2, 2013 4:03:03 PM UTC+3, Zach Oakes wrote:
>
> I’ve been working on a simple IDE for the past few months. It started as 
> an attempt to add Leiningen integration to Clooj, but eventually I decided 
> to start a new project from scratch. It is very alpha-quality, so please be 
> gentle:
>
> http://nightcode.info/
>
> Here’s what it has:
>
> -Written in Clojure (the UI is written with seesaw)
>
> -Built-in copy of Leiningen to build Clojure and pure-Java projects
>
> -Built-in templates for several common types of Clojure and Java projects
>
> -Always-on REPL in the corner to try Clojure commands
>
> -Android integration (includes the lein-droid plugin, LogCat output, etc)
>
> -ClojureScript integration (includes the lein-cljsbuild plugin)
>
> -Cool looking dark theme, because that’s trendy these days
>
> Here’s what it’s missing:
>
> -Fast build times (it launches Leiningen in a separate process, which is 
> slw...I plan on fixing this and would love any help)
>
> -Important editing features (code completion, text replace, etc)
>
> -Quick switching between recent files
>
> -Jump to definition, built-in documentation
>
> -Integration between editor and REPL (eval form or entire file)
>
> -Integration with git
> -Many other things -- please give me your thoughts!
>

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

Re: Two Dimensional Associative Map

[glow]

This simple solution is symetrical, stores both rows and colums and this 
way you get instant access both to any column and row with constant penalty 
on get, assoc and update.

It feels a bit messy because you decided to not differentiate between 
horizontal and vertical indices. That may be a good choice and give nice 
code later, but is somewhat surprising (you must be sure that sets of 
horizontal and vertical indices are disjoint). 

(defn get2d 
  ([t i] (into (into {} ((first t) i)) ((second t) i)))
  ([t x y] (if-let [res (get-in (first t) [x y])]
 res
 (get-in (second t) [x y]

(defn assoc2d [[rows cols] [x y] v]
[(assoc-in rows [x y] v) (assoc-in cols [y x] v)])

Your example:

user=>  (def foo (-> [] (assoc2d [1 :C] '[x y z]) (assoc2d [2 :A] "2a") 
(assoc2d [2 :B] "2b") (assoc2d [3 :A] :3a) (assoc2d [3 :C] "Foo")))
#'user/foo

user=>  foo
[{3 {:C "Foo", :A :3a}, 2 {:B "2b", :A "2a"}, 1 {:C [x y z]}}
 {:B {2 "2b"}, :A {3 :3a, 2 "2a"}, :C {3 "Foo", 1 [x y z]}}]

user=>  (get2d foo :A)
{3 :3a, 2 "2a"}

user=>  (get2d foo 2)
{:B "2b", :A "2a"}

user=>  (get2d foo :A 2)
"2a"

user=>  (get2d foo 2 :A)
"2a"


Please note the double into in get2d. Simple (into ((first t) i) ((second 
t) i)) doesn't work as expected when first argument is nil. 
To make get2d and assoc2d more consistent one could remove brackets around 
[x y] in the argument list of assoc2d.


-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: RPC over channels

[Marc Hämmerle]

On Erlang: sometimes you *want* to block on a node and wait for the answer
of a remote node. It's implemented as message passing under the hood - the
process gets de-scheduled, restarted in case of crash if you want et al. -
but the semantics are clearly sequential and blocking. Erlang obviously
also has benefits in that area with OTP supervision and the lightweight
processes - but doesn't core.async have at least the last one too?

Take a look into Basho's riak_core (https://github.com/basho/riak_core) and
other distributed systems written in Erlang: heavy use of RPC calls.

So I'd say on RPC: clearly depends on your needs and is not automatically
bad.

Marc


On 2 August 2013 15:46, Timothy Baldridge  wrote:

> RPC ties a local process (and all the memory its currently using) to a
> remote process. It glosses over the fact that that the link between these
> two processes is quite unreliable. In his thesis, Joe Armstrong also points
> that this system is not only susceptible to hardware/network failure, it's
> also very susceptible to programming failures. A bug in your code could
> cause every 100th RPC call to fail, for example.
>
> So instead of all of this, Erlang (or actually Erlang's OTP libraries)
> proposes a different view:
>
> 1) all messages are sent async and unreliable. This is the way networks
> are designed anyways, if you sent a message to a remote system and it gets
> thrown into a queue, you really don't know what happens to that message in
> the end, except by asking the remote system again, and again until you
> finally get an ACK.
>
> 2) If we follow the above model, then we can start programming in a
> fail-fast mode. This is what OTP is based on. Supervisor processes that
> reset dead sub processes. This is also why I'm not a fan of populating
> error messages across channels. Instead, errors should kill go blocks, and
> then those blocks should be restarted by supervisors.
>
> So RPC assumes that every call will succeed. Message passing systems
> assume that it's kind-of-sort-of-not-really-likely that your message will
> arrive at the remote system. It's a pessimistic view of the world. And with
> the systems I work with, this is the best approach.
>
> So I guess this is a super long way of saying I love the OTP style and
> would love to see it ported to core.async. But RPC is not the way, blocking
> send/recv is not the way. To get reliable systems you need your system to
> always be capable of forward progress, and having a local process tightly
> coupled to a remote process will not get you there.
>
> Timothy
>
>
> On Thu, Aug 1, 2013 at 1:55 PM, ToBeReplaced wrote:
>
>>  A client could use a timeout channel as its receive channel to get
>> timeouts on a blocking call, though I don't think that's the right way to
>> do it.  Alternatively, implementing a blocking call with an optional
>> timeout wouldn't be difficult, it just can't be the default.
>>
>> I think if you disallowed nil as a response, then it would be easy to use
>> a variety of different blocking calls -- wait forever, wait 30 seconds,
>> wait until (f) returns truthy, etc.
>>
>> -ToBeReplaced
>>
>>
>> On 08/01/2013 03:36 PM, Cedric Greevey wrote:
>>
>>  On Thu, Aug 1, 2013 at 1:09 PM,  wrote:
>>
>>> There would be no intent to solve the messenger problem explicitly --
>>> those semantics are up to the user.  By default, in the case of server
>>> death, the client side will just no longer receive responses on its
>>> receive-channel.  In the case of a blocking call, this means that the
>>> client side will hang.
>>>
>>
>>  Ugh. At the *very* least it should eventually return with some kind of
>> a timeout exception.
>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from 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 a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/P95cOfuXBUs/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+unsubscr...@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> -

the snake game with core.async and swing

[eliassonaand]

Below is a little (stupid) snake game I wrote using core.async and swing.
It uses channels for timer, keyboard input and repaint to make everything 
nice and sequential.
Thought it could be a nice example of the power of core.async.

I'm not an experienced clojure/lisp developer so I'd be happy if someone 
could give me some feedback on the code.
Is it clojure idiomatic?
Am I using core.async properly?
etc.

Thanks
--anders


(ns my-test
  (use [midje.sweet])
  (require [clojure.core.async :as async :refer :all])
  (import [javax.swing JFrame JButton JPanel SwingUtilities])
  (import [java.awt Color Dimension])
  (import [java.awt.event ActionListener WindowAdapter KeyListener]))


(defn map-chan [f in]
  (let [c (chan)]
(go (loop []
  (when-let [v (f (! c v))
  (recur)))
c))

(defn start-timer! []
  (let [c (chan)]
(go (while true (! c :go)))
c))

(defn closing-channel [frame]
  (let [c (chan)]
(.addWindowListener frame
(proxy [WindowAdapter] []
  (windowClosing [e] (put! c e
c))

(defn array-of [coordinates index]
  (int-array (map #(nth % index) coordinates)))

(defn points-of [coordinates]
  [(array-of coordinates 0) (array-of coordinates 1)])

(defn draw-poly-line [canvas coordinates]
  (SwingUtilities/invokeLater
   (fn []
 (let [[x-points y-points] (points-of coordinates)
   g (.getGraphics canvas)
   prev-color (.getColor g)]
  (.setColor g Color/BLACK)
  (.drawPolyline g x-points y-points (count coordinates))
  (.setColor g prev-color)

(def step 5)
(defmulti calc-new-pos (fn[xy prev-pos dir] [xy dir]))
(defmethod calc-new-pos [:x :right][xy prev-pos dir] (+ prev-pos step))
(defmethod calc-new-pos [:x :left][xy prev-pos dir] (- prev-pos step))
(defmethod calc-new-pos [:y :down][xy prev-pos dir] (+ prev-pos step))
(defmethod calc-new-pos [:y :up][xy prev-pos dir] (- prev-pos step))
(defmethod calc-new-pos :default [xy prev-pos dir] prev-pos)

(defn calc-snake [dir snake-obj counter]
  (let [[l-x l-y] (last snake-obj)
old-snake (if (= (mod counter 2) 0) snake-obj (rest snake-obj))]
(conj (vec old-snake) [(calc-new-pos :x l-x dir) (calc-new-pos :y l-y 
dir)])))

(facts "snake positions"
   (fact "snake moves and grows"
 (calc-snake :right [[1 2]] 2) => [[1 2] [6 2]]
 (calc-snake :right [[2 2]] 4) => [[2 2] [7 2]])
   (facts "snake moves"
  (calc-snake :right [[1 2]] 1) => [[6 2]]
  (calc-snake :down [[1 2]] 1) => [[1 7]]
  (calc-snake :left [[10 2]] 1) => [[5 2]]
  (calc-snake :up [[10 7]] 1) => [[10 2]]
  ))

(def key-to-dir-map {37 :left, 38 :up, 39 :right, 40 :down})

(defn key-channel [obj]
  (let [c (chan)]
(.addKeyListener obj
 (reify KeyListener
   (keyTyped [_ e] )
   (keyPressed [_ e] )
   (keyReleased [_ e]
 (put! c e
c))

(defn create-canvas [paint-channel]
  (proxy [JButton] []
 (getPreferredSize [] (Dimension. 300 300))
 (paintComponent [g]
   (go
 (proxy-super paintComponent g)
 (>! paint-channel :repaint)

(defmulti inside-window? (fn [dir canvas pos] dir))
(defmethod inside-window? :left [dir canvas [x _]] (>= x (.getX canvas)))
(defmethod inside-window? :right [dir canvas [x _]] (<= x (+ (.getX canvas) 
(.getWidth canvas
(defmethod inside-window? :up [dir canvas [_ y]] (>= y (.getY canvas)))
(defmethod inside-window? :down [dir canvas [_ y]] (<= y (+ (.getY canvas) 
(.getHeight canvas



(def initial-snake (vec  (map (fn [x] [x 10])  (take 20 (iterate (partial + 
step) 0)


(defn game-rules-ok? [snake dir canvas]
  (and
   (apply distinct? snake)
   (inside-window? dir canvas (last snake

(facts "game rules"
   (let [canvas (JButton.)]
 (.setBounds canvas 0 0 10 10)
 (facts "inside window"
(game-rules-ok? [[0 0]] :right canvas) => truthy
(game-rules-ok? [[11 0]] :right canvas) => falsey
(game-rules-ok? [[11 0]] :left canvas) => truthy
(game-rules-ok? [[11 0]] :up canvas) => truthy
(game-rules-ok? [[11 0]] :down canvas) => truthy
(game-rules-ok? [[11 11]] :down canvas) => falsey)
 (facts "snake eating itself"
  (game-rules-ok? [[0 0] [0 0]] :right canvas) => falsey
  (game-rules-ok? [[0 0] [1 0]] :right canvas) => true
  )))
(defn you-loose! [cc]
  (println "you loose!")
  (put! cc :close))


(defn snake [cc]
  (let [paint-channel (chan)
timer-channel (start-timer!)
canvas (create-canvas paint-channel)
dir-channel (map-chan #(key-to-dir-map (.getKeyCode %)) 
(key-channel canvas))
]
(go
 (loop [last-dir :right
   snake-obj initial

Re: [ANN] Nightcode, an IDE for Clojure and Java

[Lee Spector]

On Aug 2, 2013, at 9:03 AM, Zach Oakes wrote:

> I’ve been working on a simple IDE for the past few months. It started as an 
> attempt to add Leiningen integration to Clooj, but eventually I decided to 
> start a new project from scratch. It is very alpha-quality, so please be 
> gentle:
> 
> http://nightcode.info/

Very exciting!

I've just given it a quick initial test and will definitely be trying it out 
more.

Thanks!!

 -Lee

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

Re: Displaying objects in REPL: Clojure equivalent of Java's toString?

[Dragan Djuric]

Thanks a lot, guys :)

On Friday, August 2, 2013 5:07:37 AM UTC+2, Armando Blancas wrote:
>
> Adding to that... have a look at the implemented methods in 
> core_print.clj. The print-method will get called on print and println with 
> your instance as the first argument. In this example prints a pair type; 
> since elements can be anything it just calls print on each.
>
> (deftype Pair [fst snd])
> (defmethod print-method Pair [r, ^java.io.Writer w]
>   (.write w "Pair(")
>   (print (.fst r))
>   (.write w ",")
>   (print (.snd r))
>   (.write w ")"))
>
> On Thursday, August 1, 2013 3:04:47 PM UTC-7, Laurent PETIT wrote:
>>
>> I think you have to provide methods for multimethods print-dup and 
>> print-method: 
>>
>>
>> https://github.com/clojure/clojure/blob/c6756a8bab137128c8119add29a25b0a88509900/src/clj/clojure/core.clj#L3311
>>  
>>
>> 2013/8/1 Dragan Djuric : 
>> > I have some custom types defined using deftype and I am trying to 
>> enable a 
>> > human-friendly string representation of these types in repl. Something 
>> > similar to #. How to do that in Clojure without 
>> redefining 
>> > toString? It seems that Clojure use a different way to achieve this for 
>> > atoms and refs, I just can't find what. 
>> > 
>> > -- 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> > Groups "Clojure" group. 
>> > To post to this group, send email to clo...@googlegroups.com 
>> > Note that posts from new members are moderated - please be patient with 
>> your 
>> > first post. 
>> > To unsubscribe from this group, send email to 
>> > clojure+u...@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+u...@googlegroups.com. 
>> > For more options, visit https://groups.google.com/groups/opt_out. 
>> > 
>> > 
>>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: extend-type on

[Phillip Lord]

Well, this is certainly a possibility. Especially if I do it at
compilation time, I can put the match functions for each class into an
array, and then combine them by climbing the class hierarchies.

Phil


"Jim - FooBar();"  writes:
> On 02/08/13 12:46, Jim - FooBar(); wrote:
>> or programmatically emit identical extension points for all
>> subinterfaces/subclasses
> (def ^:private co-stub
> '(run [this text]
>   (if (instance? edu.stanford.nlp.pipeline.Annotation text)
>   (do (.annotate this text) text)
>(let [ann (edu.stanford.nlp.pipeline.Annotation. ^String text)]
>  (.annotate this ann) ann
>
> (defn- emit-IComponent-impls* [syms]
>   (mapcat
> (fn [s]
>   [(symbol (str "edu.stanford.nlp.pipeline." s)) co-stub])
> syms))
>
> (defmacro ^:private emit-IComponent-impls [& syms]
>   `(extend-protocol IComponent
>  ~@(emit-IComponent-impls* syms)))
>
> and finally you call it like this:
>
> (emit-IComponent-impls ;nice trick to avoid enumerating all the identical
> implementations
>   POSTaggerAnnotator PTBTokenizerAnnotator WordsToSentencesAnnotator
> TokenizerAnnotator
>   CleanXmlAnnotator MorphaAnnotator NERCombinerAnnotator RegexNERAnnotator
>   TrueCaseAnnotator ParserAnnotator DeterministicCorefAnnotator)
>
> neat trick imo :)
>
> Jim
>
> -- 

-- 
Phillip Lord,   Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,   skype: russet_apples
Newcastle University,   twitter: phillord
NE1 7RU 

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: RPC over channels

[Timothy Baldridge]

RPC ties a local process (and all the memory its currently using) to a
remote process. It glosses over the fact that that the link between these
two processes is quite unreliable. In his thesis, Joe Armstrong also points
that this system is not only susceptible to hardware/network failure, it's
also very susceptible to programming failures. A bug in your code could
cause every 100th RPC call to fail, for example.

So instead of all of this, Erlang (or actually Erlang's OTP libraries)
proposes a different view:

1) all messages are sent async and unreliable. This is the way networks are
designed anyways, if you sent a message to a remote system and it gets
thrown into a queue, you really don't know what happens to that message in
the end, except by asking the remote system again, and again until you
finally get an ACK.

2) If we follow the above model, then we can start programming in a
fail-fast mode. This is what OTP is based on. Supervisor processes that
reset dead sub processes. This is also why I'm not a fan of populating
error messages across channels. Instead, errors should kill go blocks, and
then those blocks should be restarted by supervisors.

So RPC assumes that every call will succeed. Message passing systems assume
that it's kind-of-sort-of-not-really-likely that your message will arrive
at the remote system. It's a pessimistic view of the world. And with the
systems I work with, this is the best approach.

So I guess this is a super long way of saying I love the OTP style and
would love to see it ported to core.async. But RPC is not the way, blocking
send/recv is not the way. To get reliable systems you need your system to
always be capable of forward progress, and having a local process tightly
coupled to a remote process will not get you there.

Timothy


On Thu, Aug 1, 2013 at 1:55 PM, ToBeReplaced  wrote:

>  A client could use a timeout channel as its receive channel to get
> timeouts on a blocking call, though I don't think that's the right way to
> do it.  Alternatively, implementing a blocking call with an optional
> timeout wouldn't be difficult, it just can't be the default.
>
> I think if you disallowed nil as a response, then it would be easy to use
> a variety of different blocking calls -- wait forever, wait 30 seconds,
> wait until (f) returns truthy, etc.
>
> -ToBeReplaced
>
>
> On 08/01/2013 03:36 PM, Cedric Greevey wrote:
>
>  On Thu, Aug 1, 2013 at 1:09 PM,  wrote:
>
>> There would be no intent to solve the messenger problem explicitly --
>> those semantics are up to the user.  By default, in the case of server
>> death, the client side will just no longer receive responses on its
>> receive-channel.  In the case of a blocking call, this means that the
>> client side will hang.
>>
>
>  Ugh. At the *very* least it should eventually return with some kind of a
> timeout exception.
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/P95cOfuXBUs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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/groups/opt_out.
>
>
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

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

Re: extend-type on

[Meikel Brandmeyer]

You could spice things a bit up:

(defn extend-to
  [protocol & class-impl-mappings]
  (doseq [[class impl] (partition 2 class-impl-mappings)]
(extend class protocol impl)))

(extend-to PThree
  Long{:hello long-hello}
  Integer {:hello long-hello}
  Number  {:hello number-hello})

Meikel



2013/8/2 Phillip Lord 

> "Meikel Brandmeyer (kotarak)"  writes:
> >> Sure, I understand why it's not working! I just don't know how to fix
> it.
> >>
> >>
> > Plain old functions:
> >
> > (defn number-hello
> >   [n]
> >   (when (= n 10)
> > "hello"))
> >
> > (defn long-hello
> >   [n]
> >   (if (= n 5)
> > "goodbye"
> > (number-hello n)))
> >
> > (extend Number
> >   PThree
> >   {:hello number-hello})
> >
> > (extend Long
> >   PThree
> >   {:hello long-hello})
> >
> > (extend Integer
> >   PThree
> >   {:hello long-hello})
> >
> > HTH.
>
> It does, and appears to be the only way to go.
>
> Phil
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/4y5eJUHL3II/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: Can I refer all but specified symbols with 'ns' macro?

[Laurent PETIT]

2013/8/2 Anthony Grimes :
> Keep in mind that you should almost never do this. It's much better to
> require :as or explicitly refer which things you want from each namespace.
> When you do :refer :all, you pollute your namespace with tons of vars and
> when you use them, nobody has any clue where they're coming from so they
> have to hunt through the codebase, your libraries, etc, to find out where
> the various vars you're using come from. All of that is mitigated by
> referring specific vars or qualifying the namespace with :as. It really
> isn't that many more characters. You can give your namespace a one letter
> prefix and access vars like x/some-var.

True.

Tho note that with an IDE (Counterclockwise for Clojure does that for
instance) with good integration with nrepl, you can hover over the
symbol (provided that you've successfully loaded the namespace in your
repl) to see documentation (including where it comes from), type F3 to
jump to its definition (either in your project files, or in jar
entries).

>
>
> On Thursday, August 1, 2013 1:19:28 AM UTC-7, Yoshinori Kohyama wrote:
>>
>> Hi group.
>>
>> Assumed that I want to refer 'baz, 'qux and etc and don't want to refer
>> 'quux of 'bar namespace within my 'foo namespace.
>>
>> With 'ns' macro, I can require a namespace and refer all public symbols in
>> it.
>>
>>   (ns foo (:require [bar :refer :all]))
>>
>> I can refer only some specific symbols.
>>
>>   (ns foo (:require [bar :refer (baz qux)]))
>>
>> Can I refer all but specific symbols?
>>
>> I'm doing
>>
>>   (ns foo (:require bar))
>>   (refer 'bar :exclude '(quux))
>>
>> or
>>
>>   (ns foo)
>>   (require 'bar)
>>   (refer 'bar :exclude '(quux))
>>
>> for now.
>>
>> Thanks in advance.
>>
>> Y. Kohyama
>>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from 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/groups/opt_out.
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: Can I refer all but specified symbols with 'ns' macro?

[Anthony Grimes]

Keep in mind that you should almost never do this. It's much better to 
require :as or explicitly refer which things you want from each namespace. 
When you do :refer :all, you pollute your namespace with tons of vars and 
when you use them, nobody has any clue where they're coming from so they 
have to hunt through the codebase, your libraries, etc, to find out where 
the various vars you're using come from. All of that is mitigated by 
referring specific vars or qualifying the namespace with :as. It really 
isn't that many more characters. You can give your namespace a one letter 
prefix and access vars like x/some-var.

On Thursday, August 1, 2013 1:19:28 AM UTC-7, Yoshinori Kohyama wrote:
>
> Hi group.
>
> Assumed that I want to refer 'baz, 'qux and etc and don't want to refer 
> 'quux of 'bar namespace within my 'foo namespace.
>
> With 'ns' macro, I can require a namespace and refer all public symbols in 
> it.
>
>   (ns foo (:require [bar :refer :all]))
>
> I can refer only some specific symbols.
>
>   (ns foo (:require [bar :refer (baz qux)]))
>
> Can I refer all but specific symbols?
>
> I'm doing
>
>   (ns foo (:require bar))
>   (refer 'bar :exclude '(quux))
>
> or
>
>   (ns foo)
>   (require 'bar)
>   (refer 'bar :exclude '(quux))
>
> for now.
>
> Thanks in advance.
>
> Y. Kohyama
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

[ANN] Nightcode, an IDE for Clojure and Java

[Zach Oakes]

I’ve been working on a simple IDE for the past few months. It started as an 
attempt to add Leiningen integration to Clooj, but eventually I decided to 
start a new project from scratch. It is very alpha-quality, so please be 
gentle:

http://nightcode.info/

Here’s what it has:

-Written in Clojure (the UI is written with seesaw)

-Built-in copy of Leiningen to build Clojure and pure-Java projects

-Built-in templates for several common types of Clojure and Java projects

-Always-on REPL in the corner to try Clojure commands

-Android integration (includes the lein-droid plugin, LogCat output, etc)

-ClojureScript integration (includes the lein-cljsbuild plugin)

-Cool looking dark theme, because that’s trendy these days

Here’s what it’s missing:

-Fast build times (it launches Leiningen in a separate process, which is 
slw...I plan on fixing this and would love any help)

-Important editing features (code completion, text replace, etc)

-Quick switching between recent files

-Jump to definition, built-in documentation

-Integration between editor and REPL (eval form or entire file)

-Integration with git
-Many other things -- please give me your thoughts!

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

Re: extend-type on

[Phillip Lord]

"Meikel Brandmeyer (kotarak)"  writes:
>> Sure, I understand why it's not working! I just don't know how to fix it. 
>>
>>
> Plain old functions:
>
> (defn number-hello
>   [n]
>   (when (= n 10)
> "hello"))
>
> (defn long-hello
>   [n]
>   (if (= n 5)
> "goodbye"
> (number-hello n)))
>
> (extend Number
>   PThree
>   {:hello number-hello})
>
> (extend Long
>   PThree
>   {:hello long-hello})
>
> (extend Integer
>   PThree
>   {:hello long-hello})
>
> HTH.

It does, and appears to be the only way to go.

Phil

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: extend-type on

[Jim - FooBar();]

On 02/08/13 12:46, Jim - FooBar(); wrote:
or programmatically emit identical extension points for all 
subinterfaces/subclasses


;;adopted from clojure/core/protocols.clj

(def ^:private co-stub
'(run [this text]
  (if (instance? edu.stanford.nlp.pipeline.Annotation text)
  (do (.annotate this text) text)
   (let [ann (edu.stanford.nlp.pipeline.Annotation. ^String text)]
 (.annotate this ann) ann

(defn- emit-IComponent-impls* [syms]
  (mapcat
(fn [s]
  [(symbol (str "edu.stanford.nlp.pipeline." s)) co-stub])
syms))

(defmacro ^:private emit-IComponent-impls [& syms]
  `(extend-protocol IComponent
 ~@(emit-IComponent-impls* syms)))

and finally you call it like this:

(emit-IComponent-impls ;nice trick to avoid enumerating all the 
identical implementations
  POSTaggerAnnotator PTBTokenizerAnnotator WordsToSentencesAnnotator 
TokenizerAnnotator

  CleanXmlAnnotator MorphaAnnotator NERCombinerAnnotator RegexNERAnnotator
  TrueCaseAnnotator ParserAnnotator DeterministicCorefAnnotator)

neat trick imo :)

Jim

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: extend-type on

[Jim - FooBar();]

On 02/08/13 12:24, Phillip Lord wrote:

"Jim - FooBar();"  writes:

your extension point on Number is never fired because 10 is a Long.

Sure, I understand why it's not working! I just don't know how to fix it.


  there is nothing to fix in this particular example...everything works 
as expected.





Generally speaking extending protocols to interfaces is not
suggested...

I'm extending an API which is interface driven -- the OWL API in this
case.
 all well-designed APIs are abstraction driven. I imagine there nothing 
special about OWL in that respect...
take for instance the openNLP API...It has 4 or 5 interfaces that define 
the different components that openNLP supports (Tokenizer, Stemmer, 
NameFinder etc etc).
I can easily extend-type to all these interfaces (that are all on the 
same 'level') which allows me to cover all concrete classes. This is one 
of the cases where it works for me just fine...


However if I try to extend a protocol to java.util.Collection and then 
to clojure.lang.IPersistenVector it won't work...only the extension to 
java.util.Collection fires (because it is above 
clojure.lang.IPersistenVector). That is what I meant...





http://owlapi.sourceforge.net/javadoc/index.html

At the moment I am just playing, but the idea was to extend this API so
that it supports core.match.


I've been bitten a couple of times in particular whenever
I'm extending to 2 different interfaces that *are* related...You can
certainly do it but you have to have sure that your top interface
comes first than the others.

In this case, that wouldn't work; I really need to call a superclass
implementation.

For instance, the class OWLEntity has one method on it that I need to
call. It has 8 direct subintefaces, and quite a lot more below that. I
don't want to have to support the single method multiple times.
I can see from the docs that OWLEntity is an interface and as you say it 
has several subinterfaces. My approach would be to either extend only to 
OWLEntity or all of the subinterfaces. If you try to do both, I suspect 
only the top one will always be fired...If the implementation of the 
method you want  is identical for all, you can just bother with 
OWLEntity or programmatically emit identical extension points for all 
subinterfaces.




I can think of otherways to do this, I guess, but they kind of involve
lots of instance? checks.


apart from sounding like non-idiomatic code, it also sounds like 
problematic code since you're dealing with interfaces that are related...

user=> (instance?  Number 1)
true
user=> (instance?  Long 1)
true
user=> (instance?  Object 1)
true




Phil



Jim

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: extend-type on

[Meikel Brandmeyer (kotarak)]

Hi,

Am Freitag, 2. August 2013 13:24:07 UTC+2 schrieb Phillip Lord:
>
> "Jim - FooBar();" > writes: 
> > your extension point on Number is never fired because 10 is a Long. 
>
> Sure, I understand why it's not working! I just don't know how to fix it. 
>
>
Plain old functions:

(defn number-hello
  [n]
  (when (= n 10)
"hello"))

(defn long-hello
  [n]
  (if (= n 5)
"goodbye"
(number-hello n)))

(extend Number
  PThree
  {:hello number-hello})

(extend Long
  PThree
  {:hello long-hello})

(extend Integer
  PThree
  {:hello long-hello})

HTH.

Kind regards
Meikel

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

Re: extend-type on

[Phillip Lord]

"Jim - FooBar();"  writes:
> your extension point on Number is never fired because 10 is a Long. 

Sure, I understand why it's not working! I just don't know how to fix it.

> Generally speaking extending protocols to interfaces is not
> suggested...

I'm extending an API which is interface driven -- the OWL API in this
case. 

http://owlapi.sourceforge.net/javadoc/index.html

At the moment I am just playing, but the idea was to extend this API so
that it supports core.match.

> I've been bitten a couple of times in particular whenever
> I'm extending to 2 different interfaces that *are* related...You can
> certainly do it but you have to have sure that your top interface
> comes first than the others.

In this case, that wouldn't work; I really need to call a superclass
implementation. 

For instance, the class OWLEntity has one method on it that I need to
call. It has 8 direct subintefaces, and quite a lot more below that. I
don't want to have to support the single method multiple times.

I can think of otherways to do this, I guess, but they kind of involve
lots of instance? checks.

Phil

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: extend-type on

[Jim - FooBar();]

Moreover, if you're going to extend a particular protocol to many types, 
it's better to use 'extend-protocol' which expands to a bunch of 
'extend-type' forms...if you need a point of reference I recently  
finished extending a 'DataSet' protocol to all clojure/java 
data-structures. YOu can find it here : 
https://github.com/jimpil/hotel-nlp/blob/master/src/hotel_nlp/tools/normalito/core.clj


500 lines of pure protocol extension points! It is that long because a 
requirement of mine was not to output the same type as the input.


Jim


On 02/08/13 11:55, Jim - FooBar(); wrote:
your extension point on Number is never fired because 10 is a Long. 
Generally speaking extending protocols to interfaces is not 
suggested...I've been bitten a couple of times in particular whenever 
I'm extending to 2 different interfaces that *are* related...You can 
certainly do it but you have to have sure that your top interface 
comes first than the others.


Your example is actually fine...try "(hello (int 10))" - you should 
see "hello"


Jim


On 02/08/13 11:44, Phillip Lord wrote:

I want to use extend-type to support a protocol both on a class and it's
subclasses. But I don't know how to do a superclass call. So for
instance, with this code

(defprotocol PThree
   (hello [this]))

(extend-type
 Number PThree
 (hello [this]
   (if (= 10 this)
 "hello")))

(extend-type
 Long PThree
 (hello [this]
   (if (= 5 this)
 "goodbye")))

;; this return "goodbye"
(hello 5)
;; this returns nil
(hello 10)


I really want (hello 10) to return "hello". But the extend-type of Long
takes precedence. How can I call the implementation on the superclass
instead?

Phil





--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

Re: extend-type on

[Jim - FooBar();]

your extension point on Number is never fired because 10 is a Long. 
Generally speaking extending protocols to interfaces is not 
suggested...I've been bitten a couple of times in particular whenever 
I'm extending to 2 different interfaces that *are* related...You can 
certainly do it but you have to have sure that your top interface comes 
first than the others.


Your example is actually fine...try "(hello (int 10))" - you should see 
"hello"


Jim


On 02/08/13 11:44, Phillip Lord wrote:

I want to use extend-type to support a protocol both on a class and it's
subclasses. But I don't know how to do a superclass call. So for
instance, with this code

(defprotocol PThree
   (hello [this]))

(extend-type
 Number PThree
 (hello [this]
   (if (= 10 this)
 "hello")))

(extend-type
 Long PThree
 (hello [this]
   (if (= 5 this)
 "goodbye")))

;; this return "goodbye"
(hello 5)
;; this returns nil
(hello 10)


I really want (hello 10) to return "hello". But the extend-type of Long
takes precedence. How can I call the implementation on the superclass
instead?

Phil



--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.

extend-type on

[Phillip Lord]

I want to use extend-type to support a protocol both on a class and it's
subclasses. But I don't know how to do a superclass call. So for
instance, with this code

(defprotocol PThree
  (hello [this]))

(extend-type
Number PThree
(hello [this]
  (if (= 10 this)
"hello")))

(extend-type
Long PThree
(hello [this]
  (if (= 5 this)
"goodbye")))

;; this return "goodbye"
(hello 5)
;; this returns nil
(hello 10)


I really want (hello 10) to return "hello". But the extend-type of Long
takes precedence. How can I call the implementation on the superclass
instead?

Phil

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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/groups/opt_out.