Need help for the macro with defn and defmacro inside
Hi : I would try to make a macro to simplify the database methods as follows, but it doesn't work, is there any way to fix it, or any easier solution? Thanks.. (defmacro with-db [& body] `(with-connection *db* ~...@body)) (defmacro with-transaction [& body] `(with-db (transaction ~...@body))) ; ; basic table operations - drop, insert, update, select(by id) ; (defmacro create-database-methods [db] (let [db# db] `(do (defn (var (str "drop-" db#)) [] (try (drop-table (keyword ~db#)) (catch Exception _)) (defn (var (str "insert-" db#)) [body] (insert-values (keyword ~db#) (keys body) (vals body))) (defn (var (str "update-" db#)) [id attribute-map] (update-values (keyword ~db#) ["id=?" id] attribute-map)) (defmacro select-userentry [id & body] `(with-transaction with-query-results rs [~~(str "select * from " ~~db# " where id=?") id] ~...@body)) -- 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: name clash/problem with refer
Hi, On Mar 4, 7:36 am, cageface wrote: > So I figured I'd try to use the :exclude option but got this: > user=> (use 'clojure.contrib.string :exclude [repeat]) > java.lang.IllegalArgumentException: Don't know how to create ISeq > from: java.lang.Boolean (NO_SOURCE_FILE:0) Almost correct: (use '[clojure.contrib.string :exclude (repeat)]) Sincerely Meikel -- 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
name clash/problem with refer
In trying to build compojure with the git MASTER versions of clojure & contrib I ran into this error: Clojure 1.2.0-master-SNAPSHOT user=> (use 'clojure.contrib.string) java.lang.IllegalStateException: repeat already refers to: #'clojure.core/repeat in namespace: user (NO_SOURCE_FILE:0) So I figured I'd try to use the :exclude option but got this: user=> (use 'clojure.contrib.string :exclude [repeat]) java.lang.IllegalArgumentException: Don't know how to create ISeq from: java.lang.Boolean (NO_SOURCE_FILE:0) Digging a little deeper I tried to diagnose the problem with refer: user=> (refer 'clojure.contrib.string :exclude [repeat]) java.lang.IllegalStateException: repeat already refers to: #'clojure.core/repeat in namespace: user (NO_SOURCE_FILE:0) Looking at the code of the refer function I'm *guessing* that the code that filters out the :excludes isn't working because [repeat] evaluates to an existing function in the current namespace and not a bare symbol to be matched against the incoming symbols from the target lib, but I'm not sure. -- 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: Some basic guidance to designing functional vs. state parts of app
On Mar 2, 11:34 pm, Sophie wrote: > > How do I choose? What are the trade-offs? > > Any and all guidance, insights, advice etc. welcome! > > Thanks! To me, it seems like you have two orthogonal pieces of data, and a function that builds a report from that data. You have a set of job listings, and a set of applicants. I see no reason why these need to be coordinated (ref). The addition of a job listing is totally independent of an applicant updating her resume. So it's uncoordinated (atom). That is, the job listings are always in a consistent state no matter what I do to the applicant data. Said another way, there's nothing I can do to the applicant data that can put the job listings in an inconsistent state. As for the match function. Well it needs to get a snapshot of both pieces of data, and then determine what applicants match up with each job listing. While this function is running a job could be added, an applicant could update her resume, or maybe an applicant will remove her resume but your function won't see any of that, but who cares? It will see a consistent snapshot of both pieces of data, and from those it will build the result. As of time T1, here is your latest and greatest match report. Now, say you want the match report built every time a job listing or applicant data is changed. This way the 'latest' report is always in memory and ready to go. Well, in this case, you now need to coordinate the update of job listings or applicant data with the generation of the report. You never want your program to enter a state where the job listings are in state L101 and applicants are in state A54 and your report is based on the combination of (L101, A53). That's an inconsistent state because your report is not based on the latest data. In this case, you'd probably want to use refs to make sure the your job/applicant data is coordinated with your report data. However, if your data is constantly changing, and the match function takes a while to run then this may be very slow. Take what I say with a grain of salt as I'm also fairly new to this stuff. At the end of the day, experience is probably the best teacher. -- 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 slides
Hi, On Thu, Mar 4, 2010 at 11:58, Wilson MacGyver wrote: > Looks like I'll be doing a talk on clojure next week at the local java > user group. > > Any recommendations on slides I can steal? :) There are some presentations in our google group file section[1]. Look for PDF files. Mike [1] http://groups.google.com/group/clojure/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
clojure slides
Looks like I'll be doing a talk on clojure next week at the local java user group. Any recommendations on slides I can steal? :) -- Omnem crede diem tibi diluxisse supremum. -- 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
doto doc fix
- value of x supplied at the from of the given arguments. The forms + value of x supplied at the front of the given arguments. The forms -- 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: Some basic guidance to designing functional vs. state parts of app
For a single value there seems to be little reason to adopt refs, though I've often wondered why Stuart Halloway's book gives an example updating a single ref of messages for a chat application. I seem to recall atoms being the last reference type to be introduced. They might not have existed when Stuart was writing. -- 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: Some basic guidance to designing functional vs. state parts of app
On 3 March 2010 04:34, Sophie wrote: > As a bit of a newbie to the functional + identity/state design space, > I'm struggling a bit with where to use identity constructs (refs) and > where to stay with pure functions, and could use some guidance. Pardon > me if some of my terms are a bit off. Here is a simple hypothetical > app for matching Applicants to Jobs. > > I have several Applicants, each with some set of Skills. There are > several Jobs, each with some Requirements. There is some Match > relation between Skills and the Jobs they can match. The set of > Applicants, each of their skills, and the set of Jobs can change with > time. There is a set of Jobs that each Applicant can fill, > functionally computed from applicant skills & job requirements & > Match. > > Ok, so jobs_that_an_applicant_can_fill is a pure function, I get > that. > > Do I design a single "World" ref whose state changes with time to > different worlds, so adding a new Applicant or even adding a new Skill > to an existing Applicant results in a new World value? Or is it better > to have an "Applicants" ref and a "Jobs" ref that refer to different > sets of those er.. things? > > Can each Applicant have a "skills" ref, whose state changes to > different sets of Skills? Should I design it this way? > > How do I choose? What are the trade-offs? If you have a single value representing the whole world, then it seems that protecting it with an atom would be the simplest and most idiomatic solution. Refs are for co-ordinated change, i.e. where you want to update multiple values at the same time. For a single value there seems to be little reason to adopt refs, though I've often wondered why Stuart Halloway's book gives an example updating a single ref of messages for a chat application. If you partition your data more, into several values, then you should use refs to co-ordinate the change. The more granular you make the refs, the more you trade complexity of design for potential throughput under concurrent load, as finer grained refs are likely to mean less collisions during transactions (unless of course you update every ref in every transaction - which sounds like it'd be the worst case scenario). R. -- 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: Some basic guidance to designing functional vs. state parts of app
On Wed, 3 Mar 2010 14:20:56 -0800 (PST) Armando Blancas wrote: > > > On Mar 2, 8:34 pm, Sophie wrote: > > Do I design a single "World" ref whose state changes with time to > > different worlds, so adding a new Applicant or even adding a new Skill > > to an existing Applicant results in a new World value? Or is it better > > to have an "Applicants" ref and a "Jobs" ref that refer to different > > sets of those er.. things? > > > > It's simpler to use refs close to the object that will change; that > makes > the code to mutate the value simpler; if the world is the only mutable > object, > then the code to change something in there will increase with the > depth > of the mutation. I'm not sure it's simpler: update-in makes reaching deep into a structure to create a new structure with that one change in it easy, and is probably more efficient than trying to do the same thing by hand. More importantly, if you break your refs up into smaller objects, you should get better concurrency, as you can change two such refs in two different threads without a problem. If you put the two in a structure in the same ref, then you can't update one while the other is being worked on. 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
Re: objects, interfaces and library design
On Wed, 3 Mar 2010 09:47:09 -0800 (PST) cageface wrote: > I've been reading through the examples of "OO" in clojure using multi- > methods and they certainly seem very flexible and powerful. I'm > wondering, however, how people handle interface & library design. If > people can implement "objects" as maps, structs, or just about > anything else you can discriminate on via a dispatch function, how do > you handle code reuse and sharing of libraries. If we're all using our > own home-grown OO systems how do we communicate? I hope that most people aren't using home-grown OO systems for most of their problems - especially given that maps are almost enough for a prototype-based system to start with. That would be working "against the grain", as it were. While it would be nice to have a standard OO system for the cases where that's appropriate, those should be relatively rare. 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
Seajure meeting tomorrow night (Seattle Clojure group)
Just a reminder: tomorrow night we're having a meeting of Seajure, the Seattle Clojure group. 7:00 pm at University Zoka http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=zoka,+university+district,+seattle&sll=37.0625,-95.677068&sspn=49.490703,90.791016&ie=UTF8&hq=zoka,&hnear=University+District,+Seattle,+WA&ll=47.66624,-122.296629&spn=0.010361,0.022166&z=16&iwloc=B We'll be at the table in the back. Look for the "my other car is a cdr" sticker. Topics may include but not be limited to: * Code clinic: get some extra eyes and opinions on a project * Making optimum use of Clojars * Map vs Reduce: which is better? -Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: objects, interfaces and library design
On Mar 3, 2:05 pm, Jarkko Oranen wrote: > Well, it seems to me that the "universal interface" is the sequence. > Turns out many things can be represented as sequences. :) And since > maps are just collections of key/value pairs, very generic code can be > written to process them, too. As long as the wanted keys are there, > any extra information the map might be carrying can often be ignored. So is it generally the case that people implement "objects" as maps? That's what I've been doing in my dabblings with the language so far and it seems flexible enough. -- 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: Some basic guidance to designing functional vs. state parts of app
On Mar 2, 8:34 pm, Sophie wrote: > Do I design a single "World" ref whose state changes with time to > different worlds, so adding a new Applicant or even adding a new Skill > to an existing Applicant results in a new World value? Or is it better > to have an "Applicants" ref and a "Jobs" ref that refer to different > sets of those er.. things? > It's simpler to use refs close to the object that will change; that makes the code to mutate the value simpler; if the world is the only mutable object, then the code to change something in there will increase with the depth of the mutation. > Can each Applicant have a "skills" ref, whose state changes to > different sets of Skills? Should I design it this way? Yes; and if the kills set in independent of other state it may be an atom and you avoid a dosync if the program is single-threaded. -- 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: objects, interfaces and library design
On Mar 3, 7:47 pm, cageface wrote: > I've been reading through the examples of "OO" in clojure using multi- > methods and they certainly seem very flexible and powerful. I'm > wondering, however, how people handle interface & library design. If > people can implement "objects" as maps, structs, or just about > anything else you can discriminate on via a dispatch function, how do > you handle code reuse and sharing of libraries. If we're all using our > own home-grown OO systems how do we communicate? > > Is this something that the deftype/protocol proposals are meant to > address or do people just work around it in other ways or is it just > not a real issue in practice? Well, it seems to me that the "universal interface" is the sequence. Turns out many things can be represented as sequences. :) And since maps are just collections of key/value pairs, very generic code can be written to process them, too. As long as the wanted keys are there, any extra information the map might be carrying can often be ignored. deftype will allow people to define their own types for data that would be inefficient to store in a map. They will still (optionally) expose a map-like interface, so any generic map-processing code is not necessarily obsoleted by them. Protocols on the other hand allow you to define interfaces which can be implemented "after the fact", hopefully making interoperability easier. -- 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: Binary byte reader closure
Works for me now. No idea what changed. Different day. Sigh. On Mar 3, 12:07 pm, Michael Wood wrote: > On 2 March 2010 23:57, TimDaly wrote: > > > > > I would like to have a function that returns the next binary byte of a > > file. > > I tried > > > (defn reader (file) > > (let [in (new java.io.FileInputStream file] > > #(. in (read > > > The idea is that I could call this function once and it would return a > > closure > > over the 'in' object. Then I could simply call reader to get the next > > byte. As in > > > (def fetchbyte (reader "file.o")) > > > (fetchbyte) > > > I get an error > > java.lang.IllegalArgumentException: Don't know how to create ISeq > > from: > > clojure.lang.Symbol > > Works for me after fixing the argument list (as mentioned by Meikel) > and closing the parenthesis in the let vector. I also changed (new > Blah something) to (Blah. something) and (. object (method)) to > (.method object) but those should not make a difference: > > user=> (defn reader [file] (let [in (java.io.FileInputStream. file)] > #(.read in))) > #'user/reader > user=> (def fetchbyte (reader "/etc/shells")) > #'user/fetchbyte > user=> (fetchbyte) > 35 > user=> (fetchbyte) > 32 > user=> (fetchbyte) > 47 > > -- > Michael Wood -- 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: "Unable to resolve symbol" in third-party jarfile
On Mar 3, 2010, at 8:42 AM, Michael Wood wrote: > On 2 March 2010 17:40, Michael Gardner wrote: >> As part of a project to help me learn Clojure, I'm trying to send an >> email using code like >> http://nakkaya.com/2009/11/10/using-java-mail-api-from-clojure/. >> For the JavaMail API I'm using GNU JavaMail, which in turn requires >> GNU JAF (activation.jar). When I try to run my program, I get: >> >>> Exception in thread "main" java.lang.Exception: Unable to resolve symbol: � >>> in this context (activation.jar:0) >> >> (The symbol in question shows up for me as a diamond with a question >> mark in it.) Any clues on what this could be? Since it's dying at line >> 0, maybe it's choking on a UTF BOM or something? > > How are you trying to run it? It looks like it's trying to treat > activation.jar as a Clojure source file. Ah, that was it. I was using clojure's -cp option with a path with a wildcard at the end, but forgot to enclose the path in quotes. Clojure was interpreting the second jarfile in that dir as the script I was asking it to run. It would be nice if clojure would die with a message about "too many arguments" in such a case, but I'm just happy to have figured it out. Thanks! -Michael -- 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
objects, interfaces and library design
I've been reading through the examples of "OO" in clojure using multi- methods and they certainly seem very flexible and powerful. I'm wondering, however, how people handle interface & library design. If people can implement "objects" as maps, structs, or just about anything else you can discriminate on via a dispatch function, how do you handle code reuse and sharing of libraries. If we're all using our own home-grown OO systems how do we communicate? Is this something that the deftype/protocol proposals are meant to address or do people just work around it in other ways or is it just not a real issue in practice? -- 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: Protocols and Types
On 03.03.2010, at 16:05, Andrea Tortorella wrote: > given that a protocol is represented as a simple map, which is the > way to know if something is infact a protocol. I don't think that is possible without relying on undocumented characteristics that are likely to change. What do you need this for? > Or suppose i want to add a function that works on protocols how can i do that? Just like for any other data type: using the existing functions that work on protocols. But again, what kind of function do you have in mind? Konrad. -- 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: Binary byte reader closure
On 2 March 2010 23:57, TimDaly wrote: > I would like to have a function that returns the next binary byte of a > file. > I tried > > (defn reader (file) > (let [in (new java.io.FileInputStream file] > #(. in (read > > The idea is that I could call this function once and it would return a > closure > over the 'in' object. Then I could simply call reader to get the next > byte. As in > > (def fetchbyte (reader "file.o")) > > (fetchbyte) > > I get an error > java.lang.IllegalArgumentException: Don't know how to create ISeq > from: > clojure.lang.Symbol Works for me after fixing the argument list (as mentioned by Meikel) and closing the parenthesis in the let vector. I also changed (new Blah something) to (Blah. something) and (. object (method)) to (.method object) but those should not make a difference: user=> (defn reader [file] (let [in (java.io.FileInputStream. file)] #(.read in))) #'user/reader user=> (def fetchbyte (reader "/etc/shells")) #'user/fetchbyte user=> (fetchbyte) 35 user=> (fetchbyte) 32 user=> (fetchbyte) 47 -- Michael Wood -- 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: Some basic guidance to designing functional vs. state parts of app
One aspect of your question that makes it difficult to answer is that you don't explain what the repercussions should be (in terms of synchronization) when a new applicant or job enters the pool or a new skill is attributed to an applicant. Should the job<->applicant matching function be restarted? Are you simply trying to isolate the matching algorithm from updates to the data structures? On Mar 2, 10:34 pm, Sophie wrote: > As a bit of a newbie to the functional + identity/state design space, > I'm struggling a bit with where to use identity constructs (refs) and > where to stay with pure functions, and could use some guidance. Pardon > me if some of my terms are a bit off. Here is a simple hypothetical > app for matching Applicants to Jobs. > > I have several Applicants, each with some set of Skills. There are > several Jobs, each with some Requirements. There is some Match > relation between Skills and the Jobs they can match. The set of > Applicants, each of their skills, and the set of Jobs can change with > time. There is a set of Jobs that each Applicant can fill, > functionally computed from applicant skills & job requirements & > Match. > > Ok, so jobs_that_an_applicant_can_fill is a pure function, I get > that. > > Do I design a single "World" ref whose state changes with time to > different worlds, so adding a new Applicant or even adding a new Skill > to an existing Applicant results in a new World value? Or is it better > to have an "Applicants" ref and a "Jobs" ref that refer to different > sets of those er.. things? > > Can each Applicant have a "skills" ref, whose state changes to > different sets of Skills? Should I design it this way? > > How do I choose? What are the trade-offs? > > Any and all guidance, insights, advice etc. welcome! > > Thanks! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Binary byte reader closure
Sorry, that was a transcription error. My common-lisp is showing. The original source has square brackets. The issue seems to be that something internal to Clojure does not implement the ISeq interface. Why it wants to find an ISeq interface on Symbol is unclear. The symbol "in" should be part of the closure but it is just a capture of the number of the stream, likely implemented as an integer. So my expectation is that the function #(. in (read)) will be returned as the value of "reader". Thus, the call (reader) should turn into (#(. in (read)) or ((lambda () (. in (read in slightly more traditional syntax. Since (read) returns a byte each call should return a byte. On Mar 3, 9:43 am, Meikel Brandmeyer wrote: > Hi, > > On Mar 2, 10:57 pm, TimDaly wrote: > > > (defn reader (file) > > (let [in (new java.io.FileInputStream file] > > #(. in (read > > The arguments a written in a vector not a list: > > (defn reader > [file] ; <- note vectpr > (...)) > > Sincerely > Meikel -- 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: Protocols and Types
I'm not on my machine so i'cant experiment, i tried on #clojure with clojurebot but it's not 1.2, so i ask here, given that a protocol is represented as a simple map, which is the way to know if something is infact a protocol. Or suppose i want to add a function that works on protocols how can i do that? > > I thought that P had some kind of protocol type, that extends > > something like: > > As you found out, it doesn't. But then, you shouldn't care about how > protocols are represented in memory, as long as the documented API functions > work. > > Konrad. -- 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: Protocols and Types
Hi, On Mar 3, 2:43 pm, Andrea Tortorella wrote: You have to use some instance of T. > (extends? P T) > ;==> nil (extends? P some-t) will return false, because you don't call extend explicitly. > (satisfies? P T) > ;==> nil (satisfies? P some-t) will return true. > (extenders P) > ;==>nil See first case. Sincerely Meikel -- 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: Protocols and Types
Hi Andrea,
You need to make two little changes: (1) satisfies? is a predicate
about instances, not types, and (2) the extend predicates check for
explicit extension:
(defprotocol P
(foo [x]))
(deftype T [])
(extend ::T
P
{:foo (fn [] "dummy")})
(extends? P T)
=> true
(satisfies? P (T))
=> true
(extenders P)
=> (:user/T #)
Hi everyone,
if I run this code:
(defprotocol P
(foo [x]))
(deftype T []
P
(foo [] "dummy"))
(extends? P T)
;==> nil
(satisfies? P T)
;==> nil
(extenders P)
;==>nil
are they not yet implemented?
anyway when I run
(type P)
;==> clojure.lang.PersistentArrayMap
So the protocol is simply a map.
I thought that P had some kind of protocol type, that extends
something like:
(defprotocol ProtocolProtocol
(extends? [p t])
(extenders [p])
(satisfies? [p t]))
(deftype Protocol [methods implementers]
ProtocolProtocol
(extends? [t] ...)
(extenders [] ...)
(satisfies? [t] ...))
Does it make any sense?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Protocols and Types
On 03.03.2010, at 14:43, Andrea Tortorella wrote: > (extends? P T) > ;==> nil > (satisfies? P T) > ;==> nil > (extenders P) > ;==>nil The doc string of both extends? and extenders refers to types "explicitly extending" a protocol. My understanding is that this excludes protocols implemented via their associated Java interface, which is what you did in your definition of T. However, satisfies? works well in your case but its second argument must be an instance of the type. Try this: (satisfies? P (T)) ; ==> true I am not aware of any function that checks whether a given type implements a given protocol, but then I never needed such a function either. BTW, you can get the Java interface corresponding to a protocol using (:on-interface protocol). This is not a documented feature, so you'd better don't use it in production code. But it's great for exploring and debugging. > I thought that P had some kind of protocol type, that extends > something like: As you found out, it doesn't. But then, you shouldn't care about how protocols are represented in memory, as long as the documented API functions work. Konrad. -- 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: Protocols and Types
On Wed, Mar 3, 2010 at 8:43 AM, Andrea Tortorella wrote: > Hi everyone, > > if I run this code: > > (defprotocol P > (foo [x])) > > (deftype T [] > P > (foo [] "dummy")) > > (extends? P T) > ;==> nil > (satisfies? P T) > ;==> nil > (extenders P) > ;==>nil > > are they not yet implemented? > Nil means the tests fail, that T does not extend or satisfy P. It looks like you're missing the argument on the foo function in the definition of T. If you put an argument in there, do you get the results you expect? -- 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: Binary byte reader closure
Hi, On Mar 2, 10:57 pm, TimDaly wrote: > (defn reader (file) > (let [in (new java.io.FileInputStream file] > #(. in (read The arguments a written in a vector not a list: (defn reader [file] ; <- note vectpr (...)) Sincerely Meikel -- 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: "Unable to resolve symbol" in third-party jarfile
On 2 March 2010 17:40, Michael Gardner wrote: > As part of a project to help me learn Clojure, I'm trying to send an > email using code like > http://nakkaya.com/2009/11/10/using-java-mail-api-from-clojure/. > For the JavaMail API I'm using GNU JavaMail, which in turn requires > GNU JAF (activation.jar). When I try to run my program, I get: > >> Exception in thread "main" java.lang.Exception: Unable to resolve symbol: � >> in this context (activation.jar:0) > > (The symbol in question shows up for me as a diamond with a question > mark in it.) Any clues on what this could be? Since it's dying at line > 0, maybe it's choking on a UTF BOM or something? How are you trying to run it? It looks like it's trying to treat activation.jar as a Clojure source file. -- Michael Wood -- 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
Protocols and Types
Hi everyone, if I run this code: (defprotocol P (foo [x])) (deftype T [] P (foo [] "dummy")) (extends? P T) ;==> nil (satisfies? P T) ;==> nil (extenders P) ;==>nil are they not yet implemented? anyway when I run (type P) ;==> clojure.lang.PersistentArrayMap So the protocol is simply a map. I thought that P had some kind of protocol type, that extends something like: (defprotocol ProtocolProtocol (extends? [p t]) (extenders [p]) (satisfies? [p t])) (deftype Protocol [methods implementers] ProtocolProtocol (extends? [t] ...) (extenders [] ...) (satisfies? [t] ...)) Does it make any sense? -- 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
Using deftype to define mutually recursive data inside agent
Sorry my english
I use in my small clojure program one complicated mutually-recursive
data structure that represents an agent-in-environment. This structure
is clojure agent which have self-reference inside himself and
reference to environment, where environment is set of agents:
(let [a (agent {:some state})]
(send a assoc
:self (delay a) ;; this is self-reference
:env (ref (delay (set a ;; this is reference to
environment in which agent live
(await a)
a) ;; my agent
Is there a better way to declare this agent using deftype?
--
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
Some basic guidance to designing functional vs. state parts of app
As a bit of a newbie to the functional + identity/state design space, I'm struggling a bit with where to use identity constructs (refs) and where to stay with pure functions, and could use some guidance. Pardon me if some of my terms are a bit off. Here is a simple hypothetical app for matching Applicants to Jobs. I have several Applicants, each with some set of Skills. There are several Jobs, each with some Requirements. There is some Match relation between Skills and the Jobs they can match. The set of Applicants, each of their skills, and the set of Jobs can change with time. There is a set of Jobs that each Applicant can fill, functionally computed from applicant skills & job requirements & Match. Ok, so jobs_that_an_applicant_can_fill is a pure function, I get that. Do I design a single "World" ref whose state changes with time to different worlds, so adding a new Applicant or even adding a new Skill to an existing Applicant results in a new World value? Or is it better to have an "Applicants" ref and a "Jobs" ref that refer to different sets of those er.. things? Can each Applicant have a "skills" ref, whose state changes to different sets of Skills? Should I design it this way? How do I choose? What are the trade-offs? Any and all guidance, insights, advice etc. welcome! 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
Binary byte reader closure
I would like to have a function that returns the next binary byte of a file. I tried (defn reader (file) (let [in (new java.io.FileInputStream file] #(. in (read The idea is that I could call this function once and it would return a closure over the 'in' object. Then I could simply call reader to get the next byte. As in (def fetchbyte (reader "file.o")) (fetchbyte) I get an error java.lang.IllegalArgumentException: Don't know how to create ISeq from: clojure.lang.Symbol I've tried several other paths. From the REPL I can type (def in (new java.io.FileInputStream "file.o")) (def fetchbyte #(. in (read))) (fetchbyte) and it all works fine. Is there a way to return a closure in Clojure? I tried using a lazy-cons to make a lazy stream but that also failed. I tried (seq (. in (read))) to generate an iterator-style walker but that failed. Tim Daly -- 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
"Unable to resolve symbol" in third-party jarfile
As part of a project to help me learn Clojure, I'm trying to send an email using code like http://nakkaya.com/2009/11/10/using-java-mail-api-from-clojure/. For the JavaMail API I'm using GNU JavaMail, which in turn requires GNU JAF (activation.jar). When I try to run my program, I get: > Exception in thread "main" java.lang.Exception: Unable to resolve symbol: � > in this context (activation.jar:0) (The symbol in question shows up for me as a diamond with a question mark in it.) Any clues on what this could be? Since it's dying at line 0, maybe it's choking on a UTF BOM or something? -Michael -- 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
