Re: [rust-dev] Autocompletion (was: Why we don't like glob use (use std::vec::*)?)
FWIW I've started working on autocomplete functionality for rust. https://github.com/phildawes/racer I'm persuing the 'scan the source code text, incrementally parsing relevant pieces' approach. I'm also learning the language so it's a bit slow going (and will require cleanup as I become more familiar with the idioms). I've only just got libsyntax parsing individual blocks and statements and am hoping to get some type inference going over the next week or so. On Wed, Mar 12, 2014 at 9:58 PM, Gaetan gae...@xeberon.net wrote: I really like anaconda with sublime. Even if the module is not perfectly parsable, it can display you the right info, with some kind of heuristic to fix type mistakes,... Le 12 mars 2014 22:42, Clark Gaebel cgae...@uwaterloo.ca a écrit : Fair enough. I didn't consider that. Note to self: rust ain't ocaml. :) On Mar 12, 2014 4:53 PM, Daniel Micay danielmi...@gmail.com wrote: On 12/03/14 04:11 PM, Clark Gaebel wrote: Honestly, I like the 98% solution of grab metadata from every other module in the project except the one you're editing, and use 'text that appears before' completion (or similar heuristics) for things in the module you're editing. It doesn't require a compiler that can parse broken code, and is relatively minimal in work. How do you find the type of the value you're trying to complete a method on, like `foo.btab`? You need to be able to identify the type and the in-scope traits. ___ 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] Why we don't like glob use (use std::vec::*)?
Perhaps it's not that important that it will be able to continue after errors? I think that generally there should not be type errors even while programming is in progress. It means that if I'm referring to something I have to immediately write a stub for it, but I don't think it's that bad. Noam On Wed, Mar 12, 2014 at 10:07 PM, Daniel Micay danielmi...@gmail.comwrote: On 12/03/14 03:52 PM, Clark Gaebel wrote: There is no accurate jump-to-definition, type retrieval, docstring retrieval or semantic completion for Rust. The compiler was not built with support for this kind of tooling in mind, and I seriously doubt that anything but inaccurate hacks will exist for a *long* time. This worries me a lot. It would need to be able to perform type checking/inference even if the file can't be fully parsed, or there are type errors in other places. At the moment, each phase simply assumes all of the previous stages were fully completed, and it bails out immediately on any error by unwinding via failure. It's easy to see this from the error reporting. Rust can report multiple errors within the same phase, but it's unable to report a type error if parsing fails. `clang` was designed with this kind of thing as a central pillar and is able to continue reporting errors or giving useful results to queries from tooling even if there are problems. It's not at all an easy task, and most compilers are not able to do it. A language like Go is simple enough that tooling like completion can be done without help from a compiler. However, Rust has powerful local type inference, which presents a difficult obstacle. Another enormous obstacle is the power of traits - a type can have methods provided by traits, if the trait is in scope and the type is covered by an implementation, which may be generic. ___ 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] Virtual fn is a bad idea
Is it correct for me to assume that, even if accepted, virtual things will be behind a feature flag for 1.0? If so, then I think that will be enough friction to cause library authors to favor traits instead, especially if users of virtual-using-libraries would have to turn on the feature flag as well. On Thu, Mar 13, 2014 at 12:34 AM, comex com...@gmail.com wrote: Small comments: - C++ RTTI is known for being slow, because dynamic_cast has to traverse the inheritance tree to decide whether the requested type is in there. LLVM and I think something else I've seen (V8?) improve on it by having a master enum of class IDs and then just testing whether the object's class ID is between the beginning and end of the list of subclasses of the requested one. As long as this is about performance, I think it would be nice to do that instead of using an implementation people are going to be motivated to replace with custom code anyway. It would require some kind of enum-based syntax to be able to enumerate all the subclasses in one compilation unit, but in my opinion that would be an improvement in some ways. For instance, it would be more sane to implement pattern matching for - maybe not very important for DOM nodes, but perhaps other things. (While not as commonly faulted, virtual methods themselves are also something of a worst case compared to situations where the compiler might know in superclass X - either because the code was written using pattern matching or because of some slightly fancy magic - that the class is either a Y or a Z, the only two subclasses, and use regular branches with inlining, instead of having to go with a full-blown indirect jump for everything that differs between subclasses.) - Alternately, if a C++-like interface is really the right answer... for the reasons mentioned elsewhere in the thread (orthogonality/more than one way to do it, bad interfaces, and all that), it should still be heavily discouraged. That is, only a small number of projects with pressing performance needs similar to this particular object tree scenario ought to be using it. But in that case, I don't think it's necessary to make it nice. In fact, I think it should be nasty: if people think like me (...but I don't design serious libraries...), then feature gates requiring one line of code to get past are not going to convince them to rethink their design; they will just bludgeon through them in order to write Java code in Rust. Servo can live with one part of it using nasty macros instead of nice language features. And in C, in my opinion, it's not even particularly nasty even without macros. I appreciate that Rust would need macros to ensure compile-time safety, but it can't be that bad... ___ 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 automation downtime
Curious, Whole Mozilla moving ? or just some teams ? and why ? making room for others ? kicked out by grumpy landlord or mayor ? :-) On Wed, Mar 12, 2014 at 11:08 PM, Brian Anderson bander...@mozilla.comwrote: This weekend Mozilla's Mountain View office is moving, and along with it some of Rust's build infrastructure. There will be downtime. Starting tonight bors is not gated on the mac or android builders and those machines are turned off. Sometime this weekend other build machines, including the build master and bors, will be moved and things will stop working. The Monday triage email will be delayed. We'll sort everything out Monday. Sorry for the inconvenience. Regards, Brian ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -Thad +ThadGuidry https://www.google.com/+ThadGuidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Virtual fn is a bad idea
On 3/13/14 6:00 AM, Benjamin Striegel wrote: Is it correct for me to assume that, even if accepted, virtual things will be behind a feature flag for 1.0? If so, then I think that will be enough friction to cause library authors to favor traits instead, especially if users of virtual-using-libraries would have to turn on the feature flag as well. Yes, I think that's almost certain. I think, based on the feedback, that the idea needs some time to bake anyhow. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Bay Area Rust meetup tonight! OSs, Parallel Layout in Servo, and Debugging Rust
Hello Rust, Just wanted to remind everyone of the Rust meetup tonight at the SF Mozilla Headquarters. Doors open at 7pm. We've had to make some substitutions with the speakers due to some conflicts, though. Here is the lineup: • Julia Evans: Writing an operating system in Rust (without knowing Rust or how to write an OS) • Patrick Walton: Parallel layout in Servo • Alex Crichton: Debugging Rust If you haven't signed up, you can do so here: http://www.meetup.com/Rust-Bay-Area/events/166034142/ I look forward to seeing you all tonight! -Erick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust automation downtime
The Mountain View office outgrew their old location and they're moving to a larger one. On Thu, Mar 13, 2014 at 6:21 AM, Thad Guidry thadgui...@gmail.com wrote: Curious, Whole Mozilla moving ? or just some teams ? and why ? making room for others ? kicked out by grumpy landlord or mayor ? :-) On Wed, Mar 12, 2014 at 11:08 PM, Brian Anderson bander...@mozilla.comwrote: This weekend Mozilla's Mountain View office is moving, and along with it some of Rust's build infrastructure. There will be downtime. Starting tonight bors is not gated on the mac or android builders and those machines are turned off. Sometime this weekend other build machines, including the build master and bors, will be moved and things will stop working. The Monday triage email will be delayed. We'll sort everything out Monday. Sorry for the inconvenience. Regards, Brian ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- -Thad +ThadGuidry https://www.google.com/+ThadGuidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ 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] Virtual fn is a bad idea
And of course I forgot to reply to the list at large... sorry :x
-- Matthieu
On Wed, Mar 12, 2014 at 8:48 PM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
On Tue, Mar 11, 2014 at 10:18 PM, Patrick Walton pcwal...@mozilla.comwrote:
On 3/11/14 2:15 PM, Maciej Piechotka wrote:
Could you elaborate on DOM? I saw it referred a few times but I haven't
seen any details. I wrote simple bindings to libxml2 dom
(https://github.com/uzytkownik/xml-rs - warning - I wrote it while I was
learning ruby) and I don't think there was a problem of OO - main
problem was mapping libxml memory management and rust's one [I gave up
with namespaces but with native rust dom implementation it would be
possible to solve in nicer way]. Of course - I might've been at too
early stage.
You need:
1. One-word pointers to each DOM node, not two. Every DOM node has 5
pointers inside (parent, first child, last child, next sibling, previous
sibling). Using trait objects would 10 words, not 5 words, and would
constitute a large memory regression over current browser engines.
2. Access to fields common to every instance of a trait without virtual
dispatch. Otherwise the browser will be at a significant performance
disadvantage relative to other engines.
3. Downcasting and upcasting.
4. Inheritance with the prefix property, to allow for (2).
If anyone has alternative proposals that handle these constraints that
are more orthogonal and are pleasant to use, then I'm happy to hear them.
I'm just saying that dismissing the feature out of hand is not productive.
Patrick
Please excuse me, I need some kind of visualization here, so I concocted a
simple tree:
// So, in pseudo C++, let's imagine a DOM tree
struct Element { Element *parent, *prevSib, *nextSib, *firstChild,
*lastChild; uint leftPos, topPos, height, width; bool hidden; };
struct Block: Element { BlockProperties blockP; }; struct Div: Block {};
struct Inline: Element { InlineProperties inlineP; }; struct Span: Inline
{};
Now, I'll be basically mimicking the way LLVM structures its AST, since
the LLVM AST achieves dynamic casting without RTTI. Note that this has a
very specific downside: the hierarchy is NOT extensible.
// And now in Rust (excuse my poor syntax/errors)
enum ElementChild'r { ChildBlock('r Block), ChildInline('r Inline) }
struct Element {
child: Option'self ElementChild'self;
parent: 'self Element;
prevSib, nextSib, firstChild, lastChild: Option'self Element;
leftPos, topPos, height, width: uint;
hidden: bool;
}
enum BlockChild'r { ChildDiv('r Div) }
struct Block {
elementBase: Element;
child: Option'self BlockChild'self;
blockP: BlockProperties;
}
struct Div { blockBase: Block; }
enum InlineChild'r { ChildSpan('r Span) }
struct Inline {
elementBase: Element;
child: Option'self InlineChild'self;
inlineP: InlineProperties;
}
struct Span { inlineBase: Inline; }
Let us review our objectives:
(1) One word to each DOM element: check = Option'r Element
(2) Direct access to a field, without indirection: check =
span.inlineBase.elementBase.hidden
(3) Downcast and upcasting: check = downcast is done by matching:
match(element.child) { ChildBlock('r block) = /* act on block */,
ChildInline('r inline) = /* act on inline */); upcast is just accessing
the base field.
(4) Inheritance with the prefix property = not necessary, (2) is already
satisfied.
Note on (3): multiple bases are allowed easily, it's one field per base.
In order to reduce the foot-print; avoiding having a child field at each
level of the hierarchy might be beneficial. In this case, only the final
classes are considered in ElementChild
enum ElementChild'r { ChildDiv('r Div), ChildSpan('r Span) }
And then downcasting to 'r Block is achieved by:
match(element.final) { ChildDiv('r div) = Some('r div.blockBase), _ =
None }
I would note that this does not make use of traits at all; the analysis is
only based on Patrick's list of objectives which I guess is incomplete and
I was lacking a realistic example so it might not address the full scope of
the problem...
... still, for CLOSED hierarchies, the use of traits should not be
necessary, although it might be very convenient.
-- Matthieu.
___
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] Virtual fn is a bad idea
Matthieu,
I tried to model something similar this way. Sometimes the extra pattern
matching gets tedious with this approach. You also end up with a lot of
constructors with similar names. I also found myself writing a lot of trivial
function wrappers around constructors. Of course there are benefits to a
non-extensible system like this. For instance, you can tell if you have
addressed every case in a match statement.
Someone on IRC mentioned that a feature similar to Haskell pattern synonyms may
make it less awkward to use these enum wrappers.
Eric
On Mar 13, 2014, at 12:56 PM, Matthieu Monrocq matthieu.monr...@gmail.com
wrote:
And of course I forgot to reply to the list at large... sorry :x
-- Matthieu
On Wed, Mar 12, 2014 at 8:48 PM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
On Tue, Mar 11, 2014 at 10:18 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 3/11/14 2:15 PM, Maciej Piechotka wrote:
Could you elaborate on DOM? I saw it referred a few times but I haven't
seen any details. I wrote simple bindings to libxml2 dom
(https://github.com/uzytkownik/xml-rs - warning - I wrote it while I was
learning ruby) and I don't think there was a problem of OO - main
problem was mapping libxml memory management and rust's one [I gave up
with namespaces but with native rust dom implementation it would be
possible to solve in nicer way]. Of course - I might've been at too
early stage.
You need:
1. One-word pointers to each DOM node, not two. Every DOM node has 5 pointers
inside (parent, first child, last child, next sibling, previous sibling).
Using trait objects would 10 words, not 5 words, and would constitute a large
memory regression over current browser engines.
2. Access to fields common to every instance of a trait without virtual
dispatch. Otherwise the browser will be at a significant performance
disadvantage relative to other engines.
3. Downcasting and upcasting.
4. Inheritance with the prefix property, to allow for (2).
If anyone has alternative proposals that handle these constraints that are
more orthogonal and are pleasant to use, then I'm happy to hear them. I'm
just saying that dismissing the feature out of hand is not productive.
Patrick
Please excuse me, I need some kind of visualization here, so I concocted a
simple tree:
// So, in pseudo C++, let's imagine a DOM tree
struct Element { Element *parent, *prevSib, *nextSib, *firstChild,
*lastChild; uint leftPos, topPos, height, width; bool hidden; };
struct Block: Element { BlockProperties blockP; }; struct Div: Block {};
struct Inline: Element { InlineProperties inlineP; }; struct Span: Inline {};
Now, I'll be basically mimicking the way LLVM structures its AST, since the
LLVM AST achieves dynamic casting without RTTI. Note that this has a very
specific downside: the hierarchy is NOT extensible.
// And now in Rust (excuse my poor syntax/errors)
enum ElementChild'r { ChildBlock('r Block), ChildInline('r Inline) }
struct Element {
child: Option'self ElementChild'self;
parent: 'self Element;
prevSib, nextSib, firstChild, lastChild: Option'self Element;
leftPos, topPos, height, width: uint;
hidden: bool;
}
enum BlockChild'r { ChildDiv('r Div) }
struct Block {
elementBase: Element;
child: Option'self BlockChild'self;
blockP: BlockProperties;
}
struct Div { blockBase: Block; }
enum InlineChild'r { ChildSpan('r Span) }
struct Inline {
elementBase: Element;
child: Option'self InlineChild'self;
inlineP: InlineProperties;
}
struct Span { inlineBase: Inline; }
Let us review our objectives:
(1) One word to each DOM element: check = Option'r Element
(2) Direct access to a field, without indirection: check =
span.inlineBase.elementBase.hidden
(3) Downcast and upcasting: check = downcast is done by matching:
match(element.child) { ChildBlock('r block) = /* act on block */,
ChildInline('r inline) = /* act on inline */); upcast is just accessing the
base field.
(4) Inheritance with the prefix property = not necessary, (2) is already
satisfied.
Note on (3): multiple bases are allowed easily, it's one field per base.
In order to reduce the foot-print; avoiding having a child field at each
level of the hierarchy might be beneficial. In this case, only the final
classes are considered in ElementChild
enum ElementChild'r { ChildDiv('r Div), ChildSpan('r Span) }
And then downcasting to 'r Block is achieved by:
match(element.final) { ChildDiv('r div) = Some('r div.blockBase), _ =
None }
I would note that this does not make use of traits at all; the analysis is
only based on Patrick's list of objectives which I guess is incomplete and I
was lacking a realistic example so it might not address the full scope of the
problem...
... still, for CLOSED hierarchies, the use of traits should not be necessary,
Re: [rust-dev] Virtual fn is a bad idea
Also this approach uses more memory. At least a byte per pointer and maybe
more with padding. In most cases like this you would prefer to use a vtable
instead of tags to reduce the memory footprint.
Eric
On Mar 13, 2014, at 1:17 PM, Eric Summers eric.summ...@me.com wrote:
Matthieu,
I tried to model something similar this way. Sometimes the extra pattern
matching gets tedious with this approach. You also end up with a lot of
constructors with similar names. I also found myself writing a lot of
trivial function wrappers around constructors. Of course there are benefits
to a non-extensible system like this. For instance, you can tell if you have
addressed every case in a match statement.
Someone on IRC mentioned that a feature similar to Haskell pattern synonyms
may make it less awkward to use these enum wrappers.
Eric
On Mar 13, 2014, at 12:56 PM, Matthieu Monrocq matthieu.monr...@gmail.com
wrote:
And of course I forgot to reply to the list at large... sorry :x
-- Matthieu
On Wed, Mar 12, 2014 at 8:48 PM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
On Tue, Mar 11, 2014 at 10:18 PM, Patrick Walton pcwal...@mozilla.com
wrote:
On 3/11/14 2:15 PM, Maciej Piechotka wrote:
Could you elaborate on DOM? I saw it referred a few times but I haven't
seen any details. I wrote simple bindings to libxml2 dom
(https://github.com/uzytkownik/xml-rs - warning - I wrote it while I was
learning ruby) and I don't think there was a problem of OO - main
problem was mapping libxml memory management and rust's one [I gave up
with namespaces but with native rust dom implementation it would be
possible to solve in nicer way]. Of course - I might've been at too
early stage.
You need:
1. One-word pointers to each DOM node, not two. Every DOM node has 5
pointers inside (parent, first child, last child, next sibling, previous
sibling). Using trait objects would 10 words, not 5 words, and would
constitute a large memory regression over current browser engines.
2. Access to fields common to every instance of a trait without virtual
dispatch. Otherwise the browser will be at a significant performance
disadvantage relative to other engines.
3. Downcasting and upcasting.
4. Inheritance with the prefix property, to allow for (2).
If anyone has alternative proposals that handle these constraints that are
more orthogonal and are pleasant to use, then I'm happy to hear them. I'm
just saying that dismissing the feature out of hand is not productive.
Patrick
Please excuse me, I need some kind of visualization here, so I concocted a
simple tree:
// So, in pseudo C++, let's imagine a DOM tree
struct Element { Element *parent, *prevSib, *nextSib, *firstChild,
*lastChild; uint leftPos, topPos, height, width; bool hidden; };
struct Block: Element { BlockProperties blockP; }; struct Div: Block {};
struct Inline: Element { InlineProperties inlineP; }; struct Span: Inline {};
Now, I'll be basically mimicking the way LLVM structures its AST, since the
LLVM AST achieves dynamic casting without RTTI. Note that this has a very
specific downside: the hierarchy is NOT extensible.
// And now in Rust (excuse my poor syntax/errors)
enum ElementChild'r { ChildBlock('r Block), ChildInline('r Inline) }
struct Element {
child: Option'self ElementChild'self;
parent: 'self Element;
prevSib, nextSib, firstChild, lastChild: Option'self Element;
leftPos, topPos, height, width: uint;
hidden: bool;
}
enum BlockChild'r { ChildDiv('r Div) }
struct Block {
elementBase: Element;
child: Option'self BlockChild'self;
blockP: BlockProperties;
}
struct Div { blockBase: Block; }
enum InlineChild'r { ChildSpan('r Span) }
struct Inline {
elementBase: Element;
child: Option'self InlineChild'self;
inlineP: InlineProperties;
}
struct Span { inlineBase: Inline; }
Let us review our objectives:
(1) One word to each DOM element: check = Option'r Element
(2) Direct access to a field, without indirection: check =
span.inlineBase.elementBase.hidden
(3) Downcast and upcasting: check = downcast is done by matching:
match(element.child) { ChildBlock('r block) = /* act on block */,
ChildInline('r inline) = /* act on inline */); upcast is just accessing
the base field.
(4) Inheritance with the prefix property = not necessary, (2) is already
satisfied.
Note on (3): multiple bases are allowed easily, it's one field per base.
In order to reduce the foot-print; avoiding having a child field at each
level of the hierarchy might be beneficial. In this case, only the final
classes are considered in ElementChild
enum ElementChild'r { ChildDiv('r Div), ChildSpan('r Span) }
And then downcasting to 'r Block is achieved by:
match(element.final) { ChildDiv('r div) = Some('r div.blockBase), _ =
None }
I would note that this does not make
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
Hi,
coersion still can break any code depending on library really badly.
Just suppose the method implemented for Hello in the following example
was added later. After the change, different function is called. IMO,
the risks from glob imports are no worse than this.
struct Hello {
s : ~str
}
impl Hello {
// added later
fn print(self) { println!({}, self.s); }
}
trait Printable {
fn print(self);
}
impl Printable for Hello {
fn print(self) { println!(Hello world from trait); }
}
fn main() {
let h = Hello {s : ~Hello world};
h.print(); // calling different function
}
J
On 03/12/2014 08:17 PM, Bob Ippolito wrote:
Glob imports work well up front but aren't good for maintenance. In
Haskell if a popular library adds a new function it could easily break
any packages that depend on it that use glob imports. It's more work but
almost always best to explicitly import individual names. A tool could
help with this though.
On Wednesday, March 12, 2014, Huon Wilson dbau...@gmail.com
mailto:dbau...@gmail.com wrote:
Certain aspects of them dramatically complicate the name resolution
algorithm (as I understand it), and, anyway, they have various
downsides for the actual code, e.g. the equivalent in Python is
frowned upon:
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing
Maybe they aren't so bad in a compiled statically typed language?
I don't know; either way, I personally find code without glob
imports easier to read, because I can work out which function is
being called very easily, whereas glob imports require more effort.
Huon
On 12/03/14 20:44, Liigo Zhuang wrote:
glob use just make compiler loading more types, but make
programmers a lot easy (to write, to remember). perhaps I'm wrong?
thank you!
--
by *Liigo*, http://blog.csdn.net/liigo/
Google+ https://plus.google.com/105597640837742873343/
___
Rust-dev mailing list
Rust-dev@mozilla.org javascript:_e(%7B%7D,'cvml','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] Virtual fn is a bad idea
On 13/03/14 02:25 PM, Eric Summers wrote: Also this approach uses more memory. At least a byte per pointer and maybe more with padding. In most cases like this you would prefer to use a vtable instead of tags to reduce the memory footprint. Eric A vtable uses memory too. Either it uses a fat pointer or adds at least one pointer to the object. signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
Existing problems with the language aren't a reason to add new problems. signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Virtual fn is a bad idea
Yes, but with tags you pay the cost even if Option is None. Eric On Mar 13, 2014, at 1:33 PM, Daniel Micay danielmi...@gmail.com wrote: On 13/03/14 02:25 PM, Eric Summers wrote: Also this approach uses more memory. At least a byte per pointer and maybe more with padding. In most cases like this you would prefer to use a vtable instead of tags to reduce the memory footprint. Eric A vtable uses memory too. Either it uses a fat pointer or adds at least one pointer to the object. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why we don't like glob use (use std::vec::*)?
On 3/13/14 11:35 AM, Daniel Micay wrote: Existing problems with the language aren't a reason to add new problems. I don't think the coercion is much of a problem; at least, not a fixable one. Dot notation for method syntax in a systems language that supports values pretty much requires some sort of coercion. (Having to write `(mut my_vector).push()` is a non-starter, sadly, as much as the compiler writer in me wants to remove all that code...) Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Virtual fn is a bad idea
A really out there solution to reduce memory may be to use a Cap’n Proto style arena that uses offsets instead of pointers, but I’m sure there are a lot of difficult problems with that. Eric On Mar 13, 2014, at 1:37 PM, Eric Summers eric.summ...@me.com wrote: Yes, but with tags you pay the cost even if Option is None. Eric On Mar 13, 2014, at 1:33 PM, Daniel Micay danielmi...@gmail.com wrote: On 13/03/14 02:25 PM, Eric Summers wrote: Also this approach uses more memory. At least a byte per pointer and maybe more with padding. In most cases like this you would prefer to use a vtable instead of tags to reduce the memory footprint. Eric A vtable uses memory too. Either it uses a fat pointer or adds at least one pointer to the object. ___ 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] Why we don't like glob use (use std::vec::*)?
I am following Rust only for few month. Was the alternate syntax Trait::method(object, other parameters) discussed? It will be sometimes useful to write Clone::clone(x) instead of x.clone() or (x as Clone).clone(). J On 03/13/2014 07:36 PM, Patrick Walton wrote: On 3/13/14 11:35 AM, Daniel Micay wrote: Existing problems with the language aren't a reason to add new problems. I don't think the coercion is much of a problem; at least, not a fixable one. Dot notation for method syntax in a systems language that supports values pretty much requires some sort of coercion. (Having to write `(mut my_vector).push()` is a non-starter, sadly, as much as the compiler writer in me wants to remove all that code...) Patrick ___ 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] Why we don't like glob use (use std::vec::*)?
On 3/13/14 11:44 AM, Jan Klesnil wrote: I am following Rust only for few month. Was the alternate syntax Trait::method(object, other parameters) discussed? It will be sometimes useful to write Clone::clone(x) instead of x.clone() or (x as Clone).clone(). Yup! That's what we call Uniform Function Call Syntax or UFCS. :) Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Virtual fn is a bad idea
Thinking about this a bit more, maybe the memory cost could go away with tagged pointers. That is easier to do on a 64-bit platform though. Eric On Mar 13, 2014, at 1:37 PM, Eric Summers eric.summ...@me.com wrote: Yes, but with tags you pay the cost even if Option is None. Eric On Mar 13, 2014, at 1:33 PM, Daniel Micay danielmi...@gmail.com wrote: On 13/03/14 02:25 PM, Eric Summers wrote: Also this approach uses more memory. At least a byte per pointer and maybe more with padding. In most cases like this you would prefer to use a vtable instead of tags to reduce the memory footprint. Eric A vtable uses memory too. Either it uses a fat pointer or adds at least one pointer to the object. ___ 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] Virtual fn is a bad idea
Hi Eric, Coming back on memory; I presented two designs: - in the first one, you have a tag at each level of the hierarchy, which indeed uses more memory for deep hierarchies but means that a type only knows about its immediate children - in the second one, you have a tag only at the root of the hierarchy, which should use exactly as much memory as a v-table pointer (the fact there is no v-table does not matter) Regarding the boilerplate methods, my experience with LLVM is that with virtual the root describes the interface and each descendant implements it whereas in this system the root implements the interface for each and every descendant... This can be alleviated by only dispatching to the immediate descendants (and let them dispatch further) which is more compatible with the memory-heavy design but also means multiple jumps at each call; not nice. However, once the interface is defined, user code should rarely have to go and inspect the hierarchy by itself; this kind of down-casting should be limited, as it is with regular inheritance in other languages. -- Matthieu On Thu, Mar 13, 2014 at 7:49 PM, Eric Summers eric.summ...@me.com wrote: Thinking about this a bit more, maybe the memory cost could go away with tagged pointers. That is easier to do on a 64-bit platform though. Eric On Mar 13, 2014, at 1:37 PM, Eric Summers eric.summ...@me.com wrote: Yes, but with tags you pay the cost even if Option is None. Eric On Mar 13, 2014, at 1:33 PM, Daniel Micay danielmi...@gmail.com wrote: On 13/03/14 02:25 PM, Eric Summers wrote: Also this approach uses more memory. At least a byte per pointer and maybe more with padding. In most cases like this you would prefer to use a vtable instead of tags to reduce the memory footprint. Eric A vtable uses memory too. Either it uses a fat pointer or adds at least one pointer to the object. ___ 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] Regarding New Hash FrameWork.
Hello Shiva! It'd be best to target these emails at rust-dev instead of me directly :) We've got a guide for new contributors here: https://github.com/mozilla/rust/wiki/Note-guide-for-new-contributors Feel free to reach out for help here, or on our irc.mozilla.org #rust IRC channel. Please let us know if you run into any trouble. Thanks, Erick On Wed, Mar 12, 2014 at 4:42 AM, shivakumar JM shivakuma...@gmail.comwrote: Dear Erick, I am newly joined member for Rust, wanted do some contribution to Rust, after watching mailing posts for a week, i wanted to start contributing on these New Hash FrameWork. I need your support and guidence. I have installed rust on Windows and i could able to run sample programs. Thanks Shiva ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Virtual fn is a bad idea
Kind of off-topic, but there is a heated discussion on the D language forums about why having non-virtual base class methods by default is a bad idea: http://forum.dlang.org/thread/lfqoan$5qq$1...@digitalmars.com Also comes up here: http://forum.dlang.org/thread/zkmunpiikmrezbzme...@forum.dlang.org ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Rust automation downtime
The entire Mountain View office is moving to a new building that has more space. On 03/13/2014 06:21 AM, Thad Guidry wrote: Curious, Whole Mozilla moving ? or just some teams ? and why ? making room for others ? kicked out by grumpy landlord or mayor ? :-) On Wed, Mar 12, 2014 at 11:08 PM, Brian Anderson bander...@mozilla.com mailto:bander...@mozilla.com wrote: This weekend Mozilla's Mountain View office is moving, and along with it some of Rust's build infrastructure. There will be downtime. Starting tonight bors is not gated on the mac or android builders and those machines are turned off. Sometime this weekend other build machines, including the build master and bors, will be moved and things will stop working. The Monday triage email will be delayed. We'll sort everything out Monday. Sorry for the inconvenience. Regards, Brian _ Rust-dev mailing list Rust-dev@mozilla.org mailto:Rust-dev@mozilla.org https://mail.mozilla.org/__listinfo/rust-dev https://mail.mozilla.org/listinfo/rust-dev -- -Thad +ThadGuidry https://www.google.com/+ThadGuidry Thad on LinkedIn http://www.linkedin.com/in/thadguidry/ ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
