The real WTF here is code that generates so many exceptions that you have to worry about the efficiency of the loop that processes them.
Lord_abletran
@Lord_abletran
Best posts made by Lord_abletran
-
RE: Optimize code with StringBuilders
-
RE: Optimize code with StringBuilders
Personally, I just use some inline assembler to increment.
for(int i = 0; i < something;
__asm (
mov eax, i
inc eax
); ) -
RE: Optimize code with StringBuilders
Well, ideally, you'd write the whole thing in asm, and just leave the value in a register if you could.
Latest posts made by Lord_abletran
-
RE: Desktopfication of Laptops
[...]Seems like a waist to me, buying a laptop [...]
-
RE: Optimize code with StringBuilders
Well, ideally, you'd write the whole thing in asm, and just leave the value in a register if you could.
-
RE: Fixed dialog sizes
@blakeyrat said:
<snipped a surprisingly reasonable blakeyrant>
A friend of mine used to know one of the guys who worked on the NT kernel while they were developing Win7. He was a smart guy, but it worried me, because he had never even been in a meeting with a filesystem guy, or a UI guy, or anything. From what I gleaned, they have all the separate parts of the OS written in almost complete isolation. While (maybe) not bad in principle, since it should help to avoid overly-tight coupling, it still makes the whole system lack a unity of design. -
RE: Linux is great! All hail Linux!
@boomzilla said:
@thistooshallpass said:
Sadly it was necessary to reboot the machine at least once a week because the software was lousy, and booting was super slow, so each time it took +30 minutes to do a full reset.
It took me longer than normal to understand what you meant by that, since the standard way to write it is "at least 30 minutes."
-
RE: Optimize code with StringBuilders
Personally, I just use some inline assembler to increment.
for(int i = 0; i < something;
__asm (
mov eax, i
inc eax
); ) -
RE: Linux is great! All hail Linux!
@Weng said:
i1586, not i586.
Sorry, I never learned how to read.
@Weng said:There actually is a (really stupid) reason Linux devs did this. The P4 and up are still technically i686 (with sprinkles) in the engineering documentation, but Intel set the family on the P4's to 0xF instead of 0x6 (which everyone else copied) - and the Linuxfailures read the family to determine what number to put in that spot. They won't fix it, because "it's what the CPU is reporting itself as. Not our bug."
Maybe I need to learn how to read, but I'm assuming that you're implying that AMD copied that? And that the devs, for no reason, used... printf("i%d86",vnumber); or something? -
RE: Linux is great! All hail Linux!
@Weng said:
Well, it does kind of make sense. In that not actually making any sense way.@Lord abletran said:
So,.. outdated OS has problems with outdated hardware?
This OS/system pair has been running happily unmolested for YEARS. The apparent cause is that I had the nerve to shut the shit down while I did some electrical work on their circuit. And naturally, a soft-reboot fixed the fucking problem, so it might have just been cosmic rays or some shit.But uh, i1586?
Edit: To clarify: It makes some sense that it might detect it as an i586 instead of an i686; for one thing, an AMD64 architecture wouldn't support the PAE of an i686, what with it already being 64-bit, however, it would still have the capabilities of at least an i586, so that makes a reasonable guess, I guess.
Either that or your Opteron has the fdiv bug, and Debian detected that on startup somehow. -
RE: Linux is great! All hail Linux!
So,.. outdated OS has problems with outdated hardware?
-
RE: Fixed dialog sizes
@pbean said:
[...] most windows and dialogue boxes in GTK and QT/KDE are resizeable, regardless of their size or function. I really like that, they should've put that in Windows 7 too.
...You can get GTK, QT, and KDE for windows. -
RE: Fixed dialog sizes
The only thing I can think of, is that this dialog was designed to work in the pre-install environment, where the display may well be running in Very Low-Resolution™ mode.