Re: Digest for clojure@googlegroups.com - 14 Messages in 9 Topics

34 views
Skip to first unread message

JAX

unread,
Jul 28, 2011, 8:23:08 PM7/28/11
to clo...@googlegroups.com
I'm all for simplifying clojure.
Even if Lein is great... If clojure is heavily biased and saddled by yet another framework/build system , it will never go mainstream.

Jay Vyas 
MMSB
UCHC

On Jul 29, 2011, at 12:32 AM, clojure...@googlegroups.com wrote:

Group: http://groups.google.com/group/clojure/topics

    Sean Corfield <seanco...@gmail.com> Jul 28 04:28PM -0700 ^
     
    >> Chas has already pointed you at the rationale / discussion but I'm a
    > Discussions about primitive arithmetic, not BigInteger arithmetic.
     
    I take it you didn't actually bother to read the page he linked to?
    Let me quote the relevant part for you since I know how averse you are
    to spending any time reading more than the first few lines of any
    material that people link to:
     
    * new clojure.lang.BigInt class
    * BigInts do not auto-reduce, and are contagious (akin to doubles)
    * BigInts will enable optimizations when fits in long
    * optimzations not yet in place
    * unlike BigInteger, BigInt has consistent hashcodes with Long,
    through range of long
     
    > That'd be my position, yes. Also, backward compatibility: format works
    > in 1.2 with (* 400000000000 400000000000 400000000000) so it should
    > work in 1.3 with (* 400000000000 400000000000 400000000000).
     
    Kinda hard since that expression is not valid in 1.3 anyway:
     
    ArithmeticException integer overflow
    clojure.lang.Numbers.throwIntOverflow (Numbers.java:1374)
     
    So that code breaks explicitly in 1.3 and in many ways (format) is
    then the least of your worries...
     
    >> Might be worth opening a JIRA ticket for enhancing format, yes?
    > You go ahead. I don't have an account there.
     
    Ah, that's right... the contributor process is too much work for
    you... Maybe one of the kind souls who've taken the time to go thru
    that process might feel inclined to open such a ticket for you? If
    they agree with your position, of course.
    --
    Sean A Corfield -- (904) 302-SEAN
    An Architect's View -- http://corfield.org/
    World Singles, LLC. -- http://worldsingles.com/
    Railo Technologies, Inc. -- http://www.getrailo.com/
     
    "Perfection is the enemy of the good."
    -- Gustave Flaubert, French realist novelist (1821-1880)

     

    octopusgrabbus <octopus...@gmail.com> Jul 28 03:37PM -0700 ^
     
    Are there any command-line examples or documentation other than what's
    up on clojure.org or ClojureDocs?
     
    I'm using
     
    (defn -main [& args]
    (with-command-line args
    "Get csv file name"
    [[in-file-name ".csv input file name" "resultset.csv" ]]
    [[in-file-name ".csv input file name" 1]]
     
    (println "in-file-name:", in-file-name)
     
    If I specify a file name it does not get used. Only resultset.csv is
    used.
     
    tnx
    cmn

     

    Sean Corfield <seanco...@gmail.com> Jul 28 04:14PM -0700 ^
     
    > So, what does it means for Clojure?
     
    It's not going to mean anything for a long time. Clojure still
    supports Java 5 so it is probably going to be years before Java 7 is
    mainstream enough that Clojure can _require_ it.
    --
    Sean A Corfield -- (904) 302-SEAN
    An Architect's View -- http://corfield.org/
    World Singles, LLC. -- http://worldsingles.com/
    Railo Technologies, Inc. -- http://www.getrailo.com/
     
    "Perfection is the enemy of the good."
    -- Gustave Flaubert, French realist novelist (1821-1880)

     

    Anthony Grimes <discip...@gmail.com> Jul 28 03:32PM -0700 ^
     
    I'm all of a sudden getting this exact same error on OS X 10.6.8. And I do
    mean all of a sudden. I actually updated to this version of OS X last night
    and today it isn't working. Is this happening to any OS X users on an older
    Snow Leopard? This is the only thing that has changed in my setup, so I'm
    actually starting to wonder if it might have something to do with that.

     

    uMany <elm...@gmail.com> Jul 28 03:57PM -0700 ^
     
    I'm a total newbie with Clojure/Lisp/Java/Cake/Lein/Emacs etc.
    But I want to help translating to Spanish.
    If you tell me where can I find instructions to do it I will with
    pleasure.
     
    By the way, I've been fighting with Emacs/Clojure and everything else.
    It has been frustrating but I've learn a lot and I like to learn. So
    for me, I don't give up. I wont give up. I just want to program in
    Clojure no matter what just because I like it.
     
    Manuel
     

     

    Sam Aaron <sama...@gmail.com> Jul 28 11:48PM +0100 ^
     
    Hi there,
     
    I'm trying to create a fn which does the following:
     
    * returns a fn which takes an arbitrary number of args
    * calls a helper fn, passing the incoming args returning a vector of alternating symbols and vals
    * creates a let form using the vector of alternating symbols and vals returned by the helper fn as the bindings
    * contains some inner form that makes use of the bindings
     
    i.e. is it possible to implement something that allows the following to work:
     
    (defn binding-vec
    [args]
    ['size (count args)])
     
    (defn mk-dynamically-bound-fn
    [form]
    ;; returns a fn with sign [& args] which
    ;; uses binding-vec to create a the vec for
    ;; which a let statement binds around form
    )
     
    (def a (mk-dynamically-bound-fn '(+ size 10)))
     
    (a 1 2 3 4) ;=> 14 (the number of args + 10)
     
     
    Please let me know if I'm being a bit crazy with the question. It's totally possible that I'm barking up the wrong tree with this line of enquiry.
     
    Sam
     
    ---
    http://sam.aaron.name

     

    nil <ach...@gmail.com> Jul 28 02:37PM -0700 ^
     
    Until you find someone, one site you can look at is the clojure euler
    site. It has some math examples written by folks who know clojure to
    varying degrees. You can see different ways of tackling a given
    problem.
     

     

    Tuba Lambanog <tuba.l...@gmail.com> Jul 28 03:32PM -0600 ^
     
    Hi, Laurent,
     
    Your suggestion of manually piping intermediate results works. Thank you
    very much!
     
    Tuba
     

     

    Michal B <mibu.c...@gmail.com> Jul 28 02:23PM -0700 ^
     
    Why does it have to be so complicated to use libraries?
     
    To use libraries, you need to learn how to operate half a dozen build tools
    and git because each library author distributes their library differently.
    If figuring out how to install an IDE with clojure wasn't bad enough, now
    you need to figure out how to install and use each of the tools with it.
     
    I'm not saying build tools are useless, on the contrary. It's just that most
    of the time, we want to sling two or three libraries together and code.
    Right? There is no need to start a project with a bunch of template files
    and an elaborate directory structure and to start configuring dependencies
    and to rely on some magic happening that makes your program run.
     
    I think we over-engineered the build process to support the big projects and
    forgot the common case. Most projects are simple.
     
    Let's remove this incidental complexity by returning to simplicity. Keep the
    build tools for the heavyweights and get back in touch with your libraries.
     
    Instead of having a complicated installation guide for your library, have a
    Download section in your site. Have there a link to the latest stable
    version of your library as a jar file or, if necessary, a zip file with your
    jar and and all the necessary dependency jars (sane library authors won't
    mind). For a zip, shortly describe what's in it - library names and
    versions, and links to their sites. That's it.
     
    I think most JVM users know or can quickly figure out how to take jars and
    put them in their project's classpath. It's simple to do with all IDEs (or
    without one) and there is no need to learn or install additional software or
    edit configuration files. Starter scripts should include in the classpath
    all jars in the current directory or jars/ directory by default.
     
    Instead of managing libraries inside a dependencies file, you do it directly
    with the jar files. If the project gets too big, bring in the build tools.
     
    What are your thoughts on this issue?

     

    Timothy Baldridge <tbald...@gmail.com> Jul 28 04:30PM -0500 ^
     
    > Why does it have to be so complicated to use libraries?
     
    I used to think it was hard until I read up on lein. Can't get much
    simpler than clojars and lein:
     
    http://clojars.org/
    http://alexott.net/en/clojure/ClojureLein.html
     
    Now I'm starting to think that I actually like the lein method over
    python easy_install or ruby gems.
     
    Timothy
     
     
    --
    “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)

     

    gaz jones <gareth....@gmail.com> Jul 28 04:31PM -0500 ^
     
    i would agree with all that if i were writing plain java (a lib dir
    for dependencies and a couple of shell scripts for building etc), but
    leiningen makes it so easy for clojure that its more work _not_ to use
    it... at least that has been my experience.
     

     

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

gaz jones

unread,
Jul 28, 2011, 9:25:54 PM7/28/11
to clo...@googlegroups.com
i would have to disagree with that. i hardly feel saddled with lein,
it frees me from thinking about any build stuff 95% of the time, and
as far as i know it is not the 'official' build system of clojure.
it's just extremely popular because it makes creating and building
projects so easy. you're free to use any tools you see fit to build
your projects -- i dont understand why having an awesome tool that
makes builds easy would in any way mean 'it will never go mainstream'?
O_o

Luc Prefontaine

unread,
Jul 28, 2011, 10:41:16 PM7/28/11
to clo...@googlegroups.com
We cannot prevent people pulling their hairs and getting bald with dependency management
if they wish to do so.

Now if you say that Maven is not mainstream, hampers Java projects and should be ditched that's
a discussion for a different mailing list.

Leiningen brings simplicity on top of Maven so you can have some hairs to brush the following morning.
It leverages what exists already in the Java dependency management world. It did not choose
to impose Maven to developers.

You can still use NetBeans or Eclipse to code in Java without the help (?!) of Maven.
You can still code in Clojure with a bare bone text editor and the REPL.

It all depends on the complexity of your software and it's size.

However you are right, Clojure may never get mainstream, people in general are against simplicity.
They make choices that make their lives impossible and can't see that they feel miserable
because of their own decisions.

I chose to live the other way around a long time ago. Choosing Clojure and Leiningen is part of that principle,
avoid dictator ship by the masses. I wish I had the guts of Rich at his age to step down and
say "enough". Not sure I would have created something as coherent as Clojure.

It's entirely up to you to live with hairy dependency problems if you wish so.

Choose your own hell, use Maven as-is, Ant or even manage you dependencies by hand with -cp .... when starting the JVM.

Luc P.


On Fri, 29 Jul 2011 01:23:08 +0100
JAX <jayun...@gmail.com> wrote:

> I'm all for simplifying clojure.
> Even if Lein is great... If clojure is heavily biased and saddled by
> yet another framework/build system , it will never go mainstream.
>
> Jay Vyas
> MMSB
> UCHC

MMSB ? Multiple Microcontroller Support Board ?
UCHC ? Upper Canada Hockey Club
Duh ?

--
Luc P.

================
The rabid Muppet

Reply all
Reply to author
Forward
0 new messages