Re: Q: How to parse stream of text (from java.io.Reader) via instaparse with minimal input consuption
If you have any control over the writer end you could also choose a specific terminal character that is not otherwise in your grammar and insert it before the next data set. Then you could be assured of a full parse. -- 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.
Q: How to parse stream of text (from java.io.Reader) via instaparse with minimal input consuption
I didn't know Instaparse supported readers. Is there no way to read from the stream into a string until the terminal character for your grammar is found and parse that ? I assume you have no control over the source data? -- 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: Best way to work with an optional type
While I think the latter two solutions show off Clojures ease of extensibility, I personally believe the first technique is more appropriate for the current wxample. I mean, how many different ways of calculating and rounding a percentage are there? -- 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: Propagating data through dependencies
What I meant was that you use all b's to generate the max date for B (used as input for its dependencies) but simply bundle all b's into B's bill. You can't bill them before or after B because they're effectively line items on B. -- 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.
Propagating data through dependencies
You said b can't be billed after B. But it sounds like it can't be billed before. Say b is ready at 1, can you bill it at 1 and then B at 2? Anyway, my first thought was using weights on the edges equal to the duration between the dependencies and use a max cost on the graph. But calculating the duration for each edge may not gain you anything compared to your current solution. If it ain't broke ... -- 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.
Propagating data through dependencies
If, say C cannot depend on any b directly, (I.e. C can only depend on B), and your domain rules say you can only bill for all b's when you bill B, then really you have a self contained sub-graph with only one bill date for the root node B. You can simply ignore backfilling the billing date for b's and just bundle them into the bill for B when you generate it. -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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: How should I begin this project?
I second Google Calendar. You can make appointments show as busy so the details are not shared with all clients. Then share your calendar with each client. You can invite specific clients to specific appointments via email, make some of them recurring, and it's up to the client to respond to say they can make it or not. If a client uses iCal or Google calendar themselves they can share that with you and you can overlay multiple calendars on the same view so it's easy to spot conflicts -- 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: Om 0.3.0
Did you get this fixed Rudi?
If your project file requires om 0.2.3, then it was something with the
lein new command (which is now fixed).
I recommend manually changing the project file to require om 0.3.0 and then
don't forget to lein cljscript clean before recompiling (which I did).
On Saturday, January 25, 2014 1:41:54 PM UTC-8, Rudi Engelbrecht wrote:
Hi David
Thank you for a great tutorial!
I really enjoyed working through your Tutorial on LightTable and Om.
A note: In my environment the contact is being deleted when the
contact-view has the following code
(defn contact-view [contact owner]
(reify
om/IRenderState
(render-state [this {:keys [delete]}]
(dom/li nil
(dom/span nil (display-name contact))
(dom/button #js {:onClick (fn [e] (put! delete contact))}
Delete)
and not when it is the following:
(defn contact-view [contact owner]
(reify
om/IRenderState
(render-state [this {:keys [delete]}]
(dom/li nil
(dom/span nil (display-name contact))
(dom/button #js {:onClick (fn [e] (put! delete @contact))}
Delete)
So the change to
(put! delete @contact)
has the effect of the delete button not working anymore.
I will investigate further.
Kind regards
Rudi
On Jan 25, 2014, at 11:16 AM, David Nolen dnolen...@gmail.comjavascript:
wrote:
A few minor simplifications to the Om model in this release. A breaking
change if you were using om.core/bind, om.core/pure-bind or om.core/read -
these complications have been removed.
There's also now a tutorial optimized for Light Table for people want to
understand the Om approach to React without losing time cobbling together a
working environment: http://github.com/swannodette/om/wiki/Tutorial
Have fun!
David
--
--
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 javascript:
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 javascript:
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+u...@googlegroups.com javascript:.
For more options, visithttps://groups.google.com/groups/opt_out.
--
--
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: [ClojureScript] Re: ANN: Om 0.3.0
I'm a big fan of this new tutorial. It hi-lights some of the benefits of cursors, and I actually realize how I might use om/join suddenly :D -- -- 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: [ClojureScript] Re: ANN: Om 0.3.0
Well at least I can know guess at the etymology : sql join leaps to mind, joining on a different branch of the state tree with keys from another branch. I didn't understand that until I read your tutorial. On Monday, January 27, 2014 10:35:54 AM UTC-8, David Nolen wrote: om/join is conceptually quite cool, but it actually needs some serious work as alluded - currently you're likely to run into some nasty surprises if you really try to use it. The tutorials aren't going to proceed until this is addressed sometime this week. David -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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: Om 0.3.0
I was following along with this and hit an interesting bug The contact list delete button actually works out of the gate in the first example, (when its supposed to fail) and when I add the deref in the next step I get Uncaught Error: No protocol method IDeref.-deref defined for type om.core/MapCursor: [object Object] And that was with 0.2.3 and 0.3.0 (I tried both) -- -- 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: Om, a ClojureScript binding to Facebook's React
Ha! Just saw your Sortable example popup in Git! Very cool. On Thursday, January 2, 2014 4:00:45 PM UTC-8, David Pidcock wrote: Very nice. Relatively easy to follow. Basically it's re-implementing the drag-list behaviour in React. I had thought to re-use some existing code, provided I could inform React that the DOM was changing. (This is the approach used by the example in the fiddler, albeit with jquery instead of goog.closure as the UI manipulation library) I'm very interested to see what you do with this, in Om. This example is complex enough that following along would most likely fill in the conceptual gaps for me, that the TODO example lacks. Again - inspiring work.. -- David On Monday, December 30, 2013 10:02:37 PM UTC-8, David Nolen wrote: From a React dev: https://www.khanacademy.org/preview/content/items/xfa03b103 https://github.com/Khan/perseus/blob/master/src/widgets/orderer.jsx#L6-L439 I'm sure this can be adapted for Om. I may write up a simpler Om example in the future. David On Tue, Dec 31, 2013 at 12:43 AM, David Pidcock eraz0...@gmail.com wrote: On Thursday, December 19, 2013 11:12:12 AM UTC-8, David Nolen wrote: Enjoy, http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ David I've been playing around with some basics. I'm still a relative n00b when it comes to functional programming, and I've never looked at React before. Very cool stuff. I managed to get Om+React to display a list of items that are sorted by a given key, and I have a content-editable span which updates the state of the owner with new value of that key for a given item, and voila! the list item moves to the correct position. (as expected) Now here's the tricky part... I want to implement a drag-list, where I can drag-drop items into a new position, and update the key based on the new position. I have that algorithm working in a different project (using goog.DragListGroup) , but React does not like you to manipulate the DOM outside it's knowledge. I found this : https://groups.google.com/forum/#!searchin/reactjs/sortable/reactjs/mHfBGI3Qwz4/rXSr-1QUcKwJ which lead to http://jsfiddle.net/LQxy7/ Unfortunately, I can't get this to work with Om. I am having trouble navigating the data structures. How are props created/accessed? I followed the TodoMVC example, but that seems to be using state, which I am given to understand should be kept as high in the hierarchy as possible (per the React recommendations). I tried something like (:value (om/get-props this)) from within IRender, but that doesn't work. Also : (om/get-props this [:items] ) (following the idiom established by get-state. I'm probably missing something obvious, so I thought I'd pop in here to see if there's someone who can point me in the right direction. -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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: Om, a ClojureScript binding to Facebook's React
Very nice. Relatively easy to follow. Basically it's re-implementing the drag-list behaviour in React. I had thought to re-use some existing code, provided I could inform React that the DOM was changing. (This is the approach used by the example in the fiddler, albeit with jquery instead of goog.closure as the UI manipulation library) I'm very interested to see what you do with this, in Om. This example is complex enough that following along would most likely fill in the conceptual gaps for me, that the TODO example lacks. Again - inspiring work.. -- David On Monday, December 30, 2013 10:02:37 PM UTC-8, David Nolen wrote: From a React dev: https://www.khanacademy.org/preview/content/items/xfa03b103 https://github.com/Khan/perseus/blob/master/src/widgets/orderer.jsx#L6-L439 I'm sure this can be adapted for Om. I may write up a simpler Om example in the future. David On Tue, Dec 31, 2013 at 12:43 AM, David Pidcock eraz0...@gmail.comjavascript: wrote: On Thursday, December 19, 2013 11:12:12 AM UTC-8, David Nolen wrote: Enjoy, http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ David I've been playing around with some basics. I'm still a relative n00b when it comes to functional programming, and I've never looked at React before. Very cool stuff. I managed to get Om+React to display a list of items that are sorted by a given key, and I have a content-editable span which updates the state of the owner with new value of that key for a given item, and voila! the list item moves to the correct position. (as expected) Now here's the tricky part... I want to implement a drag-list, where I can drag-drop items into a new position, and update the key based on the new position. I have that algorithm working in a different project (using goog.DragListGroup) , but React does not like you to manipulate the DOM outside it's knowledge. I found this : https://groups.google.com/forum/#!searchin/reactjs/sortable/reactjs/mHfBGI3Qwz4/rXSr-1QUcKwJ which lead to http://jsfiddle.net/LQxy7/ Unfortunately, I can't get this to work with Om. I am having trouble navigating the data structures. How are props created/accessed? I followed the TodoMVC example, but that seems to be using state, which I am given to understand should be kept as high in the hierarchy as possible (per the React recommendations). I tried something like (:value (om/get-props this)) from within IRender, but that doesn't work. Also : (om/get-props this [:items] ) (following the idiom established by get-state. I'm probably missing something obvious, so I thought I'd pop in here to see if there's someone who can point me in the right direction. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: 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 javascript: 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+u...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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: Om, a ClojureScript binding to Facebook's React
On Thursday, December 19, 2013 11:12:12 AM UTC-8, David Nolen wrote: Enjoy, http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ David I've been playing around with some basics. I'm still a relative n00b when it comes to functional programming, and I've never looked at React before. Very cool stuff. I managed to get Om+React to display a list of items that are sorted by a given key, and I have a content-editable span which updates the state of the owner with new value of that key for a given item, and voila! the list item moves to the correct position. (as expected) Now here's the tricky part... I want to implement a drag-list, where I can drag-drop items into a new position, and update the key based on the new position. I have that algorithm working in a different project (using goog.DragListGroup) , but React does not like you to manipulate the DOM outside it's knowledge. I found this : https://groups.google.com/forum/#!searchin/reactjs/sortable/reactjs/mHfBGI3Qwz4/rXSr-1QUcKwJ which lead to http://jsfiddle.net/LQxy7/ Unfortunately, I can't get this to work with Om. I am having trouble navigating the data structures. How are props created/accessed? I followed the TodoMVC example, but that seems to be using state, which I am given to understand should be kept as high in the hierarchy as possible (per the React recommendations). I tried something like (:value (om/get-props this)) from within IRender, but that doesn't work. Also : (om/get-props this [:items] ) (following the idiom established by get-state. I'm probably missing something obvious, so I thought I'd pop in here to see if there's someone who can point me in the right direction. -- -- 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: Difficulty working with complex protobuf objects [protobuf 0.6.2]
Well today has been the first chance I've had to try this, and
unfortunately, it's the same output. I _think_ the object ( and I use the
term loosely ) is being created more or less successfully, since I can
usually navigate to some of the sub-lists / maps
Not only that, but referencing one particular key I get a runtime exception
-- as follows:
(first (:inventory my-obj)))
{:header {:id 174927}, :count 50}
RuntimeException Unmatched delimiter: ) clojure.lang.Util.runtimeException
(Util.java:219)
This was using java classes generated by the 2.4.1 google exe. When I
get more time, I'm going to regenerate them with the lein proto plugin.
On Friday, April 12, 2013 8:08:01 AM UTC-7, David Pidcock wrote:
Thanks - I'll give that a try.
On Thursday, April 11, 2013 11:18:06 AM UTC-7, Alan Malloy wrote:
0.6.2 is six months old. I don't think anything about this has changed
since then, but you should at least try [org.flatland/protobuf 0.7.2] and
see if that does what you expect.
On Thursday, April 11, 2013 8:39:12 AM UTC-7, David Pidcock wrote:
I have some Java classes generated elsewhere (not by the lein proto
plugin) and I'm wanting to use them as the basis for the [protobuf
0.6.2] code interactions (for interdependency with an existing java
project)
One thing I noticed about the output in REPL is that only the first key
is presented to the screen from protobuf.core.PersistentProtocolBufferMap
Even (keys my-proto) only shows the first key
At first I thought I'd screwed something up, but when I try
(:some-key my-proto)
I get the expected result.
The data referenced by :some-key in this instance is another map --
almost all of the data contained in the message is complex like this.
Is this a bug in protobuf.core.PersistentProtocolBufferMap? Or am I
missing something?
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To 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: Difficulty working with complex protobuf objects [protobuf 0.6.2]
Well, using the Lein protobuf generator at least helps with the Exception,
but it doesn't help with showing the full map. I didn't forget to import
the extensions.proto (which I thought would be the source of my problem
with the generated-for-java classes)
I haven't delved into the toString, but the behviour looks like a
depth-first print that bails before it gets to the other elements of the
map.
On Saturday, April 20, 2013 4:54:08 PM UTC-7, David Pidcock wrote:
Well today has been the first chance I've had to try this, and
unfortunately, it's the same output. I _think_ the object ( and I use the
term loosely ) is being created more or less successfully, since I can
usually navigate to some of the sub-lists / maps
Not only that, but referencing one particular key I get a runtime
exception -- as follows:
(first (:inventory my-obj)))
{:header {:id 174927}, :count 50}
RuntimeException Unmatched delimiter: )
clojure.lang.Util.runtimeException (Util.java:219)
This was using java classes generated by the 2.4.1 google exe. When I
get more time, I'm going to regenerate them with the lein proto plugin.
On Friday, April 12, 2013 8:08:01 AM UTC-7, David Pidcock wrote:
Thanks - I'll give that a try.
On Thursday, April 11, 2013 11:18:06 AM UTC-7, Alan Malloy wrote:
0.6.2 is six months old. I don't think anything about this has changed
since then, but you should at least try [org.flatland/protobuf 0.7.2] and
see if that does what you expect.
On Thursday, April 11, 2013 8:39:12 AM UTC-7, David Pidcock wrote:
I have some Java classes generated elsewhere (not by the lein proto
plugin) and I'm wanting to use them as the basis for the [protobuf
0.6.2] code interactions (for interdependency with an existing java
project)
One thing I noticed about the output in REPL is that only the first key
is presented to the screen from protobuf.core.PersistentProtocolBufferMap
Even (keys my-proto) only shows the first key
At first I thought I'd screwed something up, but when I try
(:some-key my-proto)
I get the expected result.
The data referenced by :some-key in this instance is another map --
almost all of the data contained in the message is complex like this.
Is this a bug in protobuf.core.PersistentProtocolBufferMap? Or am I
missing something?
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To 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: Difficulty working with complex protobuf objects [protobuf 0.6.2]
Hmm - I think I'm on to something.
I noticed that some of the nested maps were printing more than the first
element.
When i checked the _schema_ displayed by (protobuf-schema def) , all
the keys in the schema are lower case
The generated java classes for this proto are camelCase.
So the printer for the map is finding nulls for many of the keys in the
schema, and so it's skipping them.
On Saturday, April 20, 2013 5:39:16 PM UTC-7, David Pidcock wrote:
Well, using the Lein protobuf generator at least helps with the Exception,
but it doesn't help with showing the full map. I didn't forget to import
the extensions.proto (which I thought would be the source of my problem
with the generated-for-java classes)
I haven't delved into the toString, but the behviour looks like a
depth-first print that bails before it gets to the other elements of the
map.
On Saturday, April 20, 2013 4:54:08 PM UTC-7, David Pidcock wrote:
Well today has been the first chance I've had to try this, and
unfortunately, it's the same output. I _think_ the object ( and I use the
term loosely ) is being created more or less successfully, since I can
usually navigate to some of the sub-lists / maps
Not only that, but referencing one particular key I get a runtime
exception -- as follows:
(first (:inventory my-obj)))
{:header {:id 174927}, :count 50}
RuntimeException Unmatched delimiter: )
clojure.lang.Util.runtimeException (Util.java:219)
This was using java classes generated by the 2.4.1 google exe. When I
get more time, I'm going to regenerate them with the lein proto plugin.
On Friday, April 12, 2013 8:08:01 AM UTC-7, David Pidcock wrote:
Thanks - I'll give that a try.
On Thursday, April 11, 2013 11:18:06 AM UTC-7, Alan Malloy wrote:
0.6.2 is six months old. I don't think anything about this has changed
since then, but you should at least try [org.flatland/protobuf 0.7.2]
and
see if that does what you expect.
On Thursday, April 11, 2013 8:39:12 AM UTC-7, David Pidcock wrote:
I have some Java classes generated elsewhere (not by the lein proto
plugin) and I'm wanting to use them as the basis for the [protobuf
0.6.2] code interactions (for interdependency with an existing
java project)
One thing I noticed about the output in REPL is that only the first
key is presented to the screen
from protobuf.core.PersistentProtocolBufferMap
Even (keys my-proto) only shows the first key
At first I thought I'd screwed something up, but when I try
(:some-key my-proto)
I get the expected result.
The data referenced by :some-key in this instance is another map --
almost all of the data contained in the message is complex like this.
Is this a bug in protobuf.core.PersistentProtocolBufferMap? Or am I
missing something?
--
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To 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: Difficulty working with complex protobuf objects [protobuf 0.6.2]
Thanks - I'll give that a try. On Thursday, April 11, 2013 11:18:06 AM UTC-7, Alan Malloy wrote: 0.6.2 is six months old. I don't think anything about this has changed since then, but you should at least try [org.flatland/protobuf 0.7.2] and see if that does what you expect. On Thursday, April 11, 2013 8:39:12 AM UTC-7, David Pidcock wrote: I have some Java classes generated elsewhere (not by the lein proto plugin) and I'm wanting to use them as the basis for the [protobuf 0.6.2] code interactions (for interdependency with an existing java project) One thing I noticed about the output in REPL is that only the first key is presented to the screen from protobuf.core.PersistentProtocolBufferMap Even (keys my-proto) only shows the first key At first I thought I'd screwed something up, but when I try (:some-key my-proto) I get the expected result. The data referenced by :some-key in this instance is another map -- almost all of the data contained in the message is complex like this. Is this a bug in protobuf.core.PersistentProtocolBufferMap? Or am I missing something? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To 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.
Difficulty working with complex protobuf objects [protobuf 0.6.2]
I have some Java classes generated elsewhere (not by the lein proto plugin) and I'm wanting to use them as the basis for the [protobuf 0.6.2] code interactions (for interdependency with an existing java project) One thing I noticed about the output in REPL is that only the first key is presented to the screen from protobuf.core.PersistentProtocolBufferMap Even (keys my-proto) only shows the first key At first I thought I'd screwed something up, but when I try (:some-key my-proto) I get the expected result. The data referenced by :some-key in this instance is another map -- almost all of the data contained in the message is complex like this. Is this a bug in protobuf.core.PersistentProtocolBufferMap? Or am I missing something? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To 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.
