Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Benjamin Reynolds
    @benreyn
    Actually, I may have just figured that out
    cannero
    @cannero
    @agraven, @shaleh, thank you for the info, maybe I can try to do something there. My idea is to get first the build to compile on windows on my local branch and then to open PRs for single changes. To just get the build to compile I would for example add 'dummy' functions where a function was ported for linux but not for windows (this is just one case I had where dired_unix.rs was updated but not dired_windows.rs). The changes to get the build to compile should not land on the master. What do you think of this approach?
    Sean Perry
    @shaleh
    @cannero how about a slight modification.
    You do what you describe locally and then open Issues for each function that needed changing. Count Makefiles as one "function" unless the issues are clearly spread over multiple things. Then you or someone else can take issues, open PRs to resolve them, and eventually we have a Windows build.
    cannero
    @cannero
    @shaleh yes, that sounds perfect :thumbsup:
    Benjamin Reynolds
    @benreyn

    @shaleh, what is still needed to get remacs/remacs#1536 in? I think you were saying that the build failures are unrelated there but that they should be separate PRs. Is it just a change to the Travis config that needs to be made?

    PS - If im taking up to much of your time please tell me. I have investment time this week at work so Ive been taking the long overdue plunge into Remacs.

    Sean Perry
    @shaleh
    No worries, sorry I have been all over. I work in EdTech and it is back 2 school season. So we are swamped.
    cannero
    @cannero

    Hi, did you ever experience problems that types starting with Q are blacklisted in the bindgen run and are not exported to the bindings.rs?
    There is for example one windows header, where a struct name starts with a Q and is referenced by another struct. It looks similar to:

      typedef struct _QOS_OBJECT_HDR {
        int ObjectType;
      } QOS_OBJECT_HDR;
    
      typedef struct _QOS_SD_MODE {
        QOS_OBJECT_HDR ObjectHdr;
      };

    It is not called directly by the rust code. I thought of blacklisting all those structs.

    Sean Perry
    @shaleh
    I am away from a computer. If someone else can look fabulous. If not might be a day
    Sean Perry
    @shaleh
    Back to school is almost over. I am 50 hours in this week already
    Amanda Graven
    @agraven
    This might be relevant when we become rust hosted http://blog.llvm.org/2019/09/closing-gap-cross-language-lto-between.html
    Sean Perry
    @shaleh
    @agraven at the end the example they show is of a C host program with a Rust library. Meaning in theory this could work for us now. But the compiler versions sound like a bit of fun to get right.
    Maximiliano
    @A6GibKm
    Hi
    Maximiliano
    @A6GibKm

    I am trying to port char-width

    #[lisp_fn(name = "char-width", c_name = "char_width")]
    pub fn char_width_lisp(ch: LispObject) -> usize {
        ch.is_character();
        let c: EmacsInt = ch.to_C();
        let width: usize = unsafe { char_width(c, buffer_display_table()) };
        width
    }

    and I get

    /usr/bin/ld: .././rust_src/target/release/libremacs.a(remacs-359f1bbc87c6b86a.remacs.cx1t0m7x-cgu.4.rcgu.o): in function `Fself_insert_command':
    remacs.cx1t0m7x-cgu.4:(.text.Fself_insert_command+0x26a): undefined reference to `char_width'
    /usr/bin/ld: .././rust_src/target/release/libremacs.a(remacs-359f1bbc87c6b86a.remacs.cx1t0m7x-cgu.8.rcgu.o): in function `Fchar_width':
    remacs.cx1t0m7x-cgu.8:(.text.Fchar_width+0x12): undefined reference to `char_width'
    /usr/bin/ld: .././rust_src/target/release/libremacs.a(remacs-359f1bbc87c6b86a.remacs.cx1t0m7x-cgu.8.rcgu.o): in function `remacs::character::char_width_lisp':
    remacs.cx1t0m7x-cgu.8:(.text._ZN6remacs9character15char_width_lisp17h5f4bc83323ea8cbbE+0x13): undefined reference to `char_width'
    collect2: error: ld returned 1 exit status
    when building, btw the function char_width was not in remacs_sys
    Sean Perry
    @shaleh
    That lu
    That likely means char_width is not in a header and was local to the C file. Add an entry for it to its header and recompile.
    Maximiliano
    @A6GibKm
    I am sorry, I am between learning C and improving my Rust, do you mean that I have to add its signature static ptrdiff_t char_width (int c, struct Lisp_Char_Table *dp); to the the beginning of character.c?
    Maximiliano
    @A6GibKm
    Just had to add it to character.h
    Amanda Graven
    @agraven
    Yes, exactly. And as I assume you figured out, it's important to remove the static keyword, as keeping it means the function won't be exposed to rust
    Mikhail Krainik
    @mikhail-krainik
    Hey, is there some activity?
    Sean Perry
    @shaleh
    It has been quiet lately Mikhail. I had to take the summer and now part of fall off from all open source work due to work and family obligations.
    I have been slowly working on starting over with the top of tree emacs. But not able to spend time at the moment.
    SolarAquarion
    @SolarAquarion
    something is going on with the rust toolchain

    info: syncing channel updates for 'nightly-2019-07-18-x86_64-unknown-linux-gnu'

    nightly-2019-07-18-x86_64-unknown-linux-gnu unchanged - rustc 1.38.0-nightly (bc2e84ca0 2019-07-17)

    Checking Rust toolchain install ...
    error: no default toolchain configured
    error: no default toolchain configured
    error: no default toolchain configured
    Remacs currently requires Rust toolchain version nightly-2019-07-18.

    Sean Perry
    @shaleh
    Try using a more current one and open a PR for any needed changes. Often the new rustfmt shifts things.
    Denis Grebennicov
    @denis631

    TL;DR. check out my PR: remacs/remacs#1550

    Hey guys. I decided to work on a low-hanging fruit #1418, but it appears not so easy as it seems.
    The problem is the C function which is to be ported is accessing a static var from C, which afaik is not accessible in Rust, since it's sort of a fileprivate var.
    I migrated the var to Rust and added getter/setter to Rust and call it from C.
    If this is a right approach I can continue working on migrating the func.

    Is it the right approach?

    Or do you propose just to remove the static declaration from the C file
    Sean Perry
    @shaleh
    Denis, I replied to one of the PRs about this subject yesterday. I believe you had commented too. Let me know if you need more ideas after reading.
    Denis Grebennicov
    @denis631

    @shaleh thanks for the fast response. I have two questions though.

    1. how does one run the tests written in elisp? make test?
    2. the remacs build seems to be broken on the mac.

    When I am running the current build, no text rendering is not performed and the window/frame is not displaying any text. Is it expected?

    A picture says more than a thousand words so here it is: https://imgur.com/a/eCsCUZm

    Sean Perry
    @shaleh
    We are hearing reports of failure on newer Macs. I need older MacOS for other applications so I have not updated yet.
    Move into the test directory and run make from therr
    You can also make a specific test, touch it, and run it again.
    Denis Grebennicov
    @denis631
    Thank Sean. I updated my PR #1550, the builds are passing
    I will see If I can add some tests to it
    Denis Grebennicov
    @denis631
    Sean could you review my updates #1550
    Denis Grebennicov
    @denis631
    @shaleh can anybody review my pr? :pray:
    Sean Perry
    @shaleh
    The PR looks reasonable to me. I agree, a comment documenting the oddness of LispFrameRef and Option makes sense.
    Daniel Brooks
    @db48x
    I've been trying out Pernosco on Remacs (https://pernos.co/)
    I recreated an interesting bug that I once introduced, so that I can see how the debugger works
    Denis Grebennicov
    @denis631
    @shaleh was busy the last week, so didn't manage to add some small comments.
    Did this now. A new commit is made. Could you review it one more time?
    Sean Perry
    @shaleh
    Daniel that is weird. And fascinating. Cloud scares ne.
    We are heading to a day where people own what we hack on.
    Stallman was right but 3 generations early.
    Daniel Brooks
    @db48x
    yep
    I think the future needs to be a hybrid of what is currently available. I'd want to be able to buy Pernosco, and run it on my own AWS account (or my own hardware, if I have enough and I'm willing to sysadmin it)
    Daniel Brooks
    @db48x
    anyway, make sure you check out the notebook and the instructions executed views
    both are quite cool
    Eduardo M. Lopes
    @duca
    @db48x this is mindblowing indeed..
    Daniel Brooks
    @db48x
    @duca: I want to use it for everything now