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.
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
* 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: 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] 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: 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
