Re: [rust-dev] Mutable files

[Val Markovic]

On Mon, Jul 21, 2014 at 2:45 PM, Patrick Walton 
wrote:

>
>>  ... in C++. Not in Rust. That's because, unlike C++, Rust is designed
> from the ground up to support moves and copies in a first class way.


As a C++ dev, I feel the need to say THANK YOU for that. Rust being
designed with first-class move support is a major feature for me; it's
something I highlight when I talk about Rust with other C++ devs and it's
universally applauded.


>
>
>  It's just strange that you can change the semantic of an already existing
>> operation just by adding new capabilities. Adding traits should define new
>> operations with new semantics, not changing the semantics of existing
>> operations. At least that's how it works for all other traits, and
>> deviating from that is at least surprising.
>>
>
> Hence the Opt-In Built-In Traits proposal
>
>
>  Maybe the syntax was just too heavy?
>>
>
> Any syntax at all is too much. I am convinced of that.
>
> 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] On Copy = POD

[Val Markovic]

On Fri, Jun 20, 2014 at 11:06 PM, Nick Cameron  wrote:

> I found all the clone()s in Rust unpleasant, it really put me off using
> ref counting.
>

I consider that to be a feature, not a bug.


> Given that this is something C++ programmers coming to Rust will be used
> to using, I believe ergonomics is especially important.
>

I write C++ for a living in a massive codebase and shared_ptrs are used
extremely rarely, and it's *not *because of the perf overhead of the atomic
increment/decrement, but because using shared_ptrs obscures ownership.
People tend to just put some memory in a shared_ptr and not care which part
of the system owns what and that ends up producing code that's very hard to
reason about and maintain.

unique_ptrs have made the transfer of ownership of heap-allocated memory
super-easy. Damn-nigh every design can be expressed with unique_ptrs owned
by the logical owners of that memory passing refs or const refs to other
parts of the system.

So please don't represent that shared_ptrs are commonly used in all good
C++ code. Experience has thought me and others to look at shared_ptrs as a
code smell and something to be flagged for extra clarification by the
author in code review. I hate to quote the Google C++ style guide since it
has many flaws, but this is one of the things it gets completely right
:
"Do not design your code to use shared ownership without a very good reason.
"

Rust has unique_ptrs in the form of ~ and they're doing their job just
fine. Rust needs special support for Rc ergonomics as much as it needs such
support for Gc, which is none at all. In fact, making Rc and Gc pointers
more difficult to use should steer people away from such poor design
crutches.


>
> In this case I don't think we need to aim to be more 'bare metal' than
> C++. Transparent, ref counted pointers in C++ are popular and seem to work
> pretty well, although obviously not perfectly.
>
> zwarich: I haven't thought this through to a great extent, and I don't
> think here is the right place to plan the API. But, you ought to still have
> control over whether an Rc pointer is copied or referenced. If you have an
> Rc object and pass it to a function which takes an Rc, it is copied,
> if it takes a &Rc or a &T then it references (in the latter case with an
> autoderef-ref). If the function is parametric over U and takes a &U, then
> we instantiate U with either Rc or T (in either case it would be passed
> by ref without an increment, deciding which is not changed by having a copy
> constructor). If the function takes a U literal, then U must be
> instantiated with Rc. So, you still get to control whether you reference
> with an increment or not.
>
> I think if Rc is copy, then it is always copied. I would not expect it to
> ever move. I don't think that is untenable, performance wise, after all it
> is what everyone is currently doing in C++. I agree the second option seems
> unpredictable and thus less pleasant.
>
> Cheers, Nick
>
>
> On Sat, Jun 21, 2014 at 4:05 PM, Cameron Zwarich 
> wrote:
>
>> I sort of like being forced to use .clone() to clone a ref-counted value,
>> since it makes the memory accesses and increment more explicit and forces
>> you to think which functions actually need to take an Rc and which
>> functions can simply take an &.
>>
>> Also, if Rc becomes implicitly copyable, then would it be copied rather
>> than moved on every use, or would you move it on the last use? The former
>> seems untenable for performance reasons, since removing unnecessary
>> ref-count operations is important for performance. The latter seems
>> unpredictable, since adding a second use of a value in a function would
>> mean that new code is implicitly executed wherever the first use is.
>>
>> Cameron
>>
>> On Jun 20, 2014, at 8:49 PM, Nick Cameron  wrote:
>>
>> I think having copy constructors is the only way to get rid of `.clone()`
>> all over the place when using` Rc`. That, to me, seems very important (in
>> making smart pointers first class citizens of Rust, without this, I would
>> rather go back to having @-pointers). The trouble is, I see incrementing a
>> ref count as the upper bound on the work that should be done in a copy
>> constructor and I see no way to enforce that.
>>
>> So, I guess +1 to spirit of the OP, but no solid proposal for how to do
>> it.
>>
>>
>> On Sat, Jun 21, 2014 at 8:00 AM, Benjamin Striegel <
>> ben.strie...@gmail.com> wrote:
>>
>>> I'm not a fan of the idea of blessing certain types with a
>>> compiler-defined whitelist. And if the choice is then between ugly code and
>>> copy constructors, I'll take ugly code over surprising code.
>>>
>>>
>>> On Fri, Jun 20, 2014 at 3:10 PM, Patrick Walton 
>>> wrote:
>>>
 On 6/20/14 12:07 PM, Paulo Sérgio Almeida wrote:]

  Currently being Copy equates with being Pod. The more time passes and
> 

Re: [rust-dev] Improving our patch review and approval process (Hopefully)

[Val Markovic]

On Wed, Feb 19, 2014 at 12:38 PM, Felix S. Klock II wrote:

>
> On 19/02/2014 21:12, Flaper87 wrote:
>
> 2. Approval Process
>
>  [...] For example, requiring 2 r+ from 2 different reviewers instead of
> 1. This might seem a bit drastic now, however as the number of contributors
> grows, this will help with making sure that patches are reviewed at least
> by 2 core reviewers and they get enough attention.
>
>
> I mentioned this on the #rust-internals irc channel but I figured I should
> broadcast it here as well:
>
> regarding fractional r+, someone I was talking to recently described their
> employer's process, where the first reviewer (who I think is perhaps part
> of a priveleged subgroup) assigned the patch with the number of reviewers
> it needs so that it isn't a flat "every patch needs two reviewers" but
> instead, someone says "this looks like something big/hairy enough that it
> needs K reviewers"
>

>From my personal experience with big companies, this is how it works.
Having a policy where you require more than one reviewer for everything is
too much process and wasted time; it's the big changes that require more
than one person reviewing that get this level of attention, usually with
the first reviewer going "hey X, could you take a look at this as well?".

And having a every pull request auto-tested as soon as it is sent out would
be wonderful; Travis CI is great for this (it isolates and times-out builds
if needed), but obviously couldn't work for Rust. A "b+" meaning "please
build this" seems like the second best thing.


>
> just something to consider, if we're going to look into strengthening our
> review process.
>
> Cheers,
> -Felix
>
>
> On 19/02/2014 21:12, Flaper87 wrote:
>
>Hi all,
>
>  I'd like to share some thoughts with regard to our current test and
> approval process. Let me break this thoughts into 2 separate sections:
>
>  1. Testing:
>
>  Currently, all patches are being tested after they are approved. However,
> I think it would be of great benefit for contributors - and reviewers - to
> test patches before and after they're approved. Testing the patches before
> approval will allow folks proposing patches - although they're expected to
> test the patches before submitting them - and reviewers to know that the
> patch is indeed mergeable. Furthermore, it will help spotting corner cases,
> regressions that would benefit from a good discussion while the PR is hot.
>
>  I think we don't need to run all jobs, perhaps just Windows, OSx and
> Linux should be enough for a first test phase. It would also be nice to run
> lint checks, stability checks etc. IIRC, GH's API should allow us to notify
> this checks failures.
>
>2. Approval Process
>
> I'm very happy about how patches are reviewed. The time a patch waits
> before receiving the first comment is almost 0 seconds and we are spread in
> many patches. If we think someone else should take a look at some patch, we
> always make sure to mention that person.
>
>  I think the language would benefit from a more strict approval process.
> For example, requiring 2 r+ from 2 different reviewers instead of 1. This
> might seem a bit drastic now, however as the number of contributors grows,
> this will help with making sure that patches are reviewed at least by 2
> core reviewers and they get enough attention.
>
>
>  I think both of these points are very important now that we're moving
> towards 1.0 and the community keeps growing.
>
> Thoughts? Feedback?
>
>  --
>   Flavio (@flaper87) Percoco
> http://www.flaper87.com
> http://github.com/FlaPer87
>
>
> ___
> Rust-dev mailing 
> listRust-dev@mozilla.orghttps://mail.mozilla.org/listinfo/rust-dev
>
>
>
> --
> irc: pnkfelix on irc.mozilla.org
> email: {fklock, pnkfelix}@mozilla.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] Deprecating rustpkg

[Val Markovic]

I'll second Armin and Corey here; if lib A and B depend on different
versions of lib C, you *must* still be able to easily build and link them
together as deps of lib D. This is *critical* in large codebases where it's
not feasible to go into A and B and update which version of C they depend
on since A & B are possibly very big and have tons of other users who
aren't as willing as you are to switch to a new version of C.

And now imagine a (frighteningly common) nightmare scenario, where the
library version clash is not two steps away from you, but say 8 and 12. So
you link something that depends on something that depends on something ...
that 8 steps away depends on A (which depends on C v1), and a different
chain of deps that 12 steps away depends on B (which depends on C v2). Good
luck resolving that.

Even more fun scenario: both A and B depend on C v1, but B wants to update
to C v2 because of a new feature they need. And they can't, because it
would break everyone upstream of them who depended on A. And no, you can't
just go into A and update it to C v2 because maybe the API in C changed,
maybe the same functions return slightly different results (a bug was
fixed, but old code implicitly depends on the bug) and just maybe lib A is
millions of lines of code and updating it would take weeks (or longer) for
the team that maintains A in the first place, and God only knows how long
it would take you.

This is a huge problem in large C++ codebases. It is not fun. An example: every
version of Xerces-C++ puts its code in a new C++
namespace,
so code is in xerces_3_0, xerces_3_1, xerces_3_2 etc to prevent these kinds
of issues.

Not being able to link together different versions of a library together
completely breaks encapsulation. Just don't go there.



On Thu, Jan 30, 2014 at 4:27 PM, Armin Ronacher  wrote:

> Hi,
>
>
> On 30/01/2014 23:08, Tony Arcieri wrote:
>
>> What if the different versions of the library do incompatible things,
>> like:
>>
>> - Talk incompatible versions of a network protocol
>> - Serialize data differently
>> - One contains important security fixes the other does not
>>
> They are different libraries.  It's not an issue in practice because the
> situation where this happens is if you have a library depending on another
> library internally.
>
> Not having the option to run multiple versions of the same library in
> parallel in different parts is a major problem and Python suffers
> tremendously under this.
>
>
> Regards,
> Armin
>
> ___
> 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] Deprecating rustpkg

[Val Markovic]

On Jan 27, 2014 8:53 PM, "Jeremy Ong"  wrote:
>
> I'm somewhat new to the Rust dev scene. Would anybody care to summarize
roughly what the deficiencies are in the existing system in the interest of
forward progress? It may help seed the discussion for the next effort as
well.

I'd like to second this request. I haven't used rustpkg myself but I've
read its reference manual (
https://github.com/mozilla/rust/blob/master/doc/rustpkg.md) and it sounds
like a reasonable design. Again, since I haven't used it, I'm sure I'm
missing some obvious flaws.

>
>
> On Mon, Jan 27, 2014 at 6:05 PM, Steve Klabnik 
wrote:
>>
>> Vote of strong support here. I removed the rustpkg chapter from Rust
>> for Rubyists for a reason. :/
>> ___
>> 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] RFC: New Rust channel proposal

[Val Markovic]

On Thu, Jan 23, 2014 at 2:32 PM, Vadim  wrote:

> Well maybe then channel() -> (SendEnd, RecvEnd) ?   Or, channel() ->
> (Source, Drain) ?
>

When there are two concepts, one for "data comes out of this" and one for
"data goes into this", the names I have most often encountered are "Source"
and "Sink". They're pretty descriptive; you immediately know which end is
which. "Source" and "Drain" serves the same purpose as well.

"Port" and "Chan" are IMO really bad names. Neither tells me anything about
does it accept or provide data. "Chan" especially, since conceptually a
channel is the conduit between a source and a sink.

Like Brian said, three concepts are involved here. Good names would be
"Source", "Channel" and "Sink", all three of which are descriptive. No
explanation is necessary to understand what's behind the names and no
memorization is required.

Channel::new() returning a Source and Sink would be an improvement, but it
breaks the mental model of "Type::new() creates a new Type" from the rest
of the codebase.

We need a different name than "new" for this. "Channel::pipe()" is better,
but since function names are often verbs or start with verbs, it implies
not that a pipe is being built, but that the function accepts something
that is piped through the channel.

Channel::new_pipe() returning a (Source, Sink) seems ideal. "new" as the
word before "pipe" would be a good choice because it's suggestive of how
"new()" in other types builds the type.


>
>
> On Thu, Jan 23, 2014 at 12:33 PM, Brian Anderson wrote:
>
>> On 01/13/2014 10:15 PM, Liigo Zhuang wrote:
>>
>>> People should rethink the Chan api that Chan::new() does not returns a
>>> value of type Chan (instead, a tuple), which is strange, and inconsistent
>>> with other Type::new().
>>>
>>>
>> Agree, though I haven't heard any great suggestions yet. The core problem
>> is that there are three different entities involved: the sending end, the
>> recieving end, and the thing that represents the entire channel, and they
>> all need different names. The best I've heard is `pipe() -> (Port, Chan)`,
>> but I would rather call the whole thing a channel and have a different name
>> for the sender.
>>
>> ___
>> 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] Ideas of small projects or improvements

[Val Markovic]

On Sun, Dec 1, 2013 at 1:43 PM, Daniel Micay  wrote:

> Ranges are a more
> modern implementation of iterators and are much more easily composed.
> Ranges are also trivially memory safe, and I doubt that split
> current/end iterators can provide memory safety with only references.
>

Agreed with Daniel. The C++ community has by and large reached the
conclusion that ranges are a much better idea than iterators. Boost.Range
is commonly recommended. There's also talk about getting ranges into the
C++ standard; see
N3350for
an example.

Let's not make the same mistake in Rust that C++ is now struggling to fix.


> ___
> 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 front-end to GCC

[Val Markovic]

Agreed with Daniel. The D approach would be best. They one frontend and
then dmd (frontend + proprietary backend), ldc (frontend + llvm) and gdc
(frontend + gcc backends) use that. This would be the best for the Rust
ecosystem, users and developers of the various compilers; there's no
duplication of efforts and critically, very few compiler-specific bugs. One
can reasonably assume that any code written for dmd will work with ldc and
gdc.

Multiple independent compilers would require a common, detailed spec to
reach any level of interoperability. That comes with its own costs and
complexities and IMO I don't think they're worth it.


On Tue, Dec 3, 2013 at 9:58 AM, Benjamin Striegel wrote:

> This is very cool! But, I agree with Daniel. If there's any way that we
> can reduce the duplication of effort, we should. This is especially true
> given that we don't have anything close to an accurate written
> specification to help keep two implementations in sync.
>
>
> On Tue, Dec 3, 2013 at 12:54 PM, Daniel Micay wrote:
>
>> On Tue, Dec 3, 2013 at 12:22 PM, Philip Herron 
>> wrote:
>> > Hey all
>> >
>> > Some of you may have noticed the gccrs branch on the git mirror. Since
>> PyCon
>> > IE 2013 i gave a talk on my Python Front-end pet project and heard about
>> > rust by a few people and i never really looked at it before until then
>> but
>> > i've kind of been hooked since.
>> >
>> > So to learn the language i've been writing this front-end to GCC. Only
>> > really a a month or  so on and off work in between work. Currently it
>> > compiles alot of rust already in fairly little effort on my side GCC is
>> > doing loads of the heavy lifting.
>> >
>> > Currently it compiles most of the basic stuff such as a struct an impl
>> block
>> > while loop, functions expressions calling methods passing arguments etc.
>> > Currently focusing on getting the typing working correctly to support &
>> and
>> > ~ and look at how templates might work as well as need to implement
>> break
>> > and return.
>> >
>> > There is still a lot of work but i would really like to share it and see
>> > what people think. Personally i think rust will target GCC very well
>> and be
>> > a good addition (if / when it works). I really want to try and give
>> back to
>> > this community who have been very good to me in learning over the last
>> few
>> > years with GSOC.
>> >
>> > To get a jist of what i am compiling in my tests are something like:
>> >
>> > fn fib1 (n:int) -> int {
>> > if (n <= 1) { 1 }
>> > else { n * fib1 (n - 1) }
>> > }
>> >
>> > fn fib2 (n:int) -> int {
>> > let mut i = 1;
>> > let mut result = 1;
>> > while (i <= n) {
>> > result = result * i;
>> > i = i + 1;
>> > }
>> > result
>> > }
>> >
>> > fn main () {
>> > fib1 (10);
>> > fib2 (10);
>> > }
>> >
>> > Or
>> >
>> > struct mytype {
>> > x : int
>> > }
>> >
>> > impl mytype {
>> > fn test (self) -> int {
>> > println ("yyoyoyo");
>> > test2 (1)
>> > }
>> > }
>> >
>> > fn main () {
>> > let x = mytype { x : 1 };
>> > let z = x.x;
>> > let y = x.test ();
>> > let a = test2 (y);
>> > }
>> >
>> > fn test2 (x : int) -> int {
>> > let z = x;
>> > 1 + z
>> > }
>> >
>> > Theses are both pretty abstract test cases but were the ones i just made
>> > work a while ago. Lots more work to do on it but i feel these 2 test
>> cases
>> > working is kind of a mile stone for me.
>> >
>> > I will start a wiki page on the project and the code i work on is at
>> > http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/gccrs and i
>> have
>> > it on github first mostly for travis CI and so i can do a bunch of
>> commits
>> > and rebase etc http://github.com/redbrain/gccrs
>> >
>> > Thanks
>> >
>> > --Phil
>>
>> I think another backend would be very valuable, but not another
>> implementation of the rest of the compiler. I would expect a gcc
>> backend to be based on libsyntax/librustc with an alternate backend
>> for `trans` and `back`.
>>
>> Implementing a fully compatible compiler with a full parser/macros,
>> metadata, type-checking, borrow checking, liveness checking, type
>> inference, privacy/reachability, etc. doesn't seem feasible. The
>> upstream compiler already has hundreds of issues to fix in these
>> areas.
>> ___
>> 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] Placement new and the loss of `new` to keywords

[Val Markovic]

This is an interesting thread. A few points:

- "box" makes a lot more sense than "new"; as others have pointed out, the
latter maps to a different concept in C++ which makes it familiar in the
worst way.
- "Foo::init" is terrible, agreed, but "Foo::new" is less than ideal as
well. "Foo::create" might be better. Just read this aloud: "this function
news a value." What? That makes no sense. "This function creates a value."
Much better, isn't it? Point being, it should be a verb. JavaScript does it
with Object.create, so there's precedent.
- placement new might be common in Servo and browser engines, but it's not
that common in most C++. After 10 years and 200k+ LOC of C++ across many,
many different programs and paradigms I've yet to use it once. Sure, that's
just one person's experience but others seem to be echoing the same
sentiment. I'm not saying let's not have placement new, just that we
shouldn't put on an undeserved pedestal.

On Dec 2, 2013 11:39 AM, "Patrick Walton"  wrote:
>
> Only if you SROA and inline the constructor, I think.
>
>
> comex  wrote:
>>
>> On Mon, Dec 2, 2013 at 2:33 PM, Patrick Walton 
wrote:
>>>
>>> That would require an unnecessary move. It needs to be built into the
>>> language.
>>
>>
>> Devil's advocate - aren't such unnecessary moves really easy for LLVM
>> to optimize?
>
>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
> ___
> 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] list of all reserved keywords of the language

[Val Markovic]

On Mon, Nov 25, 2013 at 2:56 AM, Niko Matsakis  wrote:

> On Wed, Nov 20, 2013 at 09:33:15PM +0100, Gábor Lehel wrote:
> > This is an even sillier idea, but then what about keeping `loop` and
> > dropping `while`?
>
> We considered this for a while -- as well as making `loop if` be the
> way you write `while` -- and decided "why antagonize people."


That was the correct decision. While some of us might think that "loop if"
is a better way of saying "while" (I'd include myself here), the latter is
so entrenched that changing it would only make newcomers angry for little
(if any) benefit.


> Besides, `while` has it's place.
>
>
> Niko
> ___
> 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] autocomplete engine for rust

[Val Markovic]

On Tue, Nov 19, 2013 at 1:12 PM, Gokcehan Kara wrote:

> I will be speculating a little since I haven't actually read the source.
> As far as I understand, YouCompleteMe uses python for some parts but at its
> core it has a cpp component using libclang library. libclang library itself
> is already something that provides code completion which is the thing
> missing for rust language.
>
> [libclang]: http://clang.llvm.org/doxygen/group__CINDEX.html
>

This is mostly correct. libclang is clang compiler API (the entire compiler
is in the binary and is exposed through the C API). YCM is written is
several languages: VimScript for the Vim client and Python & C++ for the
server binary. Python is the glue code between the various components and
semantic engines. Jedi is a semantic engine written in Python, OmniSharp is
written in C#. There's a C++ component that talks to libclang. There's
another C++ component that does the complex subsequence candidate string
matching and candidate ranking.


>
>
> On Tue, Nov 19, 2013 at 10:13 PM, Gaetan  wrote:
>
>> I think we can write in rust and perhaps reuse part of the compiler, but
>> we cannot allow to support only fully compiler crates.
>>
>> It may be possible to begin a draft in language such as python
>> (YouCompleteMe seems to be written mostly in python)
>>
>> -
>> Gaetan
>>
>>
>>
>> 2013/11/19 Gokcehan Kara 
>>
>>> I'm willing to help on this task, I think having a good completion
 library can help a lot smoothing the learning curve of a new language. I
 learned python in a few days with aptana, and I remember a few years ago
 how it was easy to write C++ with visual studio. Having an IDE integration
 is almost as important as having good tutorials.
>>>
>>>
>>> That's great. I agree that it would be nice for newbies and I think also
>>> for others as most people are already quite spoiled by the capabilities of
>>> modern IDE's these days.
>>>
>>> I'm also a newbe in Rust and I imagine you want to write in rust itself.
 I can help on the integration with sublime.
>>>
>>>
>>> I was hoping to write in rust because I don't want to implement/maintain
>>> a parser and typechecker from scratch. I was very pleased to see that it's
>>> possible to access everything in `librustc` and `libsyntax` with a simple
>>> `extern`, not sure if this will be removed later.
>>>
>>> rustfind (https://github.com/dobkeratops/rustfind) does this and more,
 for crates that compile.
>>>
>>>
>>> I wasn't aware of that, looks very nice indeed. I will take a look and
>>> see if I can contribute somehow when I have some time.
>>>
>>> Not very, for the general case. If you want autocompletion as you
 type, you currently need to have a fully-compilable crate. Otherwise,
 parsing or typechecking or something else will fail and you won't be
 able to get any results. rustc is currently very all-or-nothing.
>>>
>>>
>>> It's a bummer. Are there any plans to implement some error recovery to
>>> rustc?
>>>
>>> But, you can get useful information for completion out of an
 already-compiling crate, though I'm not sure how much better it would
 be than what etags already does.
>>>
>>>
>>> It has been some time since I last tried tags for autocompletion but it
>>> wasn't very accurate as far as I remember. As far as I know you also need
>>> some editor plugin for this, something like [OmniCppComplete](
>>> http://www.vim.org/scripts/script.php?script_id=1520) which is
>>> basically a cpp parser implemented in vimscript.
>>>
>>> Very, since it would require reworking most of the compiler ;)
>>>
>>>
>>> :)
>>>
>>
>>
>
> ___
> 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] autocomplete engine for rust

[Val Markovic]

On Mon, Nov 18, 2013 at 3:25 PM, Gokcehan Kara wrote:

> I have been thinking of working on an editor agnostic code helper library
> with an autocomplete engine for rust (since there isn't anything yet?) as a
> hobby project to get to know the internals of the compiler. Examples of
> similar projects in different languages include;
>

This is a great idea. Rust needs to have something like libclang. In fact,
I think the Clang project was started because GCC had such poor support for
being used as a library (well, that and the GPLv3 license making it hard
for Apple to link it into Xcode). This should teach us something.


> - [youcompleteme](https://github.com/Valloric/YouCompleteMe)
> (C/C++/Objective-C/Objective-C++) (this one is specific to vim and a more
> general solution to autocompletion in vim but it includes a clang based
> completion engine for c family languages)
>

YCM is a bit more complicated than that (and I'd know since I wrote it :)).
It provides a general framework for tying together various semantic engines
and building an awesome code completion experience on top. YCM currently
uses libclang as the semantic engine for C/C++/ObjC/ObjC++, Jedi for
Python, OmniSharp for C# etc. Plugging in a new semantic engine is very
easy. YCM can use the Vim omnifunc as the semantic source so it can tie
into other plugins that provide an omnifunc, like Eclim for Java or gocode
for Go. YCM then provides its own features on top of that.

YCM *used* to be specific to Vim, but that's slowly changing. I recently
rewrote it from scratch to have a client-server architecture where almost
all of the logic is in the server; the client is a very thin shell that
merely queries the server. Some time in the future you'll see YCM clients
for other editors like SublimeText, emacs and others. I first have to pull
out the server source code into a separate repo on GitHub.

Bottom line, if you get to a point where you have a library with an API
that can provide completions for Rust code, I'd love to hook it into YCM.
There's a similar project (DCD ) going
for D as well; when that's more stable it will be hooked up to YCM too.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Val Markovic]

On Tue, Nov 19, 2013 at 5:21 PM, Patrick Walton wrote:

>
> I agree that we should change this, but give us some credit: it's only an
> obvious design mistake now that we've gotten to this point.
> [...]

The current status is the product of the slow evolution of a design that
> predated the region and slicing system, and what seems obvious now was not
> obvious in retrospect.


Fair point. I give you guys a lot of credit though, Rust is a wonderful
language in general. I also admire how willing core Rust devs are to admit
"ok that was a bad idea, let's try something else." I don't see that every
day; Rust is better for it.

Please continue being awesome.


>
>
> 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] Please simplify the syntax for Great Justice

[Val Markovic]

On Tue, Nov 19, 2013 at 4:43 AM, Daniel Micay  wrote:
>
> The expression ~([1, 2, 3]) has a different type than the expression
> ~[1, 2, 3]. The former is an owned box containing a fixed size array
> (~[int, ..3]) and the latter is a dynamic array (~[int]).
>
> The ~str and ~[T] types are *not* owned boxes in the current type
> system. There has been a proposal for dynamically sized types which
> would make them owned boxes, but I only like it as the path forwards
> for traits/closures and not vectors.
>
> I don't think dynamic arrays/strings belong as built-in types
> hard-wired into the language, especially with a confusing syntax like
> this. They should be treated as other containers are.
>
> In what I think is a sane system, dynamic arrays would be a library
> `Vec` type just like we have `HashMap` and will have other
> vector types like `Rope` or `SmallVec`.


Agreed with this 100%. From a mental model perspective, you can't have ~foo
mean "foo is boxed" everywhere in the language and then go "Oh but ~str and
~[T]? Yeah those are exceptions. You're mental model is wrong".

*Everyone* is going to build this incorrect mental model of "putting ~ in
front of a thing puts that thing in a box" and it's not the user's fault,
it's Rust's fault for having this silly distinction.

~ in front of a type should mean one thing and one thing only. Otherwise
we're just making life difficult for the users for no sensible reason. I
read through all the Rust docs several times over the last few months, I
have years of experience with C++ and thought I had a rock-solid
understanding of ~T (it's just a unique_ptr) and just a few days ago I
learned that ~str and ~[T] are special. And I only learned about this by
randomly browsing through rust-dev.

I felt cheated a bit TBH. It's such an obvious design mistake IMO;
everyone's going to get this wrong because it's counter-intuitive. It's
like mutable default arguments in Python 2.x (which was thankfully fixed in
3.0). [I'm not trying to bash a different language, I know that's against
the rules of the list. I'm just trying to draw a parallel with a different
language design mistake that tripped up everyone as well.]
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev