Hacker Newsnew | comments | show | ask | jobs | submit | login

Not quite. You can map shared folders to the guest and edit the code in the VM with your favorite editor, but build it on Windows.

reply


Look at Nix & NixOS: http://nixos.org/ It would be interesting to see a comparison of Bazel/Blaze to Nix.

reply


Stupid question: Why does Xen need to emulate x86?

-----


tl;dr, Windows. But also various limitations of how PV or HVM hosts work.

PVH fixes it so you don't need emulation in Linux, but it's a brand new feature and probably not production quality. Read this (it's not too technical) http://wiki.xen.org/wiki/Virtualization_Spectrum

As of this writing, Xen 4.4 and Linux 3.14 have experimental support for PVH DomUs and Xen 4.5 has support for PVH Dom0s. PVH allows practically native-hardware-speed guests without any emulation.

-----


Completely eliminating emulation isn't always desirable, unfortunately. The problem with PVH is the forcing the use of event channels to deliver interrupts.

Local APIC emulation is fully accelerated on modern processors, which is a big win for any use case that is heavy on interrupts.

-----


In extreme cases, I combine templates and macros to achieve the desired conciseness of code. Templates are powerful, but often a lot of verbosity/boilerplate is still needed, where macros may come in. That is usually in a basic form as described in this article (one can do much more advanced stuff with macros e.g. google X macros).

Just to annoy you I'll show some code of mine. It's a compile-time expression wrapper. Code: https://github.com/ambrop72/aprinter/blob/master/aprinter/me... Test: https://github.com/ambrop72/aprinter/blob/master/tests/expr_...

-----


Before becoming suitably annoyed at your preprocessor magic, which I will examine shortly, I would like to point out one example I had in the back of my mind when I wrote my comment: just google lttng/tracepoint.h. It just seems to me like a terrible hack.

Of course, if you want to criticize templates and meta-programming (as an alternative to pre-processor), there are many jaw-dropping examples in Boost, V8, etc. I can remember several late-night sessions wrangling with (Boost) serialization code, and the cryptic multi-level warnings that ensue. Those were bad times.

I always figured that the answer would be a language/tool simple enough that a serious programmer could, without heroic effort, manage to customize to his needs over a weekend.

Sadly, it appears that the language lawyers have gone insane, and the trend appears to be entirely opposite (with the recent developments in C++0x/C++11/C++14).

For background: I was a big fan of Visual Studio (when working in games and finance), but my most recent posting precludes developing in Windows, and then porting to Linux for deployment. Looks like most people (at this posting) are doing printf-programming, relying on logs to see what happened (in debug builds). It's hard (within our current heterogeneous environment) to setup gdbserver + Eclipse or some other gdb client on a Windows front-end (which we need for administrativia).

The point is I miss being able to just set breakpoints, launch the program and inspect program state on the fly, as a means of learning the behaviour.

I have cared enough about all this, and used to eagerly await the day that MS would open-source the C++ AST/Intellisense engine, opening the door for programmers being able to perform complexe refactorings with relative ease. Maybe I should just but the whole-tomato software, or some other tool. These days, I am following Clang developments with interest and hope.

FYI, I think the ultimate annoyance is some Linux fanboy who doesn't "believe" in C++ or IDEs, but who is too young to remember when GUIs were not even an option, that text mode was all you had. I am surprised at the resurgence in TUIs (and the longevity of some CLIs). Sure, C++ has its warts, but RAII is better than gotos (here, I am conflating the kernel developer's aversion to C++ with the likelyhood that he/she uses vi, or some other console-based editor).

Sorry for the confused monologue. I'll check out the code later.

-----


Inspecting program behaviour via the debugger has always been an uphill battle in C/C++. Sometimes you're working on something where the bug only surfaces in release builds (because the debug build isn't optimised enough and the program runs too slowly to trigger it). Good luck debugging when half the function arguments read "optimised out" and program execution jumps around randomly because the compiler reordered your code for efficiency.

One thing I've always dreamed of is having the compiler emit source for the assembly it generated. So you can attach the debugger and see the code as it actually is, rather than as it was when you wrote it. I love how in Java my code gets optimised by the JIT, but once I start debugging all the optimisations come off (but only once I need to see the source) and what I see is what is running.

-----


I fully agree with you.

Using IDEs since the Amiga/MS-DOS days, Devpac, all Turbo languages and so on.

Getting half-decent IDEs in UNIX has always been an uphill battle.

And no, vim and Emacs just get one half-way there, even after stacks of ELisp code.

Although nowadays there are at least KDevelop, Eclipse, Netbeans, QtCreator to pick from.

As someone that started coding in the 80's, I also don't get this attitude of doing PDP-11 style programming.

My solution is to choose projects that allow me to use modern tools.

-----


If you just want the number: dynamic is 6x slower.

-----


Not a good summary.

1. If the static method is trivial enough, the compiler can inline it removing the need for a function call. In that case, a virtual function call for a single increment op is 6 times slower.

2. If you disable inlining for the static method, curiously it is 1.5 times slower than the virtual function call.

3. Newer compilers have devirtualize that the OP could not test but should be able to give much better than the 6x degradation.

-----


That is with gcc -O2 (version 4.8) on an i7-4771 CPU

With -O3 the speedup is even more: 7.2x

on a Xeon E5-2690 (Sandy Bridge) with gcc 4.6.3 (same code generated) it was "only" 3x

-----


... with older compilers, without -fdevirtualize.

-----


Clang docs & release notes: http://llvm.org/releases/3.6.0/tools/clang/docs/ (these are a bit hard to find)

-----


Thank you but I like NixOS & nixops too much.

-----


I do too. What do you think about Guix?

-----


Huh, I've never bothered. NixOS & Nix do what I need, and are much more developed.

-----


Guix needs a NixOps equivalent. It's on my TODO list. Help wanted!

-----


I see zero problem with using SSH, which happens to be a pretty secure protocol. In fact I would prefer it to HTTPS since it is not by default vulnerable to malicious CAs. Note for example that GitHub allows Git access over SSH.

When the author says that the system "exposes the private key", well, it's by design that the user can see it - since they need to use it to identify themselves to the SSH server. It's not much different from being assigned a password by the server. What could be improved is if it was transferred over HTTPS rather than HTTP, and of course also the install script.

(I only speak about the usage of SSH, it's possible that they still do something insecure..)

-----


> it is not by default vulnerable to malicious CAs

Well, in this particular case, they're using

  ssh [..] -o 'StrictHostKeyChecking no' -o 'UserKnownHostsFile /dev/null' [..]
So the remote authentication bits are already out the window. It would be nicer if they included the host's public key in the installation package rather than eschewing it completely.

-----


Indeed, they're just using it wrong.

-----


> When the author says that the system "exposes the private key"

To be fair the author didn't, the submitter did. I'm not sure if they are the same person.

-----


This has nothing to do with "accumulating crud", it's a trivial thing, there's probably less code needed to not treat 0.0.0.0 differently. Also, the amount of people who have ever typed 0.0.0.0 into a browser is so small that it is virtually irrelevant what they do, and whether there is consistency between browsers.

-----


But this is treating 0.0.0.0 differently. Did you not read the bug report, or the comments here, or anything? 0.0.0.0 is not a valid address. In fact, navigating to 127.0.0.1 when 0.0.0.0 is given in the URL is neither expected nor desirable.

-----


Just don't sign in? I don't feel being pushed into anything. If you're annoyed by that new button near the window management buttons, there's a chrome:flags thing to disable it (enable the new avatar).

-----

More

Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: