Oils 0.20.0 - Eggex, JSON, and Android
www.oilshell.org
  • lobsters__screwtape@crustaceanson.theshelf.topM
    1·
    16 days ago

    I was a little surprised to see the J8 string syntax for a literal byte was \yFF rather than \xFF. The FAQ mentions that’s because \xFF in JavaScript and Python is an abbreviation for \u00FF - that is, in a Unicode string (in Python, and which is the only kind of string in JavaScript) it represents a codepoint rather than a byte.

    But it seems like Oils already has a variety of string literals that support different escapes depending on their encoding (only u'' (UTF-8) strings support \u{10FFFF}, only JSON (UTF-16) strings support \uFFFF), so it seems reasonable that b'' strings could have \xFF as their special code unit literal that other kinds of string don’t support.

    score 3 · canonical

    • lobsters__andyc@crustaceanson.theshelf.topOPM
      1·
      16 days ago

      It’s subjective, but some of our design principles are “don’t silently change what code means / clobber existing syntax” and “local reasoning / readability”

      https://github.com/oilshell/oil/wiki/Language-Design-Principles

      Python and JS silently changed what \xff means (code point, not byte), without changing the syntax. IMO that was a huge mistake, but it’s done.

      Since two of our main influences are Python and JS, we don’t want to “clobber” their clobbering :-/ So we chose a different character.

      As for local reasoning, you can generally read YSH code without looking at the shebang line to see if it’s OSH or YSH. The syntaxes don’t clobber each other; they are locally readable.

      So the same thing applies with \yff. It’s annoying if you have to look at which type of quote it is to know what it means. (Also, many users confuse single and double quotes, which makes it worse)

      When you see \yff, there is no ambiguity – it means exactly one thing – a byte!

      It also helps a bit that the syntax for byte strings is b'foo \yff', with B and Y being the first 2 letters of “byte” :)

      FAQ for people who didn’t see it - https://www.oilshell.org/release/0.20.0/doc/j8-notation.html#why-are-byte-escapes-spelled-yff-and-not-xff-as-in-c

      score 1 · canonical

  • lobsters__andyc@crustaceanson.theshelf.topOPM
    1·
    16 days ago

    Any Fedora users here? I briefly mentioned this in the post, but I was able to get the same tarballs compiling pretty easily on Debian/Ubuntu and Alpine. Basically ./configure; make of zsh, and some MyPy deps via python3 -m pip.

    But, for some reason, I ran into multiple build errors on a Fedora image from sourcehut. I was kind of surprised by that, and also that I couldn’t figure out what the problem was :-/

    Compiling bash had this error

    /usr/homes/chet/src/bash/src/parse.y: In function ‘decode_prompt_string’:
/usr/homes/chet/src/bash/src/parse.y:5741:21: error: implicit declaration of function ‘count_all_jobs’ [-Wimplicit-function-declaration]

    This error with a MyPy dependency also happened on Fedora, but not Debian/Alpine (also resisted my attempts to patch it)

    https://github.com/python/typed_ast/issues/169

    The zsh error is related to ncurses, and I installed the ncurses-dev package from Fedora

    /usr/include/term.h:783:56: note: previous declaration of ‘boolcodes’ with type ‘const char * const[]’
  783 | extern NCURSES_EXPORT_VAR(NCURSES_CONST char * const ) boolcodes[];
      |                                                        ^~~~~~~~~
make[3]: *** [Makefile:232: termcap.o] Error 1

    http://travis-ci.oilshell.org/srht-jobs/1135480/dev-setup-fedora.wwz/_tmp/soil/logs/spec-bin.txt

    So I was surprised to get 3 different build errors on Fedora that didn’t happen on Debian/Ubuntu/Alpine, especially for bash and zsh which are extremely common. I was beginning to suspect that the sourcehut image has something weird about it, and this doesn’t happen on stock Fedora, but I didn’t have time to look into it more.

    The goal of this is to make it easy for people to change Oils on any distro, and not rely on containers! We need specific versions of our dependencies. The build deps are stabilizing so Nix should also work, though it will take some work to pin MyPy and its deps.

    score 2 · canonical

    • lobsters__edwintorok@crustaceanson.theshelf.topM
      1·
      16 days ago

      The build failure is in zsh-5.1.1, which is 9 years old. Your version of Fedora is likely newer than that with a newer GCC. I’d suggest updating the version of zsh to something newer, it might have fixed that build error already.

      score 1 · canonical

      • lobsters__andyc@crustaceanson.theshelf.topOPM
        1·
        16 days ago

        Yeah I suspected that and actually tried it

        https://github.com/oilshell/oil/blob/master/deps/source.medo/zsh/WEDGE#L23

          # Fedora has a conflict with zsh/Src/Modules/termcap.c and
  # /usr/include/term.h
  # Happens from zsh 5.1.1 all the way to zsh 5.9.
  # This doesn't happen on Debian/Ubuntu.

        I’m strongly suspecting something is weird about the sourcehut Fedora VM image, because there are not only compile errors in new zsh, but also new bash and MyPy typed_ast

        For now, it’s not urgent, but I guess I will wait until a Fedora user wants to contribute. Or until our Nix support is fixed up, so Fedora users can presumably use it

        score 1 · canonical