p4lindromica

Hi, Artichoke author here. I feel very blessed to have Artichoke be mentioned in this ticket on Ruby's bug tracker. If y'all are interested to follow along, @artichokeruby on Twitter is the best spot to do it.

https://twitter.com/artichokeruby

The compiler does have a lint to force being explicit about unsafe in the way you describe. It is an allow by default lint called `unsafe_op_in_unsafe_fn`.

Whimsical - https://whimsical.com/

For now Artichoke leans on mruby’s parser, but I’m looking forward to using https://github.com/lib-ruby-parser/lib-ruby-parser which is a Rust port of MRI’s parse.y.

Code size in an embedded context is one use case for the modularity here. Another is limiting access of Ruby code to the host system.

For example, one may wish to use Artichoke in a game engine for scene scripting. It’s probably undesirable for Ruby code run in this context to modify the host environment, so `ENV` can be disabled at compile time. But maybe you have existing code that uses `ENV`. Toggle a compile time flag and you can get a compatible `ENV` implementation that is backed by a hash map.

Here's a permalink: https://github.com/artichoke/artichoke/blob/939fffc015255736...

You might be interested in this early work to build a Sinatra echo server [0] with Artichoke (called ferrocarril back then). `hubris` used a custom Rack-compatible web server called `nemesis` [1] based on Rocket [2], a Rust Flask-like web framework.

[0]: https://github.com/artichoke/artichoke/tree/97ba69d31154be45...

[1]: https://github.com/artichoke/artichoke/tree/97ba69d31154be45...

[2]: https://rocket.rs/

Fixed [0]. Thanks for the report. The navbar could still use a bit of love though :(.

[0]: https://github.com/artichoke/www.artichokeruby.org/pull/171

You might want to check out https://github.com/artichoke/artichoke/blob/2d67d8537c1340f1... which lays out the goals for the project.

Hi folks, Artichoke author here. I mostly post project updates on Twitter. Here's a selection of some cool things I've been working on recently:

- https://twitter.com/artichokeruby/status/1339581223119679493

- https://twitter.com/artichokeruby/status/1339578582222266368

- https://twitter.com/artichokeruby/status/1332772105126105089

- https://twitter.com/artichokeruby/status/1332880679655247872

Thanks for catching this. That is spot on. These APIs in the `Symbol` backend [0] show this concept off really well I think.

The `Symbol` data structure knows how to, e.g. render its `Symbol#inspect` implementation [1]. To extract the underlying bytes associated with the `Symbol`, however, it needs an interpreter. But not a whole interpreter or any particular interpreter, just one that implements `Intern` [2].

All of these generics get monomorphized so there are no vtables or other indirection. Because it's unlikely you'll have more than one interpreter implementation in your program, there is no code bloat either.

[0]: https://github.com/artichoke/artichoke/blob/2d67d8537c1340f1...

[1]: https://artichoke.github.io/artichoke/spinoso_symbol/struct....

[2]: https://artichoke.github.io/artichoke/artichoke_core/intern/...

Even this regexp has false positives.

The `ai` ccTLD ran their own mail server at the root, so an address like `a@ai` was a valid email address.

They serve a website at the tld root: http://ai./

`mem::transmute` is roughly equivalent to a `reinterpret_cast` in C++. It treats the bits of a u8 as an i8.

In the Rust definition of safety (mutable xor shared, no data races, memory safety, etc), treating the bits of a u8 as an i8 is safe and can be done with an `as` cast.

in the 14 hours since I wrote the comment you replied to, I moved an MRI C API from non-goal to goal [0]. :) The red X means the goal is not yet achieved.

[0] https://github.com/artichoke/artichoke/pull/108

Not yet, but you can track progress here: https://github.com/artichoke/artichoke/issues/105

For an example of how Artichoke can be faster than MRI, I'm currently working on extending the oniguruma-based `Regexp` implementation to have a fast-path backed by the Rust regex crate in some circumstances. In testing this can speed up `String#scan` by a factor of 10 for some `Regexp`s

Thank you for your kind words.

Growing pains of blowing up on HN lol, I do not have this written down yet, but I have a ticket to start documenting this [0].

The idea is to have a core set of traits [1] that when implemented allow an implementation to load an interpreter agnostic Ruby core and Ruby Standard Library.

There is currently only one interpreter that implements these traits, and it is backed by mruby. My ultimate goal is to move off of mruby to either an MRI-backed interpeter via rutie or a native Rust-implemented backend + VM + parser.

[0] https://github.com/artichoke/artichoke/issues/102 [1] https://artichoke.github.io/artichoke/artichoke_core/

I can generate a set of pass rates during build and output it to the gh-pages branch. That's a good idea. Thank you.

https://github.com/artichoke/artichoke/issues/101

Hi eregon, I've submitted a fix to ruby/spec already! \o/ (I'm @lopopolo on GitHub.)

One spec I know is missing is how capture groups should not be expanded into globals on `String#=~`. I'll file an issue [0].

[0] https://github.com/ruby/spec/issues/676

I can run MSpec to completion for language, core, and library specs. Thank you for the encouragement :D.

I've implemented a runner that can skip known things that cause the spec to hang (e.g. Mutex specs since Artichoke has a single-threaded implementation of Mutex that deadlocks during the specs).

    $ pushd spec-runner/vendor/ruby/language
    $ cargo run --bin spec-runner **/*.rb
    Passed 1078, skipped 35, not implemented 2, failed 476 specs.
    $ popd; pushd spec-runner/vendor/ruby/core
    $ cargo run --bin spec-runner **/*.rb
    Passed 5412, skipped 998, not implemented 201, failed 8629 specs.
    $ popd; pushd spec-runner/vendor/ruby/library
    $ cargo run --bin spec-runner **/*.rb
    Passed 0, skipped 22, not implemented 16, failed 3276 specs.

The library specs pass number is a bug in my spec runner. All packages added to Artichoke pass ruby/spec. Those packages are : delegate, forwardable, json, monitor, ostruct, set, srscan, and uri.

Hi I'm the author of Artichoke.

Thanks for your interest in the project. You can track progress on this issue on GitHub [0]. Would love your help on this if you could lend it. :)

[0] https://github.com/artichoke/artichoke/issues/99

Hi, I'm the author of Artichoke.

My expectation is that MRB_API can be implemented in a thread-safe way. The API manipulates the interpreter state (in the case of mruby, an `mrb_state`). The interpreter state itself and the implementation of the API can be thread safe or they can not be.

I don't think mruby even assumes the presence of threads on target systems, so it is completely reasonable that the implementation is not thread safe.

Hi, I'm the author of Artichoke.

I wouldn't say all gems are unusable. I implemented a Rack-compatible application server in an early version of Artichoke that is capable of serving a Sinatra Rack app.

https://github.com/artichoke/ferrocarril

Hi, I'm the author of Artichoke. I don't have a good answer for whether or not implementing the MRI API would be difficult. I _suspected_ it would be, which is why I listed it as a non-goal. There is a lot of other work to do before we get to the point of C API compatibility.

However, it may be possible to use `rubysys` in rutie as a base for an MRI compatible API: https://github.com/artichoke/artichoke/issues/88

This was good motivation. I've been editing a book that I've been working on for over a year. I submitted it to a literary agent just now. It took less than an hour. I'll probably fail. But I'm living in the now.

I also made the website first ;) - https://www.burnfastburnbright.com/

A pocket veto is when the President vetos a bill by not signing it and letting it expire.

Thank you for sharing your knowledge with me Arnavion. I've applied what I've learned here: https://github.com/lopopolo/punchtop/pull/1

:)

Thank you for the suggestions and code review via blog post ;)

You are correct that `#[deny]` is what I want with Clippy.

The env_logger builder is something I didn't know about. The homepage for the docs does not even mention it - https://docs.rs/env_logger/0.6.0/env_logger/. I agree that I should depend on my own env variable, but should cargo not do the same?

In ruby, this is most easily achieved with:

    result = input.each_cons(3).map do |left, _, right|
        left + right
    end

This maps over consecutive three-tuples in `input` and returns empty array for `len(input) < 3`.

Edit: nevermind, boundary conditions are still special cases.

I created a collection of terraform modules that gets a minimal AWS network set up for a single-region webapp: https://github.com/lopopolo/hyperbola/tree/master/terraform/...