Every time you visit for the FIRST TIME today... [Part 1]

Post a random function that you made. May be from any project you've done or make one impromptu.

Any QUALITY is allowed. No bullying!

>>160
Fuck off back to pro/g/.

>>161
I am already there

>>161
oh btw, since you like saying "Fuck off" you may want to look at http://bbs.progrider.org/prog/read/1383465168/24

>>160
You're that guy? No wonder your posts are so lacking in quality.

>>164
I do, how about you?

>>165
oops reply to the wrong thread!


Storage.prototype.connect = function(callback) {
var self = this,
dbFileName = this.baseDir + "/database.db";

this.sequelize = new Sequelize(null, null, null, {
dialect: "sqlite",
storage: dbFileName
});

this.sequelize.authenticate().complete(function(err) {
if (err) {
return callback(err);
}

self.defineModels();
self.sequelize.sync().complete(callback);
});
};


>>167
I find this code sexy
10/10, would ``rub''

>>167
You forgot these:

}();{}[])};
};()[]
};};};()
};()


Hate doing math by hand in numeric calculus course, so whenever there is a PC nearby from some colleague, I whip dumb code to calculate.

Behold, a Runge-Kutta method in fucking Javascript (p.s it didn't worked at time because I messed up the values, did it again now because it was bothering me and because I'm dying of pain:

Array.prototype.last = function() {
return this[this.length - 1];
};

//@unused
function discretize(min, max, pass) {
var len = (max - min)/pass + 1, arr = new Array(len);
for(var i = 0; i < len; i++) {
arr[i] = min + pass*i;
}
return arr;
}

function problem(params) {
return Math.pow(Math.E, -params.y);
}

function invert(f) {
return function(params) {
return 1/f(params);
};
}

function rk_form(f, h) {
return function(params) {
return h*f(params);
};
}

function next_K(accum, c, h, xn, yn, rk_f) {
accum.push(rk_f({
x: xn + c*h,
y: yn + c*accum.last()
}));
return accum;
}

function reduce_next_K(h, xn, yn, rk_f) {
return function(accum, c) {
return next_K(accum, c, h, xn, yn, rk_f);
};
}

function generate_Ks(f, h, xn, yn) {
var rk_f = rk_form(f, h);
return [0.5, 0.5, 1.0].reduce(
reduce_next_K(h, xn, yn, rk_f),
[rk_f({
x: xn,
y: yn
})]);
}

function sum_Ks(k_arr) {
return (k_arr[0] + 2*k_arr[1] + 2*k_arr[2] + k_arr[3])/6;
}

function runge_kutta_4_next(f, h, xn, yn) {
return sum_Ks(generate_Ks(f, h, xn, yn));
}

function runge_kutta_4(f, h, x0, xn, y0) {
var x = x0, y = y0;
console.log(x, " -> ", y);
while(x < xn) {
y += runge_kutta_4_next(f, h, x, y);
x += h;
console.log(x, " -> ", y);
}
}

Runnable code here:
http://repl.it/N48/1

>>152

(f = fopen(*++argv, "r")) || error("fopen", "Couldn't open %s", *argv);

The CLEVEREST CODE EVER, because a fucking if statement is too imperative, ick

>>171
People use logical ands and ors in order to reduce the length of code and improve readability all the time, even in C. Anyone reading that knows exactly what's going on in less code.

And sure, I took it from perl where it's common to write things like open(...) || die $!.

I'm still questioning whether it's ok C programming to write things like that.

>>172
There is no such thing as "ok C programming", and I will stand by that statement until someone shows me an open source static analyzer that can detect every instance of potential undefined behaviour.

>>173

lol... a program that can detect all instances of undefined behavior would solve the halting problem. in the meantime, clang -Wall does well enough

>>173
The burden is on you to to come up with the potentially undefined behaviors because I happen to know none exist. Order of evaluation for && and || is guaranteed for a reason.


def _scan(self, chan, nick, msg):
store = json.load(open(FNAME))
delta = {}

for nick_ in re.findall('([a-zA-Z0-9]+)\+\+', msg):
nick_ = nick_.lower()
if nick_ == nick: continue
delta[nick_] = delta.get(nick_, 0) + 1

for nick_ in re.findall('([a-zA-Z0-9]+)\-\-', msg):
nick_ = nick_.lower()
if nick_ == nick: continue
delta[nick_] = delta.get(nick_, 0) - 1

for nick_ in sorted(delta.keys()):
store[nick_] = store.get(nick_, 0) + delta[nick_]
helpers.msg(self.client, chan, '%s now has %d points of karma.'
% (nick_.lower(), store[nick_]))

json.dump(store, open(FNAME, 'w'))


>>174
It's debatable if a program that may have undefined behavior should be allowed to be used. Like indexing outside the bounds of an array. But in order for a compiler to check these conditions tractably, a different language than c might be more appropriate. Explicit dependent types would be helpful. Otherwise the checker is essentially doing dependent typing inference...and looking for conflicting types...which is possible I'm sure but probably kind of hard...it reduces to the halting problem pretty trivially, but if you can get it to the point where the unprovable cases are questionable enough to not be accepted in a program, then that's good enough...

>>177
What are you going on about? Who are you to tell me whether my programs should be ``allowed to be used''? C can be used to write both portable and non-portable software, and that's part of its usefulness. If you want to write code in a langauge that has no undefined behavior, then go do so - I'll tell you right now that there are different languages most certainly more appropriate than C. But don't presume to tell the rest of us what to do just because you can't handle the fact that somewhere, somebody might be writing str[-1].

>>178

But don't presume to tell the rest of us what to do just because you can't handle the fact that somewhere, somebody might be writing str[-1].

I'm more worried about myself accidentally writing something like that. Well, not as obviously silly as that, of course, but still enough to cause terrible security issues.

>>178
What should be allowed to be used is determined by a standard of quality. If someone is relying on out of bounds array indexing to get some effect, I would argue that code isn't reliable and shouldn't be used for anything important (anything at all). These issues usually aren't intentional. Otherwise, if the program is relying upon machine dependent behavior, for instance, the way signed integers overflow, then there should be a way to communicate this to the compiler. That way the compiler can select a way to get the intended behavior on the target platform. If the behavior can't be described in this way, then the programmer can write routines in inline assembly, one for each target platform, and then may invoke these routines from the portable code base. It isn't safe to rely on undefined behavior even if you are only targeting one platform, since subtle changes in the compiler or compiler options may throw off the resulting behavior.

>>180
Then, like I said, go fuck off to some language that is not C, only use software not written in C, and don't write any software in C yourself. It sounds very nice to say ``Don't ever rely on undefined behavior'', but sometimes the real world doesn't accomodate that. If you don't allow extraordinary circumstances to be met with extraordinary measures, then you are nothing more than an irritation to those who can deal with such circumstances.

A C compiler that does not support -fwrapv and -fno-strict-aliasing is utterly worthless.

>>181
If you rely on undefined behavior, your program will function differently depending on the compiler's whim. It's unlikely that the collection of possible behaviors fits within the set of intended ones, as they are all undefined. If you need functionality that goes outside of standard C, then there are platform specific libraries, and many compilers support inline asm. Between those, you should be able to accomplish what you need without invoking undefined behavior. I think I'll need to see an example of what you are referring to. I don't see how constructs like *++a = *++b; help solve real world problems.

fuck me, that's not undefined. Here we are. *++a = *a

>>183

real world problems

Here you go: You have a [set of] specific hardware target[s], and you have an algorithm in which you need to deal with a range of data, stored in a specific type of memory (think main memory vs flash or such). You want to access a piece of data, and you have a pointer to it, but if your pointer is `far away' from a known location that you just accessed from the hardware, it's faster to just recompute the data from registers, since the formula is simple and known. So you write code like this, where loaded_data and unknown_location reside in this special memory area:

void foo(short *loaded_data, short *unknown_location, short param_a,
short param_b, short *outp, size_t len)
{
/* ... */
skdist = loaded_data - unknown_location;
if (ABS(skdist) > SEEK_CUTOFF) {
/* rewrite to match your idea of `fast enough' as needed */
*outp = (param_a + (param_b * *loaded_data)) / (param_b + 5);
} else {
*outp = *unknown_location;
}
outp++;
unknown_location++;
/* ... */
}

The undefined behavior there is that two pointers which are not to the same array are being subtracted (and probably storing the result, too). Two thing makes this ``okay'': That you actually do have the ability to know what the compiler does in this case, so you know that it won't cause demons to fly out of your nose, and that you have complete control over the build environment for the entire duration of the program's work cycle. Sure, you're locked onto that behavior (in practice: that version of that compiler) for the rest of the time that you would possibly want to compile that program. But that isn't always a big deal. Suppose this program will be burned into a ROM, so that updating the code is impossible, and you know that there will only be one version of the ROM^*. Then the program will really only be compiled once [for each target] - and if you control the build environment there's no reason to get fussy over requiring a specific version of a specific compiler.

The upshot is: not all code is portable, and that's not a bad thing. There's a hell of a lot of code that is not intended to work in 20 years when you compile it using the DS9000 compiler. C is more than its public face of ``that hugely portable, performant language that UNIX was written in'', and it shouldn't be restricted to that.

^{* Yes, that does mean you have to get it right the first time.}

>>185
I think this example is ok by the standards listed in >>183. The only thing undefined (correct me if I'm wrong, I have not red da standard (because I am poor and not important enough to own a copy of it)) is the value of skdist. If this value was used for something like indexing in an array, that would be bad because it's value would be unpredictable, but it's just used in an if condition. Also, both branches of the if condition achieve the same end result, while one is more efficient than the other depending on details of the underlying machine and the meaning of skdist. So from the point of view of the caller, foo behaves the same in all cases, or at least it should write the same meaningful value to outp in all cases, despite invoking undefined behavior in its interior. From a correctness point of view, it's fine. I guess I was referring more to undefined behavior affecting correctness, although there are probably some reasonable examples there as well. Like atomic assignment. Although things like that should at least be wrapped in macros.

Stop saging your posts when they are actually worth reading, for fuck's sake.

>>186
The entire program after the subtraction is undefined behavior. All of it. From the point of the view of the caller, a C compiler that made foo print ``GOODBYE WORLD'' would be conforming and valid. So would a compiler that made that program spawn a new thread, and 35.6 seconds after the subraction, execs dd if=/dev/zero of=/dev/sda. That's what undefined behavior means, so you can't say ``this undefined behavior is just a little undefined.'' So that function relies on undefined behavior because it relies on the program not spontaneously turning into a text editor when foo is called. That is the `correctness' dependency on undefined behavior.

>>188
Well that's pretty silly. I'm trying to think of a hypothetical machine where a really undefined result would make sense. Maybe it allocates arrays in hardware assisted memory banks, and then if it attempts to subtract addresses that point to two different banks, there is a hardware failure and the machine catches on fire.

>>189
Thanks uguuu~

I meana >>187 thanks ugu.

>>189
The C compiler I wrote back when I was 12 years old generated a HCF instruction whenever it encountered undefined behaviour.

>>189
It's not silly at all - it allows you to reason about C without being a silly STACK BOI. Ironically, that kind of lack of information about, say, pointer representation, is what allows C to be so portable in the first place.

Plugin.prototype.verifyNickname = function (msg: string, cb: boolean): void {
let con: object = this.con,
nickname: string = msg[0];

if (!nickname) cb(false);

let error: number = setTimeout(function(){cb(false)}, 3000);

con.raw('STATUS '+nickname);

con.once('status', function (nick: string, result: string){
clearTimeout(error);
if (~~result !== 3) cb(false);
else cb(true);
});
}

>>192
Ironically, that undefined behavior was created by ANSI in 1989 and was not part of the original vision and purpose of C or why it was portable in the first place.

splitByHour =
let f h depth =
let hourOf = .time >> Date.fromTime >> Date.hour in
List.partition (hourOf >> (>) h) >> \(less, more) ->
if (h // 3) % 2 == 0 then
let d = depth // 2 in
Dict.union
(f (h - d) d less)
(f (h + d) d more)

else
Dict.fromList
[ h => List.sortBy .time more
, (h - 3) => List.sortBy .time less
]
in f 12 12


function permbl(p){
return `<button title="Permanently remove from this listing" class ="sub1permblock" onclick="window.localStorage.permablock+=',${p}';window.forcecssreload=3000;window.permablockrefresh=1;">X</button>` ;}


instance Functor PluginT where
fmap = undefined

instance Applicative PluginT where
pure x = undefined
(<*>) = undefined

instance Monad PluginT where
(>>=) = undefined


>>197
Is that part of a C to Haskell compiler?