Re: scrolling content of ac-nrepl-popup-doc

[Mikey Griffiths]

Hi Nehal,

You can use "scroll-other-window" and "scroll-other-window-up", which are 
bound to "C-M-v" and "C-M-S-v" respectively. These will scroll the next 
window (i.e. the window that "C-x o" would switch to) up or down by a page. 
Check out the help page for "scroll-other-window" for more information, 
either by doing:
"C-h f scroll-other-window" (describe-function scroll-other-window)
"C-h k C-M-v" (describe-key C-M-v)

If you want to bind the command to a specific key combination, you can add 
the following to your .emacs:

(define-key cider-mode-map (kbd "C-c C-d") 'ac-nrepl-popup-doc)
 
Michael

On Tuesday, 1 April 2014 02:04:00 UTC+1, Nehal Patel wrote:

> Hi -- 
> I'm trying out  Emacs Live.  When I "M-x ac-nrepl-popup-doc" how do I 
> scroll the displayed text (The popup disappears immediately for the few 
> keys that I have tried)
>
> Should popup-doc also be bound to a keyboard shortcut in Emacs Live (as 
> opposed to just being triggered by autocomplete)? (Use case: it helps when 
> reading/stepping through other people's example code) 
>
> Thanks!, nehal 
>

-- 
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: Function from a symbolic expression

[Jony Hudson]

Thanks all :)

@A. Webb: I knew it must be something dopey, thanks for the advice!

@Lee That is indeed exactly what I'm trying to do, and that method is much 
more elegant and straightforward. In fact, precisely what I'm trying to do 
is write some notes on symbolic regression for some students, which has 
come out looking quite a lot like an inferior version of the code you 
linked! Reminds me of the saying "a week in the lab saves an hour in the 
library". Although, truthfully, I think the main benefit in writing the 
notes is to make sure _I_ understand it, not the students :-)


Jony

-- 
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: using contrib functions

[Herwig Hochleitner]

2014-03-29 3:40 GMT+01:00 Christopher Howard :
>
> Is that "webnf" package the thing I am supposed to put in my
> "dependencies" list? Version 0.0.1 doesn't sound right. Or am I
> supposed to download something myself and throw it in my lib
> directory?
>

For clarification: webnf.deps packages are my effort to provide up to date
dependency sets for quickly starting a new project. webnf.deps/contrib
has nothing to do with the old contrib package. It's  is named so,
because it includes all of new clojure contrib plus some commonly used
dependencies.

kind regards

-- 
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: java interop help for beginner calling java class

[bww00amd...@yahoo.com]

ANother step further 
Thanks for the help..
I set up the diretory struc and can import the class.
Now to get the call working.

On Friday, March 28, 2014 10:12:08 AM UTC-5, bww00...@yahoo.com wrote:
>
> I have read so much i cant see the tree for the forest.
> and need some help calling the  ocfLZW class below from clojure.
>
> THANKS for the help
>
> using eclipse and counterclockwise
>
> In clojure 
>  have the data to decompress read into an array.
>  have an array allocated to hold the decompresed data
>
>
> The java class ocfLZW is accessible
>
> I have a java program exert below that calls the ocfLZW class and verified 
> that it works.
>
>
> FileInputStream fis = new FileInputStream(input);
> 
> byte[] sInefficient= new byte[(int)input.length()] ;
> fis.read(sInefficient);
>
> OcfLZW oi = new OcfLZW();
>
> byte[] out = null;
>
>  out = new byte[160];
>
> int len = oi.expand(sInefficient, out);
> System.out.println(new String (out));
> System.out.println("out size = "+len);
>
>
> ocfLZW java class that does LZW decompress 
>
> /* */ public class OcfLZW
> /* */ {
> /* */   static final int INIT_BITS = 9;
> /*   6 */   final int MAX_BITS = 13;
> /*   7 */   final int TABLE_SIZE = 9029;
> /*   8 */   final int HASH_SHIFT = 5;
> /*   9 */   final int CLEAR_TABLE = 256;
> /*  10 */   final int TERMINATOR = 257;
> /* */   static final int FIRST_CODE = 258;
> /* */   static final int CHECK_TIME = 100;
> /*  13 */   final int STACK_SIZE = 4000;
> /*  14 */   boolean EOF = false;
> /* */   static int myIndex;
> /* */   static int offset;
> /* */   static int input_bit_buffer;
> /* */   static int output_bit_buffer;
> /* */   static int string_code;
> /* */   static int bytes_out_this_time;
> /*  22 */   static int next_code = 258;
> /* */   static int max_code;
> /*  24 */   static int checkpoint = 100;
> /*  25 */   static int tot_bytesin = 0;
> /* */   static int gbl_ulong;
> /*  28 */   static int[] code_value = null;
> /*  29 */   static int[] prefix_code = null;
> /*  31 */   int input_bit_count = 0;
> /*  32 */   int output_bit_count = 0;
> /*  33 */   int num_bits = 9;
> /*  34 */   int clear_bytesin = 0;
> /*  35 */   int clear_bytesout = 0;
> /*  36 */   int tot_bytesout = 0;
> /* */   int ratio_new;
> /*  38 */   int ratio_old = 100;
> /*  40 */   static boolean compress_flag = false;
> /*  41 */   static int initialized = 0;
> /*  43 */   static byte[] in_buffpoint = null;
> /*  44 */   static byte[] out_buffpoint = null;
> /*  45 */   int in_buff_n = 0;
> /*  45 */   int out_buff_n = 0;
> /*  45 */   int in_buffend = 0;
> /*  45 */   int out_buffend = 0;
> /*  47 */   byte[] append_character = null;
> /*  48 */   byte gbl_ptr_idx = 0;
> /*  50 */   byte[] decode_stack = null;
> /*  51 */   int ds_i = 0;
> /* */   
> /* */   public int expand(byte[] paramArrayOfByte1, byte[] 
> paramArrayOfByte2)
> /* */   {
> /*  56 */ this.ds_i = 0;
> /* */ 
> /*  58 */ compress_flag = false;
> /* */ 
> /* */ 
> /*  61 */ max_code = (1 << this.num_bits) - 1;
> /*  62 */ prefix_code = new int[9029];
> /*  63 */ this.append_character = new byte[9029];
> /* */ 
> /* */ 
> /* */ 
> /*  67 */ this.decode_stack = new byte[4000];
> /*  69 */ if ((prefix_code == null) || (this.append_character == null) 
> || (this.decode_stack == null) || ((compress_flag) && (code_value == 
> null))) {
> /*  73 */   return 0;
> /* */ }
> /*  75 */ out_buffpoint = paramArrayOfByte2;
> /*  76 */ this.out_buff_n = 0;
> /*  77 */ in_buffpoint = paramArrayOfByte1;
> /*  78 */ this.in_buff_n = 0;
> /* */ 
> /* */ 
> /* */ 
> /*  82 */ int[] arrayOfInt1 = new int[1];
> /*  83 */ int i = 0;
> /*  84 */ int j = 0;
> /* */ 
> /*  86 */ int[] arrayOfInt2 = new int[1];
> /*  87 */ int m = 0;
> /*  88 */ arrayOfInt1[0] = 0;
> /* */ 
> /*  90 */ arrayOfInt2[0] = 0;
> /* */ 
> /*  92 */ int k = 1;
> /* */ 
> /* */ 
> /* */ 
> /* */ 
> /* */ 
> /*  98 */ inputCode(arrayOfInt1);
> /*  99 */ while ((!this.EOF) && (arrayOfInt1[0] != 257))
> /* */ {
> /* 100 */   if (k > 0)
> /* */   {
> /* 101 */ i = arrayOfInt1[0];
> /* 102 */ j = i;
> /* 104 */ if (arrayOfInt1[0] <= 255)
> /* */ {
> /* 105 */   k = 0;
> /* 106 */   if (putByte(i) == 0) {
> /* 107 */ return 0;
> /* */   }
> /* 108 */   m++;
> /* 109 */   inputCode(arrayOfInt1);
> /* 110 */   continue;
> /* */ }
> /* */   }
> /* 114 */   if (arrayOfInt1[0] == 256)
> /* */   {
> /* 115 */ k = 1;
> /* 116 */ this.num_bits = 9;
> /* 117 */ next_code = 258;

Re: Strange behaviour for proxy when two abstract classes are passed in

[A. Webb]

On Monday, March 31, 2014 4:34:17 PM UTC-5, zcaudate wrote:
>
> I know this is a silly example but I am curious to know what is happening 
> with the proxy method.
>
> I have set up two calls to proxy:
>
> 1.
>   (def cp
> (proxy [java.util.AbstractMap clojure.asm.ClassVisitor] []))
>
> 2.
>   (def cp
> (proxy [clojure.asm.ClassVisitor java.util.AbstractMap] []))
>
>
> The first call is fine and it return cp.  The second call gives me an 
> exception.
>

You cross-posted to Stack Overflow Stack 
Overflow. 
Copy of my answer there:

Neither will work in Clojure 1.6.0. In 1.5, `clojure.asm.ClassVisitor` was 
an interface instead of an abstract class. Proxy expects at most one class 
followed by optional interfaces. As `java.util.AbstractMap` is an abstract 
class, it cannot appear second in the list of class-and-interfaces. 

-- 
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: REPL: viewing data structures containing infinite lists

[Andreas Liljeqvist]

Is there any good reason for not providing a default value for
*print-length*?
I think that if you *really* want to print a list containing 100K items,
you would have to set *print-length*.

Basically it seems less harmful to set it to a nice value by default(42?)
than possible locking up the REPL.


On Tue, Apr 1, 2014 at 2:49 AM, Gary Trakhman wrote:

> http://clojuredocs.org/clojure_core/clojure.core/*print-length*
>
>
> On Mon, Mar 31, 2014 at 8:49 PM, Christopher Howard 
> wrote:
>
>> Is there some kind of "safe" function for printing representations of
>> lazy, infinite data structures? I'm finding I like using them inside
>> other data structures here and there. However, when I go to play
>> around with things in the REPL, sooner or later my workflow is
>> interrupted by 3 million characters streaming across the console.
>>
>> I don't imagine there would be any way for the REPL to detect that a
>> lazy sequence was infinite. However, if it would simply refuse to
>> evaluate lazy sequence (say, represent them by some special identifier)
>> that
>> would be good enough for me.
>>
>> --
>> 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: REPL: viewing data structures containing infinite lists

[Phillip Lord]

I'd be interested in knowing this as well. Lots of tutorials have 
things like

(take 10 (range))

followed by statements that range on it's own will break your REPL.

Seems to me a common gotcha for Clojure.

Phil

Andreas Liljeqvist  writes:

> Is there any good reason for not providing a default value for
> *print-length*?
> I think that if you *really* want to print a list containing 100K items,
> you would have to set *print-length*.
>
> Basically it seems less harmful to set it to a nice value by default(42?)
> than possible locking up the REPL.
>
>
> On Tue, Apr 1, 2014 at 2:49 AM, Gary Trakhman wrote:
>
>> http://clojuredocs.org/clojure_core/clojure.core/*print-length*
>>
>>
>> On Mon, Mar 31, 2014 at 8:49 PM, Christopher Howard 
>> wrote:
>>
>>> Is there some kind of "safe" function for printing representations of
>>> lazy, infinite data structures? I'm finding I like using them inside
>>> other data structures here and there. However, when I go to play
>>> around with things in the REPL, sooner or later my workflow is
>>> interrupted by 3 million characters streaming across the console.
>>>
>>> I don't imagine there would be any way for the REPL to detect that a
>>> lazy sequence was infinite. However, if it would simply refuse to
>>> evaluate lazy sequence (say, represent them by some special identifier)
>>> that
>>> would be good enough for me.
>>>
>>> --
>>> 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.
>>

-- 
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/d/optout.

Re: REPL: viewing data structures containing infinite lists

[Andy Fingerhut]

One argument for default value of *print-length* being nil: Plenty of
people print Clojure data structures to files and later read them back in.
The data would be corrupted if *print-length* was a too-small numeric value
for your particular data.  It might not be obvious until much later that
you have lost data.

Andy


On Tue, Apr 1, 2014 at 9:00 AM, Andreas Liljeqvist  wrote:

> Is there any good reason for not providing a default value for
> *print-length*?
> I think that if you *really* want to print a list containing 100K items,
> you would have to set *print-length*.
>
> Basically it seems less harmful to set it to a nice value by default(42?)
> than possible locking up the REPL.
>
>
> On Tue, Apr 1, 2014 at 2:49 AM, Gary Trakhman wrote:
>
>> http://clojuredocs.org/clojure_core/clojure.core/*print-length*
>>
>>
>> On Mon, Mar 31, 2014 at 8:49 PM, Christopher Howard > > wrote:
>>
>>> Is there some kind of "safe" function for printing representations of
>>> lazy, infinite data structures? I'm finding I like using them inside
>>> other data structures here and there. However, when I go to play
>>> around with things in the REPL, sooner or later my workflow is
>>> interrupted by 3 million characters streaming across the console.
>>>
>>> I don't imagine there would be any way for the REPL to detect that a
>>> lazy sequence was infinite. However, if it would simply refuse to
>>> evaluate lazy sequence (say, represent them by some special identifier)
>>> that
>>> would be good enough for me.
>>>
>>> --
>>> 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.
>

-- 
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: REPL: viewing data structures containing infinite lists

[A. Webb]

On Tuesday, April 1, 2014 11:00:37 AM UTC-5, Andreas Liljeqvist wrote:
>
> Is there any good reason for not providing a default value for 
> *print-length*?
> I think that if you *really* want to print a list containing 100K items, 
> you would have to set *print-length*.
>
> Basically it seems less harmful to set it to a nice value by default(42?) 
> than possible locking up the REPL.
>

For the lein REPL, merge this into your ~/.lein/profiles.clj 

{:user {:repl-options {:init (set! *print-length* 42)}}} 

-- 
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: REPL: viewing data structures containing infinite lists

[Gary Trakhman]

Yea, print is generalized to a java PrintWriter class, I think, the
requirements of repl usage are not the only ones.

On Tuesday, April 1, 2014, A. Webb  wrote:

>
>
> On Tuesday, April 1, 2014 11:00:37 AM UTC-5, Andreas Liljeqvist wrote:
>>
>> Is there any good reason for not providing a default value for
>> *print-length*?
>> I think that if you *really* want to print a list containing 100K items,
>> you would have to set *print-length*.
>>
>> Basically it seems less harmful to set it to a nice value by default(42?)
>> than possible locking up the REPL.
>>
>
> For the lein REPL, merge this into your ~/.lein/profiles.clj
>
> {:user {:repl-options {:init (set! *print-length* 42)}}}
>
>  --
> 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: REPL: viewing data structures containing infinite lists

[Phillip Lord]

Of course, in this circumstances, infinitely long lists are not going to
behave well either.

But, it seems to me, that this is (or should be) independent of
interactive use in the REPL. The current behaviour is never nice.
Probably, there needs to be a *interactive-print-length* var or
equivalent.

Andy Fingerhut  writes:

> One argument for default value of *print-length* being nil: Plenty of
> people print Clojure data structures to files and later read them back in.
> The data would be corrupted if *print-length* was a too-small numeric value
> for your particular data.  It might not be obvious until much later that
> you have lost data.
>
> Andy
>
>
> On Tue, Apr 1, 2014 at 9:00 AM, Andreas Liljeqvist  wrote:
>
>> Is there any good reason for not providing a default value for
>> *print-length*?
>> I think that if you *really* want to print a list containing 100K items,
>> you would have to set *print-length*.
>>
>> Basically it seems less harmful to set it to a nice value by default(42?)
>> than possible locking up the REPL.
>>
>>
>> On Tue, Apr 1, 2014 at 2:49 AM, Gary Trakhman wrote:
>>
>>> http://clojuredocs.org/clojure_core/clojure.core/*print-length*
>>>
>>>
>>> On Mon, Mar 31, 2014 at 8:49 PM, Christopher Howard >> > wrote:
>>>
 Is there some kind of "safe" function for printing representations of
 lazy, infinite data structures? I'm finding I like using them inside
 other data structures here and there. However, when I go to play
 around with things in the REPL, sooner or later my workflow is
 interrupted by 3 million characters streaming across the console.

 I don't imagine there would be any way for the REPL to detect that a
 lazy sequence was infinite. However, if it would simply refuse to
 evaluate lazy sequence (say, represent them by some special identifier)
 that
 would be good enough for me.

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

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

Re: REPL: viewing data structures containing infinite lists

[Gary Trakhman]

It's possible for an infinite print to be just fine, it's a streaming API
after all, consider invoking a clojure program in the middle of some unix
pipes.


On Tue, Apr 1, 2014 at 12:58 PM, Phillip Lord
wrote:

>
> Of course, in this circumstances, infinitely long lists are not going to
> behave well either.
>
> But, it seems to me, that this is (or should be) independent of
> interactive use in the REPL. The current behaviour is never nice.
> Probably, there needs to be a *interactive-print-length* var or
> equivalent.
>
> Andy Fingerhut  writes:
>
> > One argument for default value of *print-length* being nil: Plenty of
> > people print Clojure data structures to files and later read them back
> in.
> > The data would be corrupted if *print-length* was a too-small numeric
> value
> > for your particular data.  It might not be obvious until much later that
> > you have lost data.
> >
> > Andy
> >
> >
> > On Tue, Apr 1, 2014 at 9:00 AM, Andreas Liljeqvist 
> wrote:
> >
> >> Is there any good reason for not providing a default value for
> >> *print-length*?
> >> I think that if you *really* want to print a list containing 100K items,
> >> you would have to set *print-length*.
> >>
> >> Basically it seems less harmful to set it to a nice value by
> default(42?)
> >> than possible locking up the REPL.
> >>
> >>
> >> On Tue, Apr 1, 2014 at 2:49 AM, Gary Trakhman  >wrote:
> >>
> >>> http://clojuredocs.org/clojure_core/clojure.core/*print-length*
> >>>
> >>>
> >>> On Mon, Mar 31, 2014 at 8:49 PM, Christopher Howard <
> cmhowa...@alaska.edu
> >>> > wrote:
> >>>
>  Is there some kind of "safe" function for printing representations of
>  lazy, infinite data structures? I'm finding I like using them inside
>  other data structures here and there. However, when I go to play
>  around with things in the REPL, sooner or later my workflow is
>  interrupted by 3 million characters streaming across the console.
> 
>  I don't imagine there would be any way for the REPL to detect that a
>  lazy sequence was infinite. However, if it would simply refuse to
>  evaluate lazy sequence (say, represent them by some special
> identifier)
>  that
>  would be good enough for me.
> 
>  --
>  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.
> >>
>
> --
> 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
>

Re: REPL: viewing data structures containing infinite lists

[Maik Schünemann]

There is real no sensible default value rather than the current.
But for me the current behaviour is no problem, just C-c C-c to interrupt
evaluation (at least in cider)

On Tue, Apr 1, 2014 at 7:02 PM, Gary Trakhman  wrote:
> It's possible for an infinite print to be just fine, it's a streaming API
> after all, consider invoking a clojure program in the middle of some unix
> pipes.
>
>
> On Tue, Apr 1, 2014 at 12:58 PM, Phillip Lord 
> wrote:
>>
>>
>> Of course, in this circumstances, infinitely long lists are not going to
>> behave well either.
>>
>> But, it seems to me, that this is (or should be) independent of
>> interactive use in the REPL. The current behaviour is never nice.
>> Probably, there needs to be a *interactive-print-length* var or
>> equivalent.
>>
>> Andy Fingerhut  writes:
>>
>> > One argument for default value of *print-length* being nil: Plenty of
>> > people print Clojure data structures to files and later read them back
>> > in.
>> > The data would be corrupted if *print-length* was a too-small numeric
>> > value
>> > for your particular data.  It might not be obvious until much later that
>> > you have lost data.
>> >
>> > Andy
>> >
>> >
>> > On Tue, Apr 1, 2014 at 9:00 AM, Andreas Liljeqvist 
>> > wrote:
>> >
>> >> Is there any good reason for not providing a default value for
>> >> *print-length*?
>> >> I think that if you *really* want to print a list containing 100K
>> >> items,
>> >> you would have to set *print-length*.
>> >>
>> >> Basically it seems less harmful to set it to a nice value by
>> >> default(42?)
>> >> than possible locking up the REPL.
>> >>
>> >>
>> >> On Tue, Apr 1, 2014 at 2:49 AM, Gary Trakhman
>> >> wrote:
>> >>
>> >>> http://clojuredocs.org/clojure_core/clojure.core/*print-length*
>> >>>
>> >>>
>> >>> On Mon, Mar 31, 2014 at 8:49 PM, Christopher Howard
>> >>> > >>> > wrote:
>> >>>
>>  Is there some kind of "safe" function for printing representations of
>>  lazy, infinite data structures? I'm finding I like using them inside
>>  other data structures here and there. However, when I go to play
>>  around with things in the REPL, sooner or later my workflow is
>>  interrupted by 3 million characters streaming across the console.
>> 
>>  I don't imagine there would be any way for the REPL to detect that a
>>  lazy sequence was infinite. However, if it would simply refuse to
>>  evaluate lazy sequence (say, represent them by some special
>>  identifier)
>>  that
>>  would be good enough for me.
>> 
>>  --
>>  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.go

Re: REPL: viewing data structures containing infinite lists

[kovas boguta]

Chalk this up as another cautionary tale about global singletons.

There can be only one print-method, yet we have two conflicting use
cases: repl interaction, and data transport.

What we need is a parameterizable write-edn function, mirroring the
already extant read-edn. The function should guarantee it will either
write valid EDN, or throw an exception. It should also take as an
argument a map that allows one to specify the printing function for
any datatype.

I've taken a stab at this in my merchant library
(https://github.com/kovasb/merchant), one of the yaks I shaved for
session. I haven't announced/documented it, but someone who really
needs a solution might be interested to know it exists. It also
provides a sane way to deal with tagged literals.

With write-edn out of the way, we need a similar function optimized
for printing forms at the repl (with no guarantee that its output is
itself readable), and make it the default for the various repls.








On Tue, Apr 1, 2014 at 1:24 PM, Maik Schünemann
 wrote:
> There is real no sensible default value rather than the current.
> But for me the current behaviour is no problem, just C-c C-c to interrupt
> evaluation (at least in cider)
>
> On Tue, Apr 1, 2014 at 7:02 PM, Gary Trakhman  wrote:
>> It's possible for an infinite print to be just fine, it's a streaming API
>> after all, consider invoking a clojure program in the middle of some unix
>> pipes.
>>
>>
>> On Tue, Apr 1, 2014 at 12:58 PM, Phillip Lord 
>> wrote:
>>>
>>>
>>> Of course, in this circumstances, infinitely long lists are not going to
>>> behave well either.
>>>
>>> But, it seems to me, that this is (or should be) independent of
>>> interactive use in the REPL. The current behaviour is never nice.
>>> Probably, there needs to be a *interactive-print-length* var or
>>> equivalent.
>>>
>>> Andy Fingerhut  writes:
>>>
>>> > One argument for default value of *print-length* being nil: Plenty of
>>> > people print Clojure data structures to files and later read them back
>>> > in.
>>> > The data would be corrupted if *print-length* was a too-small numeric
>>> > value
>>> > for your particular data.  It might not be obvious until much later that
>>> > you have lost data.
>>> >
>>> > Andy
>>> >
>>> >
>>> > On Tue, Apr 1, 2014 at 9:00 AM, Andreas Liljeqvist 
>>> > wrote:
>>> >
>>> >> Is there any good reason for not providing a default value for
>>> >> *print-length*?
>>> >> I think that if you *really* want to print a list containing 100K
>>> >> items,
>>> >> you would have to set *print-length*.
>>> >>
>>> >> Basically it seems less harmful to set it to a nice value by
>>> >> default(42?)
>>> >> than possible locking up the REPL.
>>> >>
>>> >>
>>> >> On Tue, Apr 1, 2014 at 2:49 AM, Gary Trakhman
>>> >> wrote:
>>> >>
>>> >>> http://clojuredocs.org/clojure_core/clojure.core/*print-length*
>>> >>>
>>> >>>
>>> >>> On Mon, Mar 31, 2014 at 8:49 PM, Christopher Howard
>>> >>> >> >>> > wrote:
>>> >>>
>>>  Is there some kind of "safe" function for printing representations of
>>>  lazy, infinite data structures? I'm finding I like using them inside
>>>  other data structures here and there. However, when I go to play
>>>  around with things in the REPL, sooner or later my workflow is
>>>  interrupted by 3 million characters streaming across the console.
>>> 
>>>  I don't imagine there would be any way for the REPL to detect that a
>>>  lazy sequence was infinite. However, if it would simply refuse to
>>>  evaluate lazy sequence (say, represent them by some special
>>>  identifier)
>>>  that
>>>  would be good enough for me.
>>> 
>>>  --
>>>  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/gro

using a custom :store with wrap-multipart-params in ring middle ware

[K Livingston]

I'm having trouble using a custom :store with multipart-params.  I thought 
I did exactly what the documentation indicates, but I'm getting the default 
behavior.

http://ring-clojure.github.io/ring/ring.middleware.multipart-params.html

 :store- a function that stores a file upload. The function should
  expect a map with :filename, content-type and :stream keys,
  and its return value will be used as the value for the
  parameter in the multipart parameter map. The default storage
  function is the temp-file-store.



(mp/wrap-multipart-params 
   (POST "/upload-x" request (upload/upload-file request))
   {:store upload/logging-store})

My logging store function looks like this (it's just a dummy for now - 
eventually I want to handle the stream in a custom way) None of that IO 
happens.

(defn logging-store [{filename :filename
  content-type :content-type
  stream   :stream
  :as params}]
  (println "in logging store")
  (pprint filename)
  (pprint params)
  filename)

upload-file looks like this:

(defn upload-file [{params :params
session :session :as request}]
  (let [user-id (:user-id session)
files (get params "files")]
(pprint request)
(pprint params)
(response/response
 {:status:success})))

The printing for the request and the params clearly show the multipart 
params in there and that they are being handled by the temp file store:

 :multipart-params
 {"files"
  {:size 1674,
   :tempfile
   #,
   :content-type "application/octet-stream",
   :filename "blog-test.clj"}},



cross post here (if you want stack overflow points):
http://stackoverflow.com/questions/22792577/using-a-custom-store-with-wrap-multipart-params-in-ring-middle-ware

-- 
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: using a custom :store with wrap-multipart-params in ring middle ware

[K Livingston]

Sorry, I just realized there's a ring-specific mailing list - apologies for 
the clutter.
Moved:
https://groups.google.com/d/topic/ring-clojure/O5HoT-UIWfk/discussion

On Tuesday, April 1, 2014 12:02:26 PM UTC-6, K Livingston wrote:
>
> I'm having trouble using a custom :store with multipart-params.  I thought 
> I did exactly what the documentation indicates, but I'm getting the default 
> behavior.
>
> http://ring-clojure.github.io/ring/ring.middleware.multipart-params.html
>
>  :store- a function that stores a file upload. The function should
>   expect a map with :filename, content-type and :stream keys,
>   and its return value will be used as the value for the
>   parameter in the multipart parameter map. The default storage
>   function is the temp-file-store.
>
>
>
> (mp/wrap-multipart-params 
>(POST "/upload-x" request (upload/upload-file request))
>{:store upload/logging-store})
>
> My logging store function looks like this (it's just a dummy for now - 
> eventually I want to handle the stream in a custom way) None of that IO 
> happens.
>
> (defn logging-store [{filename :filename
>   content-type :content-type
>   stream   :stream
>   :as params}]
>   (println "in logging store")
>   (pprint filename)
>   (pprint params)
>   filename)
>
> upload-file looks like this:
>
> (defn upload-file [{params :params
> session :session :as request}]
>   (let [user-id (:user-id session)
> files (get params "files")]
> (pprint request)
> (pprint params)
> (response/response
>  {:status:success})))
>
> The printing for the request and the params clearly show the multipart 
> params in there and that they are being handled by the temp file store:
>
>  :multipart-params
>  {"files"
>   {:size 1674,
>:tempfile
># /var/folders/rx/9ntjyyvs35qbmcbp6rhfmj20gn/T/ring-multipart-3853352501927893381.tmp>,
>:content-type "application/octet-stream",
>:filename "blog-test.clj"}},
>
>
>
> cross post here (if you want stack overflow points):
>
> http://stackoverflow.com/questions/22792577/using-a-custom-store-with-wrap-multipart-params-in-ring-middle-ware
>

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

ANN: ClojureScript 0.0-2199

[David Nolen]

ClojureScript, the Clojure compiler that emits JavaScript source code.

README and source code: https://github.com/clojure/clojurescript

New release version: 0.0-2199

Leiningen dependency information:

[org.clojure/clojurescript "0.0-2199"]

The only difference is the removal of spurious warnings about
required/imported Google Closure libraries.

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

Re: using a custom :store with wrap-multipart-params in ring middle ware

[James Reeves]

It's because you apply wrap-multipart-params twice. First with the default
arguments, then with your custom store. The first application of the
function is via compojure.handler/site. If you remove that, or use
handler/api instead, or apply the parameter middleware yourself, your code
should work as expected.

- James


On 1 April 2014 19:15, K Livingston wrote:

> Sorry, I just realized there's a ring-specific mailing list - apologies
> for the clutter.
> Moved:
> https://groups.google.com/d/topic/ring-clojure/O5HoT-UIWfk/discussion
>
>
> On Tuesday, April 1, 2014 12:02:26 PM UTC-6, K Livingston wrote:
>>
>> I'm having trouble using a custom :store with multipart-params.  I
>> thought I did exactly what the documentation indicates, but I'm getting the
>> default behavior.
>>
>> http://ring-clojure.github.io/ring/ring.middleware.multipart-params.html
>>
>>  :store- a function that stores a file upload. The function should
>>   expect a map with :filename, content-type and :stream keys,
>>   and its return value will be used as the value for the
>>   parameter in the multipart parameter map. The default storage
>>   function is the temp-file-store.
>>
>>
>>
>> (mp/wrap-multipart-params
>>(POST "/upload-x" request (upload/upload-file request))
>>{:store upload/logging-store})
>>
>> My logging store function looks like this (it's just a dummy for now -
>> eventually I want to handle the stream in a custom way) None of that IO
>> happens.
>>
>> (defn logging-store [{filename :filename
>>   content-type :content-type
>>   stream   :stream
>>   :as params}]
>>   (println "in logging store")
>>   (pprint filename)
>>   (pprint params)
>>   filename)
>>
>> upload-file looks like this:
>>
>> (defn upload-file [{params :params
>> session :session :as request}]
>>   (let [user-id (:user-id session)
>> files (get params "files")]
>> (pprint request)
>> (pprint params)
>> (response/response
>>  {:status:success})))
>>
>> The printing for the request and the params clearly show the multipart
>> params in there and that they are being handled by the temp file store:
>>
>>  :multipart-params
>>  {"files"
>>   {:size 1674,
>>:tempfile
>>#> /var/folders/rx/9ntjyyvs35qbmcbp6rhfmj20gn/T/ring-multipart-3853352501927893381.tmp>,
>>:content-type "application/octet-stream",
>>:filename "blog-test.clj"}},
>>
>>
>>
>> cross post here (if you want stack overflow points):
>> http://stackoverflow.com/questions/22792577/using-a-
>> custom-store-with-wrap-multipart-params-in-ring-middle-ware
>>
>  --
> 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.

Lazy evaluation

[Pradip Caulagi]

I am just a newbie who has been hanging around and it is rather late in 
the day to bring this up but...


should we remove lazy sequences and lazy evaluation from Clojure?  Back 
of the envelope calculations show that we can get 2x performance 
improvements.


Thanks,
Pradip

--
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: Lazy evaluation

[Andy Fingerhut]

Back of the envelope meaning that you thought about the implementation and
are estimating, or you have measurements?

Either way, I agree that there are definitely use cases where non-lazy
processing can give performance improvements.  Probably even relatively
common use cases.

Cases where lazy sequences have advantages (not intended to be an
exhaustive list):

+ if you determine that you do not need the whole sequence, portions of it
need not be generated at all (perhaps large portions)

+ I do not have measurements for this use case to quantify the potential
performance benefits, but if you have a 'pipeline' of lazy operations, e.g.
a map on function f1 whose result is fed into a map on function f2, then a
filter on function f3, etc., the time order of execution will typically
have f1 called on an item in the sequence, then f2, then f3, etc., and only
after that is done will you go back and call f1, f2, f3, ... on the next
item of the original sequence.  There can be performance benefits from
keeping those intermediate results in a processor's cache while doing f1,
f2, f3, etc., rather than a whole pass of applying f1, then going back to
the beginning and doing a whole pass of f2, etc.  This is primarily an
issue with sequences that are large enough that they do not fit into the
cache.

Andy



On Tue, Apr 1, 2014 at 11:19 AM, Pradip Caulagi  wrote:

> I am just a newbie who has been hanging around and it is rather late in
> the day to bring this up but...
>
> should we remove lazy sequences and lazy evaluation from Clojure?  Back of
> the envelope calculations show that we can get 2x performance improvements.
>
> Thanks,
> Pradip
>
> --
> 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: Lazy evaluation

[Timothy Baldridge]

The question is "replace them with what"? I remember with not so fond
memories the days of using IEnumerable in C#, there was no immutability and
no caching. So if you created a massive chain of data and iterated over it
twice you would have to execute the entire chain of functions twice. With
LazySeqs the data would be evaluated once and the final result stored for
each iterator.

It's a trade off, but I'm constantly amazed at how wickedly fast LazySeqs
are.

Also, reducers are a good option when LazySeqs aren't fast enough.

Timothy


On Tue, Apr 1, 2014 at 1:17 PM, Andy Fingerhut wrote:

> Back of the envelope meaning that you thought about the implementation and
> are estimating, or you have measurements?
>
> Either way, I agree that there are definitely use cases where non-lazy
> processing can give performance improvements.  Probably even relatively
> common use cases.
>
> Cases where lazy sequences have advantages (not intended to be an
> exhaustive list):
>
> + if you determine that you do not need the whole sequence, portions of it
> need not be generated at all (perhaps large portions)
>
> + I do not have measurements for this use case to quantify the potential
> performance benefits, but if you have a 'pipeline' of lazy operations, e.g.
> a map on function f1 whose result is fed into a map on function f2, then a
> filter on function f3, etc., the time order of execution will typically
> have f1 called on an item in the sequence, then f2, then f3, etc., and only
> after that is done will you go back and call f1, f2, f3, ... on the next
> item of the original sequence.  There can be performance benefits from
> keeping those intermediate results in a processor's cache while doing f1,
> f2, f3, etc., rather than a whole pass of applying f1, then going back to
> the beginning and doing a whole pass of f2, etc.  This is primarily an
> issue with sequences that are large enough that they do not fit into the
> cache.
>
> Andy
>
>
>
> On Tue, Apr 1, 2014 at 11:19 AM, Pradip Caulagi  wrote:
>
>> I am just a newbie who has been hanging around and it is rather late in
>> the day to bring this up but...
>>
>> should we remove lazy sequences and lazy evaluation from Clojure?  Back
>> of the envelope calculations show that we can get 2x performance
>> improvements.
>>
>> Thanks,
>> Pradip
>>
>> --
>> 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.
>



-- 
"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://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: using a custom :store with wrap-multipart-params in ring middle ware

[K Livingston]

Thanks.  This is indeed what was going on.  I even went checking for that 
middle ware being referenced somewhere else, but didn't realize that 
handler function was adding so much middle ware (didn't even bother looking 
in it).

I removed the double calls and things are performing exactly as I expect 
now.

thanks,
Kevin


On Tuesday, April 1, 2014 12:38:56 PM UTC-6, James Reeves wrote:
>
> It's because you apply wrap-multipart-params twice. First with the default 
> arguments, then with your custom store. The first application of the 
> function is via compojure.handler/site. If you remove that, or use 
> handler/api instead, or apply the parameter middleware yourself, your code 
> should work as expected.
>
> - James
>
>
> On 1 April 2014 19:15, K Livingston 
> > wrote:
>
>> Sorry, I just realized there's a ring-specific mailing list - apologies 
>> for the clutter.
>> Moved:
>> https://groups.google.com/d/topic/ring-clojure/O5HoT-UIWfk/discussion
>>
>>
>> On Tuesday, April 1, 2014 12:02:26 PM UTC-6, K Livingston wrote:
>>>
>>> I'm having trouble using a custom :store with multipart-params.  I 
>>> thought I did exactly what the documentation indicates, but I'm getting the 
>>> default behavior.
>>>
>>> http://ring-clojure.github.io/ring/ring.middleware.multipart-params.html
>>>
>>>  :store- a function that stores a file upload. The function should
>>>   expect a map with :filename, content-type and :stream keys,
>>>   and its return value will be used as the value for the
>>>   parameter in the multipart parameter map. The default storage
>>>   function is the temp-file-store.
>>>
>>>
>>>
>>> (mp/wrap-multipart-params 
>>>(POST "/upload-x" request (upload/upload-file request))
>>>{:store upload/logging-store})
>>>
>>> My logging store function looks like this (it's just a dummy for now - 
>>> eventually I want to handle the stream in a custom way) None of that IO 
>>> happens.
>>>
>>> (defn logging-store [{filename :filename
>>>   content-type :content-type
>>>   stream   :stream
>>>   :as params}]
>>>   (println "in logging store")
>>>   (pprint filename)
>>>   (pprint params)
>>>   filename)
>>>
>>> upload-file looks like this:
>>>
>>> (defn upload-file [{params :params
>>> session :session :as request}]
>>>   (let [user-id (:user-id session)
>>> files (get params "files")]
>>> (pprint request)
>>> (pprint params)
>>> (response/response
>>>  {:status:success})))
>>>
>>> The printing for the request and the params clearly show the multipart 
>>> params in there and that they are being handled by the temp file store:
>>>
>>>  :multipart-params
>>>  {"files"
>>>   {:size 1674,
>>>:tempfile
>>>#>> /var/folders/rx/9ntjyyvs35qbmcbp6rhfmj20gn/T/ring-multipart-3853352501927893381.tmp>,
>>>:content-type "application/octet-stream",
>>>:filename "blog-test.clj"}},
>>>
>>>
>>>
>>> cross post here (if you want stack overflow points):
>>> http://stackoverflow.com/questions/22792577/using-a-
>>> custom-store-with-wrap-multipart-params-in-ring-middle-ware
>>>
>>  -- 
>> 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/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: Lazy evaluation

[Jozef Wagner]

Reducers should be given IMO a more attention, support and importance and 
I'm actually experimenting on a hypothesis that reducers can replace lazy 
seqs in most cases (excluding simple stuff, e.g. destructuring). Imagine a 
core API where functions like map, filter, rseq, range etc. are working 
with reducers by default and falling back to seqs only in rare cases or by 
explicit request.

Jozef

On Tuesday, April 1, 2014 9:28:49 PM UTC+2, tbc++ wrote:
>
> The question is "replace them with what"? I remember with not so fond 
> memories the days of using IEnumerable in C#, there was no immutability and 
> no caching. So if you created a massive chain of data and iterated over it 
> twice you would have to execute the entire chain of functions twice. With 
> LazySeqs the data would be evaluated once and the final result stored for 
> each iterator. 
>
> It's a trade off, but I'm constantly amazed at how wickedly fast LazySeqs 
> are. 
>
> Also, reducers are a good option when LazySeqs aren't fast enough. 
>
> Timothy
>
>
> On Tue, Apr 1, 2014 at 1:17 PM, Andy Fingerhut 
> 
> > wrote:
>
>> Back of the envelope meaning that you thought about the implementation 
>> and are estimating, or you have measurements?
>>
>> Either way, I agree that there are definitely use cases where non-lazy 
>> processing can give performance improvements.  Probably even relatively 
>> common use cases.
>>
>> Cases where lazy sequences have advantages (not intended to be an 
>> exhaustive list):
>>
>> + if you determine that you do not need the whole sequence, portions of 
>> it need not be generated at all (perhaps large portions)
>>
>> + I do not have measurements for this use case to quantify the potential 
>> performance benefits, but if you have a 'pipeline' of lazy operations, e.g. 
>> a map on function f1 whose result is fed into a map on function f2, then a 
>> filter on function f3, etc., the time order of execution will typically 
>> have f1 called on an item in the sequence, then f2, then f3, etc., and only 
>> after that is done will you go back and call f1, f2, f3, ... on the next 
>> item of the original sequence.  There can be performance benefits from 
>> keeping those intermediate results in a processor's cache while doing f1, 
>> f2, f3, etc., rather than a whole pass of applying f1, then going back to 
>> the beginning and doing a whole pass of f2, etc.  This is primarily an 
>> issue with sequences that are large enough that they do not fit into the 
>> cache.
>>
>> Andy
>>
>>
>>
>> On Tue, Apr 1, 2014 at 11:19 AM, Pradip Caulagi 
>> 
>> > wrote:
>>
>>> I am just a newbie who has been hanging around and it is rather late in 
>>> the day to bring this up but...
>>>
>>> should we remove lazy sequences and lazy evaluation from Clojure?  Back 
>>> of the envelope calculations show that we can get 2x performance 
>>> improvements.
>>>
>>> Thanks,
>>> Pradip
>>>
>>> -- 
>>> 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/d/optout.
>>>
>>
>>  -- 
>> 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/d/optout.
>>
>
>
>
> -- 
> “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://groups.google.com/group/clojure?hl=en
--- 
You recei

Re: Lazy evaluation

[Ghadi Shayban]

And Happy April Fools' everyone.  Nicely done Pradip.


On Tuesday, April 1, 2014 3:58:34 PM UTC-4, Jozef Wagner wrote:
>
> Reducers should be given IMO a more attention, support and importance and 
> I'm actually experimenting on a hypothesis that reducers can replace lazy 
> seqs in most cases (excluding simple stuff, e.g. destructuring). Imagine a 
> core API where functions like map, filter, rseq, range etc. are working 
> with reducers by default and falling back to seqs only in rare cases or by 
> explicit request.
>
> Jozef
>
> On Tuesday, April 1, 2014 9:28:49 PM UTC+2, tbc++ wrote:
>>
>> The question is "replace them with what"? I remember with not so fond 
>> memories the days of using IEnumerable in C#, there was no immutability and 
>> no caching. So if you created a massive chain of data and iterated over it 
>> twice you would have to execute the entire chain of functions twice. With 
>> LazySeqs the data would be evaluated once and the final result stored for 
>> each iterator. 
>>
>> It's a trade off, but I'm constantly amazed at how wickedly fast LazySeqs 
>> are. 
>>
>> Also, reducers are a good option when LazySeqs aren't fast enough. 
>>
>> Timothy
>>
>>
>> On Tue, Apr 1, 2014 at 1:17 PM, Andy Fingerhut wrote:
>>
>>> Back of the envelope meaning that you thought about the implementation 
>>> and are estimating, or you have measurements?
>>>
>>> Either way, I agree that there are definitely use cases where non-lazy 
>>> processing can give performance improvements.  Probably even relatively 
>>> common use cases.
>>>
>>> Cases where lazy sequences have advantages (not intended to be an 
>>> exhaustive list):
>>>
>>> + if you determine that you do not need the whole sequence, portions of 
>>> it need not be generated at all (perhaps large portions)
>>>
>>> + I do not have measurements for this use case to quantify the potential 
>>> performance benefits, but if you have a 'pipeline' of lazy operations, e.g. 
>>> a map on function f1 whose result is fed into a map on function f2, then a 
>>> filter on function f3, etc., the time order of execution will typically 
>>> have f1 called on an item in the sequence, then f2, then f3, etc., and only 
>>> after that is done will you go back and call f1, f2, f3, ... on the next 
>>> item of the original sequence.  There can be performance benefits from 
>>> keeping those intermediate results in a processor's cache while doing f1, 
>>> f2, f3, etc., rather than a whole pass of applying f1, then going back to 
>>> the beginning and doing a whole pass of f2, etc.  This is primarily an 
>>> issue with sequences that are large enough that they do not fit into the 
>>> cache.
>>>
>>> Andy
>>>
>>>
>>>
>>> On Tue, Apr 1, 2014 at 11:19 AM, Pradip Caulagi wrote:
>>>
 I am just a newbie who has been hanging around and it is rather late in 
 the day to bring this up but...

 should we remove lazy sequences and lazy evaluation from Clojure?  Back 
 of the envelope calculations show that we can get 2x performance 
 improvements.

 Thanks,
 Pradip

 -- 
 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/d/optout.

>>>
>>>  -- 
>>> 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/d/optout.
>>>
>>
>>
>>
>> -- 
>> “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 

Re: java interop help for beginner calling java class

[bww00amd...@yahoo.com]

So close!!

i have a question about the called java class and access to the byte array 
from clojure upon  return of the call to java

the call to the method in the class has 2 args buffer in and buffer out. i 
confirmed that the data is in buf and nnnx contains the correct 
size of the uncompressed file. i do not see the uncompressed data in bufout.

(import '(mynicelzw1 OcfLZWBW))
def fbw (new OcfLZWBW)
buf  (byte-array 1)  ; input buffer
n (.read in buf)  ; file read in to decompress
bufout (byte-array 20) ; output buffer
nnnx(.expand fbw buf bufout)

When I debug the repl i see the the 
file read in to buf
the call made to .expand in the class OcfLZWBW

I get the correct number of  the size of the uncompressed data (nnnx)

I do not see the uncompressed data in bufout, in the debug bufout is null.

as always any help would be appreciated.

Thanks





On Friday, March 28, 2014 10:12:08 AM UTC-5, bww00...@yahoo.com wrote:
>
> I have read so much i cant see the tree for the forest.
> and need some help calling the  ocfLZW class below from clojure.
>
> THANKS for the help
>
> using eclipse and counterclockwise
>
> In clojure 
>  have the data to decompress read into an array.
>  have an array allocated to hold the decompresed data
>
>
> The java class ocfLZW is accessible
>
> I have a java program exert below that calls the ocfLZW class and verified 
> that it works.
>
>
> FileInputStream fis = new FileInputStream(input);
> 
> byte[] sInefficient= new byte[(int)input.length()] ;
> fis.read(sInefficient);
>
> OcfLZW oi = new OcfLZW();
>
> byte[] out = null;
>
>  out = new byte[160];
>
> int len = oi.expand(sInefficient, out);
> System.out.println(new String (out));
> System.out.println("out size = "+len);
>
>
> ocfLZW java class that does LZW decompress 
>
> /* */ public class OcfLZW
> /* */ {
> /* */   static final int INIT_BITS = 9;
> /*   6 */   final int MAX_BITS = 13;
> /*   7 */   final int TABLE_SIZE = 9029;
> /*   8 */   final int HASH_SHIFT = 5;
> /*   9 */   final int CLEAR_TABLE = 256;
> /*  10 */   final int TERMINATOR = 257;
> /* */   static final int FIRST_CODE = 258;
> /* */   static final int CHECK_TIME = 100;
> /*  13 */   final int STACK_SIZE = 4000;
> /*  14 */   boolean EOF = false;
> /* */   static int myIndex;
> /* */   static int offset;
> /* */   static int input_bit_buffer;
> /* */   static int output_bit_buffer;
> /* */   static int string_code;
> /* */   static int bytes_out_this_time;
> /*  22 */   static int next_code = 258;
> /* */   static int max_code;
> /*  24 */   static int checkpoint = 100;
> /*  25 */   static int tot_bytesin = 0;
> /* */   static int gbl_ulong;
> /*  28 */   static int[] code_value = null;
> /*  29 */   static int[] prefix_code = null;
> /*  31 */   int input_bit_count = 0;
> /*  32 */   int output_bit_count = 0;
> /*  33 */   int num_bits = 9;
> /*  34 */   int clear_bytesin = 0;
> /*  35 */   int clear_bytesout = 0;
> /*  36 */   int tot_bytesout = 0;
> /* */   int ratio_new;
> /*  38 */   int ratio_old = 100;
> /*  40 */   static boolean compress_flag = false;
> /*  41 */   static int initialized = 0;
> /*  43 */   static byte[] in_buffpoint = null;
> /*  44 */   static byte[] out_buffpoint = null;
> /*  45 */   int in_buff_n = 0;
> /*  45 */   int out_buff_n = 0;
> /*  45 */   int in_buffend = 0;
> /*  45 */   int out_buffend = 0;
> /*  47 */   byte[] append_character = null;
> /*  48 */   byte gbl_ptr_idx = 0;
> /*  50 */   byte[] decode_stack = null;
> /*  51 */   int ds_i = 0;
> /* */   
> /* */   public int expand(byte[] paramArrayOfByte1, byte[] 
> paramArrayOfByte2)
> /* */   {
> /*  56 */ this.ds_i = 0;
> /* */ 
> /*  58 */ compress_flag = false;
> /* */ 
> /* */ 
> /*  61 */ max_code = (1 << this.num_bits) - 1;
> /*  62 */ prefix_code = new int[9029];
> /*  63 */ this.append_character = new byte[9029];
> /* */ 
> /* */ 
> /* */ 
> /*  67 */ this.decode_stack = new byte[4000];
> /*  69 */ if ((prefix_code == null) || (this.append_character == null) 
> || (this.decode_stack == null) || ((compress_flag) && (code_value == 
> null))) {
> /*  73 */   return 0;
> /* */ }
> /*  75 */ out_buffpoint = paramArrayOfByte2;
> /*  76 */ this.out_buff_n = 0;
> /*  77 */ in_buffpoint = paramArrayOfByte1;
> /*  78 */ this.in_buff_n = 0;
> /* */ 
> /* */ 
> /* */ 
> /*  82 */ int[] arrayOfInt1 = new int[1];
> /*  83 */ int i = 0;
> /*  84 */ int j = 0;
> /* */ 
> /*  86 */ int[] arrayOfInt2 = new int[1];
> /*  87 */ int m = 0;
> /*  88 */ arrayOfInt1[0] = 0;
> /* */ 
> /*  90 */ arrayOfInt2[0] = 0;
> /* */ 
> /*  92 */ int k = 1;
> /* */ 
> /* */ 
> /* */ 
> /* */ 
> /* */ 
> /* 

Re: Strange behaviour for proxy when two abstract classes are passed in

[Chris Zheng]

Ah no wonder!

I was looking at the wrong documentation for asm.

On 02/04/2014, at 1:41, "A. Webb"  wrote:

> 
> 
> On Monday, March 31, 2014 4:34:17 PM UTC-5, zcaudate wrote:
>> 
>> I know this is a silly example but I am curious to know what is happening 
>> with the proxy method.
>> 
>> I have set up two calls to proxy:
>> 
>> 1.
>>   (def cp
>> (proxy [java.util.AbstractMap clojure.asm.ClassVisitor] []))
>> 
>> 2.
>>   (def cp
>> (proxy [clojure.asm.ClassVisitor java.util.AbstractMap] []))
>> 
>> 
>> The first call is fine and it return cp.  The second call gives me an 
>> exception.
> 
> You cross-posted to Stack Overflow Stack Overflow. Copy of my answer there:
> 
> Neither will work in Clojure 1.6.0. In 1.5, `clojure.asm.ClassVisitor` was an 
> interface instead of an abstract class. Proxy expects at most one class 
> followed by optional interfaces. As `java.util.AbstractMap` is an abstract 
> class, it cannot appear second in the list of class-and-interfaces. 
> -- 
> 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/xInFQ7hCf0c/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/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: [ClojureScript] ANN: ClojureScript 0.0-2199

[Tim Visher]

Hi David,

On Tue, Apr 1, 2014 at 2:38 PM, David Nolen  wrote:
> ClojureScript, the Clojure compiler that emits JavaScript source code.
>
> New release version: 0.0-2199
>
> The only difference is the removal of spurious warnings about
> required/imported Google Closure libraries.

As always, thanks for all the hard work!

AFAICT, I'm still getting these warnings when using lein-cljsbuild
1.0.3, clojurescript 0.0-2199, and clojure 1.6.0. Are there extra
flags I need to set to avoid them? They happen under whitespace and
advanced.

--

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ -- Spend less time on mail

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

Porting parsley & paredit.clj to Clojurescript: Crazy, or inevitable?

[kovas boguta]

I really want legitimate paredit in the browser.

Looking through the source for parsley & paredit.clj, I'm halfway
convinced that maybe its not so hard to port these to clojurescript.

Anyone have input in either direction?

Most of the Java interop seems to be
1. ArrayList (in parsley)
2. Various string methods (.endsWith, .indexOf, etc)
3. Regular expressions

Is there something I'm missing that would require structural change?

-- 
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: Porting parsley & paredit.clj to Clojurescript: Crazy, or inevitable?

[Ghadi Shayban]

I can't speak to the implementation of any of this, but I have to link to a 
favorite demo [1] of structural editing.  The animations are really slick, 
but the way he's designed moving up and down the abstraction hierarchy is 
brilliant.  Cue an Emacs user telling me it's already possible with some 
elisp magic...

[1] https://www.youtube.com/watch?v=tztmgCcZaM4

On Tuesday, April 1, 2014 9:26:51 PM UTC-4, kovasb wrote:
>
> I really want legitimate paredit in the browser. 
>
> Looking through the source for parsley & paredit.clj, I'm halfway 
> convinced that maybe its not so hard to port these to clojurescript. 
>
> Anyone have input in either direction? 
>
> Most of the Java interop seems to be 
> 1. ArrayList (in parsley) 
> 2. Various string methods (.endsWith, .indexOf, etc) 
> 3. Regular expressions 
>
> Is there something I'm missing that would require structural change? 
>

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