On Sat, Sep 14, 2013 at 06:32:07AM -0400, Nick Sabalausky wrote:
> On Sat, 14 Sep 2013 00:34:07 -0700
> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
[...]
> > 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
> 
> I had no idea you could do that! That's fantastic: despite my migration towards Linux, I had been worrying about the day I'd inevitable have to deal with multiple versions of the same thing.

In spite of all my rants against autotools, it *does* let you do cool things like:

	./configure --prefix=/path/to/my/dedicated/sandbox

which, if things were properly put together, will setup the Makefile such that make install will install to /path/to/my/dedicated/sandbox instead of the usual system directories.

Of course, then you need to setup $PATH and maybe a few other environment variables expected by the app to get things to work properly, but this is the way I usually like to install custom built-from-source apps. That way, should I want to uninstall it, I can just nuke the entire root directory dedicated for that app without damaging anything else. :)

But wait, there's more...

On Debian, a good number of library packages are actually *designed* to support installation of multiple versions simultaneously. Even fragile, sensitive giants like gcc that have an intricate web of library dependencies can have 4.6, 4.7, *and* 4.8 all installed together side-by-side (up to a certain point, of course). A good many libraries have been patched downstream by Debian developers to have proper soname correspondence with ABI changes, and the upstream version number is encoded into the package name (as opposed to just the package version number) so installing multiple versions of the same library is actually *officially* supported.

So the above prefix trick is really only necessary if you're building the library yourself.


> > > 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.
> > 
> 
> I find GUI apps to be butt-ugly under wine ;) But often usable
> otherwise (not that I've used it much so far).

I suppose so. Well, fair enough. :)


T

-- 
They pretend to pay us, and we pretend to work. -- Russian saying

On Sat, Sep 14, 2013 at 04:49:23AM -0400, Nick Sabalausky wrote: [...]
> > and as long as skype can pick up my voice and transmit the other person's voice, that's good enough.
> > 
> 
> Is the Skype software any less dreadful on Linux than it is on Windows?

Nope. It's worse, actually. Linux support is spotty, and there have been debacles where Linux support was under consideration to be dropped. Fortunately, they didn't. But it tends to fall behind the Windows version, so weird quirks may pop up every now and then. Plus, it's *still* a 32-bit app. :-(

Having said that, though, the latest incarnation of the Linux version actually has native Debian packages, which makes the ordeal a lot less painful than before, when you have to manually hunt down dependent libraries.


> It used to be that even the close button doesn't work properly, *by design*. But last I looked, the damn thing no longer even *allowed* you to end the glitchy resource-draining process *at all*. And that's just one small aspect of the program.

Fortunately, in Linux there's 'killall -9 skype'. :)

Well, that's usually not necessary, since selecting "exit" from the main menu (as opposed to merely closing the window) actually does logout *and* terminate the skype process.


> I love the Skype service, but (at least on windows) the software seems committed to forging new ground in "crapware". The android version didn't seem nearly as bad though, but even that had a *lot* of user comments posted about its overall quality and reliability taking a steep nosedive. That was about a year ago though.

You will probably not be very pleased with the Linux version either, then. :) But at least, recent versions have gotten their act together and can now do a saner job of detecting your camera/microphone devices. It used to be very unreliable and required lots of manual tweaking and babysitting.


T

-- 
Public parking: euphemism for paid parking. -- Flora

Am 14.09.2013 12:19, schrieb Iain Buclaw:
>
> ...
>
> As for your wireless driver woes, I'm sure you still had the choice to
> go for the proprietary drivers, which would mean you have to also
> blacklist the OSS one (done this plenty in the past, except for
> resolving conflicts with OSS drivers that think they can talk to the
> same device, but one gives me 1m wireless AP scanning range, and the
> other 30m :)
>
> Regards
> --
> Iain Buclaw
>
> *(p < e ? p++ : p) = (c & 0x0f) + '0';
>

Wrong. If you want I can provide the Ubuntu forum discussion.

Due to the kernel changes done for the open source version of the broadcom driver, to keep using the binary blob on my laptop, I would need to reflash the wireless card with new firmware.

Additionally, not everyone was having success with it.

So, I was forced to use either ethernet cabling, or only talk to IPv6 routers until June, which was the tim the open source driver reached feature parity level with what I already had in April.

Thankfully it is not my primary laptop.

I am not a Linux newbie, I have been using it since kernel version 1.0.9.

I just don't have the time to keep tuning the system as I used to,
nor do I want to.

--
Paulo

On Sat, 14 Sep 2013 02:39:05 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> 
> UIs should be
> *programmatically* specified in such a way that they are logically
> consistent in layout *regardless* of environmental factors such as
> screen resolution, font dimensions, etc..
> 

That's exactly why I hate CSS for layout.

Although I found Visual C#'s WYSIWYG GUI editor (and even MS's stuff as far back as Visual Basic 3) to make it fairly easy to make things adjust properly. Probably because Win32 (like other GUI systems) is designed for things like docked widget containers and auto-resizing main content.

That said, it does still make it easy for bad designers to do things the wrong way. But then, the same is true for programmatic layouts.



> > > > - graphical representation of code relationships
> 
> std.d.lexer + graphviz
> 

I think another layer on top of graphviz might be needed for that to really be comparable. I've played with graphviz's DOT format a little bit and found that it often takes some thought and tweaking to make non-trivial graphs that are particularly good (and not gigantic).

Plus, to my knowledge (I could be wrong), I don't think it has any way to generate interactive graphcs - graphs that you can drag parts around to make it look good. Just static images, AIUI.


> > > > - visual XML tooling
> 
> What would that be for?
> 

For indulging MS's XML obsession ;) j/k


> > > > - background compilation showing where there are issues
> 
> Waste of resources. I hate it when programs (including IDEs) try to be "smart" and point out perceived problems that may or may not be real problems. The compiler already points out the *real* problems when I decide to compile the code anyway; having an IDE actively try to point out the fact that my code doesn't look like code yet (because I'm still thinking over various implementation possibilities) is very disruptive to my thought processes.  I prefer to doodle possible implementations until I mold it into possibly-compilable form first, *before* I even consider running the compiler on it.  An IDE to consume system resources while annoying me? No thanks. Let Clippy rest in his grave, don't bring him back from the dead.
> 

I actually found it nice in Visual C#. Although I think it did occasionally annoy me with complaints about stuff I was still typing (unless I'm thinking of VB6...), and I definitely don't find it worth the cost of occasionally laggy text-editing.


> > > > - map failed unit tests to code lines
> 
> Er... isn't that what AssertError line numbers are for?
> 

Yea. My code editor uses a (optionally customizable) regex to grep for any "filename(line_number):" lines in the output panel. It converts them to "jump to that line in the source" links. That'll work for any tool, unittest, compiler, whatever. So this is not something that requires a full-blown IDE.

> > 
> > - Basic editing that's solid, fast, robust
> > - Highlighting
> > - CLI compiler
> 
> For me, I can dispense with the second item. :) Give me vim and a command-line compiler, and I'm good to go.
> 

Heh, I can go without it for short periods of time if I really need to. (I already do any time I use my source-diffing program.) I'm so used to it though, I find it very difficult to visually parse non-highlighted code in anything that isn't a pure data langauge (and even then it helps).

> 
> > I've had to debug things using as little as one LED. So printf debugging is perfectly comfortable to me, and I've gotten to the point where I even find it preferable to a full debugger in many cases.
> > 
> > The rest is just icing (or gravy if you prefer).
> 
> It's funny, the more years I spend coding, the less I found myself using the debugger. Nowadays my debugging approach is approximately:
> 
> 1) Code inspection: based on the bug description / known steps to reproduce it, locate the general place in the code where the problem is likely to be, and thoroughly audit that piece of code for problems. Roughly 30% of the time, the bug would be found this way, and quite often, other not-yet-found bugs would be discovered too. So it's quite worth the effort before we even use any real debugging tools.
> 
> 2) Printf/writeln debugging: mainly to determine execution path on the way to the problem, by strategically placing printfs/writelns at branch points and before/after loops, then refining it to loop bodies and functions down the call tree as the location of the problem reveals itself. Once the malfunctioning piece of code is identified, then start to dump variable values, etc., to ascertain the cause of the problem. This actually covers about 60% or so of the cases I've encountered.
> 
> 3) Use a debugger. I find myself doing this only about 10% of the time. And out of that 10%, 9% is just to get stack traces from segfaults, and only 1% is really using the debugger for stepping through code.
> 
> All in all, writeln debugging is pretty effective, for all the stigma against it.
> 

Yea, I use pretty much the same approach, although my proportions might
be a little different. I've become so accustomed to printf debugging
(a habit developed through too many situations where no real debugger
was available), that even when I should fire up a debugger I try to
push through with printf-approach anyway because "Ehh, I don't feel like
trying to remember how to hook this up to a debugger..."

Plus I've been dev'ing on windows, so instead of segfaults, D throws an Error and gives me a stack trace :)

Developing in any situation (not necessarily D) where I *don't* get stack traces is a PITA. Of course, printf debugging usually works there too, but it feels much more painful when I'm thinking "Ehh, I have to do this just because I'm not being immediately spoon-fed the stack trace? This blows!"

> > 
> > Yea, the basics of code editing are the real #1 thing. If I can't "be one with the cursor and text-edit control", so to speak, then no amount of extra features can make up for it. (Of course, for me that means *not* vi, although I just haven't cared enough to get through the learning curve - but that's just me.)
> 
> I utterly hated vi(m) until I actually tried learning it. Then I found that the "be one with the cursor" approach is actually less effective than vim's "describe your edits in a *language* involving verbs, nouns, and adjectives, not just point and grunt" mindset. Nowadays, I actually find other editors rather crude for my tastes. They're too focused on the character-by-character motion of the cursor and the WYTIWAG (what you type is all you get), whereas vim lets you speak to it in a far more expressive language.
> 

Well, "be one with the commands" in that case ;) Or "be one with the keyboard", which is still critical for me, too: I feel like I'm running through sand when I have to code with a built-in laptop keyboard (especially because of the lack of *proper* arrow/home/end/del/page keys, but also just the overall size/shape/feel of the keys).

I really can believe what you're saying about vi. Personally though, I just haven't felt much of a need or desire to really give it a chance anyway. And (in a small way) I almost don't want to like it - I'm already in the minority on enough things ;) Maybe I will someday out of curiosity, I dunno.

The "counting words/chars/lines" in particular seems rather off-putting to me though. Ex: I like to just Ctrl-Left/Right across however many words I need and don't really want to start caring how many words/lines away something is.

On Saturday, 14 September 2013 at 08:23:54 UTC, 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 &
>
> 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.

You are either dishonest or a complete morron. By respect for you, I'll pick the first one.

On Sat, 2013-09-14 at 09:53 +0100, Russel Winder wrote: […]
> OK Vim beats Emacs on that one, for Emacs it Esc 1 2 Ctrl+Down, 4 keystrokes.

Of course Vim is completely unusable since it relies on using monospace fonts, where everyone one knows that reading is best done with proportional fonts.

<yes-this-is-a-bit-of-an-intentional-troll/>

:-)


-- 
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

I never thought that this becomes a discussion about windows versus linux. :o

On 14 September 2013 04:36, Adam D. Ruppe <destructionator@gmail.com> wrote:
> On Saturday, 14 September 2013 at 02:59:49 UTC, Iain Buclaw wrote:
>>
>> Unless you enjoy spending hours on end removing viruses from your system. :)
>
>
> Meh, do you actually review the source of everything you compile? I betcha if I made a makefile
>

Bit of a trick question, as I get sources from either distribution repositories or ftp.gnu.org - both considered to be a trusted source that wouldn't have that problem.  So if you made a makefile, chances am I wouldn't use it.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Sat, 14 Sep 2013 01:40:30 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> 
> 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.
> 

Exactly. And I totally understand the focus on debuggers in the C/C++ world, just because of that.

> 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.

Yea, that's true.

> 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.
> 

Yea, I agree. Once I graduated from "just playing around in BASIC", the stuff I really started out with was indie/homebrew videogames. This was back at the tail end of the DOS days, so direct hardware access, the occasional ASM and a frequent focus on optimization were just the normal way of things. Once I moved into higher-level stuff, I always felt that understanding was still a big benefit.

I've come to think about it in terms of a more general principle, a corollary to the law of leaky abstractions:

To *truly* be good in any endeavor, you need to have a good understanding of not only that, but also whatever abstraction is directly underneath.

To be good at high-level code, you need to understand a thing or two
about low-level code. To be good at low-level code, you have to end
up picking up a bit of digital EE. I've actually studied a little bit of
digital EE and although I'm no expert, I can tell you that analog EE is
critically important to being good at digital EE. And I'd be willing to
bet chemistry would be a crucial ally to any really good analog
electronics expert. Going the other direction: To be any good at
designing software, it would be important to know at least something
about high-level code.

And it's not just computers/electronics, it's other things: Top-of-the-line athletic training these days (sports, martial arts, dancing, whatever) involves a lot of very explicit attention to biology and newtonian physics.

On Saturday, 14 September 2013 at 07:28:33 UTC, Nick Sabalausky wrote:
>
> 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.

Give me a way to writeln the callstack frames at a certain point, and I'll take that: until this, I still need a debugger for following the program flow.

And no, adding a writeln everywhere you call that function is not a solution.

- Paolo