I've been thinking about static linking recently, along with a little bit of
linking in general, and I wanted to see what others thought.
# The Goal
Primarily, I believe that if desired, rustc should be able to generate an
executable or dynamic library with no dependence on any rust libraries.
On 2013-11-15, at 9:46, Isaac Dupree m...@isaac.cedarswampstudios.org wrote:
On 11/14/2013 09:25 PM, Tommi wrote:
trait Inflate {
fn get_radius's('s mut self) - 's mut int;
fn inflate_by(mut self, amount: int) {
*self.get_radius() += amount;
}
}
[...]
Third time's
On 15/11/13 18:47, Oren Ben-Kiki wrote:
In your code, when providing a default implementation for
`inflate_by`, you are invoking the trait (hence virtual)
method `get_radius`. If the compiler compiles `inflate_by` when seeing
just the `Inflate` source code, then this must be translated to an
On 2013-11-15, at 9:47, Oren Ben-Kiki o...@ben-kiki.org wrote:
In your code, when providing a default implementation for `inflate_by`, you
are invoking the trait (hence virtual) method `get_radius`. If the compiler
compiles `inflate_by` when seeing just the `Inflate` source code, then this
On 14 November 2013 23:01, Daniel Micay danielmi...@gmail.com wrote:
Correct, you won't get optimal performance with 1 task per
request/client across every platform. For non-socket I/O, it will be
as close as you can get to optimal on Linux except in terms of the
huge virtual memory
I solved these problems somewhat clunkily using an enum:
https://github.com/jfager/d3cap/blob/master/multicast.rs
It's not pretty but it gets the job done until the various issues around
this get worked out.
On Thursday, November 14, 2013, Diego Ongaro wrote:
Hi all,
My program starts a
On Fri, Nov 15, 2013 at 11:47 AM, Huon Wilson dbau...@gmail.com wrote:
As I understand it, default methods are specialised/monomorphised for
each type for which the trait is implemented. The only time a virtual call
ever happens is when one explicitly has a trait object.
That would be
These are 2 points of secondary importance (or even less).
What about the following pattern:
for x:Type in expr {
// proceed with x
}
as equivalent to:
for y in expr {
let x = y as Type;
// proceed with x
}
both for iterator loops and range loops?
On Fri, Nov 15, 2013 at 6:54 AM, Oren Ben-Kiki o...@ben-kiki.org wrote:
That would be awesome, if it were true; it is quite a trick to pull that off
when the default methods are implemented in a different crate. Can someone
provide an authoritative answer on this?
Also, C++ faces the problem
On Fri, Nov 15, 2013 at 7:27 AM, spir denis.s...@gmail.com wrote:
These are 2 points of secondary importance (or even less).
What about the following pattern:
for x:Type in expr {
// proceed with x
}
as equivalent to:
for y in expr {
let x = y as Type;
On 15/11/13 23:27, spir wrote:
These are 2 points of secondary importance (or even less).
What about the following pattern:
for x:Type in expr {
// proceed with x
}
as equivalent to:
for y in expr {
let x = y as Type;
// proceed with x
}
both for iterator
I'm exploring the tutorial Rust for Rubyists at
[http://www.rustforrubyists.com/book/book.html], which in fact is not (only) for
rubyists, as stated in the introduction. Looks pretty good to me (just my
opinion), should definitely be pointed to from the Rust Docs page at
Thanks for the explanation! So virtual function calls are kept to the
absolute theoretical minimum, that's very good to know.
In my case I have one crate for some infrastructure and another crate for
the application using it (there would be several of these). I guess
having two copies isn't that
In reply to Nicholas Matsakis's post:
http://smallcultfollowing.com/babysteps/blog/2013/11/14/treating-vectors-like-any-other-container/
That's a really nice write-up Nicholas. I wanted to chip in because I had a
think about some similar issues in the past, but your review is far more
thorough
If the traits were polymorphic in the index type (instead of always
expecting an integer), then one could use them to make hash tables use
vector syntax (e.g., `hash[foo] = 1`)... Ruby does that, for example. So
something like bitset (with integer indices) isn't the only example.
Not sure whether
On Fri, Nov 15, 2013 at 8:35 AM, Diggory Hardy li...@dhardy.name wrote:
For me, the biggest plus of your proposal is uniformity: e.g. someone could
implement something like C++'s std::bitset and have it look syntactically
equivalent to VectorT (although given that std::bitset is not very
On 16/11/13 00:39, Oren Ben-Kiki wrote:
If the traits were polymorphic in the index type (instead of always
expecting an integer), then one could use them to make hash tables use
vector syntax (e.g., `hash[foo] = 1`)... Ruby does that, for
example. So something like bitset (with integer
Slice traits weren't: though, does `tree.mut_slice_between(foo, bar)`
even make sense?
On Fri, Nov 15, 2013 at 3:44 PM, Huon Wilson dbau...@gmail.com wrote:
On 16/11/13 00:39, Oren Ben-Kiki wrote:
If the traits were polymorphic in the index type (instead of always
expecting an integer),
On Fri, Nov 15, 2013 at 7:46 AM, spir denis.s...@gmail.com wrote:
I'm exploring the tutorial Rust for Rubyists at
[http://www.rustforrubyists.com/book/book.html], which in fact is not (only)
for rubyists, as stated in the introduction. Looks pretty good to me (just
my opinion), should
If tree is ordered, e.g. lexically, it might. I've certainly found
std::map...::lower_bound useful in the past:
http://en.cppreference.com/w/cpp/container/map/lower_bound
On Friday 15 November 2013 15:52:02 Oren Ben-Kiki wrote:
Slice traits weren't: though, does `tree.mut_slice_between(foo,
I would love a documentation Rust for Pythonist or Rust for C++'iste.
I don't like the Wiki page. I think the official documentation homepage
should be a nice, beautiful
http://doc.rust-lang.org/http://static.rust-lang.org/.
Period.
It should link all official documentation in a logical way.
after reading this doc, I would love to have:
- have a link at the bottom page to the github project
- submit one or several pullrequest
- doc is magically updated.
I'm investigating on this matter to ease documentation. That's is quite
interesting, because in my everyday job (I'm a python
On Fri, Nov 15, 2013 at 9:33 AM, Gaetan gae...@xeberon.net wrote:
after reading this doc, I would love to have:
- have a link at the bottom page to the github project
- submit one or several pullrequest
- doc is magically updated.
I'm investigating on this matter to ease documentation.
As the author of the original tutorial I'm interested in what people
hate so much about it. It appears to have slightly bit-rotted, in that
the language moved on and people haphazardly updated stuff here and
there, but the bulk of it still looks coherent. Can I get some
concrete pointers?
On Fri,
On Fri, Nov 15, 2013 at 9:55 AM, Marijn Haverbeke mari...@gmail.com wrote:
As the author of the original tutorial I'm interested in what people
hate so much about it. It appears to have slightly bit-rotted, in that
the language moved on and people haphazardly updated stuff here and
there, but
On 11/15/13 6:55 AM, Marijn Haverbeke wrote:
As the author of the original tutorial I'm interested in what people
hate so much about it. It appears to have slightly bit-rotted, in that
the language moved on and people haphazardly updated stuff here and
there, but the bulk of it still looks
On 11/15/2013 01:27 PM, spir wrote:
[...]
Thank you Huon Daniel, your replies answer my needs. I supported the issue
about removal of signed `int` as default (BAD! ;-).
Actually like `for i in range(1u, 9u)` as an alternative for `for i:uint in
range(1 ,9)`, but there also, there should
On 11/15/2013 03:55 PM, Marijn Haverbeke wrote:
As the author of the original tutorial I'm interested in what people
hate so much about it. It appears to have slightly bit-rotted, in that
the language moved on and people haphazardly updated stuff here and
there, but the bulk of it still looks
Primarily, I believe that if desired, rustc should be able to generate an
executable or dynamic library with no dependence on any rust libraries. This
includes things like librustrt and libextra. Rust shouldn't be striving to
lift
dependence on system libraries, that'll come at later times
[I posted this yesterday, but since it didn't show up, I'm re-posting it. Sorry
if it's a double post]
I'd like to be able to use the non-virtual interface (NVI) idiom:
http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Non-Virtual_Interface
The following two new features are needed to accomplish
On Fri, Nov 15, 2013 at 12:18 PM, spir denis.s...@gmail.com wrote:
On 11/15/2013 03:55 PM, Marijn Haverbeke wrote:
As the author of the original tutorial I'm interested in what people
hate so much about it. It appears to have slightly bit-rotted, in that
the language moved on and people
On Fri, Nov 15, 2013 at 12:28 PM, Alex Crichton a...@crichton.co wrote:
Primarily, I believe that if desired, rustc should be able to generate an
executable or dynamic library with no dependence on any rust libraries. This
includes things like librustrt and libextra. Rust shouldn't be striving
Hm, I suppose I should re-phrase. Rust's linkage model should not
attempt to lift dependence on global native libraries. These global
libraries (like libm and librt on linux) should be assumed to be
everywhere. Our result artifacts must always be linked against them
(if their functionality is
I agree on the semantic point.
The job of technical writer is quite a talent to have, not anyone can
easily vulgarize concept and present them in a logical way. This is
pedagogy and quite hard to set up in a developer's brain.
However, on tutorial I think there is a flaw: most of the a time,
On Fri, Nov 15, 2013 at 1:37 PM, Gaetan gae...@xeberon.net wrote:
I agree on the semantic point.
The job of technical writer is quite a talent to have, not anyone can easily
vulgarize concept and present them in a logical way. This is pedagogy and
quite hard to set up in a developer's brain.
On Fri, Nov 15, 2013 at 09:28:49AM -0800, Alex Crichton wrote:
To this end, I mainly
point out that rust should roll in local native static libraries, and
just live with global native dynamic libraries.
How does rustc know the difference? Because the local native libraries
are tagged as
On Thu, Nov 14, 2013 at 09:05:40PM +0200, Tommi wrote:
In other words, no autoderef or other transformation takes place. We
just look for a matching trait. Instead we just pass the values in by
reference. The reason for passing by reference is so that you can
compare linear types more
To this end, I mainly
point out that rust should roll in local native static libraries, and
just live with global native dynamic libraries.
How does rustc know the difference? Because the local native libraries
are tagged as #[link(once)]? (nit: maybe link(static) would be clearer?)
You're
So in the case of --staticlib, if my Rust library, libmycomp.a, depended on
non-Rust local native library, libfoo.a, would Rust then bundle all modules
from libfoo into libmycomp? Or would it only do so for Rust libraries,
e.g. libstd.a?
On Fri, Nov 15, 2013 at 12:09 AM, Alex Crichton
You would be required to specify that the native library would be static via
#[link(name = foo, static)]
extern { ... }
And then rustc would bundle libfoo.a with libmycomp.a. libmycomp.a
would also include any upstream rust dependencies (libstd.a,
libextra.a, etc.)
On Fri, Nov 15, 2013 at 12:00
On 11/15/2013 05:52 AM, Patrick Walton wrote:
* One of the BIG problems with D uptake is the split library problem
referred to before. They could not get a comfortable standard library
for a long time, despite some extremely bright and decently famous
engineers working on D. My understanding is
On 15 Nov 2013, at 20:58, Niko Matsakis n...@alum.mit.edu wrote:
On Thu, Nov 14, 2013 at 09:05:40PM +0200, Tommi wrote:
In other words, no autoderef or other transformation takes place. We
just look for a matching trait. Instead we just pass the values in by
reference. The reason for
On 16/11/13 03:05, Gábor Lehel wrote:
Hello list,
I have some ideas about typey things and I'm going to write them down.
It will be long.
No kidding.
It would be nice if `Trait1 + Trait2` were itself a trait, legal in
the same positions as any trait. This is already partly true: in
What if the final executable also wants to link against a slightly newer
version of libfoo.a? I'm not even sure what ld would do then. Complains
about duplicate symbols? Picks one at random?
I think I'd rather have Rust object file along with a list of libraries
that will be needed for final
On Thu, Nov 14, 2013 at 5:19 PM, Brian Anderson bander...@mozilla.com wrote:
On 11/14/2013 04:03 PM, Diego Ongaro wrote:
My program starts a bunch of tasks, then I want the main task to both
receive ctrl-c signals and receive results from the children. The
signal will come from a
So... did anyone think that my idea (of doing multiple-inheritance by
separating the responsibilities of providing functionality and providing data
between the trait and the type which implements the trait) would warrant an
enhancement request at github? Or how do these things tend to work
On 11/15/2013 11:05 AM, Gábor Lehel wrote:
Like C++, types could be parameterized over constants. Again, the syntax
could mirror their declarations. For example, a function to construct a
fixed-length array:
fn make_nstatic N: int(n: int) - ~[int, ..N] { [n, ..N] }
Interesting questions
I'm not certain whether it is better than anonymous members; one has to
list all the data members one by one, and there's more magic syntax. But
it is up to the powers-that-be.
On Sat, Nov 16, 2013 at 5:48 AM, Tommi rusty.ga...@icloud.com wrote:
So... did anyone think that my idea (of doing
Personally I'd appreciate a type system that's able to express SI units,
which C++ and Haskell are powerful enough to do[1].
I agree. This is of huge importance when it comes to providing compile time
safety guarantees. And if the language is powerful enough to express SI units,
then it also
49 matches
Mail list logo
