The other month, I tried to filter out classes like "java.*" in the Open Type dialog, with little success; see http://stackoverflow.com/questions/11936524/filter-out-our-own-types-in-eclipse-open-type, for some details. It does not seem to be possible, to any larger extent of usefulness. Now, I forgot about it and moved on with my...so called life. But just now, this episode came back to at me. Trying to auto-assist at "import java.|" (the | being my caret), no java.* type name showed up. Weird! Annoying! Has my RTE library vanished? Did Oracle decide to cancel Java? No.
I had left my filter pattern active (the checkbox checked). It's the correct behavior, of course, we should certainly not expect the implementation to be over-complexified to handle this case, even though it is a bit funny to not get a match on your very explicit request to match "java.|" due to a filtering pattern "java.*". If you have the same sense of humor as me. Let's just be happy computers are still not anywhere near human domination in terms of intelligence. That, or they just don't want to help us.
Software development woes. Java-based development in particular. Also, philosophizing, architecture, design.
Friday, August 24, 2012
Thursday, August 23, 2012
Undefined Timeout Burns
Doing some pleasurable (not overly) JavaScript development (slow...). I understand the advantages of dynamic languages (no I don't quite understand it, but I am being polite), but sometimes (most of the time) it burns.
Not well formatted, and untested, but you get the idea.
var timeout_millis = outer_params.timeout_millis;
var root_path = outer_params.root_path;
function loop_callback() {
setTimeout(timeout_callback, timeout_millis);
function timeout_callback() {
var params = outer_params;
do_something_and_then_call(params, loop_callback);
}
}
loop_callback();
Simple enough, right?
But this code failed miserably. 100% CPU. JS debugger locks up. JS console locks up. Good grief.
Turns out I didn't set the 'timeout_millis' of 'outer_params'. So 'timeout_millis' will be undefined. And what does setTimeout() do? Does it think this a bit strange? No. It thinks zero is an excellent choice here. Thus your loop will really run wild, with the aforementioned effects. Making it hard to find your mistake, since there is no separation between the debugger and the debuggee code in Chrome, there's no separate debugger thread that one could protect from the debugged thread or process by prioritizing the debugger. The debugger simply locks up, partly because console gets too much ouput.
Here's an immediate thing to help avoid the same situation in the future:
if (!timeout_millis) {And maybe
alert("timeout_millis == " + timeout_millis);
}
(function () {
var original_setTimeout = window.setTimeout;
window.setTimeout = function (callback, timeout_millis) {
if (timeout_millis === undefined) {
alert("timeout_millis == " + timeout_millis);
}
original_setTimeout(callback, timeout_millis);
};
})();
Not well formatted, and untested, but you get the idea.
Motivation II
One writes about motivation when it's gone missing.
There's this kind of motivation block that seems to be physiological. It's hard to describe. Not quite tired, but it can happen when you've underslept; but I think the most common time is after a night of normal sleep catching up accumulated undersleep. It's a kind of nervousness, isn't it. It can feel rather like excitement, actually. But still blocked, so there's some kind of tension, thus the nervous feel to it.
Eating a little too much can probably also be a contributing factor.
Coffee or caffeine doesn't really help. It rather adds to the nervousness, although I haven't done any study on it.
I don't know what to do about it. Walking doesn't help either. Possibly relaxing, thoroughly, but that's a pretty paradoxical thing to be able to do at work.
Wait it out. How long?
One can do some cleaning. The folders named like "untitled folder 21" in the Desktop folder, for example.
There's this kind of motivation block that seems to be physiological. It's hard to describe. Not quite tired, but it can happen when you've underslept; but I think the most common time is after a night of normal sleep catching up accumulated undersleep. It's a kind of nervousness, isn't it. It can feel rather like excitement, actually. But still blocked, so there's some kind of tension, thus the nervous feel to it.
Eating a little too much can probably also be a contributing factor.
Coffee or caffeine doesn't really help. It rather adds to the nervousness, although I haven't done any study on it.
I don't know what to do about it. Walking doesn't help either. Possibly relaxing, thoroughly, but that's a pretty paradoxical thing to be able to do at work.
Wait it out. How long?
One can do some cleaning. The folders named like "untitled folder 21" in the Desktop folder, for example.
Monday, August 20, 2012
Logging Circular JSON
Something like this:
console.log(FUNCTION_NAME + " " + JSON.stringify(params));Is often an easy way to get good debug logging. Except when:
Chrome 'Sources' Note
What the -- ?
There is one script that doesn't show up in the Chrome 'Sources' tool. Same page in Safari, the script shows up.
The scripts/sources GUI design seems to have changed for the worse in Chrome, BTW. I have to click to get the list of sources to show up, each time it seems. And the target to click is really small.
But it's easy to fix. Observe screenshot:
See the little two-pane icon under Network? It looks like this ascii graph: "[| ]". Click that, and you get (back to) the favored (by me) GUI: the source list is always showing, clickable.
If you have a small screen, then Maybe the other mode is better. Maybe.
---
This is strange: now my js source that was missing, shows! Is it the same weird Chrome caching behavior that I've experienced many times, and that I imagine I am not just imagining... or am I crazy?
EDIT: no, it's not easy to 'fix': the GUI layout reverts next time you reload. Ditch-worthy. Back to Safari, I guess. EDIT: no, I meant 'when you load a new tab'.
There is one script that doesn't show up in the Chrome 'Sources' tool. Same page in Safari, the script shows up.
The scripts/sources GUI design seems to have changed for the worse in Chrome, BTW. I have to click to get the list of sources to show up, each time it seems. And the target to click is really small.
But it's easy to fix. Observe screenshot:
See the little two-pane icon under Network? It looks like this ascii graph: "[| ]". Click that, and you get (back to) the favored (by me) GUI: the source list is always showing, clickable.
If you have a small screen, then Maybe the other mode is better. Maybe.
---
This is strange: now my js source that was missing, shows! Is it the same weird Chrome caching behavior that I've experienced many times, and that I imagine I am not just imagining... or am I crazy?
EDIT: no, it's not easy to 'fix': the GUI layout reverts next time you reload. Ditch-worthy. Back to Safari, I guess. EDIT: no, I meant 'when you load a new tab'.
Saturday, August 18, 2012
Safe Reformatting of Javadoc Hyperlinks
I was gonna write, and did write, a little piece on Safe Reformatting of Javadoc Hyperlinks. Ironically, the blogger.com rendered the blog post wrong. I then clicked 'Go back to draft' or whatever it'd be called in English, because I thought I had published the thing. The saved version turned out to be blank after that. That sucked a bit.
I'll have to redo it then, and never mind the Javadoc examples that rendered wrong.
The trick is to use double quotes for your href hyperlink attribute value, not single quotes. The Eclipse Javadoc formatter will never break a doubly-quoted string, it seems. When I used single-quoted href values, the fomatter would often chop off characters from the link text one by one, and put on the next line, and also separate the "
" would disintegrate too. With doubly quoted string, the '>' and link text will most probably end up on a new line, and be safe from chopping.
A second trick is to put spaces between the angles and the link text, e.g. '[...]> link-text
'. That will probably help with the above shredding too; the formatter will prefer to break on spaces, rather than between '<' and '/a>', which has happened to me a lot.
PS. Or somebody fix the Eclipse formatter... and while you're at it, add a better escape than @code and @literal, which don't work with '@' in the escaped text.
EDIT: Well look at that, the rendering is fuggled up again. Never mind. Here's another tip: never paste html into the blogger editor. And tip 2: edit your posts using not the blogger editor...
UPDATE: Just noticed that leaving a space before the link ('anchor') end tag makes the space be underlined; even if there is another space after the end tag. So leading space may be enough. Or no space at all, the double-quoting may be sufficient.
I'll have to redo it then, and never mind the Javadoc examples that rendered wrong.
The trick is to use double quotes for your href hyperlink attribute value, not single quotes. The Eclipse Javadoc formatter will never break a doubly-quoted string, it seems. When I used single-quoted href values, the fomatter would often chop off characters from the link text one by one, and put on the next line, and also separate the "
" would disintegrate too. With doubly quoted string, the '>' and link text will most probably end up on a new line, and be safe from chopping.
A second trick is to put spaces between the angles and the link text, e.g. '[...]> link-text
'. That will probably help with the above shredding too; the formatter will prefer to break on spaces, rather than between '<' and '/a>', which has happened to me a lot.
PS. Or somebody fix the Eclipse formatter... and while you're at it, add a better escape than @code and @literal, which don't work with '@' in the escaped text.
EDIT: Well look at that, the rendering is fuggled up again. Never mind. Here's another tip: never paste html into the blogger editor. And tip 2: edit your posts using not the blogger editor...
UPDATE: Just noticed that leaving a space before the link ('anchor') end tag makes the space be underlined; even if there is another space after the end tag. So leading space may be enough. Or no space at all, the double-quoting may be sufficient.
Wednesday, August 15, 2012
Eclipse Extract Method Not All Paths End In Return
Here's an almost interesting find. I had code like the following:
No big deal. Actually it makes sense, since refactoring means not to change meaning, and refactored meaning should probably be along this line:
And by that reasoning the error is good. But it so happened that in my attempted refactoring, the continuation of the refactored section had no more code, just getting out of the method, so the refactoring in my mind (no return in front) wouldn't have changed the meaning, if you follow me.
Anyhow. I just pushed the refactoring forward, overriding the error.
[statements]Did 'Extract Method' on the above section. Got an error for "Not All Paths End In Return", even though refactoring should work fine.
if (...) {
return;
}
[statements]
if (...) {
return;
}
[statements, but not 'return;']
No big deal. Actually it makes sense, since refactoring means not to change meaning, and refactored meaning should probably be along this line:
refactoredMethod(...); return;
And by that reasoning the error is good. But it so happened that in my attempted refactoring, the continuation of the refactored section had no more code, just getting out of the method, so the refactoring in my mind (no return in front) wouldn't have changed the meaning, if you follow me.
Anyhow. I just pushed the refactoring forward, overriding the error.
Subscribe to:
Posts (Atom)

