Re: More Rust code

On Tue, Aug 08, 2017 at 09:09:09AM +0900, Mike Hommey wrote: > On Tue, Aug 08, 2017 at 07:12:13AM +0900, Mike Hommey wrote: > > On Fri, Aug 04, 2017 at 08:45:14AM +0300, Henri Sivonen wrote: > > > I guess I buried my questions in too long a post, so extracting them: > > > > > > On Mon, Jul 31,

Re: More Rust code

On 08/08/2017 11:32 AM, Jeff Muizelaar wrote: On Mon, Aug 7, 2017 at 6:12 PM, Mike Hommey wrote: Note that the tp5n main_startup_fileio reflects the resulting size of xul.dll, which also impacts the installer size: 32-bits 64-bits MSVC (PGO):

Re: More Rust code

On Mon, Aug 7, 2017 at 11:01 PM, Henri Sivonen wrote: > On Tue, Aug 8, 2017 at 1:12 AM, Mike Hommey wrote: > > Here's a bunch of data why "let's switch compilers" is not necessarily > > easy (I happen to have gathered that recently): > > Thank you. > > >

Re: More Rust code

On Mon, Aug 7, 2017 at 6:12 PM, Mike Hommey wrote: > Note that the tp5n main_startup_fileio reflects the resulting size of > xul.dll, which also impacts the installer size: > 32-bits 64-bits > MSVC (PGO): 37904383 40803170 > clang-cl: 39537860

Re: More Rust code

On Tue, Aug 8, 2017 at 1:12 AM, Mike Hommey wrote: > Here's a bunch of data why "let's switch compilers" is not necessarily > easy (I happen to have gathered that recently): Thank you. > Newer versions of clang-cl might generate faster code, but they crash > during the build:

Re: More Rust code

On Tue, Aug 08, 2017 at 07:12:13AM +0900, Mike Hommey wrote: > On Fri, Aug 04, 2017 at 08:45:14AM +0300, Henri Sivonen wrote: > > I guess I buried my questions in too long a post, so extracting them: > > > > On Mon, Jul 31, 2017 at 1:02 PM, Henri Sivonen wrote: > > >

Re: More Rust code

On Fri, Aug 04, 2017 at 08:45:14AM +0300, Henri Sivonen wrote: > I guess I buried my questions in too long a post, so extracting them: > > On Mon, Jul 31, 2017 at 1:02 PM, Henri Sivonen wrote: > > Naïvely, one would think that it should be possible to do that with > > clang

Re: More Rust code

On Mon, Jul 31, 2017 at 4:53 PM, smaug wrote: >> And on the topic of memory management: >> >> DOM nodes themselves obviously have to be able to deal with multiple >> references to them, but otherwise we have a lot of useless use of >> refcounting attributable to the 1998/1999

Re: More Rust code

I guess I buried my questions in too long a post, so extracting them: On Mon, Jul 31, 2017 at 1:02 PM, Henri Sivonen wrote: > Naïvely, one would think that it should be possible to do that with > clang producing "object files" holding LLVM IR and rustc producing > "object

Re: refcounting [WAS: More Rust code]

On 8/2/2017 6:37 AM, Enrico Weigelt, metux IT consult wrote: On 31.07.2017 13:53, smaug wrote: Reference counting is needed always if both JS and C++ can have a pointer to the object. By the way - just curious: Anybody already thought about garbage collection ? Yes. About a decade ago,

Re: refcounting [WAS: More Rust code]

On Wed, Aug 2, 2017, at 08:32 AM, Nathan Froyd wrote: > On Wed, Aug 2, 2017 at 7:37 AM, Enrico Weigelt, metux IT consult > wrote: > > On 31.07.2017 13:53, smaug wrote: > >> Reference counting is needed always if both JS and C++ can have a > >> pointer to the object. > > >

Re: refcounting [WAS: More Rust code]

On Wed, Aug 2, 2017 at 7:37 AM, Enrico Weigelt, metux IT consult wrote: > On 31.07.2017 13:53, smaug wrote: >> Reference counting is needed always if both JS and C++ can have a >> pointer to the object. > > Anybody already thought about garbage collection ? Reference

refcounting [WAS: More Rust code]

On 31.07.2017 13:53, smaug wrote: Reference counting is needed always if both JS and C++ can have a pointer to the object. By the way - just curious: Anybody already thought about garbage collection ? That wouldn't have the problem w/ circular graphs, and should make the whole code

Re: More Rust code

On 07/31/2017 01:02 PM, Henri Sivonen wrote: On Tue, Jul 18, 2017 at 7:01 AM, Jim Blandy wrote: BTW, speaking of training: Jason's and my book, "Programming Rust" will be available on paper from O'Reilly on August 29th! And already available on Safari Books Online

Re: More Rust code

On Tue, Jul 18, 2017 at 7:01 AM, Jim Blandy wrote: > BTW, speaking of training: Jason's and my book, "Programming Rust" will be > available on paper from O'Reilly on August 29th! And already available on Safari Books Online (access available via Service Now request subject

Re: More Rust code

Thanks for starting this conversation. I'd love to be able to use more Rust in Firefox. In SpiderMonkey, the main blocker I encounter is interaction with all the nice utility classes we have in C++, in particular templatized ones. Also, for the rest of Gecko, my main blocker was the lack of

Re: More Rust code

Am 17.07.17 um 21:43 schrieb Ted Mielczarek: Nick, Thanks for kicking off this discussion! I felt like a broken record talking to people about this in SF. From my perspective Rust is our single-biggest competitive advantage for shipping Firefox, and every time we choose C++ over Rust we throw

Re: More Rust code

On 18.07.2017 06:01, Jim Blandy wrote: > BTW, speaking of training: Jason's and my book, "Programming Rust" will be > available on paper from O'Reilly on August 29th! Steve Klabnik's book with > No Starch Press is coming out soon as well, but I don't know the details > there. > Steve's book is

Re: More Rust code

BTW, speaking of training: Jason's and my book, "Programming Rust" will be available on paper from O'Reilly on August 29th! Steve Klabnik's book with No Starch Press is coming out soon as well, but I don't know the details there. On Mon, Jul 17, 2017 at 12:43 PM, Ted Mielczarek

Re: More Rust code

Nick, Thanks for kicking off this discussion! I felt like a broken record talking to people about this in SF. From my perspective Rust is our single-biggest competitive advantage for shipping Firefox, and every time we choose C++ over Rust we throw that away. We know the costs of shipping

Re: More Rust code

On Wed, Jul 12, 2017, at 07:41 PM, Mike Hommey wrote: > On Wed, Jul 12, 2017 at 04:06:39PM -0700, Eric Rahm wrote: > > Interesting points. > > > >- *using breakpad* - was the problem that creating wrappers to access > >the c/c++ code was too tedious? Could bindgen help with that, if not

Re: More Rust code

On 13/07/2017 01:06, Eric Rahm wrote: > * *using breakpad* - was the problem that creating wrappers to access > the c/c++ code was too tedious? Could bindgen help with that, if not > it would be interesting gather some details about why it wouldn't > work and file bugs against it.

Re: More Rust code

On Tue, Jul 11, 2017 at 11:03 AM, Nicholas Nethercote < n.netherc...@gmail.com> wrote: > > >> The first thing comes to my mind is crash reports. It currently doesn't >> always include useful panic message from Rust, see for example [1] and [2]. >> > > I filed

Re: More Rust code

On Wed, Jul 12, 2017 at 04:06:39PM -0700, Eric Rahm wrote: > Interesting points. > >- *using breakpad* - was the problem that creating wrappers to access >the c/c++ code was too tedious? Could bindgen help with that, if not it >would be interesting gather some details about why it

Re: More Rust code

[moving dev-platform and firefox-dev to Bcc] What I've heard in this thread is that we have a few blockers, some pain points and bugs to file regarding more Rust integration with Firefox. Nick -- please ensure those bugs get filed, and a meta-bug entitled "Make the developer experience for

Re: More Rust code

On 10.07.2017 12:29, Nicholas Nethercote wrote: Hi folks, Firefox now has multiple Rust components, and it's on track to get a bunch more. See https://wiki.mozilla.org/Oxidation for details. I wonder which of the pressing problems (eg. massing resource wasting, bad performance, horribly

Re: More Rust code

So, I've been kinda working toward the "more rust in gecko" goal, in my own space that just happened to be a good sandbox for it. Last year I was brought over to help on WebAuthn, which needs access to USB HID for things like Yubikeys. I decided to write the lowest level cross platform parts of

Re: More Rust code

Interesting points. - *using breakpad* - was the problem that creating wrappers to access the c/c++ code was too tedious? Could bindgen help with that, if not it would be interesting gather some details about why it wouldn't work and file bugs against it. - *pingsender* - was

Re: More Rust code

On 10/07/2017 12:29, Nicholas Nethercote wrote: > Hi, > What are the obstacles? Here are some that I've heard. > [...] > Anything else? In the past year I wrote two tools (minidump-analyzer and pingsender) that ship with Firefox but are separate executables so both were good candidates for being

Re: More Rust code

On Wed, Jul 12, 2017 at 08:05:05AM +0900, Brian Birtles wrote: > On Tue, Jul 11, 2017 at 11:34 PM, Jim Mathies wrote: > > > What's the debugging situation look like for Windows developers? I've heard > > it's pretty painful. Can we step through rust code using common tools

Re: More Rust code

On Tue, Jul 11, 2017 at 11:34 PM, Jim Mathies wrote: > What's the debugging situation look like for Windows developers? I've heard > it's pretty painful. Can we step through rust code using common tools > (WinDBG/Visual Studio)? > You can set breakpoints and step through

Re: More Rust code

On 07/11/2017 03:46 PM, Nicolas B. Pierron wrote: (Answering privately until I get more manager intent to get this project as part of any long term roadmap) Or not so privately after all … :( -- Nicolas B. Pierron ___ dev-platform mailing list

RE: More Rust code

] On Behalf Of Nicholas Nethercote Sent: Monday, July 10, 2017 5:30 AM To: dev-platform <dev-platform@lists.mozilla.org>; firefox-dev <firefox-...@mozilla.org> Subject: More Rust code Hi, Firefox now has multiple Rust components, and it's on track to get a bunch more. See https://wiki.mozilla.o

Re: More Rust code

On 07/11/2017 04:27 PM, Ben Kelly wrote: On Tue, Jul 11, 2017 at 4:57 AM, Nicholas Nethercote wrote: If I were the owner of that module I would consider implementing a policy something

Re: More Rust code

I'm currently trying to improve the C++ <-> Rust FFI story a bit. I just posted a draft proposal to add a mode to rustc that has it output the ABI details of all public types: https://internals.rust-lang.org/t/stabilizing-a-machine-readable-zprint-type-sizes/5525 This would theoretically reduce

Re: More Rust code

On 07/10/2017 01:29 PM, Nicholas Nethercote wrote: Hi, Firefox now has multiple Rust components, and it's on track to get a bunch more. See https://wiki.mozilla.org/Oxidation for details. I think this is an excellent trend, and I've been thinking about how to accelerate it. Here's a

Re: More Rust code

On Tue, Jul 11, 2017 at 4:57 AM, Nicholas Nethercote wrote: > On Tue, Jul 11, 2017 at 11:15 AM, Bobby Holley > wrote: > > > If I were the owner of that module I would consider implementing a policy > >> something like the following: > >> > >>

Re: More Rust code

On 7/10/17 5:29 AM, Nicholas Nethercote wrote: - Interop with existing components can be difficult. IPDL codegen rust bindings could be a big help. Rust's C++ interop story is absolutely atrocious. The FFI basically runs on C ABI, even though Rust and C++ have some similar concepts that could

Re: More Rust code

On Mon, Jul 10, 2017 at 7:51 PM, Kris Maglione wrote: > Combined with the fact that I would have needed to find and dig through > various scattered mailing list posts and wiki pages, and then pester a > bunch of people by email or IRC just to get started, I've always given

Re: More Rust code

On Tue, Jul 11, 2017 at 11:15 AM, Bobby Holley wrote: > If I were the owner of that module I would consider implementing a policy >> something like the following: >> >> "When a person writes a new compiled-code component, or majorly rewrites >> an existing one, they should

Re: More Rust code

On Tue, Jul 11, 2017 at 3:04 AM, Chris Peterson wrote: > On 7/10/17 4:48 PM, Xidorn Quan wrote: > >> The first thing comes to my mind is crash reports. It currently doesn't >> always include useful panic message from Rust, see for example [1] and [2]. >> Also for Stylo, we

Re: More Rust code

On Mon, Jul 10, 2017 at 5:39 PM, Nicholas Nethercote wrote: > On Tue, Jul 11, 2017 at 2:33 AM, Bobby Holley > wrote: > >> >> In other words, I think we should encourage people to consider Rust for >> new code, but also make sure that we have a

Re: More Rust code

On 7/10/17 4:48 PM, Xidorn Quan wrote: The first thing comes to my mind is crash reports. It currently doesn't always include useful panic message from Rust, see for example [1] and [2]. Also for Stylo, we generate lots of code (including using bindgen and mako template system, bindgen is

Re: More Rust code

see if that makes things better. It would > also be good to see if Rust developers have any advice for this situation. > Would you mind filing a bug report for this issue? I've posted a link to this thread on the Rust Internals board: https://interna

Re: More Rust code

On Tue, Jul 11, 2017 at 2:33 AM, Bobby Holley wrote: > > In other words, I think we should encourage people to consider Rust for > new code, but also make sure that we have a thoughtful and informed > discussion about whether a use-case makes sense and how best to support

Re: More Rust code

On Mon, Jul 10, 2017 at 11:41 PM, smaug wrote: > > - Interop with existing components can be difficult. IPDL codegen rust >> bindings could be a big help. >> > > ipdl? or do you mean idl? or perhaps webidl? > bkelly suggested that item to me on Twitter :) Probably all three of

Re: More Rust code

On Mon, Jul 10, 2017, at 08:29 PM, Nicholas Nethercote wrote: > Firefox now has multiple Rust components, and it's on track to get a bunch > more. See https://wiki.mozilla.org/Oxidation for details.> > I think this is an excellent trend, and I've been thinking about how to > accelerate it.

Re: More Rust code

On 07/10/2017 09:04 PM, zbranie...@mozilla.com wrote: One more thought. There's a project that fitzgen told me about that aims to allow for components to communicate between JS and Rust using Streams. If we could get to the point where instead of WebIDL/XPIDL we could just plug streams

Re: More Rust code

One more thought. There's a project that fitzgen told me about that aims to allow for components to communicate between JS and Rust using Streams. If we could get to the point where instead of WebIDL/XPIDL we could just plug streams between JS/CPP and Rust in Gecko, I believe the scope of Gecko

Re: More Rust code

On Mon, Jul 10, 2017 at 08:29:59PM +1000, Nicholas Nethercote wrote: I think this is an excellent trend, and I've been thinking about how to accelerate it... - Interop with existing components can be difficult. IPDL codegen rust bindings could be a big help. So far, this has been my biggest

Re: More Rust code

There are obvious benefits to writing new things in Rust. In general, the main barrier to doing so is the extent to which they may interact with existing C++ code, and the adequacy of our tooling for managing that interaction. In London last year, we had a meeting to discuss how we wanted to use

Re: More Rust code

Hi, This year I've been working on three new components[0] and I considered Rust for both. At the time, when asked people on #rust and #developers, the answer was that oxidation targets should have very simple APIs, because getting anything more complex than strings/ints between rust and cpp/js

Re: More Rust code

I am organizing a second rust training in Paris in September or October (amongst others) The registration has been sent to the French staff last week. Will be shared with the European staff at the end of the week. Le lun. 10 juil. 2017 à 12:30, Nicholas Nethercote a

Re: More Rust code

On Mon, Jul 10, 2017 at 9:41 AM, smaug wrote: > ipdl? or do you mean idl? or perhaps webidl? > Also, xpconnect doesn't deal with rust, and our chrome code still heavily > relies on idl+xpconnect. > I have written https://bugzilla.mozilla.org/show_bug.cgi?id=1293362, which

Re: More Rust code

On 10.07.2017 12:29, Nicholas Nethercote wrote: > > What are the obstacles? Here are some that I've heard. > > - Lack of Rust expertise for both writing and reviewing code. We have some > pockets of expertise, but these need to be expanded greatly. I've heard > that there has been some Rust

More Rust code

Hi, Firefox now has multiple Rust components, and it's on track to get a bunch more. See https://wiki.mozilla.org/Oxidation for details. I think this is an excellent trend, and I've been thinking about how to accelerate it. Here's a provocative goal worth considering: "when writing a new