131–137 of 137 posts
Earlier quoted context omitted.
> So what is the bootstrap process going to be? Other than already have a Go compiler I mean. Or is it have a Go cross compiler? What's the bootstrap process for the C compiler part of the compiler?
The is no C code in the compilers anymore.
Earlier quoted context omitted.
You can't avoid trusting trust. "Ken was here" :)
You can. You just have to bootstrap all the way up.
So what is the bootstrap process going to be? Other than already have a Go compiler I mean. Or is it have a Go cross compiler? Maybe it matters less, you used to always assume bootstrap from C but that more or less died with C++ based compilers, although you can do a multistage bootstrap from the last gcc before C++ still.
Probably gccgo, which is included in gcc.
Earlier quoted context omitted.
Care to explain what's gross about MSYS2/MinGW-w64? I'm genuinely interested in making it less gross.
Want to make it less gross? Make it completely go away . Installation of Go or Python is just like any other Windows install. You download an installer.exe or .msi, run it, and you're done. Things compile or run immediately, and you don't have to start using a "special" terminal just for it to work. My experience with MinGW is very different. Especially for dependent languages. "Step 1: Install MinGW" what does that…
You seem to be confusing mingw.org (http://www.mingw.org/wiki/getting_started) and MinGW-w64 (http://mingw-w64.sourceforge.net) and your rant seems entirely directed at mingw.org.
The software distribution I was asking the parent poster about is MSYS2 (http://msys2.github.io/ and http://sourceforge.net/projects/msys2/), do please come back with constructive criticism on that project if you are interested enough to investigate further.
Earlier quoted context omitted.
Care to explain what's gross about MSYS2/MinGW-w64? I'm genuinely interested in making it less gross.
Yes, I'd be happy to, but I'm not sure they are "solvable" issues, because they seem to be more of architectural mismatches. Part of the issue with most software that uses MinGW is that it is written with posix-y operating system in mind. That is, operating systems that can very efficiently fork processes and quickly deal with many small files. Unfortunately, Windows does neither well. Process creation is slower, and…
With Git, I can clone very large projects almost as quickly with MSYS2 as I can ArchLinux. We did begin to port msysGit (the native, non-MSYS executable, yeah, go figure) to MSYS2 and found very little speed improvement so stopped since the msys2 version is much more functional and always up-to-date.
Using Autotools on MSYS2 isn't significantly slower than on GNU/Linux. You can try building any of the many Autotools based projects we provide to see this for yourself. Besides, for software which relies on Autotools for it's build system, there's no choice but to use it (outside of cross compilation).
That NTFS (and the Windows filesystem layer) isn't fast is independent of MSYS2 vs native Windows anyway.
An anti-virus will slow down all Windows tasks to an unusable crawl, just run your scan overnight and take care about what you click on. MSYS2 isn't hit worse than, say Visual Studio. Fundamentally MSYS2 is software distribution who's end product is native Windows applications aimed at the user. The POSIX stuff exists just helps us get there (this is why we don't provide X Windows; if you want that, use Cygwin), so for example using Qt Creator as supplied by MSYS2 should give an experience that's roughly the same as using Qt Creator supplied by the Qt Project (but much easier to maintain).
Apart from for installing and updating packages, you can avoid the MSYS2 console and just run programs in C:\msys64\mingw64\bin.
The security advantages we bring via shared packages (e.g. libraries) are very worthwhile.
> Trying to deal with SSH through bash and msys is not a user friendly experience. PuTTY is the gold standard of SSH clients on Windows.
Since on MSYS2, things are shared, your SSH keys are shared between all applications that use them in ~/.ssh, as you'd expect. I use mklink /D to unify my Windows User folder and my MSYS2 HOME folders (be careful not to use our un-installer if you do this though, if follows the symlink :-(). We do have putty but I haven't checked that it doesn't use %AppData% or worse, the Windows registry to store keys. If it does that's a bug we'll fix. To install putty:
$ pacman -S mingw-w64-x86_64-putty
Earlier quoted context omitted.
Want to make it less gross? Make it completely go away . Installation of Go or Python is just like any other Windows install. You download an installer.exe or .msi, run it, and you're done. Things compile or run immediately, and you don't have to start using a "special" terminal just for it to work. My experience with MinGW is very different. Especially for dependent languages. "Step 1: Install MinGW" what does that…
I was asking about "MSYS2/MinGW-w64". You seem to be confusing mingw.org ( http://www.mingw.org/wiki/getting_started ) and MinGW-w64 ( http://mingw-w64.sourceforge.net ) and your rant seems entirely directed at mingw.org. The software distribution I was asking the parent poster about is MSYS2 ( http://msys2.github.io/ and http://sourceforge.net/projects/msys2/ ), do please come back with constructive criticism on tha…
Earlier quoted context omitted.
I was asking about "MSYS2/MinGW-w64". You seem to be confusing mingw.org ( http://www.mingw.org/wiki/getting_started ) and MinGW-w64 ( http://mingw-w64.sourceforge.net ) and your rant seems entirely directed at mingw.org. The software distribution I was asking the parent poster about is MSYS2 ( http://msys2.github.io/ and http://sourceforge.net/projects/msys2/ ), do please come back with constructive criticism on tha…
You're correct, my complaints were towards mingw.org, not MSYS2. My apologies for not reading carefully enough. I may actually take a look, thanks for directing me.
http://www.reddit.com/r/cpp/comments/2v6vlg/decission_which_...