I haven't tried to repro this so sorry if this is a false positive.
I was looking at what line endings langs/compilers/runtimes print on Win and Linux/osx.
It looks like GHC, on Windows, prints \n
in NoBuffering
mode, but \r\n
in LineBuffering
mode.
Code for NoBuffering
: https://github.com/ghc/ghc/blob/b57200de601e4ef6827727176611d7192016b8b2/libraries/ghc-internal/src/GHC/IO/Handle/Text.hs#L654
This prints \n
regardless of what the handle's line ending is.
When buffered, the same function calls writeBlocks
with the handle's line ending passed, which I think will print \r\n
in: https://github.com/ghc/ghc/blob/b57200de601e4ef6827727176611d7192016b8b2/libraries/ghc-internal/src/GHC/IO/Handle/Text.hs#L689
Secondly, the expected behavior of what hPutStrLn
, readLn
and similar "print/write or read with newline" should print or expect for the line endings should be documented. I checked putStrLn
, hPutStrLn
, and readLn
. I don't know what other similar functions exist.
As an example, this is the Rust docs specifying expected line endings in read and write functions:
\n
regardless of the platform, \r
will be part of the yielded lines)\n
regardless of the platform)Ömer Sinan Ağacan (731d2c11) at 01 Jan 09:30
Kind signatures docs: mention that they're allowed in newtypes
Ömer Sinan Ağacan (5b603139) at 01 Jan 09:30
Revert "testsuite: mark jspace as fragile on i386."
... and 9 more commits
Ömer Sinan Ağacan (42f46440) at 23 Dec 14:57
Fix a code block syntax in user manual sec. 6.8.8.6
Ömer Sinan Ağacan (0038d052) at 23 Dec 14:49
testsuite: mark jspace as fragile on i386.
... and 7260 more commits
Ömer Sinan Ağacan (537a20cf) at 23 Dec 14:46
Fix BNF in user manual 6.6.8.2: formal syntax for instance declarat...
... and 7261 more commits
This bug can be triggered without partial type signatures:
{-# LANGUAGE NoMonomorphismRestriction #-}
x :: Num a => a
(x, y) = (1.2, 3.4)
Output with GHC 9.2.5:
test.hs:4:1: error:
• Could not deduce (Fractional a) arising from GHC Bug #20076
from the context: Num a
bound by the inferred type for ‘x’:
forall a. Num a => a
at test.hs:4:1-19
• When checking that the inferred type
x :: forall {a} {b}. (Fractional a, Fractional b) => a
is as general as its signature
x :: forall a. Num a => a
|
4 | (x, y) = (1.2, 3.4)
| ^^^^^^^^^^^^^^^^^^^
A much better approach would be to keep a separate compact set of memory pages with metadata
This trades locality of metadata with performance of mapping objects to their block or segment metadata, right? Storing metadata in block or segment headers gives us an efficient way of mapping an object to its metadata by just masking the low bits and adding a constant. If we store the metadata elsewhere mapping an object to its segment or block metadata will be more costly.
Do you have an idea on how to map an object to its block/segment metadata efficiently with your suggestion?