Fwd: [ldnclj] Hackday on Sunday
Fwding to Incanter and Clojure mailing lists. This hackday is in London, this Sunday the 19th of Feb. Unfortunately, I can't attend, but I know it will be awesome! Thanks, Ben -- Forwarded message -- From: Martin Seebach Date: Wed, Feb 15, 2012 at 12:19 PM Subject: [ldnclj] Hackday on Sunday To: london-clojuri...@googlegroups.com All, The next hackday is on Sunday 19 February from 10:00 at TIM Group 4th floor 3 Copthall Ave London EC2R 7BH It's the building next door (south) to the APEX London Wall hotel, across the street from Itsu. The door buzzer may or may not work on weekends, if you have any problems give me a call at 07852948946. Nearest tube: Moorgate or Bank (roughly equidistant). I'm obliged to mention that TIM Group is an awesome place to work for developers & we're hiring, although we don't do any Clojure (and, frankly, are unlikely to begin any time soon). Read more at http://www.timgroup.com/key-roles See you there, Martin -- You received this message because you are subscribed to the Google Groups "London Clojurians" group. To post to this group, send email to london-clojuri...@googlegroups.com. To unsubscribe from this group, send email to london-clojurians+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/london-clojurians?hl=en. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Released: nREPL 0.2.0-beta1
Apart from going a bit cross-eyed from seeing clojure-as-java code
from the first time, I get it :-)
Thanks Chas, I'll give it a try and let you know how it goes.
Stathis
On Feb 15, 3:31 pm, Chas Emerick wrote:
> You can absolutely run an nREPL server from a mostly-Java application.
> Something like this would do (just a sketch, untested):
>
>
> private static IFn startServer, stopServer;
>
> static {
> try {
> RT.var("clojure.core",
> "require").invoke(Symbol.intern("clojure.tools.nrepl.server"));
> startServer = RT.var("clojure.tools.nrepl.server", "start-server");
> stopServer = RT.var("clojure.tools.nrepl.server", "stop-server");
> } catch (Exception e) {
> throw new RuntimeException(e);
> }
>
> }
>
> public static Object startServer (int port) {
> return startServer.invoke(Keyword.intern("port"), port);
>
> }
>
> public static void stopServer (Object server) {
> stopServer.invoke(server);}
>
>
>
> There's already a thin Java wrapper for the nREPL client API
> (https://github.com/clojure/tools.nrepl/blob/master/src/main/java/cloj...one
> for the server side would be good to cover that use case as well.
>
> - Chas
>
> On Feb 15, 2012, at 8:46 AM, Stathis Sideris wrote:
>
>
>
>
>
>
>
> > It sounds great Chas, especially the wide acceptance that nREPL seems
> > to already have with the various tools.
>
> > I wanted to ask about the potential of this as an embedded Clojure
> > REPL in existing Java applications for the purpose of connecting
> > remotely and performing inspection (and possibly manipulation?) of the
> > current state of the application for debugging purposes. Is this a
> > legitimate use case? How easy do you think it would be to achieve this
> > with the current version of nREPL?
>
> > Thanks!
>
> > Stathis
>
> > On Feb 14, 2:42 pm, Chas Emerick wrote:
> >> I have released nREPL 0.2.0-beta1, which should show up in Maven central
> >> soon.
>
> >> For those that don't know, nREPL is "a Clojure network REPL that provides
> >> a REPL server and client, along with some common APIs of use to IDEs and
> >> other tools that may need to evaluate Clojure code in remote environments":
>
> >>https://github.com/clojure/tools.nrepl
>
> >> This release is the result of gathering ideas, feedback, and requirements
> >> from dozens of people that need to have a REPL backend in a variety of
> >> environments, and want to maximize interoperability of Clojure tooling —
> >> much of which inevitably ends up grounding out at running or connecting to
> >> a REPL somewhere.
>
> >> This release marks a thorough breaking change from every aspect the last
> >> release of nREPL, 0.0.5. (The rationale for this is detailed in design
> >> notes in the project's wiki, for those that haven't followed along.) The
> >> result is that a design that settles a number of failings of nREPL's
> >> original design, and which provides a number of different vectors of
> >> extensibility — similar in many respects to those provided by Ring — that
> >> I hope people will take advantage of to build astonishingly cool tools.
>
> >> Note that pre-release versions of many Clojure tools are already using
> >> snapshots of nREPL 0.2.0, including Counterclockwise, Leiningen, and
> >> Reply, and as far as I know, more are on their way.
>
> >> My plans for the near future are to continue to tighten up the
> >> documentation, and release an HTTP transport: a Ring handler that exposes
> >> nREPL as an HTTP API.
>
> >> If you have any questions or find some shortcoming, bug, or problem with
> >> this release, please reply here or ping me on irc or twitter (`cemerick`
> >> in either case).
>
> >> Happy tooling,
>
> >> - Chas
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Lack in the documentation
Regarding don't want to learn Java. I understand fully, but can I suggest downloading a major java-IDE and make some small and simple java-katas in it? I would suggest IntelliJ IDEAs Community Edition (there are other, ofc) and then going through some examples from the surprisingly well written Java tutorials on Oracles site: http://docs.oracle.com/javase/tutorial/ Understanding how java works is the key to understand a lot of the sometimes apparently quirky java-interop stuff and you probably wont die in the meantime, I promise. There's also a few strange things going on in readers, streams and exceptions that is really good to have a clue of. This could be four or five very well spent hours on your way to master Clojure. Stop when programs goes into a 100 rows or so, those programs can usually be done much much quicker in Clojure. Best regards, Linus 2012/2/16 Sean Corfield > I don't think your tone is very helpful Armando. It's perfectly > reasonable to ask for specific examples - so that there are actionable > tasks we as a group can take on, rather than just some vague "the > documentation is too Java-centric" complaint. > > When I read the OP, I was not sure what he was really complaining > about or asking for. I don't agree with the assertion that all the > documentation assumes Java knowledge - and clearly a lot of non-Java > programmers have managed to pick up Clojure just fine. > > Even tho' I have Java experience, I had no experience with Maven so > the whole library dependency thing was new to me - but it didn't seem > Java-centric. I had experienced the classpath aspect of Java but, > frankly, Leiningen completely hides that. The only "required" Java > experience, as far as I can see, is if you _choose_ to use Java > libraries within Clojure - and even that is just a matter of reading a > library's documentation and applying the interop rules... > > Your snide remark about a build tool is not appropriate given how > popular Leiningen is and how much work Phil and many others have put > into it. > > Sean > > On Wed, Feb 15, 2012 at 7:38 PM, Armando Blancas > wrote: > >> Can you provide some more specific examples of what's missing? > > > > Surely you're joking, Mr. Hagelberg. > > > >> I don't know any Java and was able to manage pretty well. > > > > This is no time for modesty, lest the OP might feel his troubles > > aren't even valid. Perhaps better to say that a rudimentary grasp of > > Java (language, libraries, tools) can go a long way. Then one day... > > we'll get a killer build tool or something. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Clojure online university
Hello fellow Clojurians, yesterday I was watching Neal Ford's brilliant world domination video and it got me again thinking about idea I've got for some time. With the advent of online learning initiatives like Stanford, MITx, and many others I think it would be great to create Clojure course. Most of the resources are already out there. Videos are awesome, 4clojure is really nice, tools are improving every day and community is really great. I would really appreciate having Clojure course in my CV, and I believe that others do as well. If someone in the community is thinking about something like this, and needs any help please let me know. Cheers, Peter -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Cannot access variables without namespace in ClojureScript repl.
On Jan 15, 3:32 pm, Brenton wrote: > We found a couple of problems with theClojureScriptREPL while > working onOneand will address them soon. If you confirm that this is > the problem, please let us know. Also, feel free to add an issue to > JIRA with the steps to reproduce. [snip] I'm experiencing the same problem. I've created an issue on github. https://github.com/brentonashworth/one/issues/116 I don't understand this well enough to see if it is a ClojureScript issue or 'one' issue. - Karl -- 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
mini mud-client for within emacs-swank
Started playing with getting an within emacs clojure-based mud client, but
puzzling a bit with parsing the incoming stream. The below works (for
emacs+swank-clojure 1.4.0), but puts a space between every character. When
I try to solve that (for example by swapping "(print ..." with "(print
(apply str ...", then incoming text is no longer automatically parsed into
the repl.
Anyone knows how to fix this?
(use 'swank.core) ;; 1.4.0-MASTER
(import (org.apache.commons.net.telnet Telnet TelnetClient
TelnetOutputStream))
(defn connect []
(let [client (TelnetClient.)]
(.connect client (java.net.InetAddress/getByName "avendar.com") )
client))
(declare send-to-mud)
(defn start-reading [session] (with-read-line-support (send-to-mud session
(read-line
(defn send-to-mud [session message]
(.write (.getOutputStream session) (.getBytes message))
(.flush (.getOutputStream session))
(start-reading session))
;; Connect to mud
;;
(def avendar (connect))
(print (take 1 (remove #{\return} (map char (take-while #(not= % -1)
(repeatedly #(.read (.getInputStream avendar
;; Type this in repl:
;;
(start-reading avendar)
;; Eval this to disconnect:
;;
(.disconnect avendar)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: add-watch in clojurescript: awesome, or not awesome?
Sounds like you should build a simple abstraction layer over atoms instead of trying to use them directly? Or provide a new data binding / propagation protocol that avoids the limitation of atoms? For data binding you most definitely always want to receive the old value in my experience. On Wednesday, February 15, 2012, kovas boguta wrote: > More than a few people have noticed the similarities between > add-watch, and event/data binding in things like Backbone.js. > > Maybe its worth considering if a feature marked as "alpha" is really > the best thing for this case. > > 1. add-watch arguments are verbose. Do we really need a key to name > the watcher, and the old value? For the vast majority of cases, no. > > 2. cascading changes is verbose. Often you want the watcher to update > another atom, but all this needs to be set up manually. > Perhaps something simpler like > (echo f some-atom) > could return a new atom, whose value is (f some-atom) and is updated > with each change. > > 3. Incremental updates are difficult; the action performed on the > source atom is opaque > Simply being informed of values is not enough -- if you know what > action was performed on the source atom, you can proceed more > efficiently. Instead of recomputing an entire sequence of dom > elements, you could insert/delete the relevant ones, or decide which > other actions need to be taken. > > This last problem could potentially be addressed by adding meta-data > to the update action, which is then propagated to the watchers. > > Another approach would be to introduce new reference types > corresponding to clojure collections, atom-vector and atom-map, which > could incrementally update themselves from the source atom. > > Something like > > (echo f (atom-vector X)), > > where atom-vector implements a protocol allowing for incremental > updates which then get propagated to echo'ing atom. > > Figuring out a reasonable way to deal with collections is a big > stumbling block for me, in trying to build data-binding abstractions > in clojurescript. Recomputing everything is suboptimal (though it is > also suboptimal that there is no data sharing in the current > implementation of the clojurescript collections so you end up copying > everything on each modification anyway) > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A Bug of map function?
That's the point. Empty lazy sequence doesn't work, but not empty lazy sequence works. On 2月15日, 上午9时44分, Armando Blancas wrote: > eval doesn't mind lazy seqs as input: > > user=> (map identity ['quote ()]) > (quote ()) > user=> (class (map identity ['quote ()])) > clojure.lang.LazySeq > user=> (eval (map identity ['quote ()])) > () > > But it can't handle a form that contains an (evaluated) empty lazy > seq. Another example: > user=> (eval `(quote ~(range -1))) > CompilerException java.lang.UnsupportedOperationException: Unknown > Collection type, compiling:(NO_SOURCE_PATH:53) > > I think Alan pointed to bug. The empty-expr needs to check for LazySeq > instances as well. > > On Feb 14, 2:00 pm, Stuart Sierra wrote: > > > > > > > > > A sequence is equal to a list because Clojure defines = to compare similar > > collections by their contents. For example, the vector [1 2 3] is equal (by > > the = function) to the list (1 2 3). > > > `eval` calls the Clojure compiler. The compiler operates on lists returned > > by the reader, so I would not expect it to work on lazy sequences. > > > -S -- 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
AOT Error
1. create a new leinigen project: lein new foo 2. modify foo.core.clj as follow: (ns foo.core) (defn format [] 1) 3. modify project.clj, add foo.core to aot: (defproject foo "1.0.0-SNAPSHOT" :description "FIXME: write description" :dependencies [[org.clojure/clojure "1.3.0"]] :aot [foo.core]) 4. lein compile will throw exception Compiling foo.core WARNING: format already refers to: #'clojure.core/format in namespace: foo.core, being replaced by: #'foo.core/format Exception in thread "main" java.lang.NullPointerException at clojure.lang.Compiler$ObjExpr.emitVar(Compiler.java:4728) at clojure.lang.Compiler$DefExpr.emit(Compiler.java:395) at clojure.lang.Compiler.compile1(Compiler.java:6984) at clojure.lang.Compiler.compile(Compiler.java:7046) at clojure.lang.RT.compile(RT.java:385) at clojure.lang.RT.load(RT.java:425) at clojure.lang.RT.load(RT.java:398) at clojure.core$load$fn__4610.invoke(core.clj:5386) at clojure.core$load.doInvoke(core.clj:5385) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.core$load_one.invoke(core.clj:5200) at clojure.core$compile$fn__4615.invoke(core.clj:5397) at clojure.core$compile.invoke(core.clj:5396) at user$eval31.invoke(NO_SOURCE_FILE:1) at clojure.lang.Compiler.eval(Compiler.java:6465) at clojure.lang.Compiler.eval(Compiler.java:6455) at clojure.lang.Compiler.eval(Compiler.java:6431) at clojure.core$eval.invoke(core.clj:2795) at clojure.main$eval_opt.invoke(main.clj:296) at clojure.main$initialize.invoke(main.clj:315) at clojure.main$null_opt.invoke(main.clj:348) at clojure.main$main.doInvoke(main.clj:426) at clojure.lang.RestFn.invoke(RestFn.java:421) at clojure.lang.Var.invoke(Var.java:405) at clojure.lang.AFn.applyToHelper(AFn.java:163) at clojure.lang.Var.applyTo(Var.java:518) at clojure.main.main(main.java:37) Compilation failed. If I change the function name "format" to other things like "format1", then compile will succeed. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: A Bug of map function?
http://groups.google.com/group/clojure/browse_thread/thread/ef16bb620d3e86d7/2e8e38067325c973#2e8e38067325c973 On Mon, Feb 13, 2012 at 17:02, Eric Fong wrote: > => (eval `'~(map identity [1 2 3])) > (1 2 3) > > => (eval `'~(map identity ())) > CompilerException java.lang.UnsupportedOperationException: Unknown > Collection type, compiling:(NO_SOURCE_PATH:135) > > => (eval `'~(map identity nil)) > CompilerException java.lang.UnsupportedOperationException: Unknown > Collection type, compiling:(NO_SOURCE_PATH:138) > > try the above in repl, clojure 1.3, why the exception occured? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureScript def, vars, and binding
I've updated my fork with IWatchable and validation implemented on Var: https://github.com/brandonbloom/clojurescript/compare/8ba4849e60e5957cdac36ef6946c647e824ca3c8...vars @dnolen I assume I need to wait for my CA to be delivered/approved before I can update that Wiki page? I'd like to add some more notes... -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Lack in the documentation
Hi All, very new to clojure, so thought my experience may be relevant. Initially, the java aspect is a bit daunting. However, I don't believe you need to know java in order to take advantage of all the java interop features of clojure. All that you really need is to understand how to read java API documentation and understand the way clojure can interface with java libraries. This in itself may appear to be a big hurdle at first, but its not that hard provided you just have a go. My main advice would be to use Leiningen to help manage things, ignore maven etc and use the repl to experiment. Just reading the docs is insufficient - you have to sit at the repl and try using a few java libs and it will become clearer as you progress. I also find looking at other clojure code and how others have used java very useful. There are also some good books out there which are quite useful. I'm currently reading The Joy of Clojure and while tastes and mileage may differ, I am finding it a really interesting and informative book. >From a documentation standpoint, I've not found it too bad. The cheatsheet has been very useful and using things like find-doc etc help to narrow down the search space. I do suspect that as the complexity of what I'm trying to do increases, I will likely need to understand java better, I suspect that is a way down the road yet and it will come in little pieces as I need them. Perhaps my only criticism with the docs are that there may be too many documents out there covering the 'getting started' aspect. I'm using emacs, slime and lein and it has all worked fine, but there was quite a bit of conflicting and in some cases incorrect information out there. Much of it seems to have made it far more complicated than it ended up being. I would possibly be good if clojure.org, clojuredocs.org and dev.clojure.org had just one definitive/official getting started document. I'd go further and suggest that document should really just be "download lein; chmod u+x lein and lein install. Then, one official document for clojure+emacs, clojure+vim, clojure+eclipse etc and pointers to other tweaks/setups. However, in general, I think things are pretty good for such a young/new language and I'm having a lot of fun! Is there a document which covers the changes in 1.3 in more detail than the official release notes - especailly one which may explain how some of the changes can impact on past idioms etc. For example, it took me a while to find (with-redefs ...) as an alternative to using (bindings ...) for doing things like mocking functions for testing - I'm still not 100% sure this is even the right approach, but seems more correct than using ^:dynamic just to enable a test harness to work. Tim -- 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
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 3 (test-xml.clj:6)
I'm trying to I'm trying to create a solution for bug #21 in https://github.com/weavejester/lein-ring";>lein-ring, but before I start mucking about in weavejester's code, I want to get clojure.xml/emit to print out a modified version of http://pastebin.com/G8WeAsiv. I'm getting an exception when I try to run my code through my clojure REPL. https://gist.github.com/1838248";>Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 3 (test-xml.clj:6). Could someone please look over my code thus far and help me figure out what I'm doing wrong? Thank you for your time and consideration. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Looking for parser generator library
atto is 10^-18, and a parsec is 3.1×10^13 km, which is 3.1×10^16m, which is 3.1×10^18cm, so Cedric was right, from what I can see... Turns out I misread a 3 as a 5... lol *facepalm* On Thu, Feb 16, 2012 at 1:04 PM, Alan Malloy wrote: > Roman Gonzalez: > > this library is a port of Haskell's attoparsec > > Despite: > > > Haskell has a parser library named for a distance of approximately > > > three centimetres? :) > > > > Not that it's pertinent, but a parsec is 31 trillion kilometers. Did > > you massively misplace a decimal? :) > > 1 attoParsec = 3.08568025 × 10-5 kilometers > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Looking for parser generator library
Not massively - I get about 3.1 metres. 10^-18x10^15x10^3x3.1m... On Thu, Feb 16, 2012 at 12:47 PM, Despite wrote: > > Haskell has a parser library named for a distance of approximately > > three centimetres? :) > > Not that it's pertinent, but a parsec is 31 trillion kilometers. Did > you massively misplace a decimal? :) > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureScript def, vars, and binding
> Given the single-threaded nature of JavaScript I don't see how future-call or agents could be implemented. There are analogous constructs in a single-threaded, async-callback world. In particular, many Javascript libraries have a concept of promises and futures for managing the async callback speghetti. Like I said, that part of the puzzle needs much more thought. This is step one: Implement robust dynamic binding. > Dynamic binding is often used for configuration. Configuration that you probably want preserved across an async callback Imagine binding *parse-response-in-some-special-way* before calling ajax-get... > It's also important to note that what you're proposing could easily be provided as a useful library Maybe... but it would need to override some of the Compiler's multi-methods... Proper Var support, on par with JVM Clojure, seems like it belongs as part of the core ClojureScript distribution. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: AOT Error
Eric Fong writes: > 1. create a new leinigen project: > lein new foo > > 2. modify foo.core.clj as follow: > (ns foo.core) > (defn format [] 1) Exclude clojure.core/format then: (ns foo.core (:refer-clojure :exclude [format])) Bye, Tassilo -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Problem with the Chas Emerick: "Modeling the world ..." video
The same here. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureScript def, vars, and binding
On Wednesday, February 15, 2012, Brandon Bloom wrote:. > There are analogous constructs in a single-threaded, async-callback world. In particular, many Javascript libraries have a concept of promises and futures for managing the async callback speghetti. Like I said, that part of the puzzle needs much more thought. This is step one: Implement robust dynamic binding. Step one is properly describing the problem. There are many possible solutions many which don't try to graft Clojure's concurrency concepts onto a single-threaded environment. You're working on a particular solution - others already exist in the JS world as you've mentioned. A robust solution can be implemented via CPS transformation, and that can be provided as a ClojureScript library without changing the meaning of binding as it's currently implemented. I would expand your design notes before you continue down any particular solution. Otherwise it will have insufficient justification. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Lack in the documentation
> Initially, the java aspect is a bit daunting. However, I don't believe you > need to know java in order to take advantage of all the java interop > features of clojure. So as a background, before I give my two cents. I'm a C# developer by trade, and feel very comfortable with .NET. I also have quite a bit of Python experience, and am just as comfortable in that language. However, I have to agree with the OP...when it comes to Clojure and Java interop, I kindof feel like the developers just said "eh...we'll give good interop and make everyone learn Java as well". I'm not going to say this was a bad position to take, on the contrary, I think it's just fine. But the problem is that now I, as a .NET developer have two choices: 1) Learn Java just to use Clojure. 2) Use Clojure-CLR and be stuck withouth lein and 90% of the libs that I want to use. I think the big problem, is that Clojure makes a big deal about being "Simple". That is, avoiding unneeded complexity, but then throws its users into the sea of complexity that is Java. If I want to write arbitrary binary data to a file, I really don't want to take the time to learn what a FileOutputStream is, or a DataOutputStream. All I really want is to just spit some binary data into a file. All I really want is an interface like this: (with-file f (open "foo.baz" "w") (write-int f 1) (write-string f 3)) Doing this would allow users to port the same code to Clojure-CLR, Clojure-JVM, or ClojureScript...and write truly compatible code. As someone who doesn't know Java, my Clojure development is greatly slowed because I must spend hours pouring over the Java docs to figure out how to do simple things like write a file. I have to be worried about accidental reflection, proper class construction (or even reflection when the class is constructed), etc. It's my belief that this is why Python has had such success with the beginner programmers. You can go to the Python docs...find a section on "writing files" and in a minute know everything there is to know about writing files. Python even includes a built-in mini web server! If I want to write a mini-webserver in stock Clojure...ummm...do I start with Jetty? Timothy -- 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
How to be lazy…
Hi all, I am trying to implement a function that splits any given sequence on a subsequence. I would like it to behave like this: user> (split-at-subsequence [5 6] (range 10)) ((0 1 2 3 4) (7 8 9)) user> (split-at-subsequence [5 7] (range 10)) ((0 1 2 3 4 5 6 7 8 9)) user> (first (second (split-at-subsequence [1 2] (range 3 The code I have so far inserts sentinels for the given subsequence and then returns chunks until a sentinel is found. (defn starts-with-subseq? "Returns true if the first sequence starts with the second one" [sub-seq coll] (let [pairs (map vector coll sub-seq) matching-pairs (take-while #(= (first %) (second %)) pairs)] (= (count matching-pairs) (count sub-seq (defn- replace-subseq-with-sentinel [sub-seq sentinel coll] (lazy-seq (when-let [s (seq coll)] (if (starts-with-subseq? sub-seq s) (cons sentinel (replace-subseq-with-sentinel sub-seq sentinel (drop (count sub-seq) s))) (cons (first s) (replace-subseq-with-sentinel sub-seq sentinel (rest s))) (defn- split-at-sentinel [sentinel coll] (take-nth 2 (partition-by #(= sentinel %) coll))) (defn split-at-subsequence [sub-seq coll] (let [sentinel (Object.)] (->> (replace-subseq-with-sentinel sub-seq sentinel coll) (split-at-sentinel sentinel))) This does exactly what it should do, except for the fact that user> (first (second (split-at-subsequence [1 2] (range never returns as it does not seem to be "lazy enough". What surprises me is that user> (def sentinel (Object.)) #'user/sentinel user> (take 5 (replace-subseq-with-sentinel [1 2] sentinel (range))) (0 # 3 4 5) works just fine, so the problem must be in my implementation of split-at-sentinel. I would be grateful for any pointers that might shed light on this behaviour. I am using clojure 1.3 if that is of any importance. Thanks for your time and may you have a nice day! -- Wolodja 4096R/CAF14EFC 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Re: How to be lazy…
partition-by is lazy in that it only splits its argument into as many subseqs as requested; the subseqs themselves are not lazy. So when you partition-by the result of (replace-subseq-with-sentinel [1 2] sentinel (range)) and then request the infinite third subseq thereof, partition-by won't terminate. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Lack in the documentation
> I think the big problem, is that Clojure makes a big deal about being > "Simple". That is, avoiding unneeded complexity, but then throws its > users into the sea of complexity that is Java. If I want to write > arbitrary binary data to a file, I really don't want to take the time > to learn what a FileOutputStream is, or a DataOutputStream. All I > really want is to just spit some binary data into a file. All I really > want is an interface like this: > > (with-file f (open "foo.baz" "w") > (write-int f 1) > (write-string f 3)) > > Doing this would allow users to port the same code to Clojure-CLR, > Clojure-JVM, or ClojureScript...and write truly compatible code. As > someone who doesn't know Java, my Clojure development is greatly > slowed because I must spend hours pouring over the Java docs to figure > out how to do simple things like write a file. I have to be worried > about accidental reflection, proper class construction (or even > reflection when the class is constructed), etc. > > It's my belief that this is why Python has had such success with the > beginner programmers. You can go to the Python docs...find a section > on "writing files" and in a minute know everything there is to know > about writing files. Python even includes a built-in mini web server! > If I want to write a mini-webserver in stock Clojure...ummm...do I > start with Jetty? I agree with Timothy. I have been using Clojure for over 2 years and still consider myself a beginner (despite having gotten a Clojure article published in PragProg magazine). I have a Seesaw-based Clojure application running, but it's been painful every step of the way, and it continues to be so because I always have to start by figuring out how to do X--is the answer in Clojure or Java? Would it kill somebody to write a library of simple functions that would answer most beginners' simple needs, then have it "blessed" as canonical? I'd write it myself, but I still don't know enough! If every beginner has to painfully figure these things out, most beginners are going to bail--which means that Clojure remains a niche language, unknown to a lot of people who could have brought their considerable creativity to the Clojure community. And, Timothy, you make extremely valid points. They are very far away from being a rant. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How to be lazy…
On Thu, Feb 16, 2012 at 10:51 -0600, Michael Gardner wrote: > partition-by is lazy in that it only splits its argument into as many > subseqs as requested; the subseqs themselves are not lazy. So when you > partition-by the result of (replace-subseq-with-sentinel [1 2] sentinel > (range)) and then request the infinite third subseq thereof, partition-by > won't terminate. Thanks for the explanation. What would be a good way to ensure that the subseqeuence are lazy too? -- Wolodja 4096R/CAF14EFC 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: Digital signature
Re: Lack in the documentation
On Thu, Feb 16, 2012 at 12:04 PM, Gregg Williams wrote: > Would it kill somebody to write a library of simple functions that > would answer most beginners' simple needs, then have it "blessed" as > canonical? I'd write it myself, but I still don't know enough! If > every beginner has to painfully figure these things out, most > beginners are going to bail--which means that Clojure remains a niche > language, unknown to a lot of people who could have brought their > considerable creativity to the Clojure community. > We are patiently waiting for *you* to do / start / lead this. If it's a real paint point for enough people - folks will happily contribute, you don't need to know / think of everything. I've found this to be case with ClojureScript, core.match, and core.logic. I'm working on ClojureScript support for core.match and core.logic and I happily welcome any patches that will make them work on the CLR. It's tiresome to hear people complain about something they do not contribute anything towards. David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Lack in the documentation
Armando Blancas writes: >> Can you provide some more specific examples of what's missing? > > Surely you're joking, Mr. Hagelberg. I was asking because when I was starting, I found I had trouble specifically with Java's IO classes. This article was written after I had already learned what I needed, and I often point newbies to it: http://copperthoughts.com/p/clojure-io-p1/ So if the main problem is IO, then maybe moving that to the official docs could go a long way. If the problem is with other pieces of the Java ecosystem, then maybe someone could write a similar introductory article on other problematic areas. Simply saying "it's not good enough" is unhelpful. -Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Lack in the documentation
On Feb 16, 2012, at 12:16 PM, David Nolen wrote: > On Thu, Feb 16, 2012 at 12:04 PM, Gregg Williams > wrote: > Would it kill somebody to write a library of simple functions that > would answer most beginners' simple needs, then have it "blessed" as > canonical? I'd write it myself, but I still don't know enough! If > every beginner has to painfully figure these things out, most > beginners are going to bail--which means that Clojure remains a niche > language, unknown to a lot of people who could have brought their > considerable creativity to the Clojure community. > > We are patiently waiting for *you* to do / start / lead this. If it's a real > paint point for enough people - folks will happily contribute, you don't need > to know / think of everything. I've found this to be case with ClojureScript, > core.match, and core.logic. I'm working on ClojureScript support for > core.match and core.logic and I happily welcome any patches that will make > them work on the CLR. > > It's tiresome to hear people complain about something they do not contribute > anything towards. This is a horrible venue for this sort of conversation, but here goes. Refocusing on the question of documentation, there have been no shortage of people doing what they can / think is best to help. This is what produced ClojureDocs, cheatsheets of all sorts, ClojureAtlas, the tooling stuff on dev.clojure.org, N books, screencasts, etc. etc. etc. Of course, none of that helps with official documentation, clojure.org, `clojure.*` docstrings, and so on, all of which has been the subject of these kinds of conversations a hundred times in the past, but which will always be front-and-center for the newcomer. Yes, you can learn and use Clojure effectively with the resources that are available — thousands have, and many thousands more will, but that doesn't mean that the resources available and their presentations don't have significant shortcomings, and that many thousands more with different backgrounds and aptitudes won't make it through the funnel (or worse, will pass it by entirely) because of them. Of course, there are a variety of reasons why those that are in a position to help, cannot. On the topic of the need for a "library of simple functions that answer most beginners' simple needs"…I'm skeptical of that, insofar as the "simple needs" premise sounds like a variant of the tantalizing 80/20 myth (http://www.joelonsoftware.com/articles/fog20.html). Assuming that's wrong, I don't know if yet-another-library is much of a solution, as that mostly just shifts the documentation problem around from looking at javadoc to looking at one of N different people's take on a library to solve those simple needs, with all of the abstraction leakage that is usually implied by such endeavors. There is surely a need here though, which I'll take the liberty of dropping into the "easy mode" bucket mentioned in Stuart H.'s talk from the Conj. I'm not sure anyone knows what easy mode looks like from an API standpoint. To the OP's original complaint, I think Stuart's reply is succinct and correct but nearly irrelevant from the perspective of a newcomer. I'm hopefully helping the non-Java developer by trying to provide more signposts for them in the book I co-authored (specifically, for those with some Ruby and Python experience), so that Clojure's foreign concepts can be more easily linked up with known quantities. However, a "critical mass" of tutorials and documentation aimed at non-Java developers does nothing to alleviate the burden of awareness and familiarity with JDK APIs that are so often needed. Clojure is trying to do a lot, and _not_ covering up the host — a huge advantage once you have your sea legs and have become comfortable with that relationship — is new territory AFAIK for a language with uptake ambitions. To compare, consider if Python forced you into the C FFI to write a byte to a file or draw a line on a graphics context. So, I think there is merit to the complaint, but the solutions probably aren't in the realm of "it'll take time", "patches welcome", or "write a library that does foo". Cheers, - Chas -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Looking for parser generator library
https://www.google.com/search?q=attoparsec+in+centimeters is where I got a citation to back the 3.1 centimeter number (though, curiously, I asked for km instead of cm the first time). On Feb 15, 5:51 pm, DAemon wrote: > Not massively - I get about 3.1 metres. 10^-18x10^15x10^3x3.1m... > > > > > > > > On Thu, Feb 16, 2012 at 12:47 PM, Despite wrote: > > > Haskell has a parser library named for a distance of approximately > > > three centimetres? :) > > > Not that it's pertinent, but a parsec is 31 trillion kilometers. Did > > you massively misplace a decimal? :) > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How to be lazy…
On Feb 16, 2012, at 11:08 AM, Wolodja Wentland wrote: > Thanks for the explanation. What would be a good way to ensure that the > subseqeuence are lazy too? I can't think of a good way to do this with higher-order functions, so you'll probably have to write a recursive function that "manually" iterates over the collection, looking ahead as necessary to figure out when to split. To make the result lazy, just wrap your function's body in a call to lazy-seq. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: add-watch in clojurescript: awesome, or not awesome?
I'm arguing that IMHO, the atom+watcher abstraction is not rich enough to build upon. Atoms have the watcher list natively built into their datastructure. But the watcher abstraction is too simple to do anything beyond syntactic sugar. If you want to roll your own, you need to maintain your own notification system and bypass the existing mechanism entirely. This is what I'll end up doing. Though if the update action had an additional parameter, it would be more flexible. Out of curiosity, what do you do with the old value? On Thu, Feb 16, 2012 at 8:15 AM, David Nolen wrote: > Sounds like you should build a simple abstraction layer over atoms instead > of trying to use them directly? Or provide a new data binding / propagation > protocol that avoids the limitation of atoms? For data binding you most > definitely always want to receive the old value in my experience. > > > On Wednesday, February 15, 2012, kovas boguta > wrote: >> More than a few people have noticed the similarities between >> add-watch, and event/data binding in things like Backbone.js. >> >> Maybe its worth considering if a feature marked as "alpha" is really >> the best thing for this case. >> >> 1. add-watch arguments are verbose. Do we really need a key to name >> the watcher, and the old value? For the vast majority of cases, no. >> >> 2. cascading changes is verbose. Often you want the watcher to update >> another atom, but all this needs to be set up manually. >> Perhaps something simpler like >> (echo f some-atom) >> could return a new atom, whose value is (f some-atom) and is updated >> with each change. >> >> 3. Incremental updates are difficult; the action performed on the >> source atom is opaque >> Simply being informed of values is not enough -- if you know what >> action was performed on the source atom, you can proceed more >> efficiently. Instead of recomputing an entire sequence of dom >> elements, you could insert/delete the relevant ones, or decide which >> other actions need to be taken. >> >> This last problem could potentially be addressed by adding meta-data >> to the update action, which is then propagated to the watchers. >> >> Another approach would be to introduce new reference types >> corresponding to clojure collections, atom-vector and atom-map, which >> could incrementally update themselves from the source atom. >> >> Something like >> >> (echo f (atom-vector X)), >> >> where atom-vector implements a protocol allowing for incremental >> updates which then get propagated to echo'ing atom. >> >> Figuring out a reasonable way to deal with collections is a big >> stumbling block for me, in trying to build data-binding abstractions >> in clojurescript. Recomputing everything is suboptimal (though it is >> also suboptimal that there is no data sharing in the current >> implementation of the clojurescript collections so you end up copying >> everything on each modification anyway) >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: add-watch in clojurescript: awesome, or not awesome?
On Thu, Feb 16, 2012 at 4:39 PM, kovas boguta wrote: > I'm arguing that IMHO, the atom+watcher abstraction is not rich enough > to build upon. > I'm not disagreeing :) > If you want to roll your own, you need to maintain your own > notification system and bypass the existing mechanism entirely. This > is what I'll end up doing. Though if the update action had an > additional parameter, it would be more flexible. > Probably not worth breaking the expected behavior of Atoms. > Out of curiosity, what do you do with the old value? There are many reasons you might want to use the old value when developing user interfaces. All useful data-binding layers I'm familiar with from Cocoa to Backbone.js provide it. David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure online university
On Thu, Feb 16, 2012 at 1:57 AM, Peter Hanak wrote: > If someone in the community is thinking about something like this, and > needs any help please let me know. Something like this, from the author of Clojure in Action, Amit Rathore: http://codelesson.com/courses/view/introduction-to-clojure -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- 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
Problem with amap over byte arrays
Hi all, I'm experiencing the following problem: (def an-array (byte-array 200 (byte 1))) (amap ^bytes an-array idx ret (bit-xor (byte 0) (aget ^bytes an-array idx))) Resulting in: No matching method found: aset Wheras this: (def another-array (int-array 200 (int 1))) (amap ^ints an-array idx ret (bit-xor (int 0) (aget ^ints another-array idx))) Works as expected. Does anyone know what's going on? Clojure version is 1.3.0 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Problem with amap over byte arrays
Because bit-xor returns a integer,so you have to cast it to byte: (amap ^bytes an-array idx ret (byte (bit-xor (byte 0) (aget ^bytes an-array idx 2012/2/17 Andreas Kostler > Hi all, > I'm experiencing the following problem: > > (def an-array (byte-array 200 (byte 1))) > (amap ^bytes an-array > idx > ret > (bit-xor (byte 0) > (aget ^bytes an-array idx))) > > Resulting in: > > No matching method found: aset > > Wheras this: > > (def another-array (int-array 200 (int 1))) > (amap ^ints an-array > idx > ret > (bit-xor (int 0) > (aget ^ints another-array idx))) > > Works as expected. Does anyone know what's going on? > Clojure version is 1.3.0 > > -- > 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 -- 庄晓丹 Email:killme2...@gmail.com xzhu...@avos.com Site: http://fnil.net Twitter: @killme2008 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Problem with amap over byte arrays
How stupid of me. Cheers On 17 February 2012 12:12, dennis zhuang wrote: > Because bit-xor returns a integer,so you have to cast it to byte: > > > (amap ^bytes an-array > idx > ret > (byte (bit-xor (byte 0) > (aget ^bytes an-array idx > > > 2012/2/17 Andreas Kostler > >> Hi all, >> I'm experiencing the following problem: >> >> (def an-array (byte-array 200 (byte 1))) >> (amap ^bytes an-array >> idx >> ret >> (bit-xor (byte 0) >> (aget ^bytes an-array idx))) >> >> Resulting in: >> >> No matching method found: aset >> >> Wheras this: >> >> (def another-array (int-array 200 (int 1))) >> (amap ^ints an-array >> idx >> ret >> (bit-xor (int 0) >> (aget ^ints another-array idx))) >> >> Works as expected. Does anyone know what's going on? >> Clojure version is 1.3.0 >> >> -- >> 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 > > > > > -- > 庄晓丹 > Email:killme2...@gmail.com xzhu...@avos.com > Site: http://fnil.net > Twitter: @killme2008 > > > > > -- > 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 > -- ** Andreas Koestler, Software Engineer Leica Geosystems Pty Ltd 270 Gladstone Road, Dutton Park QLD 4102 Main: +61 7 3891 9772 Direct: +61 7 3117 8808 Fax: +61 7 3891 9336 Email: andreas.koest...@leica-geosystems.com www.leica-geosystems.com* when it has to be right, Leica Geosystems Please consider the environment before printing this email. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Lack in the documentation
> It's tiresome to hear people complain about something they do not > contribute anything towards. Thank you for your extremely helpful critique. By the way, please go to http://www.GettingClojure.com, a web site that I started and contributed to, which nobody (except Sean Cornfeld) expressed any interest in. I announced GettingClojure.com on this forum, which nobody encouraged, contributed to, or endorsed as a good idea. (I'd be willing to transfer the domain to the right person--even more, I'd like to see the site be a good place for newcomers to go.) BTW, a guy named David Sletten contributed 29 (I counted them) entries to a fledgling Clojure Cookbook, which made a good start on what could be a good newcomer resource. And I did say that I wrote an article about a nontrivial aspect of Clojure that I found *no* documentation or hints about anywhere on the Internet? See http://pragprog.com/magazines/2010-11/getting-clojure if you're interested; its real title is "Extending Java Classes Using Proxy." (I invite feedback on this, as well.) Yes, a few people have been helpful, but is it any surprise that I have called the Clojure community "newcomer-hostile"? (See my post, which is part of this thread: http://groups.google.com/group/clojure/browse_thread/thread/f97699164e9be29e/a9b91350905109b1?lnk=gst&q=Gregg+Williams#a9b91350905109b1 ) For future reference: I invite you to be less dismissive of someone who would like to be of help. To quote from the abovementioned thread: > I hope you can see that I'm saying these things only because I *want* > to see Clojure succeed. The community's "we're-all-experts-here" > mindset is driving newcomers away. (By all right, I should have been > one of them--but I'm an extremely stubborn cuss.) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Lack in the documentation
Nothing I said was meant to dismiss any particular contribution(s) of any kind made by anyone. If this was not clear, apologies. On Thursday, February 16, 2012, Gregg Williams wrote: >> It's tiresome to hear people complain about something they do not >> contribute anything towards. > > Thank you for your extremely helpful critique. > > By the way, please go to http://www.GettingClojure.com, a web site > that I started and contributed to, which nobody (except Sean Cornfeld) > expressed any interest in. I announced GettingClojure.com on this > forum, which nobody encouraged, contributed to, or endorsed as a good > idea. (I'd be willing to transfer the domain to the right person--even > more, I'd like to see the site be a good place for newcomers to go.) > > BTW, a guy named David Sletten contributed 29 (I counted them) entries > to a fledgling Clojure Cookbook, which made a good start on what could > be a good newcomer resource. > > And I did say that I wrote an article about a nontrivial aspect of > Clojure that I found *no* documentation or hints about anywhere on the > Internet? See http://pragprog.com/magazines/2010-11/getting-clojure if > you're interested; its real title is "Extending Java Classes Using > Proxy." (I invite feedback on this, as well.) > > Yes, a few people have been helpful, but is it any surprise that I > have called the Clojure community "newcomer-hostile"? (See my post, > which is part of this thread: > http://groups.google.com/group/clojure/browse_thread/thread/f97699164e9be29e/a9b91350905109b1?lnk=gst&q=Gregg+Williams#a9b91350905109b1 > ) > > For future reference: I invite you to be less dismissive of someone > who would like to be of help. To quote from the abovementioned thread: > >> I hope you can see that I'm saying these things only because I *want* >> to see Clojure succeed. The community's "we're-all-experts-here" >> mindset is driving newcomers away. (By all right, I should have been >> one of them--but I'm an extremely stubborn cuss.) > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureScript def, vars, and binding
2012/2/16 David Nolen > On Wednesday, February 15, 2012, Brandon Bloom > wrote:. > > > There are analogous constructs in a single-threaded, async-callback > world. In particular, many Javascript libraries have a concept of promises > and futures for managing the async callback speghetti. Like I said, that > part of the puzzle needs much more thought. This is step one: Implement > robust dynamic binding. > > Step one is properly describing the problem. There are many possible > solutions many which don't try to graft Clojure's concurrency concepts onto > a single-threaded environment. Forgive me if I'm wrong, but global vars / dynamic variables have essentially more to do with scoping than multithreading, e.g. they existed in lisps and other languages way before thread support was added to them. So I don't understand why you are rejecting the idea of adding support for them based on the argument that Javascript is monothread ... > You're working on a particular solution - others already exist in the JS > world as you've mentioned. A robust solution can be implemented via CPS > transformation, and that can be provided as a ClojureScript library without > changing the meaning of binding as it's currently implemented. > > I would expand your design notes before you continue down any particular > solution. Otherwise it will have insufficient justification. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Clojure/West - last day for regular registration rates
Friday Feb. 17th is the last day for regular registration rates at Clojure/West! - http://clojurewest.org/schedule - http://regonline.com/clojurewest2012 Monday Feb. 20th is the last day for the hotel block rate of $119/ night - https://resweb.passkey.com/go/clojurewest We've had a late addition to the schedule of Chris Houser talking about debugging in a distributed environment. No title/abstract yet Alex -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureScript def, vars, and binding
On Fri, Feb 17, 2012 at 1:28 AM, Laurent PETIT wrote: > Forgive me if I'm wrong, but global vars / dynamic variables have > essentially more to do with scoping than multithreading, e.g. they existed > in lisps and other languages way before thread support was added to them. +1 > So I don't understand why you are rejecting the idea of adding support for > them based on the argument that Javascript is monothread ... Particularly when there is no guarantee that JS will stay that way forever, and the general historic trend has been for languages to gain multithreading that formerly lacked it. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureScript def, vars, and binding
On Fri, Feb 17, 2012 at 1:28 AM, Laurent PETIT wrote: > Forgive me if I'm wrong, but global vars / dynamic variables have > essentially more to do with scoping than multithreading, e.g. they existed > in lisps and other languages way before thread support was added to them. > > So I don't understand why you are rejecting the idea of adding support for > them based on the argument that Javascript is monothread ... > Dynamic binding already works in ClojureScript. The discussion is about whether dynamic binding should be extended to address common async patterns in JavaScript applications. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureScript def, vars, and binding
Envoyé de mon iPhone Le 17 févr. 2012 à 08:24, David Nolen a écrit : On Fri, Feb 17, 2012 at 1:28 AM, Laurent PETIT wrote: > Forgive me if I'm wrong, but global vars / dynamic variables have > essentially more to do with scoping than multithreading, e.g. they existed > in lisps and other languages way before thread support was added to them. > > So I don't understand why you are rejecting the idea of adding support for > them based on the argument that Javascript is monothread ... > Dynamic binding already works in ClojureScript. Oh, ok then The discussion is about whether dynamic binding should be extended to address common async patterns in JavaScript applications. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
