On Tue, Feb 21, 2012 at 11:50:24AM -0500, Nick Sabalausky wrote:
[...]
> I literally grew up on command-lines[1]. But despite that, I still
> much prefer GUIs for anything a GUI reasonably works for: Like file
> browsers, DB admin, manual DB queries, debuggers, Tortoise*, etc.
> (although for web server configuration I've come to vastly prefer
> config files - MUCH easier to remotely manage, plus the settings for
> files/paths are necessarily tied to the file/path *name*, not the
> physical file, so you don't kave to keep messing with them every time
> something's moved/renamed/deleted/recreated)
OK, this isn't exactly GUI, but have you tried mc?
I remember in the good ole DOS days, Norton Commander (of which mc is a
clone) was one of the best things around. It made DOS usable. In fact,
even pleasant.
> When I'm on Linux, I've come to do most things on the command line
> just because 1. Many things still can only be done on the cmd line,
> and 2. Linux file managers suck about as much as the Windows command
> line. I'm proficient with bash, and I do love it as far as command
> lines go (And damn near anything can be scripted, which is fantastic),
> but I hate using it for file manipulation - just seems really clumsy
> compared to a *good* GUI file manager (which I've yet to find on
> Linux). Although the autocomplete *is* a huge help.
Yeah, you should check out mc. Though I haven't used it for at least a
decade, so I can't vouch for whether it's still usable. I've yet to find
a better file manager than the original NC, though.
> Although that said, even the Windows file manager has been plummeting
> downhill ever since Vista. I don't know wtf MS has been thinking.
I hate the windows file manager with a passion. It's so difficult to
make it display things properly, there's no way (not easily anyway) to
specify a glob filter in a huge directory, change sorting criteria with
a keystoke, etc.. I find `ls | grep` much more palatable than that
painful 1-pixel wide horizontal scrollbar that leaps several pages per
pixel when you're trying to find something in a truly huge directory, I
mean folder.
> Keyboard/mouse switching comes pretty naturally to me. Part of it's
> probably years of practice, and the other part is that I use
> trackballs which tend to mostly stay put.
I used to do a lot of keyboard/mouse switching too. Until I switched to
ratpoison, a window manager that doesn't require the mouse. Since then
I've found that my speed almost doubled.
Keyboard/mouse switching is much better when it's a laptop with that
"nipple" thing in the middle of the keyboard. In fact, that's the only
case of mouse-switching that is comparable in speed to a keyboard-only
interface. Unless, of course, you're trying to manipulate graphical
stuff like draw freehand curves, in which case you'll want to be on the
mouse 99% of the time anyway. For discrete tasks like typing or
navigating menus, keyboard shortcuts are unbeatable.
> [1] First AppleSoft BASIC and occasionally the built-in memory-editor
> and AppleSoft Logo. Later, MS-DOS 6-ish and occasionally gwbasic
> (normally used QBASIC instead, though)
[...]
Ooooh! Another Apple II veteran! Ah, the good ole Apple II. Believe it
or not, my dad actually still has a couple o' 30-year-old Apple II's
that he actually *still uses*. He wrote a little personal accounting app
in Dbase, and has been using it for the last 3 decades. Never felt the
need to upgrade. Of course, now he also has a modern-day laptop and
modern PCs in the office. But that old faithful Apple II is still
chugging away...
T
--
Береги платье снову, а здоровье смолоду.

On 21.02.2012 18:54, Benjamin Thaut wrote:
> Am 21.02.2012 04:08, schrieb torhu:
>> On 20.02.2012 22:36, Benjamin Thaut wrote:
>>> 2) Will dmd support exporting/importing data symbols from dlls? I know
>>> there is a patch that does the data symbol address patching from the
>>> runtime but thats a feature that should be supported by the compiler
>>> directly in my eyes.
>>
>> Importing data symbols works just fine both in DMD and GDC. At least it
>> did a couple of years ago. Can't remember if I've tried exporting, but I
>> wouldn't be surprised if it worked.
>>
>> You don't need to do anything special to get it working, just use
>> declare the data as 'export extern extern (C)' in your D code. For D2
>> prefix that with '__gshared'. Not very elegent, but it does work.
>
> I tried that but it does not work. For example compiler generatd data
> symbols like the module info or the vtable don't get exported even if
> the class is declared as "export" Also the tls storage does not work
> with threads across dll boundaries. And a lot of other stuff. I consider
> dll support working as soon as phobos is a shared dll.
I see. I assumed you were talking about linking with DLLs written in C.
I've never tried linking with a D DLL, except for maybe a simple test
case.

"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message
news:mailman.811.1329854653.20196.digitalmars-d@puremagic.com...
> On Tue, Feb 21, 2012 at 01:48:35PM -0500, Nick Sabalausky wrote:
> [...]
>> Another issue with it is that to make a binary work on both an older
>> and newer Linux, you have to actually compile it *on* an older Linux.
>> I've heard that, in theory, you can use a newer Linux to create
>> binaries that work on older systems, but in practice, nobody actually
>> knows how.
>
> Oh, there are ways to do that, sure.
> [...]
> This is arcane black
> magic that will explode in your face if you don't know what you're
> doing, unfortunately.
>
Exactly.
>
> [...]
>> Eeeww. I had no idea the shell did the expansion. That's just awful.
>
> Awful in some ways, powerful in others. Shell expansion allows you to do
> stuff like:
>
Actually, I specifically meant glob expansion.
I do think it's good that, for example, env var expansion occurs in the
shell - I can't imagine that working well otherwise. Quoted args should also
be handled by the shell:
$touch 'My Modern Filename.txt'
Speaking of cmdline args and argv, I've written this trivial 'showargs'
utility which I find indispensable for examining/experimenting/debugging cmd
line params:
----------------------------------------------
import std.stdio;
void main(string[] args)
{
writefln("args.length: %s", args.length);
foreach(i, arg; args)
writefln("args[%s]: '%s'", i, arg);
}
----------------------------------------------
$ dmd showargs.d
$ ./showargs ' hi world ' hi world '' x ' '
args.length: 7
args[0]: './showargs'
args[1]: ' hi world '
args[2]: 'hi'
args[3]: 'world'
args[4]: ''
args[5]: 'x'
args[6]: ' '
----------------------------------------------
Does something like that already exist in Unix that I've overlooked?
> mv myfilena{e,}me.ext
>
> to correct a misspelt filename, for example.
>
That's not a bad trick, I'll have to remember it.
> Me, I personally wished that instead of shoving all that functionality
> into the shell, they would've just provided a library that did these
> standard things so that programs could use them as needed.
>
For globs, at the very least, I definitely agree.
> IIRC, glob() was originally only implemented in the shell; it was only
> later that it actually became a library usable by other programs.
>
I see, that would certainly explain it then.
>
> [...]
>> Maybe I don't understand the way the package/dep managers work well
>> enough, but it always seemed bad to me that you can't do:
>>
>> $sudo apt-get install [url to an apt-compatible package]
>
> If you filed a bug on bugs.debian.org and ask nicely, somebody may
> implement that for you. :)
>
Yea, probably worth a shot... Actually, I wonder if aptitude might already
do it? (Hmm, doesn't look like it. At least if it does, the man page doesn't
seem to mention it.)
>> Linux is definitely groing on me more and more, but you're right, it
>> does have it's quirks.
> [...]
>
> The thing is, the *concepts* behind the OS are rock solid,
Oh yea, no arguments here.
> but the
> implementation suffers from decades of historical accidents that led to
> a working but sometimes quite counterintuitive system. For example, what
> on earth does "grep" mean anyway?! (Yes I know what it means. I'm just
> saying, it's a totally stupid name for that utility.) And "cat"? It that
> supposed to meow? And what on earth does "etc" stand for anyway, and
> what has it gotta do with configuration files?!
>
Agree again ;)
> Or my favorite syscall, creat(). Apparently in the old days there was
> only one E on the keyboard. Oh wait... :P
>
> There are also little flaws inherited from decades-old conventions that
> nobody dares break, lest existing code fail in new and mysterious ways.
> Or not-so-mysterious ways, like if you redesign the terminal protocol to
> be more in line with modern computing.
>
I think the way to do that would be to make it a completely alternative
protocol that software has to specifically choose to support. Sure, it's be
next-to-useless at first, but eventually support could build up to critical
mass and finally tip the scale. Similar to the approach of Wayland. (On the
other hand, IPv6 still isn't the de facto standard...)
> But whine as I may, I still love my Linux systems, both at home and at
> work. I know how to sing to their tune and make them dance. Whereas
> Windows just stares at me with a blue face.
>
For me, Windows is an old friend (or at least XP anyway) and I know how to
deal with it. But over the last decade my respect for Linux has slowly grown
and grown. I thought Linux was in a pretty bad state around 2001 and
temporarily wrote it off. But at this point, I think that if Linux had these
four things:
1. A nice GUI file manager I really liked (including TortoiseGit-style
functionality and Windows's quick image viewer).
2. A port of Programmer's Notepad 2 (or if I found something very, very
similar. I'm not an emacs, vi, or eclipse kinda guy. Normally I use kate or
gedit on Linux, but they're both still painful compared to PN2).
3. A good GUI SMART monitor comparable to Hard Disk Sentinel (not just
something with an utterly useless manually-polled interface).
4. A music library manager that worked like iTunes/WinAmp/Foobar2000 (but
hopefully wasn't shitty like iTunes and WinAmp and didn't have Foobar's
limitations).
There's a few other things that would be really, really nice to have too
(like a video player up-to-par with Media Player Classic HC, and DVD
Decryptor, DVD Shrink, and uTorrent...I *do* have totally legit uses for all
those!).
But those four main things listed above: I think those would probably be
enough for me to feel comfortable making Linux my primary OS and leave
Windows as my secondary. In fact, I really am itching for that to happen. In
the meantime, I've been considering giving MSYS/MinGW another chance. I've
had bad experiences with it before, but I've seen hints that things may have
improved since then.

"Nick Sabalausky" <a@a.a> wrote in message
news:ji0s7e$81a$1@digitalmars.com...
> "Adam D. Ruppe" <destructionator@gmail.com> wrote in message
> news:veaiisjzbijgdjbzwjif@forum.dlang.org...
>> On Tuesday, 21 February 2012 at 03:53:20 UTC, H. S. Teoh wrote:
>>
>>> Heh, never seen that before. I usually just turn off all fancy settings
>>> after installing a new system, and just stick with a bare-bones prompt.
>>
>> I like slackware's default of \u@\h:\w\$
>>
>> Simple, informative, reliable.
>>
>
> That's default on Debian and Ubuntu, too. And if you're root, the "$"
> changes to "#" (I think that's pretty common though...?).
>
> I used to find the "\u@\h" kinda pointless, especially the "@\h" part. But
> now that I'm dealing more and more with multiple machines/VMs/users, ssh,
> etc., I absolutely love it.
>
On other thing I meant to mention: It's kinda annoying on Linux how if you
launch a gui app at the command line, it will automatically be a blocking
foreground process unless you remember to add "&" at the end. Which I always
forget. And even then, a lot of GUI apps (most notably KDE) will flood the
cmd window with stdout/stdin. On windows, none of that happends: whenever
you launch a process from the command line it does the most useful thing
depending if it's a GUI or cmdline app. I had so much trouble getting used
to the Linus behavior I created a couple tiny scripts to help out:
$ cat ~/bin/gui
#!/bin/sh
"$@" > /dev/null 2> /dev/null &
$ cat ~/bin/guisudo
#!/bin/sh
gui kdesudo "$@"
I still have to remember to prepend each gui-lauching command with "gui " or
"guisudo ", but it works a lot better for me (except when the command I
typed doesn't exist and I don't get any message saying so).
Again, Linux's comand line totally blows Windows out of the water, no doubt,
but there are still a few niceities with Windows.
Another one is that in windows, it's possible for a batch script to export
env vars when it chooses too. Granted, it's done in an *extremely* sloppy
and haphazard way, and it shouldn't be the default, but at least it's
possible.
I totally understand the technical and hygenic reasons why Linux requires
scripts to be sourced for their env var exports to...well, be exported, but
the fact that it's impossible for the script to override that forces DVM,
for instance, to stick a "dvm" shell function inside '.bashrc'. Otherwise,
you'd have to remember to run it like ". dvm use 2.058" for it to actualy
work. On windows, when you type "dvm ..." it just runs an ordinary batch
file.

On Tuesday, 21 February 2012 at 22:26:34 UTC, Nick Sabalausky
wrote:
> On other thing I meant to mention: It's kinda annoying on Linux
> how if you launch a gui app at the command line, it will
> automatically be a blocking foreground process unless
> you remember to add "&" at the end. Which I always forget.
You can also hit ctrl+z in that terminal to pause the gui app,
then hit "bg" in there to move it to the background.
Tho it still spams the text iirc.
I kinda like how linux apps keep it though. It's just so
easy to throw in a printf() from time to time to tell something
to me without doing a popup window or something.

>Nick replied to something about globbing
Having programs doing the globbing sounds great until you run
into someone who doesn't play ball. *cough* every single digital
mars utility *cough*. I think Windows and unix both get it wrong,
but unix gets it less wrong (as it could theoretically be
annoying, but in practice I just escape it and move on, but
working around a non-globbing program is just annoying).
Wot I think should happen: the runtime (say libc) should handle
globbing of arguments, and it should be enabled by default. So if
someone wants an app that handles wildcards specially, they can
do that, but for most apps it'll just work™. I don't think this
really meshes with the traditional main signature of just passing
the strings as arguments. Perhaps just a non_globbed_args
function or something.
Buuuut things are pretty much set in stone at this point.

"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message
news:mailman.812.1329855805.20196.digitalmars-d@puremagic.com...
> On Tue, Feb 21, 2012 at 11:50:24AM -0500, Nick Sabalausky wrote:
> [...]
>> I literally grew up on command-lines[1]. But despite that, I still
>> much prefer GUIs for anything a GUI reasonably works for: Like file
>> browsers, DB admin, manual DB queries, debuggers, Tortoise*, etc.
>> (although for web server configuration I've come to vastly prefer
>> config files - MUCH easier to remotely manage, plus the settings for
>> files/paths are necessarily tied to the file/path *name*, not the
>> physical file, so you don't kave to keep messing with them every time
>> something's moved/renamed/deleted/recreated)
>
> OK, this isn't exactly GUI, but have you tried mc?
>
Umm, I don't *think* so, unless you count mcedit. For a breif while I used
mcedit as my preferred remote-file text editor, since it was text-mode (so
it worked through ssh) and was slightly better than nano/pico. But I haven't
had much need for it ever since I realized I could do this:
$sshfs user@domain:/ mount-point
$kate mount-point/remote-path &
I'll take a look though.
> I remember in the good ole DOS days, Norton Commander (of which mc is a
> clone) was one of the best things around. It made DOS usable. In fact,
> even pleasant.
>
Hmm, if that's like Total Commander on Windows, then I don't think I would
like it. I do *love* Total Commander's multi-file renaming, but that feature
is really the only reason I keep it around.
Heh, as bad as this might sound, I think what I basically want is more or
less Windows Explorer on linux ;) (Including the customizations I've
installed, like "DOS Prompt Here" and Tortoise*) And yea, Explorer works
under wine, but it's kinda like running a GTK app in Windows - but worse
since Windows GTK apps at least *know* what OS they're really running on.
>
>> Although that said, even the Windows file manager has been plummeting
>> downhill ever since Vista. I don't know wtf MS has been thinking.
>
> I hate the windows file manager with a passion. It's so difficult to
> make it display things properly, there's no way (not easily anyway) to
> specify a glob filter in a huge directory, change sorting criteria with
> a keystoke, etc.. I find `ls | grep` much more palatable than that
> painful 1-pixel wide horizontal scrollbar that leaps several pages per
> pixel when you're trying to find something in a truly huge directory, I
> mean folder.
>
Yea. While Windows Explorer is my favorite file manager, even I'll readily
admit it's not perfect:
- It keeps locking files/dirs for no apperent reason and keeps them locked.
- Sometimes it has a hard time in dirs with lots of files, especially in
thumbnail mode.
- Search is slow.
- It doesn't have a built-in "Extension" column, just that useless "Type"
column. There's a third-party extension to add an "ext" column, but it's
confused by zip files and it conflicts with the columns added by Tortoise*,
so in many folders, instead of my "ext" column, it often gives me this
useless "Product Version" column instead.
But implementation issues aside (which I've more or less gotten used to), I
like the basic UI itself a lot. In XP anyway. They really fucked up its UI
in Vista and 7.
>
>> Keyboard/mouse switching comes pretty naturally to me. Part of it's
>> probably years of practice, and the other part is that I use
>> trackballs which tend to mostly stay put.
>
> I used to do a lot of keyboard/mouse switching too. Until I switched to
> ratpoison, a window manager that doesn't require the mouse. Since then
> I've found that my speed almost doubled.
>
> Keyboard/mouse switching is much better when it's a laptop with that
> "nipple" thing in the middle of the keyboard. In fact, that's the only
> case of mouse-switching that is comparable in speed to a keyboard-only
> interface. Unless, of course, you're trying to manipulate graphical
> stuff like draw freehand curves, in which case you'll want to be on the
> mouse 99% of the time anyway. For discrete tasks like typing or
> navigating menus, keyboard shortcuts are unbeatable.
>
I like to call it the clit mouse. It beats the shit out of trackpads (I hate
those things with a passion), but I still find them a pain compared to mice
and my trusty Logitech trackball. So I'm the opposite of you there: I
actually find it much *easier* to switch between keyboard and trackball than
keyboard and "clit mouse" despite the increased distance. Maybe I'm just
weird.
>
>> [1] First AppleSoft BASIC and occasionally the built-in memory-editor
>> and AppleSoft Logo. Later, MS-DOS 6-ish and occasionally gwbasic
>> (normally used QBASIC instead, though)
> [...]
>
> Ooooh! Another Apple II veteran! Ah, the good ole Apple II. Believe it
> or not, my dad actually still has a couple o' 30-year-old Apple II's
> that he actually *still uses*. He wrote a little personal accounting app
> in Dbase, and has been using it for the last 3 decades. Never felt the
> need to upgrade. Of course, now he also has a modern-day laptop and
> modern PCs in the office. But that old faithful Apple II is still
> chugging away...
>
Wow. Nice. I have an Apple IIc in a pile on the floor here to my right.
Haven't had time to play with it in forever though. It's the same model I
grep up on (IIc), but not the same physical machine. *God* I wish I hadn't
sold my floppies along with my original system. I really wish I still had
all that old data of mine. Probably all gone forever now: Overwritten,
decayed, or in a landfill. :(
I'm actually a huge Apple hater ever since I got fed up with my 10.2 eMac
and the whole "Return of Jobs" world and product lines in general. But I
*always* consider Woz's Apple II line to be the big, giant, glaring
exception in Apple's portfolio.

"Adam D. Ruppe" <destructionator@gmail.com> wrote in message
news:bexfgnarfyprlvslmksn@forum.dlang.org...
> On Tuesday, 21 February 2012 at 22:26:34 UTC, Nick Sabalausky wrote:
>> On other thing I meant to mention: It's kinda annoying on Linux how if
>> you launch a gui app at the command line, it will
>> automatically be a blocking foreground process unless
>> you remember to add "&" at the end. Which I always forget.
>
> You can also hit ctrl+z in that terminal to pause the gui app,
> then hit "bg" in there to move it to the background.
>
> Tho it still spams the text iirc.
>
That hadn't occurred to me. Thanks. Normally, the only time I use fg/bg is
if I try to cancel something with Ctrl-blah and it suspends the process
instead of stopping it. So then I "fg [whatever num]" and either try a
different key combo or let it finish.
But still, I'd venture to say that probably 99.9% of the times you launch a
gui app from the command line, you don't want, or at least don't need, it to
be blocking or spamming the console. It'd be nice if it could do like
windows and detect "gui or cmdline" so it can automatically do the right
thing without the user coddling it. Unfortunately I'm not sure that's
possible since I don't think Linux binaries are flagged as "cmdline or gui"
like in windows. It just either calls some GUI apis or it doesn't.
That reminds me of another thing (yea, I know I sounds like I'm just ranting
on and on about Linux, but I *do* rather like it overall): What the hell is
up with this "sudo" vs "gtksudo/kdesudo" shit? I understand that it's
somehow necessary for the permissions/process-owner stuff to all be right,
but why should *that* be necessary? The whole Unix philosophy is
orthogonality, one tool to do one task well, no duplicated functionality for
slightly-different use cases. The whole "sudo" vs "gtksudo/kdesudo" thing
seems to be some sort of big ugly hack.
>
> I kinda like how linux apps keep it though. It's just so
> easy to throw in a printf() from time to time to tell something
> to me without doing a popup window or something.
>
Yea. I think though, that *those* cases are the ones for which there should
be some special way of launching the process. The typical case as the
default, the exceptional case as an option. Not the other way around.

On Tue, Feb 21, 2012 at 11:35:09PM +0100, Adam D. Ruppe wrote:
> On Tuesday, 21 February 2012 at 22:26:34 UTC, Nick Sabalausky wrote:
> >On other thing I meant to mention: It's kinda annoying on Linux
> >how if you launch a gui app at the command line, it will
> >automatically be a blocking foreground process unless
> >you remember to add "&" at the end. Which I always forget.
>
> You can also hit ctrl+z in that terminal to pause the gui app,
> then hit "bg" in there to move it to the background.
>
> Tho it still spams the text iirc.
You can do:
program_name >/dev/null 2>&1 &
That will silence everything. But yeah, too much typing, too much
obscure stdout/stderr redirecting for a newbie to even begin to dream
that such things are possible.
A good default behaviour (for the app writer) is to fork() at startup,
detach from pty in child, and then exit parent. A couple o' programs do
this.
> I kinda like how linux apps keep it though. It's just so easy to throw
> in a printf() from time to time to tell something to me without doing
> a popup window or something.
You can disable the fork() in debug builds (or with a -debug flag) so
that you can still get error messages out of it when something goes
wrong.
I'm pretty sure this is common knowledge, just that nobody bothers to do
it. But I can dream. :)
T
--
The two rules of success: 1. Don't tell everything you know. -- YHL

On Tuesday, 21 February 2012 at 23:35:09 UTC, H. S. Teoh wrote:
> That will silence everything. But yeah, too much typing
Yea.
> I'm pretty sure this is common knowledge, just that nobody
> bothers to do it. But I can dream. :)
Yeah, though I've only seen it suggested for daemon like
programs... I think you're the first person who I've seen
suggest it for gui apps too.
Not a bad idea.