Re: Closure for object pattern? A good idea?
I feel like you would be better off separating functions from the data they
operate on here. In this case, you could represent the state of a stopwatch
with a map containing the start time and the time elapsed, and have
functions `stop`, `reset`, `start`, etc that take the stopwatch data
structure as an argument and compute an answer or return a new stopwatch
data structure as needed. If you need to share the state of the stopwatch
you can always put that map in an atom when you need to.
This has the additional benefit that you can implement new functions on the
stopwatch without changing the implementation stopwatch data structure
itself, while in the case of the closure you need to change the
implementation of `new-stopwatch` if you want to be able to do anything
else with the stopwatch data - sort of the same rationale for
clojure.core's extensive use of functions that operate on seqs instead of
many specialized data structures.
You don't gain much by storing the state in a closure unless you need to
guarantee that the user of your code can't access it, which with immutable
data structures isn't often necessary.
-Logan
On Saturday, December 10, 2016 at 2:47:34 AM UTC-5, Didier wrote:
>
> I'm wondering what everyone thinks of using closures to mimic a simplistic
> object system in Clojure? I'm not sure what to think of it yet, but the
> idea is that you wrap object fields inside a closed function, and it
> returns a map of methods that operates over those fields.
>
> Here's an example of using this pattern to implement a StopWatch:
>
> (import [java.lang System])
> (defn new-stopwatch []
> (let [start-time (atom nil)
> elapsed (atom 0)]
> {:start (fn []
> (when (nil? @start-time)
> (reset! start-time (System/currentTimeMillis
> :stop (fn []
> (when-not (nil? @start-time)
>(reset! elapsed
>(+ @elapsed
> (- (System/currentTimeMillis) @start-time)))
>(reset! start-time nil))
> @elapsed)
> :reset (fn []
> (reset! start-time nil)
> (reset! elapsed 0)
> @elapsed)
> :elapsed (fn []
> (if-not (nil? @start-time)
> (- (System/currentTimeMillis) @start-time)
> @elapsed))}))
>
> (let [sw1 (new-stopwatch)
> sw2 (new-stopwatch)]
> ((:start sw1))
> ((:start sw2))
> (Thread/sleep 100)
> ((:reset sw1))
> ((:start sw1))
> (println (str "Elapsed for SW1: " ((:elapsed sw1
> (println (str "Elapsed for SW2: " ((:elapsed sw2
> (Thread/sleep 100)
> (println (str "SW1: " ((:stop sw1
> (println (str "SW2: " ((:stop sw2)
>
> I find for certain things, like a stopwatch, this pattern is actually
> pretty nice. I can't think of any alternative way to do this in Clojure
> that I'd like better actually.
>
> What are your thoughts?
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Clojure 1.9.0-alpha10: Semantic mismatch: any? vs not-any?
FWIW, I was not aware of `any?` when I read this thread, and I found its semantics confusing -- I think `anything?` would be much clearer. `anything?` also seems more obviously useful for defining specs (e.g. a function can take _anything_ as an argument). It seems usual in Clojure for scalar predicates such as int?, string?, rational? etc to have noun or adjective names, and collection predicates such as every? to have determiners such as every, some, any as names. Logan On Wednesday, July 13, 2016 at 6:15:14 AM UTC-4, Tassilo Horn wrote: > > Alex Miller > writes: > > Hi Alex, > > > Well, there are only so many words. > > Of course, but I also think that any? is absolutely certain to be > confused with some counterpart to every?. > > > As it happens any? is best name for this function. > > What about "anything?". To me (as a non-native speaker) that sounds > even better to me, i.e., a function foo has an argument whose value > might be anything. > > 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
processing large text files
The JVM on most platforms has good support for memory-mapped files. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: What to use for serializing reference types?
See inline... On Monday, August 11, 2014 3:32:21 PM UTC-7, MS wrote: > > Actually there are several things going on. > In general the database I'm trying to define would include not only the > actual net list (ie a mapping between nets and pins), but also all the PCB > junk that goes on. > > The cyclic graph requires some type of mutability... > I was addressing the serialization of a cyclic structure more than the mutability of cyclic structures. Those are two independent issues. > ...if I want to find the net that belongs to a node and also find the > nodes that belong to a net, but I may have come up with something that > works without mutability, which I described a while ago here: > http://stackoverflow.com/questions/4580865/how-can-one-create-cyclic-and-immutable-data-structures-in-clojure-without-ext/10242730#10242730 > > . I haven't done much with that since I wrote it, so I'm not sure it'll > work well. > Sure, a cyclic graph can be "connected" symbolically using any number of immutable structures of such symbols. The selection of a structure could depend on the required functionality, e.g. if your PCBs might consist of millions of pins, if you want to run discrete simulations, etc. (Having said that, I'm not a fan of immutability for immutability's sake, but this is the Clojure list, and you seem determined, so, I'll assume there's a good reason and let it go at that.) So far I'm overwhelmed at trying to think about how to capture all the > features I've thought of. I guess I just need to start small. > There's something to be said for that. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: What to use for serializing reference types?
Yeah, EDIF is certainly a big, old, consensual standard. It does handle PCBs just fine. I thought it might be worth perusing for useful nuggets and insights rather than an en masse kind of adoption. On Monday, August 11, 2014 3:13:17 PM UTC-7, MS wrote: > > Thanks, I'm roughly familiar with edif, having seen it on occasion in > various previous lifetimes. However I'm trying to get away from Big EDA > companies in genera. Without looking at the format in too much detail, it > seems to want to define how the internal structure of the program would be, > ie how libraries are done, etc.. Also it appears to be mask-based, ie IC > design; I'm trying to do something PCB level.I'll take a look at > JSON-LD. > > > On Sunday, August 10, 2014 6:37:01 PM UTC-7, Patrick Logan wrote: >> >> You'll have to adopt some form of reference designator. JSON-LD defines >> these. More domain specific, you could implement a subset of or borrow >> ideas from EDIF, a standard Electronic Design Interchange Format, which >> happens to be based on Lisp. >> >> http://en.m.wikipedia.org/wiki/EDIF >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: What to use for serializing reference types?
Space is one thing, but I would assume the net list should be able to represent sequential logic, which implies a cyclic graph. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
What to use for serializing reference types?
You'll have to adopt some form of reference designator. JSON-LD defines these. More domain specific, you could implement a subset of or borrow ideas from EDIF, a standard Electronic Design Interchange Format, which happens to be based on Lisp. http://en.m.wikipedia.org/wiki/EDIF -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Developer with clojure wanted in Auckland.
Hi all .. I hope it is OK to post in here. I am looking for a number of Java developers with clojure experience for an exciting start up in Auckland. If you are interested to hear more then please email or call me - cheers, Indiana ilo...@globalattract.co.nz 09 903 0865 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Extend-protocol to numbers fails with zero in CLJS
It will work for 0 if you use `number` instead of `js/Number`. Generally
you shouldn't extend any js/* type
On Friday, June 6, 2014 9:57:38 AM UTC-7, Karsten Schmidt wrote:
>
> I'm trying to extend-protocol for numbers and various other types (incl.
> collections & nil) in CLJS, so have been doing something like this (reduced
> email version):
>
> (defprotocol PDeltaEq (delta= [a b]))
>
> (extend-protocol PDeltaEq
> js/Number
> (delta= [a b] :yay)
>
> nil
> (delta= [_ b] (nil? b)))
>
> (delta= 1 1)
> ;; :yay
>
> (delta= 0 0)
> Error: No protocol method Foo.foo defined for type number: 0
>
> Now I guessed, this might have something to do with JS' considering 0 as
> `false` somewhere in the internal protocol machinery... and I was right!
> Here's a relevant excerpt from the compiled protocol dispatch fn:
>
> var delta_EQ___2 = function(a, b) {
> if (function() {
> var and__3466__auto__ = a;
> if (and__3466__auto__) {
> return a.thi$ng$common$math$core$PDeltaEq$delta_EQ_$arity$2;
> } else {
> return and__3466__auto__;
> }
> }()) {
> return a.thi$ng$common$math$core$PDeltaEq$delta_EQ_$arity$2(a, b);
> } else {
>
> }
> };
>
> Obviously, with the `a` arg being 0, that `if (and__3466__auto__)` check
> is always failing, so shouldn't this check be rewritten as:
>
> if (goog.isDefAndNotNull(and__3466__auto__) &&
> a.thi$ng$common$math$core$PDeltaEquals$delta_EQ_$arity$2) {
> return a.thi$ng$common$math$core$PDeltaEquals$delta_EQ_$arity$2;
> }
> ...
>
> This change seems to fix this kind of error and AFAIK doesn't impact any
> of my other (30+) test cases for this protocol...
>
> Thoughts? :)
>
> Thanks, K.
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [ANN] JSON/CLJ/EDN comparison table
All things being equal, I would prefer a Lisp-based format rather than JSON, yes. (My involvement with that approach goes back 25 years: https://en.wikipedia.org/wiki/Electronic_Design_Interchange_Format ) But EDN + this convention would be something only my software would support, and anyone I could convince. JSON-LD is a fairly simple standard, already has a good and growing level of support, and because it is "just JSON" can be used directly by a lot of software without any awareness of the LD aspect. Everything is a compromise. Pro's and con's all around. On Sunday, June 1, 2014 12:04:50 AM UTC-7, Jozef Wagner wrote: > > How about format which can represent either graph or structure, depending > on users needs? I would argue that EDN is more suitable for linked data > than JSON is. Its support for identifiers and tagged elements allows for > pretty straightforward serialization of linked data. See > https://gist.github.com/wagjo/d6419a289a64c503010c > <https://www.google.com/url?q=https%3A%2F%2Fgist.github.com%2Fwagjo%2Fd6419a289a64c503010c&sa=D&sntz=1&usg=AFQjCNH4biGF4OXzCJVVQ4AUHE_H_srSJg> > > for one possible approach. > > Jozef > > On Sunday, June 1, 2014 2:18:00 AM UTC+2, Patrick Logan wrote: >> >> Now *that* is a pretty reasonable comparison. I would quibble here and >> there: I don't find JSON-LD as heavy-weight as you; the benefit of >> universal identifiers is an advantage in the domains I work in; and the >> whole graph vs. struct debate... it's a lot easier to represent a struct as >> a simple graph than it is to represent a graph as "structs + conventions", >> etc. But those are all needs-based trade-offs. The comparison is fair. >> >> >> On Saturday, May 31, 2014 3:45:24 PM UTC-7, Jozef Wagner wrote: >>> >>> Well the suggestion to consider JSON-LD was really out of place. >>> Compared to JSON-LD, EDN belongs to the category of lightweight, schemaless >>> and streaming friendly data serialization formats. JSON-LD is closer to >>> e.g. Turtle or RDF/XML. It serves a different purpose and has different >>> goals than EDN. >>> >>> JSON-LD is a representation of labeled, directed graph of nodes [1]. The >>> smallest thing you can represent in it is a graph of nodes. You may make >>> analogy between IRI [2] node and EDN map, but note that in JSON-LD, every >>> property must be a valid IRI. >>> >>> Besides other IRI nodes as a property values, JSON-LD supports integers, >>> floats, strings, booleans and custom types through typed values, which is >>> something like edn tagged elements but can be only applied to string >>> values. >>> >>> JSON-LD has no built in support for nils and characters, and no support >>> for random-access vectors. JSON-LD has a concept of unordered and >>> ordered collections (which is an improvement compared to RDF [3]), which >>> corresponds to EDN set and list types. >>> >>> While the motivation behind JSON-LD is to be a simple Microdata/RDFa >>> alternative for web services, over engineered technologies lurks underneath >>> and they sometimes leak through the JSON-LD facade. I'm pessimistic that it >>> will slip (again) into unnecessary complex ontologies and rigid schemas no >>> one wants to use. >>> >>> [1] http://www.w3.org/TR/json-ld/#data-model-overview >>> [2] http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-iri >>> [3] see section 'Decision 3' at >>> http://manu.sporny.org/2014/json-ld-origins-2/ >>> >>> Jozef >>> >>> On Saturday, May 31, 2014 5:32:55 PM UTC+2, Patrick Logan wrote: >>>> >>>> Brilliant analysis. >>> >>> -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] JSON/CLJ/EDN comparison table
Now *that* is a pretty reasonable comparison. I would quibble here and there: I don't find JSON-LD as heavy-weight as you; the benefit of universal identifiers is an advantage in the domains I work in; and the whole graph vs. struct debate... it's a lot easier to represent a struct as a simple graph than it is to represent a graph as "structs + conventions", etc. But those are all needs-based trade-offs. The comparison is fair. On Saturday, May 31, 2014 3:45:24 PM UTC-7, Jozef Wagner wrote: > > Well the suggestion to consider JSON-LD was really out of place. Compared > to JSON-LD, EDN belongs to the category of lightweight, schemaless and > streaming friendly data serialization formats. JSON-LD is closer to e.g. > Turtle or RDF/XML. It serves a different purpose and has different goals > than EDN. > > JSON-LD is a representation of labeled, directed graph of nodes [1]. The > smallest thing you can represent in it is a graph of nodes. You may make > analogy between IRI [2] node and EDN map, but note that in JSON-LD, every > property must be a valid IRI. > > Besides other IRI nodes as a property values, JSON-LD supports integers, > floats, strings, booleans and custom types through typed values, which is > something like edn tagged elements but can be only applied to string > values. > > JSON-LD has no built in support for nils and characters, and no support > for random-access vectors. JSON-LD has a concept of unordered and ordered > collections (which is an improvement compared to RDF [3]), which > corresponds to EDN set and list types. > > While the motivation behind JSON-LD is to be a simple Microdata/RDFa > alternative for web services, over engineered technologies lurks underneath > and they sometimes leak through the JSON-LD facade. I'm pessimistic that it > will slip (again) into unnecessary complex ontologies and rigid schemas no > one wants to use. > > [1] http://www.w3.org/TR/json-ld/#data-model-overview > [2] http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-iri > [3] see section 'Decision 3' at > http://manu.sporny.org/2014/json-ld-origins-2/ > > Jozef > > On Saturday, May 31, 2014 5:32:55 PM UTC+2, Patrick Logan wrote: >> >> Brilliant analysis. > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] JSON/CLJ/EDN comparison table
Brilliant analysis. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] JSON/CLJ/EDN comparison table
Jozef, You might be interested in the JSON-LD w3c standard which defines representations for most of the items in your table using JSON. Primarily missing are "discards" and direct ties to clojure/script functions and macros. JSON-LD has several implementations, a test suite, and support of search engines, and other systems, from google, microsoft, yahoo, etc. For example, they provide JSON-LD examples of all the semi-structured data on http://schema.org/docs/full.html along with a standard script tag for including that data within HTML. http://www.w3.org/TR/json-ld/ http://json-ld.org/ On Friday, May 30, 2014 5:25:05 AM UTC-7, Jozef Wagner wrote: > > I've put together a table comparing JSON, EDN and CLJ formats based on > their specs [1]. Pull requests are welcome. > > Jozef > > [1] https://github.com/wagjo/serialization-formats > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: core.async over websocket + cljs + clojure
This seems like more trouble than it is worth. There are almost certainly suitable but more established protocols and implementations for the problem at hand. Anyway, maybe it's worth exploring. To me it seems to muddy the waters for what core.async seems intended to provide, which seems to me to be fairly straight-forward CSP. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: core.async over websocket + cljs + clojure
In CSP you might have a limited size buffer, but then block on the next Put. That's not something you want to casually attempt over a distance. It seems you want an interface like Channels that deal in fully formed objects, but you don't want CSP blocking semantics. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: core.async over websocket + cljs + clojure
> > To be reliable you'd have to introduce addition machinery to account for > the hazards of distributed systems, so you're probably better off starting > with an abstraction that has those hazards in mind already. The WebSocket (protocol) is the machinery that's handling this. We aren't discussing using CSP to implement the actual network communication. We aren't concerned what happens outside of the edges of the system. Unlike when using actors, with CSP you don't care where a value you took from a channel came from, and similarly you don't care where the value you put onto a channel goes. The channel is only a primitive for conveyance. The application knows nothing of a WebSocket other than what does the put!s and take!s. CSP-like channels aren't a good across-the-wire abstraction. Their blocking > semantics are intended to coordinate concurrency within a single runtime. Coordination is possible through the blocking semantics of CSP, but isn't the only mechanism it provides. CSP also facilitates buffered, asynchronous operations. I don't see why it would imply anything about a single runtime. On Friday, January 24, 2014 4:45:01 PM UTC-8, Patrick Logan wrote: > > * one side of the channel is in clojure land > * other side of the channel is in cljs land > > Are you implementing coordination across the wire, as if the two channels > are "the same virtual channel"? If so, read on... otherwise, n/m, sorry if > I misinterpreted... > > CSP-like channels aren't a good across-the-wire abstraction. Their > blocking semantics are intended to coordinate concurrency within a single > runtime. > > To be reliable you'd have to introduce addition machinery to account for > the hazards of distributed systems, so you're probably better off starting > with an abstraction that has those hazards in mind already. > > I'm unsure what the arguments would be in favor of CSP-like behavior > across distances, especially between a server (clj) and a browser (cljs)? > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: core.async over websocket + cljs + clojure
* one side of the channel is in clojure land * other side of the channel is in cljs land Are you implementing coordination across the wire, as if the two channels are "the same virtual channel"? If so, read on... otherwise, n/m, sorry if I misinterpreted... CSP-like channels aren't a good across-the-wire abstraction. Their blocking semantics are intended to coordinate concurrency within a single runtime. To be reliable you'd have to introduce addition machinery to account for the hazards of distributed systems, so you're probably better off starting with an abstraction that has those hazards in mind already. I'm unsure what the arguments would be in favor of CSP-like behavior across distances, especially between a server (clj) and a browser (cljs)? -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: core.async over websocket + cljs + clojure
I've been working on a game in my spare time that does this. The Clojure backend and ClojureScript client communicate with core.async over WebSocket carrying edn data Game: https://github.com/loganlinn/ji Client WebSocket using: https://github.com/loganlinn/cljs-websockets-async Server WebSocket using: https://github.com/lynaghk/jetty7-websockets-async I had hoped to have writeup about this technique by now, but coding seems to take higher priority when I get free time :P On Wednesday, January 22, 2014 11:39:06 PM UTC-8, t x wrote: > > Hi, > > I apologize for my vague question. > > Does anyone have a good example / blog / library for using the > core.async abstraction across a websocket. > > * one side of the channel is in clojure land > * other side of the channel is in cljs land > > * I promise that all messages can be encoded via pr-str and read via > clojure.edn/read-string > > What I'm struggling with are matters of: > > * how to ensure data is not lost even when websocket disconects / > reconnects > > * "naming" on client/server side to ensure messages go to right channels > on both sides > > * issues I haven't even begun to imagine. > > Good news: > > * I control both sides: both the clj and cljs side, so any workable > design is fine. > > 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: oob schemas, re: The Language of the System
"finds dates, and other data types, heuristically" -- I'm sure Google would rather not, but that's life on the web. Google also supports JSON-LD which is a W3 standard for semi-structured and linked data. JSON-LD defines "in-band" syntax for dates, all XSD data types, and arbitrary data types (including but not exclusively those defined at http://schema.org/docs/full.html ) On Saturday, January 18, 2014 12:00:09 PM UTC-8, Brian Craft wrote: > > Regarding Rich's talk (http://www.youtube.com/watch?v=ROor6_NGIWU), can > anyone explain the points he's trying to make about self-describing and > extensible data formats, with the JSON and google examples? > > He argues that google couldn't exist if the web depended on out-of-band > schemas. He gives as an example of such a schema a JSON encoding where an > out-of-band agreement is made that field names with substring "date" refer > to string-encoded dates. > > However, this is exactly the sort of thing google does. It finds dates, > and other data types, heuristically, and not through the formats of the web > being self-describing or extensible. > > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN]: Clojure/West 2014 - San Francisco - March 24-26
This was great news to hear. Looking forward to it. Talks will be presented in two tracks Does this mean there will be two stages/presentations at a time? On Thursday, January 9, 2014 8:01:13 PM UTC-8, Alex Miller wrote: > > At long last, we have finalized the plans for Clojure/West 2014! > > Site: http://clojurewest.org > Date: March 24-25 conference, March 26 hackfest! > Venue: Palace Hotel, San Francisco > http://www.sfpalace.com/ > https://goo.gl/maps/pBXav > > Call for Presentations: > - > https://cognitect.wufoo.com/forms/clojurewest-2014-call-for-presentations/ > - Open from now till Jan 24th (yes, that's soon!) > - Speakers receive: free admission, up to 3 nights hotel, US airfare or > $450 stipend if international > - Tracks (sessions are 40 minutes): > 1) Core Clojure - Talks that focus on core usage of Clojure or > ClojureScript, focused mostly (but not exclusively) on the less experienced > Clojure developer. Examples: language features, techniques, libraries, > tools. > 2) Production Clojure - Talks from and for those doing Clojure or > ClojureScript in production systems or products. Examples: integrating with > existing code bases, creating and communicating designs, structuring your > code, performance, management and organization. > 3) Crazy Clojure - Talks from those probing the boundaries of Clojure or > bringing Clojure into amazing new areas. Examples: music, art, alternate > hosts, space stations, donuts, etc. > > Talks will be presented in two tracks on March 24-25th. On the 26th, we > will have space available for people to get together and do what we all > love: write some Clojure! More info to come. > > We expect early bird registration and the sponsorship prospectus to be > available soon. > > Please let us know if you have any questions! > > Alex Miller and Lynn Grogan > Questions: clojur...@cognitect.com > > > > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
My recap of Clojure/conj 2013
I've posted a writeup of my experience from this year's Clojure/conj and wanted to share with those who couldn't make it: http://loganlinn.com/blog/2013/11/18/clojureconj-2013/ Big thanks to all who helped organize & operate the event! -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [ANN] Sleight: whole program transformations
"Expansion Passing Style" is a similar mechanism described in http://citeseerx.ist.psu.edu/viewdoc/summary;jsessionid=B1F3B3E99DE8FD3BD5CA489868730967?doi=10.1.1.50.4332 A number of interesting (and easy to implement) examples are in the paper, including debugging tools. This is an easy way to get symbolic debuggers and inspectors up and running. On Wednesday, September 18, 2013 1:21:26 PM UTC-7, Zach Tellman wrote: > > This is a lein plugin which hijacks the Clojure reader and allows all > forms to be transformed before they're passed to the compiler. Usage and > potential applications are described in the readme: > https://github.com/ztellman/sleight > > I wrote the original version of this a year ago, but due to the lack of > good code walking facilities it was more a sketch than anything else. > Luckily, with the recent release of Riddley [1], this is newly useful. > I'm looking forward to seeing what people use it for. > > Zach > > [1] https://github.com/ztellman/riddley > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Knowledge derivation in core.logic?
On Tuesday, May 28, 2013 5:48:08 AM UTC-7, Phillip Lord wrote: > > One of the things that I am sort of interested in with tawny is whether > there is any value to the overlap of Clojure and OWL in the same > syntax. It would be, for example, possible to annotate a Clojure > function with the OWL; then, potentially, you could reason over the > ontology, then use this to retrieve the executable function. Yes, absolutely. The combination of clojure and OWL with core.logic would be interesting. (as well as other rule engines, databases, etc.) > > A problem with saying these are equivalent in OWL is that "equivalent > > class" is two-way. And so this implies that if you know the unencrypted > > nonce then you also know the secret key and the encrypted nonce. > > Ah, okay, that's my lack of understanding of the domain. You can do this > with a subclass relationship instead, which would make the implication > unidirectional. > Hmmm... I think you're right about that... the set of people who know a given secret key and a given nonce encrypted with that key is a subset of the people who know that unencrypted nonce. I think you've got it! -pdl -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Knowledge derivation in core.logic?
On Tuesday, May 28, 2013 2:51:51 AM UTC-7, Phillip Lord wrote: > > > > > > "Given a secret key and encrypted nonce for that key, assert the > > unencrypted nonce." > > > > What I mean is that there is no way to express this in OWL alone. This > > could be expressed in core.logic, in clojure, in java, in SPARQL + a > custom > > function, in SWRL + a custom function, in Prolog, etc. > > Perhaps I misunderstand the statements in the cryptography. I think he > wanted to say "a person who has a secret key and the encrypted nonce for > that key, also knows the unencrypted nonce". > > I think you could do that in OWL -- something like > > person (and (some knows secret_key) > (some knows encrypted_nonce)) > > equivalent to... > > person (some knows unencrypted_nonce) > > Could be wrong -- I'm just a user of the logic, and a user of > cryptography. > You're correct about the desired goal. Looks like the actual decryption does not need to be performed. But the point stands that OWL does not define any inferences that will lead to that desired OWL statement, given the original statements. A problem with saying these are equivalent in OWL is that "equivalent class" is two-way. And so this implies that if you know the unencrypted nonce then you also know the secret key and the encrypted nonce. > > Yes, that's all I meant by the above, i.e. people unfamiliar with OWL > > inferences would need to be aware of this and explicitly add statements > > like "Alice and Bob are different individuals" or "the set of Male and > > Female are disjoint", etc. > > Wrote a paper about male and female once; it's more complicated than you > might think! > Good point. One always has to make choices when choosing what to model... -pdl -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Knowledge derivation in core.logic?
On Monday, May 27, 2013 12:40:34 AM UTC-7, Phillip Lord wrote: > > Patrick Logan > writes: > > OWL has several levels of increasingly expressive but general > inferences. > > Much of the domain could be represented in OWL (classes (i.e. sets), > > instances (i.e. set membership), relationships with domains and ranges, > > etc.), but there would still be a need for the domain-specific > inferences > > described in the original post. > > Not sure that I understand the domain-specifc inferences that you mean > here; you want a model of the domain that draw inferences over that > model. The actual inferencing technology that you need is not > domain-specific. > In the cryptography domain, the original post mentioned (I rephrase)... "Given a secret key and encrypted nonce for that key, assert the unencrypted nonce." What I mean is that there is no way to express this in OWL alone. This could be expressed in core.logic, in clojure, in java, in SPARQL + a custom function, in SWRL + a custom function, in Prolog, etc. > The other concern about applying OWL when it comes to security and > privacy > > is that OWL is based on Open World reasoning and does not follow the > Unique > > Name Assumption. OWL would say, "Unless these two things are explicitly > > designated as being different, assume they *might* be the same thing." > You > > have to go a bit further to close off these open questions in OWL. > > One of the motivations for tawny, is that you can automate this process. > By default, the logic of OWL will not assume that Alice and Bob are > different people, as you say, but it's easy to add these statements. > Yes, that's all I meant by the above, i.e. people unfamiliar with OWL inferences would need to be aware of this and explicitly add statements like "Alice and Bob are different individuals" or "the set of Male and Female are disjoint", etc. -pdl -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Local database recommendation?
Apache Jena is another good choice for a graph database. It has the choice of an in-memory database, memory-mapped file database (optionally with ACID transactions), or mapped to a relational database. It can also run as a separate database server. There is a procedural java API and the standard SPARQL graph query / update language. http://jena.apache.org/ On Sunday, May 26, 2013 8:33:22 AM UTC-7, James Thornton wrote: > > Hi Cedric - > > Look at Datomic free edition or the Titan graph database using > either Berkeley DB as its backend datastore or Cassandra in single-server > mode -- you can run both locally. > > Datomic: http://www.datomic.com/ > Docs: http://docs.datomic.com/ > Clojure Client: http://docs.datomic.com/clojure/index.html > Videos: http://www.datomic.com/videos.html > Blog: http://blog.datomic.com/ > Query Language: http://docs.datomic.com/query.html (Datalog) > > Titan: http://thinkaurelius.github.io/titan/ > Repo: https://github.com/thinkaurelius/titan > Clojure Client: https://github.com/clojurewerkz/archimedes > Blog: http://thinkaurelius.com/blog/ > Query Language: https://github.com/tinkerpop/gremlin/wiki (Gremlin) > > See the Resources section of the TinkerPop Book website for a collection > of Titan videos and tutorials: http://www.tinkerpopbook.com/#resources > > > - James > > > On Sunday, May 26, 2013 10:09:51 AM UTC-5, Cedric Greevey wrote: >> >> I may be developing an application which will need a persistent, ACID >> local database (on the same disk as the application, rather than having to >> be accessed over the network) containing information about potentially >> 100,000-1,000,000 (or more) objects. >> >> Much of that information will be of a quasi-boolean character: "is it an >> X or not?" for various choices of X, but with "yes", "no", "borderline", >> and "not yet evaluated" as the four possible values. It will be desirable >> to query for these, for example to get a lazy seq of all objects for which >> it's a borderline Y or for which it's not yet evaluated whether it's a Z or >> for which it's either "yes" or "borderline" on whether it's an X or >> whatever. >> >> I'm not that familiar with the local-DB solutions out there. I'd like a >> recommendation for one which is a) a good for for Clojure use and b) a good >> fit for the type of data and queries noted above. The DB must be able to >> grow larger then available RAM without crashing the JVM and the seqs >> resulting from queries like the above will also need to be able to get >> bigger than RAM. >> >> My own research suggests that H2 may be a good choice, but it's a >> standard SQL/relational DB and I'm not 100% sure that fits well with the >> type of data and querying noted above. Note though that not all querying >> will take that form; there'll also be strings, uuids, dates, and other such >> field types and the need to query on these and to join on some of them; >> also, to do less-than comparisons on dates. >> >> Also, what is the current best recommendation of clojure library for >> interfacing to the DB? (Answer might depend on the sort of DB recommended >> -- standard, object/NoSQL, graph/ontology, etc.) >> >> -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Knowledge derivation in core.logic?
OWL has several levels of increasingly expressive but general inferences.
Much of the domain could be represented in OWL (classes (i.e. sets),
instances (i.e. set membership), relationships with domains and ranges,
etc.), but there would still be a need for the domain-specific inferences
described in the original post.
The other concern about applying OWL when it comes to security and privacy
is that OWL is based on Open World reasoning and does not follow the Unique
Name Assumption. OWL would say, "Unless these two things are explicitly
designated as being different, assume they *might* be the same thing." You
have to go a bit further to close off these open questions in OWL.
A set of inferences for this domain might be better based on Closed World
reasoning and Unique Names (e.g. the proposed "OWL ICV"
http://stardog.com/docs/sdp/icv-specification.html ).
Using core.logic, you can implement a domain-specific graph logic, which is
a well-worn technique of knowledge representation. The idea is to:
1. model your domain as a labeled graph
2. represent a graph in core.logic as triples: ?subject ?property ?object
3. implement a simple graph query "DSL" in core.logic (for example here is
one for SWI Prolog:
http://www.swi-prolog.org/pldoc/doc_for?object=section(3,'3.1',swi('/doc/packages/semweb.html'))
)
4. implement your domain-specific inferences using the above general graph
queries.
As Phillip mentioned, depending on the size of your graphs, you may run out
of steam using core.logic, but then you can switch over to more capable
graph-specific implementations that maintain indexes, etc. on the graph.
-pdl
On Sunday, May 26, 2013 2:43:47 AM UTC-7, Phillip Lord wrote:
>
>
> Not a direct answer to your question, but you might want to take a look
> at:
>
> https://github.com/phillord/tawny-owl
>
> This tool wraps OWL, which is a standard language for knowledge
> representation, that maps to a formal logic underneath, which is machine
> interpretable and reasonable.
>
> I don't know enough about cryptography to know whether the semantics of
> OWL would be rich enough, but you should be able to specific that a
> thing that knows a public key of someone is also a subclass of a thing
> that knows the encrypted nonce.
>
> There are some limitations of OWL -- it is not full first order logic,
> but in return, it has better computational properties that logic. The
> reasoners are also highly developed and will scale to 10's or 100's of
> thousands of statements.
>
> Phil
>
>
>
>
> Adam Saleh > writes:
> > I am trying to implement a simple knowledge derivation program in
> > clojure.core.logic,
> > and I am not sure how to approach it. To be more specific, after I am
> done,
> > it will be used as a toy cryptographic protocol verifier,
> > that tries to infer what knowledge can attacker get based on some
> initial
> > knowledge and some rules.
> >
> > For example, I might denote [:pk A] a knowledge of public key of
> somebody
> > and [:pcrypted [:pk A] :nonce] an encrypted nonce sent to this person.
> >
> > Then I'd like be able to somehow specify, that if I know [:pk A], I know
> as
> > well [:pcrypted [:pk A] [:nonce A]] and therefore my program would
> derive
> > from initial knowledge
> >
> > [ [:pk :a] [:pk :b] ] the full knowledge [[:pk :a] [:pk :b] [:pcrypted
> > [:pk :a] [:nonce :a]] [:pcrypted [:pk :b] [:nonce :b]]]
> >
> > Or in slightly more difficult case to specify that if I know a secret
> key
> > [:sk A] and encrypted nonce [:pcrypted [:pk A] [:nonce A]], I also know
> the
> > [:nonce a].
> >
> > Anybody has any hints?
> >
> > So far I managed to implement some of this, but it is a tangled mess of
> > recursive pattern matching, membero, nonmembero and macros :-/
> >
> > Thanks for any pointers,
> >
> > Adam
> >
> > --
>
> --
> Phillip Lord, Phone: +44 (0) 191 222 7827
> Lecturer in Bioinformatics, Email:
> philli...@newcastle.ac.uk
> School of Computing Science,
> http://homepages.cs.ncl.ac.uk/phillip.lord
> Room 914 Claremont Tower, skype: russet_apples
> Newcastle University, twitter: phillord
> NE1 7RU
>
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: ANN: Clojure 1.5
Congrats and thanks to all those who contributed! On Friday, March 1, 2013 7:56:58 AM UTC-8, stuart@gmail.com wrote: > > We are pleased to announce the release of Clojure 1.5. > > Getting Clojure: > > Web: http://clojure.org/downloads > Lein/Maven: :dependencies [[org.clojure/clojure "1.5.0"]] > > Note that it will take a few hours for the links above to become live, > as the completed build moves into Maven Central. > > This release includes significant features and bug fixes, documented > here: > > https://github.com/clojure/clojure/blob/master/changes.md > > The number of Clojure contributors continues to grow. Thanks to all > the people whose code is included in this release: > > Aaron Bedra > Alan Malloy > Alex Redington > Alf Kristian Stoyle > Ambrose Bonnaire-Sergeant > Andy Fingerhut > Brandon Bloom > Brenton Ashworth > Bronsa > Chas Emerick > Christophe Grand > Colin Jones > Cosmin Stejerean > Daniel Solano Gómez > David Powell > David Santiago > Ed Bowler > Federico Brubacher > Gabriel Horner > Gary Fredericks > Herwig Hochleitner > Hubert Iwaniuk > Hugo Duncan > John Szakmeister > Juha Arpiainen > Justin Kramer > Kevin Downey > Laurent Petit > Meikel Brandmeyer > Michael Fogus > Michał Marczyk > Michel Alexandre Salim > Philip Aston > Philip Potter > Rich Hickey > Scott Lowe > Steve Miner > Stuart Halloway > Stuart Sierra > Tassilo Horn > Toby Crawley > Tom Faulhaber > > Thanks to all involved! > > Stu Halloway > Clojure/core > > > > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Trouble calling Dojo grid constructor from ClojureScript
I don't want to bog the list down with my javascript naivete, but the full
fix to dojo/on.js is something like this:
if (type.call && !(((typeof type) === "string") || (type instanceof
String))){...
On Wednesday, November 28, 2012 9:15:11 PM UTC-8, Brian Nelson wrote:
>
> ok. I've had some time to look into this now and have figured out a few
> things.
>
> 1. This is not due to calling the DGrid constructor from clojurescript. It
> occurs even when I call the DGrid constructor from straight javascript
> code. So it doesn't have to do with the clojurescript code calling the
> constructor.
>
> 2. The error goes away if I don't require cljs.core. If cljs.core is
> required then the grid constructor ends up calling back into some code in
> cljs.core, which is where the error occurs.
>
> So I'm a little further down the road but still don't know exactly why
> doing a goog.require("cljs.core") causes cljs.core to receive events from
> the DGrid constructor. Digging in with my javascript debugger and will
> update this as I find out more information.
>
>
>
> On Monday, November 19, 2012 11:15:54 PM UTC-6, Brian Nelson wrote:
>>
>> Hi,
>>
>> I'm brand new to ClojureScript and have been trying to get myself
>> familiarized with it's javascript interop capabilities by implementing
>> the Dojo toolkit tutorials. I've successfully implemented several of
>> the tutorials, but now I've run into something that I can't figure out
>> and am looking for someone to point me in the right direction.
>>
>> I am calling the DGrid(Dojo grid) constructor using the function
>> maingrid
>>
>> (ns couchadmin.core
>> (:use [jayq.util :only [clj->js]])
>> (:require [clojure.browser.repl :as repl]))
>>
>> (defn greet [dom fx]
>> (let [element (.byId dom "greetingcljs")]
>> (set! (. element -innerHTML) "Hello from Dojo using
>> ClojureScript")
>> (.play (.slideTo fx (clj->js {:top 200 :left 200 :node
>> element})
>>
>> (defn maingrid [dom grd]
>> (do
>>
>> (grd. (clj->js {:columns (clj->js {:first "First Name"})}) "grid")
>> (js/alert "hello world")))
>>
>> (defn ^:export main []
>> (comment (repl/connect "http://localhost:9000/repl";))
>> (comment (js/require (array "dojo/dom" "dojo/fx" "dojo/domReady!")
>> greet))
>> (js/require (array "dojo/dom" "dgrid/Grid" "dojo/domReady!")
>> maingrid))
>>
>>
>> When the page is loaded the grid is constructed, but afterwards I see
>> the following javascript exception
>>
>> Uncaught Error: No protocol method ILookup.-lookup defined for
>> type object: [object HTMLDivElement]
>>
>> I'm wondering what this message is indicating. Did I call the
>> constructor incorrectly? Is this an incompatibility with Dojo? Do I
>> need to implement ILookup somehow? Any help would be greatly
>> appreciated.
>>
>> Brian
>>
>
--
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: Trouble calling Dojo grid constructor from ClojureScript
I sent a note to the dojo list, so they're aware of the situation.
Meanwhile it's an easy enough work-around to avoid the problem.
-Patrick
On Saturday, December 29, 2012 5:51:32 PM UTC-8, David Nolen wrote:
>
> Yes this is known problem w/ ClojureScript that could be solved if/when we
> get proper Keywords/Symbol types.
>
> David
>
>
> On Sat, Dec 29, 2012 at 8:46 PM, Patrick Logan
>
> > wrote:
>
>> From what I can tell, dojo is testing an argument to see whether it has a
>> method named "call". dojo seems to be assuming that if such a method
>> exists, then the argument will not be a string.
>>
>> Then clojurescript seems to be assigning a function named "call" to the
>> String prototype. And so these two libraries conflict.
>>
>> I am unsure whether either library is completely to blame. However it
>> seems fairly clear that dojo does not intend to invoke "call" on a string.
>>
>> Changing dojo/on.js, line 83, to
>>
>> if(type.call && (!type instanceof String)){
>>
>> does fix the problem. I'll check with the dojo folks on making a change
>> along these lines unless someone can suggest a change to clojurescript.
>>
>> -Patrick
>>
>>
>> On Wednesday, November 28, 2012 9:15:11 PM UTC-8, Brian Nelson wrote:
>>>
>>> ok. I've had some time to look into this now and have figured out a few
>>> things.
>>>
>>> 1. This is not due to calling the DGrid constructor from clojurescript.
>>> It occurs even when I call the DGrid constructor from straight javascript
>>> code. So it doesn't have to do with the clojurescript code calling the
>>> constructor.
>>>
>>> 2. The error goes away if I don't require cljs.core. If cljs.core is
>>> required then the grid constructor ends up calling back into some code in
>>> cljs.core, which is where the error occurs.
>>>
>>> So I'm a little further down the road but still don't know exactly why
>>> doing a goog.require("cljs.core") causes cljs.core to receive events from
>>> the DGrid constructor. Digging in with my javascript debugger and will
>>> update this as I find out more information.
>>>
>>>
>>>
>>> On Monday, November 19, 2012 11:15:54 PM UTC-6, Brian Nelson wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm brand new to ClojureScript and have been trying to get myself
>>>> familiarized with it's javascript interop capabilities by implementing
>>>> the Dojo toolkit tutorials. I've successfully implemented several of
>>>> the tutorials, but now I've run into something that I can't figure out
>>>> and am looking for someone to point me in the right direction.
>>>>
>>>> I am calling the DGrid(Dojo grid) constructor using the function
>>>> maingrid
>>>>
>>>> (ns couchadmin.core
>>>> (:use [jayq.util :only [clj->js]])
>>>> (:require [clojure.browser.repl :as repl]))
>>>>
>>>> (defn greet [dom fx]
>>>> (let [element (.byId dom "greetingcljs")]
>>>> (set! (. element -innerHTML) "Hello from Dojo using
>>>> ClojureScript")
>>>> (.play (.slideTo fx (clj->js {:top 200 :left 200 :node
>>>> element})
>>>>
>>>> (defn maingrid [dom grd]
>>>> (do
>>>>
>>>> (grd. (clj->js {:columns (clj->js {:first "First Name"})}) "grid")
>>>> (js/alert "hello world")))
>>>>
>>>> (defn ^:export main []
>>>> (comment (repl/connect "http://localhost:9000/repl";))
>>>> (comment (js/require (array "dojo/dom" "dojo/fx" "dojo/domReady!")
>>>> greet))
>>>> (js/require (array "dojo/dom" "dgrid/Grid" "dojo/domReady!")
>>>> maingrid))
>>>>
>>>>
>>>> When the page is loaded the grid is constructed, but afterwards I see
>>>> the following javascript exception
>>>>
>>>> Uncaught Error: No protocol method ILookup.-lookup defined for
>>>> type object: [object HTMLDivElement]
>>>>
>>>> I'm wondering what this message is indicating. Did I call the
>>>> constructor incorrectly? Is this an incompatibility with Dojo? Do I
>>>> need to implement ILookup somehow? Any help would be greatly
>>>> appreciated.
>>>>
>>>> Brian
>>>>
>>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>>
>
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To 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: Trouble calling Dojo grid constructor from ClojureScript
>From what I can tell, dojo is testing an argument to see whether it has a
method named "call". dojo seems to be assuming that if such a method
exists, then the argument will not be a string.
Then clojurescript seems to be assigning a function named "call" to the
String prototype. And so these two libraries conflict.
I am unsure whether either library is completely to blame. However it seems
fairly clear that dojo does not intend to invoke "call" on a string.
Changing dojo/on.js, line 83, to
if(type.call && (!type instanceof String)){
does fix the problem. I'll check with the dojo folks on making a change
along these lines unless someone can suggest a change to clojurescript.
-Patrick
On Wednesday, November 28, 2012 9:15:11 PM UTC-8, Brian Nelson wrote:
>
> ok. I've had some time to look into this now and have figured out a few
> things.
>
> 1. This is not due to calling the DGrid constructor from clojurescript. It
> occurs even when I call the DGrid constructor from straight javascript
> code. So it doesn't have to do with the clojurescript code calling the
> constructor.
>
> 2. The error goes away if I don't require cljs.core. If cljs.core is
> required then the grid constructor ends up calling back into some code in
> cljs.core, which is where the error occurs.
>
> So I'm a little further down the road but still don't know exactly why
> doing a goog.require("cljs.core") causes cljs.core to receive events from
> the DGrid constructor. Digging in with my javascript debugger and will
> update this as I find out more information.
>
>
>
> On Monday, November 19, 2012 11:15:54 PM UTC-6, Brian Nelson wrote:
>>
>> Hi,
>>
>> I'm brand new to ClojureScript and have been trying to get myself
>> familiarized with it's javascript interop capabilities by implementing
>> the Dojo toolkit tutorials. I've successfully implemented several of
>> the tutorials, but now I've run into something that I can't figure out
>> and am looking for someone to point me in the right direction.
>>
>> I am calling the DGrid(Dojo grid) constructor using the function
>> maingrid
>>
>> (ns couchadmin.core
>> (:use [jayq.util :only [clj->js]])
>> (:require [clojure.browser.repl :as repl]))
>>
>> (defn greet [dom fx]
>> (let [element (.byId dom "greetingcljs")]
>> (set! (. element -innerHTML) "Hello from Dojo using
>> ClojureScript")
>> (.play (.slideTo fx (clj->js {:top 200 :left 200 :node
>> element})
>>
>> (defn maingrid [dom grd]
>> (do
>>
>> (grd. (clj->js {:columns (clj->js {:first "First Name"})}) "grid")
>> (js/alert "hello world")))
>>
>> (defn ^:export main []
>> (comment (repl/connect "http://localhost:9000/repl";))
>> (comment (js/require (array "dojo/dom" "dojo/fx" "dojo/domReady!")
>> greet))
>> (js/require (array "dojo/dom" "dgrid/Grid" "dojo/domReady!")
>> maingrid))
>>
>>
>> When the page is loaded the grid is constructed, but afterwards I see
>> the following javascript exception
>>
>> Uncaught Error: No protocol method ILookup.-lookup defined for
>> type object: [object HTMLDivElement]
>>
>> I'm wondering what this message is indicating. Did I call the
>> constructor incorrectly? Is this an incompatibility with Dojo? Do I
>> need to implement ILookup somehow? Any help would be greatly
>> appreciated.
>>
>> Brian
>>
>
--
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: STM - a request for "war stories"
Contact the apache river folks for details. There have been several published accounts, but it is definitely the case that many jini/javaspaces users felt it was in their own interest not to draw attention to this technology as it was determined to be a competitive advantage. http://river.apache.org/ You can also contact the gigaspaces commercial effort, where they are very willing to talk: http://www.gigaspaces.com/ On Thursday, December 13, 2012 9:51:50 PM UTC-8, Paul Butcher wrote: > > On 14 Dec 2012, at 00:22, Patrick Logan > > wrote: > > Another concurrency model I've used a great deal is the tuplespace model, > specifically javaspaces. This is an often forgotten model that has a lot to > offer with a high expressiveness to complexity ratio. > > > Ah! That brings back memories :-) I wrote my PhD thesis on Linda back in > the early 90s. > > I agree that it's a cute model (I thought that it was cute enough to spend > 3 years of my life on it!) but I'm not aware of anyone using it in anger > now? I'd be very interested to hear about live projects. > > I know about Javaspaces/JINI/River, but I've not really heard about anyone > using them? > > -- > paul.butcher->msgCount++ > > Snetterton, Castle Combe, Cadwell Park... > Who says I have a one track mind? > > http://www.paulbutcher.com/ > LinkedIn: http://www.linkedin.com/in/paulbutcher > MSN: pa...@paulbutcher.com > AIM: paulrabutcher > Skype: paulrabutcher > > -- 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: tuple spaces (was Re: STM - a request for "war stories")
I've used javaspaces a fair bit in high-flexibility situations, although not in a truly high-scale situation. I am aware of truly high-scale implementations. Just be careful extrapolating from one case to another. Contact the apache river folks for detailed reports of javaspaces in high-scale... http://river.apache.org/ On Thursday, December 13, 2012 4:36:55 PM UTC-8, raould wrote: > > > Another concurrency model I've used a great deal is the tuplespace > model, specifically javaspaces. This is an often forgotten model that has a > lot to offer with a high expressiveness to complexity ratio. > > otish: > > in the back of my mind i seem to recall hearing that tuplespaces > sounded nifty but quickly ran into brick walls. i'm trying to search > up some results about that, but so far have only found e.g. > > http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.39.744 > > which mentions some of the suck. there's probably other / more / > different suck about tuple spaces, or to put it another way, it is > always good to know what types of things a given approach is and is > not good for :-) > -- 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
STM - a request for "war stories"
Paul, Another concurrency model I've used a great deal is the tuplespace model, specifically javaspaces. This is an often forgotten model that has a lot to offer with a high expressiveness to complexity ratio. Not closure specific, so feel free to contact me again directly if you're interested. -- 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: STM - a request for "war stories"
I am unsure whether you are writing about STM in general or in Clojure specifically. I worked for Gemstone Systems for five years on the object engine as well as applications of the distributed, multi-user, garbage-collected STM that is the centerpiece of Gemstone Smalltalk. During that time I worked with several customer applications where STM had both positive and negative contributions. If this is of interest, you can contact me directly. I can say briefly that Gemstone Smalltalk and its multi-user STM was and is being used for: 1. tracking nearly every container shipped across the Pacific ocean. 2. used to quickly develop cutting-edge financial trading instruments. 3. used to quickly develop mobile communications billing policies. 4. used to control and monitor large semiconductor fabs. 5. dispatching utility repair equipment throughout the southeastern U.S. 6. pharmaceuticals, ... 7. insurance policies, ... 8. ad hoc, distributed workflows, ... -Patrick On Sunday, December 2, 2012 8:03:53 AM UTC-8, Paul Butcher wrote: > > All, > > I have a request which I hope the members of this group are uniquely > positioned to help with. I have recently started working on a new book for > The Pragmatic Programmers with the working title "Seven Concurrency Models > in Seven Weeks" (it follows on from their existing "Seven Languages" and > "Seven Databases" titles). > > One of the approaches that I'll be covering is STM, and I'll be presenting > it in Clojure. > > What I'd like to solicit are "war stories" about problems you've solved > using STM, which demonstrate the strengths of the technique over and above > (say) threads and locks. > > I'm looking for real-world examples instead of presenting yet another > hackneyed atomically-make-a-bank-account-withdrawal :-) > > Very many thanks in advance for your help! > > -- > paul.butcher->msgCount++ > > Snetterton, Castle Combe, Cadwell Park... > Who says I have a one track mind? > > http://www.paulbutcher.com/ > LinkedIn: http://www.linkedin.com/in/paulbutcher > MSN: pa...@paulbutcher.com > AIM: paulrabutcher > Skype: paulrabutcher > > -- 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: GSOC : Constraint based UI layout
Sure. I probably sounded too critical of the project per se. I should not have implied that. A general constraint solver in and of itself is a good thing, and this seems like a good summer project. But if someone has time and or funding to look at a larger effort to improve the current state of UI development... Garnet should be on the list or resources. I am unaware of any language/toolkit moving that kind of work forward, although it was practical 20 years ago. -Patrick On Saturday, April 7, 2012 9:56:19 PM UTC-7, Kevin Lynagh wrote: > > Hi Patrick, > > I'm the potential mentor for the GSoC Cassowary project. > The goal isn't to port Cassowary---it's already implemented in Java > and available in the browser via my CoffeeScript port with > ClojureScript bindings: > > https://github.com/lynaghk/cassowary-coffee > > Rather, the aim of the summer project is to put a higher-level, > idiomatic Clojure API on top of Cassowary (and possibly a DSL like > Cocoa's Autolayout: "[el]--10--[el2]") that folks can use to layout > complex visualizations and user interfaces. > > That said, I appreciate the pointer to Garnet; I've heard about it, > but not dug into it much at all. > One of my favorite things about the Clojure community is the > appreciation for history. > I have no illusions of doing anything novel. > I'd be happy if the GSoC project makes 1990s-state-of-the-art more > accessible, similar to how core.logic introduced so many folks to > logic programming even though Prolog has been around for ages. > > > > > > > On Apr 6, 7:13 pm, Patrick Logan wrote: > > Cassowary seems like a good summer-sized project. My only concern is > that browsers are already gaining fairly expressive constraint-based > layout. > > > > A project that would extend beyond a summer, but move clojure to the > forefront of UI development (and by "forefront" I mean "up to early 1990s > state of the art"), would be a Garnet-like toolkit in clojurescript. Garnet > was a little sluggish in Common Lisp 20 years ago. I'd be curious to get a > sense of responsiveness in 2012 browsers. > > > > Garnet goes well beyond layout to provide declarative interactions and > editors. Which are what we all need to develop anyway. Recently "cassowary" > has become a hot topic. I'm not sure why. But I fear it's popular among > developers today who don't necessarily understand its place amid > superseding advances in UI development. > > > > Seehttp://garnetlisp.sourceforge.netfor information on Garnet. > > > > > > > > > > > > > > > > On Friday, April 6, 2012 9:48:47 AM UTC-7, SHIVAM HANDA wrote: > > > Hi everyone, > > > > > I am Shivam Handa, a sophomore at IIT (Indian Institute of > > > technology), Delhi majoring Computer Science and Engineering. I am > > > intending to work on Constraint based UI layout as a GSOC project > > > during the summer. I had a long chat with the mentor of the project > > > Kevin Lynagh and with his help I have deeper insight into the project. > > > Therefore I have applied for the same project idea at Gsoc’s website. > > > The link to proposal ishttp:// > www.google-melange.com/gsoc/proposal/review/google/gsoc2012/sh > > > I have a github page where I have some more info and a plan to upload > > > some sample code of test cases I have been working on there. The link > > > ishttp://www.github.com/kill-switch > > > > > The project aims at creating a high level Api for cassowary constraint > > > solver for ClojureScript. The project lets the user define layout in > > > term of a few equations (A DSL implementation for easier use of the > > > project will help in easily specifying equations) and layout will > > > follow these equations. One of the direct applications that can be > > > seen is that values need not be calculated for each and every element. > > > > > My project proposal gives the weekly schedule I will follow. It is > > > very well insured that all mentioned will be finished on time. All the > > > specification details of the project as well a good explanation of all > > > the benefits of the open source community is also given there. > > > > > I hope you will support me with my proposal. > > > > > With regards > > > Shivam Handa -- 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: GSOC : Constraint based UI layout
Cassowary seems like a good summer-sized project. My only concern is that browsers are already gaining fairly expressive constraint-based layout. A project that would extend beyond a summer, but move clojure to the forefront of UI development (and by "forefront" I mean "up to early 1990s state of the art"), would be a Garnet-like toolkit in clojurescript. Garnet was a little sluggish in Common Lisp 20 years ago. I'd be curious to get a sense of responsiveness in 2012 browsers. Garnet goes well beyond layout to provide declarative interactions and editors. Which are what we all need to develop anyway. Recently "cassowary" has become a hot topic. I'm not sure why. But I fear it's popular among developers today who don't necessarily understand its place amid superseding advances in UI development. See http://garnetlisp.sourceforge.net for information on Garnet. On Friday, April 6, 2012 9:48:47 AM UTC-7, SHIVAM HANDA wrote: > Hi everyone, > > I am Shivam Handa, a sophomore at IIT (Indian Institute of > technology), Delhi majoring Computer Science and Engineering. I am > intending to work on Constraint based UI layout as a GSOC project > during the summer. I had a long chat with the mentor of the project > Kevin Lynagh and with his help I have deeper insight into the project. > Therefore I have applied for the same project idea at Gsoc’s website. > The link to proposal is > http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/shivamhanda/1. > I have a github page where I have some more info and a plan to upload > some sample code of test cases I have been working on there. The link > is http://www.github.com/kill-switch > > The project aims at creating a high level Api for cassowary constraint > solver for ClojureScript. The project lets the user define layout in > term of a few equations (A DSL implementation for easier use of the > project will help in easily specifying equations) and layout will > follow these equations. One of the direct applications that can be > seen is that values need not be calculated for each and every element. > > My project proposal gives the weekly schedule I will follow. It is > very well insured that all mentioned will be finished on time. All the > specification details of the project as well a good explanation of all > the benefits of the open source community is also given there. > > > I hope you will support me with my proposal. > > > With regards > Shivam Handa -- 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-scheme - Compiling Clojure to Scheme to C
Gambit Scheme especially has a great interface to C/C++/Objective-C. I've been happily using Gambit quite a bit for 20+ years, when it originated as gambit-68k for the Motorola 68000. Gambit-C's been ported to iOS, Nintendo DS, etc. In addition to the great C interface, it also has a great Unix/Posix interface, a great threads and message passing library (in the neighborhood of Erlang's performance for numbers of threads and messages per second), etc. It comes with Termite which is an Erlang-like programming model with mobile continuations. So porting to Gambit provides some good avenues to explore. -Patrick On Wednesday, March 21, 2012 12:46:13 AM UTC-7, Nathan Sorenson wrote: > > I see the C code generation as an advantage, in that it becomes possible > to target any platform with a C compiler. > > Can Clozure compile to iOS? > > Just a question, why Clojure->Scheme->C, instead of Clojure->Clozure? >> >> That way there would no be any C compiler dependency. >> > On Wednesday, March 21, 2012 12:46:13 AM UTC-7, Nathan Sorenson wrote: > > I see the C code generation as an advantage, in that it becomes possible > to target any platform with a C compiler. > > Can Clozure compile to iOS? > > Just a question, why Clojure->Scheme->C, instead of Clojure->Clozure? >> >> That way there would no be any C compiler dependency. >> > -- 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: Latest Bagwell paper for a new implementation of Clojure vectors ?
Are there currently any plans to eventually replace PersistentVector? Looking at the code, the upper limit for the number of elements that can be stored in PersistentVector is 32^6, which is quite a lot but still might become a real limitation in the near future. -- 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
Strategy direction for ClojureScript regarding Google Dash?
I think it's probably too early to speculate, but does the clojure/ core team have any thoughts on how Google Dash might affect ClojureScript? Given that ClojureScript currently compiles to Closure Javascript, can we then compile that into Dash for performance enhancements? http://css.dzone.com/news/google-dart-%E2%80%9Cultimately -- 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: Please stand firm against Steve Yegge's "yes language" push
I think Yegge clarified in a follow-up post that what he really meant to say was "say yes to USERS", not "say yes to FEATURES", but in his typical off-the-cuff ranty writing style, he had accidentally conflated the two. As far as saying yes to every feature, I think that is obviously not a great idea. It is easy to make the argument that one of the reasons Java became successful are the features that it said no to: No to pointers, no to multiple inheritance, no to operator overloading. As far as saying yes to USERS. I think Yegge brings up a really important point about a critical problem that plagues not just clojure but all open source communities in general. Basically the blowhard who thinks he is smarter than the average person and who enjoys letting other people know it. We all have some element of self-interest in our hearts. When you get paid to write software the reward is obvious. When you are contributing to open source what is the motivation? If you have the soul of an artist maybe you just want to create something beautiful. But there are a lot of others for whom contributing to open source is an ego trip. They haven't gotten the recognition that they feel they deserve in other parts of their life, so they decided that by writing something cool and putting it on the internet then they will be cool too. When you are getting paid for software you have a direct incentive to make your software as user friendly as possible. If it "just works" for the users and they like it and they can happily use it without ever looking at a manual, then you get more users and more money. People in open source want more users too but they don't necessarily want it to be user friendly. In fact often I feel there is this huge incentive to NOT be user friendly. It is like hazing. You get to say things like "That is not the functional way, I know the right way but you don't, I am better than you." or "Why would anyone want to do that? The problem you are stumped on has such an obvious solution to me that I can't even understand why you have a problem, I am better than you." There is this attitude of "I figured how to write my own .emacs all by myself, from reading the forums and the documentation, because I was too socially maladjusted to ask anyone for help. Why can't you?" This poisonous attitude is perfectly exemplified in this thread by James Keats. I think it's important to recognize that we are all human beings, which means that we are herd animals, which means that we all have genetically hardwired responses to desire to be part of a hierarchy and we desire to place ourselves higher up on that hierarchy. This is why we have bullies in kindergarten. But just because you were bullied in kindergarten does not make it okay for you to bully newbies over the internet now. Back then it was not okay for the bigger kids to pick on the smaller kids and right now just because you are smarter than someone does not make you a better person. We are herd animals but we are also civilized human beings, we can rise above our base animal desires to put other people down, we don't have to give in to our desire to feel like we are part of a special club. I think the clojure community has in general been much better about this than some other open source communities, but as clojure gets more popular, the ego trippers are starting to join the party, the guys who want to say "I use clojure, clojure is the best language of all, I am better than you!" The guys who don't care about the pragmatic beauty of clojure and just want to be a big man in a new tribe. I think it would be good to not pay too much attention to such people and say yes to the users. Say yes to the newbies, yes to the object oriented people not by making clojure more object oriented, but by not shutting them out of the discourse and laughing them off as just "object oriented people". As someone whose name I can't remember right now once said, "There are no bad students, only bad teachers." -- 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: More sane emacs for clojure
I don't know if "ergo" is the right name to describe this project. Most of the default emacs key-bindings are very ergonomic, assuming you remap your ctrl to your caps lock. Most of the commands that you use most frequently can be entered in with just your left hand, with your little finger on the ctrl key and the other key (or other 2 keys) positioned so that they can be quickly typed with two different fingers. The default mappings are a pain to learn but they make more sense from a practical perspective. On Jun 27, 8:47 pm, flebber wrote: > Something I just discovered and thought it might be of benefit here. > Since the main environment for clojure is currently emacs; clojure > box, swank etc; and emacs has a learning curve it may be useful to > reduce the emacs learning curve so that we can concentrate on learning > clojure. > > Ergo Emacshttp://ergoemacs.org. Provides normal(expected) key > bindings for emacs plus includes a lot of goodies and language support > bundled in by default. This might even by very cool with clj > launcherhttp://clojure02.managed.contegix.com/display/design/CLJ+Launcher. > > Just some languages supported out of the box. From > herehttp://ergoemacs.org/features.html. > > Csharp > JavaScript > PHP > Haskell > Clojure > Erlang > Scala > OCaml, F# > Lua > > And some of the preinstalled features. > Additional Conveniences - there are far more listed on the site. > > Template set for tens of languages (yasnippet) > Enhanced feature of name completion. (AutoComplete) > Enhanced directory viewer (DiredPlus) > Enhanced bookmark (BookmarkPlus) > Emacs Unicode Browser > Emacs Math Symbols Input Mode (xmsi-mode) > Tab bar GUI (TabBarMode) > A Twitter mode (TwIt) > PDF and Image files can be viewed inside emacs. > Bundled all common unix commands that are used by emacs: grep, find, > diff, patch, gzip ... (the whole MSYS component of MinGW.) > Support 3 new shells: shell (cmd.exe), msys-shell (bash), eshell > (elisp shell), powershell (PowerShell). All these are under the menu > > I am going to try and figure out what clojure box installs and see if > I can merge it with ergo emacs. It might create a great ready to go > environement out of the box. -- 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: Memoizing a recursive function?
paul what version did you use? your version was the first one I tried, and on 1.2 at least it does not work. Jules version works, except lambda should be fn in clojure. On Jul 22, 4:51 pm, Paul Mooser wrote: > Why not simply do: > > (defn fib [n] > (println "called with " n) > (if (> n 2) > (+ (fib (- n 2)) (fib (- n 1))) > 1)) > > (def fib (memoize fib)) > > I inserted the println to verify when we were actually calling the > function, and I believe this works - fib only seems to get invoked a > single time for any given n. Is this solution incorrect in some way? -- 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: Memoizing a recursive function?
I tried defn-memo .. it still does not appear to memoize the original fib call? I tried this using clojure 1.2 beta. Reading the code definition for defn-memo it seems like it should work, but calling (fib 41) still takes a long time after calling (fib 40), when it should basically be an instantaneous call if the memoization works correctly. Jules code works, except of course in clojure there is no lambda, but fn. On Jul 22, 5:36 am, Laurent PETIT wrote: > nevermind, the following code does not work. > > Jules' one is the right one > > 2010/7/22 Laurent PETIT > > > > > Another solution, use the var, and then use memoize on your function as > > usual: > > > (defn fib[n] > > (if (> n 2) > > (+ (#'fib (- n 2)) (#'fib (- n 1 > > > (of course this was to answer closely to the question. Nobody would write > > fib like that in practice : good general question, bad example) > > > HTH, > > > -- > > Laurent > > > 2010/7/22 Mike Meyer > > > On Wed, 21 Jul 2010 14:47:12 -0700 (PDT) > >> logan wrote: > > >> > Lets say I have the following function > > >> > (defn fib[n] > >> > (if (> n 2) > >> > (+ (fib (- n 2)) (fib (- n 1))) > >> > 1)) > > >> > and I want to memoize it, what is the right way to do it? > > >> Use defn-memo from clojure.contrib.def. > > >> >> -- > >> Mike Meyer > >>http://www.mired.org/consulting.html > >> Independent Network/Unix/Perforce consultant, email for more information. > > >> O< ascii ribbon campaign - stop html mail -www.asciiribbon.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 -- 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
Memoizing a recursive function?
Lets say I have the following function (defn fib[n] (if (> n 2) (+ (fib (- n 2)) (fib (- n 1))) 1)) and I want to memoize it, what is the right way to do it? Using the default memoize does not work correctly. the reason is even though the first call to fib is memoized, the recursive calls go to the original fib, and not the memoized function. Even using (def fib (memoize fib)) does not seem to work. if you run (fib 45) and (fib 46), in the ideal case, (fib 47) should just call the memoized (fib 45) and (fib 46) and return almost immediately, but that is not the case. -- 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
Question about how to write efficient code in functional style
Let's say I want to write a function that takes as an argument a list of n numbers, and returns 4 lists, a list of odd numbers that are multiples of 5, a list of even numbers that are multiples of 5, a list of odd numbers that are not multiples of 5, and a list of even numbers that are not multiples of 5. If I were writing this function procedurally, I could create 4 empty lists, and iterate through my input list once, using a compound if statement to add to the appropriate list. In functional style, I could use filter, but I can't seem to think of a solution that doesn't end up iterating through the whole list multiple times. Can someone please teach me what is the correct clojure approach? 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
