Re: [ANN] Taoensso library updates / 2014 September
> > No problem. I just wanted to check that it was an intentional change, and > not some unknown bug that had crept in. Sure, appreciate that. And one had (buggy CHANGELOG) - so good that you checked ;-) I just switched my app from Om/Sablono + Sente to Reagent + Sente and I'm > currently working on cleaning things up now that Reagent has allowed for > quite a bit of simplification so I'm in refactoring mode at the moment... > Reagent's great, can't recommend it enough. > About the only thing I could ask for is IE8 compatibility :) Hmm, yeah - haven't looked into that myself. Can't think of anything off-hand that'd make it impossible, PR would absolutely be welcome. Cheers! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- 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: Sente 1.0.0 (was: [ANN] Taoensso library updates / 2014 September
Ah, I remember why now: Since the event loop is in a 'go' block and because I didn't want slow event handlers blocking everything, I wanted to dispatch my event handler in a (thread ...) call. Perhaps start-chsk-router! could take an optional argument to indicate the handler call should be spun off in a thread? I'll go open an issue for this on Sente's Github repo for discussion. Sean On Sep 6, 2014, at 3:48 PM, Sean Corfield wrote: > On Sep 6, 2014, at 3:55 AM, Hugo Duncan wrote: >> Did you change `start-chsk-router-loop!` to `start-chsk-router!`? > > I don't use those. I read directly from ch-recv due to some of the stuff I > needed to do (when I first started using Sente). I may revisit this now... > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Sente 1.0.0 (was: [ANN] Taoensso library updates / 2014 September
On Sep 6, 2014, at 3:55 AM, Hugo Duncan wrote: > Did you change `start-chsk-router-loop!` to `start-chsk-router!`? I don't use those. I read directly from ch-recv due to some of the stuff I needed to do (when I first started using Sente). I may revisit this now... Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [ANN] Taoensso library updates / 2014 September
On Sep 6, 2014, at 5:01 AM, Peter Taoussanis wrote: > The upgrade to v1.0.0 *is* actually breaking *if* you've been reading from > the client-side :ch-recv directly. Most folks use the provided router utils, > so it slipped my mind to document that - I'm really sorry. No problem. I just wanted to check that it was an intentional change, and not some unknown bug that had crept in. > Client-side :ch-recv used to receive `event` vectors, and now instead > receives `event-msg` maps like the server. Yup, this makes much more sense. It just took a while to figure out why my app broke, but it was an easy fix. > 3. The extra data in `event-msg`s makes it easier to write functional event > handlers (i.e. that don't need access to a global send-fn or ch-recv). I'll have to see if that can make my code easier to work with. I may try to refactor my code to work with the regular router loop but when I first started out, there were things I needed to do that wouldn't quite fit that mould. > 4. That all event handlers now take a map makes future changes > easier/non-breaking (we can add extra interesting keys in time w/o needing > event handlers to change, etc.). Definitely an improvement. I just switched my app from Om/Sablono + Sente to Reagent + Sente and I'm currently working on cleaning things up now that Reagent has allowed for quite a bit of simplification so I'm in refactoring mode at the moment... > Please feel free to drop me an email if you run into any more trouble. About the only thing I could ask for is IE8 compatibility :) I haven't poked at that area too much but it looked like something in XhrIo failed in IE8 (related to Web Sockets and not failing back gracefully I think?). If we had IE8 compatibility, I could use Sente for several user-facing things in production, as opposed to just internal-facing stuff in production. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: how do you name your protocols?
Clojure API exposes types to the user (Agent, Ref, Var, ...), so it is benefical to see on the first glance whether the name is of a type or interface/protocol. If the API would be built solely on the protocols/interfaces, those prefixes would be of less use. Moreover, I think that names of types should be nouns (e.g. Atom) and names of protocols should be adjectives/verbs (e.g. ICounted), with the exception of protocols which represent an abstract type (e.g. IPersistentList) Jozef On Sat, Sep 6, 2014 at 6:40 PM, Bobby Eickhoff wrote: > What might be an advantage to using something like the I-prefix? At first > glance, this appears to be unbeneficial hungarian notation. > > Aesthetically, this seems backwards (to me). I want interfaces and > protocols to have the most readable names. I'm willing to concede on less > readable names for concrete implementations. Many implementations and > participants will even be anonymous. > > On Friday, September 5, 2014 5:52:48 AM UTC-4, Dave Sann wrote: >> >> I saw a comment on protocol naming here: >> https://groups.google.com/d/msg/clojure/A4xIitQWloU/6E4xHDTPPaIJ >> >> there is nothing in the coding standards: >> http://dev.clojure.org/display/community/Library+Coding+Standards (are these >> maintained?) >> >> is there any sensible consensus on good naming convention? >> >> IBlah >> PBlah >> BlahP >> Blah >> ...other >> >> ...doesn't matter >> >> Dave > > -- > 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. -- 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 do you name your protocols?
What might be an advantage to using something like the I-prefix? At first glance, this appears to be unbeneficial hungarian notation. Aesthetically, this seems backwards (to me). I want interfaces and protocols to have the most readable names. I'm willing to concede on less readable names for concrete implementations. Many implementations and participants will even be anonymous. On Friday, September 5, 2014 5:52:48 AM UTC-4, Dave Sann wrote: > > I saw a comment on protocol naming here: > https://groups.google.com/d/msg/clojure/A4xIitQWloU/6E4xHDTPPaIJ > > there is nothing in the coding standards: > http://dev.clojure.org/display/community/Library+Coding+Standards (are > these maintained?) > > is there any sensible consensus on good naming convention? > > IBlah > PBlah > BlahP > Blah > ...other > > ...doesn't matter > > Dave > -- 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] Taoensso library updates / 2014 September
Hi Sean, thank you for pinging about this. The upgrade to v1.0.0 *is* actually breaking *if* you've been reading from the client-side :ch-recv directly. Most folks use the provided router utils, so it slipped my mind to document that - I'm really sorry. Will update the README and CHANGELOG now. In the meantime, the change you need to make: Server-side :ch-recv used to receive `event-msg` maps, and still does (no change). Client-side :ch-recv used to receive `event` vectors, and now instead receives `event-msg` maps like the server. Server-side `event-msg` maps contain keys: :ch-recv, :send-fn, :connected-uids, :client-uuid, :ring-req, :event, :?reply-fn. Client-side `event-msg` maps contain keys: :ch-recv, :send-fn, :state, :event. So (:event ) will get you the old event vector. Motivations behind this change: 1. Client+server :ch-recv values are now consistent (both receive `event-msg`s). 2. Client+server routing is therefore now consistent. 3. The extra data in `event-msg`s makes it easier to write functional event handlers (i.e. that don't need access to a global send-fn or ch-recv). 4. That all event handlers now take a map makes future changes easier/non-breaking (we can add extra interesting keys in time w/o needing event handlers to change, etc.). Definitely should be documented though, again - really sorry about that! Please feel free to drop me an email if you run into any more trouble. Cheers! :-) - Peter Taoussanis > -- 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: Sente 1.0.0 (was: [ANN] Taoensso library updates / 2014 September
s...@corfield.org writes: > Is that an intentional change? I ask because you claimed the release was > major but non-breaking - and this seems to be a breaking change...? Did you change `start-chsk-router-loop!` to `start-chsk-router!`? The former maintains the previous event handler signature (and is thus non-breaking), but the later requires the new signature. Hugo signature.asc Description: PGP signature
Re: [ANN] Clojure 1.7.0-alpha2
Great stuff, and thanks for all the hard work. But if I may, I'd like to suggest that "completing" isn't a great name for that transducer helper function-- at least not in the core namespace. It's too generic: there's no way to guess what it does from the name, and IMO a function with such a niche role doesn't merit such a basic name. Granted I can't think of a slam-dunk alternative, but what about something like "trans-complete"? -- 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.
Sente 1.0.0 (was: [ANN] Taoensso library updates / 2014 September
Peter, I just upgraded from Sente 0.15.1 to 1.0.0 and it looks like the values that come in ch-recv have changed format? I used to have the following: (go (loop [[op arg] ( wrote: > (All new releases are now on BreakVersioning, > https://github.com/ptaoussanis/encore/blob/master/BREAK-VERSIONING.md). > > Sente - v1.0.0 / 2014 Sep 2 (today) > == > Realtime web comms for Clojure/Script (think Socket.IO but with Transit & > core.async). > https://github.com/ptaoussanis/sente/releases > Notable recent changes: v1 release, optional Transit support, efficiency > improvements (perf+bandwidth). signature.asc Description: Message signed with OpenPGP using GPGMail
