PA Programming Thread :: PAdev.net - Need hosting for a service of yours? Check it out.

Infidel

Why aren't your times just converted to ints ahead of time and compared normally?

agoaj

Because the only time the numbers matter as numbers is for sorting. Every other use requires them as text.

Infidel

Storing the numeric values will save on calculating multiple times during sorts, depends on your usage how much that matters.

The important part is as mentioned, you need to consistently have a value for "not a number" if you want consistent results.

wildwood

Left-padding dates with zeroes, like having a fixed format of YYYYMMDD, makes them sortable as both strings and numbers.

bowen

regexPattern = "([\\+-]?\\d+)([eE][\\+-]?\\d+)?";
if(time.matches(regexPattern) && arg0.time.matches(regexPattern)) {
	try {
		return ((Integer.parseInt(time)) - ((Integer.parseInt(arg0.time));
	} catch(NumberFormatException e) {
		//forward to parent function, numbers outside range probably
		throw e;
	}
} else {
	//throw exception here, numbers not in correct format
	//best not to assume any arthimetic operation
}

I have no idea if that works in Java, but that's the jist. Probably the only time I'd use regex is to do something like this if the language doesn't implement something like "tryparse" to return me a bool for easy error catching in known cases.

bowen

wildwood wrote:

Left-padding dates with zeroes, like having a fixed format of YYYYMMDD, makes them sortable as both strings and numbers.

The best thing about using date formats in this way.

agoaj

Why would using a regex be preferable to using parse?
And the time string is just flat milliseconds, no date issues for me to worry about.

Grey Paladin

I got into an arguement about a feature of the C language. If anyone can help settle it I'll appreciate it.

K&R page 99 (Second printing) reads 'In evaluating a[ i ], C converts it to *(a+i) immediately; the two forms are equivalent.'. I took it as meaning that any time array_name[subscript] is invoked in the code, the program converts it to the form *(array_name+subscript), where the array's name is the address of the first element of the array. The other person says this only happens when arrays are passed to functions. Who is correct?

Phyphor

It always converts, that's why

a[i]

and

i[a]

are equivalent

Grey Paladin

Cool. Thanks for the lightning-quick response.

ASimPerson

That's one of my favorite bits of C trivia. The brackets are just syntactic sugar for the conversion to going to the correct address and dereferencing it.

Anyway, I was just catching up on the thread and reading through the C# vs. Objective-C stuff.

It makes me wonder what's wrong with me for liking just plain ol' C.

Grey Paladin

I also like plain old C! Most of the time, at least, when it is not confusing the hell out of me. I suspect it has something to do with having to code with Java for 3 years.

Out of curiosity, I disassembled the following piece of code in GCC, on an x86 machine.

...
	int arr[5];
	arr[4]=6;
	*(arr+4)=6;
...

The disassembler gave me this. The C code is comments that mark the following text as the translation (I think, anyhow)

...
;arr[4]=6;
004013ce:   movl $0x6,0x1c(%esp)
;*(arr+4)=6;
004013d6:   lea 0xc(%esp),%eax
004013da:   add $0x10,%eax
004013dd:   movl $0x6,(%eax)
...

It seems that the two commands do not disassemble to the same code. I wonder why that is, and if there actually is a difference which is faster. I don't remember much from the bit of assembly I was taught in highschool.

Phyphor

You might need to turn optimizations on

ASimPerson

I would guess that the brackets are optimized in some way to correspond to the x86 method of loading effective addresses. I checked on ppc and mips and it seems to make a difference there too.

Phyphor

Well the language states that they're equivalent, but its up to the compiler to transform it to asm, technically all it must do is produce the same result no matter which one you use

ASimPerson

Yeah, pretty much. And I think compilers would tend to optimize brackets because it's such a common idiom.

Also I did try turning optimizations on but gcc was just optimizing the variables out because they weren't being used and I'm too lazy to make the program slightly less trivial so that doesn't happen

ecco the dolphin

Grey Paladin wrote:

I also like plain old C! Most of the time, at least, when it is not confusing the hell out of me. I suspect it has something to do with having to code with Java for 3 years.

Out of curiosity, I disassembled the following piece of code in GCC, on an x86 machine.

...
	int arr[5];
	arr[4]=6;
	*(arr+4)=6;
...

The disassembler gave me this. The C code is comments that mark the following text as the translation (I think, anyhow)

...
;arr[4]=6;
004013ce:   movl $0x6,0x1c(%esp)
;*(arr+4)=6;
004013d6:   lea 0xc(%esp),%eax
004013da:   add $0x10,%eax
004013dd:   movl $0x6,(%eax)
...

It seems that the two commands do not disassemble to the same code. I wonder why that is, and if there actually is a difference which is faster. I don't remember much from the bit of assembly I was taught in highschool.

Functionally the same.

movl $0x6,0x1c(%esp)

is effectively:

Store the constant value "6" into (esp+0x1C). i.e. arr[4] = 6;

lea 0xc(%esp),%eax
add $0x10,%eax
movl $0x6,(%eax)

is effectively:

Load the pointer to the array into register eax i.e. (arr)
Add 0x10 (4 * 4 bytes) to get to index 4 i.e. (arr + 4)
Store the constant 6 into the address pointed to by register eax i.e. *(arr+4) = 6

As Phyphor says, I'm pretty sure turning optimisations on will make them both the same.

Jasconius

ASimPerson wrote:

It makes me wonder what's wrong with me for liking just plain ol' C.

Means your beard is too long and you designed your own circuit board to automate your french press!

Infidel

Jasconius wrote:

ASimPerson wrote:

It makes me wonder what's wrong with me for liking just plain ol' C.

Means your beard is too long and you designed your own circuit board to automate your french press!

I wish to subscribe to your newsletter.

Frem

So I'm not particularly fond of Javascript, but I'm also not a huge fan of Flash, and Flash and NaCl don't run everywhere anyway. I'm too lazy to play games I actually have to download and unzip, so I figure I should hold myself to my own standard of laziness.

What's the best Javascript game library for 2D stuff? I rather liked Love2D's api. Anyone use JawsJS before?

GnomeTank

I forgot how easy Lua is to work with. It really is incredibly easy to embed, even in a C# program (I am using Tao.Lua). It's a pretty bare bones wrapper, but that's really what I want. LuaInterface is neat, but it doesn't compile on Linux (automatic deal breaker), and it doesn't allow near enough control over what's injected in to the scripting environment. I don't want script writers to have access to anything except the API's I give them. No file I/O, no network I/O, no ability to 'require' or 'load' other Lua files. Writing the high-level wrapper code myself lets me do that.

bowen

agoaj wrote:

Why would using a regex be preferable to using parse?
And the time string is just flat milliseconds, no date issues for me to worry about.

Why would I? I prefer tryparse style techniques ("Does this evaluate properly") in my programming. I don't like defaulting to try/catch to determine correctness. Try/catch is to determine faults like index out of range, not for something like "Is this a parse-able integer?" but more like "I tried to parse this integer, tell me if it doesn't work," which can fail on a lot of things which you and I would consider valid. Not to mention try/catch tends to be a bit slower, so anticipating incorrectness in your logic will speed it up, so long as you can go "if(these are ints)" in some way without resorting to "try to parse this as an int, tell me if it doesn't work."

I hate that logic flow, and I hate java for encouraging it. Because I see a lot of things where people resort to try/catch for assignments in C++ code, or even C# code.

Things like different locale number values, something outside the range of a valid integer, so on and so forth. (I think those are the two biggest offenders for NFE)

jackal

I always wrap TryParse in a version that returns Maybe<T>. It works pretty well.

bowen

jackal wrote:

I always wrap TryParse in a version that returns Maybe<T>. It works pretty well.

It really helps with the paradigm that your modules and code should not throw/catch exceptions except in extreme conditions and should forward errors to the topmost code it can so that you can determine what you need to do, and not the library.

You see this a lot in things like "I caught an exception, now exit." in libraries which causes libraries to kill the main running application which is not desirable in the least bit.

urahonky

bowen wrote:

jackal wrote:

I always wrap TryParse in a version that returns Maybe<T>. It works pretty well.

It really helps with the paradigm that your modules and code should not throw/catch exceptions except in extreme conditions and should forward errors to the topmost code it can so that you can determine what you need to do, and not the library.

You see this a lot in things like "I caught an exception, now exit." in libraries which causes libraries to kill the main running application which is not desirable in the least bit.

My company has a TON of try/catch exceptions everywhere. It generally keeps the program running if something happens instead of just breaking everything. It also stores the problem in a log file so they can email it to us and we can find out exactly what happened.

jackal

With Maybe<T> the code goes like:

parsed = Decimal.TryParse(someInput)
if not parsed.HasValue
  'do whatever you do to handle a lack of a value
'do something with parsed.Value

So it's a bit less awkward than passing in a ref and checking the returned boolean, but we are on the same side that formatexceptions are a terrible way to handle it.

urahonky

Here's another thing that needs to die in a fire: the 80 character limit per line. How many people actually print out code any more? I can understand not wanting the entire program on a single line, but if I have to break something up 3 or 4 times it makes it much harder to read and makes the code uglier.

jackal

urahonky wrote:

bowen wrote:

jackal wrote:

I always wrap TryParse in a version that returns Maybe<T>. It works pretty well.

It really helps with the paradigm that your modules and code should not throw/catch exceptions except in extreme conditions and should forward errors to the topmost code it can so that you can determine what you need to do, and not the library.

You see this a lot in things like "I caught an exception, now exit." in libraries which causes libraries to kill the main running application which is not desirable in the least bit.

My company has a TON of try/catch exceptions everywhere. It generally keeps the program running if something happens instead of just breaking everything. It also stores the problem in a log file so they can email it to us and we can find out exactly what happened.

This sounds like insanity to me. Unless you are really careful about where these try...catch blocks are so that the program is never in an unknown state you're just keeping a program going that you can't reason about. Crashing is far better than giving incorrect results or destroying data.

urahonky

jackal wrote:

urahonky wrote:

bowen wrote:

jackal wrote:

I always wrap TryParse in a version that returns Maybe<T>. It works pretty well.

It really helps with the paradigm that your modules and code should not throw/catch exceptions except in extreme conditions and should forward errors to the topmost code it can so that you can determine what you need to do, and not the library.

You see this a lot in things like "I caught an exception, now exit." in libraries which causes libraries to kill the main running application which is not desirable in the least bit.

My company has a TON of try/catch exceptions everywhere. It generally keeps the program running if something happens instead of just breaking everything. It also stores the problem in a log file so they can email it to us and we can find out exactly what happened.

This sounds like insanity to me. Unless you are really careful about where these try...catch blocks are so that the program is never in an unknown state you're just keeping a program going that you can't reason about. Crashing is far better than giving incorrect results or destroying data.

Wonder if there's a way to see how many try/catches we have... But we also have to write them to ensure that data is not lost and incorrect results aren't given. Basically if it crashes it tells the user what happened, where to get the log, where to send it to, and how to contact us. It sounds odd I know, but it seems to work out for them.

Jasconius

Frem wrote:

So I'm not particularly fond of Javascript, but I'm also not a huge fan of Flash, and Flash and NaCl don't run everywhere anyway. I'm too lazy to play games I actually have to download and unzip, so I figure I should hold myself to my own standard of laziness.

What's the best Javascript game library for 2D stuff? I rather liked Love2D's api. Anyone use JawsJS before?

I'm currently breaking ground on Javascript 2D with CoffeeScript

I was a CoffeeScript skeptic for a while but I tried it this weekend and I love it. It hides everything you hate about javascript and you don't surrender much in the process.

From there it just depends on your philosophy. I'm a Canvas kind of guy so I start with EaselJS to get super basic graphics tools going quickly.

bowen

jackal wrote:

urahonky wrote:

bowen wrote:

jackal wrote:

I always wrap TryParse in a version that returns Maybe<T>. It works pretty well.

It really helps with the paradigm that your modules and code should not throw/catch exceptions except in extreme conditions and should forward errors to the topmost code it can so that you can determine what you need to do, and not the library.

You see this a lot in things like "I caught an exception, now exit." in libraries which causes libraries to kill the main running application which is not desirable in the least bit.

My company has a TON of try/catch exceptions everywhere. It generally keeps the program running if something happens instead of just breaking everything. It also stores the problem in a log file so they can email it to us and we can find out exactly what happened.

This sounds like insanity to me. Unless you are really careful about where these try...catch blocks are so that the program is never in an unknown state you're just keeping a program going that you can't reason about. Crashing is far better than giving incorrect results or destroying data.

The easiest way to do it is to have your main method start a subclassed/surrogate singleton with a main method in it. This way you can do something like:

class MyMainClass
{
    int main(string[] args //or however java does it)
    {
        try {
            SomeOtherClass surrogate = new SomeOtherClass();
            surrogate.Main(args);
        } catch(Exception E) {
            //error report any major crashes here
        }
    }
}

This way if you have a system crash that you haven't contaminated for internally to your code, you can at least know what happened without having to litter your code with try/catch for every little exception.

jackal

That's just replacing the default exception handler with your own, and in .Net (I can't speak for Java) there is a built in way to do that already.

bowen

It was mostly a catchall so the program doesn't crash outright at unhandled exceptions, so that there's still a way to record it. Not as a stopgap or overriding the exception handler.

The subclasses will still catch their appropriate exceptions as specified but larger ones and unplanned (lolwat) ones won't go uncaught.

It also makes code a lot better to read than something like

try {
  //this
} catch(SomeException e) {
  //that
} catch(SomeOtherException e) {
  //something else
} catch(ThirdSomeException e) {
  //why not this too
} catch(FourthSomeException e) {
  //you should probably catch this
} catch(Exception e) {
  //just in case
}

Because everytime I see that I will murder someone. If your index is out of range, fuck you, you don't need to catch the exception you need to pay attention to the shit you're doing.

urahonky

Agreed. Anything more than one or two catches and it feels like it's a problem with the code in the try than it is whatever's entered.

jackal

What I'm saying in .Net (at least, again I can't say for java) there is already a way to set up a default handler that can log before the program is taken down. You can wire up an UnhandledException event that can log before the exception is handled by the default handler which displays the unhandled exception dialog and takes the whole program down.

Incindium

You can register your own Unhandled Exception event handler in C#. However I've ran into issues where that didn't actually work correctly when dealing with a windows service with threading. You are probably safer just wrapping your stuff in try/catches.

Program exception flow is a pretty important thing to work through if you are trying to create software that is fault tolerant and can recover automatically from error states. try/catch(and log error information) is the cornerstone to doing that.

bowen

jackal wrote:

What I'm saying in .Net (at least, again I can't say for java) there is already a way to set up a default handler that can log before the program is taken down. You can wire up an UnhandledException event that can log before the exception is handled by the default handler which displays the unhandled exception dialog and takes the whole program down.

Ah I didn't know that. And I don't think Java does. In my experience no one does this though, or at least the vast majority don't, and I don't (didn't even know about it).

bowen

Index out of range exceptions bug me the most. Like... you didn't know you were going out of range? You have a array.count/size value to read, you can test every. single. time.

bowen

Incindium wrote:

You can register your own Unhandled Exception event handler in C#. However I've ran into issues where that didn't actually work correctly when dealing with a windows service with threading. You are probably safer just wrapping your stuff in try/catches.

Program exception flow is a pretty important thing to work through if you are trying to create software that is fault tolerant and can recover automatically from error states. try/catch(and log error information) is the cornerstone to doing that.

Absolutely, but you shouldn't use them to test if an integer is valid. I hate that java basically encourages that.

Incindium

bowen wrote:

Absolutely, but you shouldn't use them to test if an integer is valid. I hate that java basically encourages that.

No I totally agree with you... catching an exception should not be a integral part of your normal program flow. Sounds like Java just needs to implement the TryParse() methods on their basic types like C#.