On Wednesday, 26 November 2014 at 22:22:43 UTC, H. S. Teoh via
Digitalmars-d wrote:
Have you considered just replacing the power supply?
That was one of my first thoughts, my last computer refit was
caused by a PSU failure.
I did some measurements on it and everything looked normal.... in
fact, EVERYTHING looked normal, the only time I could
consistently reproduce the problem on-demand was running memtest
with SMP turned on. That's why I figured the problem was with the
dual-core and disabled it.
But even now, I'm not 100% convinced that was the problem, maybe
it was the power supply, under stress not keeping up. I didn't
measure it at higher draw.
I figure I'll set up the old computer still - pull my IDE hard
drive out of the upstairs storage box to see about booting it....
though that i think has a 32 bit kernel on it... well, i can
tackle that later. Anyway, I figure I'll set it up somewhere and
still try to use it and see if the fix actually works in the
longer run, but I didn't want to depend on it because these kinds
of problems just tend to get worse.
But here's the funny thing... I took out the motherboard,
bought a new chassis and PSU, and plugged it all in, and
it booted with no problems!!!!
wow, sounds like luck to me :P
IME, that's almost a sure setup for disappointment. :-P
So is trying anything new.
Except cheesecake, I was convinced to make a cheesecake this
August and even at a piece myself when there was leftovers... and
it was AMAZING. I have one in the oven right now!
But mostly: change... bah, humbug.
I like my PC to be
completely mute except when I ask it to make a sound.
That's actually exactly *why* I *like* the speaker. I have ways
of making it only work when I want it to (mostly my heavily
customized software stack...) and having the separate channel
from the main speakers lets me keep a clean separation.
I use the PC speaker beeps to quickly and unobstructively* notify
me about new events. Emails, instant messages, etc., each has its
own beep tone. I can turn off the main audio speakers or use them
for different things at various volumes without worrying about my
notification beeps coming in nasty.
I hate it when I'm cranking some noise and then someone FB
messages me and it is like PLUNK and my ear drums explode. The
speaker beep is nice and consistent.
* One time, I used a computer with a MEGA LOUD BEEP and that
drive me nuts. Defeats the whole point to me. But I've been lucky
with just-right beeps out of my own desktops.
Really?? I would've thought DMD easily soaks up 4GB if you do
enough recursive CTFE / template metaprogramming... :-P
I run 32 bit dmd, it'd be killed before then :P
I like off-white terminals. Better yet, if your terminal could
support the xterm 256-color escape sequences...
I'm pretty sure it does support these already.... yeah, line 1437
of terminalemulator.d has it.
I implemented a 256 color palette at one point but the case 38
there for xterm 256 colors actually draws in truecolor. There's
also palette swap capabilities in there.
I went kinda nuts on features in that thing. One of them is also
a copy/paste extension that can be forwarded through nested
terminals. The Windows version can do clean cut+paste with linux
apps! (The Windows versions are cool btw, one is a GUI just like
the linux one - like identical, since it uses an embedded font
and font renderer too, and the other is a win32 console version,
which is surprisingly elegant. I like it a lot. But not enough to
kill PuTTY yet (especially since my windows version depends on
plink to communicate. It just speaks to a piped process instead
of knowing ssh or anything itself.)
Shouldn't byGrapheme handle most of that out-of-the-box already?
Maybe, I haven't tried.
misinterprets sequences not meant for it. Ideally, screen (or
your replacement thereof) should be able to detect the end
user's terminal (even if it's proxied via ssh, etc.) and do the
Right Thing(tm)
The approach I took is similar to screen: it intercepts all the
escape sequences and handles them itself.
My screen replacement has two parts: attach and detachable. You
can see the source on my github terminal-emulator project. Attach
uses terminal.d to read user input events and forward them down
the line. detachable uses the terminal emulator core to maintain
an internal screen buffer.
When you attach to it, it sends commands to draw itself and a few
other state issues. When it changes, it forwards those changes
outward.
But ultimately, the detachable thing is just a terminal emulator
that redraws itself through a unix socket instead of straight to
the screen.
I have a muttrc that basically completely remaps most of the
keys...
I kept my muttrc (I didn't copy my whole /home/me directory
because I kinda want to clean it out - it has like 2,000 files on
the top level - but I copied parts of it to the new one and the
old is available on demand) but the new mutt changed a behavior I
had gotten used to. I might remap the key or just hack the
source, idk yet.
point-n-grunt rodent-dependent UIs. Supposedly that's "more
productive",though I'm honestly baffled how anyone could
believe that.
indeed
