klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
Dreg has joined #osdev
nyah has quit [Ping timeout: 256 seconds]
k8yun has quit [Ping timeout: 240 seconds]
MiningMarsh has quit [Ping timeout: 240 seconds]
MiningMarsh has joined #osdev
gxt has quit [Ping timeout: 240 seconds]
gxt has joined #osdev
<mrvn> I broke my RPi monitor, now I have to put it back together again: https://www.amazon.de/Cloudberries-Gradient-Puzzle-1000-Teile/dp/B01M1871LS
<bslsk05> ​www.amazon.de: Cloudberries Gradient Puzzle - Cooles Erwachsenenpuzzle mit Farbverlauf (1000 Teile): Amazon.de: Spielzeug
Burgundy has quit [Ping timeout: 240 seconds]
Jari-- has joined #osdev
ElectronApps has joined #osdev
[_] has joined #osdev
[itchyjunk] has quit [Killed (silver.libera.chat (Nickname regained by services))]
[_] is now known as [itchyjunk]
<geist> Oh that reminds me, i had some little tiny VGA thing years ago, i think i left it at the office
<geist> Was nice to have
<geist> Like a 6 inch screen or so
freakazoid333 has joined #osdev
<Jari--> morning all developers + others from EU Finland
<vdamewood> Hyvää huomenta.
<klange> I had a terrible idea from mrvn's link of a physical puzzle where the pieces are also individual OLED or eink displays.
xenos1984 has quit [Read error: Connection reset by peer]
<Jari--> vdamewood kohtaus ohitse, seizure is over
<Jari--> tosi onnellinen - really happy its over
rustyy has quit [Remote host closed the connection]
xenos1984 has joined #osdev
<vdamewood> Seizure?
<Jari--> vdamewood yeah in the stomach, some in head
<Jari--> dunno it is over
<Jari--> no idea, I am not a doctor
<Jari--> constipation on seizure
<Jari--> one sign
<vdamewood> Good luck.
<Jari--> vdamewood could be Havanna syndrome :-)
rustyy has joined #osdev
<geist> Wow, okay
Oli_ has quit [Quit: leaving]
<bslsk05> ​www.themoscowtimes.com: Russian Tech Giant Yandex Says Might Default - The Moscow Times
dormito has quit [Ping timeout: 250 seconds]
dormito has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
xhrzg2017 has joined #osdev
xhrzg2017 has quit [Remote host closed the connection]
Matt|home has quit [Ping timeout: 245 seconds]
masoudd has joined #osdev
xhrzg2017 has joined #osdev
xhrzg2017 has quit [Client Quit]
ravan has quit [Remote host closed the connection]
troseman has quit [Read error: Connection reset by peer]
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
the_lanetly_052 has joined #osdev
ThinkT510 has quit [Quit: WeeChat 3.4]
[itchyjunk] has quit [Remote host closed the connection]
ThinkT510 has joined #osdev
the_lanetly_052 has quit [Ping timeout: 240 seconds]
<mrvn> moin
ElectronApps has quit [Remote host closed the connection]
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
GeDaMo has joined #osdev
Burgundy has joined #osdev
ElectronApps has joined #osdev
elastic_dog has quit [Ping timeout: 240 seconds]
ElectronApps has quit [Max SendQ exceeded]
ElectronApps has joined #osdev
elastic_dog has joined #osdev
pretty_dumm_guy has joined #osdev
elastic_dog has quit [Client Quit]
elastic_dog has joined #osdev
Matt|home has joined #osdev
not_not has joined #osdev
<not_not> Hai
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
dennis95 has joined #osdev
aejsmith has quit [Remote host closed the connection]
aejsmith has joined #osdev
mahmutov has joined #osdev
gxt has quit [Remote host closed the connection]
gxt_ has joined #osdev
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
vancz has quit [Ping timeout: 240 seconds]
pie_ has quit [Ping timeout: 256 seconds]
xenos1984 has quit [Remote host closed the connection]
pie_ has joined #osdev
vancz has joined #osdev
xenos1984 has joined #osdev
pie_ has quit [Ping timeout: 256 seconds]
vancz has quit [Ping timeout: 256 seconds]
pie_ has joined #osdev
vancz has joined #osdev
f11 has joined #osdev
milesrout has joined #osdev
<mrvn> Why does this take an hour and counting to compile? https://paste.debian.net/1233095/
<bslsk05> ​paste.debian.net: debian Pastezone
<kazinsal> i blame itanium
<mrvn> It's up to 2.7G memory now.
<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 ?
<FatAlbert> http://ix.io/3RqU
<GeDaMo> In what way does it not work?
<FatAlbert> it buffers
<FatAlbert> when i explicitly told stdout not to
<mrvn> no, it's line buffered
<GeDaMo> If you mean it waits until you press enter, that's not a buffering issue
<mrvn> "The setlinebuf() function is exactly equivalent to the call:
<mrvn> setvbuf(stream, NULL, _IOLBF, 0);
<mrvn> wait, different flag, sorry.
<FatAlbert> GeDaMo: then what issue is that ?
<FatAlbert> GeDaMo: i mean yeah, i try to output immediately (not waiting for Enter)
<GeDaMo> You need to set raw mode
<bslsk05> ​viewsourcecode.org: 2. Entering raw mode | Build Your Own Text Editor
<GeDaMo> Or you can use ncurses
<mrvn> why even use streams if you want unbuffered input? Do you want to ungetc()?
Oli_ has joined #osdev
<mrvn> hmm, the manpage does not detail what _IONBF means for reads.
<clever> my guess, is that it may read more then you meant to with a syscall
<mrvn> But it would conflict with ungetc()
<bslsk05> ​en.cppreference.com: setvbuf - cppreference.com
<clever> and buffer the extra in userland
Oli has quit [Ping timeout: 256 seconds]
<FatAlbert> GeDaMo: i didn't read it all ( yet ) but yeah .. it seems exactly what i need
<mrvn> GeDaMo: that page sayys even less about the effect of setvbuf()
<FatAlbert> can you please explain in short though why setvbuf is not the solution here ?
pretty_dumm_guy has quit [Ping timeout: 256 seconds]
<FatAlbert> it stated explicitly in every source i found that it should DISABLE buffering
<mrvn> FatAlbert: the manpage says only for writes
<FatAlbert> sorry i don't get it
<mrvn> FatAlbert: My (Debian) manpage says that _IONBF will not buffer any writes. It says nothing about reads.
<FatAlbert> how does it make any sense to buffer reads ?
<GeDaMo> reads can be coming from all kinds of devices, not just the terminal
<mrvn> FatAlbert: streams are required to have at least 1 char buffer for ungetc().
Oli_ is now known as Oli
<mrvn> FatAlbert: and if you read slow or the input is fast (file, disk, pipe, socket, ....) then you can easily read many characters at a time.
<FatAlbert> ok i talk only about the terminal
<FatAlbert> and my keyboard
<FatAlbert> where buffer stdin does not make sense
<mrvn> It's the whole reason for buffered IO. You want one costly syscall to get a whole bunch of characters at a time.
<FatAlbert> so the question is why setvbuf(stdout ..) doesn't solve that ?
<mrvn> FatAlbert: why not use getchar()? https://en.cppreference.com/w/c/io/getchar
<bslsk05> ​en.cppreference.com: getchar - cppreference.com
<FatAlbert> i used getchar
<FatAlbert> http://ix.io/3RqZ
<FatAlbert> even try to unbuf stdin
<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
<clever> which gave you a form of tab completion
<bslsk05> ​github.com: nginx-rtmp-module/ngx_rtmp_notify_module.c at master · arut/nginx-rtmp-module · GitHub
<clever> that thing i mentioned
<clever> other code (the table on line 100) enforces that only valid tokens can enter, but they havent been reduced to an enum
<klange> with considerable credit to munificent, as I probably would have written this as a series of strcmps otherwise...: https://github.com/kuroko-lang/kuroko/blob/master/src/scanner.c#L196-L268
<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
<mrvn> +is
<zid> return (*scanner.cur == '\0') ? '\0' : *(scanner.cur++);
<zid> That's an interesting line
<zid> I'm quite tickled by it
<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: nix/value.hh at master · NixOS/nix · GitHub
<klange> moon-child: Not sure what you mean
<clever> in nix, every value is a `struct Value`
<clever> it contains an enum with its type, and then a union that is always 2 pointers long
<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
<mrvn> clever: except python does refcounting
<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