Clojure Plugin for Netbeans - Pre Alpha on Google Code

2008-12-24 Thread Ffailla

The Clojure Plugin for Netbeans NBM is now available on Google Code.
It can be downloaded at:

http://enclojure-nb-clojure-plugin.googlecode.com/files/org-enclojure-ide-nb-editor.nbm

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Clojure Plugin for Netbeans Pre-Alpha Release-20090130

2009-01-30 Thread Ffailla

A new Clojure Plugin for Netbeans is available at
http://code.google.com/p/enclojure-nb-clojure-plugin/.  Some issues
addressed are:

- Enabled Windows support (only Windows XP has been tested)
- Project Support
   * Enabled Clojure Project Run/Debug functionality
   * Clojure Project Debugging support
- REPL Enhancements
   * REPLs can now be created per project
   * REPL std out and std err has been separated into tabs
- Code Completion Enhancements
   * invoke completion --> ctrl+space (also returns results from
hippie completion)
   * search through clojure namespaces/ java Classes --> search-string
+dot
   * get members for a java class --> Class + "/"
   * get clojure functions for a namespace-->  namespace + "/"
   * get clojure.core functions --> ctrl+space or search-string + ctrl
+ space
- Editor Enhancements
   * Lexer bug fixes related to string encoding (regular expression
support will be available in next release)
   * Editor Context Menu displays Clojure Actions
  = Re-Indent (format) code
  = Evaluate Current Expression
  = Load File into REPL
  = Toggle Comments
  = Select Top Clojure Form
  = Select Enclosing Clojure Form
  = Navigate to Start of Clojure Form
  = Navigate to End of Clojure Form
  = Change the REPL namespace to be the namespace defined in the
file

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Enclojure Plugin for Netbeans Release

2009-05-26 Thread Ffailla

This release has the minor changes listed below.

Clojure Plugin for Netbeans
* Using Clojure 1.0.0
* Removed com.infolace.format dependency

Enclojure Library
* org.enclojure.common.jar dependency removed from org.enclojure.repl

The plugin can be downloaded here:  
http://code.google.com/p/enclojure-nb-clojure-plugin/downloads/list
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to 
clojure+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---



Difference between JVM and CLR when destructuring a lazy sequence

2012-11-15 Thread ffailla
I believe I have discovered differing behavior between the JVM and CLR 
implementations when running the following statement:

user> (let [foo (repeatedly (fn [] (let [r (rand)]
(println "in-repeat: " r)
r)))
 [f & rst] foo]
 (println "return: " f))

When run on the JVM with clojure 1.4.0, I get the following output:

in-repeat:  0.6929552277817549
in-repeat:  0.7005322422752974
return:  0.6929552277817549
nil
user> 

When run on the CLR with clojure-clr 1.4.0, the random number will be 
printed from "in-repeat" infinitely, never to return.

Is this difference between the JVM and CLR implementations when 
destructuring a lazy sequence known?  

Also, why was the random number printed twice on the JVM side.  I haven't 
looked an the implementation, but I would guess this would be due to 
chunking the sequence. Thanks.

-Frank Failla 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from 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: Difference between JVM and CLR when destructuring a lazy sequence

2012-11-16 Thread ffailla
Thank you David for looking into this so quickly.  For now I am working 
around this by not destructuring, but I look forward to the patch.  Thanks.

-Frank

On Thursday, November 15, 2012 7:41:39 PM UTC-5, dmiller wrote:
>
> The difference is that the JVM version is correct and the CLR 
> implementation has a bug.
>
> I'll fix it in the current branch and try to get a patched 1.4 out as soon 
> as I can.
>
> -- Above is all you really need to know, but I find myself forced to 
> continue. :) --
>
> This bug has sitting there from the first commit in the public repo. (That 
> would be early 2009.)  The line of code in question is testing for the 
> IList interface.  The line has a comment that the JVM implementation 
> changed from IList to RandomAccess, which has no equivalent in the CLR.  I 
> didn't know why the change was made, so I left it alone.  (The history is 
> lost, but I can place the JVM version change between Nov 08 and Feb 09.) 
> Four years later, I've just discovered the reason.  The bug only surfaces 
> in certain circumstances on infinite (lazy) sequences -- and specifically 
> it is triggered by destructuring.  LazySeq itself is not the problem -- 
> that's used everywhere.
>
> -David
>
>
>
> On Thursday, November 15, 2012 9:23:05 AM UTC-6, ffailla wrote:
>>
>> I believe I have discovered differing behavior between the JVM and CLR 
>> implementations when running the following statement:
>>
>> user> (let [foo (repeatedly (fn [] (let [r (rand)]
>> (println "in-repeat: " r)
>> r)))
>>  [f & rst] foo]
>>  (println "return: " f))
>>
>> When run on the JVM with clojure 1.4.0, I get the following output:
>>
>> in-repeat:  0.6929552277817549
>> in-repeat:  0.7005322422752974
>> return:  0.6929552277817549
>> nil
>> user> 
>>
>> When run on the CLR with clojure-clr 1.4.0, the random number will be 
>> printed from "in-repeat" infinitely, never to return.
>>
>> Is this difference between the JVM and CLR implementations when 
>> destructuring a lazy sequence known?  
>>
>> Also, why was the random number printed twice on the JVM side.  I haven't 
>> looked an the implementation, but I would guess this would be due to 
>> chunking the sequence. Thanks.
>>
>> -Frank Failla 
>>
>

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

Clojure CLR and System.Double Behavior

2012-11-29 Thread ffailla
I have discovered some odd behavior when type-hinting fns with 
^System.Double:

user=> (defn bar [^System.Double d] d)
#'user/bar
user=> (bar 1.2)
2.35293190771409E-316
user=> (bar 1)
2.35069794048985E-316

The same behavior occurs when extending double via extend-protocol or 
extend-type:

user=> (defprotocol FooProto (foo [_]))
user=> (extend-protocol FooProto System.Double (foo [d] d))
nil
user=> (foo 1.2)
2.25126584588049E-316

Any ideas?  Thanks.

-Frank Failla

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

clojure.contrib.except's future?

2011-10-13 Thread ffailla
Does anyone now if clojure.contrib.except being ported to the new
contrib?  Thanks.

Frank Failla

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

2011-10-28 Thread ffailla
Put me down for:

ClojureScript
core.logic

Thanks!

Frank Failla

On Oct 25, 12:11 pm, Fogus  wrote:
> All,
>
> We talked about the possibility of getting some ideas about
> extracurricular activities during the Conj days (and possibly training
> days).  I've created a spreadsheet at the link below to collect
> ideas.  It is not my intention to be the organizer of these
> activities.  Instead, if you have an idea then please be prepared to
> own it.  The matter of space for these activities would need to be
> worked out by Conj planners or activity organizers, but having a list
> would help that process.
>
> https://docs.google.com/spreadsheet/ccc?key=0Alim_jfrt24MdDFqZVZsNW0t...
>
> I've entered an example, feel free to add your own ideas. :-)
>
> This should be epic.

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