February 21, 2012
On 2012-02-20 22:36, Benjamin Thaut wrote:

> 3) Am I mistaken or are most of the people here using dmd under linux?
> General bugs or linux only bugs tend to get fixed a lot faster then
> windows only bugs.

Mac OS X here.

-- 
/Jacob Carlborg
February 21, 2012
"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:epzlyfzibmpuoilawaqz@forum.dlang.org...
> On Tuesday, 21 February 2012 at 00:38:46 UTC, Andrei Alexandrescu wrote:
>> ssh into Windows and... well last time I did it it was like "welcome to Hell".
>
> Oh, certainly!

Does anyone suppose it would work better (or at all) to ssh into MSYS/MinGW? Anyone tried?

Also I'm curious: what sort of problems were there ssh-ing into win?


February 21, 2012
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.740.1329784653.20196.digitalmars-d@puremagic.com...
> On Tue, Feb 21, 2012 at 12:21:33AM +0100, Adam D. Ruppe wrote:
>> On Monday, 20 February 2012 at 23:12:36 UTC, James Miller wrote:
>> >Windows has not, historically, been a pleasant platform to develop lower-level code for
>>
>> I couldn't disagree with that more, especially if you're comparing to something like linux. The linux console is a big pain.
> [...]
>
> Weird. I guess I must be a very strange person, because I find that my productivity soars at the command-line, but when I'm forced to used Windows, productivity drops to 20% because of all that keyboard-to-mouse switching and clicking through endless layers of menus just to get one thing done.
>

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)

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.

Although that said, even the Windows file manager has been plummeting downhill ever since Vista. I don't know wtf MS has been thinking.

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.

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


February 21, 2012
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.

Kind Regards
Benjamin Thaut
February 21, 2012
Am 21.02.2012 10:06, schrieb Manu:
> On 21 February 2012 01:00, H. S. Teoh <hsteoh@quickfur.ath.cx
> <mailto:hsteoh@quickfur.ath.cx>> wrote:
>
>     On Mon, Feb 20, 2012 at 05:25:28PM -0500, Jonathan M Davis wrote:
>      > On Monday, February 20, 2012 22:36:49 Benjamin Thaut wrote:
>      > > 1) Is there a chance that dmd will support 64 bit on windows any
>      > > time soon? What are the issues currently with 64 bit support on
>      > > windows?  (optlink? backend?)
>      >
>      > Neither support 64-bit. So, the changes required to the toolchain are
>      > _far_ greater for 64-bit Windows than the Posix OSes. It'll come
>      > eventually, but probably not for a while.
>     [...]
>
>     Does gdc support 64-bit? AFAIK it should, since it uses the gcc backend.
>
>
> I use GDC in windows, and it's good. It's always up to date too, which
> is nice.

Do you build GDC yourself or are you using a precompiled version?
If you build it yourself which gcc source do you use?

Kind Regards
Benjamin Thaut
February 21, 2012
Unless things have changed dramatically in the past few years, SUA is barely usable though.  The shells don't behave the same way as their *nix equivalents and the API coverage is spotty at best.  If you really want to go the Posix on Windows route I'd suggest either downloading GnuWin32 (for tools that can be run from the Windows command-line) or Cygwin (for a full programming environment).  Having once made an attempt at porting a large Solaris app to Interix (aka SUA), I feel pretty comfortable in saying that native Posix support under Windows is there more to be listed as a feature for government contracts or whatever than because it's something anyone would actually want to use.

For SSH support, I'd suggest getting a client/server app from somewhere like Vandyke Systems, then maybe grabbing Windows PowerShell from Microsoft.  It will be a lot more effective than trying anything built-in.

On Feb 21, 2012, at 12:08 AM, Paulo Pinto wrote:

> They did, but Microsoft way as usual.
> 
> SSH in Windows, means making use of Powershell remote access. SSH is only meant
> for UNIX compatibility and it works better if SUA (UNIX personality) is also installed.
> 
> --
> Paulo
> 
> "Andrei Alexandrescu"  wrote in message news:jhupcv$2l7j$1@digitalmars.com...
> 
> On 2/20/12 6:41 PM, Adam D. Ruppe wrote:
>> On Tuesday, 21 February 2012 at 00:38:46 UTC, Andrei Alexandrescu wrote:
>>> ssh into Windows and... well last time I did it it was like "welcome to Hell".
>> 
>> Oh, certainly!
> 
> Rats. I was hoping the boys in Redmond have improved the situ since.
> 
> Andrei

February 21, 2012
"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:hmldxgffvfeyydarulig@forum.dlang.org...
>
>The ugly escape sequences showed through to the end user (me)!

I'm not as experienced in Unix as you are, but there's some smaller quirks I've noticed. For instance, if you're in the terminal and use the arrow keys while a foreground process is running (and not prompting for input) you'll get:

^[[D^[[A^[[C^[[B

Or if you hit any arrow key right before typing a password you're being prompted for, it'll think you meant it as part of the password and it'll fail.

>> But I agree with you though, that libc incompatibilities are really really REALLY annoying.
>
> Even worse is linux's binary incompatibilities.
>
> The dmd in the zip doesn't work out of the box on centos for instance... have to recompile it.
>

Yea, those binary/libc incompatibilities are a pain if you're used to the Windows world.

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.

>> That's more a bash limitation than anything, AFAIK.
>
> Yes and no. bash (and the kernel) is good about it now,
> but it is an effect of the unix design of the shell
> doing the expansion.
>
> rm *
>
> could have sent argv == ["rm", "*"], and your app
> simply done foreach(a; glob(argv[1..$])) { delete(a); }
> or whatever.
>
> But, unix decided to do this in the shell. Which isn't
> all bad, it has some nice effects.
>
> But, run that in a folder with 20,000 items, and you send 20,000 strings in argv...
>

Eeeww. I had no idea the shell did the expansion. That's just awful.

>> Most distros do distribute prebuilt binaries, but if your app isn't part of the distribution, things get tough.
>
> Aye, or if the version you need isn't in there. centos,
> I'm looking at you!
>

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]

Or whatever the yum equivalent would be.

Erm, at least, I don't *think* you can...Maybe I'm wrong? In any case, having to mess with the sources list sucks.

Linux is definitely groing on me more and more, but you're right, it does have it's quirks.


February 21, 2012
"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.

>
> But, one of the sysadmins I worked with fell in love with
> colors. I still have access to one of his systems, let
> me pull this up... this system is slow! come on...
>
> Here we go:
> # echo $PS1
> \033[0m\033[36mname\033[34mredacted\033[0m#
>
> Two different colors forming the system's name! And no useful info. This isn't a prompt. It's a logo.
>

Hmm yea. I never could stand prompts that didn't at least include the working dir.

It's pretty though! Crap, now I want to color-code the user and host parts of my prompts...Especially for root and live production servers, that could be downright useful: Big bright right "This is ROOT!!!", or "This is LIVE PRODUCTION SERVER!!!" staring you in the face.

>> Only seven years? ;-) I've been at it for several years longer.
>
> I'm relatively new but just as grizzled :-)
>

I started about 11 years ago, but only on an occasional basis (and there was a big gap of a few years in the middle). It's been nowhere near permanent day-to-day (though that's slowly changing). So I'm practically a newbie by comparison.

>
> Fond memories here of video mode 13h too. That was
> easy programming, and good speed too, even on those
> old computers.
>

God yes.  0xA0000 forever! :)  And on a related note, long live Future Crew!

> When I finally switched to coding for these
> newfangled multitasking OSes, it took a long time
> to get used to not having my precious memory map.
>

I remember that playing high-end games in Windows (thanks to GameSDK/DirectX) just felt very weird. Took some getting used too.

Actaully, even now I'm not a real huge fan of it. The multitasking can still cause stutters and such that never occur when games are able to take over 99% of the system.

>
> With Linux users, there's always some list of third
> party stuff they need too. dmd, qt, whatever, but
> always something.
>

I had loads of fun with dependencies when I tried to compile Git from source a few weeks ago. (Not as bad as pre-yum rpm's though.)


February 21, 2012
"Nick Sabalausky" <a@a.a> wrote in message news:ji0s7e$81a$1@digitalmars.com...
>
> It's pretty though! Crap, now I want to color-code the user and host parts of my prompts...Especially for root and live production servers, that could be downright useful: Big bright right "This is ROOT!!!", or "This is LIVE PRODUCTION SERVER!!!" staring you in the face.
>

"Big bright right..." == "Big bright red background..."

I don't know how the hell I managed that typo...


February 21, 2012
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.

You can always make a chroot and install an old version in it, then do your compilation there. Disadvantage: it's a major pain to move files back and forth and get the compiler to be installed properly in the chroot. You can't (easily) just build everything in your source tree, since the build has to be run under the chroot.

Or you could build a cross-compiler and fiddle with gcc path settings to coax it to link to old libraries instead. Or if you're brave, build a multi-target compiler. But you still have to deal with coaxing the linker to find older libs instead of new ones. This is arcane black magic that will explode in your face if you don't know what you're doing, unfortunately.


[...]
> 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:

	mv myfilena{e,}me.ext

to correct a misspelt filename, for example.

But shell expansion also forces you to write \\\\0000 instead of \00, so I can't say with a straight face that it's definitely a good thing.

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.

IIRC, glob() was originally only implemented in the shell; it was only later that it actually became a library usable by other programs.


[...]
> 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.  :)


> Or whatever the yum equivalent would be.
> 
> Erm, at least, I don't *think* you can...Maybe I'm wrong? In any case, having to mess with the sources list sucks.

For isolated packages I find online, I usually just do this:

	wget http://server.com/path/to/package.deb
	dpkg -i package.deb

Mission accomplished.

Well, provided there are no nasty dependencies. :) If there are, there's currently no choice but to edit /etc/apt/sources.list.


> 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, 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?!

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.

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.


T

-- 
Only boring people get bored. -- JM