profile
viewpoint

lrs-lang/lib 205

An experimental standard library

mahkoh/comm 66

Communication primitives

mahkoh/dns2 5

Rudimentary DNS library

lrs-lang/build 4

The lrs build system

lrs-lang/driver 2

The lrs compiler driver

mahkoh/align 1

Align text

mahkoh/areasel 1

select area with mouse

mahkoh/cmus 1

Small, fast and powerful console music player for Unix-like operating systems.

issue commentfontforge/fontforge

Scripting constants changed in 1536d58fb5969c73644337053c8af2ffe3e0ae82

You are saying that 1536d58 inadvertently flipped omit-instructions and no-hints.

Yes

It made fm_flag_nopshints omit TTF instructions

Not quite. fm_flag_nopshints does what the name says. However, fm_flag_nopshints has the wrong numerical value 8 instead of 0x80000 and the python engine maps omit-instructions to fm_flag_nopshints instead of fm_flag_nottfhints. So the bug is a bit spread out.


Fundamentally this was an api break. But it happened in 2019-03 and at this point there might be fonts depending on the new behavior. For example if the DejaVu font is fixed in arch by applying my patch to the DejaVu package, then the package will break again if you make a release with the old behavior restored.

mahkoh

comment created time in 2 months

issue commentfontforge/fontforge

Scripting constants changed in 1536d58fb5969c73644337053c8af2ffe3e0ae82

Before the linked commit, using omit-instructions from python or the flag 0x8 from old-style scripts caused truetype instructions to be stripped. Now it no longer does. Are you saying this was intentional?

mahkoh

comment created time in 2 months

issue openedfontforge/fontforge

Scripting constants changed in 1536d58fb5969c73644337053c8af2ffe3e0ae82

In commit 1536d58fb5969c73644337053c8af2ffe3e0ae82 the value of the constant causing ttf_flag_nohints was changed from 0x8 to 0x80000. 0x8 now means ps_flag_nohints.

In the case of python scripting, omit-instructions continues to map to 0x8 (now ps_flag_nohints, previously ttf_flag_nohints).

This change in values broke the build of the DejaVu fonts which uses both the constants and the python names to strip the tt instructions. I believe that this is also in violation of the documentation:

no-hints

Do not include PS hints

omit-instructions

Do not include TrueType instructions

I've submitted a patch downstream to fix the build: https://bugs.archlinux.org/task/67500

But this patch is distro specific because some distros might ship fontforge versions from before 1536d58fb5969c73644337053c8af2ffe3e0ae82.

created time in 2 months

issue commentrust-lang/libc

musl: Change `time_t` definition on 32-bit targets according to "time64"

Isn't this broken either way as soon as C libraries are involved or am I missing something?

As documented in time64.html, C code compiled against >=1.2 assumes time_t = i64 whereas code compiled against <1.2 assumes time_t = i32 on 32 bit systems. If you use a C library that uses time_t in its interface (e.g. openssl), the time_t used by rust code must have the same size as in the musl headers.

JohnTitor

comment created time in 2 months

issue commentrust-lang/rust

Document FromRawFd unsafety

It's actually more ridiculous than that. The referenced issue https://github.com/rust-lang/rfcs/issues/1043 contains an elementary mistake:

fn main() {
    let f = File::create(...);
    let f2 = File::from_raw_fd(f.as_raw_fd());
    let m = MemoryMap::new(f).unwrap();
    drop(f2);
    // Use m and segfault...
}

Since mmap performs the equivalent of dup, there would not have been a segfault in the first place. Furthermore, the use of file-backed mmap can never be safe because the file (and thus the mapped memory) can be changed by other processed at will.

mahkoh

comment created time in 2 months

issue commentrust-lang/rust

Document FromRawFd unsafety

FromRawFd was made unsafe in 2705051e2067e8f467b4cb9bc75e801a5cd4f0e7. The justification was providing a safe version of mmap. Since nobody has been able to do this since, the justification seems to have been misguided.

mahkoh

comment created time in 2 months

issue commentrust-lang/rust

Document FromRawFd unsafety

dup2 can be used to replace the meaning of the integer stored in an object implementing FromRawFd without using FromRawFd directly. E.g. let file = File::open(), dup2(xyz, file.as_raw_fd()).

In any case, I maintain that there is no unsafety and that there never will be. The value of the standard unix functions dup2, fcntl, etc. being safe to use is much higher than the value of being able to do some obscure optimization based on sole ownership. If there even is such an optimization.

mahkoh

comment created time in 2 months

issue commentrust-lang/rust

Document FromRawFd unsafety

I don't think there is any UB here. The constructor is guarded with an assert. But it does split the issue in two parts:

  • UB for fds that are not uniquely owned by the object or manipulated via fcntl, dup2, etc.
  • UB for integers that were never valid file descriptors
mahkoh

comment created time in 2 months

pull request commentalacritty/alacritty

Set default FreeType properties

Works on my machine.

kchibisov

comment created time in 3 months

issue commentrust-lang/rust-clippy

Incorrect suggestion of `string_lit_as_bytes` lint

The lint should instead be removed. The only justification for the lint given is that using byte strings is shorter. &b"string literal"[..] is perl-tier.

ordovicia

comment created time in 3 months

push eventmahkoh/elang

Julian Orth

commit sha cbe33145891b5bf15e66effe73079cf1233af2bb

a

view details

push time in 3 months

push eventmahkoh/elang

Julian Orth

commit sha 50162180deddf27a9ff7661b06e7905de1a4083b

a

view details

Julian Orth

commit sha 6df42e72646ceda84b2863aa8d5c422393b805da

a

view details

push time in 3 months

issue openedintellij-rust/intellij-rust

Backslashes not shown in test output

I'm using CLion 2020.1.2 with IR 0.2.125.3191-201

Problem description

Title

Steps to reproduce

#[test]
fn t() {
    eprintln!("a\\\\b");
    eprintln!("a\\b");
    eprintln!("ab");
}

cargo test -- --nocapture output:

a\\b
a\b
ab

IR output:

a\b

ab

I believe this worked before so possibly caused by #5611

created time in 3 months

issue commentalacritty/alacritty

hintfull setting is not respected

@dnkl For some reason I was under the impression that alacritty didn't support bitmap fonts. Maybe this was a problem in the very early days of alacritty. In urxvt I'm using terminus.

mahkoh

comment created time in 3 months

issue commentalacritty/alacritty

hintfull setting is not respected

Funnily enough, the FT_Set_Default_Properties API was added to freetype in 2017 because I reported to the freetype developers that hinting was broken chromium: https://savannah.nongnu.org/bugs/?49187.

Like freetype-rs, chromium also uses FT_New_Library instead of FT_Init_Freetype (via skia.) After calling FT_New_Library, skia calls FT_Set_Default_Properties. Whether freetype-rs should call FT_Set_Default_Properties for you is unclear. But it should certainly expose the API.

mahkoh

comment created time in 3 months

issue commentalacritty/alacritty

hintfull setting is not respected

For full, it uses FT_LOAD_TARGET_DEFAULT, unless rgba has been enabled, in which case it uses one of the FT_LOAD_TARGET_LCD modes. This matches Alacritty, I think?

2020-07-03-185439_265x58_scrot

This is how urxvt renders the same font. It seems much closer to the patched alacritty version than the unpatched one.

mahkoh

comment created time in 3 months

issue commentalacritty/alacritty

hintfull setting is not respected

As for the sharpened variant seen in the images posted in #3534 (comment), the only way I get something like that anywhere is if I do export FREETYPE_PROPERTIES="truetype:interpreter-version=35"

That's in fact what I'm using.

I.e. use the legacy freetype interpreter (the default up to FreeType 2.6).

"legacy" seems a bit ambiguous. interpreter-version=35 is a fully supported setting of freetype.

mahkoh

comment created time in 3 months

issue commentalacritty/alacritty

hintfull setting is not respected

The previous patch is certainly not sufficient. It still has the desired effect on my laptop but does nothing on my desktop. Probably because I'm setting rgba to none on my desktop.

I'm now using the following patch:

diff --git a/font/src/ft/mod.rs b/font/src/ft/mod.rs
index d393b63..f7a1a58 100644
--- a/font/src/ft/mod.rs
+++ b/font/src/ft/mod.rs
@@ -491,6 +491,7 @@ impl FreeTypeRasterizer {
             (true, _, fc::Rgba::Unknown) => LoadFlag::TARGET_NORMAL,
             (true, _, fc::Rgba::None) => LoadFlag::TARGET_NORMAL,
         };
+        flags = LoadFlag::TARGET_MONO;

         // Non scalable fonts only have bitmaps, so disabling them entirely is likely not a
         // desirable thing. Colored fonts aren't scalable, but also only have bitmaps.

With patch:

2020-07-01-230001_310x66_scrot

Without patch:

2020-07-01-230032_310x66_scrot

mahkoh

comment created time in 3 months

push eventmahkoh/elang

Julian Orth

commit sha 9cbc68291651c85afe07e402ad1ea1586d2d6a7c

a

view details

push time in 3 months

push eventmahkoh/elang

Julian Orth

commit sha 483bbc16d3eb641fdb854871004985478e678271

a

view details

push time in 3 months

push eventmahkoh/elang

Julian Orth

commit sha ad3bfb6006d4fb6a18fb96145efc5455ebc69f9b

a

view details

push time in 3 months

push eventmahkoh/elang

Julian Orth

commit sha 9fbfcac830b42a45482d5fa43c92d629dd737593

a

view details

push time in 3 months

push eventmahkoh/elang

Julian Orth

commit sha 70674b9b1fbc53089aa5e4533095c620cb3851d7

a

view details

push time in 3 months

push eventmahkoh/elang

Julian Orth

commit sha 97cf30dd831c13ac71a2dae39d79aea74b2d22da

a

view details

push time in 3 months

push eventmahkoh/elang

Julian Orth

commit sha db72477396794f839854d32b24c3c276cd312cfc

a

view details

push time in 3 months

push eventmahkoh/elang

Julian Orth

commit sha 82c481ab9c8b1e04965406fbb061368a763e7022

a

view details

push time in 3 months

push eventmahkoh/elang

Julian Orth

commit sha d68e6d6ad0e5f6e18b831c42923f8a4874bcb5bc

a

view details

push time in 3 months

push eventmahkoh/elang

Julian Orth

commit sha 91b69d3989c4ff10d600dbbd61711c37ba2f3a5c

a

view details

push time in 3 months

push eventmahkoh/elang

Julian Orth

commit sha cee01471e380f8edbe4602fe0863de919bb9615c

a

view details

Julian Orth

commit sha 6682b22472b18d6107f0e7282fd02699851ef900

a

view details

Julian Orth

commit sha e1769c5e88167f4790b1d4071599c6b38a4f600b

a

view details

Julian Orth

commit sha 5806fca79e529114935319460b7598d06f1fe7d7

a

view details

Julian Orth

commit sha 426e04a3be60d62608946cd696e5eb547a92337c

a

view details

Julian Orth

commit sha 16a015150967a0f33f3242aa2914864e225f75c8

a

view details

push time in 3 months

more