Re: [rust-dev] First Rust gathering in Beijing, China - 17 January 2015

2014-12-11 Thread Fantix King
This is great! Definitely a must-to-attend! I'll post this great news in a
local QQ group of Chinese Rustaceans (also http://rust.cc community)

Thanks a thousand for organizing this!


BR,
Fantix
--
http://about.me/fantix

On Thu, Dec 11, 2014 at 6:45 PM, Jakub Bukaj ja...@jakub.cc wrote:

 Hello Rustaceans!

 I am pleased to inform you that there will be a Rust meet-up in
 Beijing, China on Saturday, the 17th of January 2015. Mozilla China
 has kindly agreed to host us at their Beijing office so we'll meet
 there at 14:00.

 I will be visiting Beijing at that time and will hold an introductory
 session about Rust and Servo. Otherwise we'll keep it fairly free-form
 and I hope there'll be lots of interesting discussions about
 developments in the Rust ecosystem. If you're in Beijing and would be
 interested in giving a talk about a community project or even your own
 project using Rust, please do let me know! :)

 See the Eventbrite page for this event:
 https://www.eventbrite.com/e/rust-meet-up-in-beijing-tickets-14905925023.
 There will also be more details about the gathering posted on the
 community website. [0]

 I hope to see you there!
 Jakub

 [0] http://mozilla.com.cn/
 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] First Rust gathering in Beijing, China - 17 January 2015

2014-12-11 Thread Fantix King
Thanks, Brian!

We(rust.cc) are actually the same group of people from the 中文社区 hosted on
Google Plus led by the same liigo.

Great to be a part of the bigger group!


BR,
Fantix
--
http://about.me/fantix

On Fri, Dec 12, 2014 at 2:23 AM, Brian Anderson bander...@mozilla.com
wrote:

  I added rust.cc to the list of user groups on the wiki:
 https://github.com/rust-lang/rust/wiki/Docs


 On 12/11/2014 02:53 AM, Fantix King wrote:

 This is great! Definitely a must-to-attend! I'll post this great news in a
 local QQ group of Chinese Rustaceans (also http://rust.cc community)

  Thanks a thousand for organizing this!


BR,
 Fantix
 --
 http://about.me/fantix

 On Thu, Dec 11, 2014 at 6:45 PM, Jakub Bukaj ja...@jakub.cc wrote:

 Hello Rustaceans!

 I am pleased to inform you that there will be a Rust meet-up in
 Beijing, China on Saturday, the 17th of January 2015. Mozilla China
 has kindly agreed to host us at their Beijing office so we'll meet
 there at 14:00.

 I will be visiting Beijing at that time and will hold an introductory
 session about Rust and Servo. Otherwise we'll keep it fairly free-form
 and I hope there'll be lots of interesting discussions about
 developments in the Rust ecosystem. If you're in Beijing and would be
 interested in giving a talk about a community project or even your own
 project using Rust, please do let me know! :)

 See the Eventbrite page for this event:
 https://www.eventbrite.com/e/rust-meet-up-in-beijing-tickets-14905925023.
 There will also be more details about the gathering posted on the
 community website. [0]

 I hope to see you there!
 Jakub

 [0] http://mozilla.com.cn/
 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev




 ___
 Rust-dev mailing 
 listRust-dev@mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev



 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] Mutiplexing I/O within a task

2014-07-07 Thread Fantix King


 在 2014年7月5日,下午11:07,Nat Pryce nat.pr...@gmail.com 写道:
 
 I've been trying to write tasks that wait for both I/O and channel 
 communication. I've been told that, to maximise communication performance, 
 channels do not support selecting of both channels and I/O objects.  
 Therefore a program should signal to a task that is waiting for I/O over 
 another I/O object, such as a pipe, not by sending a message over a channel.  
 Fair enough.

I was thinking about almost the same thing when trying zmq.rs, but end up with 
something very different, which might be a bit different than what is in the 
thread topic. The ioserver solution will certainly work, yet I'm trying to do 
it differently.

Let me try to start with your problem here - why it is wanted to wait on both 
I/O and channel communication? For my case, I had two reasons: (please let me 
know if your case is different)

1. Both I/O and channel may produce data at any time in any order for one piece 
of logic (task) to handle
2. It is wanted that the blocking I/O call can somehow be interrupted so that 
other code can run cooperatively.

For 1 I simply wrapped the I/O operation in a separate Task, communicating with 
the main Task with a normal channel, which can then be selected together with 
other channels. With libgreen I think it is a pretty direct decision, because 
Tasks are very cheap and cooperatively scheduled under the hood which is 
exactly what we wanted. With libnative it is a bit ugly, there might be 
hundreds of Tasks to create, so it might be sane to mix in a libgreen scheduler 
here for those Tasks.

As for 2, it does not need to be interrupted for task scheduling any more. 
However interrupt is still wanted in order to, for example, shutdown the Task. 
I used a timeout on the I/O operation (thanks to recent changes in Rust), so 
when the rest of the world is gone, the I/O call times out shortly and the Task 
fails trying to report the timeout through a broken channel. Drawback is the 
program freezes for a while on exit. For socket I/O it is also possible to be 
interrupted by close_read() or close_write() calls.

Please see also my blog post 
http://blog.segmentfault.com/fantix/119000593564 and tcp_lisrener.rs of 
zmq.rs https://github.com/zeromq/zmq.rs/blob/master/src/tcp_listener.rs.

I'd love to know if my solution for I/O is reasonable too.

BR,
Fantix

 
 What API should I use to wait for multiple I/O objects within a task?  Is 
 there a runtime-independent API for this?
 
 And if I write my own I/O abstractions, for example around eventfd on Linux, 
 what traits (platform specific traits, I imagine) should I implement to make 
 them work with the runtime-independent I/O select API?
 
 Sorry if this is already covered in the documentation.  I've searched but not 
 found anything obvious.
 
 Any help much appreciated.
 
 --Nat
 
 ___
 Rust-dev mailing list
 Rust-dev@mozilla.org
 https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


[rust-dev] [ANN] zmq.rs - native stack of ØMQ in Rus

2014-07-02 Thread Fantix King
Hi,

Here is zmq.rs, a native implementation of ØMQ in the Rust programming
language in MPLv2. I've just got a very ugly prototype running till now,
and I'm expecting to hear more comments on anything.

https://github.com/zeromq/zmq.rs

For who wants to know more about ØMQ, it looks like an embeddable
networking library but acts like a concurrency framework. It gives you
sockets that carry atomic messages across various transports like
in-process, inter-process, TCP, and multicast. You can connect sockets
N-to-N with patterns like fan-out, pub-sub, task distribution, and
request-reply. (according to http://zguide.zeromq.org/page:all)

Back to the project, I did a few iterations and got what it is now, in the
hope that more discussion can be raised over some actual code to talk
about. zmq.rs currently has REQ and REP, can `send` and `recv` in ZMTP 2.0.
I also blogged a bit about the design here (more to come):

http://blog.segmentfault.com/fantix/119000593564

You are more than welcome to:
 * comment on the design
 * suggest different solution
 * complain about whatever you don't like
 * open issues on github
 * send me PRs and code reviews
 * join me developing and maintaining it
 * or even star it on github ;)


BR,
Fantix
--
http://about.me/fantix
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev


Re: [rust-dev] [ANN] zmq.rs - native stack of ØMQ in Rus

2014-07-02 Thread Fantix King
Thank you, Corey!

Honestly I didn't dig deep about licensing. It was MIT which I think is the
most open one as BSD. Then http://zeromq.org/docs:organization suggested
MPLv2 - something between BSD and GPL just sounded also not bad for me,
so I didn't pay much attention changing to MPLv2. I wouldn't mind changing
back to MIT if that works better for the community :)

BR,
Fantix
--
http://about.me/fantix


On Wed, Jul 2, 2014 at 3:16 PM, Corey Richardson co...@octayn.net wrote:

 Complaining about something I don't like:

 Due to the choice of MPLv2, this won't be usable in the wider Rust
 ecosystem, which is MIT/ASL2 focused. In particular, section 3.2(a)
 requires that any distribution in Executable Form carry a notice
 about how to acquire the source code of zmq.rs. This is not
 unworkable, but it is something we have avoided so far in the
 community.

 Otherwise, I look forward to reviewing this in more depth tomorrow. Nice
 work!

 On Tue, Jul 1, 2014 at 11:38 PM, Fantix King fantix.k...@gmail.com
 wrote:
  Hi,
 
  Here is zmq.rs, a native implementation of ØMQ in the Rust programming
  language in MPLv2. I've just got a very ugly prototype running till now,
 and
  I'm expecting to hear more comments on anything.
 
  https://github.com/zeromq/zmq.rs
 
  For who wants to know more about ØMQ, it looks like an embeddable
 networking
  library but acts like a concurrency framework. It gives you sockets that
  carry atomic messages across various transports like in-process,
  inter-process, TCP, and multicast. You can connect sockets N-to-N with
  patterns like fan-out, pub-sub, task distribution, and request-reply.
  (according to http://zguide.zeromq.org/page:all)
 
  Back to the project, I did a few iterations and got what it is now, in
 the
  hope that more discussion can be raised over some actual code to talk
 about.
  zmq.rs currently has REQ and REP, can `send` and `recv` in ZMTP 2.0. I
 also
  blogged a bit about the design here (more to come):
 
  http://blog.segmentfault.com/fantix/119000593564
 
  You are more than welcome to:
   * comment on the design
   * suggest different solution
   * complain about whatever you don't like
   * open issues on github
   * send me PRs and code reviews
   * join me developing and maintaining it
   * or even star it on github ;)
 
 
  BR,
  Fantix
  --
  http://about.me/fantix
 
  ___
  Rust-dev mailing list
  Rust-dev@mozilla.org
  https://mail.mozilla.org/listinfo/rust-dev
 



 --
 http://octayn.net/

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev