Re: Extend-protocol to numbers fails with zero in CLJS

2014-06-06 Thread Logan Linn
It will work for 0 if you use `number` instead of `js/Number`. Generally 
you shouldn't extend any js/* type

On Friday, June 6, 2014 9:57:38 AM UTC-7, Karsten Schmidt wrote:

 I'm trying to extend-protocol for numbers and various other types (incl. 
 collections  nil) in CLJS, so have been doing something like this (reduced 
 email version):

 (defprotocol PDeltaEq (delta= [a b]))

 (extend-protocol PDeltaEq
   js/Number
   (delta= [a b] :yay)

   nil
   (delta= [_ b] (nil? b)))

 (delta= 1 1)
 ;; :yay

 (delta= 0 0)
 Error: No protocol method Foo.foo defined for type number: 0

 Now I guessed, this might have something to do with JS' considering 0 as 
 `false` somewhere in the internal protocol machinery... and I was right! 
 Here's a relevant excerpt from the compiled protocol dispatch fn:

 var delta_EQ___2 = function(a, b) {
   if (function() {
 var and__3466__auto__ = a;
 if (and__3466__auto__) {
   return a.thi$ng$common$math$core$PDeltaEq$delta_EQ_$arity$2;
 } else {
   return and__3466__auto__;
 }
   }()) {
 return a.thi$ng$common$math$core$PDeltaEq$delta_EQ_$arity$2(a, b);
   } else {
 
   }
 };

 Obviously, with the `a` arg being 0, that `if (and__3466__auto__)` check 
 is always failing, so shouldn't this check be rewritten as:

 if (goog.isDefAndNotNull(and__3466__auto__) 
 a.thi$ng$common$math$core$PDeltaEquals$delta_EQ_$arity$2) {
   return a.thi$ng$common$math$core$PDeltaEquals$delta_EQ_$arity$2;
 }
 ...

 This change seems to fix this kind of error and AFAIK doesn't impact any 
 of my other (30+) test cases for this protocol...

 Thoughts? :)

 Thanks, K.
  

-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: core.async over websocket + cljs + clojure

2014-01-24 Thread Logan Linn


 To be reliable you'd have to introduce addition machinery to account for 
 the hazards of distributed systems, so you're probably better off starting 
 with an abstraction that has those hazards in mind already.


The WebSocket (protocol) is the machinery that's handling this. We aren't 
discussing using CSP to implement the actual network communication. We 
aren't concerned what happens outside of the edges of the system.

Unlike when using actors, with CSP you don't care where a value you took 
from a channel came from, and similarly you don't care where the value you 
put onto a channel goes. The channel is only a primitive for conveyance. 
The application knows nothing of a WebSocket other than what does the put!s 
and take!s.

CSP-like channels aren't a good across-the-wire abstraction. Their blocking 
 semantics are intended to coordinate concurrency within a single runtime.


Coordination is possible through the blocking semantics of CSP, but isn't 
the only mechanism it provides. CSP also facilitates buffered, asynchronous 
operations. I don't see why it would imply anything about a single runtime.
 

On Friday, January 24, 2014 4:45:01 PM UTC-8, Patrick Logan wrote:

   * one side of the channel is in clojure land
   * other side of the channel is in cljs land

 Are you implementing coordination across the wire, as if the two channels 
 are the same virtual channel? If so, read on... otherwise, n/m, sorry if 
 I misinterpreted...

 CSP-like channels aren't a good across-the-wire abstraction. Their 
 blocking semantics are intended to coordinate concurrency within a single 
 runtime.

 To be reliable you'd have to introduce addition machinery to account for 
 the hazards of distributed systems, so you're probably better off starting 
 with an abstraction that has those hazards in mind already.

 I'm unsure what the arguments would be in favor of CSP-like behavior 
 across distances, especially between a server (clj) and a browser (cljs)?



-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: core.async over websocket + cljs + clojure

2014-01-23 Thread Logan Linn
I've been working on a game in my spare time that does this.

The Clojure backend and ClojureScript client communicate with core.async 
over WebSocket carrying edn data

Game: https://github.com/loganlinn/ji
Client WebSocket using: https://github.com/loganlinn/cljs-websockets-async
Server WebSocket using: https://github.com/lynaghk/jetty7-websockets-async

I had hoped to have writeup about this technique by now, but coding seems 
to take higher priority when I get free time :P

On Wednesday, January 22, 2014 11:39:06 PM UTC-8, t x wrote:

 Hi,

   I apologize for my vague question.

   Does anyone have a good example / blog / library for using the 
 core.async abstraction across a websocket.

   * one side of the channel is in clojure land
   * other side of the channel is in cljs land

   * I promise that all messages can be encoded via pr-str and read via 
 clojure.edn/read-string

   What I'm struggling with are matters of:

   * how to ensure data is not lost even when websocket disconects / 
 reconnects

   * naming on client/server side to ensure messages go to right channels 
 on both sides

   * issues I haven't even begun to imagine.

   Good news:

   * I control both sides: both the clj and cljs side, so any workable 
 design is fine.

 Thanks!


-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [ANN]: Clojure/West 2014 - San Francisco - March 24-26

2014-01-10 Thread Logan Linn
This was great news to hear. Looking forward to it.

Talks will be presented in two tracks


Does this mean there will be two stages/presentations at a time?

On Thursday, January 9, 2014 8:01:13 PM UTC-8, Alex Miller wrote:

 At long last, we have finalized the plans for Clojure/West 2014!  

 Site: http://clojurewest.org
 Date: March 24-25 conference, March 26 hackfest!
 Venue: Palace Hotel, San Francisco 
 http://www.sfpalace.com/
 https://goo.gl/maps/pBXav

 Call for Presentations:
 - 
 https://cognitect.wufoo.com/forms/clojurewest-2014-call-for-presentations/
 - Open from now till Jan 24th (yes, that's soon!)
 - Speakers receive: free admission, up to 3 nights hotel, US airfare or 
 $450 stipend if international
 - Tracks (sessions are 40 minutes): 
 1) Core Clojure - Talks that focus on core usage of Clojure or 
 ClojureScript, focused mostly (but not exclusively) on the less experienced 
 Clojure developer. Examples: language features, techniques, libraries, 
 tools.
 2) Production Clojure - Talks from and for those doing Clojure or 
 ClojureScript in production systems or products. Examples: integrating with 
 existing code bases, creating and communicating designs, structuring your 
 code, performance, management and organization.
 3) Crazy Clojure - Talks from those probing the boundaries of Clojure or 
 bringing Clojure into amazing new areas. Examples: music, art, alternate 
 hosts, space stations, donuts, etc.

 Talks will be presented in two tracks on March 24-25th. On the 26th, we 
 will have space available for people to get together and do what we all 
 love: write some Clojure! More info to come.

 We expect early bird registration and the sponsorship prospectus to be 
 available soon.

 Please let us know if you have any questions!

 Alex Miller and Lynn Grogan
 Questions: clojur...@cognitect.com javascript:






-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


My recap of Clojure/conj 2013

2013-11-20 Thread Logan Linn
I've posted a writeup of my experience from this year's Clojure/conj and 
wanted to share with those who couldn't make it: 
http://loganlinn.com/blog/2013/11/18/clojureconj-2013/

Big thanks to all who helped organize  operate the event!

-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: ANN: Clojure 1.5

2013-03-01 Thread Logan Linn
Congrats and thanks to all those who contributed!

On Friday, March 1, 2013 7:56:58 AM UTC-8, stuart@gmail.com wrote:

 We are pleased to announce the release of Clojure 1.5.

 Getting Clojure:

   Web:  http://clojure.org/downloads
   Lein/Maven:   :dependencies [[org.clojure/clojure 1.5.0]]

 Note that it will take a few hours for the links above to become live,
 as the completed build moves into Maven Central.

 This release includes significant features and bug fixes, documented
 here:

   https://github.com/clojure/clojure/blob/master/changes.md

 The number of Clojure contributors continues to grow. Thanks to all
 the people whose code is included in this release:

 Aaron Bedra 
 Alan Malloy
 Alex Redington  
 Alf Kristian Stoyle 
 Ambrose Bonnaire-Sergeant 
 Andy Fingerhut 
 Brandon Bloom 
 Brenton Ashworth 
 Bronsa 
 Chas Emerick 
 Christophe Grand 
 Colin Jones 
 Cosmin Stejerean 
 Daniel Solano Gómez 
 David Powell 
 David Santiago 
 Ed Bowler 
 Federico Brubacher 
 Gabriel Horner 
 Gary Fredericks 
 Herwig Hochleitner 
 Hubert Iwaniuk 
 Hugo Duncan 
 John Szakmeister 
 Juha Arpiainen 
 Justin Kramer 
 Kevin Downey 
 Laurent Petit 
 Meikel Brandmeyer 
 Michael Fogus
 Michał Marczyk 
 Michel Alexandre Salim 
 Philip Aston 
 Philip Potter 
 Rich Hickey 
 Scott Lowe 
 Steve Miner 
 Stuart Halloway 
 Stuart Sierra 
 Tassilo Horn 
 Toby Crawley 
 Tom Faulhaber 

 Thanks to all involved!

 Stu Halloway
 Clojure/core





-- 
-- 
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.