Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Stargrasper]

Well, to be honest...

What I really want is a job.  Because I'm making $12/hour right now, when I'm employed, which is infrequent.

We may still be hiring here in panama city.

BUT: the work is boring, arbitrary and annoying. Plus we are more likely to be looking for a long term programmer considering the massive scale of the projects we work on. And I don't think you want to get this far away from your family, or deal with all the extreme conservatives...

Why the hell do I work here again?

Because they're giving you more money than a local competitor is offering.  I hope.

Speaking of which, I'm having a hell of a time finding of job...  If I've learned anything in the last several years, it's that I look bad on paper.  I guess.  Employers frequently won't even interview me to find out I do in fact know what I'm talking about.  From what I'm told, my resume isn't that bad...  It's mostly just lacking in work experience because nobody will hire me...

[Rose]

Spoiler: So this is something I got working. (click to show/hide)

[Siquo]

Spoiler: So this is something I got working. (click to show/hide)

O_o Really?!

That... is effing cool.

[Rose]

Yep. This means that things like a Unity DF vis or a .Net utility of some sort are possible.

[Stargrasper]

Yep. This means that things like a Unity DF vis or a .Net utility of some sort are possible.

Pretty sure the Lazy Newb Pack launcher is a .NET app.  And I see no particular reason a utility actually connecting to DF couldn't be Unity.  I'm just going to oppose it the same as any .NET app since it can't be easily ported to run on Linux.  The biggest thing that sucks about DF on Linux is that few to no utilities are compatible with the native Linux binary.

[Rose]

Unity uses Mono, which works on Linux fine. And the lazy newb back doesn't connect directly to DF. It launches it, I think, but it doesn't interface with it. It can't read dorves beard lengths in realtime.

Also, this was mostly a proof of concept, to make sure it can be done. Now that I know that it can be, there's no reason it can't be ported over to Java or Python as well.

[Stargrasper]

Unity uses Mono, which works on Linux fine. And the lazy newb back doesn't connect directly to DF. It launches it, I think, but it doesn't interface with it. It can't read dorves beard lengths in realtime.

Also, this was mostly a proof of concept, to make sure it can be done. Now that I know that it can be, there's no reason it can't be ported over to Java or Python as well.

Yes, the LazyNewbPack is only a launcher.  I've also never successfully been able to make a Unity app work on Linux without errors.

That being said, if you can do it, go for it!

[MorleyDev]

You know, lately I've been thinking about C++ and third party dependency management. There isn't any kind of NuGet for c++, nearest is apt-get for Linux and even that has issues. Too many compilers, too many subtle variations between compilation flags and versions...it's a big problem for any kind of Continuous Integration system.

I mean, I literally have a Jenkins server running locally that constantly checks a variety of third party open source libraries for updates, then pulls and packages those. And then another program I wrote that checks for updates to those packages, and unpacks them to the ext source directory as part of the build scripts (it stores a jenkins build number in the directory too, so it can compare installed and latest versions).

Hmm, instead a centralised repository of build scripts would make more sense (with a NuGet like client that knows how to get and run those scripts), with a program you can call as a part of the build to check for updates and if found (or library not present) downloads and builds the dependency.

Might think on that a bit more, sounds like a good final year university project...

[Twiggie]

Sounds like something I shoulda done, instead of the bullcrap game I put out. At least then I'd've actually learnt something :p

[cerapa]

"Sure", I thought, "SDL2 will be way better!" I thought.

Ah, the folly of a positive mind. I should have know that the compiler would puke its own guts out before rather than accept a replacement to its old friend. It now passive agressively declares that it can't find references to any SDL's functions, and says it cannot find WinMain@16.

I have scoured the net in search of a way to appease the unhappy compiler, but have found only people shouting at others to use tutorials that do not work, to create a GUI program instead of a console program(which mine is certainly not), and a single person who seems to have solved the problem, with a final declaration of "---I'VE HOUND THE SOLUTION!-- –"

EDIT: Wat. You see, SDL2 comes with 2 versions packaged. One is for i686 and the other for x86. I was trying to compile with x86, while I should have been trying with i686.

Whatever, seems I will be continuing development of this after a 3 month period of rewriting pretty much everything about input, drawing and windows.

[Stargrasper]

...

EDIT: Wat. You see, SDL2 comes with 2 versions packaged. One is for i686 and the other for x86. I was trying to compile with x86, while I should have been trying with i686.

Whatever, seems I will be continuing development of this after a 3 month period of rewriting pretty much everything about input, drawing and windows.

Time to point out something on architectural nomenclature.

Common names for 32- and 64-bit processor architectures:
32-bit: x86, IA-32, i386, i486, i586, i686, etc
64-bit: x86_64, amd64, x64

I assume what you said is a typo and you meant i686 and x86_64.  x86 is the name of two CPU architectures from Intel.  The first is a 16-bit architecture.  The second is a 32-bit architecture also known as IA-32.

[cerapa]

Indeed. Didn't know the _64 was that important.

The thing is that my processor is 64-bit, so thats why I tried to compile with the x86_64.

[Stargrasper]

Indeed. Didn't know the _64 was that important.

The thing is that my processor is 64-bit, so thats why I tried to compile with the x86_64.

Which means something, somewhere in the chain, isn't 64-bit.  I don't recall if 32-bit gcc/g++ can compile 64-bit code, but if it can't, that could be your problem.  It's also possible, and probably more likely, that a dependency somewhere is 32-bit.  Basically, you can't normally mix-and-match software for different architectures.  Either all of it is 32-bit or all of it is 64-bit...unless you go out of your way with compatibility libraries.  The reason 32-bit software runs on 64-bit architectures is because most 64-bit computers have two sets of libraries; 32- and 64-bit versions, many being different versions of the same library.  Without these 32-bit libraries, you'll notice many 32-bit applications do not work on 64-bit computers.

It's probably not worth worrying about unless you have a particular reason to want to compile a 64-bit binary.  And even if you do want a 64-bit binary, when it comes time to distribute the thing, you'll want to distribute both 32- and 64-bit binaries, anyway.

[dreadmullet]

Integer overflows are fun:

Code: (C++) [Select]

for(unsigned char c = 0; c < 256; c++){

}
results in an infinite loop.

[alexandertnt]

My favourite from my own code:

Code: [Select]

for(int i = 0; 9 < list.size; i++){
}

where i typo'd a "9" instead of "i".