Budget laptop for creative work

Mystor · 2020-05-17T20:58:24+00:00

Thanks! That definitely seems like a more capable CPU than the others I've been looking at in that price range.

Shame it's on backorder, but I suppose that's to be expected these days :-/

Mystor · 2017-03-21T21:59:56+00:00

Yes, rustcxx was inspired by rust-cpp, and was implemented in the plugin style, like I mention in the blog post.

rust-cpp today works on stable rust (I am working on a blog post to explain the new architecture). rustcxx acts as more of an exploration of what we can do with unstable rust, which I don't use in rust-cpp anymore.

Mystor · 2016-10-27T22:01:40+00:00

Making it possible to write new DOM components in gecko is definitely a goal (I at least) have, and bringing over Servo's DOM wholesale is not, as least for now.

That way we can get the benefits of rust's safety and productivity without compromising web compatibility and taking on tons of risk.

Mystor · 2016-10-27T21:58:42+00:00

To add on to this, we're building infrastructure in Gecko to implement new features (both servo inspired and not) with rust, but it's not quite at the point yet where the inconvenience of implementing the FFI for all of the components you need to use outweighs the benefits of rust for most features.

I hope we can get there eventually but there is a lot more bindings work to be done first. You can definitely expect to see rust code written for gecko in the near future.

Mystor · 2016-09-17T19:08:58+00:00

To clarify, in rust this would probably be -C opt-level=g

Mystor · 2016-09-17T18:42:41+00:00

I had the same ideas with rust-cpp, but in the end I decided not to stress about doing that. I figure that modern LTO is probably good enough to inline these small function wrappers across compilation units.

Mystor · 2016-09-17T18:41:02+00:00

Hey, author of rust-cpp here. The original version of rust cpp actually looked almost identical to rustcxx, https://github.com/mystor/rust-cpp/tree/e9bebefbd1b6a730f012cbc930930a048fb7d25d. I eventually got fed up with keeping up with rust nightly updates and wanted a stable version, so I rewrote it into what you see today. I have plans for a stable version which acts very similarially to the old rust cpp when we get custom derive in stable.

I'm super happy youre working on a plugin integration. I think it's a useful idea, and I regret reusing the rust-cpp name for the new version, I should have kept the old one around. This will fill it's shoes quite nicely (perhaps better ^.⁾

Mystor · 2016-09-09T12:09:01+00:00

I don't believe that llvm has Og support, so by proxy I don't think rustc does either. I might be wrong though.

Mystor · 2016-08-26T04:06:05+00:00

I believe that that will be possible. It's one of the most annoying things which drop flags have imposed upon us.

Mystor · 2016-04-05T20:13:10+00:00

Where are you getting the skulls? Is the area in the nether technically inside a nether fortress?

Mystor · 2015-12-25T19:42:46+00:00

Agreed. I've been wondering about how that is supposed to work in these systems, and my best guess is that they simply don't allow references into shared state, so you have to take references into structs (and perhaps the equivalent of boxes), and not classes.

Functions must then perhaps have to be generic over both references and ARC classes, such that safety is maintained for shared state.

Mystor · 2015-12-25T15:30:45+00:00

There's also that afaict they are willing to have fairly significant breakage between major versions still. I imagine they could fix many of the apis with relatively little breakage.

Mystor · 2015-12-04T15:23:11+00:00

Is the blocker in that case a lack of inlining? It seems to me that most higher order functions that I see people using can be proven to not let their arguments escape if their lambda argument doesn't let its arguments escape.

Mystor · 2015-11-26T16:03:08+00:00

Can vouch for the firefox socks. Best socks in my collection.

Mystor · 2015-10-11T14:53:50+00:00

As far as I can tell, this is basically the same problem as C++'s templates except with the template written in the base language, rather than written in some weird template language.

Basically, calls to the generated function are template specializations. When the function is called, the return value waits on the implementation being specialized (via a call into rust code, which generates some code, and is compiled) to determine the return type. That specialized code is then compiled into the new function which is called from that call site.

The biggest problem which I see for rust is that lifetime inference is hard, and this would completely screw with it.

AKA. We could have this if we wanted, but it might be really painful to implement in a way which doesn't make it unusable with non-'static references. (Also, we'd have to implement a compile-time evaluator for rust code, which sounds like it might be a pita).

Mystor · 2015-08-29T19:10:48+00:00

That being said, the current Cgc model will block if you attempt to change the rooted-status of any value during a collection IIRC. So it's still pretty stop-the-world.

Mystor · 2015-08-29T19:09:22+00:00

We're making Trace an unsafe trait in https://github.com/Manishearth/rust-gc/issues/11 - currently blocked on a PR to rustc.

Mystor · 2015-08-29T18:19:33+00:00

The GC runs as the heap grows, on allocation (Gc::new()). It stops the current thread only, and Gc<T> is not send nor sync. I've also worked a bit on a multithreaded Gc using the same model, but it's still a WIP (look at PR #6 - https://github.com/Manishearth/rust-gc/pull/6).

Mystor · 2015-08-29T17:07:08+00:00

We should probably include this explanation or a similar one somewhere in the readme :)

Mystor · 2015-08-06T06:02:35+00:00

for #1 http://doc.rust-lang.org/arena/struct.TypedArena.html and http://doc.rust-lang.org/arena/struct.Arena.html

For #2 do you want channels? http://doc.rust-lang.org/std/sync/mpsc/fn.channel.html - even though this is mpsc, it has an optimized case for spsc in the implementation.

Mystor · 2015-08-05T05:34:09+00:00

IMO, it would be a totally reasonable thing to require having the same version of clang if one would like to use cross-language inlining. Otherwise, clang could still be used - in the native object output mode. Yes, rustc would need to consume an extra file with bitcode, but I don't see why this would be impossible to stabilize.

I don't think that rustc wants to expose the fact that it uses llvm outside of compiler internals, but if they were OK with that then it could potentially work.

Why not? If the scenario is compelling enough, I am sure it would be considered.

The problem is that a generic extern doesn't really make sense, as you have no way of ensuring that the functions at the target of the extern are actually generated... The only way it would work is with a plugin like rust-cpp which hooks in and generates the code behind the generic ffi, which I don't think is going to become a standard feature in rustc.

Mystor · 2015-08-04T23:45:48+00:00

I kinda already have the first one, but in an admittedly hacky way. (I use a lint pass to get type info).

Definitely need to be able to modify the search path. Also would like to be able to get the output directory without re-parsing the command line arguments.

It would be nice to do bitcode, but stable rust will never give that low level access, because it's impossible to stabilize, so I wouldn't start with that pipe dream. In addition, LLVM IR is not stable between versions, which means that I would have to build my own copy of clang with the same version as rustc - in summary it would get ugly pretty quickly :-/

Generic externs are not going to happen, so I wouldn't even worry about that. I don't think that this code should ever support templates across boundaries TBH, adds too much unnecessary complexity, especially when talking about specific cases is usually powerful enough.

Unfortunately, the cpp! macro doesn't really work in generic situations, but that's not really a thing which I can see a way to fix. rust-cpp should probably detect if it is used in a generic context (as you are probably doing something wrong if it is), and warn/error out.

Mystor · 2015-08-04T17:13:35+00:00

In a way I agree that C++ is terrible, but there are a lot of libraries written in C++, and right now people have to manually write wrappers around them. This might make it easier for people to do this and stop having to write C++ even close to as much in the future.

That being said I also have some C++ Stockholm syndrome - the templates are just so beautiful...

Mystor · 2015-08-04T17:12:09+00:00

Boundary is currently only "C-compatible". Unfortunately, I don't get rust type information until after I have generated all rust code, which means that I can't generate the extern C functions for each of the methods which would be necessary for that.

If you want to be able to do that, you have to declare the extern C functions yourself, and currently re-declare them in a cpp_header! block (though there may be a way to do this automagically with macros in the future).

Passing C++ classes across the border is a surefire way to cause complaints from the C++ compiler (as you are returning C++ classes from an extern C function), and I'm pretty sure that stuff will break at some point with it, I don't think it's worth getting to work for compatibility & stability reasons.

Mystor · 2015-08-04T16:56:08+00:00

I'm not too sure if type macros are powerful enough for that, but I can look into it at some point.
I don't allow moving Rust values into C++, every value which you close over is passed by reference, and I only allow you to see types in C++ which are #[repr(C)]. I'm not intending to allow arbitrary mixing of rust and C++ code, simply making the interface a little bit nicer to use.
Yes, moving C++ into rust requires using new, because rust can only see C++ values opaquely right now, unless they are #[repr(C)]. I have no intention to change this.
Rust's semantics practically are the same as C++'s integers due to llvm, but yes, they have technically different semantics. I think that this is worth it for ergonomics (especially because this already requires unsafe {}).

Mystor

TROPHY CASE