At 3/23/16 06:14 PM, Diki wrote: This might be faster, but I am far too lazy to find out:

return Math.sign(n) === 1 && parseInt(n) === n;

Still doesn't require 10 dependencies to work. The future is now!

Haxe optimized my custom floor (pos or neg):

on js to

That obviously doesn't deal with NaN, inf, floats bigger than MAX_SIGNED_INT, and probably other things. But yeah, 20x faster than Math.floor. But it's not nearly as dramatic of a speedup on the other targets, 2x faster on flash, a little bit on cpp, and worse on neko for some ghastly reason.

Std.int on neko is slower than Math.floor, so there's not a lot I can do there anyway

For some of these, the function call to Math.floor is more expensive than inlining the math.

At 3/23/16 06:26 PM, MSGhero wrote: on js to

return n > 0 ? n|0 : (n-1)|0;

That obviously doesn't deal with NaN, inf, floats bigger than MAX_SIGNED_INT, and probably other things. But yeah, 20x faster than Math.floor. But it's not nearly as dramatic of a speedup on the other targets, 2x faster on flash, a little bit on cpp, and worse on neko for some ghastly reason.

That clever version using just bitshifts in my edit will most likely be faster than that. (And might even be a bit faster with the redundant > 0 at the end removed, which, so far as I can tell, is just there to make the result an actual boolean for true cases.)

But, at the end of the day: it's JavaScript. If you need that kind of performance, you're writing the wrong language.

At 3/23/16 06:31 PM, Diki wrote:

That clever version using just bitshifts in my edit will most likely be faster than that. (And might even be a bit faster with the redundant > 0 at the end removed, which, so far as I can tell, is just there to make the result an actual boolean for true cases.)

What the hell was that. Requiring 3 things instead of just doing the math?

In haxe, the stuff to the left of >> has to be typed as an int, so n >> 0 doesn't do anything. The cool thing is that the static analyzer would just remove the >> 0 (build, and check js export).

But, at the end of the day: it's JavaScript. If you need that kind of performance, you're writing the wrong language.

Well, for me it's haxe, which is every language :)

At 3/23/16 07:32 PM, MSGhero wrote: What the hell was that. Requiring 3 things instead of just doing the math?

It's technically doing more, but bitshifting is incredibly fast.

At 3/23/16 07:32 PM, MSGhero wrote: In haxe, the stuff to the left of >> has to be typed as an int, so n >> 0 doesn't do anything. The cool thing is that the static analyzer would just remove the >> 0 (build, and check js export).

It's good that Haxe does that, but that code was written for JS, and JS is very fucking goofy; if you're writing in a goofy language, may as well do goofy things.

At 3/23/16 07:32 PM, MSGhero wrote: Well, for me it's haxe, which is every language :)

Well, if you compile it to JS and need speed, then you're compiling to the wrong language. :)

At 3/23/16 07:41 PM, Diki wrote: Well, if you compile it to JS and need speed, then you're compiling to the wrong language. :)

Or CPP export is broken on master, and you need features/fixes that were added after the previous master.

inheriting multiple interfaces is a compile error in CPP

I have no need for native builds right now, but hopefully a new master gets released soon. Otherwise, I'll have to venture into dev-land. Not bad in general, but I don't keep up with haxe enough to know if the current dev build is awful or not. Like, they made switch statements more consistent internally, but it was a massive breaking change, and there was no mention of it except a single inline comment in the commit.

and every library's travis build failing with dev haxe

At 3/23/16 08:06 PM, MSGhero wrote:

inheriting multiple interfaces is a compile error in CPP

https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem

At 3/23/16 08:18 PM, egg82 wrote:

At 3/23/16 08:06 PM, MSGhero wrote:

inheriting multiple interfaces is a compile error in CPP

https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem

No, like implementing two distinct, unrelated interfaces causes an error when building. That was fixed on dev, but then they broke having multiple build macros (haxe feature), then they broke other stuff on CPP. So I'm just chilling with flash export on my old haxe version.

At 3/23/16 08:06 PM, MSGhero wrote: Or CPP export is broken on master, and you need features/fixes that were added after the previous master.

inheriting multiple interfaces is a compile error in CPP

I just write actual C++ so I don't have to deal with that. :)

edit:

At 3/23/16 08:06 PM, MSGhero wrote:

inheriting multiple interfaces is a compile error in CPP

Not if you write C++. ;)

At 3/23/16 09:41 PM, Diki wrote: Not if you write C++. ;)

I'm not looking for a job in CS, but if I have to have one, I really hope the language they use is supported by haxe. I could just be like "Yeah, I'm fluent in JS, and I'm the one who wrote this code, me a human, not a computer. Yes, I know C++ too, sorry I tend to use g1, g2, etc as my local variable names."

At 3/23/16 11:00 PM, MSGhero wrote: I'm not looking for a job in CS, but if I have to have one, I really hope the language they use is supported by haxe.

Does haxe even support a way to use C++ libraries that were written in raw C++ and not haxe? Like, is there a feasible way to use something like Boost or SMFL with haxe without having to do a bunch of hacky stuff?

I'm not about to stop writing actual C++ or anything; just curious about how haxe works.

At 3/23/16 11:11 PM, Diki wrote: I'm not about to stop writing actual C++ or anything; just curious about how haxe works.

Me, too. I've been seriously considering using/learning Haxe (since it's really not much different from AS3, that actually makes it harder to learn for me because I'm liable to get very confused during the transition)

I'm just not sure how it'll affect my workflow and how the whole "black magic" part of it works (on a basic level, at least)

I still like using C# for desktop apps because, well fuck, it's C#. But if I can port my framework to/develop desktop games with Haxe I might do that.

At 3/24/16 12:06 AM, egg82 wrote:

At 3/23/16 11:11 PM, Diki wrote: I'm not about to stop writing actual C++ or anything; just curious about how haxe works.

I don't understand it much, but yes. You can inject raw C++ directly into your haxe code which shows up in the output, and you can load raw C++ libs in. There is a load/save file dialog thing written in C++ , and you conditionally compile to include the Win/Mac/Lin versions or to use flash's FileReference class or whatever. Better would be to hide the conditional parts in some abstract class so you can use a common API on each platform. That's basically what the gamedev haxe libraries do.

There's a set of libs that provide native bindings to OpenGL, SDL, iCloud, etc. Not sure about boost, I don't see anyone using it.

I'm just not sure how it'll affect my workflow and how the whole "black magic" part of it works (on a basic level, at least)

I construct a map at compile time of everything in my json directory, but parsed to Dynamic ahead of time and inject it as a variable. Also, remember a while ago when I had to manually embed like 300 assets into my flash project? Haxe does this automatically at compile time using the same method. That might be Black Magic 2001, and there's some upperclassmen-level shit when you move away from the (easy) compile-time macros.

At 3/23/16 09:41 PM, Diki wrote: Not if you write C++. ;)

My final project at uni is partially in C++ and oh my god. I don't necessarily think it's bad, I'm just bad at it. And the standard lib leaves a lot to be desired; I find myself implementing a lot of boring functions. Maybe it's the contrast between working in Python one minute and C++ the next that's bringing out the negativity.

I suppose that's what I get for not using boost.

At 3/24/16 02:36 PM, Sam wrote: I suppose that's what I get for not using haxe.

Fixed.

At 3/24/16 02:36 PM, Sam wrote:

At 3/23/16 09:41 PM, Diki wrote: Not if you write C++. ;)

My final project at uni is partially in C++ and oh my god. I don't necessarily think it's bad, I'm just bad at it. And the standard lib leaves a lot to be desired; I find myself implementing a lot of boring functions. Maybe it's the contrast between working in Python one minute and C++ the next that's bringing out the negativity.

I suppose that's what I get for not using boost.

The standard library is pretty robust, especially with C++11. What functions did you have to write to do things that aren't available in the STL?

I finally decided to write an article on the whole ransomware thing.

The irony of putting ads on that page is not lost on me.

And now, out of boredom, I've re-written my Pi PRNG program.
It's a ton faster and cleaner. Only needed three classes for it. Entropy isn't quite as good as the first one, but it's pretty damn close for being at least 10x more efficient.

C# Source

I need this in my life :D

At 3/28/16 04:33 PM, egg82 wrote: I need this in my life :D

That's hilarious, and if I used the console for more than haxe stuff, I would totally use that.

At 3/28/16 04:33 PM, egg82 wrote: I need this in my life :D

But happens if you accidentally type fick?

At 3/28/16 06:03 PM, Diki wrote: But happens if you accidentally type fick?

I believe it just deletes your entire filesystem because you can't even spell "fuck" correctly and thus don't deserve to be under Linux's guiding light :P

At 3/28/16 10:05 PM, egg82 wrote: I believe it just deletes your entire filesystem because you can't even spell "fuck" correctly and thus don't deserve to be under Linux's guiding light :P

I was looking for a package in the repositories under "fick" but didn't find anything. That's the best I got :(

This absolutely blew my mind. This is perfect for things like gov't jobs that usually require two separate computers on two distinct networks. Also for malware analysis and package/application development/testing.
It even runs Windows because fuck you that's why.

Ooooh shiiit. I think I can just about retire with the bucks I'm raking in from a shitty game I made twelve years ago:

At 3/31/16 09:35 AM, Diki wrote: Ooooh shiiit. I think I can just about retire with the bucks I'm raking in from a shitty game I made twelve years ago:

I created my YT channel about three years ago and I've made ~$15 from it so far.
Woo, rich!

Oh, good. Now there's a quick and entertaining video on how video games are made.
(Actually the video is pretty damn good. I might start referencing it here on the forums)

I don't understand viruses/malware that intentionally destroys your computer. Wouldn't it be better to remain unnoticed and simply do data mining/keylogging for personal accounts and information potentially for years until the computer is retired?

I dunno. Just my two cents.

Maybe some people just want to watch the world burn

What the fuck is this website

At 4/1/16 01:34 AM, MSGhero wrote: What the fuck is this website

Apparently my personal blog where I talk to myself.

Nobody loves me :(

(Or maybe it's just that I don't have much in the way of helpful things to say. That could be it.)

.. Or are you talking about the slot machine at the top of the page which I just discovered upon writing this reply?
I like it.

Okay. Three things I've learned tonight:

1. "sudo dpkg --add-architecture i386 && sudo apt-get update && sudo apt-get -y upgrade" gives you a completely hosed system.
2. Disabling the root account and running "sudo usermod -G www-data user" on your ONLY user also gives you a hosed system.
3. Re-installing Debian-based OSes with encrypted filesystems at 3 AM sucks and you make a lot of mistakes.