Whenever i create a new SpotLight object i keep getting debug info in my console.
SpotLight spotlight1 = new SpotLight();
gives an endless stream of:
anfle995.99146
anfle965.99146
anfle965.5
anfle995.99146
anfle965.99146
anfle965.5
I have updated to the latest version but the error persists.
ive reported this before (http://hub.jmonkeyengine.org/forum/topic/system-out-println-in-spotlight/) and nehon patched the code in subversion. i am not sure why the patch hasnt made it in to stable yet though
Fixing trivial bugs in the Engine seems not to be a priority for this project. I wish I understood why.
Fortunately we have nightly builds and the ability to build from (and customize) the trunk sources.
@sgold said: Fixing trivial bugs in the Engine seems not to be a priority for this project. I wish I understood why.
This is a little unfair. It’s not like there is some board sitting around rejecting fixes. If something simple isn’t fixed then it’s because it was overlooked or forgotten about. Gentle reminders are the best way to see that something gets fixed that affects you.
For various reasons, @nehon seems to be the only active engine committer these days. Not the only committer… just the only active one. He’s pulled a few different ways and there are currently three branches that a patch like this needs to go to and every time we update the 3.0.x branch we also need to change the version in three places. So sometimes things slip by. If we don’t think something affects someone on the release branch then it may not get fixed there.
Anyway, just in case, I will dock his pay 50%. 
@pspeed said: Anyway, just in case, I will dock his pay 50%. ;)
Ouch! Now he is only gonna get half of nothing. How is he not going to pay his rent now? I feel imaginary bad for him =(
@t0neg0d said: Ouch! Now he is only gonna get half of nothing. How is he not going to pay his rent now? I feel imaginary bad for him =(
Me too. He already started out French as it was.
@pspeed said: This is a little unfair. It's not like there is some board sitting around rejecting fixes. If something simple isn't fixed then it's because it was overlooked or forgotten about. Gentle reminders are the best way to see that something gets fixed that affects you.
If I’ve been unfair, then I regret that. I didn’t intend any personal criticism—and certainly not of @nehon, who seems not only highly talented, but also unfailingly helpful and polite.
I fully understand that this is a project running on volunteer labor. Volunteers do what they wish and little more, or else they soon burn out.
That said, I’m honestly puzzled by the low level of activity on the engine itself. If, as you say, there’s only one active committer there (and I believe you) then to me that looks like another piece of this same puzzle. Do the other developers regard the engine as boring or difficult or unrewarding to work on? Does maintenance work seem unglamorous? Is there some other disincentive which you can articulate?
As for this particular bug: frankly, it doesn’t affect my work: I haven’t used spotlights yet, and I mostly work with the JME trunk, where the bug is surely fixed. Understand, however, that the reason I work with the trunk is that I long ago despaired of getting fixes back-ported into the 3.0.x line. I’ve heard that if an issue isn’t “blocking” then it must wait until 3.1.
I’m in no position to argue with that, but that sounds to me like a statement of priorities, not a cry for help or an apology for an oversight. Am I misreading the situation?
I thought i fixed this one. Didn’t i?on nightly?
Anyway i will. For now i’m in London until wednesday.
And m’y 50% drop is notre gonna help,things are pretty expensive here
@sgold said: That said, I'm honestly puzzled by the low level of activity on the engine itself. If, as you say, there's only one active committer there (and I believe you) then to me that looks like another piece of this same puzzle. Do the other developers regard the engine as boring or difficult or unrewarding to work on? Does maintenance work seem unglamorous? Is there some other disincentive which you can articulate?
Personally, for me it’s because I have a wife with a brain tumor and have little energy or time outside of the minimal amount I can spend pushing my own projects forward or answering questions on the forum. 3.1 is the future and I will fix things there in my direct areas of expertise (which already requires committing to two branches while our build is in flux) but unless it’s real bug, I personally don’t have time to also make cosmetic fixes to the 3.0.x branch. That attitude is also one of the things that keeps that branch stable… while this bug is clearly easily fixed there are others that are not so clean cut. (The BitmapFont loader being an example where fixing it could in theory break 3.0.x.)
I can’t speak for the numerous other comitters (core devs and others). Mostly I think people fix the stuff in their way and “will get to” the other stuff. Sometimes someone will take a turn through the issue backlog and wipe a bunch out. Things that get reported should get cleared eventually. Also, I think most non-core-dev committers are probably already on some version of HEAD or a trunk with hand-picked changes. (Mythruna builds against a hand-picked trunk while Lemur and Zay-ES build against 3.0.x.)
I have an engine to-do list of about 30 items or so, though. Not sure when I personally will get to them but, yeah, for me there are all of a higher priority than removing a println. Partially because it doesn’t affect me, partially because it’s cosmetic, and partially because “anyone committer do it”, ie: it doesn’t require any special expertise.
Well this thread is kinda unfair to normen for example,
he certainly is active as well, and helped me getting some patches and features into the bullet binding. I think he is currently mostly occupied with the gradle build changes.
The best chance to get patches into the engine is to create change for the svn.
I think it will get better after the switch to gradle is done and there is one branch less to support.
Also note that contributing To the engune is not only committing things.Paul and Normen spend a considerable amount of time answering questions here. There are not a lot of oss projects where you can get an answer within the hour.
I also think that community around jme3 is highly active. I have seen commercial solution with way less support.
From my point of view moving to Gradle/Git might going to help a bit. At least if you find one of those cosmetical bugs, create a fork, fix it and submit a merge request. The core them than has just to review the changes. At least it sounds more comfortable then posting a few lines here in the forum and they have to apply the changes to 3 branches…
Well yes, but lets not start the git discussion again, it hopefully will change in time, but there are currently already enough changes ongoing.
Was not intended to start that discuss. AFAIK it is on the todo list anyways.
@nehon said: I thought i fixed this one. Didn't i?on nightly? Anyway i will. For now i'm in London until wednesday.
You promptly fixed it in the JME trunk at rev 10843, so the fix should be in every nightly build since Oct. 21st. However, the 3.0final codeline branched from trunk at rev 10749, and the fix was never backported there, which explains why the bug is exposed in 3.0.5.
In an ideal world, Raschke would stay on 3.0.5 until the 3.1 release, but I have no idea when that might occur. In the mean time, there are plenty of nightlies to choose from.
@pspeed said: Sometimes someone will take a turn through the issue backlog and wipe a bunch out. Things that get reported should get cleared eventually. Also, I think most non-core-dev committers are probably already on some version of HEAD or a trunk with hand-picked changes. (Mythruna builds against a hand-picked trunk while Lemur and Zay-ES build against 3.0.x.)I have an engine to-do list of about 30 items or so, though. Not sure when I personally will get to them but, yeah, for me there are all of a higher priority than removing a println. Partially because it doesn’t affect me, partially because it’s cosmetic, and partially because “anyone committer do it”, ie: it doesn’t require any special expertise.
I’ve come to doubt the effectiveness of submitting patches and filing issues at the GoogleCode site. For instance, it looks like the issue backlog hasn’t been swept since at least December 5th. (That’s not to say that it will never happen, of course.)
I sympathize with you and your situation, Paul, and also with Normen and Rémy, and I hate feeling (as I sometimes do) that most of what I do around here amounts to nitpicking other people’s work. I think I want to become a committer, empowered make changes which don’t require special expertise. This might not help the original poster, but perhaps it would ease the load on Rémy, not to mention my frustration level.
Although I’m not a software professional, duplicating commits across two codelines doesn’t scare me. So—what’s the procedure for becoming committer?
Well, just look at the people who actually had/have big contributions to make. They never get there because they get some kind of nervous breakdown before anything is done.
So there seems to be a correlation between how much you do for the engine and how much you become insane. Given most of the core devs are in it for more than three years I guess they/we strike a good balance
If you want to be a core member we need to know you don’t end up with a nervous breakdown at some point Our way to test that is to invite you to the core chat, make fun about you for a few weeks and then see if you still stand. Then you became one of the miserable people who have to deal with the burden of giving something to others for free
@sgold said: I've come to doubt the effectiveness of submitting patches and filing issues at the GoogleCode site. For instance, it looks like the issue backlog hasn't been swept since at least December 5th. (That's not to say that it will never happen, of course.)I sympathize with you and your situation, Paul, and also with Normen and Rémy, and I hate feeling (as I sometimes do) that most of what I do around here amounts to nitpicking other people’s work. I think I want to become a committer, empowered make changes which don’t require special expertise. This might not help the original poster, but perhaps it would ease the load on Rémy, not to mention my frustration level.
Although I’m not a software professional, duplicating commits across two codelines doesn’t scare me. So—what’s the procedure for becoming committer?
@normen said: If you want to be a core member we need to know you don't end up with a nervous breakdown at some point :) Our way to test that is to invite you to the core chat, make fun about you for a few weeks and then see if you still stand.
now that explains why the core team is so small… the angry monkey logo did match the situation
That doesn’t mean you can’t commit to trunk as a non-core-member though. If you paste a patch here so we can check it and ask us if you can commit that as it is you sure can. But for breaking or changing the engine you need to be a core member.