jbert

Further, even if you're looking at a mutable reference (like master), the line number links could/should be to the underlying immutable url (based on the commit).

If there is a marginal use case for linking to line numbers of mutable refs, perhaps it should be the non-default case, discoverable by keyboard shortcut like this...

So - there are ground-based observatories continuously determining the absolute position of the satellites?

This seems really hard. The satellites are ~20,000Km up. I think that means a 1 millimetre difference would be a 5 x 10^-11 radians difference (theta ~ tan theta), or 0.0001 arc seconds - surely this is beyond any telescope technology?

And even if they could resolve at that level, we're trying for an absolute fix, so we're also trying to measure the alignment of a (moving?) telescope with 0.0001 arc second precision (hoping no mice cough nearby?)

That can't be right, so what am I missing?

Wikipedia says that there are lots (~13?) stations: http://en.wikipedia.org/wiki/Global_Positioning_System#Contr...

Are there potential issues with them being covered by weather etc?

[Ah - found the link to 'http://en.wikipedia.org/wiki/Kalman_filter' - this is probably the magic?]

Yes, if you know where the satellites are to the same degree of precision. That's what I was wondering about.

If so, how is this accuracy achieved? (Obviously the satellites themselves cannot use gps to determine their position...). Measurement from the ground plus manouvering?

Are there any events (micro debris strike, solar wind?) which cause drift in our estimate of their position?

e.g.

1 - Select Advanced

2 - the two processor options shown are (+11% cost, +13% perf) and (+7% cost, +3%perf). If I expand "more options", I can see a (+9 %cost, +16%perf) in there which is preumably superior to either of the two shown.

But this is awesome - please keep it going and improving it :-)

Possibly, but it's mostly only useful if you can't recompile the app (i.e. don't have source).

And in that case, you've probably paid money for it, and want support. Which you won't get if you've swapped out a component for one it wasn't tested with.

[But I agree with your general point. DLL search path/LD_LIBRARY_PATH can be a useful 'speed hack' to drop in a different lib with an identical API and minor tweaks. e.g. overload malloc/free/realloc() in some misbehaving app to trace a problem without recompiling.]

set editing-mode vi

in your ~/.inputrc (instead) and all GNU libreadline using programs will give you vi keys instead of emacs :-)

Assuming the following points from the post are correct:

a) the perf problem is YAML marshalling b) that can be solved via a go rewrite

then perhaps an easy way to solve "I want to call the old code" is to access it over HTTP, using a cheaper marshalling method than YAML.

I guess the tradeoff is whether you'd prefer an AMQP broker in there mediating the requests or an HTTP load balancer (or http client pool code in the go app). And whether you see other uses for that broker in your setup.

Looks like a bunch of konsole stuff never got implemented as dbus interfaces in KDE4. This specific use case seems to be covered by the konsoleprofile command (I wonder why the devs chose that route instead of exposing a dbus interface).

Example task:

1) inspect running konsole task to find exposed interfaces

2) find one related to background colour

3) script up "change background colour to red in current konsole" command

Last time I looked at the KDE+dbus situation (early KDE4) it seemed this was really hard.

The code which wants to be generic is in the handling of things like setting up channels between stages, handling data passing between them and cancellation (shutdown).

I also want to support a layer of abstraction, where I can compose a graph of stages into a single stage.

The goal is to have a number of primitive processing stages and allow abstraction and composition to build more complex processing.

Basically I could move to a pure interface and associated functions (not methods). That would perhaps be more idiomatic go. It's just a slight shame that a bunch of code which lives to my mind slightly more naturally as a set of methods on a type gets promoted to top-level package functions due to the inabillity to define methods on an interface. But that's probably OK.

So I want a few different, but similar things. These are actually stages in a processing pipeline, each stage doing different processing steps.

What I'm currently doing, which mostly works well, is to have a struct type ('Stage') which does all the generic work (equivalent to an abstract base class in C++). The Stage contains a function ptr ('Each') to actually do the processing step.

I can then have various 'derived' types which embed 'Stage'. Each one is assembled via a ctor which sets up the 'Each' function ptr. Effectively this provides inheritance with method overloading for the Each function.

I also have an interface ('Stager') which is satisfied by the Stage type, and so consequently by all the derived types (since they embed Stage).

So, I seem to have most of the benefits of C++ abstract base class and 'inheritance' (of data and methods), including overriding of methods by subclasses (using explicit assignment to function ptr).

It feels pretty nice to work with. The main concern I have is the slight klunkiness of the Stage/Stager duality. I also don't think I'd like this if I had many overridden methods (I just have one atm).

Anyone care to comment on a better way to this or other critique?

I'm also not entirely sure what you intend by "changing everything but keep the name the same". Why not use a new name?

Perl evolved into it's "new form" some time ago. Modern Perl came out 5 years ago and was really just codifying best practice at the time.

It's still the same language if you want it to be. Backwards compatability is taken very seriously. Which - yes - does mean that you can write crappy old perl in it if you want to. (And also that all the crappy old perl you have lying around will continue to work).

But it's also a pretty vibrant, modern language. Any new project or new perl codebase can and should be written in modern perl. And - despite your assertions - it's still very much the same language.

Just now with extra, better stuff too.

    sub foo($x, $y, $z) ...

    sub foo {
        my ($x, $y, $z) = @_;
        ...

The people who want to hate perl will continue to hate it.

After the list of reasons they dislike it are resolved, they'll come up with new ones and/or point to "it's not popular enough" (while simultaneously embracing a brand new language which is significantly less popular).

https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlsu...

edit: and the copy-on-write string concatenating has the potential to speed up a lot of code, I think.

Can anyone recommend a more limited course or tutorial focussing on that, or should I try and extract particular lectures from this course?

http://www.catb.org/jargon/html/S/scratch-monkey.html

[edit. huh - that's been edited to remove the actual story. Here's the story: http://edp.org/monkey.htm]

The jargon file has lots of great stuff in it (also see "Magic/More Magic"). Some versions have had some dubious stuff added, but that's a big old ball of flame waiting to happen, so I'll say read with caution :-)

Thank you, that helps. I was mentally projecting the whole plane down and could see why it wasn't all-green (or all-not).

If the datasets aren't disjoint, then you're trying to do fast and slow ops with the same data, which - if you need accurate values - is going to be mildly hairy even if multithreaded, since you'll need to somehow lock the data while you do the slow op (which will exclude the GETs, causing high latency), or you'll need some kind of transaction-based stable view to operate on (e.g. transactional memory?)

Chemical fuels have a great energy density. Problem is, they dump carbon into the air when you burn them (and also basic pollutants).

So we just need:

1) fusion or similar "lots of 'free' energy"

2) a process like this to soak up that energy + CO2 + H2O and emit nice energy dense hydrocarbons

3) decent catalytic convertor/filter tech (we're pretty good on this at the moment when we want to spend the money?)

then we've got a long-term energy future.

There must be some side effect of the optimisation, otherwise there wouldn't be a problem. Detect that side effect (e.g. write a buffer of memory to disk, check timing of some code, ptrace-attach to the other process and inspect it, trigger a core dump and pick over the bones, code up an exploit which would work if the explicit_bzero() wasn't present)

> How do you know all the scenarios where some compiler would optimize things out?

You only really need to know one case where the compiler will, if the prevent-optimisation compiler magic isn't sprinkled on it.

> Tests might not hurt, but I am not sure trying to cater for braindead porters is a good idea. They might get the idea they're doing it right once they get the tests to pass one way or another...

At least they'd get an idea that something was up. I guess you might get away with:

    #ifndef OPENBSD
    #error "You can't just call bcopy() for explicit_bcopy() - see http://good-description-here why not"
    #endif

e.g. a test which calls explicit_bzero() in a way which would have it optimised out in a platform with a low-quality port.

A reasonably descriptive comment in the header (or failure text) of the test should guide a porter onto the path of wisdom.

(If there is a problem in that the test would need to inspect the output of explicit_bzero(), hence negating the optimisation, it can be implemented as multiple processes).

For more general use, a simple way to keep the amount of 'pending writes' down to reasonable levels is to have a thread walking your mmap()'d regions and enforcing an msync() on a regular basis. This also gives you guarantees such as "each part of mmap'd file is no more than N seconds out of date".

Of course, you'll potentially increase disk load overall, since a page dirtied three times, once every second, might only get written out once by the kernel (after 5s) but if you're syncing every 1s it'll get written three times.

But you should be able to take control.

It's more along the lines of sporting team rivalry.

1) I built two Dockerfiless on my laptop (one for nginx, one for my postfix setup) tested locally, then scp'd the Dockerfiles over to the server, built images and ran them. I didn't really want to pollute the registry with my stuff. Is this reasonable? For bigger stuff, should I use a private registry? Should I be deploying images instead of Dockerfiles?

2) The nginx setup I deployed exports the static html as a VOLUME, which the run command binds to a dir in my home dir, which I simply rsync when I want to update (i.e. the deployed site is outside the container). Should I have the content inside the container really?

3) I'm still using the 'default' site in nginx (currently sufficient). It would be kind of nice to have a Dockerfile in each site I wanted to deploy to the same host. But only one can get the port. I sort of want to have a 'foo.com' repo and a 'bar.org' repo and ship them both to the server as docker containers. Don't really see how to make that work.

What I think I want is:

- a repo has a Dockerfile and represents a service

- I can push these things around (git clone, scp a tgz, whatever) and have the containers "just run"

Not sure how to make that fit with "someone has to own port 80"

I'm not sure I understand this. Surely the point of if-modified-since and etag headers is that you can send them in the GET request and get back a 304, there is no need to do a HEAD-then-GET?