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
Port bolp and eolp to rust #293
Conversation
I think the use of We don't have an API for accessing bytes in buffers yet. Looking at the relevant C macros: /* Return the byte at byte position N. */
#define FETCH_BYTE(n) *(BYTE_POS_ADDR ((n)))
#define BYTE_POS_ADDR(n) \
(((n) >= GPT_BYTE ? GAP_SIZE : 0) + (n) + BEG_ADDR - BEG_BYTE) This looks like it's doing pointer arithmetic of bytes before or after the gap. We should probably do the same thing. |
I think now it's in a mergeable state (if travis says 'green'). There was some trial and error in the castings (casting everything to u32, then to isize, and ended up using ptrdiff_t (I'd appreciate any feedback)). Also ported eolp. There's clearly some space for refactoring in both (they are basically (bobp() || .....) and (eobp() || ....) and we're not reusing them, but I'm not confident enough we want to create new internal functions with different signatures (bool instead of LispObject). |
mmm... It looks like it's a formatting issue. The thing is that if I run Any hints? (of course, it's my first time running cargo fmt) Thanks! |
You might have an old version of rustfmt. The default style changed quite a lot with 0.9.0. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few minor things...
rust_src/src/buffers.rs
Outdated
0 | ||
}; | ||
let byte_addr = (base_addr + n + | ||
self.beg_addr() as ptrdiff_t - self.beg_byte()) as *const u8; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like that should be self.beg_addr().offset(base_addr + n - self.beg_byte())
rust_src/src/editfns.rs
Outdated
#[lisp_fn] | ||
pub fn bolp() -> LispObject { | ||
let buffer_ref = ThreadState::current_buffer(); | ||
let pt_byte = buffer_ref.pt_byte - 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, calling pt_byte - 1
also pt_byte
is a bit confusing.
rust_src/src/editfns.rs
Outdated
let buffer_ref = ThreadState::current_buffer(); | ||
let pt_byte = buffer_ref.pt_byte - 1; | ||
LispObject::from_bool(buffer_ref.pt == buffer_ref.begv || | ||
buffer_ref.fetch_byte(pt_byte) as char == '\n') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
instead of as char
, compare with b'\n'
Thanks for the comments! I'll fix those asap. |
* Formatted according to rust fmt * Compare bytes using b''
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One tiny comment, but this is nice Rusty code :)
I'm not sure why the build has failed though. It looks like a timeout. It's annoying if so (it means our build is unreliable) but I don't see how these changes could relate.
rust_src/src/buffers.rs
Outdated
|
||
#[inline] | ||
pub fn fetch_byte(&self, n: ptrdiff_t) -> u8 { | ||
let base_addr = if n >= self.gpt_byte() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer we called this offset
-- it's not actually an address (0 wouldn't make sense as an address here).
pub fn eolp() -> LispObject { | ||
let buffer_ref = ThreadState::current_buffer(); | ||
LispObject::from_bool( | ||
buffer_ref.pt == buffer_ref.zv() || buffer_ref.fetch_byte(buffer_ref.pt_byte) == b'\n', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cargo fmt told me about that final comma, but.... does it make sense? I find it a bit strange, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, it's a little odd. Perhaps it's a rustfmt bug.
I like that rustfmt is a tool that you just run and it fixes formatting without human input. We could file a bug upstream, but I'd leave the comma for now if rustfmt wants it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's a big, it's just consistent in always having a final comma on multi-line lists of expressions. The argument for having the trailing comma in the first place, less churn when an element is added, applies to single arguments as well.
still timeouts :(. Next week I'm going to have some time to bisect over the commits, or try to investigate a bit more. It's a pity it doesn't happen in my local machine, just in travisCI :( |
@kidd have you tried running the test suite yourself? Does it terminate? I've been thinking that |
@Wilfred you're right, the infinite loop was caused by not returning eolp => t in certain situations. The bug was introduced during the latest refactors and went under the radar. Hopefully now it's green. |
I believe all the issues mentioned have been resolved :)
Awesome :) |
With the PR as it is, I get
^^^^^^^^^^ expected u8, found char
, which makes sense because I'm comparing the address offset address with the char '\n' itself.I couldn't find the function that would get the char at a given addr (something with a signature like: buffer.char_at_addr(addr)). Do we have such function?
Also, is that use of unsafe, safe? :) or at least, sensible?