Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add LispObarrayRef and port intern functions to Rust #267

Merged
merged 8 commits into from Aug 7, 2017

Conversation

@atheriel
Copy link
Contributor

@atheriel atheriel commented Jul 23, 2017

This PR ports a chunk of the obarray-related code from lread.c to Rust, including the lisp functions intern and intern-soft. I had to add some extern functions to the C code in order to get access to some global state.

@@ -942,3 +943,14 @@ impl Debug for LispObject {
Ok(())
}
}

/// Intern (e.g. create a symbol from) a string.
#[allow(dead_code)]
Copy link
Collaborator

@birkenfeld birkenfeld Jul 24, 2017

dead_code still needed?

Copy link
Contributor Author

@atheriel atheriel Jul 26, 2017

Nope. Fixed.

/// This is a wrapper around the C function `oblookup`. It is capable of
/// handling multibyte strings, unlike intern_1 and friends.
pub fn lookup(&self, name: LispObject) -> LispObject {
let string = if name.is_symbol() {
Copy link
Collaborator

@birkenfeld birkenfeld Jul 24, 2017

It's still better to use as_symbol which does the conversion already.

Anyway, this is basically LispObject::symbol_or_string_as_string.

Copy link
Contributor Author

@atheriel atheriel Jul 26, 2017

Fixed.

@@ -4009,6 +4009,20 @@ check_obarray (Lisp_Object obarray)
return obarray;
}

/* Like check_obarray, but for the global Vobarray. */
Copy link
Collaborator

@birkenfeld birkenfeld Jul 24, 2017

Is it not possible to access the V... from Rust?

Copy link
Contributor Author

@atheriel atheriel Jul 26, 2017

No, it's not exposed in any .h files. I got a linker error when I tried. Is there another way?

Copy link
Collaborator

@DavidDeSimone DavidDeSimone Jul 26, 2017

it looks like Vobarray is defined as #define Vobarray globals.f_Vobarray in globals.h. We set up the emacs globals as remacs_sys::globals, so it seems like if we need access to the V... variables in Rust, we can just use the global object (unless I am misunderstanding the situation).

Copy link
Contributor Author

@atheriel atheriel Jul 27, 2017

So... at first I thought this would work. But if I replace

let obarray = unsafe { check_vobarray() };

with

let obarray = unsafe { check_obarray(globals.f_Vobarray) };

The bootstrapping process fails on the first call to intern_1 in the C code, and Emacs will not build past the temacs stage, because globals.f_Vobarray is inexplicably nil at that point. This is a totally bizarre bug I haven't been able to track down. My best guess at the moment is that the globals object might have different contents for obarray during the bootstrap process and the regular Emacs incarnation.

Any thoughts on this would be appreciated.

Copy link
Collaborator

@Wilfred Wilfred Aug 2, 2017

Ouch, that's odd. Let's open an issue and fix that, but I don't think it should hold up this PR.

Copy link
Collaborator

@Wilfred Wilfred left a comment

I like your LispObarrayRef, looks good :)

Generally looks good to me, but I agree we should use globals.f_Vobarray. Other than that, I think this is good to go

Wilfred
Wilfred approved these changes Aug 2, 2017
Copy link
Collaborator

@Wilfred Wilfred left a comment

Sorry for the delay on this.

I think this is ready to merge. It would be nice to fix the globals.V_obarray issue, but that shouldn't delay this PR. It's nice clean Rust and makes it easier for us to build additional symbol functionality.

@atheriel
Copy link
Contributor Author

@atheriel atheriel commented Aug 2, 2017

@Wilfred I've actually been working on other major symbol table work that builds on this PR, and I fixed one of the globals issues in the process. Let me upstream that fix and rebase tonight, and then this first part can be merged.

atheriel added 4 commits Aug 2, 2017
In order to get access to the `obarray` lisp object, I've had to add
an extern function to the C sources: `check_vobarray`.

Signed-off-by: Aaron Jacobs <atheriel@gmail.com>
Signed-off-by: Aaron Jacobs <atheriel@gmail.com>
This commit adds an extern function to the C code in order to get
access to a previously un-exposed piece of global state: whether Emacs
has set the `purify-flag'.

Signed-off-by: Aaron Jacobs <atheriel@gmail.com>
Signed-off-by: Aaron Jacobs <atheriel@gmail.com>
Signed-off-by: Aaron Jacobs <atheriel@gmail.com>
@atheriel
Copy link
Contributor Author

@atheriel atheriel commented Aug 3, 2017

This should be good to go now.

Copy link
Collaborator

@birkenfeld birkenfeld left a comment

Just some minor comments.

@@ -122,6 +123,9 @@ pub use vectors::Fsort;
pub use lists::merge;
pub use buffers::Fget_buffer;
pub use buffers::Fcurrent_buffer;
pub use obarray::intern_1;
Copy link
Collaborator

@birkenfeld birkenfeld Aug 5, 2017

You're declaring intern_1 in remacs-sys but also exporting it here...

/// This is a wrapper around the C function `oblookup`. It is capable of
/// handling multibyte strings, unlike intern_1 and friends.
pub fn lookup(&self, name: LispObject) -> LispObject {
let string = LispObject::symbol_or_string_as_string(name);
Copy link
Collaborator

@birkenfeld birkenfeld Aug 5, 2017

Should use normal method call syntax here.

@birkenfeld
Copy link
Collaborator

@birkenfeld birkenfeld commented Aug 7, 2017

Resolved conflicts and my two suggestions.

@birkenfeld birkenfeld merged commit 11bfbcf into remacs:master Aug 7, 2017
1 check passed
@atheriel
Copy link
Contributor Author

@atheriel atheriel commented Aug 7, 2017

@birkenfeld Thanks for doing that, I wasn't able to get back to it this past weekend.

@atheriel atheriel deleted the obarray branch Aug 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants