On Wed, Mar 12, 2014 at 12:12 PM, Clark Gaebel wrote:
> That implies we need better editors. Things I need for exploring large
> codebases:
>
> 1. Go to definition
> 2. What's the type of this variable/function?
>
> With these two things, it should be relatively easy to read code with or
> without
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 obje
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 b
On 3/12/14 2:59 PM, Daniel Micay wrote:
Traits aren't really any simpler than this. Templates don't produce nice
errors and require the type checker to redo work on each instantiation,
but I don't think the implementation/specification is more complex.
Templates are more complex because of what
I'm actually confused about what "object inheritance" means in Rust.
I understand that Rust makes a very clear separation between behaviour
(traits) and data (structs). So, when I saw mentions to "virtual
structs" implementing or not implementing virtual functions, I had the
/sensation/ that these
On 03/12/2014 08:17 AM, Patrick Walton wrote:
On 3/12/14 3:29 AM, Nathan Myers wrote:
Given such primitives, esoteric constructions like virtual inheritance
could be left to ambitious users.
We did sketch a macro-based solution for this that was basically what
you said. It involved an `rtti!()
> templates without concepts
Traits aren't really any simpler than this. Templates don't produce nice
errors and require the type checker to redo work on each instantiation,
but I don't think the implementation/specification is more complex.
> preprocessor
Macros are more complex than a text-bas
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" a écrit :
> Fair enough. I didn't consider that. Note to self: rust ain't ocaml. :)
> On
Fair enough. I didn't consider that. Note to self: rust ain't ocaml. :)
On Mar 12, 2014 4:53 PM, "Daniel Micay" 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
>> We should also use tags: `Rejected` / `Approved`
>
> I'm specifically trying to avoid those words :) 'approved' is stronger than
> I want, because an approved RFC still may not get merged into the language,
> and being 'rejected' is unfun.
XMPP uses the XEP process, which has decent names for t
Hi rust-dev@,
We participated in an informal "try a new language" session and decided to
try out Rust. The goal of session was to implement a simple TCP proxy.
Our approach was to accept an incoming connection, then open an outgoing
connection, and finally to spawn two tasks, each doing a blockin
On 03/12/2014 03:42 AM, Simon Sapin wrote:
On 12/03/2014 01:11, Brian Anderson wrote:
* Fork the RFC repohttp://github.com/rust-lang/rfcs
* Copy `-template.md` to `active/-my-feature.md` (where
'my-feature' is descriptive. don't assign an RFC number yet).
* Fill in the RFC
* Submit a pul
On 03/12/2014 12:54 AM, Flaper87 wrote:
2014-03-12 2:11 GMT+01:00 Brian Anderson mailto:bander...@mozilla.com>>:
[snip]
-
Many changes, including bug fixes and documentation improvements can
be implemented and reviewed via the normal GitHub pull request workflow.
Some c
On 12/03/14 04:35 PM, Niko Matsakis wrote:
> On Wed, Mar 12, 2014 at 03:12:16PM -0400, Clark Gaebel wrote:
>> That implies we need better editors. Things I need for exploring large
>> codebases:
>>
>> 1. Go to definition
>> 2. What's the type of this variable/function?
>
> FWIW, ctags (with etags-
On 12/03/14 04:24 PM, Patrick Walton wrote:
> It's not as dire as you suggest. We can just allow some further passes
> to continue if earlier passes fail. We have this "ty_err" infrastructure
> in place already. Parsing creating an incomplete AST is also possible.
>
> I don't really think that Go
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 requ
On 3/12/14 12:33 PM, Daniel Micay wrote:
Rust is already a large language, and the interactions between many of
the features are subtle or poorly defined.
Citation? Like what?
There's a complexity cost for
every feature that's added. It gets harder for a single programmer to
learn the languag
On Wed, Mar 12, 2014 at 03:12:16PM -0400, Clark Gaebel wrote:
> That implies we need better editors. Things I need for exploring large
> codebases:
>
> 1. Go to definition
> 2. What's the type of this variable/function?
FWIW, ctags (with etags-select [1]) gives me both of these things
today to an
It's not as dire as you suggest. We can just allow some further passes to
continue if earlier passes fail. We have this "ty_err" infrastructure in place
already. Parsing creating an incomplete AST is also possible.
I don't really think that Go is that much easier to do completion on. Type
infer
That makes sense. Rust is an easier language to parse then C/C++ though, so
maybe it isn’t necessary. Just need to convert the source in to an AST with an
alternate parser that can throw out stuff that is invalid. Then analyze it
with the compiler.
Eric
On Mar 12, 2014, at 3:07 PM, Daniel M
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
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 inacc
Maybe I’m wrong, but I’m not sure this is accurate. rustdoc does all of this
with libsyntax including jumping to the line of the actual source code for a
symbol. Maybe it isn’t perfectly ideal for some tools, but I don’t think it is
anywhere near a lost cause.
Eric
On Mar 12, 2014, at 2:52 P
> 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
Yes, but you can minimize the risk. Particularly if you are importing your own
modules. Just need to use some common sense.
If you are referring to importing at the block level, I see a lot of Rust code
doing that including in the compiler. Glob imports are not really used though.
Like most
Is that what people actually do? You still risk breakage if you glob import
from two or more modules in the same block.
On Wed, Mar 12, 2014 at 12:22 PM, Eric Summers wrote:
>
> Fixed ;-)
>
> On Mar 12, 2014, at 2:19 PM, Eric Summers wrote:
>
> I think it helps that Rust allows imports in any
On 12/03/14 03:12 PM, Clark Gaebel wrote:
> That implies we need better editors. Things I need for exploring large
> codebases:
>
> 1. Go to definition
> 2. What's the type of this variable/function?
>
> With these two things, it should be relatively easy to read code with or
> without glob impor
On 12/03/14 09:21 AM, Niko Matsakis wrote:
> I personally think that offering some kind of virtual structs fits
> completely within Rust. We've always tried to avoid "one size fits
> all" thinking -- in real life there are performance tradeoffs, and you
> often can't cover the entire space with a s
Fixed ;-)
On Mar 12, 2014, at 2:19 PM, Eric Summers wrote:
> I think it helps that Rust allows imports in any block. You could use glob
> imports like this with less risk of breaking:
>
> ```
> fn foo() {
> use std::str::*
> [..]
> }
> ```
>
> Eric
>
>
> On Mar 12, 2014, at 2:
I think it helps that Rust allows imports in any block. You could use glob
imports like this with little risk of breaking:
```
fn foo() {
import std::str::*
[..]
}
```
Eric
On Mar 12, 2014, at 2:17 PM, Bob Ippolito wrote:
> Glob imports work well up front but aren't good for
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
t
I don’t like the glob patterns either, but I might like them more if a module
could define a “prelude” and only those symbols would be imported by a glob
pattern. For example, if you say `use std::str::*`, you would automatically
get the functions but not rarely used things like the raw module.
That implies we need better editors. Things I need for exploring large
codebases:
1. Go to definition
2. What's the type of this variable/function?
With these two things, it should be relatively easy to read code with or
without glob imports.
On Wed, Mar 12, 2014 at 2:57 PM, Daniel Micay wrote
On 12/03/14 06:38 AM, Huon Wilson 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
Yes, I meant Sunday, sigh.
Just keep me in the loop. :)
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
I hope you mean Sunday, not Saturday :) I just want to start the discussion
on Thursday, so I expect there to be plenty of planning done on Friday and
Saturday, so there will be plenty of time to help plan.
On Wednesday, March 12, 2014, Steve Klabnik wrote:
> I am going to be missing Thursday, u
I'm sorry for being kind of off-topic here, but whatever you decide on this
matter, I'd still like to be able to emulate multiple-inheritance using the
following idiom (which requires being able to say that a trait method is
private or, preferably, why don't we make trait methods private by defa
I am going to be missing Thursday, unfortunately, but will be there Saturday.
I wouldn't mind helping organize, but if it's happening Thursday, I
won't be able to take part. No worries.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.
On 3/12/14 7:16 AM, Bill Myers wrote:
However, the extensibility of trait objects comes at the cost of fat
pointers, which can be a problem if you have a lot of pointers.
This is fixable without introducing virtual functions, by adding a
way to express "Struct and vtable for impl Trait for Stru
On 3/12/14 2:24 AM, Maciej Piechotka wrote:
+ impl with potentially partial methods? Is the 'all nodes consuming
same amount of memory' too much memory?
Yes, that's too much memory. You see this in rustc actually. rustc uses
a similar structure and AST nodes take up too much memory, leading to
On 3/12/14 3:29 AM, Nathan Myers wrote:
Given such primitives, esoteric constructions like virtual inheritance
could be left to ambitious users.
We did sketch a macro-based solution for this that was basically what
you said. It involved an `rtti!()` macro that allowed construction of
vtables
> Should the mailing list be involved in this process, as a way to get more
people discussing RFCs?
I'm using Github's "watch" feature on the RFC repo so that I am
automatically emailed whenever a new PR pops up or a discussion occurs.
These emails then get filtered to a "Rust RFCs" folder for eas
> However, the extensibility of trait objects comes at the cost of fat
> pointers, which can be a problem if you have a lot of pointers.
This is fixable without introducing virtual functions, by adding a way to
express "Struct and vtable for impl Trait for Struct" and "thin pointer to
Struct and
First off, it'd probably be best to wait to have this discussion until
the RFC is available, so that we can be sure we're all commenting on
the same thing. The current design evolved after many hours of
discussion about the precise performance requirements we wanted to
meet as well as exploring the
>Is the 'all nodes consuming same amount of memory' too much memory?
Unfortunately yes, this is a very big problem. This solution has been
discussed in the past, but some of the elements types necessarily contain
far more members than others, and this would absolutely destroy memory
usage in the f
On 12/03/2014 01:11, Brian Anderson wrote:
* Fork the RFC repohttp://github.com/rust-lang/rfcs
* Copy `-template.md` to `active/-my-feature.md` (where
'my-feature' is descriptive. don't assign an RFC number yet).
* Fill in the RFC
* Submit a pull request. The pull request is the time to g
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
On 03/11/2014 02:18 PM, Patrick Walton wrote:
> You need:
> 1. One-word pointers to each DOM node, not two...
> 2. Access to fields common to every instance of a trait without
> virtual dispatch...
> 3. Downcasting and upcasting.
Let's look at what C++ virtual functions F and the classes T they
"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 mail
Recently I saw a video of person from scala team who regretted some
'pragmatic' choices in long run so I might be still under it's
impression regarding pragmatic choices in a language. Fortunately (or
unfortunately) I'm not in charge of Rust design.
Also last question - why not use:
struct Elemen
Rather than discuss this here, let's start dogfooding:
https://github.com/rust-lang/rfcs/pull/2
On Wed, Mar 12, 2014 at 3:54 AM, Flaper87 wrote:
>
>
>
> 2014-03-12 2:11 GMT+01:00 Brian Anderson :
>
> [snip]
>
>
>> -
>>
>> Many changes, including bug fixes and documentation improvements can
Hello
Here are some reference documentation I found really powerful, all
information are here, presented the right way. Each have its different
approach. I would be good that the Rust documentation use the same pattern
for each doc.
- QT Doc: http://qt-project.org/doc/qt-4.8/qthread.html /
http:/
2014-03-12 2:11 GMT+01:00 Brian Anderson :
[snip]
> -
>
> Many changes, including bug fixes and documentation improvements can be
> implemented and reviewed via the normal GitHub pull request workflow.
>
> Some changes though are "substantial", and we ask that these be put
> through a bit of
53 matches
Mail list logo
