Re: Light Table Playground got a lot more useful.
Is saving supported? Because I have the save option disabled. Juan Manuel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] Nippy, a fast Clojure serializer and drop-in reader replacement
Hey Frank, Thanks for getting in touch! With the tag literal support of 1.4+, is that kind of the idiomatic way of > the future to structure protocols for serialized clojure data/code? > Sorry, could you clarify what you're asking here - I'm not sure if I follow what you mean by "structure protocols"? I'm not familiar with the implementation details of the tagged literal support btw, so someone else should probably chime in if that's the domain. When you say that Nippy is much faster than the reader, are there ways to > improve on or optimize the reader? > (guess the speed improvement is only achieved for true data (?)) > Well again not knowing much about the particular implementation, my general inclination would be to say that the reader's performance doesn't seem especially bad given all that it's doing and its flexibility. Optimizing it for speed at this point is, I'd guess, a low priority. Though I'm curious to see what impact if any Datomic will have on Clojure core, since I'm assuming they're likely to start butting into some of these performance edge-cases eventually. Naturally, these things are a trade-off. The Java serialization libs are a good example of this: each brings its own particular opinion about the correct simplicity/flexibility/speed balance. Given that context, it probably makes sense to let the reader focus on simplicity+flexibility, and to outsource to a lib when you (really+rarely) need the extra speed and where you have a knob to choose how much flexibility you're prepared to give up. Not sure what you mean by "true data" btw, so it's possible I've completely missed what you're getting at ^^ -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] ClojureC - A Clojure to C compiler - Work in Progress
Man- the day there's a mature, production-ready C(something) compiler, I'm going to flip out. Can't wait. Thank you for working on this! -- 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
Parsing SGML
Dear all,
I am running into problems when I try to parse SGML documents [0] that are
valid XML apart from the fact that they lack a root tag. The whole issue is
complicated by the fact that the input files are pretty large (i.e. 9.1 GB
gzipped files) and that I therefore cannot read them completely into memory.
My goal is to extract each "document" and index it using Lucene, so I need
access to the data at one point, but can throw it away immediately after
processing.
The input data looks something like [1] and my main problem is that none of
the parsers I tried cope with the missing root tag. The main problem is
that if the SGML is parsed with either clj-tagsoup's [3] parse-xml or
data.xml's [4] parse function I get a broken representation and can't extract
all
data using either zippers (e.g. like in [5]) or by working on the parsed data
directly (as in [6]).
The main problem is that the *first* is (wrongly) assumed to be the root
tag for the entire document and that the result of the parse looks something
like [7] (for tagsoup) or [8] (for data.xml). As you can imagine I want output
such as from my (hypothetical) processing function:
(documents-from-gigaword-file (-> in-file
(io/input-stream)
(GZIPInputStream.
({:id "AFP_ENG_20101220.0219"
:type "story"
:headline "Headline 1"
:paragraphs ("Paragraph 1" "Paragraph 2")}
{:id "AFP_ENG_20101220.0235"
:type "story"
:headline "Headline 2"
:text ("Paragraph 3")})
But I get the follwing right now: (no wonder!)
user=> (clojure.pprint/pprint (gw-file->documents (io/file
"/home/babilen/foo.gz")))
({:id "AFP_ENG_20101206.0235",
:type "story",
:headline " Headline 2 ",
:paragraphs (" Paragraph 3 ")})
I am, however, unsure how to proceed. I tried wrapping the input stream in
" ... " [10] but that requires me to read the entire file into memory
and I get OutOfMemory errors when working on the complete corpus. So in short
my questions are:
* Do you know a parser that I can use to parse this data?
* Lacking that: How can I wrap the GZIPInputStream in opening and closing
tags?
* Do you think that I should just write a parser myself? (seems a lot of work
just because the enclosing tags are missing)
* Are there other feasible approaches?
Any input would be most appreciated!
References
--
[0] The input data is the English gigaword corpus from
http://www.ldc.upenn.edu/Catalog/catalogEntry.jsp?catalogId=LDC2011T07
[1] Example data:
Headline 1
Location, Dec 20, 2010 (AFP)
Paragraph 1
Paragraph 2
Headline 2
Location, Dec 6, 2010 (AFP)
Paragraph 3
[3]
https://github.com/nathell/clj-tagsoup/blob/master/src/pl/danieljanus/tagsoup.clj
[4] https://github.com/clojure/data.xml/
[5] Extraction using a zipper:
(defn gw-file->documents
[in-file]
(let [xml-zipper (zip/xml-zip (parse-gw-file in-file))]
(map (fn [doc]
{:id (dzx/xml1-> doc (dzx/attr :id))
:type (dzx/xml1-> doc (dzx/attr :type))
:headline (dzx/xml1-> doc :HEADLINE dzx/text)
:paragraphs (dzx/xml-> doc :TEXT :p dzx/text)})
(dzx/xml-> xml-zipper :DOC
[6] Example extraction of data on the output of parse(-xml) directly:
I use filter-tag to search for all :DOC's and call process-document for
each.
(defn- filter-tag
[tag xmls]
(filter identity
(for [x xmls
:when (= tag (:tag x))]
x)))
(defn process-document
[doc]
{:id (:id (:attrs doc))
:type (:type (:attrs doc))
:headline (filter-tag :HEADLINE (xml-seq doc))})
[7] Parsing with tagsoup
user=> (clojure.pprint/pprint
(tagsoup/parse-xml
(-> "/home/babilen/foo.gz" (io/file) (io/input-stream) (GZIPInputStream.
{:tag :DOC,
:attrs {:id "AFP_ENG_20101220.0219", :type "story"},
:content
[{:tag :HEADLINE, :attrs nil, :content ["\nHeadline 1\n"]}
{:tag :DATELINE,
:attrs nil,
:content ["\nLocation, Dec 20, 2010 (AFP)\n"]}
{:tag :TEXT,
:attrs nil,
:content
[{:tag :p, :attrs nil, :content ["\nParagraph 1\n"]}
{:tag :p, :attrs nil, :content ["\nParagraph 2\n"]}]}
{:tag :DOC,
:attrs {:id "AFP_ENG_20101206.0235", :type "story"},
:content
[{:tag :HEADLINE, :attrs nil, :content ["\nHeadline 2\n"]}
{:tag :DATELINE,
:attrs nil,
:content ["\nLocation, Dec 6, 2010 (AFP)\n"]}
{:tag :TEXT,
:attrs nil,
:content [{:tag :p, :attrs nil, :content ["\nParagraph 3\n"]}]}]}]}
[8] Parsing with clojure.data.xml/parse
user=> (clojure.pprint/pprint
(clojure.data.xml/parse
(-> "/home/babilen/foo.gz" (io/file) (io/input-stream) (GZIPInputStream.
{:tag :DOC,
:attrs {:id "AFP_ENG_20101220.0219", :type "story"},
:content
({:tag :HEADLINE, :attrs {}, :content ("\nHeadline 1\n")}
{:tag :D
strange lazy behaviour
Hi! Just created this solution for the Number Maze problem on 4clojure: http://www.4clojure.com/problem/106 ( (fn [a b] (letfn [(nummaze [a b len] (cond (= len 0) false (= a b) true (nummaze (* 2 a) b (dec len)) true (and (even? a) (nummaze (quot a 2) b (dec len))) true (nummaze (+ 2 a) b (dec len)) true :else false))] (first (filter #(nummaze a b %) (range 15) ;(first (filter #(nummaze a b %) (range) 9 2) Normally the program returns instantly. The strange thing is that if I uncomment the line with the unrestricted (range) then it churns for minutes but gives the correct answer. So it is evaluated lazily since it gives an answer. Is it a codegen bug or just the effect of chunked sequences? Is so why? Thanks, Andrew -- 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: Creating a custom Closure UI component in Clojurescript
I just hit this issue myself and wrote a macro to make it a bit easier to
extend google-closure provided classes. Here's the code:
(ns move.macros
(:require [cljs.compiler :as compiler]
[cljs.core :as cljs]))
(defmacro goog-extend [type base-type ctor & methods]
`(do
(defn ~type ~@ctor)
(goog/inherits ~type ~base-type)
~@(map
(fn [method]
`(set! (.. ~type -prototype ~(to-property (first method)))
(fn ~@(rest method
methods)))
And here's the macro in action. I'm extending TreeControl so that I can
intercept when the user presses ENTER on an item in the tree:
(ns move.views
(:use-macros [move.macros :only [goog-extend]]
[cljs.core :only [this-as]])
(goog-extend
MyTree goog/ui.tree.TreeControl
([name config]
(this-as this
(goog/base this name config)))
(handleKeyEvent
[e]
(this-as this
(goog/base this "handleKeyEvent" e)
(let [view (.-hiddenView this)]
(when (#{(.-ENTER goog/events.KeyCodes)
(.-MAC_ENTER goog/events.KeyCodes)} (.-keyCode e))
(events/fire [:edit view] (get-selected-index this))
(.preventDefault e))
(defn- make-list-view [name]
(let [config goog/ui.tree.TreeControl.defaultConfig
tree (MyTree. name config)]
tree))
On Sunday, July 1, 2012 9:08:27 PM UTC-4, David Nolen wrote:
>
> On Fri, Jun 29, 2012 at 9:08 AM, Danny O' Connor
> wrote:
> > Hello,
> >
> > I'm trying to build an user interface in Clojurescript using the Google
> > Closure library.
> >
> > It appears that the idiomatic way to use the goog.ui package is to
> create
> > subclasses of goog.ui.Component.
> >
> > Firstly, is this possible in Clojurescript ? This kind of approach
> doesn't
> > appear to work:
> >
> > (defrecord EchoComponent [text]
> >goog.ui.Component
> >(render [] text))
>
> That won't work. You'll need to write CLJS that is equivalent to JS
> for doing what GClosure expects.
>
--
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
Help getting Clojure/Leiningen 2.0 building with LWJGL
Is anybody willing and able to walk me through getting a simple project compiling which correctly manages all the dependencies required by LWJGL [1]? It seems that Leiningen's handling of native dependencies has changed over time and so much of the already scant information on the web is no longer correct or functioning. I'm using the latest prerelease of Leiningen 2.0 as recommended on the download page. Things I've already done: 1. Sticking [org.lwjgl.lwjgl/lwjgl "2.8.4"] in my project.clj which causes this files to be downloaded as expected. 2. Created a directory named "native" in the project root and copied the native library files (*.so, *.dll, etc.) into it. 3. Added :native-path "native" to my project.clj, although I'm not sure this is correct or working the way I expect This allows me to import the parts of the library that don't link against the native libraries, but not those that do. Help please! [1] http://www.lwjgl.org/ -- 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
HTML documentation
Hi! I know I can type (odoc definst) and get the docs for definst. Is there an HTML version of the documentation for all of the functions and macros in the overtone framework? I can't find any. Thanks! -- 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 @ Prague?
Hi guys, I, somehow, missed this thread but I am all up for clojure @ Prague On Thu, Jul 5, 2012 at 7:54 PM, Edward Tsech wrote: > HI Daniel, > > I'm interested in Clojure and I would like to meet some Clojurians in > Prague too! > > Ed > > > On Friday, June 29, 2012 12:21:58 PM UTC+2, Daniel Skarda wrote: >> >> Hi, >> >> are there fellow Clojurians from Prague, Czech Republic using Clojure to >> attack real problems? >> I started with Clojure about three months ago. At the beginning it was >> curious experiment, now it is full time engagement. And you know - >> programming can be fun again :) >> >> Would you like to meet for a beer and discuss Clojure, ClojureScript or >> Datomic? >> >> Cheers, >> Dan >> >> >> -- > 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 > -- :J -- 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
Give sequences it's own structure
It's confusing that the REPL prints out a list structure when it's in fact a sequence: Eg. (seq [1 2 3]) ;=> (1 2 3) People might think it's a list, but it's a sequence (logical list in memory only, not a new data structure). (seq? (seq [1 2 3])) ;=> true (list? (seq [1 2 3])) ;=> false I feel that it would be better if it was printed out in a structure letting people know that it's a sequence so we don't mix list with sequence structures. Perhaps something like: (lazy-seq [1 2 3]) (seq [1 2 3]) or something telling users it's a sequence. Clojure is a great lang since it's focused on simplicity. I feel the way it works currently is adding unnecessary complexity in understanding what sequence really is, and is not. Johnny -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] ClojureC - A Clojure to C compiler - Work in Progress
I would take a look at bigloo and gambit, those implementations produce solid C code from a Scheme base. On 07/09/2012 08:50 AM, Baishampayan Ghose wrote: >> I'm excited to announce ClojureC, an effort to produce a Clojure >> implementation that targets C: >> >> https://github.com/schani/clojurec >> >> My personal goals with this are to be able to write self-contained >> (command-line) Clojure programs that have (essentially) zero start-up time, >> as well as to have a Clojure implementation that plays well with iOS (no >> work on Objective-C bindings has been done so far, but I have plans...). > > This is incredibly exciting! Thanks for the great work, Mark. > > Regards, > BG > -- 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: ClojureC - A Clojure to C compiler - Work in Progress
I think the benefits outweight the negatives, yes it's more pure going straight to LLVM and takes out one more compilation step , but having it translate to C opens up the possibility of it running on any machine architecture that has a C compiler. On Mon, Jul 9, 2012 at 11:40 AM, Paulo Pinto wrote: > > > On Jul 9, 4:11 pm, Mark Probst wrote: > > On Mon, Jul 9, 2012 at 4:05 PM, Paulo Pinto > wrote: > > > A question that I also mentioned on the HN thread, any idea to bypass > > > C and > > > compile directly to native, for example via LLVM? > > > > No particular plans. Why would you prefer that? > > > > Mark > > I would rather not depend on an external C compiler. > > -- > Paulo > > -- > 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: ClojureC - A Clojure to C compiler - Work in Progress
Please don't bypass C! Almost all platforms have some sort of C compiler - it's like javascript for native platforms, instead of the web. With C output, I can probably get it working on iOS (my main work target platform, along with Android) - I had Boehm GC compiled and working sometime ago for iOS - but ran into deadlines at work to continue. C might even be a better platform for Android then the current Java version - though would need to run some startup, cpu and memory benchmarks to determine that. And it might might also be usable for WindowsPhone8 using MSVC++ - but I don't much experience with that platform. However, thanks for your work on this! In the next couple of days, I'll see if I can get it compiling and running under iOS. On Mon, Jul 9, 2012 at 10:11 AM, Mark Probst wrote: > On Mon, Jul 9, 2012 at 4:05 PM, Paulo Pinto > wrote: > > A question that I also mentioned on the HN thread, any idea to bypass > > C and > > compile directly to native, for example via LLVM? > > No particular plans. Why would you prefer that? > > Mark > > -- > 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: critique my code!
On Sun, Jul 8, 2012 at 4:58 PM, William Morgan wrote: > (E.g. surely people don't use the repl with single-line uninformative > error messages... what am I doing wrong?) (pst) ; that is, print stack trace Ivan -- 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
strange behavior with seqs
Hi! It is a second time I post this message, now I will not put a link into it so maybe it will get trough the spam filter... So I have solved the 106. 4clojure problem, the Number Maze, and my solution behaves rather strangely in the Counterclockwise REPL (and similar on 4clojure solution checking). If I run it with the limited (range 15) then all is good. If I run it with (range) then it runs for minutes then finally gives the good answer. So it is lazy evaluation, otherwise it would run forever. Why is that? Is it a codegen bug or a chunked seq problem? ( (fn [a b] (letfn [(nummaze [a b len] (cond (= len 0) false (= a b) true (nummaze (* 2 a) b (dec len)) true (and (even? a) (nummaze (quot a 2) b (dec len))) true (nummaze (+ 2 a) b (dec len)) true :else false))] ;(first (filter #(nummaze a b %) (range 15) (first (filter #(nummaze a b %) (range) 9 2) A related question is that 4clojure executes (for) very slowly, I had to rewrite several good solutions not to time out on checking. Does anybody know why? Thanks, Andrew -- 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
[SemiOT] Using Clojure word into open source project name
Hi people! Is there any recommendation, flow to follow, requirements, to use "Clojure" word in an open source project? Or I can use it without any previous ceremony? Or there is any formal/informal "os-etiquette"? I'm not a lawyer (I understand code! ;-). I want to use the c** word ;-) in one of my project (a simple clojure interpreter, not compiler). TIA Angel "Java" Lopez http://ajlopez.wordpress.com @ajlopez gh:ajlopez -- 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: ClojureC - A Clojure to C compiler - Work in Progress
On Mon, Jul 9, 2012 at 7:03 PM, Adam King wrote: > However, thanks for your work on this! In the next couple of days, I'll > see if I can get it compiling and running under iOS. Wonderful! If you're interested in working on Objective-C interop, let me know - I have a few ideas. Mark -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
ANN Monger 1.1.0
Monger is an idiomatic Clojure MongoDB driver for a more civilized age: with batteries included, sane defaults, solid documentation and excellent performance. 1.1.0 is a small release that includes * A new session store that works well with Friend * Alternative functions for inserting and saving documents that return the document stored and not write result. * Collection names now can be passed in as keywords All the details can be found in the change log: https://github.com/michaelklishin/monger/blob/1.1.x-stable/ChangeLog.md Documentation: http://clojuremongodb.info MK mich...@defprotocol.org signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Give sequences it's own structure
> It's confusing that the REPL prints out a list structure when it's in fact a > sequence: There's really only one key difference between seqs and lists is that lists include a count private field. So the only way that you will ever have a problem in this regard is when doing a count on the data. In the case of seqs the count will be O(n) until it hits a list when suddenly it becomes O(1) and count on lists is always O(1). So just be aware that doing a count on a seq could be slow (or may not be) and there really isn't a problem. Personally I consider lists to be "slightly faster" seqs. In reality seqs are just any object that implements ISeq. So this also includes Cons, LazySeq, PersistentList, KeySeq, ValueSeq, etc. 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
Re: strange lazy behaviour
Andrew Rafas writes: Hi Andrew, > Just created this solution for the Number Maze problem on 4clojure: > http://www.4clojure.com/problem/106 > > ( > (fn [a b] > (letfn [(nummaze [a b len] > (cond >(= len 0) false >(= a b) true >(nummaze (* 2 a) b (dec len)) true >(and (even? a) (nummaze (quot a 2) b (dec len))) true >(nummaze (+ 2 a) b (dec len)) true >:else false))] > (first (filter #(nummaze a b %) (range 15) > ;(first (filter #(nummaze a b %) (range) > 9 2) > > Normally the program returns instantly. The strange thing is that if I > uncomment the line with the unrestricted (range) then it churns for > minutes but gives the correct answer. So it is evaluated lazily since > it gives an answer. > > Is it a codegen bug or just the effect of chunked sequences? Is so why? Seems to be the result of chunked seqs where the first 32 items are realized although you only take one. For i < 20 (nummaze 9 2 i) is fast but it gets costly quite soon. Fogus once posted some de-chunkifying function `seq1` for such use-cases at http://blog.fogus.me/2010/01/22/de-chunkifying-sequences-in-clojure/ Putting his `seq1` around the `(range)` solves the issue here. BTW, in his blog-post he said that one day, there will be an official de-chunkifying in Clojure, but AFAICS there's none right now, right? I think, there are several use-cases like the one above where you know exactly that realization is very costly and should be avoided if not needed. 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: Give sequences it's own structure
Timothy Baldridge writes: >> It's confusing that the REPL prints out a list structure when it's in >> fact a sequence: > > There's really only one key difference between seqs and lists is that > lists include a count private field. That's true for any seq that's not created by calling seq on a list. Lists are their own seqs, i.e., calling seq on a list returns the given list again. --8<---cut here---start->8--- user> (let [l (list 1 2 3) s (seq l)] (identical? l s)) true --8<---cut here---end--->8--- That's because lists implement ISeq directly. 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: Parsing SGML
Wolodja Wentland writes: Hi Wolodja, > valid XML apart from the fact that they lack a root tag. The whole issue is > complicated by the fact that the input files are pretty large (i.e. 9.1 GB > gzipped files) and that I therefore cannot read them completely into > memory. > > I am, however, unsure how to proceed. I tried wrapping the input > stream in " ... " [10] but that requires me to read the > entire file into memory and I get OutOfMemory errors when working on > the complete corpus. So in short my questions are: > > * Do you know a parser that I can use to parse this data? > * Lacking that: How can I wrap the GZIPInputStream in opening and closing > tags? > * Do you think that I should just write a parser myself? (seems a lot of work > just because the enclosing tags are missing) > * Are there other feasible approaches? I think, I'd simply copy the clojure.xml code and adapt it to my needs. Basically, you only have to adapt the handler methods in the proxied org.xml.sax.DefaultHandler to create the structure you want. Since it's a SAX API, it just scans the document sequentially reporting elements and attributes as they appear, and it doesn't need to keep everything in memory and neither do the docs have to be strictly well-formed. Not too pretty, but should be adequate for getting the job done. 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: [ANN] Nippy, a fast Clojure serializer and drop-in reader replacement
If you are serializing data, then using the reader implies serializing to a string (by printing your data) and reading it from a string. It should be obvious that marshalling data to/from strings is neither fast nor small compared to other binary alternatives. Using the reader is nice for certain applications (tagged literals help) and using serializers is necessary for other applications. Nippy looks pretty clean and I like that it doesn't have the baggage of carbonite's dependency on kryo. [I wrote carbonite.] Looking at the code, I would guess that it suffers quite a bit on performance and serialization size based on my experiences with Carbonite. Some key ideas for improvement: 1) buffer reuse - reusing cached ThreadLocal byte[] for converting from data to bytes is a nice trick and made possible in most serialization libs but I don't that's possible in the current code. 2) transients while deserializing collections (in coll-thaw!) - I found this to be the only way to get anywhere close to Java serialization while benchmarking. 3) more efficient primitive writing - this is the main reason I wrapped Kryo - there are lots of well-known tricks for writing chars, ints, etc. Thrift, Protobuff, Kryo, and others have made these pretty standard and they make a huge difference vs the basic DataInputStream serialization. I did a lot of benchmarking vs standard Java serialization (which is supported on all Clojure data types already). Despite its well-known issues, Java serialization is so deeply hacked into the language (some people say Java's greatest design mistake) that it is actually really fast. For small pieces of data, it is incredibly bloated, but for larger graphs, that actually amortizes out a bit if you have repeated object references. I found the use of transients in deserializing collections to be the only way I could get anywhere close to Java serialization performance - they are critical. The resulting data is definitely smaller, especially on smaller amounts of data, and for our uses that's actually really important so it was still a win overall. The other major issue that drove the creation of carbonite was that Java serialization of LazySeqs could easily blow the stack by pushing every cons serialization onto the stack. This is a trivial issue to solve in any Clojure-aware serializer. For that reason alone, we needed a better solution. If you want to steal ideas from Carbonite, please feel free. :) https://github.com/revelytix/carbonite 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: Help getting Clojure/Leiningen 2.0 building with LWJGL
On Sunday, July 8, 2012 7:26:05 PM UTC-7, Karl Smeltzer wrote: > > > 3. Added :native-path "native" to my project.clj, although I'm not sure > this is correct or working the way I expect > > Have a look at this, http://stackoverflow.com/questions/10558795/using-lwjgl-in-leiningen-clojure -- 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
ClojureScript compiler generates incorrect javascript code for protocol function
Hi,
The javascript code generated for the following clojurescript is wrong. The
problem is, if the protocol name is hyphenated, the generated name is
treating that as an arithmetic expression rather than translating the
hyphen to underscore. The git tag of clojurescript is r1443.
I am not very familiar with the compiler source to locate the root cause.
Can somebody point me in the right direction to fix this?
== cljs =
(ns bug)
(defprotocol foo-bar-p
(qux[this])
(baaz [this a]))
(defrecord foo-bar []
foo-bar-p
(qux [this] "qux")
(baaz [this a]
(qux this)))
== javascript ===
bug.foo_bar.prototype.bug$foo_bar_p$qux$arity$1 = function() {
return"qux"
};
bug.foo_bar.prototype.bug$foo_bar_p$baaz$arity$2 = function(a) {
return a.bug$foo - bar - p$qux$arity$1(a)
};
--
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 compiler generates incorrect javascript code for protocol function
On Tue, Jul 10, 2012 at 12:23 PM, Praki wrote:
> Hi,
>
> The javascript code generated for the following clojurescript is wrong. The
> problem is, if the protocol name is hyphenated, the generated name is
> treating that as an arithmetic expression rather than translating the hyphen
> to underscore. The git tag of clojurescript is r1443.
>
> I am not very familiar with the compiler source to locate the root cause.
> Can somebody point me in the right direction to fix this?
>
>
> == cljs =
> (ns bug)
>
> (defprotocol foo-bar-p
> (qux[this])
> (baaz [this a]))
>
> (defrecord foo-bar []
> foo-bar-p
> (qux [this] "qux")
> (baaz [this a]
> (qux this)))
>
> == javascript ===
> bug.foo_bar.prototype.bug$foo_bar_p$qux$arity$1 = function() {
> return"qux"
> };
> bug.foo_bar.prototype.bug$foo_bar_p$baaz$arity$2 = function(a) {
> return a.bug$foo - bar - p$qux$arity$1(a)
> };
Thanks for the report:
http://dev.clojure.org/jira/browse/CLJS-336
Patch welcome!
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: [ANN] Nippy, a fast Clojure serializer and drop-in reader replacement
Hi Alex, Thanks for your input (and all your work on Carbonite)- much appreciated! 1) buffer reuse - reusing cached ThreadLocal byte[] for converting from > data to bytes is a nice trick and made possible in most serialization libs > but I don't that's possible in the current code. > I experimented with a number of different buffering approaches, including a reusable ByteBuffer. Didn't see as big of a performance boost as I was expecting, so elected to keep it simple for the moment. It's very possible I missed something or tested incorrectly: I'll certainly check out your approach! > 2) transients while deserializing collections (in coll-thaw!) - I found > this to be the only way to get anywhere close to Java serialization while > benchmarking. > I'm relying on `into` when possible, which is using transients under-the-hood. The notable exception is for maps - but that was because the only approaches I could think of that'd allow transients actually turned out to be slower in practice due to other overhead. A transient-based zipmap was the best perf I could get, but it was only ~10% faster and it incurred some other effects I didn't like. 3) more efficient primitive writing - this is the main reason I wrapped > Kryo - there are lots of well-known tricks for writing chars, ints, etc. > Thrift, Protobuff, Kryo, and others have made these pretty standard and > they make a huge difference vs the basic DataInputStream serialization. > This I'm completely unfamiliar with and it sounds interesting: I'll definitely check it out as well, thank you! > I found the use of transients in deserializing collections to be the only > way I could get anywhere close to Java serialization performance - they are > critical. > To be honest, performance for Nippy was actually a relatively low priority for me since in its current/obvious form, it's already fast enough that it ceases to be the bottleneck in any practical contexts in which I would be using it (mostly DB-related). That's to say, I haven't spent an awful lot of effort tweaking for performance and there's probably lots of low-hanging fruit. I'll start by checking out what you've suggested, and I'm very open to input if you (or anyone else) thinks of other ideas! Cheers! -- 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
Hiring clojure/haskell developer
Hello. My company is looking to hire a haskell/clojure developer. South California (San Dimas), full time job, local only (no telecommute) We use yesod (haskell web framework) for internal web application and web services, and compojure (clojure web framework) for customer facing web site. All development will be ether with haskell (if libraries permit) or clojure on JVM. If interested please contact me. Regards, Vagif Verdi -- 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: ClojureC - A Clojure to C compiler - Work in Progress
Hi Mark: I've spent a couple of hours on this - and have run into a snag. I've got libgc compiling/linking with arm iOS and the Xcode project compiles cljc.c fine. The problem is glib. From what I've read, iOS can not use glib as it must be statically linked into the app - but the LGPL doesn't allow that (at least from what I've read). Currently, there only seems to be about 7 methods that you're using that need it - 6 of which at utf8 related. So, I'm thinking that I'll make a 'prepreamble.m' and use NSString's utf8/unichar support for simulating those methods. But before I spend time on that, any comments or ideas? For g_file_get_contents(), I can probably use [NSString stringWithContentsOfFile:encoding:error]. Here's the current output from Xcode when it gets to linking: Undefined symbols for architecture armv7: "_g_unichar_to_utf8", referenced from: _make_string_from_unichar in cljc.o "_g_utf8_get_char", referenced from: _FN_G__36475 in cljc.o "_g_utf8_skip", referenced from: _FN_G__36582 in cljc.o "_g_utf8_strchr", referenced from: _strchr_offset in cljc.o "_g_utf8_strlen", referenced from: _FN_G__36477 in cljc.o "_g_utf8_offset_to_pointer", referenced from: _FN_G__36475 in cljc.o "_g_strdup", referenced from: _FN_G__36582 in cljc.o "_g_file_get_contents", referenced from: _slurp_file in cljc.o "_g_strndup", referenced from: _FN_G__36582 in cljc.o "_g_strdup_printf", referenced from: _FN_G__36452 in cljc.o ld: symbol(s) not found for architecture armv7 clang: error: linker command failed with exit code 1 (use -v to see invocation) On Tue, Jul 10, 2012 at 9:20 AM, Mark Probst wrote: > On Mon, Jul 9, 2012 at 7:03 PM, Adam King wrote: > > However, thanks for your work on this! In the next couple of days, > I'll > > see if I can get it compiling and running under iOS. > > Wonderful! > > If you're interested in working on Objective-C interop, let me know - > I have a few ideas. > > Mark > > -- > 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: ClojureC - A Clojure to C compiler - Work in Progress
> Please don't bypass C! Almost all platforms have some sort of C compiler - > it's like javascript for native platforms, instead of the web. With C > output, I can probably get it working on iOS The same is true for LLVM. There's no reason why LLVM can't target iOS. 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
Re: ClojureC - A Clojure to C compiler - Work in Progress
On Tue, Jul 10, 2012 at 2:09 PM, Timothy Baldridge wrote: > > Please don't bypass C! Almost all platforms have some sort of C > compiler - it's like javascript for native platforms, instead of the web. > With C output, I can probably get it working on iOS > > The same is true for LLVM. There's no reason why LLVM can't target iOS. > Right - but what about Android NDK and Win8RT (mobile and 'Surface')? I build for native Android almost every day and NDK-r8 is currently at gcc 4.4.3. After a quick google search, there doesn't appear to be a LLVM compiler for Android (other than "it's possible, but not easy"). And then what about Microsoft? ClojureCLR on Win8RT might be a possibility - but can LLVM compile to that platform? And other, less common embedded systems might not have great support for the latest llvm. I also don't know much about LLVM, other than using clang++ for iOS work - so maybe it is all possible with enough time and money.. *shrug* I'll keep at getting iOS/AndroidNDK working as that is what interests me. LLVM does look cool though :) Adam > 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 > -- 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: Help getting Clojure/Leiningen 2.0 building with LWJGL
On Tue, Jul 10, 2012 at 8:36 AM, George Oliver wrote: > > > On Sunday, July 8, 2012 7:26:05 PM UTC-7, Karl Smeltzer wrote: >> >> >> 3. Added :native-path "native" to my project.clj, although I'm not sure >> this is correct or working the way I expect >> >> > > Have a look at this, > > > http://stackoverflow.com/questions/10558795/using-lwjgl-in-leiningen-clojure > > Thanks -- that clears up some of what I've been facing. Unfortunately the :native-dependencies suggestion still didn't work for me, but I was able to piece together a working solution from the information provided. By modifying java.library.path using :jvm-opts, I am able to get things building as desired and modifying LD_LIBRARY_PATH in a launch script sorts out all remaining issues. -- 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: Parsing SGML
Just create a Reader over the file, and do something like (take-while
identity (repeatedly #(read-one-wellformed-xml-tag the-reader))). It needs
some fleshing out for boundary conditions, but I hope you get the general
idea.
On Tuesday, July 10, 2012 6:04:23 AM UTC-7, Wolodja Wentland wrote:
>
> Dear all,
>
> I am running into problems when I try to parse SGML documents [0] that are
> valid XML apart from the fact that they lack a root tag. The whole issue
> is
> complicated by the fact that the input files are pretty large (i.e. 9.1 GB
> gzipped files) and that I therefore cannot read them completely into
> memory.
> My goal is to extract each "document" and index it using Lucene, so I need
> access to the data at one point, but can throw it away immediately after
> processing.
>
> The input data looks something like [1] and my main problem is that none
> of
> the parsers I tried cope with the missing root tag. The main problem is
> that if the SGML is parsed with either clj-tagsoup's [3] parse-xml or
> data.xml's [4] parse function I get a broken representation and can't
> extract all
> data using either zippers (e.g. like in [5]) or by working on the parsed
> data
> directly (as in [6]).
>
> The main problem is that the *first* is (wrongly) assumed to be the
> root
> tag for the entire document and that the result of the parse looks
> something
> like [7] (for tagsoup) or [8] (for data.xml). As you can imagine I want
> output
> such as from my (hypothetical) processing function:
>
> (documents-from-gigaword-file (-> in-file
> (io/input-stream)
> (GZIPInputStream.
> ({:id "AFP_ENG_20101220.0219"
> :type "story"
> :headline "Headline 1"
> :paragraphs ("Paragraph 1" "Paragraph 2")}
>
> {:id "AFP_ENG_20101220.0235"
> :type "story"
> :headline "Headline 2"
> :text ("Paragraph 3")})
>
> But I get the follwing right now: (no wonder!)
>
> user=> (clojure.pprint/pprint (gw-file->documents (io/file
> "/home/babilen/foo.gz")))
> ({:id "AFP_ENG_20101206.0235",
> :type "story",
> :headline " Headline 2 ",
> :paragraphs (" Paragraph 3 ")})
>
>
> I am, however, unsure how to proceed. I tried wrapping the input stream in
> " ... " [10] but that requires me to read the entire file into
> memory
> and I get OutOfMemory errors when working on the complete corpus. So in
> short
> my questions are:
>
> * Do you know a parser that I can use to parse this data?
> * Lacking that: How can I wrap the GZIPInputStream in opening and closing
> tags?
> * Do you think that I should just write a parser myself? (seems a lot of
> work
> just because the enclosing tags are missing)
> * Are there other feasible approaches?
>
> Any input would be most appreciated!
>
> References
> --
>
> [0] The input data is the English gigaword corpus from
> http://www.ldc.upenn.edu/Catalog/catalogEntry.jsp?catalogId=LDC2011T07
>
> [1] Example data:
>
>
>
> Headline 1
>
>
> Location, Dec 20, 2010 (AFP)
>
>
>
> Paragraph 1
>
>
> Paragraph 2
>
>
>
>
>
> Headline 2
>
>
> Location, Dec 6, 2010 (AFP)
>
>
>
> Paragraph 3
>
>
>
>
> [3]
> https://github.com/nathell/clj-tagsoup/blob/master/src/pl/danieljanus/tagsoup.clj
>
> [4] https://github.com/clojure/data.xml/
> [5] Extraction using a zipper:
> (defn gw-file->documents
> [in-file]
> (let [xml-zipper (zip/xml-zip (parse-gw-file in-file))]
> (map (fn [doc]
> {:id (dzx/xml1-> doc (dzx/attr :id))
> :type (dzx/xml1-> doc (dzx/attr :type))
> :headline (dzx/xml1-> doc :HEADLINE dzx/text)
> :paragraphs (dzx/xml-> doc :TEXT :p dzx/text)})
>(dzx/xml-> xml-zipper :DOC
> [6] Example extraction of data on the output of parse(-xml) directly:
> I use filter-tag to search for all :DOC's and call process-document
> for
> each.
>
> (defn- filter-tag
> [tag xmls]
> (filter identity
> (for [x xmls
> :when (= tag (:tag x))]
> x)))
>
> (defn process-document
> [doc]
> {:id (:id (:attrs doc))
>:type (:type (:attrs doc))
>:headline (filter-tag :HEADLINE (xml-seq doc))})
> [7] Parsing with tagsoup
>
> user=> (clojure.pprint/pprint
> (tagsoup/parse-xml
>(-> "/home/babilen/foo.gz" (io/file) (io/input-stream)
> (GZIPInputStream.
> {:tag :DOC,
> :attrs {:id "AFP_ENG_20101220.0219", :type "story"},
> :content
> [{:tag :HEADLINE, :attrs nil, :content ["\nHeadline 1\n"]}
> {:tag :DATELINE,
>:attrs nil,
>:content ["\nLocation, Dec 20, 2010 (AFP)\n"]}
> {:tag :TEXT,
>:attrs nil,
>:content
>[{:tag :p, :attrs nil, :content ["\nParagraph 1\n"]}
>
Re: ClojureC - A Clojure to C compiler - Work in Progress
Hey Adam, > I've spent a couple of hours on this - and have run into a snag. I've got > libgc compiling/linking with arm iOS and the Xcode project compiles cljc.c > fine. The problem is glib. From what I've read, iOS can not use glib as it > must be statically linked into the app - but the LGPL doesn't allow that (at > least from what I've read). Currently, there only seems to be about 7 > methods that you're using that need it - 6 of which at utf8 related. So, > I'm thinking that I'll make a 'prepreamble.m' and use NSString's > utf8/unichar support for simulating those methods. But before I spend time > on that, any comments or ideas? For g_file_get_contents(), I can probably > use [NSString stringWithContentsOfFile:encoding:error]. I see the problem. My guess is that on iOS we'd use NSString anyway, even if we use glib2 or whatever else for command-line programs. One problem here is that you cannot allocate NSString's from Boehm, so you'd have to use finalizers to make sure the NSString's are released when the corresponding Clojure objects are collected. See GC_register_finalizer in Boehm's gc.h. Late on we'll have proper Objective-C bindings, so the glueing will become much easier. Mark -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: [ANN] ClojureC - A Clojure to C compiler - Work in Progress
Looks like a lot of people are excited about this. For the specific purpose of cocoa apps, can someone explain how this is better/different than the other approaches? There are at least 3 other projects that promise some kind of c/objective-c interop, https://github.com/takeoutweight/clojure-scheme, https://github.com/raph-amiard/clojurescript-lua, https://github.com/jspahrsummers/cocoa-clojure So it would be interesting to know what the pros and cons are (again, for the case making cocoa apps) On Mon, Jul 9, 2012 at 7:03 AM, Mark Probst wrote: > Dear Clojurians, > > I'm excited to announce ClojureC, an effort to produce a Clojure > implementation that targets C: > > https://github.com/schani/clojurec > > My personal goals with this are to be able to write self-contained > (command-line) Clojure programs that have (essentially) zero start-up time, > as well as to have a Clojure implementation that plays well with iOS (no > work on Objective-C bindings has been done so far, but I have plans...). > > So far the best overview of how far along ClojureC is is the test suite: > > https://github.com/schani/clojurec/blob/master/test/clojurec/core_test.clj > > as well as cljc.core: > > https://github.com/schani/clojurec/blob/master/src/cljc/cljc/core.cljc > > The ClojureC compiler as well as core.cljc are adapted versions of > ClojureScript's code. I intend to unify the compiler with ClojureScript's > again, once things have settled. > > Collaborators are very much welcome! > > Cheers! > > Mark > > PS: I'm "schani" on IRC. > > -- > 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
Implemented isa? as a protocol, makes multimethods more open
Hi, everybody. I reimplemented the function isa? in terms of a protocol Is-A. The reason why you would want to do that is in the README at https://github.com/leifp/clj-isa-protocol tl;dr: One of the reasons why people are excited about predicate dispatch is the irritation caused by the dispatch function of a multimethod being closed. You have to decide up front what information the dispatch fn is going to pull out of your arguments. Changing it afterward is a pain. Since the dispatch uses 'isa?' internally, if that function is extensible, then multimethod dispatch becomes, to a certain extent, open. See the README. Comments, critique, code, and questions welcome. Cheers, Leif P.S. As an aside to people that like weird, obscure programming languages, the rough idea of how is-a? should work for maps was inspired by (but very much simpler than) the functional logic language LIFE [ http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.90.3175 ] -- 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: Implemented isa? as a protocol, makes multimethods more open
This is cool :)
It reminds me of subtyping between maps in Typed Clojure, where
{:a 1, :b 2} <: {:a Number}
Thanks,
Ambrose
On Wed, Jul 11, 2012 at 2:16 PM, Leif wrote:
> Hi, everybody. I reimplemented the function isa? in terms of a protocol
> Is-A.
>
> The reason why you would want to do that is in the README at
> https://github.com/leifp/clj-isa-protocol
>
> tl;dr: One of the reasons why people are excited about predicate dispatch
> is the irritation caused by the dispatch function of a multimethod being
> closed. You have to decide up front what information the dispatch fn is
> going to pull out of your arguments. Changing it afterward is a pain.
>
> Since the dispatch uses 'isa?' internally, if that function is extensible,
> then multimethod dispatch becomes, to a certain extent, open. See the
> README.
>
> Comments, critique, code, and questions welcome.
>
> Cheers,
> Leif
>
> P.S. As an aside to people that like weird, obscure programming
> languages, the rough idea of how is-a? should work for maps was inspired by
> (but very much simpler than) the functional logic language LIFE [
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.90.3175 ]
>
> --
> 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: Implemented isa? as a protocol, makes multimethods more open
Thanks!
The similarity is no accident: When you consider it, 'isa?' is a
generalized subtyping relation:
(isa? Double Number) ==> Double <: Number
(isa? ::goat ::animal) ==> ::goat <: ::animal
(isa? 1 x) ==> #{1} <: x, which makes sense if you define the value x to
mean "the set of all things equivalent to x"
Specifically for the keyword case, clojure.core lets you define ad hoc
hierarchies, which you could view as type lattices. This project lets you
define ad hoc type lattice relations.
You might be interested in the papers on LIFE. They define "sorts" for
logic terms (very much like types), and an algorithm for unifying two terms
(which can be quite a bit more complicated than Prolog terms).
On Wednesday, July 11, 2012 2:22:51 AM UTC-4, Ambrose Bonnaire-Sergeant
wrote:
>
> This is cool :)
>
> It reminds me of subtyping between maps in Typed Clojure, where
>
> {:a 1, :b 2} <: {:a Number}
>
> Thanks,
> Ambrose
>
> On Wed, Jul 11, 2012 at 2:16 PM, Leif wrote:
>
>> Hi, everybody. I reimplemented the function isa? in terms of a protocol
>> Is-A.
>>
>> The reason why you would want to do that is in the README at
>> https://github.com/leifp/clj-isa-protocol
>>
>> tl;dr: One of the reasons why people are excited about predicate
>> dispatch is the irritation caused by the dispatch function of a multimethod
>> being closed. You have to decide up front what information the dispatch fn
>> is going to pull out of your arguments. Changing it afterward is a pain.
>>
>> Since the dispatch uses 'isa?' internally, if that function is
>> extensible, then multimethod dispatch becomes, to a certain extent, open.
>> See the README.
>>
>> Comments, critique, code, and questions welcome.
>>
>> Cheers,
>> Leif
>>
>> P.S. As an aside to people that like weird, obscure programming
>> languages, the rough idea of how is-a? should work for maps was inspired by
>> (but very much simpler than) the functional logic language LIFE [
>> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.90.3175 ]
>>
>> --
>> 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
