seems to hold up pretty well.
uv::hl API is affected.. had to do work on tests and std::timer code that
leverages the global loop/high_level_loop API.
see test_stress_gl_uv_global_loop_high_level_global_timer for a stress
example.. it takes a while to run, but it exits cleanly (something I could
never accomplish with earlier iterations of the global loop)
.. leveraging std::uv, we have:
timer::delayed_send - send a value over a provided channel after the
timeout has passed
timer::sleep - block the current task for the specified period
both of these fns (and everything that goes in timer.rs) leverage the
uv_timer_* API
.. fixes issue, in previous commit, with global loop test hanging on
32bit linux (this was because the struct was too small, so (presumably),
the data member was garbled.. yippy)
- moved global loop tests, as well.. will add tests in uv_hl that encompass
rolling your own high_level_loop via uv::hl::run_high_level_loop()
- also whitespace cleanups and misc warning cleanup..
- doesn't work on 32bit linux
.. seeing an occasional valgrind/barf spew on some invalid read/writes..
need to investigate further.. i think its related to my poor citizen
conduct, re: pointers stashed in rust_kernel..
- starting/stoping the loop based on client work is functioning, correctly
- the issue appears to be that, when the process is about to exit, the
signal to let weak tasks know that they need to exit isn't getting fired.
.. up next: windows!
.. impl'd uv::direct::read_stop() and uv::direct::close() to wrap things up
.. demonstrated sending data out of the uv_read_cb via a channel (which
we block on to recv all of it, complete w/ EOF notification) that is
read from after the loop exits.
.. helpers to read the guts of a uv_buf_t
.. an idea im kicking around: starting to pile up all of these hideous
data accessor functions in uv::direct .. I might make impl/iface pairs
for the various uv_* types that I'm using, in order to encapsulate those
data access functions and, perhaps, make the access look a little cleaner
(it still won't be straight field access, but it'll be a lot better)
.. formatting cleanup to satisfy make check
so we're now adhering the libuv C api and passing structs by-val where
it is expected, instead of pulling pointer trickery (or worse having to
malloc structs in c++ to be passed back to rust and then into C again)
have to use ++ sigil in rust-side extern fn decls in order to have rust
actually copy the struct, by value, onto the C stack. gotcha, indeed.
also adding a helper method to verify/remind how to pass a struct by-val
into C... check out the rust fn sig for rust_uv_ip4_test_verify_port_val()
for more infos
.. but passing sockaddr_in by val back to C is broken, still passing by
ptr
.. the uv_write_cb is processed, but we have a status -1.. there is
also valgrind spew.. so buf passing is broken, still.
lots of changes, here.. should've commited sooner.
- added uv::direct module that contains rust fns that map, neatly, to
the libuv c library as much as possible. they operate on ptrs to libuv
structs mapped in rust, as much as possible (there are some notable
exceptions). these uv::direct fns should only take inputs from rust and,
as neccesary, translate them into C-friendly types and then pass to the
C functions. We want to them to return ints, as the libuv functions do,
so we can start tracking status.
- the notable exceptions for structs above is due to ref gh-1402, which
prevents us from passing structs, by value, across the Rust<->C barrier
(they turn to garbage, pretty much). So in the cases where we get back
by-val structs from C (uv_buf_init(), uv_ip4_addr(), uv_err_t in callbacks)
, we're going to use *ctypes::void (or just errnum ints for uv_err_t) until
gh-1402 is resolved.
- using crust functions, in these uv::direct fns, for callbacks from libuv,
will eschew uv_err_t, if possible, in favor a struct int.. if at all
possible (probably isn't.. hm.. i know libuv wants to eventually move to
replace uv_err_t with an int, as well.. so hm).
- started flushing out a big, gnarly test case to exercise the tcp request
side of the uv::direct functions. I'm at the point where, after the
connection is established, we write to the stream... when the writing is
done, we will read from it, then tear the whole thing down.
overall, it turns out that doing "close to the metal" interaction with
c libraries is painful (and more chatty) when orchestrated from rust. My
understanding is that not much, at all, is written in this fashion in the
existant core/std codebase.. malloc'ing in C has been preferred, from what
I've gathered. So we're treading new ground, here!
Most could use the each method, but because of the hack used to
disambiguate old- and new-style loops, some had to use vec::each.
(This hack will go away soon.)
Issue #1619
Add an optional --logfile argument to std::test::test_main and to
compiletest.
Use this features and the new 'check-summary.py' script to
summarise all the tests performed by the 'check' target. This is
a short term fix for #2075.
It's possible to have negative times if expressing time before 1970, so
we should use signed types. Other platforms can return times at a higher
resolution, so we should use 64 bits.
We used to generate a module T with a serialize() and deserialize() fn,
but this was suboptimal for a number of reasons:
- it required moving serialization into core so that uint etc worked
- it was harder to override the serialization behavior locally
(this is now trivial)
- Move io, run and rand to core.
- Remove incorrect ctypes module (use libc).
- Remove os-specific modules for os and fs.
- Split fs between core::path and core::os.
As per discussion on IRC. I am about to file an RFC for further
discussion about the more general issue of whether to enforce
invariants through types, typestate, or dynamic checks, but for now,
removing the misleading name "last_unsafe".
This required changing almost all users of hashmaps to import the hashmap interface first.
The `size` member in the hashmap structure was renamed to `count` to work around a name conflict.
This required changing almost all users of hashmaps to import the hashmap interface first.
The `size` member in the hashmap structure was renamed to `count` to work around a name conflict.
Our json implementation did not conform to the spec, and
was missing support for escpaed characters and exponental
numbers. This fixes it, and adds support for reading/writing
json directly from/to a stream.
There are two things left unimplemented. We could use a
"to_json" iface/impl, but that really needs traits to cut
down on code duplication. The other is it wouldn't be that
not that hard to turn this implementation into a event driven
parser like YAJL, but I ran into some type-inference bugs,
so I cut that out. It'd be nice to revisit this in the future
though.
because of the last change, the loop ptr is no longer cleaned up
when the loop exits. This api call addresses that. Sadly, the loop
ptr is not "reusable" across multiple calls to uv::run().
the core impl is there, with a async handle in place
to take incoming operations from user code. No actual
uv handle/operations are implemented yet, though.
Issue #352Closes#1720
The old checker would happily accept things like 'alt x { @some(a) { a } }'.
It now properly descends into patterns, checks exhaustiveness of booleans,
and complains when number/string patterns aren't exhaustive.
* Renamed str::split -> str::split_byte
* Renamed str::splitn -> str::splitn_byte
* Renamed str::split_func -> str::split
* Renamed str::split_char -> str::split_char
* Renamed str::split_chars_iter -> str::split_char_iter
* Added u8::is_ascii
* Fixed the behavior of str::split_str, so that it matches split_chars
and split (i.e. ["", "XXX", "YYY", ""] == split_str(".XXX.YYY.", "."))
* Fixed str::split_byte and str::splitn_byte so that they handle
splitting UTF-8 strings on a given UTF-8/ASCII byte and also handle ""
as the others do
