Re: [ANN] 2016 State of Clojure Community Survey

2016-12-13 Thread Terje Norderhaug 
Should've been a separate question for choice of rank order... :-)

On Tue, Dec 13, 2016 at 7:49 AM, Colin Yates  wrote:

> Oh the joys of a lack of a ubiquitous language :-). I was only
> surprised it didn't start at 0 ;-).
>
> On 13 December 2016 at 15:46, Jose Figueroa Martinez 
> wrote:
> > Me too :-|
> >
> >
> > El martes, 13 de diciembre de 2016, 2:44:08 (UTC-6), Patrick Kristiansen
> > escribió:
> >>
> >> On Tuesday, December 13, 2016 at 2:00:10 AM UTC+1, Mike Rodriguez wrote:
> >>>
> >>> Uh oh. I should have asked. I ranked my priorities in the exact
> opposite
> >>> order since I thought 1 was lowest.
> >>
> >>
> >> I did too.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> your
> > first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Best IDE

2013-06-07 Thread Terje Norderhaug 
On Thu, Jun 6, 2013 at 6:02 PM, Lee Spector lspec...@hampshire.edu wrote:


 8) If you want to become a rock star eternal golden coder's hero then
 develop an Emacs-like Clojure coding environment for which the features ARE
 discoverable and for which the learning curve is gentle. This sort of thing
 has been done before! At least FRED (FRED Resembles Emacs Deliberately),
 which was part of the (sadly) long dead Macintosh Common Lisp environment,
 counts in my book. And the MCLIDE project continued this work to some
 extent for a while, for multiple Lisps including Clojure (
 http://mclide.com). All of that was just for Mac, however, and none of it
 appears to be active... but the idea is a superb one: Provide all of the
 power of Emacs but ditch the ancient user interface. E.g., instead of
 hiding buffers invisibly behind each other, just pop up ordinary windows
 that people already know how to use. Use standard menus and dialogs to
 interact with the user for opening files, browsing stack traces, and
 everything else. Set preferences in a standard preferences dialog. Allow
 features to be discovered by browsing menus, and allow key commands to be
 viewed/changed in standard ways. Life would be beautiful if something like
 this arose in the Clojure community.


MCLIDE is alive and well. Although the most recent public build was
released last summer, there are open source on github for those that want
to participate in the development:

   https://github.com/TerjeNorderhaug/mclide

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

2013-05-09 Thread Terje Norderhaug 
I suggest allowing participants from the listed countries, but give
an eventual prize to a charity of choice to avoid a cash payment.


On Thu, May 9, 2013 at 12:59 PM, u1204 d...@axiom-developer.org wrote:

 I believe that cash payments are forbidden by law in the listed
 countries. The contest will make cash payments. I know that
 Lisp In Summer Projects has no problem with people from Italy,
 Brazil, or other listed countries.

 Tim Daly

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

2012-12-02 Thread Terje Norderhaug 
On Thu, Nov 15, 2012 at 5:17 PM, Alan Malloy a...@malloys.org wrote:
 The primary point of let- is that you can insert it into an existing -
 pipeline.

 (- foo
 (stuff)
 (blah)
 (let- foo-with-stuff
   (for [x foo-with-stuff]
 (inc x)))

This use case of the macro now renamed as- in Clojure 1.5 is already
covered by using fn in a pipeline:

(- foo
(stuff)
(blah)
((fn [foo-with-stuff]
   (for [x foo-with-stuff]
 (inc x)

A benefit of using fn here is that it also works with - just the
same. However, there is a place for a construct to simplify multiple
uses of fn in a pipeline like in:

 (- foo
(stuff)
(blah)
((fn [foo]
   (for [x foo]
 (inc x
((fn [foo]
   (for [x foo]
 (dec x)

I propose fn- as name for a construct similar to as- used like this:

(- foo
(stuff)
(blah)
((fn- [foo]
   (for [x foo]
 (inc x))
   (for [x foo]
 (dec x)

The fn- macro defines an anonymous function using the same syntax as
fn, with its forms threaded like in as- where each evaluated form is
bound to a symbol.

In the example above, the result of the first 'for' form is bound to
the 'foo' used by the second 'for' form. That is, within fn- the
items in the list bound to foo is first incremented and the resulting
list bound to foo, then the items in the list bound to foo is
decremented with the resulting list returned (incidentally leaving the
list as before).

Keeping the syntax and semantics of fn- similar to fn provides an
smooth upgrade path from current uses of fn in pipelines.

-- Terje Norderhaug

 On Thursday, November 15, 2012 10:35:59 AM UTC-8, Alex Nixon wrote:

 Hi all,

 I find the proposed function let- in Clojure 1.5 very useful, but a bit
 ugly.  The arguments are backwards when compared to vanilla let, and it
 doesn't support destructuring where it easily could (which I believe would
 be helpful when threading 'state-like' maps, as I find let- very useful
 for).

 I'd like to float an alternative implementation which improves on both
 these issues.  Thoughts?

 (defmacro new-let-
   Establishes bindings as provided for let, evaluates the first form
in the lexical context of that binding, then re-establishes bindings
to that result, repeating for each successive form
   [bindings  forms]
   (assert (vector? bindings) binding must be a vector)
   (assert (= 2 (count bindings)) binding vector must contain exactly two
 forms)
   `(let [~@bindings
  ~@(interleave (repeat (bindings 0)) (drop-last forms))]
  ~(last forms)))

 (new-let- [{:keys [foo bar] :as state} {:foo 1 :bar 2}]
   (assoc state :foo (inc bar))
   (assoc state :bar (inc foo))) ; = {:foo 3, :bar 4}

 --
 Alex Nixon

 Software Engineer | SwiftKey

 al...@swiftkey.net | http://www.swiftkey.net/

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

Re: Proposed change to let- syntax

2012-12-02 Thread Terje Norderhaug 
Here is the short form of the proposal below:

1. Make as- in Clojure 1.5 have a syntax and semantic matching how fn
is used in pipelines.
2. Rename as- to fn- reflecting its similarity to fn.

-- Terje Norderhaug

On Sun, Dec 2, 2012 at 5:30 PM, Terje Norderhaug te...@in-progress.com wrote:
 On Thu, Nov 15, 2012 at 5:17 PM, Alan Malloy a...@malloys.org wrote:
 The primary point of let- is that you can insert it into an existing -
 pipeline.

 (- foo
 (stuff)
 (blah)
 (let- foo-with-stuff
   (for [x foo-with-stuff]
 (inc x)))

 This use case of the macro now renamed as- in Clojure 1.5 is already
 covered by using fn in a pipeline:

 (- foo
 (stuff)
 (blah)
 ((fn [foo-with-stuff]
(for [x foo-with-stuff]
  (inc x)

 A benefit of using fn here is that it also works with - just the
 same. However, there is a place for a construct to simplify multiple
 uses of fn in a pipeline like in:

  (- foo
 (stuff)
 (blah)
 ((fn [foo]
(for [x foo]
  (inc x
 ((fn [foo]
(for [x foo]
  (dec x)

 I propose fn- as name for a construct similar to as- used like this:

 (- foo
 (stuff)
 (blah)
 ((fn- [foo]
(for [x foo]
  (inc x))
(for [x foo]
  (dec x)

 The fn- macro defines an anonymous function using the same syntax as
 fn, with its forms threaded like in as- where each evaluated form is
 bound to a symbol.

 In the example above, the result of the first 'for' form is bound to
 the 'foo' used by the second 'for' form. That is, within fn- the
 items in the list bound to foo is first incremented and the resulting
 list bound to foo, then the items in the list bound to foo is
 decremented with the resulting list returned (incidentally leaving the
 list as before).

 Keeping the syntax and semantics of fn- similar to fn provides an
 smooth upgrade path from current uses of fn in pipelines.

 -- Terje Norderhaug

 On Thursday, November 15, 2012 10:35:59 AM UTC-8, Alex Nixon wrote:

 Hi all,

 I find the proposed function let- in Clojure 1.5 very useful, but a bit
 ugly.  The arguments are backwards when compared to vanilla let, and it
 doesn't support destructuring where it easily could (which I believe would
 be helpful when threading 'state-like' maps, as I find let- very useful
 for).

 I'd like to float an alternative implementation which improves on both
 these issues.  Thoughts?

 (defmacro new-let-
   Establishes bindings as provided for let, evaluates the first form
in the lexical context of that binding, then re-establishes bindings
to that result, repeating for each successive form
   [bindings  forms]
   (assert (vector? bindings) binding must be a vector)
   (assert (= 2 (count bindings)) binding vector must contain exactly two
 forms)
   `(let [~@bindings
  ~@(interleave (repeat (bindings 0)) (drop-last forms))]
  ~(last forms)))

 (new-let- [{:keys [foo bar] :as state} {:foo 1 :bar 2}]
   (assoc state :foo (inc bar))
   (assoc state :bar (inc foo))) ; = {:foo 3, :bar 4}

 --
 Alex Nixon

 Software Engineer | SwiftKey

 al...@swiftkey.net | http://www.swiftkey.net/

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

Re: [ANN] clj-xpath 1.3.3

2012-11-20 Thread Terje Norderhaug 
On Tue, Nov 20, 2012 at 9:07 AM, Phil Hagelberg p...@hagelb.org wrote:
 However, the likelihood that anyone else will come along in the future
 and name another library clj-xpath is basically nil in this case.

For standards/recommendations like xpath it would be preferable to
avoid that the first Clojure implementation coming along gets to
monopolize the name. In fact, I've been thinking for a while about
implementing an xpath library for Clojure, talking a different
approach than Kyle, as I've implemented XPath in the past in Common
Lisp as part of an XSLT processor/compiler used in my commercial
products. So I second the use of a group-id for clojure libraries that
use the name of a standard/recommendation in their name.

-- Terje Norderhaug

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

Re: Clojure on Heroku

2012-07-21 Thread Terje Norderhaug 
On Jul 26, 2011, at 1:50 AM, Tarantoga wrote:
 Does anyone know how to create an autoincrementing ID field for a
 table schema on Heroku?

In the schema for the table, define an id field like this:

 [:id :serial PRIMARY KEY]

 It uses PostgreSQL and a common way for this DB is to create a
 sequence and then take default ID's from this sequence. But I haven't
 found a way to do something like that.
 
 I know that rails migrations do something similar but don't know how.
 Are there any ideas?
 
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clojure@googlegroups.com
 Note that posts from new members are moderated - please be patient with your 
 first post.
 To unsubscribe from this group, send email to
 clojure+unsubscr...@googlegroups.com
 For more options, visit this group at
 http://groups.google.com/group/clojure?hl=en

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

[ANN] MCLIDE 1.0b3 Mac IDE for Clojure 1.2

2010-08-20 Thread Terje Norderhaug 
I just released a new version of MCLIDE, the free open source Macintosh lisp 
IDE:

   http://mclide.in-progress.com

The new version makes it easier than ever to get going with Clojure. MCLIDE is 
like a clojure-in-a-box, with the only missing ingredient being the Clojure 
distribution. After selecting the clojure.jar file in a dialog, MCLIDE 
automatically starts Clojure with swank and opens a listener to evaluate 
Clojure forms.

MCLIDEs built-in programming editor has paren matching, automatic indentation 
and numerous keyboard shortcuts, as well as optional lisp syntax styling and 
symbol completion. The mature IDE provides rich interactive development, 
debugging and introspection tools in the form of dialogs on Mac OS X:

   http://mclide.in-progress.com/tour

MCLIDE can be used on the same computer as Clojure or remotely as development 
environment for installations on any platform available over the net.

Enjoy!

-- Terje Norderhaug
te...@in-progress.com

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

Completions and XREFs [Re: Introduction + question re. diff between 'Programming Clojure']

2010-03-24 Thread Terje Norderhaug 

On Mar 24, 2010, at 3:53 AM, Laurent PETIT wrote:

2010/3/24 Konrad Hinsen konrad.hin...@fastmail.net:

The original version (. object method) still could have an interest
where IDEs could guess the method names to propose based on what they
could infer from the object arg.
With the (.methodName object) version, the IDE usually can make
methode name completions based on everything but the object source
code which has not been yet entered by the user, and this is less than
ideal :-(.

So some IDEs (like ccw) try hard doing completion based on the start
of the method name type by the user (and it is currently slow with ccw
because it searches for matches in all available classes in the
project's classpath), some base their search only on classes that are
imported in the current namespace (which is less than ideal given that
generally the objects are not referred to directly in the ns and thus
do not require an import statement for their class/interface).


Clojure IDEs that do completions (like MCLIDE, SLIME and ccw) could  
benefit from having collections of method names and other Clojure  
properties available for efficient access without loading the  
associated code. Such as if jars included a compilation/database  
built from a static analysis of the Clojure code.


Other information of interest includes cross references like the  
callers of a function (see XREF for Common Lisp). The Swank server  
used by SLIME and MCLIDE already provides an interface to support  
such references and completions in these IDEs.


Some require the user to write an intermediate form of source  
code, e.g.

by prefixing the method name with the class name to narrow the search,
e.g. type String.le to have code completion on String.length, and
when you accept the code completion, it is transformed back into
.length in the editor ...


-- Terje Norderhaug
  te...@in-progress.com




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

To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or 
reply to this email with the words REMOVE ME as the subject.

Re: Why I have chosen not to employ clojure

2010-03-21 Thread Terje Norderhaug 

On Mar 21, 2010, at 3:56 PM, Mark Derricutt wrote:
Thanks for the pointer to MCLIDE!  That looks really nice!  Any  
idea if a 64bit build is in the works?  For some reason I feel  
dirty about having to install Rosetta :)


MCLIDE 2.0 will have that cutting edge you're craving for and  
definitely NOT require Rosetta, but please don't let that hold you  
back from using MCLIDE 1.0. The first version is intended to provide  
fodder for a conversation about what to include in the next  
generation lisp/clojure IDE for Macintosh. I invite you to download  
the upcoming release of MCLIDE for Clojure and join the dialogue  
about where to go from here. Think of Rosetta as just another VM... ;-)


There are good reasons for the initial release to use Rosetta,  
particularly that it allowed MCLIDE to be built rapidly on top of a  
mature, proven lisp IDE. This dramatically cut down the development  
time from conception to usable software, making MCLIDE available now  
instead of at the time of the 2.0 release.


You get the gist: Release early. Release often. And listen to your  
customers.


When MCLIDE for Clojure is out, you will be able to download a  
distribution of MCLIDE and have it work instantly as an IDE for  
Clojure on Mac OSX, and with a little extra effort as a Mac IDE for  
Clojure on any platform.


If you just can't wait any longer, send me an email, and I'll let you  
in on how to make the current version of MCLIDE work with Clojure.


On Mon, Mar 22, 2010 at 11:08 AM, Lee Spector  
lspec...@hampshire.edu wrote:
I'm sure that this can and will be overcome, in part because I  
think that for my main environment (Mac OS X) and for my needs  
(which are more about ease of starting to write and run code than  
about deployment) MCLIDE/Clojure is very close already (three  
cheers for Terje!).


-- Terje Norderhaug
  te...@in-progress.com




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

To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or 
reply to this email with the words REMOVE ME as the subject.

Re: Long post with some questions about getting started...

2010-03-19 Thread Terje Norderhaug 

On Mar 18, 2010, at 2:04 PM, Nick wrote:

I'm having an interesting (to me) question around a using REPL.  Once
it's shut down, where does this code go?  I feel like I'm in the old
TRS-80 volatile coding days where you write some code, and if you shut
down you've lost it all.  Is this the case?  So how do you save your
code in a REPL?  I understand these could be unique per editor so I
understand if you get irate at me for asking such a silly question...


I mostly use the repl for executing tests, preferring to write and  
evaluate Clojure definitions from a lisp editor. For example, in the  
MCLIDE lisp editor, I evaluate lisp code in the editor by placing the  
cursor at the opening or closing parenthesis of an expression then  
hit the Enter key. Alternatively, I use a menu shortcut to (re) 
evaluate all definitions in the file I am editing.


-- Terje Norderhaug
  te...@in-progress.com




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

To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or 
reply to this email with the words REMOVE ME as the subject.

Re: Long post with some questions about getting started...

2010-03-19 Thread Terje Norderhaug 

On Mar 19, 2010, at 4:17 PM, Mike Meyer wrote:

On Fri, 19 Mar 2010 07:21:50 -0700 (PDT)
Sean Devlin francoisdev...@gmail.com wrote:
I'm having an interesting (to me) question around a using REPL.   
Once

it's shut down, where does this code go?  I feel like I'm in the old
TRS-80 volatile coding days where you write some code, and if you  
shut

down you've lost it all.  Is this the case?  So how do you save your
code in a REPL?  I understand these could be unique per editor so I
understand if you get irate at me for asking such a silly  
question...


To answer your question about the REPL, yes everything is lost when
you close it.  However, this isn't the whole story.  Once you  
create a

new project w/ Enclojure, you can send code from a file too the REPL
either from a context menu or keyboard shortcut (Alt+E in windows).
It's standard practice to edit your file, and send the code to the
REPL dynamically.  This gets you out of the 1960s and back to 2010.


Most clojure-aware environments will have similar functionality:
SLIME+SWANK, Eclipse, etc. It's not clear this really gets you out of
the 60s, though - it's been standard practice for (file-based *) LISP
development for as long as I can remember. Nuts, it worked with
Scheme2C and mg on the Amiga in the 80s.

*) InterLISP and some others were more like SmallTalk, or MS BASIC, in
   that you edited code at the REPL and saved the entire
   workspace. That did add power - I've never seen a file-based LISP
   whose error handler would let me fix the code on the fly and
   continue execution.


Possibly I am misunderstanding I've never seen a file-based LISP  
whose error handler would let me fix the code on the fly and continue  
execution but that sounds like common practice in the REPL break  
loop for many lisps.


-- Terje Norderhaug
  te...@in-progress.com




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

To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or 
reply to this email with the words REMOVE ME as the subject.

Re: help with infinite loop: break and examine stack? dynamic tracing? circular lists?

2010-03-17 Thread Terje Norderhaug 

On Mar 17, 2010, at 8:14 AM, Lee Spector wrote:
The root problem is that I think I have an infinite loop somewhere  
in my code and I'm having a hard time tracking it down. [...] In  
Common Lisp I would wait until I think I'm in trouble, break  
execution with a keyboard interrupt, look at the function call  
stack (and local vars, if I'm in a nice CL environment), and  
probably figure it out pretty quickly.[...] Is there is a way to  
break and look around under slime? [...]


I've also been doing some runs under MCLIDE, with help from Terje  
Norderhaug, and there I can indeed issue a break from a menu and  
get a backtrace of sorts... but so far I have not been able to get  
a backtrace that shows me what I need -- that is, I don't see any  
of my own functions, presumably because the break changed the  
context... I'm not sure what's going on there.


MCLIDE gets the same backtrace items from swank-clojure as does emacs  
SLIME. I believe the issue is that the JVM only provides limited  
stacktrace information (at least compared to what Common Lisp  
developers are used to).


A good backtrace is essential for efficient debugging. Are there any  
ways to improve the backtrace provided by swank-clojure?


An alternative: Is there a way to watch my running Clojure program  
without breaking it, that is to observe the recent call history (of  
my own definitions, either all of them or specifically marked ones)  
from outside the process?


You could use a profiler to see which of your Clojure functions  
monopolize the execution.


I can think of some clumsy ways to roll my own version of this,  
e.g. using trace and sending the trace output to a file, but I  
don't think this will be practical because I generally only get  
these errors after long stretches of intensive computation that  
will involve many many calls to the potentially problematic  
functions. So I think there'll be too much trace output to save on  
disk, and the slowdown from tracing all of the calls may prevent me  
from ever reaching a problematic state (although I haven't tried  
this to be sure of the timing).


Consider waiting until you are in the situation then use trace on  
candidate culprits.


And in spite of the problems listed above I'm having a great time  
in the Clojureverse!



-- Terje Norderhaug
  te...@in-progress.com




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

Re: clojure slides

2010-03-08 Thread Terje Norderhaug 

On Mar 6, 2010, at 5:27 PM, Sophie wrote:

Re: Emacs + Slime + paredit. I did not see Clojure listed as supported
for Slime and paredit. Do you know if:

- Can you do all Slime stuff in Clojure? evaluate, macro-expand,  
docs, etc?


You can do much of the SLIME stuff including the items listed,  
although the Clojure Swank server used with MCLIDE and emacs SLIME  
does not yet support *all* features implemented in the Common Lisp  
version. Inspection is still incomplete, and it lacks xref  
functionality such as listing the callers of a function.


-- Terje Norderhaug
  te...@in-progress.com




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

Meta for method definitions

2010-03-07 Thread Terje Norderhaug 
What is a good way to get the :file and :line meta information for a  
method?


Getting this meta information for a multi is straight forward:

(meta #'clojure.core/print-method) =
{:ns #Namespace clojure.core, :name print-method, :file clojure/ 
core.clj, :line 2314, :tag clojure.lang.MultiFn}


But what about getting this meta information for a method? Such as  
the result from a call to get-method:


(get-method clojure.core/print-method 1)

Calling meta on the result returns nil, even if this is true:

(instance? clojure.lang.IMeta (get-method clojure.core/print-method 1))

-- Terje Norderhaug
  te...@in-progress.com




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

Re: newbie code (genetic programming) and questions (dev environments)

2010-03-01 Thread Terje Norderhaug 

On Feb 28, 2010, at 11:38 AM, Lee Spector wrote:
On the development environment front: Is anyone contemplating  
creating a Mac OS X Clojure in a Box? I would be an enthusiastic  
user. If it could have roughly the feature set of the old Macintosh  
Common Lisp IDE then I would be ecstatic.


MCLIDE is on way to provide essentially a Mac OS X Clojure in a Box:

   http://mclide.in-progress.com

MCLIDE does indeed have roughly the feature set of the old Macintosh  
Common Lisp IDE - although modernized. This should come as no  
surprise: MCLIDE is in fact based on the MCL IDE (which Peter Norvig  
a few years ago named in Dr. Dobbs Journal as his favorite IDE on  
the Macintosh platform for any language).


MCLIDE is a free open source Mac IDE for lisp on any platform. It  
implements the swank protocol of emacs SLIME and can potentially be  
used with the same lisps. The essential functionality for Clojure is  
is in place, with the rest to be completed over the coming weeks.  
Follow the progress of MCLIDE at:


   http://twitter.com/MCLIDE

Despite a fair amount of tinkering I don't currently have a  
functional SLIME setup, and despite the nice screencasts for  
Eclipse/Counterclockwise (and very nice features it seems to have  
-- e.g. the namespace browser and integrated documentation... is  
there any environment that has a debugging environment  
approximating a Lisp break loop?) that's not really working for me  
yet either. (A few specifics: In emacs, using a variety of  
configuration instructions and hints from the web, I get syntax  
coloring and indentation but not a functional inferior Lisp mode.  
Eclipse is a bit confusing to me overall, I can't seem to figure  
out how to get Clojure indenting, and it seems to be re-evaluating  
my buffers without me asking it to :-(. And saving an awful lot of  
files to its workspace directory.) I'm not only interested in  
getting one of these environments working on my own machine --  
although that would be nice -- but also in having a simple,  
repeatable sequence of instructions for getting the environment  
running on fresh machines. This is because I teach and I may want  
to use this on classroom machines, student machines, etc., with  
students who have various levels of expertise. Our students use all  
sorts of platforms but our teaching environment is Mac OS X (with a  
linux cluster for compute-intensive stuff).


-- Terje Norderhaug
  te...@in-progress.com




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

Re: Prefixed or suffixed symbols?

2010-02-26 Thread Terje Norderhaug 

On Feb 25, 2010, at 7:59 PM, Sean Devlin wrote:

As to you question about editors, I know that it's possible to adapt
emacs clojure-mode the change colors based on a regex.  That's how it
knows to color something pink for a fn in clojure.core, and green
for a fn in the standard library (e.g. clojure.walk).  You'll have to
make your own customizations, of course.


Syntax styling is better based on the meta-information of symbols  
rather than on whether the name of a symbols fits a pattern. Hence it  
would be a mistake to institute syntax conventions for symbols and  
clutter the code just to facilitate styling in editors.


-- Terje Norderhaug 


On Feb 25, 10:50 pm, joshua-choi rbysam...@gmail.com wrote:

Ah, yes, it is a. (The only thing that I anticipate a computer would
use this for is different syntax highlighting. Actually, can any
Clojure editors change symbols’ colors based on if they match a
pattern like *a*?)

Because Daniel Warner and Jarkko Oranen both said they think
underscores are undesirable, I suspect that a lot of other Clojure
users feel the same too. Right now, I’m thus leaning toward using -
vector-. I’ve just tried replacing all rule symbols in one of my  
files

with -blah-, and it actually looks a little pretty. If I don’t hear
any other good suggestions, I think I’ll use circumfix hyphens, then.

On Feb 25, 8:31 pm, Sean Devlin francoisdev...@gmail.com wrote:




Hmmm... maybe I misunderstood your point.  Is the intent of your
naming conventions:


a.  Something that is human readable but does not affect the  
execution
of code?  Examples include placing I in front of interface names,  
and

A in front of abstract class names.


b.  Something that other code will use to infer behavior?   
Examples of

this include JUnit 3.8  the get/set Java Bean convention.


If it's a, I made a mistake  my comments don't apply (as a  
matter of
taste I like suffixes).  If it's the behavior version, I think  
that a

special macro is in order (e.g. deftest)



Sean



On Feb 25, 10:22 pm, joshua-choi rbysam...@gmail.com wrote:



Could you explain more what you mean? For instance, how are macros
related to these questions? This just has to do with informal  
naming
conventions, in the same matter as *e or *print-dup*. Are you  
talking

about that it’s possible for naming conventions to interfere with
macros that interpret symbols abnormally if they’re named a certain
way?


Now, I’ve considered just not using any characters to set apart  
rules

completely, but that’ll bring me back to my original problems. The
only disadvantage I can think of to using a convention is that it
might make code that use rules more noisy...but I think that’s
preferable to having to recall what a rule is called if it  
conflicts

with another symbol—which is really common with my rules. What
notation do you all think is the least ugly?



On Feb 25, 7:32 pm, Sean Devlin francoisdev...@gmail.com wrote:


I think using a naming convention isn't a good idea, especially  
when
you have a rich macro system like Clojure.  I'm actually going  
to be
talking about using a reference to handle things like this in  
my next
episode.  For now, you can take a look at my definference macro  
here:


http://github.com/francoisdevlin/devlinsf-clojure-utils/blob/ 
master/s...



Hope this helps,
Sean



On Feb 25, 8:59 pm, joshua-choi rbysam...@gmail.com wrote:


Yeah, I don’t really like the underscores either. But I have  
to work
with the set of currently allowed non-alphanumeric symbol  
characters

(*, +, !, -, _, and ?, according to clojure.org/reader).



There’s actually two different questions here—I’d love for other
people to bring in their input.



I need to set apart “rules”, a certain type of object, from other
kinds of Clojure objects. (Why do you even need to do this?  
people

ask. Because I really want to graphically set them apart in the
programmers mind. And also, rules often shared names with  
objects that
they were representing: it was difficult to remember string- 
char-r vs.
string-char in functions, for instance. It was always a big  
pain. I

think it will be worth it.)



Question 1: Of the allowed characters, which would be best to
distinguish rule symbols from other symbols?


* can be confused with the REPL vars (*1, *e, etc.) and re- 
bindable

vars.
+ may be a better choice, though in the other Lisps it already
indicates constants.
I don’t think ! and ? are good at all, because they really  
stand out

to me to mean destruction and querying respectively.
- is apparently used only once in the standard libraries: in  
defn-.

Maybe it would be a good choice.
_ is ugly, but it’s not used at all, so that’s good. Well,  
except when

used on its own: “_”, for useless bindings.



I’m leaning toward +, -, or _.



Question 2: Prefix, suffix, or circumfix?



+vector, vector+, or +vector+? -vector, vector-, -vector-? Or
whatever. Don’t forget, I’m deciding this for my parser rules  
library.
“vector

Swank Clojure [Re: clojure-dev: #55 ...]

2010-02-14 Thread Terje Norderhaug 

On Feb 13, 2010, at 3:22 PM, Phil Hagelberg wrote:

I should mention that I could use some help co-maintaining
swank-clojure. I don't feel like I have a great grasp on the codebase
right now and have just been keeping it on autopilot after figuring
out packaging issues, but having someone who's familiar with how it
works from CL would be very helpful. Even without CL experience, just
gathering up the various patches into one branch and seeing what works
and what doesn't would be very helpful too. Otherwise I'll get to it
when I have time, but it might not be very prompt.


I am gearing up for considerable involvement in improving swank- 
clojure. I am very familiar with CL swank, having implemented the  
MCLIDE swank client - a Macintosh IDE for Lisp implementations on any  
platform:


   http://mclide.in-progress.com/

I am routinely using swank on various lisp implementations, so I am  
in a good position to help making swank-clojure consistent with the  
normative CL swank server. I'd prefer to work with somebody familiar  
with swank-clojure that could review my contributions and integrate  
them in the codebase.


-- Terje Norderhaug
te...@in-progress.com




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

Swank Clojure [Re: clojure-dev: #55]

2010-02-14 Thread Terje Norderhaug 

On Feb 13, 2010, at 5:19 PM, wilig wrote:

I'm willing to give maintenance of swank-clojure a shot.  With one
huge caveat: I'm very new to both clojure and CL, so patience will
have to be practiced as I slowly get up to speed on a new code base in
a new language.  Unless anyone with more experience wants to jump in,
I will begin applying patches, and working on open issues.


Your participation is appreciated!

Please consider joining the swank-clojure mailing list:

  http://groups.google.com/group/swank-clojure

-- Terje Norderhaug
  te...@in-progress.com




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

Re: ClojureCLR under slime / emacs?

2010-02-14 Thread Terje Norderhaug 

On Feb 14, 2010, at 7:43 AM, Shawn Hoover wrote:

On Sat, Feb 13, 2010 at 11:43 PM, Mike K mbk.li...@gmail.com wrote:
Does anyone have ClojureCLR running under emacs via slime?

Failing that, can anyone give me some pointers as to how I might
hacking swank-clojure.el (or whatever) to get this to work?

  Mike

Hi Mike,

I've not heard of anyone doing this. The changes to swank- 
clojure.el would involve changing how it sets up the Clojure  
process. Instead of calling Java with a classpath, it needs to call  
ClojureCLR's executable. The real work would be in the swank- 
clojure clj sources. Every use of a Java standard library class  
would have to be replaced with an appropriate CLR base class  
library class.


Perhaps this could be implemented like CL Swank http://github.com/ 
technomancy/slime, with a portable core and platform specific  
backend modules.


-- Terje Norderhaug
  te...@in-progress.com




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