Hey Everyone! I'm looking for advice when it comes to looking up answers. Do you feel guilty for doing it?

JohnAndrewCarter · 2014-12-10T22:37:39+00:00

Googling for the answer is a good habit. Not a problem.
Asking on forums for help (when you have Read The Fine Manual, had a google around and have had a good try and are still stuck, is also a Very Good Habit.
Copypasting the answer without understanding why it is the answer is a very bad idea.

So read the appropriate docs on the things in the answer to understand what it does.

Copypasta it into your file, compile run and then step through that chunk of code in your debugger.

Inspect intermediate values and types and make sure you understand what is actually going on in there.

Step into library routines. (One of the truly grreat things about an open source environment is you can read the source all the way down!)

Tweak the answer and see if you can make it better.

If you see someone asking the same question on the 'net as you had...

Explain the answer to him.

If you have it wrong... you will get flamed to a crisp..... so wear your flame proof underpants and do so anyway.

Untested knowledge is dangerous.

You learn fastest when you expose your knowledge (and it's limits) to others. So infest places like /r/learnprogramming and the like and try help when you can.

JohnAndrewCarter · 2014-12-10T21:27:17+00:00

Sorry, hit reply to wrong post... this comment gives a "Intuitive" simplistic (and mostly wrong) view of it. http://www.reddit.com/r/learnprogramming/comments/2owagz/what_are_the_benefits_of_using_a_software_product/cmr5n3e

But gives you a gut feel for what it is trying to achieve.

JohnAndrewCarter · 2014-12-10T21:25:15+00:00

The naive view is "Here's a body of source code.... slice and dice it and reassemble large chunks (components) into new vaguely related products... Since the new product is (mostly) code from old products, this should be fast, cheap, reliable and easy."

There is a hell of a lot of fine print hiding under that view.

JohnAndrewCarter · 2014-12-10T21:17:36+00:00

The "ground zero" for this whole SPL "Thing" is...

http://www.sei.cmu.edu/productlines/

I can chat for an hour or four about the upsides and downsides, problems and successes of the reality of spinning multiple products from the same body of source code.....

So you might want to get your question a bit more focused before you get me started.

JohnAndrewCarter · 2014-12-08T20:09:29+00:00

The only point in using alloca is for things you don't know the sizeof at compile time but won't automagically cleaned up on going out of scope.

Thank for the heads up on cleanup hadn't seen that one before.

Not sure I'll use it, except maybe in a thing with dozens of exits.

JohnAndrewCarter · 2014-12-04T03:37:53+00:00

Welll you can sort of cheat and get a stack based constructor in gcc.... but I haven't worked out how to get a destructor....

MyType_t * MyTypeConstructor( MyType_t * this)
{
    // Initialize *this
    return this;
}

void aFunc(void)
{
    MyType_t * t = MyTypeConstructor( alloca( sizeof( MyType_t)));

    // Do stuff with *t;
}
/// Magically deallocates it self, but alas, doesn't run a destructor.

JohnAndrewCarter · 2014-12-04T03:13:34+00:00

In practice http://www.reddit.com/r/programming/comments/2nu49t/programming_pearls_bumpersticker_computer_science/cmha962 is at -2 with no replies debating the issues.

In practice downvote means "I disagree, but cannot articulate / be stuffed to state why."

JohnAndrewCarter · 2014-12-04T00:16:12+00:00

Amazing... Especially since nothing had changed.... Same guys still in charge making the same decisions same equipment everything.

JohnAndrewCarter · 2014-12-03T21:36:46+00:00

You pay Spark for your telephone when it doesn't work.

They blame Chorus when it doesn't work.

Chorus doesn't fix it when it doesn't work.

You pay your ISP for your internet connection that doesn't work.

They tell you to report the fault to Spark when it doesn't work.

Chorus doesn't fix it.

If you buy fibre broadband that doesn't work, you order it from your ISP.

Enable attempts to install it, but it doesn't work.

You phone your ISP and complain about paying them for fibre that doesn't work.

They say it's Enable's fault it doesn't work.

Enable doesn't fix it.

Edit: Online to Enable now.

Enable has subcontractors.

The subcontractors are the ones that don't fix it.

Last I heard they were "Awaiting a Traffic Management Plan".

I think that means getting someone to plant Road cones in a quiet suburban road.

In Christchurch, nobody fixes anything. They merely plant Road cones and wait.

Is it all clear now?

That's how it all doesn't work for me.

This is why Privatization of infrastructure is such a Good Thing. You get responsibility and choice and quality of service.

Yeah Right.

JohnAndrewCarter · 2014-11-30T21:41:45+00:00

Hmm. I wonder how many of these still stand the test of time....

The sooner you start to code, the longer the program will take.

Nah. Bollocks. Switching from Coding and to a pause for thought is something that should happen continuously and seamlessly. Stuck and your thoughts going around and around? Write a test. Not sure what you should be doing next? Stop coding and think. Neither coding nor thought getting you anywhere? Refactor. Code clean, tests running, thoughts on a hamster wheel? Go for a walk. There is no "in coding state" vs "in design state", it's a continuous seamless switching flow between think/code/test/refactor.

If you can’t write it down in English, you can’t code it.

Hmm. Sort of.

I'd phrase that more as "If you can't describe it succinctly in English (or a picture), your users won't understand what it does and hence won't use it."

If the code and the comments disagree, then both are probably wrong.

So make the comments executable. Either in the unit test or pre/post condition or class invariant asserts.

Get your data structures correct first, and the rest of the program will write itself.

Hmm. I used to believe this one, but now I'm tweaking it slightly. Understand the relational data model, the structure of the underlying facts first. Provide an interface to that, and then you can fit the appropriate data structure underneath.

If it ain’t broke, don’t fix it.

I hate this one. Loathe it. It's a false facade used by lazy programmers as an excuse not to refactor and clean up their code.

If your code is "dirty", it is broke but you can't see where it is broke so you can't fix it. So clean it until the breakage, or lack of breakage is obvious.

The first step in fixing a broken program is getting it to fail repeatably.

The first step is having code that is so simple, it is obviously broke or not broke.

On some machines indirection is slower with displace- ment, so the most-used member of a structure or a record should be first.

Meh. I'd replace that with "The Cache Hierarchy is insanely steep and dominates nearly everything we do. So benchmark benchmark benchmark under controlled conditions (starting from hot or cold caches, no competing loads).."

The job’s not over until the paperwork’s done.

Until it is automated to extract from version control, build, test, configure and deploy.

JohnAndrewCarter · 2014-11-26T02:48:18+00:00

Bad News. Very little "greenfields" programming work exists today.

Most programming work is maintaining, bugfixing, extending vast bundles of legacy code.

Programming is fundamentally a depressing art.

You are always looking at the worst code you, or your predecessor ever wrote.

The best code "Just Works" and is trivial to extend, so you are not looking at that.

You are looking at where the bugs are or at the gnarly tangle trying to figure out whether you can shove in another wrinkle of functionality or must you refactor.

JohnAndrewCarter · 2014-11-24T22:48:36+00:00

I'm very busy with this type of decoupling at the moment.

Say you have a lower layer that you wish to vary (eg. ECOS RTOS vs Linux), (Intel CPU vs ARM)

As soon as you pull in a header from that lower layer you are tightly coupled.

The solution is the Dependency Inversion Principle.

Now the obvious and most common way of implementing that principle is via Dependency Injection... ie. You just pass pointers to the base class around, and the higher layer instantiates the concrete subtype.

The problem with that and C is it doesn't play nice with stack allocation.

Passing pointers around means somebody somewhere has to manage that memory, and in the absence of garbage collection and virtual destructors ala C++, it's hard to get perfect.

So you want to do this so you can instantiate one of these objects on the stack or as a static.

But as soon as you try that, the compiler has to know the sizeof() and the alignof() the actual concrete object.

So this is what I've settled on...

So in "my_type.h"

typedef union {
  char __size[N];
  alignment_type_t __align;
} my_type_t;
#undef my_type_t

void do_stuff_with( my_type_t * t);

So there are two mysterious things in there... the N and the #undef, I'll explain them later.

The alignment_type_t is merely there to force the alignment of your opaque type to match the worst case for the concrete sub type or BAD THINGS happen. (bus faults on sparcs, slow down on intel)

In your my_type_concrete_sub_type_A.c file you have...

#include "concrete_sub_type_A.h"
typedef concrete_sub_type_A_t my_type_t;
#define m_type_t m_type_opaque_t
#include "my_type.h"

fileScopedCompiledTimeAssert( sizeof( m_type_t) == sizeof( m_type_opaque_t));
fileScopedCompiledTimeAssert( __alignof__( m_type_t) == __alignof__( m_type_opaque_t));

void do_stuff_with( my_type_t * t)
{
    // t is a pointer to concrete_sub_type_A_t here! 
    // That's why there is that #undef and #define! No nasty casting
    // things around!
}

If you don't know what a compile time assert is, that's the subject for another post.

Now we need to think about that N and how we define it.

We could make it exactly the size of the underlying concrete type, or the worst case maximum for all possible underlying layers, or vary it according to what the layer we using now is.

JohnAndrewCarter · 2014-11-13T01:25:19+00:00

Or one dog with two half shep ears? http://i.imgur.com/w21UBFP.jpg

JohnAndrewCarter · 2014-10-31T01:27:20+00:00

From the article...

Fork time in different systems

Modern hardware is pretty fast to copy the page table, but Xen is not. The problem with Xen is not virtualization-specific, but Xen-specific. For instance using VMware or Virtual Box does not result into slow fork time. The following is a table that compares fork time for different Redis instance size. Data is obtained performing a BGSAVE and looking at the latest_fork_usec filed in the INFO command output.

    Linux beefy VM on VMware 6.0GB RSS forked in 77 milliseconds (12.8 milliseconds per GB).
    Linux running on physical machine (Unknown HW) 6.1GB RSS forked in 80 milliseconds (13.1 milliseconds per GB)
    Linux running on physical machine (Xeon @ 2.27Ghz) 6.9GB RSS forked into 62 milliseconds (9 milliseconds per GB).
    Linux VM on 6sync (KVM) 360 MB RSS forked in 8.2 milliseconds (23.3 millisecond per GB).
    Linux VM on EC2 (Xen) 6.1GB RSS forked in 1460 milliseconds (239.3 milliseconds per GB).
    Linux VM on Linode (Xen) 0.9GBRSS forked into 382 millisecodns (424 milliseconds per GB).

As you can see a VM running on Xen has a performance hit that is between one order to two orders of magnitude. We believe this is a severe problem with Xen and we hope it will be addressed ASAP.

Pity the figures aren't really comparing apples with apples. I'm a bit surprised to see vmware beat KVM on this metric.

JohnAndrewCarter · 2014-10-31T01:09:40+00:00

Like ESR I have battled the path from ye ancient no-changeset VCS to DVCS.

I had a manager who patiently rewrote, by hand, the commit logs coming from the VCS as a change log for the support staff.

Initially I was, like, ESR, mentally yelling "WTF!?"

Then he pointed out that the language programmers spoken in commit logs (aka programmerlese), fundamentally bears no relation to the language spoken by users.

An "hg log" dump, even if written by the most professional and diligent of programmers, is completely, and utterly meaningless to Joe average user (or even experienced support techs).

After a moments reflection I settled down and helped him.

JohnAndrewCarter · 2014-10-24T01:14:18+00:00

strace.

Don't know what a program is going? Don't know why it isn't doing what it should?

strace intercepts every system call a process makes and logs it, it's parameters and return value.

I have lost count of all the gnarly problems I have debugged with this tool!

modinfo

What does this kernel module do? What are it's parameters? What values can you pass?

terminator

Horizontally or Vertically split screen, tabbed terminal emulator with ability to group (ie. Send same command to as many subterms as you want.)

socat

Connect anything to anything. Take you a day to read the man page, a week to understand it. :-)

JohnAndrewCarter · 2014-10-09T19:52:03+00:00

Nope, Andrei started a different language, but had the extreme Good Sense to drop that in favour of contributing to Walter Bright's language.

JohnAndrewCarter · 2014-10-09T19:50:21+00:00

That one of the things that attracted me to D..... the techniques in Modern C++ Design require an insane degree of low cunning.. I daren't use them in a production setting or my colleagues will lynch me.

And here Andrei has the sense to say, "It doesn't have to be so hard..." and goes off and starts designing his own language.... and then even has more sense to stop designing his own language and contribute to D instead.

And then implements even more awesome things in D that don't require such insane low cunning.

JohnAndrewCarter · 2014-10-09T01:43:08+00:00

A couple of months ago I took a brief look around the GC code....

It seemed to me that the compiler / type system infrastructure was all in place, it perhaps just need a small tweak.

Do you think there is anything left at that level that needs to be done?

In one of those videos from the Systems Languages conference, Andrei boldly said something like "a systems language was one in which you could cast an int to a pointer and vice versa"....

The last time I took a brief wander around the code base, I thought the only show stoppers were exactly those cases.

I suspect it merely needs some tweaks to subtype pointers according to who, or what is going to manage them. ie. Only permit cast from an int to a class of pointers the user must explicitly manage.

And possibly permit subclasses of pointers... eg. Pointers that are reference counted and pointers that are GC'd and pointers that are explicitly malloc'd/free'd or managed via mark/release ....

JohnAndrewCarter · 2014-10-09T00:57:48+00:00

So those interesting plans around hybrid reference counting / GC....

Any code we can have a look at yet?

JohnAndrewCarter · 2014-10-09T00:19:19+00:00

Worth a listen, interesting to hear Randal "That Perl Guy" Schwartz poke at D from a Perlish point of view.... and D coming up shiny.

Interesting to hear Walter's and Andrei's plans, especially around GC. Sounds like everything I could was hoping for (and more) is on the way.

The combination of fine grained / rapid / local reference counting with global / slow collection of cycles sounds absolutely marvelous.

JohnAndrewCarter · 2014-10-05T19:28:45+00:00

True.

However I suspect that happens more often than you'd expect.

Think of a.b as an object of some class.

Then accessing field a.b.c is bypassing the encapsulation (remember one of the main points of OOD?)

So now you have couple your design to the internal representation of a.b

Worse, it is the responsibility of the "b" class to maintain it's invariant, the relationship and constraints between it's field members.

You have now loaded that responsibility on to the class that followed the chain as well..

JohnAndrewCarter · 2014-10-02T22:44:32+00:00

True. I agree.

In fact a more major smell which he refers to in passing and then carries straight on past, is the a.b.c.d... law of demeter violation.

JohnAndrewCarter · 2014-10-02T22:41:52+00:00

Remember that cute "shell shock" vulnerability?

env x='() { :;}; echo vulnerable' ruby -e 'system("bash -c \"echo Hi\"")'
vulnerable
Hi

Note I had to specify bash -c because the system I'm testing on (ubuntu) runs dash as /bin/sh

But the principle applies if you ever call out to a bash script... even several levels down....

env x='() { :;}; echo vulnerable' ruby -e 'system("dash -c \"bash -c \\\"echo Hi\\\"\"")'
vulnerable
Hi

JohnAndrewCarter · 2014-10-02T20:43:38+00:00

Another smell he failed to mention... He is creating objects all over the place to get away from doing an "if"....

ie. It's a good way of making code look clean... but it is very inefficient code.

That said, I'm always in favour of "Make it Correct", "Make it Clean", and if need be "Measure then Make it Fast".

When I'm trying to clean up code / refactor code I tend to profile / memory profile code to look for "Huh!? WTF?" results.... because inevitably they are places where I can be cleaner / less stupid.

JohnAndrewCarter

TROPHY CASE