Re: [rust-dev] A shiny test framework
It's great to see Hamcrest ported to Rust.
On 22 July 2014 20:06, Vladimir Pouzanov wrote:
> I've just published a tiny test framework: shiny at
> https://github.com/farcaller/shiny. It's best used with hamcrest-rust.
>
> This library exists because I find it ugly to redefine all the
> initialisation code in every test case and I can't simply move it to a
> function due to problems with moving [T] out.
>
> Here's how shiny looks:
>
> #[cfg(test)]
> mod test {
> describe!(
> before_each {
> let awesome = true;
> }
>
> it "is awesome" {
> assert!(awesome);
> }
>
> it "injects before_each into all test cases" {
> let still_awesome = awesome;
> assert!(still_awesome);
> }
> )
> }
>
> --
> Sincerely,
> Vladimir "Farcaller" Pouzanov
> http://farcaller.net/
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
--
http://www.natpryce.com
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] A shiny test framework
Could you use RAII to call a lambda?
On 22 July 2014 20:31, Vladimir Pouzanov wrote:
> One note on why there's no after_each:
>
> You cannot really make sure that the epilogue is being called, so if you
> need to do anything after your test case, use RAII in before_each.
>
>
> On Tue, Jul 22, 2014 at 8:10 PM, Benjamin Gudehus
> wrote:
>
>> Nice to see an RSpec-like test framework and Hamcrest assertions/matchers
>> for Rust!
>>
>>
>> On Tue, Jul 22, 2014 at 9:09 PM, Ilya Dmitrichenko <
>> errordevelo...@gmail.com> wrote:
>>
>>> Dude, that's pretty much rspec ;) sweet!
>>> On 22 Jul 2014 20:07, "Vladimir Pouzanov" wrote:
>>>
I've just published a tiny test framework: shiny at
https://github.com/farcaller/shiny. It's best used with hamcrest-rust.
This library exists because I find it ugly to redefine all the
initialisation code in every test case and I can't simply move it to a
function due to problems with moving [T] out.
Here's how shiny looks:
#[cfg(test)]
mod test {
describe!(
before_each {
let awesome = true;
}
it "is awesome" {
assert!(awesome);
}
it "injects before_each into all test cases" {
let still_awesome = awesome;
assert!(still_awesome);
}
)
}
--
Sincerely,
Vladimir "Farcaller" Pouzanov
http://farcaller.net/
___
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
>>>
>>>
>>
>
>
> --
> Sincerely,
> Vladimir "Farcaller" Pouzanov
> http://farcaller.net/
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
--
http://www.natpryce.com
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] How to get the file descriptors of standard I/O types?
I'm writing for the Raspberry Pi, so cross-compiling to ARM Linux. --Nat www.natpryce.com On 15 Jul 2014, at 00:18, Ilya Dmitrichenko wrote: Are you working on a project targeting MCUs or Linux? If MCUs, I'd strongly encourage you to join the efforts on Zinc (http://Zinc.rs)! On 14 Jul 2014 23:15, "Nat Pryce" wrote: > I'm currently using the native API to implement new I/O abstractions for > GPIO, I2C, etc. But really want to combine them with the existing File and > socket APIs. I've had to copy code from the native runtime library to > convert native errors to IoError, which makes me uncomfortable. > > What's the URL of your pull request? > > > On 14 July 2014 22:47, Ilya Dmitrichenko wrote: > >> Nat, I would very much appreciate if you join the discussion on my pull >> request. >> >> There is also a link to the Stack Overflow answer I got earlier, it >> describes how you can get the file descriptor form a lower layer >> `libnative` API... >> >> On 14 July 2014 22:26, Nat Pryce wrote: >> > Are there plans to better link the standard I/O APIs and the platform's >> > native I/O? For example, to control devices (on Linux often done by >> ioctl, >> > which needs a file descriptor), use non-IP protocols (on Linux, >> different >> > socket families, return a file descriptor), multiplex I/O events, etc. >> > >> > --Nat >> > >> > >> > On 14 July 2014 20:38, Alex Crichton wrote: >> >> >> >> There is not currently a method of doing so through the `std::io` >> >> apis. While possible through the rustuv and native apis, I would >> >> discourage manual use of those crates as they have experimental and >> >> volatile APIs. >> >> >> >> You may be interested in https://github.com/rust-lang/rust/pull/15643 >> >> which may add support for acquiring the file descriptor. That PR has >> >> dome discussion about the hazards of doing so, as well. >> >> >> >> On Sun, Jul 13, 2014 at 4:43 AM, Nat Pryce >> wrote: >> >> > Hi. I want to use the existing I/O types (files, sockets, etc.) with >> >> > epoll. >> >> > Is there an API call to get hold of their file descriptors? >> >> > >> >> > --Nat >> >> > >> >> > -- >> >> > http://www.natpryce.com >> >> > >> >> > ___ >> >> > Rust-dev mailing list >> >> > Rust-dev@mozilla.org >> >> > https://mail.mozilla.org/listinfo/rust-dev >> >> > >> > >> > >> > >> > >> > -- >> > http://www.natpryce.com >> > >> > ___ >> > Rust-dev mailing list >> > Rust-dev@mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> > >> > > > > -- > http://www.natpryce.com > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] How to get the file descriptors of standard I/O types?
I'm currently using the native API to implement new I/O abstractions for GPIO, I2C, etc. But really want to combine them with the existing File and socket APIs. I've had to copy code from the native runtime library to convert native errors to IoError, which makes me uncomfortable. What's the URL of your pull request? On 14 July 2014 22:47, Ilya Dmitrichenko wrote: > Nat, I would very much appreciate if you join the discussion on my pull > request. > > There is also a link to the Stack Overflow answer I got earlier, it > describes how you can get the file descriptor form a lower layer > `libnative` API... > > On 14 July 2014 22:26, Nat Pryce wrote: > > Are there plans to better link the standard I/O APIs and the platform's > > native I/O? For example, to control devices (on Linux often done by > ioctl, > > which needs a file descriptor), use non-IP protocols (on Linux, different > > socket families, return a file descriptor), multiplex I/O events, etc. > > > > --Nat > > > > > > On 14 July 2014 20:38, Alex Crichton wrote: > >> > >> There is not currently a method of doing so through the `std::io` > >> apis. While possible through the rustuv and native apis, I would > >> discourage manual use of those crates as they have experimental and > >> volatile APIs. > >> > >> You may be interested in https://github.com/rust-lang/rust/pull/15643 > >> which may add support for acquiring the file descriptor. That PR has > >> dome discussion about the hazards of doing so, as well. > >> > >> On Sun, Jul 13, 2014 at 4:43 AM, Nat Pryce wrote: > >> > Hi. I want to use the existing I/O types (files, sockets, etc.) with > >> > epoll. > >> > Is there an API call to get hold of their file descriptors? > >> > > >> > --Nat > >> > > >> > -- > >> > http://www.natpryce.com > >> > > >> > ___ > >> > Rust-dev mailing list > >> > Rust-dev@mozilla.org > >> > https://mail.mozilla.org/listinfo/rust-dev > >> > > > > > > > > > > > -- > > http://www.natpryce.com > > > > ___ > > Rust-dev mailing list > > Rust-dev@mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > -- http://www.natpryce.com ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] How to get the file descriptors of standard I/O types?
Are there plans to better link the standard I/O APIs and the platform's native I/O? For example, to control devices (on Linux often done by ioctl, which needs a file descriptor), use non-IP protocols (on Linux, different socket families, return a file descriptor), multiplex I/O events, etc. --Nat On 14 July 2014 20:38, Alex Crichton wrote: > There is not currently a method of doing so through the `std::io` > apis. While possible through the rustuv and native apis, I would > discourage manual use of those crates as they have experimental and > volatile APIs. > > You may be interested in https://github.com/rust-lang/rust/pull/15643 > which may add support for acquiring the file descriptor. That PR has > dome discussion about the hazards of doing so, as well. > > On Sun, Jul 13, 2014 at 4:43 AM, Nat Pryce wrote: > > Hi. I want to use the existing I/O types (files, sockets, etc.) with > epoll. > > Is there an API call to get hold of their file descriptors? > > > > --Nat > > > > -- > > http://www.natpryce.com > > > > ___ > > Rust-dev mailing list > > Rust-dev@mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > > -- http://www.natpryce.com ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] How to get the file descriptors of standard I/O types?
Hi. I want to use the existing I/O types (files, sockets, etc.) with epoll. Is there an API call to get hold of their file descriptors? --Nat -- http://www.natpryce.com ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Mutiplexing I/O within a task
Yes, I do want something like an nio Selector. I'm trying to write it myself using epoll and eventfd on Linux. Binding to the syscall is straightforward. However I can't work out how to get the fds of IO objects (File struct, for example) so am stuck again. The ioserver approach sounds promising as long as it can be easily extended with new I/O mechanisms. One thing to keep in mind is that not all I/O can be made non-blocking. Eg I2C and SPI communication on Linux is performed by ioctls that block the calling thread and so would block an event loop that relies on nonblocking IO. --Nat On Sunday, July 6, 2014, Tony Arcieri wrote: > On Sat, Jul 5, 2014 at 8:07 AM, Nat Pryce > wrote: > >> 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. >> >> What API should I use to wait for multiple I/O objects within a task? Is >> there a runtime-independent API for this? >> > > Sounds like you might want something like a Java NIO Selector. These > Selectors bake in a pipe as a wakeup mechanism as well: > > http://docs.oracle.com/javase/7/docs/api/java/nio/channels/Selector.html > > However, there is more than one way to do it ;) Earlier I sent this > message out about providing I/O "as a service" by having a dedicated task > (or pool of tasks) that performs I/O operations for you, sending > completions back as messages over the normal std::comm message protocol, > ala Erlang's ioserver. Perhaps it's relevant to bring up again? > > -- Forwarded message -- > From: Tony Arcieri > > Date: Wed, Jan 29, 2014 at 1:40 AM > Subject: Multiplexing I/O the Erlang way: an "ioserver" > To: "rust-dev@mozilla.org > " < > rust-dev@mozilla.org > > > > > libnative (fast, low-latency native I/O) and libgreen (libuv backed and > great for large numbers of infrequent/idle messengers) are both awesome and > provide some great options for network server I/O, particularly since you > can mix-and-match them. > > However there's a seemingly unsolved problem in Rust: multiplexing I/O > operations with channels. I think this can be fixed in a purely additive > manner (i.e everything else that exists today is great!) with a new feature > borrowed from Erlang: the ioserver (noting that Erlang also implements > libgreen-style synchronous I/O in addition to ioserver) > > Ignoring Erlang for a second, the naive solution to the I/O + channel > multiplexing is magic select API that can handle both. In my experience > (i.e. I wrote and support this approach in a system some people actually > use) the backend implementation, especially across POSIX and Windows, ends > up quite ugly. > > There's a better option though... if you want to multiplex IO with channel > messages, turn everything into channel messages in one place: the "ioserver" > > Solution: Centralize I/O event loops into a separate thread (pool if > necessary, probably not). Erlang and 0MQ work this way. Erlang implements > an API called a "port" to talk to the ioserver. In Rust perhaps you could > have a type that implements the same trait as channels? > > The ioserver becomes the central place to optimize the nitty gritty of > taking I/O requests from the rest of the program and multiplexing them with > other (i.e channel) events in the system. The basic formula is: > > - Have the ioserver block for events using libuv or what have you, and > have an OS-specific I/O handle (i.e. a pipe) to unblock the selector in the > event of in-process communication > - Use lock-free mechanisms so if the selector isn't stuck in a system call > we can use more efficient coordination of registering and unregistering I/O > op interests > > (Note: libuv is an I/O completions library and not a selector library so > the proposed solution is admittedly a bit handwavey) > > Mixing a pipe-based wakeup mechanism with lock-free operations to > eliminate unnecessary system calls has been used somewhat successfully in > the Netty I/O library for the JVM. > > -- > Tony Arcieri > -- http://www.natpryce.com ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Mutiplexing I/O within a task
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. 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
