 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/6/2012 2:02, Orchid Win7 v1 wrote:
> On 06/04/2012 03:12 AM, Darren New wrote:
>> On 4/3/2012 6:41, Invisible wrote:
>>> When you install the normal JDK bundle, it doesn't include a parsing
>>> library.
>>
>> Now, grasshopper, do you understand why every configuration file
>> everywhere in any Java-based system is based on XML or property files?
>
> Oh, well, that's almost an /advantage/. Why invent yet another file format
> when you can use an existing well-supported one?
Because XML sucks for that purpose, because it was never designed for that
purpose.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Now, grasshopper, do you understand why every configuration file
>>> everywhere in any Java-based system is based on XML or property files?
>>
>> Oh, well, that's almost an /advantage/. Why invent yet another file
>> format
>> when you can use an existing well-supported one?
>
> Because XML sucks for that purpose, because it was never designed for
> that purpose.
So what would you use?
Personally, I'm somewhat partial to JSON. Unfortunately, the rest of the
world seems to like the horrifyingly awful YAML...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I almost feel like I'm going mad. I'm trying to use the NetBeans
debugger, and... well... it doesn't appear to /work/.
I'm single-stepping through the code, and half the time the local
variables window doesn't even remotely correspond to the code I'm
actually looking at. I step over a line that says id++, and the id field
remains stubbornly fixed at its previous value. Even though I just
god-damn /watched/ the increment instruction execute! WTF?!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/7/2012 11:01, Orchid Win7 v1 wrote:
> So what would you use?
I would use something specific to what I'm configuring, if possible. I don't
want my makefiles, my database schema, my network packet layout, and my
description of my UI to all be written in the same language.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/7/2012 1:52 PM, Orchid Win7 v1 wrote:
> I almost feel like I'm going mad. I'm trying to use the NetBeans
> debugger, and... well... it doesn't appear to /work/.
>
> I'm single-stepping through the code, and half the time the local
> variables window doesn't even remotely correspond to the code I'm
> actually looking at. I step over a line that says id++, and the id field
> remains stubbornly fixed at its previous value. Even though I just
> god-damn /watched/ the increment instruction execute! WTF?!
Often a result of the "id" being tracked having been from "someplace
else", like a different function, and thus the "local" copy is changing,
or the copy within *this instance of the function call*, but not the one
that is actually being tracked (which was the last time it was called,
or from a different function or... who the hell knows). Basically,
tracking is context insensitive, so you are not tracking which ever
version of the variable you are currently stepping through, as expected,
you are tracking one from a different context.
And, yeah, its a damn pain in the ass that this happens, but sort of
understandable (especially when its in a library, or the like, where you
might have 3-4 instances running in memory, so you actually could, in
principle, have 3-4 different copies of the same variable, all of them
changing independently). What might be nice is a way to identify which
thing the variable really belongs to, like contextual highlighting
**if** its the one local to what you are looking at. Or, if you want to
live dangerous, and be more confused, you could just have it track which
ever one "is" being looked at... I think the "highlight the one you are
currently looking at" version, would be better, since you can tell what
you are actually dealing with, and not confuse the current one with one
that belongs to something else, or some other instance. A combination
could be helpful in some cases too, but then you kind of need to have
some way to tell which of these is the "local" one:
int id 234
int id 10
int id 135435
Other than that one happens to be changing. And, there may be cases
where you do need to see what all of them at doing, even with the same
name, so:
main: int id 234
sub1: int id 10
print: int id 135435
Its just, doing that isn't something some debuggers just don't handle
right (in at least one case, setting the watch on it worked, the first
pass through, but the second time the function was called, it was no
longer tracking the same variable. Why? Because the original variable
didn't exist, just a new one, which happened to have the same name, and
so it couldn't "track" changes to something that wasn't there any more.
Yeah, doesn't make a lot of sense, from a debugging standpoint, to me
either, but that is what the bloody thing was doing, tracking the "last
value" the original one had, even thought it was gone, and I wanted to
see what the new copy was doing. I don't remember how/if I got around
the bloody problem at the time.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I'm single-stepping through the code, and half the time the local
>> variables window doesn't even remotely correspond to the code I'm
>> actually looking at. I step over a line that says id++, and the id field
>> remains stubbornly fixed at its previous value. Even though I just
>> god-damn /watched/ the increment instruction execute! WTF?!
> Often a result of the "id" being tracked having been from "someplace
> else", like a different function, and thus the "local" copy is changing,
> or the copy within *this instance of the function call*, but not the one
> that is actually being tracked (which was the last time it was called,
> or from a different function or... who the hell knows). Basically,
> tracking is context insensitive, so you are not tracking which ever
> version of the variable you are currently stepping through, as expected,
> you are tracking one from a different context.
Thing is, most of the time when you jump to another function, the local
variables display updates to reflect that you're now in a different
scope. But, about 30% of the time, /it doesn't update/. So you're now
looking at a completely irrelevant bunch of data while single-stepping
your code.
I haven't seen any other debugger fail in this way. I've seen debuggers
where you can't /see/ all the local variables, only the once you've
configured to "watch". But I haven't seen a debugger where the watched
variables don't actually frigging update at random. I can only imagine
it's a bug. A bug... in the debugger. Now that's meta.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/04/2012 11:01 PM, Darren New wrote:
> On 4/7/2012 11:01, Orchid Win7 v1 wrote:
>> So what would you use?
>
> I would use something specific to what I'm configuring, if possible. I
> don't want my makefiles, my database schema, my network packet layout,
> and my description of my UI to all be written in the same language.
Um... why?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/8/2012 1:53, Orchid Win7 v1 wrote:
> On 07/04/2012 11:01 PM, Darren New wrote:
>> On 4/7/2012 11:01, Orchid Win7 v1 wrote:
>>> So what would you use?
>>
>> I would use something specific to what I'm configuring, if possible. I
>> don't want my makefiles, my database schema, my network packet layout,
>> and my description of my UI to all be written in the same language.
>
> Um... why?
Because that means you're using the wrong language for all of them. It's
inefficient, confusing, and full of senseless markup that's irrelevant to
the problem at hand.
How would you feel if someone said "We're replacing Haskell syntax with XML"?
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/8/2012 1:53, Orchid Win7 v1 wrote:
> Thing is, most of the time when you jump to another function, the local
> variables display updates to reflect that you're now in a different scope.
> But, about 30% of the time, /it doesn't update/.
I'm guessing either your debugger is bugged, or your compiler is doing a
good job of inlining functions.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/8/2012 1:53 AM, Orchid Win7 v1 wrote:
> I haven't seen any other debugger fail in this way. I've seen debuggers
> where you can't /see/ all the local variables, only the once you've
> configured to "watch". But I haven't seen a debugger where the watched
> variables don't actually frigging update at random. I can only imagine
> it's a bug. A bug... in the debugger. Now that's meta.
Thing is, I have seen it. I don't remember the context, but I think it
had something to do with "when" and "how" I added the watch for that
variable. Something to do with creating it "during" the execution of the
function, instead of as a global watch, tied to 'all' copies of that
specific function's variables, or something.
And, while I can't be sure, I think it was one of the higher end
debuggers. But, yeah, it could have been a bug too.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
