<milesrout>
<ranges> and good compile times: pick one
<mrvn>
Worst case it should compute the first 100 primes at compile time and collaps the whole thing, right? Creates a nested templated type 100 level deep, right?
<mrvn>
Can I do a type erasure on a range so the recursion doesn't create a new type?
masoudd has quit [Ping timeout: 272 seconds]
the_lanetly_052 has joined #osdev
[itchyjunk] has joined #osdev
<mrvn>
2h and 3.7G. I wonder if the code will ever compile or if the source is a halting problem.
Oli has joined #osdev
Clockface has joined #osdev
srjek has quit [Ping timeout: 240 seconds]
ElectronApps has quit [Remote host closed the connection]
f11 has quit [Quit: WeeChat 3.4]
not_not has quit [Ping timeout: 272 seconds]
the_lanetly_052_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 240 seconds]
kingoffrance has quit [Ping timeout: 250 seconds]
bleb has quit [Remote host closed the connection]
elastic_dog has quit [Ping timeout: 240 seconds]
pie_ has quit [Quit: pie_]
vancz has quit [Quit: vancz]
elastic_dog has joined #osdev
elastic_dog has quit [Client Quit]
elastic_dog has joined #osdev
Oli has quit [Ping timeout: 256 seconds]
Oli has joined #osdev
bleb has joined #osdev
dennis95 has quit [Quit: Leaving]
pie_ has joined #osdev
vancz has joined #osdev
pie_ has quit [Quit: pie_]
vancz has quit [Quit: vancz]
vancz has joined #osdev
pie_ has joined #osdev
FatalNIX has joined #osdev
Mikaku has quit [Quit: server maintenance ...]
Mikaku has joined #osdev
Oli has quit [Read error: Connection reset by peer]
Oli has joined #osdev
blockhead has joined #osdev
<CompanionCube>
mrvn: did it compile
<moon-child>
mrvn: I think you want constexpr if (prime < limit)
<mrvn>
moon-child: I stopped it at some point. prime can't be constexpr since sieve.front() isn't.
<moon-child>
I mean that seems like the problem
<mrvn>
And without that the compiler has to validate the code inside the if even if it knows it will never be taken.
<moon-child>
it's gonna instantiate the function 4b times
<mrvn>
FINAE kills it
<mrvn>
I don't get why the type of a view needs tp know the whole stack of filters I apply. All it really needs to know is the items are ints. What does the rest matter to the outside?
<geist>
ints not up to you
FatAlbert has joined #osdev
<FatAlbert>
why setvbuf(stdout, NULL, _IONBF, 0); does not work ?
<mrvn>
FatAlbert: I think we are talking past each other. We suspect the problem is on the input side, not output.
<GeDaMo>
The buffering of the stream is not the same as the buffering of the device
<FatAlbert>
i see ...
<FatAlbert>
i am being buffered merely on being on the terminal before launching setvbuf()
<GeDaMo>
"However, by default your terminal starts in canonical mode, also called cooked mode. In this mode, keyboard input is only sent to your program when the user presses Enter"
<FatAlbert>
so setvbuf() don't effect the terminal buffering
<mrvn>
FatAlbert: in the end of your while loop add "break;" Now the code should only read one char and exit. But it waits for the ENTER.
<mrvn>
FatAlbert: that shows the problem is on the input side, not the output.
<mrvn>
FatAlbert: correct, the terminal buffers before the stream.
<mrvn>
FatAlbert: hence you can type in some text and use backspace to correct any typos.
<FatAlbert>
GeDaMo: thanks
<FatAlbert>
i get it
<FatAlbert>
mrvn: ok thanks
smeso has quit [Ping timeout: 256 seconds]
smeso has joined #osdev
eddof13 has joined #osdev
<FatAlbert>
is everything i an do in termios.h i can do with stty ?
<geist>
i also think there was some weirdness re: setting vbuf once things are already queued up?
<geist>
i think i remember something like that before
<geist>
but i haven't read this full backtrace
<clever>
FatAlbert: another factor, is that there is both kernel and userland buffering
xenos1984 has quit [Remote host closed the connection]
<mrvn>
geist: you can only set vbuf after opening the file but before using it
<clever>
FatAlbert: i think termios.h and stty, are purely kernel-side buffering, where the raw read() syscall may not return anything, until the user hits enter
<clever>
while setvbuf is part of libc, and handles userland side buffering i believe
xenos1984 has joined #osdev
<clever>
so it may not even call write(), half the time, and read() may read more then you asked for
<geist>
mrvn: yeah
<mrvn>
would be kind of hard to switch buffers mid stream. What if you have more data buffered than the new bufer has space?
<FatAlbert>
clever: ok thanks
<clever>
FatAlbert: running your program under strace can reveal some of what is going on, at the syscall level
<clever>
i also strace other things like say bash, to see how its handling its input, and then lookup those functions in man pages
<FatAlbert>
strace is really helpfull thanks for the tip
<rwb>
klange: >Is ToaruOS a Linux distribution? No, not all.
<rwb>
did you mean "not at all"?
<sham1>
He a word
GeDaMo has quit [Remote host closed the connection]
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sortie>
You wouldn't distribute a Linux
eddof13 has joined #osdev
<klange>
that's been there for ages and no one's told me
<klange>
unrelated, I submitted a patch to QEMU to fix a bug I reported months ago, it's like a two-line patch
Oli_ has joined #osdev
Oli has quit [Ping timeout: 240 seconds]
<klange>
if that goes through I might prep a patchset to make the cocoa UI not garbage
<sortie>
:D
<klange>
It opens behind iTerm2, and it prompts to quit when you try to close the window - and someone explicitly wrote that bit and spent time on the modal for it!
<klange>
The patch I sent is for the gtk UI, which is interpreting GDK 2-button and 3-button press events as mouse button releases and sending them to the guest as such.
<klange>
This indirectly causes an issue in ToaruOS where double clicking a window title bar results in dragging the window, as it leads to a timing problem - the bad release happens immediately with the press, and then the real release doesn't happen because there's no status change in the PS/2 device
<klange>
And the actual handling of mouse down = start dragging is client-side in Yutani, while the release handling to exit it is server-side, so the server has already processed the release before the client responds to the press with "please drag this window".
<klange>
Normally the IPC would be fast enough that a human initiated click would not trigger this timing issue.
<milesrout>
that sounds enormously frustrating
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
eddof13 has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Client Quit]
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
eddof13 has joined #osdev
rcvalle has quit [Quit: Leaving]
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mrvn>
type erasure in C++ loks like it's going to be slow. You have a wraper class with free/member functions that has a std:uniq_ptr to a base class that has a pointer to the vtable with pointers to mebmer functions that then call free functions. So function call -> indirection -> indirection -> function pointer call -> function call to do anything.
* moon-child
hands mrvn a copy of hotspot
<mrvn>
what's that?
<moon-child>
java vm
<moon-child>
does fancy runtime devirtualization
<moon-child>
=> free type erasure
<mrvn>
I can just use python or ocaml. They do that natively.
<moon-child>
pypy probably, but does ocaml do that kind of thing? I thought it was a static/batch compiler?
<mrvn>
moon-child: ocaml has polymorphism and objects with methods.
<mrvn>
both have no runtime types.
<moon-child>
right, but it doesn't remove the overhead of the indirect call?
<mrvn>
polymorphism has no indirection and no virtual functions or the like. You would have to pass in getters and setters yourself. Methods do a hashtbl lookup.
<clever>
something i'm reminded of, is that haskell has some features that kind of behave like java templates
<clever>
where you can define a set of functions an object should have, and then declare a class as having those functions
<moon-child>
hash table? My, that's terrible..
<mrvn>
clever: type classes
<clever>
mrvn: yep
<klange>
pretty much everything in python is a hash table
<clever>
for haskell, its not using vtables, but it functions much more like c++ templates
<mrvn>
moon-child: the hash is computed at compile time. SO it's just a jump table.
<clever>
where the functions get re-compiled, for every class that they could be used against
<clever>
so there is no cpu overhead at runtime, only a size of .text overhead
<mrvn>
You have to have one indirection somewhere.
<mrvn>
clever: that would be functors then
<moon-child>
you still need a div before you even get to the indirect call. And it's way worse than java, where you have an inline cache, so not really any indirection
<mrvn>
moon-child: what div?
<moon-child>
you know the hash of the symbol being looked up, but you don't know the size of the table it's being looked up in, so you need to mod by the size of the table
<moon-child>
(unless you use pot tables I guess)
<mrvn>
moon-child: that's a mod and not a div. And often you have 2^n-1 or so as size.
<moon-child>
mod is the same cost as a div
<mrvn>
or hell, even straight up 2^n. Those hashes are compile time things so the compiler can warn/error when you try to cause collisions.
<mrvn>
moon-child: mod (2^n-1) is much simpler.
<moon-child>
idk how you do mod 2^n-1. mod 2^n is cheap yes
<moon-child>
perfect hashing is doable, seems rather expensive for what it gets you, though
<mrvn>
moon-child: doesn't have to be perfect, far from it. You can just grow the hashtbl to make it collision free. You have one table per type, size doesn't really matter.
<clever>
i was looking at some nginx module config parsing code recently, and it was crazy
<clever>
instead of just a big list of strcmp() calls, it was a strlen() and then a single character test
<klange>
i had more fun in a month of hacking together my own python knock-off than in a decade of osdev
<moon-child>
mrvn: that's still perfect hashing
<mrvn>
moon-child: perfect-hashing I believe would have no gaps in the table.
<klange>
clever: that reminds me of how php function table hashing worked
<klange>
the hash was strlen()
<moon-child>
perfect hashing is just an injection from S to {n∊N|n<z}, no stipulation that z is the length of S
<mrvn>
clever: I can't remember what it was called but there is a language where you tokenize keywords by looking at the first and 3rd character and you get an unique token and it even works with translation. So there is a english flavour and german flavour and so on.
<moon-child>
haha cute
<klange>
In TI Basic for the 83, 84 series calculators, the keywords of the language are separate tokens and not actually typed out; the editor only displays them as words.
<mrvn>
klange: C64 basic too. Why store the word when the token only needs 1 byte and is faster for the interpreter too?
<clever>
oh, that reminds me
<klange>
This was also a massive pain in the ass as despite the calculators having alphabet keys you had to enter keywords from a menu.
<clever>
c64 basic, used bit7 of the character, as a "last character" signal
<clever>
so you didnt waste a byte on \0
eddof13 has joined #osdev
<mrvn>
klange: oh that sucks. The C64 prompt would just tokenize the input.
<clever>
but, the way it was doing the string compare, having bit7 set on the input string (the keyword you typed in the code), would falsely trigger a "end of string, all matched" condition
<mrvn>
so no typing in öäü?
<clever>
mrvn: so if you type a unique prefix, and hit the last character with the right modifier, the tokenizer would falsely think it was a perfect match
<bslsk05>
github.com: kuroko/scanner.c at master · kuroko-lang/kuroko · GitHub
<mrvn>
anyway, back to type erasure. Storing a void* and struct Methods with function pointers and then casting things around seems much faster even if it incredibly dirty
<clever>
klange: i think this is where pattern matching in a language like haskell can do better
<clever>
you can just give it a list of strings you want to match on, and a function body to run for each case
<clever>
and the compiler will find the unique sub-strings, and auto-generate code like what you wrote
<mrvn>
zid: The scanner can be called multiple times at the EOF and remains EOF.
<zid>
could even throw in a warning statement to it
<clever>
c/c++ doesnt have string support in switch/case, so the compiler isnt really allowed to be that smart
<mrvn>
In c++ you can use string literals as template parameters or constexpr to do a lot of cool stuff now.
<zid>
oh it doesn't actually use it everywhere, what a shame
<clever>
mrvn: but can you do `case "foo":` and `case "bar":`, then the compiler first switches on string length, then comparing chars?
nyah has joined #osdev
<mrvn>
clever: why would I want that? The input could be 465634756347 bytes long.
<moon-child>
klange: I would rather intern symbols as I read them
<moon-child>
pay one hashtable lookup and then everything else is free
<mrvn>
python strings are length prefixed, right?
<klange>
python string objects have a stored length, but "length prefixed" implies some things that are not true of them
<moon-child>
length prefixed means the length is in the memory pointed-to, same as the contents, right?
<klange>
specifically it's not like there's a length and then the string... the string contents are not stored with the object, they're elsewhere
<mrvn>
klange: ok, prefixed is the wrong word as that implies a certain memory layout. but you got the idea.
<mrvn>
So what you actually get is member wise comparison. strlen() is simply the first member of the python string and then the data pointer, which it follows.
<bslsk05>
github.com: kuroko/obj_str.c at master · kuroko-lang/kuroko · GitHub
<klange>
wheeee
<clever>
i forget exactly which language, but ive also seen strings stored as a length+ptr, where it may be sharing a sub-string of another string
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<clever>
but thats also maintaining a reference to the original string object, and bumping the refcnt of it
<clever>
so only when all sub-strings are out of scope, can it free the whole thing
<j`ey>
Rust has that (&str) and C++ too (string_view)
<mrvn>
Ocaml has a nice string representation too. Every value is stored as a block of N words with a header that includes N. Strings then store the number of bytes free in the last word in the last byte of that word.
<mrvn>
e.g. {{.N=4, ...}, {"Hell"}, {"o, w"}, {"orld"}, {"!\0\0\2"}}
<mrvn>
Means the strings are always 0 terminated. Either through padding or because the free count is 0.
<clever>
neat
<klange>
I intern all strings, store them as UTF-8 bytes, and also lazily store them as an efficient codepoint array.
<moon-child>
klange: synthetic codepoints?
<moon-child>
mrvn: so string contents are accessed indirectly?
<klange>
This is sort of an inverse of what CPython does, as it stores the efficient codepoint array and then lazily will convert back to bytes as needed, but I use bytes more internally so it made more sense.
<mrvn>
moon-child: no. A string is a pointer to 'H'.
<bslsk05>
github.com: MoarVM/strings.asciidoc at master · MoarVM/MoarVM · GitHub
<mrvn>
moon-child: The header is metadata for the GC that's placed before each allocated block.
<clever>
a list of length 1, and length 2, are special types, that use the Value * smallList[2]; part of the union
<moon-child>
klange: gives you efficient O(1) access to grapheme clustres, but only requires indirections for the grapheme clustres comprising more than one codepoint
<clever>
while a list of length n, uses the struct { size_t size Value * * elems; } bigList; part
<klange>
No, grapheme clusters require more data than my entire compiler's source.
<mrvn>
Python lists aren't lists, they are arrays.
<klange>
I store actual codepoints and deal only in actual codepoints, as Python does.
<clever>
so short lists, skip a level of indirection, and dont waste 2 pointers to refer to a single pointer
<clever>
but longer lists do have indirection
<klange>
For a larger language, I can definitely understand wanting grapheme clusters as a native concept, but with Kuroko opting for 'just codepoints' was an easy decision - it was what Python does, and it meant not having to depend on a whole truckload of Unicode data in my interpreter.
<mrvn>
clever: how does that work with passing around items from the list? Wouldn't that have to refcount the whole short list?
<clever>
mrvn: garbage collection works by just searching each object for a pointer to another object
<bslsk05>
en.wikipedia.org: Boehm garbage collector - Wikipedia
<mrvn>
boehm is horrible.
<mrvn>
way to many false positives
eddof13 has joined #osdev
<clever>
that may explain why its always using so much ram, for larger evals
<clever>
i'm also reminded of a JS framework called qx
<klange>
you want a horrible gc, look at mine
<clever>
it was made back in the days before js engines had cycle detection
<moon-child>
bdw is fine on 64-bit
<clever>
when refcounting would leak horribly, because a depends on b, which depends on a, but nothing refers to the cycle
<klange>
babby's first mark and sweep
<klange>
(it's my first actual language, please be gentle)
<moon-child>
no semispace?
<clever>
qx's solution, was to add destructors to javascript, and to shred every reference upon destruction
<clever>
so cycles didnt exist when you where done with an object
<clever>
and the refcnt would hit a true 0
<moon-child>
thanks, I hate it
<moon-child>
it's like weak pointers but worse
wolfshappen has quit [Ping timeout: 268 seconds]
<mrvn>
at which point you can just free the object directly. no refcnt needed.
<clever>
moon-child: qx also stored every bloody object in a single global array, so if you forget to destruct it, you leak harder then ever!
<moon-child>
worse and worse!
<clever>
also, at page unload, it runs the destructor for every object in that array
<clever>
causing firefox to lock up solid for 3-4 minutes
<clever>
at which point, firefox would ask, do you want to kill this? do you want me to ask again?
<clever>
but the "ask again" checkbox, means it just stops asking, and stays locked up for the full 4 minutes :P
<clever>
this was back in the days before multi-processes engines, when js and gui shared a thread
<mrvn>
firefox still locks up like that today.
<clever>
but back on the subject of boehm
<clever>
if i null out every pointer in the c++ destructor, could that reduce false positives?
<moon-child>
probably not significantly
<moon-child>
it's likely to get overwritten anyway before long
<mrvn>
boehm looks at every bit of data. Anything that could be a pointer is assumed to be a pointer. So if your code uses 4GB of ram then every int is a pointer to a valid address and nothing gets freeed at all.
<moon-child>
the false positives are really not a big practical issue at all on 64-bit