lrs-lang/lib 205
An experimental standard library
mahkoh/comm 66
Communication primitives
Rudimentary DNS library
The lrs build system
The lrs compiler driver
Align text
select area with mouse
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.
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?
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.
comment created time in 2 months
issue commentrust-lang/rust
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.
comment created time in 2 months
issue commentrust-lang/rust
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.
comment created time in 2 months
issue commentrust-lang/rust
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.
comment created time in 2 months
issue commentrust-lang/rust
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
comment created time in 2 months
pull request commentalacritty/alacritty
Set default FreeType properties
Works on my machine.
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.
comment created time in 3 months
push eventmahkoh/elang
commit sha 50162180deddf27a9ff7661b06e7905de1a4083b
a
commit sha 6df42e72646ceda84b2863aa8d5c422393b805da
a
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.
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.
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?
This is how urxvt renders the same font. It seems much closer to the patched alacritty version than the unpatched one.
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.
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:
Without patch:
comment created time in 3 months
push eventmahkoh/elang
commit sha cee01471e380f8edbe4602fe0863de919bb9615c
a
commit sha 6682b22472b18d6107f0e7282fd02699851ef900
a
commit sha e1769c5e88167f4790b1d4071599c6b38a4f600b
a
commit sha 5806fca79e529114935319460b7598d06f1fe7d7
a
commit sha 426e04a3be60d62608946cd696e5eb547a92337c
a
commit sha 16a015150967a0f33f3242aa2914864e225f75c8
a
push time in 3 months