On 11/15/2011 12:04 AM, David Rajchenbach-Teller wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/14/11 9:53 PM, Brian Anderson wrote:
On 11/13/2011 11:53 PM, David Rajchenbach-Teller wrote:
*** #ifdef
My code heavily relies on #ifdefs with macros to compile code
conditionally, depending on both: - - which platform is targeted
(in mozilla-central, that's macros XP_WIN, XP_UNIX); - - which
primitives are available in libc (through autoconf's
AC_CHECK_FUNS and the macros HAVE_xxxxx that it defines).
What is the best way to achieve this in Rust?
Rust items can be conditionally compiled with the 'cfg' attribute,
so your build can call 'rustc --cfg FEATURE' (and you can provide
--cfg any number of times) then you can have functions annotated
#[cfg(FEATURE)]. The target platform is already set by default as
'target_os', so you can say #[cfg(target_os = "win32")].
If your question is more about how to integrate your
autoconf-based build with Rust's anti-autoconf build then the
answer is probably that they have to be kept separate.
Indeed, I have seen `cfg`, and I was wondering if this was the right
tool. From what I see, it is much coarser-grained than what I achieve
atm with autoconf.
Let me detail:
- - I need to compile some code for MacOS only;
- - I need to compile some code for all Unix platforms;
- - I need to compile some code for Unix platforms in which libc defines
a given function, say, `mkdirat`;
- - I need to compile some code for Unix platforms in which libc does
not define a given function.
How do you suggest I do this?
To complicate matters, on MacOS platform, I need to compile and link
to Objective-C code.
Unfortunately the cfg attribute is the only tool we have for this. Maybe
we need more.
*** Unicode
stdlib's string handling for win32 is wrong and I don't believe
anybody has put much thought into what needs to happen. Suggestions
welcome.
Well, I can try and work on this along the way. For this purpose,
though, I may need Unicode conversion.
We have an intent to integrate libicu. Maybe that would help.
*** Garbage-collection / destruction
Resources are what you want, but you usually want to box them and
wrap them in some other type because they are a bit unwieldy from a
user perspective.
Good to know, thanks.
In cases where I would use a `auto_ptr` / go's `defer` / Java's
`finally` / etc., though, I suppose that I should rather have my
resource on the stack, no?
Ideally, yes. Currently resources are pinned and can't be copied or
moved (though Marijn is soon going to make them moveable). If you put
them in a box and are careful about taking references to them they will
still run the destructor when you expect.
Failed tasks will call destructors during unwinding. Can you point
me to the incorrect documentation?
I probably over-interpreted « The unwinding procedure of hard failure
frees resources but does not execute destructors. » (Ref.Task.Life)
This is referring to what happens when a destructor itself fails during
unwinding (after the task has already entered the failure state). This
is, by the way, not implemented. Failing within a destructor will leak
currently.
One thing to note is that we still don't implement unwinding on
win32 so failure is currently unrecoverable on that platform.
Will that happen?
Is this related to the fact that win32 stack introspection is off by
default on 64bit platforms, as I have heard?
It will happen, but probably not by the time 0.1 is released. It's
because LLVM exception handling doesn't seem to work on windows. The
reason for that i don't know.
*** Error-handling - - Either aggressively `spawn_notify` tasks,
`unsupervise` them and `fail` in case of any error, with some
convention to pass `errno`;
I've tried to implement this approach before and found that the
language is not yet expressive enough to do this in a convenient
way (because we can't spawn closures). It's also quite inefficient
for general use.
Ah, I was not aware that we could not spawn closures. I guess it makes
sense, but it's a bit counter-intuitive for a fp/process algebra guy
like me. I assume this is because type-state cannot make guarantees on
values hidden inside a closure. Are there plans to improve the
expressivity of the language on this front?
Yes, it is because we don't know what is inside the closure. There is a
plan to add a unique closure type that is guaranteed to only contain
sendable things, but not everyone likes the idea of adding yet another
type of function. We definitely do have to come up with some solution,
because working with tasks is not very easy right now.
Regards,
Brian
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
