On Saturday, 14 September 2013 at 06:35:05 UTC, Nick Sabalausky wrote:
> On Fri, 13 Sep 2013 20:49:03 -0700
> Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 9/13/13 5:39 PM, Adam D. Ruppe wrote:
>> > On Friday, 13 September 2013 at 22:32:30 UTC, Andrei Alexandrescu
>> > wrote:
>> >> Sure... wait, what?
>> >
>> > Download a random binary off the internet.
>> 
>> Nope :o).
>> 
>
> Meh, all the hip blackhats are doing browser drive-by exploits,
> session hijacking and specially-corrupted-data exploits. Trojans and
> exe-infection is, like, soooo 90's, dude.
>
> But more seriously though, I run exes off the net all the time and I
> haven't dealt with those problems on my own Win computers in probably a
> decade.

Because virus nowaday aren't there to destroy your computer, but to make it participate in botnet. Being as discrete as possible is the goal.

And probably also because you use trusted sources + a bit of luck.

On Fri, 13 Sep 2013 15:48:55 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> > 
> > LOL. Yeah, the main reason that I don't use IDEs is the fact that they're essentially a glorified version of notepad as far as editing goes. They _do_ usually have better editing capabilities then the ever-so-pathetic notepad, but they can't do much of anything in comparison to the likes of vim or emacs.
> 
> I don't even consider a notepad a real "editor". Useful for doodling random notes to yourself, I suppose, in accordance with its name, but pretty much unusable for anything beyond that.
> 

Yea, notepad has *not* held up well. It's pretty awful. I occasionally use it to remove formatting from text I'm copy-pasting, and that's about it.

Even for basic "jotting down notes" I've switched from notepad over to my fast-loading code-editor (Programmer's Notepad 2) or OpenOffice if I want spellcheck (it's slow to load, but I usually keep a blank instance open just in case - hey, it's still far less of a resource drain than any web browser!).

> 
> > So, I end up using (g)vim for everything. The features that an IDE has that vim doesn't typically just aren't worth it. e.g. if I'm stuck doing Windows programming, about the most that I even do with VS is use the debugger. I even build from the command line rather than open the IDE.
> 
> We really should improve D support in gdb (or whatever other debugger people like to use on Windows). I've mainly resorted to writeln debugging, and it's really quite embarrassing. Though, I think there's an unfair stigma against it -- I found that well-placed fprintf's (in C/C++) are surprisingly effective at tracking down hard-to-find bugs in code involving fork() and dynamically-loaded .so's, that gdb (or any other debugger) would require lots of tedious setup to even begin to debug properly. In an embedded environment, where it's not so easy to substitute system libraries or install the latest debugging scaffolding, printf debugging may well be on par with "real" debugging with a debugger, methinks.
> 

I love writeln debugging. I don't have to boot it up, configure it, learn about or task-switch my mind over to any new interface, or actively shy away from any opportunities that don't come with a fully-mature debugger (or wind up with my arms tied when I'm in the debugger habit and don't have a debugger available for whatever reason - in my experience, debuggers are reliance-forming drugs).

But the *best* thing of all with writeln debugging: Being able to examine the entire relevant execution forwards *and* backwards in time, all at a glance, with zero "stepping". Total win.

Any time I use a debugger I get sooo sick of having to reset and hit "step" a million times (or muck around with conditional breakpoints, which never seem to be intuitive - *if* they even work at all) every single time I want to see (or remember) what happened *before*. But with writeln - I already see the whole relevant trace at a glance, and all with exactly the same tools and interfaces I'm already using.

Writeln debugging rocks my world.

On Sat, Sep 14, 2013 at 02:42:13AM +0200, Adam D. Ruppe wrote:
> On Friday, 13 September 2013 at 22:34:44 UTC, Justin Whear wrote:
> >This is a distribution problem; I've stuck with Debian or Debian-based distros over the years and never had issues like this.
> 
> I've used them too... ever have a proprietary requirement that only works with, say, php 5.2, but only php 5.1 is available in the repo?
> 
> Or a custom built thing the company relies upon.... but no longer has the source, and their old server just died? Or, has the source, but it only compiles with one specific setup anyway.
> 
> I've had to deal with stuff like this several times, and the package manager fights me every step of the way.

When I custom-install stuff, I usually put it in /usr/local/*, or even give it a dedicated home in /home (though usually just /usr/src/$pkgname/install or some such), away from the package manager managed stuff.  It tends to work far better that way.  Fighting with the package manager never ends well, as does installing external files into directories managed by the package manager. Almost all modern sources come with PREFIX configurability -- those that don't tend to be so fundamentally b0rken anyway that I don't even bother with them in the first place. But you have my sympathies if you're compelled to do so by work requirements. In that case, I'd use a chroot and custom install all system binaries so that I control exactly what goes in there, and never have the package manager interfere with me.


> Or, on my home computer, someone wrote something cool.... but of course they don't offer a package for my system. (At home, I use Slackware.) So it is time to build from source. Great, but then it is time to track down a hundred tiny libraries (seriously, a 10 kb library, why didn't you just include that in your own source?), of course matching the version too. What a hassle!

I find that even with sources downloaded from some random person's "cool proggies" website, apt-get install libabc123-dev tends to work quite well, where abc is the name of the library and 123 is the desired version number. You do have to get to know Debian naming conventions for these things to be able to find them easily, though. Or know how to find out the right name(s). My go-to tool is apt-cache search, which is pretty good at finding libraries most people need. It also helps to know how to coax apt-get to fetch specific library versions instead of the default latest version.

If I have to install libraries not in the apt repository (or multiple conflicting versions of the same library), I tend to put it either under an entirely different PREFIX, preferably under a dedicated subtree for the app I'm trying to build, or inside a chroot if all else fails.  This way I can install libfoo101-dev for randomapp123 in one place, and never have it conflict with libfoo109-dev for randomprog321, which exists in a completely unrelated directory tree. The library can be so b0rken as to use the same soname for incompatible ABIs, and they won't step on each other's toes. For this latter case, chroots are the most convenient setup, otherwise you have to munge around with LD_LIBRARY_PATH, which can get quite messy. (Thankfully, you can put this in a wrapper shell script that hides away the mess under a convenient command in your $PATH, so the pain only has to be felt once.)

Generally, all of this is still less painful than trying to make a random binary executable run. For all you know, you could be wasting your time trying to run a Solaris binary on an i386 system. There are just too many possible configurations out there for binary distribution to be viable, except when you're the distro provider.


> Hence my first comment: I prefer to just grab the Windows version and run it in wine. That usually just works.

I dunno, wine doesn't seem to like my GUI configuration (or lack thereof :-P). It just falters in its steps and gasps every now and then, that I don't trust that whatever program it's running is actually doing what it should be doing. I still rather build from source.


T

-- 
"A man's wife has more power over him than the state has." -- Ralph Emerson

Sublime Text 3 or VisualD, mostly

On Sat, Sep 14, 2013 at 02:54:55AM +0200, Adam D. Ruppe wrote:
> On Friday, 13 September 2013 at 22:29:28 UTC, H. S. Teoh wrote:
> >The only time I've actually had trouble with linux binaries is when there's a problem with libc upgrades
> 
> The biggest offender for my home computer is gtk and glib. libc can be painful too - especially with work computers that stick to a particular version in the name of stability (I don't blame them, updating software is an exercise in pain. Even when they don't outright break things, so often they've changed it, now it sucks.).
> 
> But all those glib whatevers really kill me.

You're right. Building GTK apps require 102 dependencies that may or may not be the exact version the app needs to actually compile. This is another reason I stay away from GUI apps. They're fat, require a veritable labyrinth of dependencies that may or may not work, and is bound to a GUI, generally in an unscriptable way. No thanks. Compiling, installing, and using a CLI app is far easier and in many cases more powerful. If I wanted the eye-candy, I'd go to Windows -- they have better eye-candy.

(Well, I did install Compiz with the 3D rotating cube interface once, just for some Linux fanboyistic bragging, but ... actually use that for my everyday tasks? Nah...)


> >On Windows, when installing stuff I used to always get messages like "this installer
> 
> That's not such a problem anymore since Vista. The system does some magic rewrites so those naughty programs think they are writing to system folders, but are actually pretty isolated.

Ah, figures. My wife's laptop is still running XP. *shrug* It does what she wants, and I don't see why I should replace it with new expensive hardware just so I can run Vista (or whatever), for no real added functionality. But it's good to know they finally got their act together.


> Still worries me on Linux though! "just run sudo make install", and trust you not to do anything wrong? Nope!

I *never* do that. I always tell it to install to a different non-system $PREFIX. If it can't, I just delete it outright (or, if I desperately need it, put it inside a chroot).


> On both systems, I don't like installing programs. Whenever I can, I like to keep the application in its own folder and run it as my limited user account only

Me too.


> (e.g., unzip dmd.zip, run ./dmd2/linux/bin32/dmd. it just worked! and any versions can live side by side! and it didn't overwrite anything else another program might rely on! WIN!)

+1. :) DMD seriously trumps gcc and its ilk in this area, by a looong shot. You don't realize what a flimsy fortress of cards gcc can be until you've tried to install it by hand. It requires 150 different files installed in 50 scattered locations (along with the 25 requisite ./configure parameters), and if even one of them is wrong, it won't work.

When the gcc makefile actually works (and it can be a real challenge to get it to this point, as it's a rather sensitive soul with very high and demanding standards), it does work like a charm. But when it *doesn't*, well ... you may not have any hair left after the ordeal, shall we say.

DMD, OTOH, is surprisingly easy to build, and can be run from just about anywhere. I usually just run it straight from dmd/src.


> >Having said that, though, linux *is* more geared to building from source than anything else
> 
> That'd be great if you didn't have to recreate the original author's environment on your computer, or wait seemingly forever for ./configure to run, then wait forever again for make to run, just to see if the program even does what you want it to do.

Yeah, autotools... that patch upon the patch to a broken bandage over a festering wound on a patch to a bandage over a primitive system stretched beyond its simplistic design... OK OK, I'll refrain from another build system rant here. :-P


> This is why my D programs usually just have a few files you can drop in. So I say "get my simpledisplay.d and color.d" and you don't have to install it, you don't have to download the same libraries I have, you just grab those two files and
> 
> dmd yourapp.d simpledisplay.d color.d
> 
> and boom, it *should* work. While I do have some other libs installed, various C headers and so forth, I think it is unreasonable to ask you, my user, to have all that too.

Speaking of which, dmd git HEAD appears to have broken terminal.d sometime recently... if you don't mind could you take a look at it? It's complaining about some template mismatch or some such. :-(


> If modularity and DRY are at odds, I prefer to err on the side of fewer dependencies.

Well, dub is proposed to be a solution to this kind of problems, but I haven't really felt the need to use it yet. So far, I've been OK with just downloading D libraries in some local directory and building stuff from source. But then again, I haven't gotten to the point where my D code is big enough and complex enough to face these kinds of issues yet, so who knows. *shrug*


> >but linux's customizability means
> 
> eh to an extent yes, but my custom window manager shouldn't mean your notepad program doesn't work. Maybe some special features won't be the same, but my preference in one location shouldn't break core functionality in another. There is a reasonable common denominator here - people don't customize their ELF loaders (much). They don't hack their kernels so the syscall numbers don't match. Those things actually work, so nobody really cares.
> 
> Why do people use other sound servers/modules or gui libraries? Because the default is broken. Not because they disagree, but because it is *broken*. So then everyone does their own fixes to work around it... and that leads to pain.

Yeah, sound servers have never worked well for me either. I don't even bother with them nowadays. I usually hate whatever sounds an app makes anyway, so if sound outright doesn't work, so much the better. As long as mpg123 / mplayer works, and I can listen to music of my own choice (instead of whatever dreary soundtrack or cartoon popping sounds the app author feels I must endure through), and as long as skype can pick up my voice and transmit the other person's voice, that's good enough.


> So it isn't end user customizability that cause the problem. It is mid-user patching a broken core.

I dunno, I find that ALSA works pretty well these days. It has come a long way since its original inception, when it would mysteriously fail to work for inscrutable reasons, and then just as mysteriously start working again upon the next upgrade. Most apps that interface directly with ALSA tend to Just Work(tm), whereas apps that expect this or that soundserver to be running generally *don't* work, or don't work very well.


> >Isn't this thread already [OT]? ;-)
> 
> yeah but it wasn't meant to be a rant thread! oh well.

Hehe... rant threads are fun! As long as people don't take them too seriously, that is.


T

-- 
What is Matter, what is Mind? Never Mind, it doesn't Matter.

On Fri, 13 Sep 2013 19:56:14 -0400
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote:
> 
> I guess that it's a matter of perspective. Personally, I find the Windows/DOS shell to be completely unusable and use git-bash when I'm forced to use Windows. Windows definitely has some things going for it (e.g. its graphics engine creams the horror that is X.org IMHO), but on the whole, I find that Linux is just way better for a power user like myself. Windows doesn't even come close to cutting it.
> 

While I definitely prefer bash to the windows prompt overall, there are some places where I think windows makes the linux cmdline look bad. Like launching a GUI program instead of a CLI:

Windows (nice):
% program-cli file.txt
% program-gui file.txt

Linux (wtf?!):
% program-cli file.txt
% program-gui file.txt >/dev/null 2>%1 &

But that's not always right - sometimes you need this instead: % gksudo program-gui file.txt >/dev/null 2>%1 &

But that's not always right either. On some systems it's:
% kdesudo program-gui file.txt >/dev/null 2>%1 &

Of course, Linux *also* provides many ways to do it *wrong*, which are naturally more convenient:

# Hangs your terminal until you close the gui app,
# which is so very useful an enormous 0% of the time:
% program-gui file.txt >/dev/null 2>%1

# Seems to work, but various warnings will be randomly
# spewed into your terminal while you're trying to use it.
% program-gui file.txt >/dev/null &

# Same as previous, but with more random spewings.
% program-gui file.txt &

# Wrong sudo (there are apparently good technical reasons
# you're not supposed to do this, even though it normally
# appears to works fine anyway)
% sudo program-gui file.txt >/dev/null 2>%1 &

On my Linux systems I like to stick these into one of my bin directories (trying to do this from memory, so I may not have it exactly right):

% cat gui
#!/bin/sh
"$*" >/dev/null 2>%1 &

% cat gsudo
#!/bin/sh
# Or kdesudo for KDE
gksudo "$*" >/dev/null 2>%1 &

Then it's just...
% gui kate stuff.d
% gsudo kate /some/system/file

...Until the next time I'm on a different unix machine and have to remember to use the full magic incantation again.

On Friday, 13 September 2013 at 19:48:18 UTC, Namespace wrote:
> Just out of interest.
>
> I use Sublime 2, Notepad++ and as IDE currently Mono-D. But I will try this evening VisualD.

Sublime Text 3 or TextAdept, 4 whitespaces as tab)))

On Fri, 2013-09-13 at 21:52 -0700, Walter Bright wrote:
> On 9/13/2013 8:48 PM, Andrei Alexandrescu wrote:
[…]
> > For the few souls who don't yet... http://xkcd.com/378/

Emacs FTW.

> I've used punch cards and paper tape. But I refused to use paddle switches.

So how did you get the paper tape or punch card loader in without first using the paddle switches? No paddle switch manipulation, no booted computer. :-)

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sat, Sep 14, 2013 at 03:28:14AM -0400, Nick Sabalausky wrote: [...]
> I love writeln debugging. I don't have to boot it up, configure it, learn about or task-switch my mind over to any new interface, or actively shy away from any opportunities that don't come with a fully-mature debugger (or wind up with my arms tied when I'm in the debugger habit and don't have a debugger available for whatever reason - in my experience, debuggers are reliance-forming drugs).
> 
> But the *best* thing of all with writeln debugging: Being able to examine the entire relevant execution forwards *and* backwards in time, all at a glance, with zero "stepping". Total win.
> 
> Any time I use a debugger I get sooo sick of having to reset and hit "step" a million times (or muck around with conditional breakpoints, which never seem to be intuitive - *if* they even work at all) every single time I want to see (or remember) what happened *before*. But with writeln - I already see the whole relevant trace at a glance, and all with exactly the same tools and interfaces I'm already using.
> 
> Writeln debugging rocks my world.
[...]

Hmm. Now that you put it *that* way... maybe I should stick with writeln debugging after all. :-P  You're right that the most annoying thing about having a "real" debugger is the fact that you can't step backwards. The only thing is, you have to recompile your program each time... but with D's compilation speed, it actually becomes a real alternative. Hmm.

One use case that has no writeln equivalent is stepping through assembly code when something REALLY screwed up, like when dealing with dmd codegen bugs. Though for that case, I did recently adopt the method of reading disassembly code listings. I've actually located and fixed several bugs in my work project this way (not with dmd, I mean, but with a C program). People will of course object that assembly is "too obscure to learn", "too hard", ad nauseaum, but I agree with what Knuth said once: if you don't know how the machine *actually* works, the programs you write will be pretty weird (i.e., far removed from reality). IMO the ability to read and understand assembly should be a requirement for every professing programmer.


T

-- 
If it's green, it's biology, If it stinks, it's chemistry, If it has numbers it's math, If it doesn't work, it's technology.

On Saturday, September 14, 2013 04:23:35 Nick Sabalausky wrote:
> On Fri, 13 Sep 2013 19:56:14 -0400
> 
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote:
> > I guess that it's a matter of perspective. Personally, I find the Windows/DOS shell to be completely unusable and use git-bash when I'm forced to use Windows. Windows definitely has some things going for it (e.g. its graphics engine creams the horror that is X.org IMHO), but on the whole, I find that Linux is just way better for a power user like myself. Windows doesn't even come close to cutting it.
> 
> While I definitely prefer bash to the windows prompt overall, there are some places where I think windows makes the linux cmdline look bad. Like launching a GUI program instead of a CLI:
> 
> Windows (nice):
> % program-cli file.txt
> % program-gui file.txt
> 
> Linux (wtf?!):
> % program-cli file.txt
> % program-gui file.txt >/dev/null 2>%1 &

I actually often find that convenient, because that means that I can get the output from a GUI program when I need it (generally when there's a problem with it). And if I want to run a GUI program but don't want any output to stdout, I usually just use Alt+F2 to start it (which works in KDE - as I understand it, other DEs have similar facilities). So, I rarely start GUI programs other than gvim from the command line. And gvim actually acts the way that you want. Oddly, it doesn't even require & to avoid having it take over the shell, which I have mixed feelings about.

And while I can understand your annoyance, I'd expect there to be more problems in general if GUI programs were treated differently than other programs when run from the command line. Then you'd have to have a way to get the CLI behavior for a GUI program when you needed it rather than having everything just work the same, wheras right now, you just have to learn one way of doing things.

But it is true that it's often the case that starting a GUI program from the command line in Linux results in a lot more output than you want if you're just trying to run it.

- Jonathan M Davis