Re: [rust-dev] Crosscompiling rust with non-blessed compiler prefixes
Thanks Ben, I was just about to reply with the link: https://github.com/rust-lang/rust/pull/16156/ Cody, you are welcome to test out the branch, as you are to compile rust with OE anyway ;) On 16 Oct 2014 20:52, "Ben Harris" wrote: > This will be available very soon. There is a pull request in the final > stages of review that will allow you to define custom targets with custom > linkers, link args, PIC options, etc. > > That is for building binaries using rustc. I'm not sure what the solution > would be for building rustc itself. > > On 16 October 2014 12:55, Cody P Schafer wrote: > >> Hi all, >> >> I'm trying to create an openembedded/yocto layer that includes rust, >> and for this to work I need to be able to have rust build using target >> a compiler with a prefix that isn't included in mk/platform.mk. >> >> For example: >> >> My yocto build is targeting a beaglebone black, so an >> arm-linux-gnueabihf device. My particular gcc binary prefix is >> "arm-poky-linux-gnueabi", which isn't something that rust's build >> system knows about. >> >> >> Q: Is there an accepted way to point particular rust targets at build >> tools with a particular prefix? For example, can I tell rust's >> configure that I've got an arm-unknown-linux-gnueabihf system (which >> it understands) and then have it use tools with >> "arm-poky-linux-gnueabihf-" as their prefix? >> >> Alternately, is the current practice to have buildscripts muck with >> platform.mk to add my particular case? >> ___ >> 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 mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust and real-time audio
It would make sense to suggest that a Real-time Runtime would be an interesting project to consider. I also think that may be one could attempt implementing an audio engine on a bare-metal chip, like an MCU. For that purpose there is Zinc project to look into, which already supports some Cortex-M4 devices, which are great for DSP. Perhaps a device with audio peripherals would have to be found and drivers may need to be implemented, but this is probably okay to do considering that such project would leverage Rust's ability to run on bare-silicon, as well as study it's suitability for real-time applications without burden of latency caused by general purpose OS. On 13 Oct 2014 17:35, "David Henningsson" wrote: > > On 2014-10-08 07:49, David Henningsson wrote: > >> Hi, >> >> I'm curious about the possibilities to use Rust for programming real-time >> audio stuff. Usually one has one small task that runs in high priority, and >> everything else is handled by a main task. >> >> I have a few questions related to this: >> >> 1) The real-time audio task should never block when not expected to, so >> stuff like malloc() is forbidden. Is there a way I can mark a >> section/module/crate/something of the code as "real time safe", and thus >> get warnings or errors in case I try to do something that would require >> heap allocation or other blocking stuff? >> The rest of the code (i e the main task) should still be able to use the >> entire libstd. >> > > It seems to me like one option could be to do this runtime, by switching > the allocator (this should be possible, right?) to one that checks the > thread context first and fails (or emits a warning) in case we're currently > in a hard real-time safe thread/mode. > > >> 2) The real-time audio thread might want to receive messages as well. >> Are channels suitable for this, or are the complications that cause things >> to be problematic here? >> > > So after having looked through the code, I think I can answer the two > remaining one myself (but feel free to correct me if I'm wrong here) : > > It looks like this *might* be problematic in the sense that there *might* > be heap memory allocation involved when sending things over the channel. > But it seems to recycle the memory by keeping a list of "unused list > items". So it was not designed for hard real-time usage. > > >> 3) When using e g ALSA as your audio API, you usually block waiting on a >> file descriptor. I was wondering if one would be able to select between >> ALSA's fd and the channel, thus the blocking part of the real-time thread >> would look something like: >> >> select! ( >> command = rx.recv() => handle_command_from_main_thread(command), >> () = alsa.wait_for_avail() => alsa.write_more_audio_to_buffer() >> ) >> >> ...where alsa.wait_for_avail() would somehow tell rust that it should >> block on ALSA's file descriptor in addition to other things (such as >> messages on the channel). >> >> If it matters, assume native threads (i e, not green threads). >> > The answer is "no, not as the runtime is currently designed". When a task > deschedules, it seems to wait on a mutex or semaphore. It is not waiting > for file descriptors (like the other mainloops I've seen on Linux). > > If it were, it would provide a more flexible approach, including waiting > for pipes, sockets, etc. And eventfds could replace the mutex/semaphore > currently used for channels. It would be interesting to know if there was a > difference in performance though. > > // David > > ___ > 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] Issues linking a static Rust library
Sounds like very annoying sort of issue... Have you tried patching this via a script or manually for the start? ar x libtreble.a ar c libtreble.a *.o Also, the good question to ask how those non-traditional files in a static library archive are use... I would assume that compilers other then rustc would not be able to make any use of it whatsoever. — Ilya Dmitrichenko On 7 October 2014 21:03, Tahia Khan wrote: > Hey all! Rust newbie here. I'm having some problems including a static Rust > library inside of an Objective-C project on XCode. > > I was looking through rustc source code (specifically /back/link.rs) and I > saw that rlibs and staticlibs are built very similarly (in fact link_rlib is > called inside of link_staticlib). According to the comments above the > link_rlib function in link.rs, non-object "magical files" are tacked onto > the end of archive files for rlibs/staticlibs. I inspected my staticlib with > otool and confirmed that there are a bunch of non-object files at the end: > > libtreble.a(r-std-std-4e7c5e5c.0.bytecode.deflate): is not an object file > libtreble.a(r-rand-rand-4e7c5e5c.0.bytecode.deflate): is not an object file > libtreble.a(r-sync-sync-4e7c5e5c.0.bytecode.deflate): is not an object file > libtreble.a(r-rustrt-rustrt-4e7c5e5c.0.bytecode.deflate): is not an object > file > libtreble.a(r-collections-collections-4e7c5e5c.0.bytecode.deflate): is not > an object file > libtreble.a(r-alloc-alloc-4e7c5e5c.0.bytecode.deflate): is not an object > file > libtreble.a(r-libc-libc-4e7c5e5c.0.bytecode.deflate): is not an object file > libtreble.a(r-unicode-unicode-4e7c5e5c.0.bytecode.deflate): is not an object > file > libtreble.a(r-core-core-4e7c5e5c.0.bytecode.deflate): is not an object file > > When I try to build my Xcode project, my build fails with the following > error: > > ld: in > [path-to-library]/rust-from-c/libtreble.a(r-std-std-4e7c5e5c.0.bytecode.deflate), > archive member 'r-std-std-4e7c5e5c.0.bytecode.deflate' with length 999896 is > not mach-o or llvm bitcode for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > It looks like the Xcode linker hits the very first non-object file then > isn't able to determine the architecture of the archive. Does anyone know if > there's some way to exclude these non-object files in a staticlib/rlib? Or > if there's some other way to avoid this build issue with the XCode linker? > > Cheers, > Tahia > > ___ > 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] Rust compiler for Risc-v
Hi Wink, I would be interested to help with RISC-V port. In terms of slim runtime and other non-OS aspects, have you looked at Zinc yet? Cheers, -- Ilya On 22 Sep 2014 17:47, "Wink Saville" wrote: > I'm interested in writing deeply embedded low level Rust code for risc-v ( > http://riscv.org/) that thus don't expect to need a significant runtime > library. As such I expect to use #![no_std] and #![no_start]. > > Anyway, there is a risc-v "llvm compiler" ( > http://riscv.org/download.html#tab_llvm) and it appears that rustc is an > "llvm compiler". > > It seems with both being llvm I should be able to connect the Rust's llvm > "frontend" to the risc-v "backend" and thus be able to generate Rust code > for risc-v. > > Would love to know if Rust compiler people would think this is reasonably > easy and if so what general guidance on how to do it. > > -- Wink > > ___ > 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] New Directions in Operating Systems, A one day conference, 25 November, London
Hi List, As I know that some of you are probably going to be quite interested in this, here is a conference coming up in November. http://operatingsystems.io/ They are still open for talk submissions. Cheers, -- Ilya ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Place for discussions
I think the point of discourse is that it provides a far better user interface then the mailing list does. Mailing lists are pretty backward in this day an age. The basics are that you can tag discussions and use backticks to quote code etc. Other smart things you can probably implement is sorting based on which discussion has been more active on average response frequency in given period of time, and not just you mail client's "most recently replied to" kind of sorting. Cross-referencing with github issues/pulls would be great to have! On 1 August 2014 00:42, Evan G wrote: > The correct link is http://discuss.rust-lang.org > > > On Thu, Jul 31, 2014 at 5:15 PM, Brian Anderson > wrote: >> >> Here's the current state of official project support for various forums: >> >> * discourse.rust-lang.org is for *discussion of the development of Rust >> itself*. It is maintained by Mozilla. >> * r/rust is for user discussion. It is maintained by the community. >> * rust-dev is for user discussion. It is maintained by Mozilla. It used to >> be for development discussion but none of the core developers like working >> there because the signal-to-noise is awful and it is unmoderatable. >> * stackoverflow is ultimately where we want users to go for help. >> >> Discourse is an *experiment* to see if it works better than mailing lists >> for having civil conversations. If it works, we may shut off the mailing >> list. It's not clear whether we would extend discourse to general Rust >> discussion or leave reddit and stackoverflow for that. >> >> >> >> On 07/30/2014 06:08 PM, Tobias Müller wrote: >>> >>> Hello, >>> >>> I'm following rust for quite a while, but the discussions are more and >>> more >>> distributed between different places. >>> The mailing list was probably first, then with more user attention reddit >>> and StackOverflow, and now the discourse forum. >>> >>> I understand that StackOverflow and Reddit are more for users, not >>> developers, but the discourse forum seems mostly redundant. >>> >>> What's the reason for that split? Is the mailing list deprecated? Which >>> one >>> is the future? >>> >>> I for myself prefer the mailing list because of the gmane NNTP service, I >>> can use my usual usenet software and have all my forums in one place. >>> >>> Tobi >>> >>> ___ >>> 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 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] [ANN] Rust Cross Support for PNaCl
On 1 August 2014 01:32, Richard Diamond wrote: > Yes, but currently only when target_os = "nacl", ie when one has targeted > le32-unknown-nacl (otherwise it's just a matter of using --cfg > "target_libc=\"newlib\""). I should note however, libuv is for the most part > unable to use Newlib (last time I tried, it was a mess, even after much > effort on my part to remove uses of glibc only functions). In fact, it is > this reason libuv is disabled for PNaCl. It'd would be helpful if you could point out what specific parts of libuv depend on glibc... We need to figure out how to move forward with this, whether it's fixable or rustuv crate would have to be disable when newlib is in in use. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] August 21st SF Bay Area Rust Meetup - Updates from the Rust Team
Are you guys filming it? On 30 July 2014 01:53, Erick Tryzelaar wrote: > Hello Rustillians! > > I'm pleased to announce the next Bay Area Rust Meetup on Thursday, August > 21, 2014, at Mozilla's San Francisco office: Please sign up here if you wish > to attend: > > http://www.meetup.com/Rust-Bay-Area/events/191293242/ > > This is a unique meetup because we will be having the full Mozilla Rust team > in town in attendance and speaking about what they've been working on. Here > is our lineup of speakers: > > * Alex Crichton: Cargo: forged in a crucible of Rust > > * Niko Matsakis: TBD > > * Patrick Walton - Explaining the Borrowcheck (or TBD). > > * Aaron Turon: The intersection of new language features and libraries. > > If you cannot attend in person, we will have the talk livestreamed on Air > Mozilla (https://air.mozilla.org/bay-area-rust-meetup-august-2014/). As > always, Mozilla will be graciously providing food and drink. > > I hope you can all make it! > > -Erick > > PS: The brand new San Francisco Rust Hacknights meetup group is also hosting > a hacknight happening that same week on August 19th: > > http://www.meetup.com/SF-Rust-Hacknights/events/194585552/ > > Don't miss out on it! > > ___ > 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] Migrating libs out of rust-lang/rust
Ok, I got the basic going with a temporary for of `libsemver` here:
- https://travis-ci.org/errordeveloper/rust-libsemver/builds/31217706
- https://github.com/errordeveloper/rust-libsemver
Few questions:
- should I bother with enabling OS X beta on Travis?
- what naming convetion we gonna use? shall it be `rust-lib{name}`?
On 30 July 2014 10:44, Simon Sapin wrote:
> Long term, I'd like Rust to have an official package index, like Python's
> PyPI: https://pypi.python.org/
I though Cargo had an early version of this... Although, I don't think
this is even needed. People should just use git (or other SCM) in a
decent fashion, with a branch policy and tagging. If you have a
central index, it's a point of failure and you may end-up with
bullshit like mirroring.
> PyPI provides free hosting for documentation of Python projects. I'd like
> Rust to have something like this too. GitHub Pages works and exists now, but
> I'm not a fan of generated files in the source repository, even in a
> separate branch.
I think godoc.org (http://godoc.org/) is pretty sweet, although it
doesn't handle revisions, as I can see. Well, neither does `go get`.
Anyhow, I think rdoc.info (http://rdoc.info/) is probably the most
extensive implementation of an auto-magic docs site.
> I've just checked: GitHub does not allow forking (and therefore making PRs
> to) an empty repository, so the person creating the repository will have to
> at least check the "Initialize this repository with a README" checkbox to
> make a dummy first commit.
Yeah, could someone create empty repos for all the libs we agreed to pull out?
> How will this be achieve? http://www.rust-ci.org/ does it, but I'd like to
> see something more "official" and tied to the rust-lang.org binary nightlies
> rather than the Ubuntu PPA.
Hm... I think we should complete the splitting part, and then look back at this.
Perhaps, in the library repos, we can create tags with revision of the
compiler that it passed the test on. Crago, in turns, could pick
lookup these tags and checkout the relevant version. How do people
find this idea? Does Cargo even handle compiler versions at the
moment? If not, it's certainly an important feature to add.
> Regarding documentation on GitHub pages mentioned earlier, the script doing
> it looks like this:
>
> https://github.com/servo/rust-cssparser/blob/331e5695dc/.travis.yml
I pick some bit of yours into mine and we can hopefully come up with a
simple template for everyone.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] London Rust meetup: 2014-08-14
Hi Simon, I and @farcaller where thinking to prepare a talk on Zinc project (http://zinc.rs/). What length of the talks you guys do? Cheers, -- Ilya On 24 July 2014 09:00, Simon Sapin wrote: > Hello Rustaceans, > > The next London meetup is on August 14. Come and say hi! Nick Cameron a.k.a > nrc will be giving a talk on DST. > > http://www.meetup.com/Rust-London-User-Group/events/196222722/ > > We're also looking for speakers for this or future events. Let me know if > you're interested! > > Cheers, > -- > Simon Sapin > ___ > 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] A shiny test framework
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
Re: [rust-dev] moving out few odd libraries from the main tree
On 21 July 2014 22:46, Corey Richardson wrote: > Cargo is pretty awesome now, and I think we could get away with moving those > out, with the caveat that cargo depends on semver.. It does have a bunch of things as submodules already. I wouldn't find it unreasonable to just make libsemver part of cargo, as I doubt there would be much use for it outside of cargo in the near feature. Any suggestions on where misc libs should live? If someone create repos, I'll be happy to pull these two out and push into a given repo. In regards to CI, I'm not sure if these will really need buildbot+bors, Travis should be pretty sufficient, I think. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] moving out few odd libraries from the main tree
It would be great to discuss which libraries can be removed from the main tree, I can see that there had been some progress with liburl [1], but there appear to be a few other very dubious libraries that can easily leave outside of the main tree. The ones I was able to spot so far, would be: - libfourcc - libsemver The main question would be where would these live on github? Should it be under the main (`github.com/rust`) organisation or actually we could consider creating `github.com/rust-libs`? [1]: https://github.com/rust-lang/rust/issues/10707 Cheers, -- Ilya ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] adding a new cross-compile target
Hi Rob! It's probably best to way until porting had been simplified. Here is a ongoing discussion of this matter: https://github.com/rust-lang/rfcs/pull/131 Cheers, -- Ilya On 20 Jul 2014 15:35, "Rob Latham" wrote: > I probably picked the exact wrong project for diving into rust, but > I'd like to teach rust how to build powerpc64-bgq-linux binaries. > > I've got a powerpc64-bgq-linux toolchain. I added this stanza to > mk/platforms.mk, but cribbed from other platforms. Did I leave out > any important settings? > > % git diff > diff --git a/mk/platform.mk b/mk/platform.mk > index d1ec7c65..f1272eaa 100644 > --- a/mk/platform.mk > +++ b/mk/platform.mk > @@ -580,6 +580,19 @@ CFG_LDPATH_x86_64-unknown-freebsd := > CFG_RUN_x86_64-unknown-freebsd=$(2) > CFG_RUN_TARG_x86_64-unknown-freebsd=$(call > CFG_RUN_x86_64-unknown-freebsd,,$(2)) > > +# powerpc64-bgq-linux configuration > +CC_powerpc64-bgq-linux=powerpc64-bgq-linux-gcc > +CXX_powerpc64-bgq-linux=powerpc64-bgq-linux-g++ > +CPP_powerpc64-bgq-linux=powerpc64-bgq-linux-cpp > +AR_powerpc64-bgq-linux=powerpc64-bgq-linux-ar > +CFG_LIB_NAME_powerpc64-bgq-linux=libs$(1).so > +CFG_STATIC_LIB_NAME_powerpc64-bgq-linux=libs$(1).a > +CFG_LIB_GLOB_powerpc64-bgq-linux=lib$(1)-*.so > +CFG_CFLAGS_powerpc64-bgq-linux := $(CFLAGS) > +CFG_GCCISH_CFLAGS_powerpc64-bgq-linux := -Wall -Werror -g -fPIC $(CFLAGS) > +CFG_UNIXY_powerpc64-bgq-linux := 1 > +CFG_RUN_powerpc64-bgq-linux = > +CFG_RUN_TARG_powerpc64-bgq-linux = > > I can configure ok: > > ../configure --target=powerpc64-bgq-linux > --prefix=/sandbox/robl/rust-master > > But build progresses pretty far, hanging up here: > > [...] > rustc: > x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustdoc > rustc: > x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libfourcc > rustc: > x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhexfloat > rustc: > x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libregex_macros > make: *** No rule to make target > `powerpc64-bgq-linux/rt/arch/powerpc64/morestack.o', needed by > `powerpc64-bgq-linux/rt/libsmorestack.a'. Stop. > > I don't know how to go about debugging this. Any ideas? > > thanks > ==rob > ___ > 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] no error or warning when an unknown attribute is used
On 16 July 2014 15:23, Chris Morgan wrote: >>> Did it come up as an unused-attribute warning? >> No, it didn't. > The simple reason it doesn't come up as an unknown attribute is > because it did not successfully compile, and so it did not get to the > step where it warns about unused attributes. Sure, it's pretty clear what's going on, but I do think it's a bit of a problem. It's rather hard to spot a misspelled attribute. Should there be a pre-lint stage for this purpose? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] no error or warning when an unknown attribute is used
On 16 July 2014 14:59, Ben Harris wrote: > You can ask on the Rust IRC. My guess is that the error is triggering before > there is a chance to throw the unused-attribute warning out. In the past it > would have told you the error, but with the new plugin system we can define > our own attributes, so the lint can't tell that we have done something wrong > till the end. Ben, your guess was right. I remove the `json::encode` call and got `warning: unused attribute` and fixing the attribute name gets rid of the warning. I suppose this is a downside of the plugin system... ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] no error or warning when an unknown attribute is used
On 16 July 2014 14:51, Ben Harris wrote: > Did it come up as an unused-attribute warning? No, it didn't. This is all the output I got: >> > rustc foo.rs >> foo.rs:13:3: 13:15 error: failed to find an implementation of trait >> >> serialize::serialize::Encodable,std::io::IoError> >> for Data >> foo.rs:13 json::encode(&data); >> ^~~~ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] no error or warning when an unknown attribute is used
Hi List,
Using serialize crate, I have made a typo in attribute name and wrote
'derives' instead of 'deriving' and I got an error message about
`ToJson` trait not being implemented.
Here is what I did:
> cat foo.rs
extern crate serialize;
use serialize::json;
#[derive(Decodable, Encodable)]
pub struct Data {
test: bool,
uuid: int,
time: f64,
}
fn main() {
let data = Data { test: true, uuid: 123, time: 34349480.24 };
json::encode(&data);
}
> rustc foo.rs
foo.rs:13:3: 13:15 error: failed to find an implementation of trait
serialize::serialize::Encodable,std::io::IoError>
for Data
foo.rs:13 json::encode(&data);
^~~~
The compiler happily skipped over unknown attribute... Is this a
desired behaviour or a known issues?
Cheers,
--
Ilya
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Daemonizing a process
Sure, traditional deamons don't have stdio.
You will need to write to a log file and then also care about how that
file is being rotated etc. Traditionally daemons have a signal handle
that execution reopening of logs... You will also need to write an
init script to actually start it.
What I was saying is that it is not really necessary with a modern
init implementations, such as systemd or upstart. The do take care of
stdio and logging as well as "backgrounding" the service.
Cheers,
--
Ilya
On 15 July 2014 07:28, Gulshan Singh wrote:
> Alex Crichton helped me figure out a solution:
>
> use std::io::Command;
> use std::os;
> use std::io::timer::sleep;
>
> fn main() {
> let args = os::args();
> if args.len() == 1 {
> let child = Command::new(args.get(0).as_slice())
> .arg("child")
> .detached().spawn().unwrap();
> println!("child: {}", child.id());
> child.forget();
> } else {
> sleep(4); // In the daemon
> }
> }
>
> You can use pgrep to confirm the daemon is running. I don't know how to
> print to stdout because the file descriptor is closed (and the daemon
> silently crashes when calling `println`).
>
>
> On Wed, Jul 9, 2014 at 1:00 AM, Ilya Dmitrichenko
> wrote:
>>
>> Additionally, I'd like to note that modern best practice is to relay this
>> on the init process itself. With modern init systems, such as systemd or
>> launchctl, this works very nicely and application developer doesn't have to
>> care about daemonisation and logging is also done simply via stdout.
>>
>> On 9 Jul 2014 08:33, "richo" wrote:
>>>
>>> On 08/07/14 23:47 -0700, Gulshan Singh wrote:
>>>>
>>>> Is there currently any way to daemonize a process in Linux? I was using
>>>> the
>>>> `daemon` function in C:
>>>> http://man7.org/linux/man-pages/man3/daemon.3.html.
>>>> I asked in the IRC but I didn't get a response.
>>>
>>>
>>> There's going to be excitement with this, mostly because typically
>>> daemonising involves forking twice to ensure that you're reparented to
>>> init,
>>> which will result in a Really Bad Time if you're using libnative.
>>>
>>> Therefore, it's possible but only if you've not done too much stuff,
>>> which
>>> would be unsafe.
>>>
>>> Seperately though, rust *does* need a coherent story here. I'm just not
>>> at
>>> all sure what it will look like.
>>>
>>> ___
>>> 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] How to get the file descriptors of standard I/O types?
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?
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 > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust Guidelines
On 13 July 2014 19:18, Tony Arcieri wrote: > How about a gofmt-like source code reformatting utility? Provided it will not support hard tabs... ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries
On 13 July 2014 00:43, Stepan Koltsov wrote: > -- want to have several versions of rust side by side to investigate problems Not true, the share object files include git revision in the name and that's what they are being looked up by, as far as I understood. So one can have: DYLD_LIBRARY_PATH = /opt/Rust/0/lib/:/opt/Rust/1/lib/:/opt/Rust/2/lib/ My layout is like this: cd /opt; ls Rust/versions/*/*/lib/libnative-* Rust/versions/0f2ae7b932a9045f0d03ca35ff8cfc3fd939414e/rust-nightly-x86_64-apple-darwin/lib/libnative-1fb5e2c0-0.11.0-pre.dylib Rust/versions/21fd11fef66e9973bd424915b9ee958c0990af2b/rust-nightly-x86_64-apple-darwin/lib/libnative-4e7c5e5c.dylib Rust/versions/65395dc2bb240534c288bd60a5983538410af47d/rust-nightly-x86_64-apple-darwin/lib/libnative-35e04b6f-0.11.0.dylib Rust/versions/8d6cd8c1b95b2bb6d14008258e5e571552159f38/rust-nightly-x86_64-apple-darwin/lib/libnative-4e7c5e5c.dylib Rust/versions/a7b8824b2f8388705e4683b938fea442a663ebcb/rust-nightly-x86_64-apple-darwin/lib/libnative-4e7c5e5c.dylib > -- need different fixed per-project environments They will only need to care about executable path, which is something they would need to care about even if this change hadn't been made. > -- don't have permission to write into /usr/local (typically on shared > servers) Is is not a valid reason, they can unpack the tarball into any prefix. > -- don't want to have a mess in /usr/local Sure, so I personally put it under /opt/Rust/ >> As detailed in the meeting where this decision was made, Linux distros >> really dislike it when you mess with rpath; it's a deal-breaker in many >> cases. > > I don't know about all Linux distros, but apparently Ubuntu is OK about > rpath: > > $ objdump -x /usr/lib/jvm/java-7-openjdk-amd64/bin/java | grep RPATH > RPATH > $ORIGIN/../lib/amd64/jli:$ORIGIN/../lib/amd64:$ORIGIN/../jre/lib/amd64 Ubuntu is not the best example of how an OS should be built. It's probably a longstanding OpenJDK issue too, did you check? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries
Is the following error cause by this change? % rustc -v dyld: Library not loaded: x86_64-apple-darwin/stage1/lib/rustlib/x86_64-apple-darwin/lib/librustc-4e7c5e5c.dylib Referenced from: /Users/ilya/Library/Local/Rust/current/bin/rustc Reason: image not found Trace/BPT trap On 9 July 2014 00:53, Brian Anderson wrote: > Yes, it does. > > > On 07/08/2014 04:41 PM, Simon Sapin wrote: >> >> On 08/07/14 23:57, Brian Anderson wrote: >>> >>> *Running rustc directly from the build directory will no longer work by >>> default*. To do this either set LD_LIBRARY_PATH or pass --enable-rpath >>> to the configure script. >> >> >> Does this also apply to running a (nightly) binary distribution from where >> the tarball was extracted, without installing it? >> > > ___ > 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] Daemonizing a process
Additionally, I'd like to note that modern best practice is to relay this on the init process itself. With modern init systems, such as systemd or launchctl, this works very nicely and application developer doesn't have to care about daemonisation and logging is also done simply via stdout. On 9 Jul 2014 08:33, "richo" wrote: > On 08/07/14 23:47 -0700, Gulshan Singh wrote: > >> Is there currently any way to daemonize a process in Linux? I was using >> the >> `daemon` function in C: http://man7.org/linux/man- >> pages/man3/daemon.3.html. >> I asked in the IRC but I didn't get a response. >> > > There's going to be excitement with this, mostly because typically > daemonising involves forking twice to ensure that you're reparented to > init, > which will result in a Really Bad Time if you're using libnative. > > Therefore, it's possible but only if you've not done too much stuff, which > would be unsafe. > > Seperately though, rust *does* need a coherent story here. I'm just not at > all sure what it will look like. > > ___ > 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
