On Wed, 26 Nov 2014 14:20:37 -0800
"H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:

> > The other part of my terminal emulator was also a gnu screen replacement. I got it to the point where it worked pretty well... but not well enough to break my inertia toward good old screen. Maybe I'll revisit that too though.
> 
> Ooooh, I'd love that! I do use screen a lot, but some aspects of it annoy me a lot. Like the non-transitivity of terminal settings, so $TERM doesn't get set properly, and even when it does, screen sometimes 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) on the server end so that applications get the right $TERM settings.
i was never big fan of screen and i never used any of it's advanced features, so once i dumped it in favor of dtach. and now i'm really happy, 'cause dtach does exactly what i want: allows me to detach from console program and then attach to it again. it intercepts only one hotkey and doesn't try to mess with escape codes at all. love it.

sure, it doesn't keep output history, you have to press something like ctrl+l to redraw the screen in fullscreen app (if that app supports it) and so on, but my, it's nothing compared to constant fighting with 'screen', it's configs, it's habit to steal and reinterpret escapes...

now i'm happy dtach user.

On Wed, Nov 26, 2014 at 10:46:08PM +0100, Andrej Mitrovic via Digitalmars-d wrote:
> On 11/26/14, Adam D. Ruppe via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > That's in the xterm source code. Yes, it depends on the presence of a particular include guard.
> 
> Oh you should know how much trouble I went through when I was building my C++ wrapping tool (initially just a wxWidgets wrapping tool). The include stuff was 90% of the mess. So much frustration with *order of inclusions*. It's probably *the* reason why I completely burnt-out on continuing working on tool after several months.

Wow. I've only had the misfortune of having to deal with order-dependent #include's a few times in my life. I must live a sheltered life indeed! :-P  I do agree that they are utterly evil, though. Even more evil is header files that compile successfully even if the #include's are wrongly ordered, but behaves differently (yes, I have actually seen this before):

	// some evil .h file:
	...
	#ifndef someSillyStdLibMacro
	#define someSillyStdLibMacro myOwnBrokenImpl
	#endif

So if you #include the system header that defines someSillyStdLibMacro, then you get the right behaviour, otherwise, the code still compiles but you end up using myOwnBrokenImpl instead, which inevitably does NOT work properly on your system 'cos, unsurprisingly, it was written for the author's own peculiar environment. Worse yet, the broken implementation only gets used in .c files that have the wrong ordering of #include's. Good luck debugging this nightmare!


> I can't believe there are brand-new programming languages being
> developed where the author(s) still insist(s) on textual inclusion.

Wow. Textual inclusion is so 80's! Where've they *been* all this time?!


> I'm sorry, but the detour you took with that simple decision causes an insane mess for both the tools and the end-user, don't repeat the mistake of C and C++ anymore, please! D's modules are a **massive blessing**.

Yeah, D's module system saves a LOT of headache, even in spite of its flaws. (Private imported module symbols conflicting with public symbols, anyone? Global scoped imports always being public? Local unscoped imports shadowing local variables (aka local variable hijacking)? Yeah, D modules could be better...  but compared with #ifdef hell in C/C++, it's still orders of magnitude better.)


T

-- 
Turning your clock 15 minutes ahead won't cure lateness---you're just making time go faster!

On Thu, Nov 27, 2014 at 12:33:25AM +0200, ketmar via Digitalmars-d wrote: [...]
> i was never big fan of screen and i never used any of it's advanced features, so once i dumped it in favor of dtach. and now i'm really happy, 'cause dtach does exactly what i want: allows me to detach from console program and then attach to it again. it intercepts only one hotkey and doesn't try to mess with escape codes at all. love it.
> 
> sure, it doesn't keep output history, you have to press something like ctrl+l to redraw the screen in fullscreen app (if that app supports it) and so on, but my, it's nothing compared to constant fighting with 'screen', it's configs, it's habit to steal and reinterpret escapes...
> 
> now i'm happy dtach user.

Whoa. Just looked up dtach... I like it!!!! I think I might start using it in favor of screen, which like you said is just a mess.

Thanks for the tip!!


T

-- 
I've been around long enough to have seen an endless parade of magic new techniques du jour, most of which purport to remove the necessity of thought about your programming problem.  In the end they wind up contributing one or two pieces to the collective wisdom, and fade away in the rearview mirror. -- Walter Bright

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

On Wednesday, 26 November 2014 at 22:39:52 UTC, H. S. Teoh via Digitalmars-d wrote:
> Whoa. Just looked up dtach... I like it!!!! I think I might start using it in favor of screen, which like you said is just a mess.

I've tried dtach before but never got into it. There's actually a handful of screen's messier features that I like...

Found a bug in the terminal emulator immediately after switching my hotkeys to use it - there was an escape sequence sent to it that the controlling terminal usually responded to and now it didn't have one.

And vim apparently changed its auto indent behavior. Thanks, now my habit of hitting enter then tab is breaking the code. So angry, this is stupid beyond belief. vim usually impresses me with its goodness. That makes this BETRAYAL hurt all the more.

et tu, vim? et tu?


BTW @nogc should have an escape hatch at least for assert(0, allocate_a_message). The program is dying anyway, at least let me conveniently format a descriptive error message.

On Thu, 27 Nov 2014 03:51:58 +0000
"Adam D. Ruppe via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:

> BTW @nogc should have an escape hatch at least for assert(0, allocate_a_message). The program is dying anyway, at least let me conveniently format a descriptive error message.
hey, but we can hack it!

  import std.traits;

  auto assumeNoGC(T) (T t) if (isFunctionPointer!T || isDelegate!T) {
    enum attrs = functionAttributes!T | FunctionAttribute.nogc;
    return cast(SetFunctionAttributes!(T, functionLinkage!T, attrs)) t;
  }

  void test () @nogc {
    assert(0, assumeNoGC(() { import std.format : format; return "%s".format("hi")~" there!"; })()); }

  void main () @nogc {
    test();
  }

On Thursday, 27 November 2014 at 03:51:59 UTC, Adam D. Ruppe wrote:
> BTW @nogc should have an escape hatch at least for assert(0, allocate_a_message). The program is dying anyway, at least let me conveniently format a descriptive error message.

Ownership would solve this.

On Thursday, 27 November 2014 at 05:04:20 UTC, deadalnix wrote:
> On Thursday, 27 November 2014 at 03:51:59 UTC, Adam D. Ruppe wrote:
>> BTW @nogc should have an escape hatch at least for assert(0, allocate_a_message). The program is dying anyway, at least let me conveniently format a descriptive error message.
>
> Ownership would solve this.

Is there any work being done on ownership?

@Adam D. Ruppe : Check out st from suckless, it was made because
xterm is unmaintainable. Also, consider a distro from this
century ;)

On Thu, 27 Nov 2014 05:12:51 +0000
weaselcat via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> @Adam D. Ruppe : Check out st from suckless, it was made because xterm is unmaintainable. Also, consider a distro from this century ;)
heh, that was the base of my own terminal emulator. just because that was the only TE with non-writeonly code. ;-)